From owner-freebsd-current@FreeBSD.ORG Sun Aug 18 15:23:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A1E3A75B for ; Sun, 18 Aug 2013 15:23:53 +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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 337532C41 for ; Sun, 18 Aug 2013 15:23:52 +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 <1VB4pU-0023dX-N5>; Sun, 18 Aug 2013 17:23:44 +0200 Received: from g229174215.adsl.alicedsl.de ([92.229.174.215] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1VB4pU-000VGN-IG>; Sun, 18 Aug 2013 17:23:44 +0200 Date: Sun, 18 Aug 2013 17:23:40 +0200 From: "O. Hartmann" To: Tim Kientzle Subject: Re: /etc/namedb->@ referrs to NIL after crash or typing "reboot" (not shutdown -r) Message-ID: <20130818172340.103eb39e@thor.walstatt.dyndns.org> In-Reply-To: References: <20130817113636.21346cd2@thor.walstatt.dyndns.org> <520FAE99.8040003@passap.ru> <20130817193517.2bf01dfe@thor.walstatt.dyndns.org> <20130817201750.4cc9907b@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_/y0V=HmOQb.K14DMEdkss0+b"; protocol="application/pgp-signature" X-Originating-IP: 92.229.174.215 Cc: FreeBSD CURRENT , Boris Samorodov 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, 18 Aug 2013 15:23:53 -0000 --Sig_/y0V=HmOQb.K14DMEdkss0+b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 17 Aug 2013 11:41:08 -0700 Tim Kientzle wrote: >=20 > On Aug 17, 2013, at 11:17 AM, O. Hartmann wrote: >=20 > > On Sat, 17 Aug 2013 10:42:07 -0700 > > Tim Kientzle wrote: > >=20 > >>=20 > >> On Aug 17, 2013, at 10:35 AM, O. Hartmann wrote: > >>=20 > >>> On Sat, 17 Aug 2013 21:10:49 +0400 > >>> Boris Samorodov wrote: > >>>=20 > >>>> 17.08.2013 13:36, O. Hartmann =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>>>=20 > >>>>> I can reproduceable truncate the link in /etc/ to be NIL by > >>>>> typing simply "reboot" when rebooting the box > >>>>=20 > >>>> Does it make any difference if you use "shutdown -r" instead? > >>>>=20 > >>>=20 > >>> Yes, when using "shutdown -r" the link isn't broken and the system > >>> reboots and operates as expected. Only if I use the "quick and > >>> dirty way" via "reboot" or after a crash when service named ahs > >>> already been started the link is dead. If a crahs occurs BEFORE > >>> service named has been started, the recovery is also operable - > >>> this is my observation. > >>=20 > >> Does "reboot" show the same problem If the system has been running > >> for a while (at least 15 minutes or so)? > >=20 > > Yes, of course. >=20 > That's not good. Addendum: The reported problem doesn't show up every "reboot". I had to do it now for three times before the broken link showed up (always waiting T > 15 min). I have also to add, that the filesystem in question resides on a SSD (Samsung 830 with 120 GB). >=20 > After 15 minutes, the link contents should have been written > all the way to disk, even on an idle system. It sounds like the > sync process might not be running except at system shutdown. >=20 > What filesystem are you using? ZFS? UFS/SU? SU+J? >=20 > Kernel version? >=20 > Can you reproduce this without named? That is: > * create a symlink,=20 > * wait 15 minutes, > * "reboot" > Is the symlink broken? >=20 > Tim >=20 > _______________________________________________ > 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" --Sig_/y0V=HmOQb.K14DMEdkss0+b Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSEOcAAAoJEOgBcD7A/5N8Kr4H/jMoogDFrW4B772Lw+ffW/ta iHOIpZOfecxBv2cfsFH+OXfXueTuAwD4VqnCWAZMuH3m5jdLJWN7Am53Uuu61wkF 51buyHlFjA8S8o+bRmsQ8n1U/vyfhmQ1ClPr8WHbabeCSw4xJv6Sg9grugU201wV uIkxr6VjdgMPYCKksW00qSPVf5YpTeFgZ+tysibf7losHVmfvEV/VWOUEEOCUofr thPEFnD1lFUZ4Z6/Gl6TLNavNIMbYnsKYmTOltOMTbJBX/Idlot3c6MGXWIpNR38 NSjbQb7kjEwRIFpu4UcdR9szjpLV40YAa3XBSd8XmLdYQQgfNNBeJDE7h2eNYps= =6eXC -----END PGP SIGNATURE----- --Sig_/y0V=HmOQb.K14DMEdkss0+b-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 18 18:40: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0730B20E for ; Sun, 18 Aug 2013 18:40:34 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7EBAC2596 for ; Sun, 18 Aug 2013 18:40:33 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id o7so2475040lbv.17 for ; Sun, 18 Aug 2013 11:40:31 -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=KOneafVClo/cKc0g+x5gMODV3ZFs2808/FchzliQPJg=; b=gUYNHOzAa70nBTDjgiLtB4uYSrB9u8kdMIKTE0b4WJA53JwkMg0ox1R1xVWbJVaRQw 1DzRkmQYbD7tge22SyEtXdrDsu9AEppQ8U0f6viY2Rhxx2QCAhwOHPt4SUHNAbX9m3VW BuUYnGn0tN7+QeCcyN4uz6IqGQPmQgPZGtSZALkEV8idDZPQh5PyNoSDDp6vEDiorq49 /DtDrH3RIfl5zRxS05kZLUhY5NAUjW2+LBu9UZngFT/ulY4DUHz3+P8aphRuDLdPqAZ1 EHSNFlX6AImeaVTnXDjf3iGzLBFI5yG81u//ubK+8V/1WDDUjBaNhDqW/f+Ml2TzD7y5 YTIg== X-Received: by 10.152.26.72 with SMTP id j8mr8580971lag.19.1376851231302; Sun, 18 Aug 2013 11:40:31 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([91.198.175.1]) by mx.google.com with ESMTPSA id ua4sm3044107lbb.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Aug 2013 11:40:30 -0700 (PDT) Sender: Alexander Motin Message-ID: <5211151B.2070006@FreeBSD.org> Date: Sun, 18 Aug 2013 21:40:27 +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: Hans Petter Selasky Subject: Re: USB no proper work References: <520E8602.5050408@gmail.com> <520E8842.4020609@bitfrost.no> <520E8DE1.1090609@gmail.com> <520F16B6.1070106@bitfrost.no> <520FA7C3.2060708@FreeBSD.org> <520FF137.1020709@gmail.com> <520FF37D.6050002@bitfrost.no> In-Reply-To: <520FF37D.6050002@bitfrost.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexander Panyushkin , 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, 18 Aug 2013 18:40:34 -0000 On 18.08.2013 01:04, Hans Petter Selasky wrote: > On 08/17/13 23:55, Alexander Panyushkin wrote: >> 17.08.2013 19:41, Alexander Motin пишет: >>> On 17.08.2013 09:22, Hans Petter Selasky wrote: > >> >> On USB device FAT-32 file system. When I removed flash drive, the file >> system has been unmounted. > > Hi, > > The problem might be in the GELI module then. Did you test that Alexander ? > > Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Device gpt/swap0.eli created. > Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Encryption: AES-XTS 128 > Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Crypto: software That seems like encrypted swap. It is probably not on the flash drive. Swap disconnect is a known problem since system may loose part of its kernel address space that may cause immediate panic if we handle disconnect too pedantic. But any way this I think is not our case. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Aug 18 19:05: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4AEBF717 for ; Sun, 18 Aug 2013 19:05:00 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward10l.mail.yandex.net (forward10l.mail.yandex.net [IPv6:2a02:6b8:0:1819::a]) by mx1.freebsd.org (Postfix) with ESMTP id 0F7472694 for ; Sun, 18 Aug 2013 19:05:00 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward10l.mail.yandex.net (Yandex) with ESMTP id 1BC27BA0C8F for ; Sun, 18 Aug 2013 23:04:58 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id D106C1B415A7 for ; Sun, 18 Aug 2013 23:04:57 +0400 (MSK) Received: from 93.91.10.81.tel.ru (93.91.10.81.tel.ru [93.91.10.81]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id FP2Fr35HXy-4vsKCOcL; Sun, 18 Aug 2013 23:04:57 +0400 Message-ID: <52111AD9.9030001@passap.ru> Date: Sun, 18 Aug 2013 23:04:57 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: bsdtar/libarchive change behaviour 9->10 Content-Type: text/plain; charset=UTF-8 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, 18 Aug 2013 19:05:00 -0000 Hi All, there are two systems which produce different results: ----- % uname -a FreeBSD int.wart.ru 9.2-BETA2 FreeBSD 9.2-BETA2 #19 r253968: Tue Aug 6 04:16:05 SAMT 2013 bsam@int.wart.ru:/usr/obj/usr/src/sys/INT i386 % tar --version bsdtar 2.8.5 - libarchive 2.8.5 % tar -tf /usr/ports/distfiles/Catalyst-Plugin-Prototype-1.33.tar.gz | grep Plugin/ Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/ Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/._Prototype.pm Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/Prototype.pm ----- % uname -a FreeBSD srv.bb.tel.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r253953: Mon Aug 5 16:16:42 SAMT 2013 bsam@srv.bb.tel.ru:/usr/obj/usr/src/sys/BB64X amd64 % tar --version bsdtar 3.1.2 - libarchive 3.1.2 % tar -tf /usr/ports/distfiles/Catalyst-Plugin-Prototype-1.33.tar.gz | grep Plugin/ Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/ Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/Prototype.pm ----- I.e. the CURRENT system does not honor the presence of "._*" file. The file seems to be a MAC file and anyway get deletted before installation. So, the question is: is it a regression/bug/new feature? Thanks! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Aug 18 19:39: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 48F7894A for ; Sun, 18 Aug 2013 19:39:39 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2633028A4 for ; Sun, 18 Aug 2013 19:39:38 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r7IJdbiW059107; Sun, 18 Aug 2013 19:39:37 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id wjjc7jpvrfkbww3hcmznvhszr2; Sun, 18 Aug 2013 19:39:37 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: bsdtar/libarchive change behaviour 9->10 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <52111AD9.9030001@passap.ru> Date: Sun, 18 Aug 2013 12:39:37 -0700 Content-Transfer-Encoding: 7bit Message-Id: <164B2B31-D142-4F0A-8FD1-EE112906A470@kientzle.com> References: <52111AD9.9030001@passap.ru> To: Boris Samorodov 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: Sun, 18 Aug 2013 19:39:39 -0000 On Aug 18, 2013, at 12:04 PM, Boris Samorodov wrote: > Hi All, > > there are two systems which produce different results: > ----- > % uname -a > FreeBSD int.wart.ru 9.2-BETA2 FreeBSD 9.2-BETA2 #19 r253968: Tue Aug 6 > 04:16:05 SAMT 2013 bsam@int.wart.ru:/usr/obj/usr/src/sys/INT i386 > > % tar --version > bsdtar 2.8.5 - libarchive 2.8.5 > > % tar -tf /usr/ports/distfiles/Catalyst-Plugin-Prototype-1.33.tar.gz | > grep Plugin/ > Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/ > Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/._Prototype.pm > Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/Prototype.pm > ----- > % uname -a > FreeBSD srv.bb.tel.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r253953: Mon > Aug 5 16:16:42 SAMT 2013 > bsam@srv.bb.tel.ru:/usr/obj/usr/src/sys/BB64X amd64 > > % tar --version > bsdtar 3.1.2 - libarchive 3.1.2 > > % tar -tf /usr/ports/distfiles/Catalyst-Plugin-Prototype-1.33.tar.gz | > grep Plugin/ > Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/ > Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/Prototype.pm > ----- > > I.e. the CURRENT system does not honor the presence of "._*" file. > The file seems to be a MAC file and anyway get deletted before > installation. > > So, the question is: is it a regression/bug/new feature? Libarchive 3 does handle ._* files differently than libarchive 2. In libarchive 2.x those files were treated as normal files and bsdtar then had special code to process them as Mac extensions. Libarchive 3.x can treat them as extended metadata. As a result, bsdtar doesn't see them at all (except as additional metadata which can't be restored on FreeBSD). If you are using libarchive directly, you can ask it to not interpret those files as metadata. Bsdtar does request such handling from libarchive. Tim From owner-freebsd-current@FreeBSD.ORG Sun Aug 18 23:53: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 029B16BF for ; Sun, 18 Aug 2013 23:53:03 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBA5D243E for ; Sun, 18 Aug 2013 23:53:03 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id r10so4382560pdi.28 for ; Sun, 18 Aug 2013 16:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q60d2SB4qPspwxN+s6BgKrR/3pBVO+8M5fZvXDYLkaw=; b=IUpYpKtvuUPgCW1CTvwx40H2uNVjRFCtqdvgr8S4iD5C509tt8gwQnSNRNE10HgRw9 n9p5TwBeIQfLmAJzQqIYG8WHVsM7G2U3Hayyr4FJ9bge4FBNO8bF3L4ZmPJzpphw5ppM Gdz4ZWrfm6kG/d1WqOp75IyMRLQgUqfgdXZl0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=q60d2SB4qPspwxN+s6BgKrR/3pBVO+8M5fZvXDYLkaw=; b=VSrHnVVbV8Ed9Z+iA6JHBw6NpEkam3S/0gCWU7jpZpohm2WmtvlA4v25UF+57DALdR /Aj+b0c9hFSoleKRhL0ULPJHQ5u7TWeRLh8LAVV/oMMjDT3MUreqkAfT08bRYmOrJXMJ iZSM9f/URxllaAUaqiDN/RnygwdXKVoEmrbm5bTo3Pp+td5rycSvyu+FEy/CzhsnJ/eB r9GypPcAP1hAo5MTS8sjQj6KrVQN8qx2C9vuerqmxMkm6aizSHZPokgZCi9iRc4DkwVf aG55tLKuASes9VyYGVXgoMnJhv1kgT7j8ZxIlFvGAQOlPjkFJbgsvJClySOMWMlMzE8y 7IwQ== X-Gm-Message-State: ALoCoQkUVKrqBRGyEbRG7JNkK+GukoNkWqMaqnXghNyUuQCfeEF+j1QV4Jai8AUXg1/jpTTlRguC X-Received: by 10.68.235.102 with SMTP id ul6mr10238290pbc.14.1376869983334; Sun, 18 Aug 2013 16:53:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.6.3 with HTTP; Sun, 18 Aug 2013 16:52:33 -0700 (PDT) In-Reply-To: <164B2B31-D142-4F0A-8FD1-EE112906A470@kientzle.com> References: <52111AD9.9030001@passap.ru> <164B2B31-D142-4F0A-8FD1-EE112906A470@kientzle.com> From: Eitan Adler Date: Mon, 19 Aug 2013 01:52:33 +0200 Message-ID: Subject: Re: bsdtar/libarchive change behaviour 9->10 To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Current , Boris Samorodov 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, 18 Aug 2013 23:53:04 -0000 On Sun, Aug 18, 2013 at 9:39 PM, Tim Kientzle wrote: > Libarchive 3.x can treat them as extended metadata. > As a result, bsdtar doesn't see them at all (except as > additional metadata which can't be restored on FreeBSD). Are there other such examples? > If you are using libarchive directly, you can ask it > to not interpret those files as metadata. Bsdtar does > request such handling from libarchive. Perhaps this could be exposed to the UI as a env var or a flag? -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Mon Aug 19 16:57:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A45F867B for ; Mon, 19 Aug 2013 16:57:55 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 73BC32A7E for ; Mon, 19 Aug 2013 16:57:55 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7JGvml0054295 for ; Mon, 19 Aug 2013 09:57:49 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <52124E8C.5020603@rawbw.com> Date: Mon, 19 Aug 2013 09:57:48 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: current@freebsd.org Subject: Witness message about lock order reversal on 10 (head) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 19 Aug 2013 16:57:55 -0000 I got these messages on 10 head, rev.254235, during 'filesystem full' condition. Yuri ===== log ===== lock order reversal: 1st 0xffffff80f7432470 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3054 2nd 0xfffffe00075b5600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8000284440 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff80002844f0 witness_checkorder() at witness_checkorder+0xd4f/frame 0xffffff8000284580 _sx_xlock() at _sx_xlock+0x75/frame 0xffffff80002845c0 ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xffffff8000284600 ufs_direnter() at ufs_direnter+0x688/frame 0xffffff80002846c0 ufs_mkdir() at ufs_mkdir+0x863/frame 0xffffff80002848c0 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf0/frame 0xffffff80002848f0 kern_mkdirat() at kern_mkdirat+0x21a/frame 0xffffff8000284ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8000284bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8000284bf0 --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x800931e9a, rsp = 0x7fffffffd798, rbp = 0x7fffffffdc70 --- lock order reversal: 1st 0xfffffe0007633840 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1184 2nd 0xfffffe0007a45240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4346 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff800031f6b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff800031f760 witness_checkorder() at witness_checkorder+0xd4f/frame 0xffffff800031f7f0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xffffff800031f920 ffs_lock() at ffs_lock+0x84/frame 0xffffff800031f970 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xffffff800031f9a0 _vn_lock() at _vn_lock+0xab/frame 0xffffff800031fa10 knlist_remove_kq() at knlist_remove_kq+0x82/frame 0xffffff800031fa40 knote_fdclose() at knote_fdclose+0xc8/frame 0xffffff800031fa90 closefp() at closefp+0x64/frame 0xffffff800031fae0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff800031fbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff800031fbf0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80164537a, rsp = 0x7fffff7fbf08, rbp = 0x7fffff7fbf20 --- pid 983 (sendmail), uid 25 inumber 473785 on /: filesystem full pid 1101 (dd), uid 2 inumber 426338 on /: filesystem full lock order reversal: 1st 0xfffffe0007cbc240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 2nd 0xffffff80f7894338 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xfffffe003b531418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8000378e60 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8000378f10 witness_checkorder() at witness_checkorder+0xd4f/frame 0xffffff8000378fa0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xffffff80003790d0 ffs_lock() at ffs_lock+0x84/frame 0xffffff8000379120 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xffffff8000379150 _vn_lock() at _vn_lock+0xab/frame 0xffffff80003791c0 vget() at vget+0x70/frame 0xffffff8000379210 vfs_hash_get() at vfs_hash_get+0xf5/frame 0xffffff8000379260 ffs_vgetf() at ffs_vgetf+0x41/frame 0xffffff80003792f0 softdep_sync_buf() at softdep_sync_buf+0x2e4/frame 0xffffff80003793a0 ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xffffff8000379420 ffs_truncate() at ffs_truncate+0x5ca/frame 0xffffff8000379600 ufs_direnter() at ufs_direnter+0x891/frame 0xffffff80003796c0 ufs_mkdir() at ufs_mkdir+0x863/frame 0xffffff80003798c0 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf0/frame 0xffffff80003798f0 kern_mkdirat() at kern_mkdirat+0x21a/frame 0xffffff8000379ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8000379bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8000379bf0 --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x800931e9a, rsp = 0x7fffffffd898, rbp = 0x7fffffffd970 --- From owner-freebsd-current@FreeBSD.ORG Mon Aug 19 18:39: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 33C9DA3C for ; Mon, 19 Aug 2013 18:39:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE9442103 for ; Mon, 19 Aug 2013 18:39:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 57891B91A; Mon, 19 Aug 2013 14:39:31 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: /etc/namedb->@ referrs to NIL after crash or typing "reboot" (not shutdown -r) Date: Mon, 19 Aug 2013 13:58:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130817113636.21346cd2@thor.walstatt.dyndns.org> <20130817193517.2bf01dfe@thor.walstatt.dyndns.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201308191358.40555.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 19 Aug 2013 14:39:31 -0400 (EDT) Cc: "O. Hartmann" , Boris Samorodov 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, 19 Aug 2013 18:39:34 -0000 On Saturday, August 17, 2013 1:42:07 pm Tim Kientzle wrote: >=20 > On Aug 17, 2013, at 10:35 AM, O. Hartmann wrote: >=20 > > On Sat, 17 Aug 2013 21:10:49 +0400 > > Boris Samorodov wrote: > >=20 > >> 17.08.2013 13:36, O. Hartmann =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>=20 > >>> I can reproduceable truncate the link in /etc/ to be NIL by typing > >>> simply "reboot" when rebooting the box > >>=20 > >> Does it make any difference if you use "shutdown -r" instead? > >>=20 > >=20 > > Yes, when using "shutdown -r" the link isn't broken and the system > > reboots and operates as expected. Only if I use the "quick and dirty > > way" via "reboot" or after a crash when service named ahs already been > > started the link is dead. If a crahs occurs BEFORE service named has > > been started, the recovery is also operable - this is my observation. >=20 > Does "reboot" show the same problem If the system has been running > for a while (at least 15 minutes or so)? >=20 > Your broken link sounds like the expected behavior when you > do a dirty reboot shortly after the link has been created (before > the link contents have been written all the way to disk). "reboot" shouldn't be a dirty reboot in this sense though. The disks shoul= d=20 still be synced if you do a reboot. Only a panic or power failure should g= ive=20 you unsynced disks. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Aug 19 19:03:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B9D7937C for ; Mon, 19 Aug 2013 19:03:32 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (borg.macktronics.com [209.181.253.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 930612259 for ; Mon, 19 Aug 2013 19:03:32 +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 E6DDF6A7; Mon, 19 Aug 2013 13:57:14 -0500 (CDT) Date: Mon, 19 Aug 2013 13:57:13 -0500 (CDT) From: Dan Mack To: Yuri Subject: Re: Witness message about lock order reversal on 10 (head) In-Reply-To: <52124E8C.5020603@rawbw.com> Message-ID: References: <52124E8C.5020603@rawbw.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 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, 19 Aug 2013 19:03:32 -0000 It might be the same false positive I saw a couple weeks ago ... Davide said to me: | The LOR is a false positive. | See the comment in sys/ufs/ufs/ufs_dirhash.c | Also, switching motherboards is not related to this in any way. You'll | eventually hit that LOR report, unless you disabled WITNESS. Thanks, -- Davide On Mon, 19 Aug 2013, Yuri wrote: > I got these messages on 10 head, rev.254235, during 'filesystem full' > condition. > > Yuri > > > ===== log ===== > lock order reversal: > 1st 0xffffff80f7432470 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3054 > 2nd 0xfffffe00075b5600 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xffffff8000284440 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff80002844f0 > witness_checkorder() at witness_checkorder+0xd4f/frame 0xffffff8000284580 > _sx_xlock() at _sx_xlock+0x75/frame 0xffffff80002845c0 > ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xffffff8000284600 > ufs_direnter() at ufs_direnter+0x688/frame 0xffffff80002846c0 > ufs_mkdir() at ufs_mkdir+0x863/frame 0xffffff80002848c0 > VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf0/frame 0xffffff80002848f0 > kern_mkdirat() at kern_mkdirat+0x21a/frame 0xffffff8000284ae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8000284bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8000284bf0 > --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x800931e9a, rsp = > 0x7fffffffd798, rbp = 0x7fffffffdc70 --- > lock order reversal: > 1st 0xfffffe0007633840 filedesc structure (filedesc structure) @ > /usr/src/sys/kern/kern_descrip.c:1184 > 2nd 0xfffffe0007a45240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4346 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xffffff800031f6b0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff800031f760 > witness_checkorder() at witness_checkorder+0xd4f/frame 0xffffff800031f7f0 > __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xffffff800031f920 > ffs_lock() at ffs_lock+0x84/frame 0xffffff800031f970 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xffffff800031f9a0 > _vn_lock() at _vn_lock+0xab/frame 0xffffff800031fa10 > knlist_remove_kq() at knlist_remove_kq+0x82/frame 0xffffff800031fa40 > knote_fdclose() at knote_fdclose+0xc8/frame 0xffffff800031fa90 > closefp() at closefp+0x64/frame 0xffffff800031fae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xffffff800031fbf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff800031fbf0 > --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80164537a, rsp = > 0x7fffff7fbf08, rbp = 0x7fffff7fbf20 --- > pid 983 (sendmail), uid 25 inumber 473785 on /: filesystem full > pid 1101 (dd), uid 2 inumber 426338 on /: filesystem full > lock order reversal: > 1st 0xfffffe0007cbc240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 > 2nd 0xffffff80f7894338 bufwait (bufwait) @ > /usr/src/sys/ufs/ffs/ffs_vnops.c:262 > 3rd 0xfffffe003b531418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xffffff8000378e60 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8000378f10 > witness_checkorder() at witness_checkorder+0xd4f/frame 0xffffff8000378fa0 > __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xffffff80003790d0 > ffs_lock() at ffs_lock+0x84/frame 0xffffff8000379120 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xffffff8000379150 > _vn_lock() at _vn_lock+0xab/frame 0xffffff80003791c0 > vget() at vget+0x70/frame 0xffffff8000379210 > vfs_hash_get() at vfs_hash_get+0xf5/frame 0xffffff8000379260 > ffs_vgetf() at ffs_vgetf+0x41/frame 0xffffff80003792f0 > softdep_sync_buf() at softdep_sync_buf+0x2e4/frame 0xffffff80003793a0 > ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xffffff8000379420 > ffs_truncate() at ffs_truncate+0x5ca/frame 0xffffff8000379600 > ufs_direnter() at ufs_direnter+0x891/frame 0xffffff80003796c0 > ufs_mkdir() at ufs_mkdir+0x863/frame 0xffffff80003798c0 > VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf0/frame 0xffffff80003798f0 > kern_mkdirat() at kern_mkdirat+0x21a/frame 0xffffff8000379ae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8000379bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8000379bf0 > --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x800931e9a, rsp = > 0x7fffffffd898, rbp = 0x7fffffffd970 --- > > _______________________________________________ > 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" > dan -- Dan Mack From owner-freebsd-current@FreeBSD.ORG Mon Aug 19 19:54:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4CD782B1; Mon, 19 Aug 2013 19:54:12 +0000 (UTC) (envelope-from vsityz@gmail.com) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC7262510; Mon, 19 Aug 2013 19:54:11 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id d49so2355609eek.34 for ; Mon, 19 Aug 2013 12:54:10 -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:content-type:content-transfer-encoding; bh=jlVddHd5QmAlMdkBESLT10CoVy/oCyl0GDUKxEioh/8=; b=VN67Z0NfWQmbMCN5cG2Pq7hGok05NiXSeKGHQnFj9/IGh2OngeLp8/FFlz+YVh0MH8 nbtqgeP9DjGyhgS/P2V2UQIjfI4l3onaWOPtDDgT2cL0NMwY4uwPZxIRcmJTtSNzhyCV 0iEu8oqyc9stigxhrMQljLtCET4iXHTosWSD7NTlpTt5eaDy9jmf9aK7ebQdhfpIxWrp vf6zTVJfb8kArrzAV12doazVjR7CKuQQCFAXxATPZU4BB3XmJRm4vV/iod2Teq8El1jg CxwTQCwi9EUvXQGbbJWq2j4zaLDlWuA/XbZSvwuwbe7t2MZg0XodoaKymCc6yetIW9ZQ vYdQ== X-Received: by 10.14.5.78 with SMTP id 54mr6140631eek.55.1376942049965; Mon, 19 Aug 2013 12:54:09 -0700 (PDT) Received: from scorpion.kiev.ua ([46.247.184.240]) by mx.google.com with ESMTPSA id i1sm5653589eeg.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 12:54:08 -0700 (PDT) Message-ID: <521277DB.4010200@gmail.com> Date: Mon, 19 Aug 2013 22:54:03 +0300 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130811 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: USB no proper work References: <520E8602.5050408@gmail.com> <520E8842.4020609@bitfrost.no> <520E8DE1.1090609@gmail.com> <520F16B6.1070106@bitfrost.no> <520FA7C3.2060708@FreeBSD.org> <520FF137.1020709@gmail.com> <520FF37D.6050002@bitfrost.no> In-Reply-To: <520FF37D.6050002@bitfrost.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexander Motin , 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, 19 Aug 2013 19:54:12 -0000 18.08.2013 01:04, Hans Petter Selasky пишет: > On 08/17/13 23:55, Alexander Panyushkin wrote: >> 17.08.2013 19:41, Alexander Motin пишет: >>> On 17.08.2013 09:22, Hans Petter Selasky wrote: > >> >> On USB device FAT-32 file system. When I removed flash drive, the file >> system has been unmounted. > > Hi, > > The problem might be in the GELI module then. Did you test that > Alexander ? > > Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Device gpt/swap0.eli created. > Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Encryption: AES-XTS 128 > Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Crypto: software > > Hint: You can set the following knob to disable the USB waiting at > reboot. > > hw.usb.no_shutdown_wait=1 > If set hw.usb.no_shutdown_wait = 1 Reboot successful, but if detach and attach again, USB device not detecting. > That seems like encrypted swap. It is probably not on the flash drive. > Swap disconnect is a known problem since system may loose part of its > kernel address space that may cause immediate panic if we handle > disconnect too pedantic. But any way this I think is not our case. unmount the swap did not happiness From owner-freebsd-current@FreeBSD.ORG Mon Aug 19 19:56: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3DBD2430; Mon, 19 Aug 2013 19:56:37 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id EDEEF2534; Mon, 19 Aug 2013 19:56:36 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id D6D427A3E4; Mon, 19 Aug 2013 21:56:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 6F2D18F36AA; Mon, 19 Aug 2013 21:56:45 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTO9EYGlaN1t; Mon, 19 Aug 2013 21:56:44 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id C77DA8F36A6; Mon, 19 Aug 2013 21:56:44 +0200 (CEST) Message-ID: <521278BC.5010009@bitfrost.no> Date: Mon, 19 Aug 2013 21:57:48 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alexander Panyushkin Subject: Re: USB no proper work References: <520E8602.5050408@gmail.com> <520E8842.4020609@bitfrost.no> <520E8DE1.1090609@gmail.com> <520F16B6.1070106@bitfrost.no> <520FA7C3.2060708@FreeBSD.org> <520FF137.1020709@gmail.com> <520FF37D.6050002@bitfrost.no> <521277DB.4010200@gmail.com> In-Reply-To: <521277DB.4010200@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexander Motin , 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, 19 Aug 2013 19:56:37 -0000 On 08/19/13 21:54, Alexander Panyushkin wrote: > 18.08.2013 01:04, Hans Petter Selasky пишет: >> On 08/17/13 23:55, Alexander Panyushkin wrote: >>> 17.08.2013 19:41, Alexander Motin пишет: >>>> On 17.08.2013 09:22, Hans Petter Selasky wrote: >> >>> >>> On USB device FAT-32 file system. When I removed flash drive, the file >>> system has been unmounted. >> >> Hi, >> >> The problem might be in the GELI module then. Did you test that >> Alexander ? >> >> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Device gpt/swap0.eli created. >> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Encryption: AES-XTS 128 >> Aug 16 23:23:43 scorpion kernel: GEOM_ELI: Crypto: software >> >> Hint: You can set the following knob to disable the USB waiting at >> reboot. >> >> hw.usb.no_shutdown_wait=1 >> > If set hw.usb.no_shutdown_wait = 1 > Reboot successful, but if detach and attach again, USB device not > detecting. This test is an indication that the USB stack is waiting for the CAM layer to finish detaching its clients. Maybe you can turn on cam debugging to figure out who is leaking a ref. Alexander Motin knows how. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Aug 19 19:33: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8CAFBA8C for ; Mon, 19 Aug 2013 19:33:05 +0000 (UTC) (envelope-from vitja.makarov@gmail.com) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5354323FA for ; Mon, 19 Aug 2013 19:33:05 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id cy12so3269556veb.18 for ; Mon, 19 Aug 2013 12:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YXFZD6y6VVZmCMst3SQe7UVZwmmrxkRpritVF4UUvA4=; b=qZl0VqM+RwobDwxEccg81oBFpEN321bUhbpN6dbzxVgbWU6F1flEtuJuog5fpyQrSX HlhNnC6EZaaf8nK8v+Yw9DetwSgVmkZg8it0SvwsLBLbZCQzv2NJ4AchUrWg+qBRbAAY jArP2Q9NbTi5Z5e5ofJo4jrRm7Q5cMCqzff9JeZOlfgy0VrvpSp2GrCQ1B7OQl5F27TI rRtkePcymu76IjHSPR2f/t6lSYnJlfeYuACXnSx3Ua61RlEs0R2EqgRloAptNrJLYsXU hksjyIyX361g+R0tJKIRiiIEejEElhKxvMtN4rP/2xY4xQFcElanEvNogh4S2HhF096p ItcA== MIME-Version: 1.0 X-Received: by 10.221.40.10 with SMTP id to10mr3980293vcb.22.1376940784437; Mon, 19 Aug 2013 12:33:04 -0700 (PDT) Received: by 10.52.175.198 with HTTP; Mon, 19 Aug 2013 12:33:04 -0700 (PDT) Date: Mon, 19 Aug 2013 23:33:04 +0400 Message-ID: Subject: Question about socket timeouts From: Vitja Makarov To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 20 Aug 2013 02:02:46 +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, 19 Aug 2013 19:33:05 -0000 Hi! Recently I was playing with small socket timeouts. setsockopt(2) SO_RCVTIMEO and found a problem with it: if timeout is small enough read(2) may return before timeout is actually expired. I was unable to reproduce this on linux box. I found that kernel uses a timer with 1/HZ precision so it converts time in microseconds to ticks that's ok linux does it as well. The problem is in details: freebsd uses floor() approach while linux uses ceil(): from FreeBSD's sys/kern/uipc_socket.c: val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; if (val == 0 && tv.tv_usec != 0) val = 1; /* at least one tick if tv > 0 */ from Linux's net/core/sock.c: *timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(1000000/HZ-1))/(1000000/HZ); So, for instance, we have a freebsd system running with kern.hz set 100 and set receive timeout to 25ms that is converted to 2 ticks which is 20ms. In my test program read(2) returns with EAGAIN set in 0.019ms. So the question is: is that a problem or not? -- vitja. From owner-freebsd-current@FreeBSD.ORG Tue Aug 20 02:49: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 97E204A7 for ; Tue, 20 Aug 2013 02:49:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E0E72888 for ; Tue, 20 Aug 2013 02:49:06 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id j17so3815137wiw.1 for ; Mon, 19 Aug 2013 19:49:04 -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:message-id:subject :from:to:cc:content-type; bh=tenO2eYhvoVqVxbsSGBtEPeGIFRivB85+7BDq7AZtUI=; b=LpN0PHkjnIWRdmfnmpoAn02wI5Ak8sqPo3ShAoIbaWXugQGUtxcBjqmuPbqHhhfVry TtrWmo9Cx1X6ijmAAg/fADn49TMBYaoetgBZ8zc3UBWgYYvTywN9qO3fiL1q4pk71jrh FhYiVwOOfejCyk5WeStY0kEsiaIXZbEROB9Afkg1YGSef+pbjX6WHlJc6E6HFY7Wmc9r uvOaEAsCcmkPHat4kBaqSapNaRwsHUDIyjUEEX1PTpN1Y9OGDLDFWYRUsLGq+N9KilN6 mMYdoqUV8ciLSiS4UhfE/MXEg5Mfem3T0iZBTKuiy0aCwdnHpHIvSzQk01cIBX7SA3Mi aQaQ== MIME-Version: 1.0 X-Received: by 10.194.250.6 with SMTP id yy6mr11153015wjc.13.1376966944336; Mon, 19 Aug 2013 19:49:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Mon, 19 Aug 2013 19:49:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Aug 2013 19:49:04 -0700 X-Google-Sender-Auth: szaBWge10QLrLmRv44ktBvurh2c Message-ID: Subject: Re: Question about socket timeouts From: Adrian Chadd To: Vitja Makarov 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, 20 Aug 2013 02:49:06 -0000 Yes! Please file a PR! -adrian On 19 August 2013 12:33, Vitja Makarov wrote: > Hi! > > Recently I was playing with small socket timeouts. setsockopt(2) > SO_RCVTIMEO and found a problem with it: if timeout is small enough > read(2) may return before timeout is actually expired. > > I was unable to reproduce this on linux box. > > I found that kernel uses a timer with 1/HZ precision so it converts > time in microseconds to ticks that's ok linux does it as well. The > problem is in details: freebsd uses floor() approach while linux uses > ceil(): > > from FreeBSD's sys/kern/uipc_socket.c: > val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; > if (val == 0 && tv.tv_usec != 0) > val = 1; /* at least one tick if tv > 0 */ > > from Linux's net/core/sock.c: > *timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(1000000/HZ-1))/(1000000/HZ); > > So, for instance, we have a freebsd system running with kern.hz set > 100 and set receive timeout to 25ms that is converted to 2 ticks which > is 20ms. In my test program read(2) returns with EAGAIN set in > 0.019ms. > > So the question is: is that a problem or not? > > -- > vitja. > _______________________________________________ > 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 Aug 20 03:13:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A0AC3C24; Tue, 20 Aug 2013 03:13:09 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 644C82A54; Tue, 20 Aug 2013 03:13:08 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r7K3D2Dc039343; Mon, 19 Aug 2013 23:13:02 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.9]); Mon, 19 Aug 2013 23:13:02 -0400 (EDT) Date: Mon, 19 Aug 2013 23:13:02 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Adrian Chadd Subject: Re: Question about socket timeouts In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Vitja Makarov , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 03:13:09 -0000 On Mon, 19 Aug 2013, Adrian Chadd wrote: > Yes! Please file a PR! This sorta implies that both are acceptable (although, the Linux behavior seems more desirable). http://austingroupbugs.net/view.php?id=369 > On 19 August 2013 12:33, Vitja Makarov wrote: > >> Hi! >> >> Recently I was playing with small socket timeouts. setsockopt(2) >> SO_RCVTIMEO and found a problem with it: if timeout is small enough >> read(2) may return before timeout is actually expired. >> >> I was unable to reproduce this on linux box. >> >> I found that kernel uses a timer with 1/HZ precision so it converts >> time in microseconds to ticks that's ok linux does it as well. The >> problem is in details: freebsd uses floor() approach while linux uses >> ceil(): >> >> from FreeBSD's sys/kern/uipc_socket.c: >> val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; >> if (val == 0 && tv.tv_usec != 0) >> val = 1; /* at least one tick if tv > 0 */ >> >> from Linux's net/core/sock.c: >> *timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(1000000/HZ-1))/(1000000/HZ); >> >> So, for instance, we have a freebsd system running with kern.hz set >> 100 and set receive timeout to 25ms that is converted to 2 ticks which >> is 20ms. In my test program read(2) returns with EAGAIN set in >> 0.019ms. >> >> So the question is: is that a problem or not? >> >> -- >> vitja. -- DE From owner-freebsd-current@FreeBSD.ORG Tue Aug 20 06:28:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4708C72 for ; Tue, 20 Aug 2013 06:28:27 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CAF325BF for ; Tue, 20 Aug 2013 06:28:26 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id E8D26C00A6; Tue, 20 Aug 2013 06:28:18 +0000 (UTC) Date: Tue, 20 Aug 2013 08:28:18 +0200 From: Jeremie Le Hen To: Eitan Adler Subject: Re: bsdtar/libarchive change behaviour 9->10 Message-ID: <20130820062818.GB24767@caravan.chchile.org> Mail-Followup-To: Eitan Adler , Tim Kientzle , freebsd-current Current , Boris Samorodov References: <52111AD9.9030001@passap.ru> <164B2B31-D142-4F0A-8FD1-EE112906A470@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Current , Boris Samorodov 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, 20 Aug 2013 06:28:27 -0000 On Mon, Aug 19, 2013 at 01:52:33AM +0200, Eitan Adler wrote: > On Sun, Aug 18, 2013 at 9:39 PM, Tim Kientzle wrote: > > Libarchive 3.x can treat them as extended metadata. > > As a result, bsdtar doesn't see them at all (except as > > additional metadata which can't be restored on FreeBSD). This sounds like a POLA breakage. The rule is maybe different for softwares in contrib/. > > If you are using libarchive directly, you can ask it > > to not interpret those files as metadata. Bsdtar does > > request such handling from libarchive. > > Perhaps this could be exposed to the UI as a env var or a flag? +1 for this. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Tue Aug 20 16:04:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6AFFE16B for ; Tue, 20 Aug 2013 16:04:49 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFC7F2A14 for ; Tue, 20 Aug 2013 16:04:48 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.7/8.14.6) with ESMTP id r7KG4imG022038 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 20 Aug 2013 17:04:46 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <5213939C.8050609@unsane.co.uk> Date: Tue, 20 Aug 2013 17:04:44 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "freebsd-current@freebsd.org" Subject: Panic/Freeze with IPSEC on r254532 X-Enigmail-Version: 1.5.2 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: Tue, 20 Aug 2013 16:04:49 -0000 I thought I'd have a play with ipsec since its been a while since I last set it up, and was setting up a transport mode connection between my poudiere/repo server (the -curent server) and another box (8.2-RELEASE) 3 pings later the -CURRENT box froze, its zfs on root so no kernel dump I'm afraid, it does have an ipmi so I repeated with a serial over lan connection to test but got nothing it just froze. Any suggestions? The only unusual thing about this machine is that i am running a bhyve vm on it. not sure how relevant that is. Log output 1st occurance Aug 20 13:24:51 bsdpkgbuild kernel: Kernel page fault with the following non-sleepable locks held: Aug 20 13:24:51 bsdpkgbuild kernel: shared rw ipsec request (ipsec request) r = 0 (0xfffff80020fe2f60) locked @ /usr/src/sys/netipsec/ipsec_output.c:436 Aug 20 13:24:51 bsdpkgbuild kernel: shared rw rawinp (rawinp) r = 0 (0xfffff800587afda8) locked @ /usr/src/sys/netinet/raw_ip.c:446 Aug 20 13:24:51 bsdpkgbuild kernel: KDB: stack backtrace: Aug 20 13:24:51 bsdpkgbuild kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0238af91e0 Aug 20 13:24:51 bsdpkgbuild kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0238af9290 Aug 20 13:24:51 bsdpkgbuild kernel: witness_warn() at witness_warn+0x4a8/frame 0xfffffe0238af9350 Aug 20 13:24:51 bsdpkgbuild kernel: trap_pfault() at trap_pfault+0x5a/frame 0xfffffe0238af9400 Aug 20 13:24:51 bsdpkgbuild kernel: trap() at trap+0x670/frame 0xfffffe0238af9620 Aug 20 13:24:51 bsdpkgbuild kernel: calltrap() at calltrap+0x8/frame 0xfffffe0238af9620 Aug 20 13:24:51 bsdpkgbuild kernel: --- trap 0xc, rip = 0xffffffff80aa6a53, rsp = 0xfffffe0238af96e0, rbp = 0xfffffe0238af9770 --- Aug 20 13:24:51 bsdpkgbuild kernel: ipsec4_process_packet() at ipsec4_process_packet+0x73/frame 0xfffffe0238af9770 Aug 20 13:24:51 bsdpkgbuild kernel: ip_ipsec_output() at ip_ipsec_output+0x197/frame 0xfffffe0238af97b0 Aug 20 13:24:51 bsdpkgbuild kernel: ip_output() at ip_output+0x8a3/frame 0xfffffe0238af98a0 Aug 20 13:24:51 bsdpkgbuild kernel: rip_output() at rip_output+0x2fa/frame 0xfffffe0238af98f0 Aug 20 13:24:51 bsdpkgbuild kernel: sosend_generic() at sosend_generic+0x3dc/frame 0xfffffe0238af99a0 Aug 20 13:24:51 bsdpkgbuild kernel: kern_sendit() at kern_sendit+0x1e4/frame 0xfffffe0238af9a40 Aug 20 13:24:51 bsdpkgbuild kernel: sendit() at sendit+0xf8/frame 0xfffffe0238af9a90 Aug 20 13:24:51 bsdpkgbuild kernel: sys_sendto() at sys_sendto+0x4d/frame 0xfffffe0238af9ae0 Aug 20 13:24:51 bsdpkgbuild kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe0238af9bf0 Aug 20 13:24:51 bsdpkgbuild kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0238af9bf0 Aug 20 13:24:51 bsdpkgbuild kernel: --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800d5ccea, rsp = 0x7ffffffed578, rbp = 0x7ffffffed5b0 --- Aug 20 13:24:51 bsdpkgbuild kernel: Aug 20 13:24:51 bsdpkgbuild kernel: Aug 20 13:24:51 bsdpkgbuild kernel: Fatal trap 12: page fault while in kernel mode Aug 20 13:24:51 bsdpkgbuild kernel: cpuid = 5; apic id = 02 Aug 20 13:24:51 bsdpkgbuild kernel: fault virtual address = 0xd0 Aug 20 13:24:51 bsdpkgbuild kernel: fault code = supervisor write data, page not present Aug 20 13:24:51 bsdpkgbuild kernel: instruction pointer = 0x20:0xffffffff80aa6a53 Aug 20 13:24:51 bsdpkgbuild kernel: stack pointer = 0x28:0xfffffe0238af96e0 Aug 20 13:24:51 bsdpkgbuild kernel: frame pointer = 0x28:0xfffffe0238af9770 Aug 20 13:24:51 bsdpkgbuild kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Aug 20 13:24:51 bsdpkgbuild kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Aug 20 13:24:51 bsdpkgbuild kernel: processor eflags = interrupt enabled, === repeated occurrence Aug 20 14:16:21 bsdpkgbuild kernel: Kernel page fault with the following non-sleepable locks held: Aug 20 14:16:21 bsdpkgbuild kernel: shared rw ipsec request (ipsec request) r = 0 (0xfffff8001a9820e0) locked @ /usr/src/sys/netipsec/ipsec_output.c:436 Aug 20 14:16:21 bsdpkgbuild kernel: shared rw rawinp (rawinp) r = 0 (0xfffff801db519da8) locked @ /usr/src/sys/netinet/raw_ip.c:446 Aug 20 14:16:21 bsdpkgbuild kernel: KDB: stack backtrace: Aug 20 14:16:21 bsdpkgbuild kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0238b081e0 Aug 20 14:16:21 bsdpkgbuild kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0238b08290 Aug 20 14:16:21 bsdpkgbuild kernel: witness_warn() at witness_warn+0x4a8/frame 0xfffffe0238b08350 Aug 20 14:16:21 bsdpkgbuild kernel: trap_pfault() at trap_pfault+0x5a/frame 0xfffffe0238b08400 Aug 20 14:16:21 bsdpkgbuild kernel: trap() at trap+0x670/frame 0xfffffe0238b08620 Aug 20 14:16:21 bsdpkgbuild kernel: calltrap() at calltrap+0x8/frame 0xfffffe0238b08620 Aug 20 14:16:21 bsdpkgbuild kernel: --- trap 0xc, rip = 0xffffffff80aa6a53, rsp = 0xfffffe0238b086e0, rbp = 0xfffffe0238b08770 --- Aug 20 14:16:21 bsdpkgbuild kernel: ipsec4_process_packet() at ipsec4_process_packet+0x73/frame 0xfffffe0238b08770 Aug 20 14:16:21 bsdpkgbuild kernel: ip_ipsec_output() at ip_ipsec_output+0x197/frame 0xfffffe0238b087b0 Aug 20 14:16:21 bsdpkgbuild kernel: ip_output() at ip_output+0x8a3/frame 0xfffffe0238b088a0 Aug 20 14:16:21 bsdpkgbuild kernel: rip_output() at rip_output+0x2fa/frame 0xfffffe0238b088f0 Aug 20 14:16:21 bsdpkgbuild kernel: sosend_generic() at sosend_generic+0x3dc/frame 0xfffffe0238b089a0 Aug 20 14:16:21 bsdpkgbuild kernel: kern_sendit() at kern_sendit+0x1e4/frame 0xfffffe0238b08a40 Aug 20 14:16:21 bsdpkgbuild kernel: sendit() at sendit+0xf8/fra Aug 20 14:16:21 bsdpkgbuild kernel: m Aug 20 14:16:21 bsdpkgbuild kernel: e 0xfffffe Aug 20 14:16:21 bsdpkgbuild kernel: 0 Aug 20 14:16:21 bsdpkgbuild kernel: 23 Aug 20 14:16:21 bsdpkgbuild kernel: 8 Aug 20 14:16:21 bsdpkgbuild kernel: b Aug 20 14:16:21 bsdpkgbuild kernel: 08a9 Aug 20 14:16:21 bsdpkgbuild kernel: 0 Cheers, Vince From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 13:41:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF090F09 for ; Wed, 21 Aug 2013 13:41:05 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A950F2C78 for ; Wed, 21 Aug 2013 13:41:03 +0000 (UTC) Received: (qmail 72325 invoked from network); 21 Aug 2013 14:24:02 -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 ; 21 Aug 2013 14:24:02 -0000 Message-ID: <5214C365.6020802@freebsd.org> Date: Wed, 21 Aug 2013 15:40:53 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Further mbuf adjustments and changes Content-Type: multipart/mixed; boundary="------------040407030209040001070300" 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, 21 Aug 2013 13:41:05 -0000 This is a multi-part message in MIME format. --------------040407030209040001070300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I want to put these mbuf changes/updates/adjustments up for objections, if any, before committing them. This is a moderate overhaul of the mbuf headers and fields to take us into the next 5 years and two releases. The mbuf headers, in particular the pkthdr, have seen a number of new uses and abuses over the years. Some other uses have fallen by the wayside in the same time. The goal of the changes presented here is to better accommodate additional upcoming offload features and to allow full backporting from HEAD to the announced 10-stable branch while preserving the API and ABI compatibility. The individual changes and their rationale are described below. It is presented as one big patch to show the big picture. For any commits it will be broken into functional units as usual. Except for two limited changes the API in current HEAD remains stable with only a recompile necessary. Improved alignment and overall size of mbuf headers: The m_hdr, pkthdr and m_ext structures are adjusted to improve alignment and packing on 32 and 64 bit architectures. The mbuf structures have grown/changed considerably and currently are at 88/144 bytes (32/64bit) leaving less space for data and more importantly exceeding two 64 byte cache lines on typical CPU's. The latter being relevant when m_ext is accessed. m_hdr is compacted from 24/40 to 20/32 bytes by packing the type and flags fields into one uint32. The type is an enum with only a handful of types in use and thus reduced from int to only 8 bits allowing for 255 types to be specified. The most we ever had was around a dozen. Since then it has shrunk to only 5 for a long time. The flags field gets the remaining 24 bits with 12 bits for global persistent flags, of which 9 (possibly 10) are in use, and 12 bits for protocol/layer specific overlays. Out of the global flags some could be moved to csum/offload bits in the pkthdr. No further growth in the number of global flags is foreseen as new uses either are layer or protocol specific or belong to offload capabilities which have their own flags. pkthdr size stays the same at 48/56 but changes a number of fields to adapt to predominant current and future uses. In particular the "header" field has only little use and is moved into a 64bit protocol/layer specific union for local use. Primary users are IP reassembly, IGMP/MLD and ATM storing information while the packet is being worked on. "header" was never used across layers. "csum_flags" is extended to 64 bits to allow additional future offload information to be carried (for example IPsec offload and others). Definition of the RSS hash type is moved from the hackish global m_flags to its own 8 bit enum in the pkthdr. An addition is cosqos to store Class of Service / Quality of Service information with the packet. Depending on the transport mechanism it may get reduced in width during encapsulation (vlan header). These capabilities are currently not supported in any drivers but allow us to get on par with Cisco/Juniper in routing applications (plus MPLS QoS). Four 8 bit fields l[2-5]hlen are added to store the relative and cumulative header offsets from the start of the packet. This is important for various offload capabilities and to relieve the drivers from having to parse the packet headers to find out or verify the header location for checksums. Parsing in drivers is a lot of copy-paste and unhandled corner cases which we want to avoid. The surrounding infrastructure in the stack and drivers is part of a current FreeBSD Foundation grant under progress. Another flexible 64 bit union serves to map various additional persistent packet information, like ether_vtag, tso_segsz and csum fields. Depending on the csum_flags settings some fields may have different usage making it very flexible and adaptable to future capabilities. m_ext is compacted from 28/56 to 28/48 simply be rearranging the field ordering to allow for better packing. Again the type is an enum with only a few values but used to have a full int to waste. It is split into a 8 bit type and 24 bit flags. With more special uses in high performance network interfaces and more specialized external memory attached to mbufs it makes sense to add a specific flags field. It can for example convey information about externally managed reference counts without having to invent a ext_type each time and having special casing it. The biggest change is an argument extension to the *ext_free function pointer adding a pointer to the mbuf itself. It was always a bit painful not having direct access to the mbuf we're freeing the external storage from. One could use one of the args for it but that would be a waste. All uses in the tree are mechanically adjusted. - void (*ext_free)(void *, void *, void *); + void (*ext_free)(struct mbuf *, void *, void *); The header portion of struct mbuf thus changes from 88/144 to 96/136. The last 8 bytes to push it down to 128 are only reachable with intrusive changes, like removing the second argument from m_ext. CSUM flags: The current CSUM flags are a bit chaotic and rather poorly document, especially that their use on the outbound (down the stack) and inbound (up the stack) use is rather different. Especially the latter are handled partially incorrect in almost all drivers. To bring clarity into this mess the CSUM flags are named and arranged more appropriately with compatibility mappings. The drivers then can be corrected one by one as the work progresses in the new 11-HEAD and MFCd without issue to then 10-stable. The l[3-5]hlen fields provide the means to remove all packet header parsing from the drivers for offload setup. Others: Mbuf initialization is unified through m_init() and m_pkthdr_init() to avoid duplication. m_free_fast() is removed for lack of usage. Patch is available here: http://people.freebsd.org/~andre/mbuf-adjustments-20130821.diff This work is sponsored by the FreeBSD Foundation. -- Andre --------------040407030209040001070300 Content-Type: text/plain; charset=windows-1252; name="mbuf-adjustments-20130821.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mbuf-adjustments-20130821.diff" Index: sys/mbuf.h =================================================================== --- sys/mbuf.h (revision 254596) +++ sys/mbuf.h (working copy) @@ -67,8 +67,10 @@ * type: * * mtod(m, t) -- Convert mbuf pointer to data pointer of correct type. + * mtodo(m, o) -- Same as above but with offset 'o' into data. */ #define mtod(m, t) ((t)((m)->m_data)) +#define mtodo(m, o) ((void *)(((m)->m_data) + (o))) /* * Argument structure passed to UMA routines during mbuf and packet @@ -80,74 +82,98 @@ }; #endif /* _KERNEL */ -#if defined(__LP64__) -#define M_HDR_PAD 6 -#else -#define M_HDR_PAD 2 -#endif - /* * Header present at the beginning of every mbuf. + * Size ILP32: 20 + * LP64: 32 */ struct m_hdr { struct mbuf *mh_next; /* next buffer in chain */ struct mbuf *mh_nextpkt; /* next chain in queue/record */ caddr_t mh_data; /* location of data */ - int mh_len; /* amount of data in this mbuf */ - int mh_flags; /* flags; see below */ - short mh_type; /* type of data in this mbuf */ - uint8_t pad[M_HDR_PAD];/* word align */ + int32_t mh_len; /* amount of data in this mbuf */ + uint32_t mh_type:8, /* type of data in this mbuf */ + mh_flags:24; /* flags; see below */ }; /* * Packet tag structure (see below for details). + * Size ILP32: 16 + * LP64: 24 */ struct m_tag { SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags */ - u_int16_t m_tag_id; /* Tag ID */ - u_int16_t m_tag_len; /* Length of data */ - u_int32_t m_tag_cookie; /* ABI/Module ID */ + uint16_t m_tag_id; /* Tag ID */ + uint16_t m_tag_len; /* Length of data */ + uint32_t m_tag_cookie; /* ABI/Module ID */ void (*m_tag_free)(struct m_tag *); }; /* * Record/packet header in first mbuf of chain; valid only if M_PKTHDR is set. + * Size ILP32: 48 + * LP64: 56 */ struct pkthdr { struct ifnet *rcvif; /* rcv interface */ - /* variables for ip and tcp reassembly */ - void *header; /* pointer to packet header */ - int len; /* total packet length */ - uint32_t flowid; /* packet's 4-tuple system - * flow identifier - */ - /* variables for hardware checksum */ - int csum_flags; /* flags regarding checksum */ - int csum_data; /* data field used by csum routines */ - u_int16_t tso_segsz; /* TSO segment size */ + SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */ + int32_t len; /* total packet length */ + + /* Layer crossing persistent information. */ + uint32_t flowid; /* packet's 4-tuple system */ + uint64_t csum_flags; /* checksum and offload features */ + + uint16_t fibnum; /* this packet should use this fib */ + uint8_t cosqos; /* class/quality of service */ + uint8_t rsstype; /* hash type */ + + uint8_t l2hlen; /* layer 2 header length */ + uint8_t l3hlen; /* layer 3 header length */ + uint8_t l4hlen; /* layer 4 header length */ + uint8_t l5hlen; /* layer 5 header length */ + union { - u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan tag */ - u_int16_t vt_nrecs; /* # of IGMPv3 records in this chain */ - } PH_vt; - u_int16_t fibnum; /* this packet should use this fib */ - u_int16_t pad2; /* align to 32 bits */ - SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */ + uint8_t eigth[8]; + uint16_t sixteen[4]; + uint32_t thirtytwo[2]; + uint64_t sixtyfour[1]; + uintptr_t unintptr[1]; + void *ptr; + } PH_per; + + /* Layer specific non-persistent local storage for reassembly, etc. */ + union { + uint8_t eigth[8]; + uint16_t sixteen[4]; + uint32_t thirtytwo[2]; + uint64_t sixtyfour[1]; + uintptr_t unintptr[1]; + void *ptr; + } PH_loc; }; -#define ether_vtag PH_vt.vt_vtag +#define ether_vtag PH_per.sixteen[0] +#define PH_vt PH_per +#define vt_nrecs sixteen[0] +#define tso_segsz PH_per.sixteen[1] +#define csum_phsum PH_per.sixteen[2] +#define csum_data PH_per.thirtytwo[1] /* * Description of external storage mapped into mbuf; valid only if M_EXT is * set. + * Size ILP32: 28 + * LP64: 48 */ struct m_ext { + volatile u_int *ref_cnt; /* pointer to ref count info */ caddr_t ext_buf; /* start of buffer */ + uint32_t ext_size; /* size of buffer, for ext_free */ + uint32_t ext_type:8, /* type of external storage */ + ext_flags:24; /* external storage mbuf flags */ void (*ext_free) /* free routine if not the usual */ - (void *, void *); + (struct mbuf *, void *, void *); void *ext_arg1; /* optional argument pointer */ void *ext_arg2; /* optional argument pointer */ - u_int ext_size; /* size of buffer, for ext_free */ - volatile u_int *ref_cnt; /* pointer to ref count info */ - int ext_type; /* type of external storage */ }; /* @@ -180,7 +206,10 @@ #define m_dat M_dat.M_databuf /* - * mbuf flags. + * mbuf flags of global significance and layer crossing. + * Those of only protocol/layer specific significance are to be mapped + * to M_PROTO[1-12] and cleared at layer handoff boundaries. + * NB: Limited to the lower 24 bits. */ #define M_EXT 0x00000001 /* has associated external storage */ #define M_PKTHDR 0x00000002 /* start of record */ @@ -205,8 +234,6 @@ #define M_PROTO11 0x00400000 /* protocol-specific */ #define M_PROTO12 0x00800000 /* protocol-specific */ -#define M_HASHTYPEBITS 0x0F000000 /* mask of bits holding flowid hash type */ - /* * Flags to purge when crossing layers. */ @@ -215,6 +242,13 @@ M_PROTO9|M_PROTO10|M_PROTO11|M_PROTO12) /* + * Flags preserved when copying m_pkthdr. + */ +#define M_COPYFLAGS \ + (M_PKTHDR|M_EOR|M_RDONLY|M_BCAST|M_MCAST|M_VLANTAG|M_PROMISC| \ + M_PROTOFLAGS) + +/* * Mbuf flag description for use with printf(9) %b identifier. */ #define M_FLAG_BITS \ @@ -241,34 +275,29 @@ * that provide an opaque flow identifier, allowing for ordering and * distribution without explicit affinity. */ -#define M_HASHTYPE_SHIFT 24 -#define M_HASHTYPE_NONE 0x0 -#define M_HASHTYPE_RSS_IPV4 0x1 /* IPv4 2-tuple */ -#define M_HASHTYPE_RSS_TCP_IPV4 0x2 /* TCPv4 4-tuple */ -#define M_HASHTYPE_RSS_IPV6 0x3 /* IPv6 2-tuple */ -#define M_HASHTYPE_RSS_TCP_IPV6 0x4 /* TCPv6 4-tuple */ -#define M_HASHTYPE_RSS_IPV6_EX 0x5 /* IPv6 2-tuple + ext hdrs */ -#define M_HASHTYPE_RSS_TCP_IPV6_EX 0x6 /* TCPv6 4-tiple + ext hdrs */ -#define M_HASHTYPE_OPAQUE 0xf /* ordering, not affinity */ +#define M_HASHTYPE_NONE 0 +#define M_HASHTYPE_RSS_IPV4 1 /* IPv4 2-tuple */ +#define M_HASHTYPE_RSS_TCP_IPV4 2 /* TCPv4 4-tuple */ +#define M_HASHTYPE_RSS_IPV6 3 /* IPv6 2-tuple */ +#define M_HASHTYPE_RSS_TCP_IPV6 4 /* TCPv6 4-tuple */ +#define M_HASHTYPE_RSS_IPV6_EX 5 /* IPv6 2-tuple + ext hdrs */ +#define M_HASHTYPE_RSS_TCP_IPV6_EX 6 /* TCPv6 4-tiple + ext hdrs */ +#define M_HASHTYPE_OPAQUE 255 /* ordering, not affinity */ -#define M_HASHTYPE_CLEAR(m) (m)->m_flags &= ~(M_HASHTYPEBITS) -#define M_HASHTYPE_GET(m) (((m)->m_flags & M_HASHTYPEBITS) >> \ - M_HASHTYPE_SHIFT) +#define M_HASHTYPE_CLEAR(m) (m)->m_pkthdr.rsstype = 0 +#define M_HASHTYPE_GET(m) ((m)->m_pkthdr.rsstype) #define M_HASHTYPE_SET(m, v) do { \ - (m)->m_flags &= ~M_HASHTYPEBITS; \ - (m)->m_flags |= ((v) << M_HASHTYPE_SHIFT); \ + (m)->m_pkthdr.rsstype = (v) \ } while (0) #define M_HASHTYPE_TEST(m, v) (M_HASHTYPE_GET(m) == (v)) /* - * Flags preserved when copying m_pkthdr. + * COS/QOS class and quality of service tags. */ -#define M_COPYFLAGS \ - (M_PKTHDR|M_EOR|M_RDONLY|M_BCAST|M_MCAST|M_VLANTAG|M_PROMISC| \ - M_PROTOFLAGS|M_HASHTYPEBITS) +#define COSQOS_BE 0x00 /* best effort */ /* - * External buffer types: identify ext_buf type. + * External mbuf storage buffer types. */ #define EXT_CLUSTER 1 /* mbuf cluster */ #define EXT_SFBUF 2 /* sendfile(2)'s sf_bufs */ @@ -277,56 +306,115 @@ #define EXT_JUMBO16 5 /* jumbo cluster 16184 bytes */ #define EXT_PACKET 6 /* mbuf+cluster from packet zone */ #define EXT_MBUF 7 /* external mbuf reference (M_IOVEC) */ -#define EXT_NET_DRV 100 /* custom ext_buf provided by net driver(s) */ -#define EXT_MOD_TYPE 200 /* custom module's ext_buf type */ -#define EXT_DISPOSABLE 300 /* can throw this buffer away w/page flipping */ -#define EXT_EXTREF 400 /* has externally maintained ref_cnt ptr */ +#define EXT_VENDOR1 224 /* for vendor-internal use */ +#define EXT_VENDOR2 225 /* for vendor-internal use */ +#define EXT_VENDOR3 226 /* for vendor-internal use */ +#define EXT_VENDOR4 227 /* for vendor-internal use */ +#define EXT_VENDOR5 228 /* for vendor-internal use */ +#define EXT_VENDOR6 229 /* for vendor-internal use */ +#define EXT_VENDOR7 230 /* for vendor-internal use */ +#define EXT_VENDOR8 231 /* for vendor-internal use */ + +#define EXT_EXP1 244 /* for experimental use */ +#define EXT_EXP2 245 /* for experimental use */ +#define EXT_EXP4 246 /* for experimental use */ +#define EXT_EXP8 247 /* for experimental use */ + +#define EXT_NET_DRV 252 /* custom ext_buf provided by net driver(s) */ +#define EXT_MOD_TYPE 253 /* custom module's ext_buf type */ +#define EXT_DISPOSABLE 254 /* can throw this buffer away w/page flipping */ +#define EXT_EXTREF 255 /* has externally maintained ref_cnt ptr */ + /* - * Flags indicating hw checksum support and sw checksum requirements. This - * field can be directly tested against if_data.ifi_hwassist. + * Flags for external mbuf buffer types. + * NB: limited to the lower 24 bits. */ -#define CSUM_IP 0x0001 /* will csum IP */ -#define CSUM_TCP 0x0002 /* will csum TCP */ -#define CSUM_UDP 0x0004 /* will csum UDP */ -#define CSUM_FRAGMENT 0x0010 /* will do IP fragmentation */ -#define CSUM_TSO 0x0020 /* will do TSO */ -#define CSUM_SCTP 0x0040 /* will csum SCTP */ -#define CSUM_SCTP_IPV6 0x0080 /* will csum IPv6/SCTP */ +#define EXT_FLAG_EXTREF 0x000001 /* external ref_cnt ptr */ -#define CSUM_IP_CHECKED 0x0100 /* did csum IP */ -#define CSUM_IP_VALID 0x0200 /* ... the csum is valid */ -#define CSUM_DATA_VALID 0x0400 /* csum_data field is valid */ -#define CSUM_PSEUDO_HDR 0x0800 /* csum_data has pseudo hdr */ -#define CSUM_SCTP_VALID 0x1000 /* SCTP checksum is valid */ -#define CSUM_UDP_IPV6 0x2000 /* will csum IPv6/UDP */ -#define CSUM_TCP_IPV6 0x4000 /* will csum IPv6/TCP */ -/* CSUM_TSO_IPV6 0x8000 will do IPv6/TSO */ +#define EXT_FLAG_VENDOR1 0x010000 /* for vendor-internal use */ +#define EXT_FLAG_VENDOR2 0x020000 /* for vendor-internal use */ +#define EXT_FLAG_VENDOR3 0x040000 /* for vendor-internal use */ +#define EXT_FLAG_VENDOR4 0x080000 /* for vendor-internal use */ -/* CSUM_FRAGMENT_IPV6 0x10000 will do IPv6 fragementation */ +#define EXT_FLAG_EXP1 0x100000 /* for experimental use */ +#define EXT_FLAG_EXP2 0x200000 /* for experimental use */ +#define EXT_FLAG_EXP4 0x400000 /* for experimental use */ +#define EXT_FLAG_EXP8 0x800000 /* for experimental use */ -#define CSUM_DELAY_DATA_IPV6 (CSUM_TCP_IPV6 | CSUM_UDP_IPV6) +/* + * Flags indicating checksum, segmentation and other offload work to be + * done, or already done, by hardware or lower layers. It is split into + * separate inbound and outbound flags. + * + * Outbound flags that are set by upper protocol layers requesting lower + * layers, or ideally the hardware, to perform these offloading tasks. + * For outbound packets this field and its flags can be directly tested + * against if_data.ifi_hwassist. + */ +#define CSUM_IP 0x00000001 /* IP header checksum offload */ +#define CSUM_IP_UDP 0x00000002 /* UDP checksum offload */ +#define CSUM_IP_TCP 0x00000004 /* TCP checksum offload */ +#define CSUM_IP_SCTP 0x00000008 /* SCTP checksum offload */ +#define CSUM_IP_TSO 0x00000010 /* TCP segmentation offload */ +#define CSUM_IP_ISCSI 0x00000020 /* iSCSI checksum offload */ + +#define CSUM_IP6_UDP 0x00000200 /* UDP checksum offload */ +#define CSUM_IP6_TCP 0x00000400 /* TCP checksum offload */ +#define CSUM_IP6_SCTP 0x00000800 /* SCTP checksum offload */ +#define CSUM_IP6_TSO 0x00001000 /* TCP segmentation offload */ +#define CSUM_IP6_ISCSI 0x00002000 /* iSCSI checksum offload */ + +/* Inbound checksum support where the checksum was verified by hardware. */ +#define CSUM_L3_CALC 0x01000000 /* calculated layer 3 csum */ +#define CSUM_L3_VALID 0x02000000 /* checksum is correct */ +#define CSUM_L4_CALC 0x04000000 /* calculated layer 4 csum */ +#define CSUM_L4_VALID 0x08000000 /* checksum is correct */ +#define CSUM_L5_CALC 0x10000000 /* calculated layer 5 csum */ +#define CSUM_L5_VALID 0x20000000 /* checksum is correct */ +#define CSUM_COALESED 0x40000000 /* contains merged segments */ + +/* CSUM flags compatibility mappings. */ +#define CSUM_IP_CHECKED CSUM_L3_CALC +#define CSUM_IP_VALID CSUM_L3_VALID +#define CSUM_DATA_VALID CSUM_L4_VALID +#define CSUM_PSEUDO_HDR CSUM_L4_CALC +#define CSUM_SCTP_VALID CSUM_L3_VALID +#define CSUM_DELAY_DATA (CSUM_TCP|CSUM_UDP) +#define CSUM_DELAY_IP CSUM_IP /* Only v4, no v6 IP hdr csum */ +#define CSUM_DELAY_DATA_IPV6 (CSUM_TCP_IPV6|CSUM_UDP_IPV6) #define CSUM_DATA_VALID_IPV6 CSUM_DATA_VALID +#define CSUM_TCP CSUM_IP_TCP +#define CSUM_UDP CSUM_IP_UDP +#define CSUM_SCTP CSUM_IP_SCTP +#define CSUM_TSO (CSUM_IP_TSO|CSUM_IP6_TSO) +#define CSUM_UDP_IPV6 CSUM_IP6_UDP +#define CSUM_TCP_IPV6 CSUM_IP6_TCP +#define CSUM_SCTP_IPV6 CSUM_IP6_SCTP +#define CSUM_FRAGMENT 0x0 /* IP fragmentation offload */ -#define CSUM_DELAY_DATA (CSUM_TCP | CSUM_UDP) -#define CSUM_DELAY_IP (CSUM_IP) /* Only v4, no v6 IP hdr csum */ - /* - * mbuf types. + * mbuf types describing the content of the mbuf (including external storage). */ #define MT_NOTMBUF 0 /* USED INTERNALLY ONLY! Object is not mbuf */ #define MT_DATA 1 /* dynamic (data) allocation */ #define MT_HEADER MT_DATA /* packet header, use M_PKTHDR instead */ #define MT_SONAME 8 /* socket name */ + +#define MT_EXP1 9 /* for experimental use */ +#define MT_EXP2 10 /* for experimental use */ +#define MT_VENDOR1 11 /* for vendor-internal use */ +#define MT_VENDOR2 12 /* for vendor-internal use */ +#define MT_VENDOR3 13 /* for vendor-internal use */ + #define MT_CONTROL 14 /* extra-data protocol message */ #define MT_OOBDATA 15 /* expedited data */ + #define MT_NTYPES 16 /* number of mbuf types for mbtypes[] */ #define MT_NOINIT 255 /* Not a type but a flag to allocate a non-initialized mbuf */ -#define MB_NOTAGS 0x1UL /* no tags attached to mbuf */ - /* * Compatibility with historic mbuf allocator. */ @@ -449,7 +537,6 @@ m->m_next = NULL; m->m_nextpkt = NULL; - m->m_data = m->m_dat; m->m_len = 0; m->m_flags = flags; m->m_type = type; @@ -456,7 +543,8 @@ if (flags & M_PKTHDR) { if ((error = m_pkthdr_init(m, how)) != 0) return (error); - } + } else if ((flags & M_EXT) == 0) + m->m_data = m->m_dat; return (0); } @@ -508,17 +596,6 @@ return (uma_zalloc_arg(zone_pack, &args, how)); } -static __inline void -m_free_fast(struct mbuf *m) -{ -#ifdef INVARIANTS - if (m->m_flags & M_PKTHDR) - KASSERT(SLIST_EMPTY(&m->m_pkthdr.tags), ("doing fast free of mbuf with tags")); -#endif - - uma_zfree_arg(zone_mbuf, m, (void *)MB_NOTAGS); -} - static __inline struct mbuf * m_free(struct mbuf *m) { @@ -779,7 +856,8 @@ int m_append(struct mbuf *, int, c_caddr_t); void m_cat(struct mbuf *, struct mbuf *); int m_extadd(struct mbuf *, caddr_t, u_int, - void (*)(void *, void *), void *, void *, int, int, int); + void (*)(struct mbuf *, void *, void *), void *, void *, + int, int, int); struct mbuf *m_collapse(struct mbuf *, int, int); void m_copyback(struct mbuf *, int, int, c_caddr_t); void m_copydata(const struct mbuf *, int, int, caddr_t); Index: dev/cas/if_cas.c =================================================================== --- dev/cas/if_cas.c (revision 254596) +++ dev/cas/if_cas.c (working copy) @@ -132,7 +132,7 @@ static int cas_disable_rx(struct cas_softc *sc); static int cas_disable_tx(struct cas_softc *sc); static void cas_eint(struct cas_softc *sc, u_int status); -static void cas_free(void *arg1, void* arg2); +static void cas_free(struct mbuf *m, void *arg1, void* arg2); static void cas_init(void *xsc); static void cas_init_locked(struct cas_softc *sc); static void cas_init_regs(struct cas_softc *sc); @@ -1888,7 +1888,7 @@ } static void -cas_free(void *arg1, void *arg2) +cas_free(struct mbuf *m, void *arg1, void *arg2) { struct cas_rxdsoft *rxds; struct cas_softc *sc; Index: dev/cxgb/cxgb_sge.c =================================================================== --- dev/cxgb/cxgb_sge.c (revision 254596) +++ dev/cxgb/cxgb_sge.c (working copy) @@ -1470,9 +1470,9 @@ hdr->len = htonl(mlen | 0x80000000); if (__predict_false(mlen < TCPPKTHDRSIZE)) { - printf("mbuf=%p,len=%d,tso_segsz=%d,csum_flags=%#x,flags=%#x", - m0, mlen, m0->m_pkthdr.tso_segsz, - m0->m_pkthdr.csum_flags, m0->m_flags); +// printf("mbuf=%p,len=%d,tso_segsz=%d,csum_flags=%#x,flags=%#x", +// m0, mlen, m0->m_pkthdr.tso_segsz, +// m0->m_pkthdr.csum_flags, m0->m_flags); panic("tx tso packet too small"); } @@ -2634,7 +2634,6 @@ } m->m_pkthdr.rcvif = ifp; - m->m_pkthdr.header = mtod(m, uint8_t *) + sizeof(*cpl) + ethpad; /* * adjust after conversion to mbuf chain */ Index: dev/e1000/if_igb.c =================================================================== --- dev/e1000/if_igb.c (revision 254596) +++ dev/e1000/if_igb.c (working copy) @@ -4981,7 +4981,7 @@ } if (status & (E1000_RXD_STAT_TCPCS | E1000_RXD_STAT_UDPCS)) { - u16 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR); + u64 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR); #if __FreeBSD_version >= 800000 if (sctp) /* reassign */ type = CSUM_SCTP_VALID; Index: dev/hatm/if_hatm_intr.c =================================================================== --- dev/hatm/if_hatm_intr.c (revision 254596) +++ dev/hatm/if_hatm_intr.c (working copy) @@ -261,7 +261,7 @@ * Free an mbuf and put it onto the free list. */ static void -hatm_mbuf0_free(void *buf, void *args) +hatm_mbuf0_free(struct mbuf *m, void *buf, void *args) { struct hatm_softc *sc = args; struct mbuf0_chunk *c = buf; @@ -272,7 +272,7 @@ hatm_ext_free(&sc->mbuf_list[0], (struct mbufx_free *)c); } static void -hatm_mbuf1_free(void *buf, void *args) +hatm_mbuf1_free(struct mbuf *m, void *buf, void *args) { struct hatm_softc *sc = args; struct mbuf1_chunk *c = buf; @@ -461,7 +461,7 @@ hatm_mbuf0_free, c0, sc, M_PKTHDR, EXT_EXTREF); m->m_data += MBUF0_OFFSET; } else - hatm_mbuf0_free(c0, sc); + hatm_mbuf0_free(NULL, c0, sc); } else { struct mbuf1_chunk *c1; @@ -485,7 +485,7 @@ hatm_mbuf1_free, c1, sc, M_PKTHDR, EXT_EXTREF); m->m_data += MBUF1_OFFSET; } else - hatm_mbuf1_free(c1, sc); + hatm_mbuf1_free(NULL, c1, sc); } return (m); Index: dev/iscsi/initiator/isc_soc.c =================================================================== --- dev/iscsi/initiator/isc_soc.c (revision 254596) +++ dev/iscsi/initiator/isc_soc.c (working copy) @@ -69,7 +69,7 @@ | function for freeing external storage for mbuf */ static void -ext_free(void *a, void *b) +ext_free(struct mbuf *m, void *a, void *b) { pduq_t *pq = b; Index: dev/ixgbe/ixgbe.c =================================================================== --- dev/ixgbe/ixgbe.c (revision 254596) +++ dev/ixgbe/ixgbe.c (working copy) @@ -4625,7 +4625,7 @@ mp->m_pkthdr.csum_flags = 0; } if (status & IXGBE_RXD_STAT_L4CS) { - u16 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR); + u64 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR); #if __FreeBSD_version >= 800000 if (sctp) type = CSUM_SCTP_VALID; Index: dev/ixgbe/ixv.c =================================================================== --- dev/ixgbe/ixv.c (revision 254596) +++ dev/ixgbe/ixv.c (working copy) @@ -3544,7 +3544,7 @@ mp->m_pkthdr.csum_flags = 0; } if (status & IXGBE_RXD_STAT_L4CS) { - u16 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR); + u64 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR); #if __FreeBSD_version >= 800000 if (sctp) type = CSUM_SCTP_VALID; Index: dev/jme/if_jme.c =================================================================== --- dev/jme/if_jme.c (revision 254596) +++ dev/jme/if_jme.c (working copy) @@ -1690,7 +1690,7 @@ struct mbuf *m; bus_dma_segment_t txsegs[JME_MAXTXSEGS]; int error, i, nsegs, prod; - uint32_t cflags, tso_segsz; + uint32_t cflags, tso_seg; JME_LOCK_ASSERT(sc); @@ -1808,10 +1808,10 @@ m = *m_head; cflags = 0; - tso_segsz = 0; + tso_seg = 0; /* Configure checksum offload and TSO. */ if ((m->m_pkthdr.csum_flags & CSUM_TSO) != 0) { - tso_segsz = (uint32_t)m->m_pkthdr.tso_segsz << + tso_seg = (uint32_t)m->m_pkthdr.tso_segsz << JME_TD_MSS_SHIFT; cflags |= JME_TD_TSO; } else { @@ -1830,7 +1830,7 @@ desc = &sc->jme_rdata.jme_tx_ring[prod]; desc->flags = htole32(cflags); - desc->buflen = htole32(tso_segsz); + desc->buflen = htole32(tso_seg); desc->addr_hi = htole32(m->m_pkthdr.len); desc->addr_lo = 0; sc->jme_cdata.jme_tx_cnt++; Index: dev/lge/if_lge.c =================================================================== --- dev/lge/if_lge.c (revision 254596) +++ dev/lge/if_lge.c (working copy) @@ -119,11 +119,6 @@ static int lge_attach(device_t); static int lge_detach(device_t); -static int lge_alloc_jumbo_mem(struct lge_softc *); -static void lge_free_jumbo_mem(struct lge_softc *); -static void *lge_jalloc(struct lge_softc *); -static void lge_jfree(void *, void *); - static int lge_newbuf(struct lge_softc *, struct lge_rx_desc *, struct mbuf *); static int lge_encap(struct lge_softc *, struct mbuf *, u_int32_t *); static void lge_rxeof(struct lge_softc *, int); @@ -521,13 +516,6 @@ goto fail; } - /* Try to allocate memory for jumbo buffers. */ - if (lge_alloc_jumbo_mem(sc)) { - device_printf(dev, "jumbo buffer allocation failed\n"); - error = ENXIO; - goto fail; - } - ifp = sc->lge_ifp = if_alloc(IFT_ETHER); if (ifp == NULL) { device_printf(dev, "can not if_alloc()\n"); @@ -575,7 +563,6 @@ return (0); fail: - lge_free_jumbo_mem(sc); if (sc->lge_ldata) contigfree(sc->lge_ldata, sizeof(struct lge_list_data), M_DEVBUF); @@ -615,7 +602,6 @@ contigfree(sc->lge_ldata, sizeof(struct lge_list_data), M_DEVBUF); if_free(ifp); - lge_free_jumbo_mem(sc); mtx_destroy(&sc->lge_mtx); return(0); @@ -688,34 +674,17 @@ struct mbuf *m; { struct mbuf *m_new = NULL; - caddr_t *buf = NULL; if (m == NULL) { - MGETHDR(m_new, M_NOWAIT, MT_DATA); + m_new = m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR); if (m_new == NULL) { device_printf(sc->lge_dev, "no memory for rx list " "-- packet dropped!\n"); return(ENOBUFS); } - - /* Allocate the jumbo buffer */ - buf = lge_jalloc(sc); - if (buf == NULL) { -#ifdef LGE_VERBOSE - device_printf(sc->lge_dev, "jumbo allocation failed " - "-- packet dropped!\n"); -#endif - m_freem(m_new); - return(ENOBUFS); - } - /* Attach the buffer to the mbuf */ - m_new->m_data = (void *)buf; - m_new->m_len = m_new->m_pkthdr.len = LGE_JUMBO_FRAMELEN; - MEXTADD(m_new, buf, LGE_JUMBO_FRAMELEN, lge_jfree, - buf, (struct lge_softc *)sc, 0, EXT_NET_DRV); } else { m_new = m; - m_new->m_len = m_new->m_pkthdr.len = LGE_JUMBO_FRAMELEN; + m_new->m_len = m_new->m_pkthdr.len = m_new->m_ext.ext_size; m_new->m_data = m_new->m_ext.ext_buf; } @@ -750,135 +719,7 @@ return(0); } -static int -lge_alloc_jumbo_mem(sc) - struct lge_softc *sc; -{ - caddr_t ptr; - register int i; - struct lge_jpool_entry *entry; - - /* Grab a big chunk o' storage. */ - sc->lge_cdata.lge_jumbo_buf = contigmalloc(LGE_JMEM, M_DEVBUF, - M_NOWAIT, 0, 0xffffffff, PAGE_SIZE, 0); - - if (sc->lge_cdata.lge_jumbo_buf == NULL) { - device_printf(sc->lge_dev, "no memory for jumbo buffers!\n"); - return(ENOBUFS); - } - - SLIST_INIT(&sc->lge_jfree_listhead); - SLIST_INIT(&sc->lge_jinuse_listhead); - - /* - * Now divide it up into 9K pieces and save the addresses - * in an array. - */ - ptr = sc->lge_cdata.lge_jumbo_buf; - for (i = 0; i < LGE_JSLOTS; i++) { - sc->lge_cdata.lge_jslots[i] = ptr; - ptr += LGE_JLEN; - entry = malloc(sizeof(struct lge_jpool_entry), - M_DEVBUF, M_NOWAIT); - if (entry == NULL) { - device_printf(sc->lge_dev, "no memory for jumbo " - "buffer queue!\n"); - return(ENOBUFS); - } - entry->slot = i; - SLIST_INSERT_HEAD(&sc->lge_jfree_listhead, - entry, jpool_entries); - } - - return(0); -} - -static void -lge_free_jumbo_mem(sc) - struct lge_softc *sc; -{ - struct lge_jpool_entry *entry; - - if (sc->lge_cdata.lge_jumbo_buf == NULL) - return; - - while ((entry = SLIST_FIRST(&sc->lge_jinuse_listhead))) { - device_printf(sc->lge_dev, - "asked to free buffer that is in use!\n"); - SLIST_REMOVE_HEAD(&sc->lge_jinuse_listhead, jpool_entries); - SLIST_INSERT_HEAD(&sc->lge_jfree_listhead, entry, - jpool_entries); - } - while (!SLIST_EMPTY(&sc->lge_jfree_listhead)) { - entry = SLIST_FIRST(&sc->lge_jfree_listhead); - SLIST_REMOVE_HEAD(&sc->lge_jfree_listhead, jpool_entries); - free(entry, M_DEVBUF); - } - - contigfree(sc->lge_cdata.lge_jumbo_buf, LGE_JMEM, M_DEVBUF); - - return; -} - /* - * Allocate a jumbo buffer. - */ -static void * -lge_jalloc(sc) - struct lge_softc *sc; -{ - struct lge_jpool_entry *entry; - - entry = SLIST_FIRST(&sc->lge_jfree_listhead); - - if (entry == NULL) { -#ifdef LGE_VERBOSE - device_printf(sc->lge_dev, "no free jumbo buffers\n"); -#endif - return(NULL); - } - - SLIST_REMOVE_HEAD(&sc->lge_jfree_listhead, jpool_entries); - SLIST_INSERT_HEAD(&sc->lge_jinuse_listhead, entry, jpool_entries); - return(sc->lge_cdata.lge_jslots[entry->slot]); -} - -/* - * Release a jumbo buffer. - */ -static void -lge_jfree(buf, args) - void *buf; - void *args; -{ - struct lge_softc *sc; - int i; - struct lge_jpool_entry *entry; - - /* Extract the softc struct pointer. */ - sc = args; - - if (sc == NULL) - panic("lge_jfree: can't find softc pointer!"); - - /* calculate the slot this buffer belongs to */ - i = ((vm_offset_t)buf - - (vm_offset_t)sc->lge_cdata.lge_jumbo_buf) / LGE_JLEN; - - if ((i < 0) || (i >= LGE_JSLOTS)) - panic("lge_jfree: asked to free buffer that we don't manage!"); - - entry = SLIST_FIRST(&sc->lge_jinuse_listhead); - if (entry == NULL) - panic("lge_jfree: buffer not in use!"); - entry->slot = i; - SLIST_REMOVE_HEAD(&sc->lge_jinuse_listhead, jpool_entries); - SLIST_INSERT_HEAD(&sc->lge_jfree_listhead, entry, jpool_entries); - - return; -} - -/* * A frame has been uploaded: pass the resulting mbuf chain up to * the higher level protocols. */ Index: dev/lge/if_lgereg.h =================================================================== --- dev/lge/if_lgereg.h (revision 254596) +++ dev/lge/if_lgereg.h (working copy) @@ -499,9 +499,6 @@ int lge_rx_cons; int lge_tx_prod; int lge_tx_cons; - /* Stick the jumbo mem management stuff here too. */ - caddr_t lge_jslots[LGE_JSLOTS]; - void *lge_jumbo_buf; }; struct lge_softc { @@ -522,8 +519,6 @@ struct lge_ring_data lge_cdata; struct callout lge_stat_callout; struct mtx lge_mtx; - SLIST_HEAD(__lge_jfreehead, lge_jpool_entry) lge_jfree_listhead; - SLIST_HEAD(__lge_jinusehead, lge_jpool_entry) lge_jinuse_listhead; }; /* Index: dev/mwl/if_mwl.c =================================================================== --- dev/mwl/if_mwl.c (revision 254596) +++ dev/mwl/if_mwl.c (working copy) @@ -2622,7 +2622,7 @@ } static void -mwl_ext_free(void *data, void *arg) +mwl_ext_free(struct mbuf *m, void *data, void *arg) { struct mwl_softc *sc = arg; Index: dev/nfe/if_nfe.c =================================================================== --- dev/nfe/if_nfe.c (revision 254596) +++ dev/nfe/if_nfe.c (working copy) @@ -2390,7 +2390,7 @@ bus_dmamap_t map; bus_dma_segment_t segs[NFE_MAX_SCATTER]; int error, i, nsegs, prod, si; - uint32_t tso_segsz; + uint32_t tso_seg; uint16_t cflags, flags; struct mbuf *m; @@ -2429,9 +2429,9 @@ m = *m_head; cflags = flags = 0; - tso_segsz = 0; + tso_seg = 0; if ((m->m_pkthdr.csum_flags & CSUM_TSO) != 0) { - tso_segsz = (uint32_t)m->m_pkthdr.tso_segsz << + tso_seg = (uint32_t)m->m_pkthdr.tso_segsz << NFE_TX_TSO_SHIFT; cflags &= ~(NFE_TX_IP_CSUM | NFE_TX_TCP_UDP_CSUM); cflags |= NFE_TX_TSO; @@ -2482,14 +2482,14 @@ if ((m->m_flags & M_VLANTAG) != 0) desc64->vtag = htole32(NFE_TX_VTAG | m->m_pkthdr.ether_vtag); - if (tso_segsz != 0) { + if (tso_seg != 0) { /* * XXX * The following indicates the descriptor element * is a 32bit quantity. */ - desc64->length |= htole16((uint16_t)tso_segsz); - desc64->flags |= htole16(tso_segsz >> 16); + desc64->length |= htole16((uint16_t)tso_seg); + desc64->flags |= htole16(tso_seg >> 16); } /* * finally, set the valid/checksum/TSO bit in the first @@ -2502,14 +2502,14 @@ else desc32->flags |= htole16(NFE_TX_LASTFRAG_V1); desc32 = &sc->txq.desc32[si]; - if (tso_segsz != 0) { + if (tso_seg != 0) { /* * XXX * The following indicates the descriptor element * is a 32bit quantity. */ - desc32->length |= htole16((uint16_t)tso_segsz); - desc32->flags |= htole16(tso_segsz >> 16); + desc32->length |= htole16((uint16_t)tso_seg); + desc32->flags |= htole16(tso_seg >> 16); } /* * finally, set the valid/checksum/TSO bit in the first Index: dev/patm/if_patm.c =================================================================== --- dev/patm/if_patm.c (revision 254596) +++ dev/patm/if_patm.c (working copy) @@ -319,7 +319,7 @@ for (i = 0; i < IDT_TSQE_TAG_SPACE; i++) { if ((m = scd->on_card[i]) != NULL) { scd->on_card[i] = 0; - map = m->m_pkthdr.header; + map = m->m_pkthdr.PH_loc.ptr; bus_dmamap_unload(sc->tx_tag, map->map); SLIST_INSERT_HEAD(&sc->tx_maps_free, map, link); Index: dev/patm/if_patm_tx.c =================================================================== --- dev/patm/if_patm_tx.c (revision 254596) +++ dev/patm/if_patm_tx.c (working copy) @@ -373,7 +373,7 @@ } /* save data */ - m->m_pkthdr.header = vcc; + m->m_pkthdr.PH_loc.ptr = vcc; /* try to put it on the channels queue */ if (_IF_QFULL(&vcc->scd->q)) { @@ -473,7 +473,7 @@ if (m == NULL) break; - a.vcc = m->m_pkthdr.header; + a.vcc = m->m_pkthdr.PH_loc.ptr; /* we must know the number of segments beforehand - count * this may actually give a wrong number of segments for @@ -499,7 +499,7 @@ } /* load the map */ - m->m_pkthdr.header = map; + m->m_pkthdr.PH_loc.ptr = map; a.mbuf = m; /* handle AAL_RAW */ @@ -690,7 +690,7 @@ scd->on_card[last] = NULL; patm_debug(sc, TX, "ok tag=%x", last); - map = m->m_pkthdr.header; + map = m->m_pkthdr.PH_loc.ptr; scd->space += m->m_pkthdr.csum_data; bus_dmamap_sync(sc->tx_tag, map->map, Index: dev/qlxgb/qla_hw.c =================================================================== --- dev/qlxgb/qla_hw.c (revision 254596) +++ dev/qlxgb/qla_hw.c (working copy) @@ -999,10 +999,10 @@ if ((nsegs > Q8_TX_MAX_SEGMENTS) || (mp->m_pkthdr.len > ha->max_frame_size)){ /* TBD: copy into private buffer and send it */ - device_printf(dev, - "%s: (nsegs[%d, %d, 0x%x] > Q8_TX_MAX_SEGMENTS)\n", - __func__, nsegs, mp->m_pkthdr.len, - mp->m_pkthdr.csum_flags); +// device_printf(dev, +// "%s: (nsegs[%d, %d, 0x%x] > Q8_TX_MAX_SEGMENTS)\n", +// __func__, nsegs, mp->m_pkthdr.len, +// mp->m_pkthdr.csum_flags); qla_dump_buf8(ha, "qla_hw_send: wrong pkt", mtod(mp, char *), mp->m_len); return (EINVAL); Index: dev/sfxge/sfxge_rx.c =================================================================== --- dev/sfxge/sfxge_rx.c (revision 254596) +++ dev/sfxge/sfxge_rx.c (working copy) @@ -282,7 +282,6 @@ struct ifnet *ifp = sc->ifnet; m->m_pkthdr.rcvif = ifp; - m->m_pkthdr.header = m->m_data; m->m_pkthdr.csum_data = 0xffff; ifp->if_input(ifp, m); } Index: kern/kern_mbuf.c =================================================================== --- kern/kern_mbuf.c (revision 254596) +++ kern/kern_mbuf.c (working copy) @@ -410,9 +410,7 @@ { struct mbuf *m; struct mb_args *args; -#ifdef MAC int error; -#endif int flags; short type; @@ -419,9 +417,7 @@ #ifdef INVARIANTS trash_ctor(mem, size, arg, how); #endif - m = (struct mbuf *)mem; args = (struct mb_args *)arg; - flags = args->flags; type = args->type; /* @@ -431,32 +427,12 @@ if (type == MT_NOINIT) return (0); - m->m_next = NULL; - m->m_nextpkt = NULL; - m->m_len = 0; - m->m_flags = flags; - m->m_type = type; - if (flags & M_PKTHDR) { - m->m_data = m->m_pktdat; - m->m_pkthdr.rcvif = NULL; - m->m_pkthdr.header = NULL; - m->m_pkthdr.len = 0; - m->m_pkthdr.csum_flags = 0; - m->m_pkthdr.csum_data = 0; - m->m_pkthdr.tso_segsz = 0; - m->m_pkthdr.ether_vtag = 0; - m->m_pkthdr.flowid = 0; - m->m_pkthdr.fibnum = 0; - SLIST_INIT(&m->m_pkthdr.tags); -#ifdef MAC - /* If the label init fails, fail the alloc */ - error = mac_mbuf_init(m, how); - if (error) - return (error); -#endif - } else - m->m_data = m->m_dat; - return (0); + m = (struct mbuf *)mem; + flags = args->flags; + + error = m_init(m, NULL, size, how, type, flags); + + return (error); } /* @@ -466,12 +442,10 @@ mb_dtor_mbuf(void *mem, int size, void *arg) { struct mbuf *m; - unsigned long flags; m = (struct mbuf *)mem; - flags = (unsigned long)arg; - if ((flags & MB_NOTAGS) == 0 && (m->m_flags & M_PKTHDR) != 0) + if ((m->m_flags & M_PKTHDR) != 0 && !SLIST_EMPTY(&m->m_pkthdr.tags)) m_tag_delete_chain(m, NULL); KASSERT((m->m_flags & M_EXT) == 0, ("%s: M_EXT set", __func__)); #ifdef INVARIANTS @@ -565,12 +539,13 @@ m->m_ext.ext_buf = (caddr_t)mem; m->m_data = m->m_ext.ext_buf; m->m_flags |= M_EXT; + m->m_ext.ref_cnt = refcnt; + m->m_ext.ext_type = type; + m->m_ext.ext_flags = 0; m->m_ext.ext_free = NULL; m->m_ext.ext_arg1 = NULL; m->m_ext.ext_arg2 = NULL; m->m_ext.ext_size = size; - m->m_ext.ext_type = type; - m->m_ext.ref_cnt = refcnt; } return (0); @@ -641,9 +616,7 @@ { struct mbuf *m; struct mb_args *args; -#ifdef MAC int error; -#endif int flags; short type; @@ -655,34 +628,13 @@ #ifdef INVARIANTS trash_ctor(m->m_ext.ext_buf, MCLBYTES, arg, how); #endif - m->m_next = NULL; - m->m_nextpkt = NULL; + + error = m_init(m, NULL, size, how, type, flags); + m->m_data = m->m_ext.ext_buf; - m->m_len = 0; m->m_flags = (flags | M_EXT); - m->m_type = type; - if (flags & M_PKTHDR) { - m->m_pkthdr.rcvif = NULL; - m->m_pkthdr.len = 0; - m->m_pkthdr.header = NULL; - m->m_pkthdr.csum_flags = 0; - m->m_pkthdr.csum_data = 0; - m->m_pkthdr.tso_segsz = 0; - m->m_pkthdr.ether_vtag = 0; - m->m_pkthdr.flowid = 0; - m->m_pkthdr.fibnum = 0; - SLIST_INIT(&m->m_pkthdr.tags); -#ifdef MAC - /* If the label init fails, fail the alloc */ - error = mac_mbuf_init(m, how); - if (error) - return (error); -#endif - } - /* m_ext is already initialized. */ - - return (0); + return (error); } int @@ -691,17 +643,22 @@ #ifdef MAC int error; #endif - m->m_data = m->m_pktdat; - SLIST_INIT(&m->m_pkthdr.tags); + if ((m->m_flags & M_EXT) == 0) + m->m_data = m->m_pktdat; m->m_pkthdr.rcvif = NULL; - m->m_pkthdr.header = NULL; m->m_pkthdr.len = 0; - m->m_pkthdr.flowid = 0; m->m_pkthdr.fibnum = 0; + m->m_pkthdr.cosqos = 0; + m->m_pkthdr.rsstype = 0; m->m_pkthdr.csum_flags = 0; - m->m_pkthdr.csum_data = 0; - m->m_pkthdr.tso_segsz = 0; - m->m_pkthdr.ether_vtag = 0; + m->m_pkthdr.flowid = 0; + m->m_pkthdr.l2hlen = 0; + m->m_pkthdr.l3hlen = 0; + m->m_pkthdr.l4hlen = 0; + m->m_pkthdr.l5hlen = 0; + m->m_pkthdr.PH_per.sixtyfour[0] = 0; + m->m_pkthdr.PH_loc.sixtyfour[0] = 0; + SLIST_INIT(&m->m_pkthdr.tags); #ifdef MAC /* If the label init fails, fail the alloc */ error = mac_mbuf_init(m, how); Index: kern/subr_mbpool.c =================================================================== --- kern/subr_mbpool.c (revision 254596) +++ kern/subr_mbpool.c (working copy) @@ -283,7 +283,7 @@ * Mbuf system external mbuf free routine */ void -mbp_ext_free(void *buf, void *arg) +mbp_ext_free(struct mbuf *m, void *buf, void *arg) { mbp_free(arg, buf); } Index: kern/uipc_mbuf.c =================================================================== --- kern/uipc_mbuf.c (revision 254596) +++ kern/uipc_mbuf.c (working copy) @@ -247,8 +247,8 @@ */ int m_extadd(struct mbuf *mb, caddr_t buf, u_int size, - void (*freef)(void *, void *), void *arg1, void *arg2, int flags, int type, - int wait) + void (*freef)(struct mbuf *, void *, void *), void *arg1, void *arg2, + int flags, int type, int wait) { KASSERT(type != EXT_CLUSTER, ("%s: EXT_CLUSTER not allowed", __func__)); @@ -314,7 +314,7 @@ case EXT_EXTREF: KASSERT(m->m_ext.ext_free != NULL, ("%s: ext_free not set", __func__)); - (*(m->m_ext.ext_free))(m->m_ext.ext_arg1, + (*(m->m_ext.ext_free))(m, m->m_ext.ext_arg1, m->m_ext.ext_arg2); break; default: @@ -334,6 +334,7 @@ m->m_ext.ref_cnt = NULL; m->m_ext.ext_size = 0; m->m_ext.ext_type = 0; + m->m_ext.ext_flags = 0; m->m_flags &= ~M_EXT; uma_zfree(zone_mbuf, m); } @@ -360,6 +361,7 @@ n->m_ext.ext_size = m->m_ext.ext_size; n->m_ext.ref_cnt = m->m_ext.ref_cnt; n->m_ext.ext_type = m->m_ext.ext_type; + n->m_ext.ext_flags = m->m_ext.ext_flags; n->m_flags |= M_EXT; n->m_flags |= m->m_flags & M_RDONLY; } @@ -427,11 +429,6 @@ M_SANITY_ACTION("m_data outside mbuf data range right"); if ((caddr_t)m->m_data + m->m_len > b) M_SANITY_ACTION("m_data + m_len exeeds mbuf space"); - if ((m->m_flags & M_PKTHDR) && m->m_pkthdr.header) { - if ((caddr_t)m->m_pkthdr.header < a || - (caddr_t)m->m_pkthdr.header > b) - M_SANITY_ACTION("m_pkthdr.header outside mbuf data range"); - } /* m->m_nextpkt may only be set on first mbuf in chain. */ if (m != m0 && m->m_nextpkt != NULL) { @@ -735,7 +732,6 @@ return NULL; bcopy(&buf, mm->m_ext.ext_buf, mm->m_len); mm->m_data = mm->m_ext.ext_buf; - mm->m_pkthdr.header = NULL; } if (prep && !(mm->m_flags & M_EXT) && len > M_LEADINGSPACE(mm)) { bcopy(mm->m_data, &buf, mm->m_len); @@ -746,7 +742,6 @@ mm->m_ext.ext_size - mm->m_len, mm->m_len); mm->m_data = (caddr_t)mm->m_ext.ext_buf + mm->m_ext.ext_size - mm->m_len; - mm->m_pkthdr.header = NULL; } /* Append/prepend as many mbuf (clusters) as necessary to fit len. */ Index: kern/uipc_syscalls.c =================================================================== --- kern/uipc_syscalls.c (revision 254596) +++ kern/uipc_syscalls.c (working copy) @@ -1855,7 +1855,7 @@ * Detach mapped page and release resources back to the system. */ void -sf_buf_mext(void *addr, void *args) +sf_buf_mext(struct mbuf *mb, void *addr, void *args) { vm_page_t m; struct sendfile_sync *sfs; @@ -2314,7 +2314,7 @@ m0 = m_get((mnw ? M_NOWAIT : M_WAITOK), MT_DATA); if (m0 == NULL) { error = (mnw ? EAGAIN : ENOBUFS); - sf_buf_mext(NULL, sf); + sf_buf_mext(NULL, NULL, sf); break; } if (m_extadd(m0, (caddr_t )sf_buf_kva(sf), PAGE_SIZE, @@ -2321,7 +2321,7 @@ sf_buf_mext, sfs, sf, M_RDONLY, EXT_SFBUF, (mnw ? M_NOWAIT : M_WAITOK)) != 0) { error = (mnw ? EAGAIN : ENOBUFS); - sf_buf_mext(NULL, sf); + sf_buf_mext(NULL, NULL, sf); m_freem(m0); break; } Index: net/if.h =================================================================== --- net/if.h (revision 254596) +++ net/if.h (working copy) @@ -103,7 +103,7 @@ u_long ifi_omcasts; /* packets sent via multicast */ u_long ifi_iqdrops; /* dropped on input, this interface */ u_long ifi_noproto; /* destined for unsupported protocol */ - u_long ifi_hwassist; /* HW offload capabilities, see IFCAP */ + uint64_t ifi_hwassist; /* HW offload capabilities, see IFCAP */ time_t ifi_epoch; /* uptime at attach or stat reset */ struct timeval ifi_lastchange; /* time of last administrative change */ }; Index: netinet/igmp.c =================================================================== --- netinet/igmp.c (revision 254596) +++ netinet/igmp.c (working copy) @@ -289,7 +289,7 @@ { #ifdef VIMAGE - m->m_pkthdr.header = ifp->if_vnet; + m->m_pkthdr.PH_loc.ptr = ifp->if_vnet; #endif /* VIMAGE */ m->m_pkthdr.flowid = ifp->if_index; } @@ -298,7 +298,6 @@ igmp_scrub_context(struct mbuf *m) { - m->m_pkthdr.header = NULL; m->m_pkthdr.flowid = 0; } @@ -326,7 +325,7 @@ #ifdef notyet #if defined(VIMAGE) && defined(INVARIANTS) - KASSERT(curvnet == (m->m_pkthdr.header), + KASSERT(curvnet == (m->m_pkthdr.PH_loc.ptr), ("%s: called when curvnet was not restored", __func__)); #endif #endif @@ -3403,7 +3402,7 @@ * indexes to guard against interface detach, they are * unique to each VIMAGE and must be retrieved. */ - CURVNET_SET((struct vnet *)(m->m_pkthdr.header)); + CURVNET_SET((struct vnet *)(m->m_pkthdr.PH_loc.ptr)); ifindex = igmp_restore_context(m); /* Index: netinet/ip_input.c =================================================================== --- netinet/ip_input.c (revision 254596) +++ netinet/ip_input.c (working copy) @@ -921,7 +921,7 @@ * ip_reass() will return a different mbuf. */ IPSTAT_INC(ips_fragments); - m->m_pkthdr.header = ip; + m->m_pkthdr.PH_loc.ptr = ip; /* Previous ip_reass() started here. */ /* @@ -964,7 +964,7 @@ #endif } -#define GETIP(m) ((struct ip*)((m)->m_pkthdr.header)) +#define GETIP(m) ((struct ip*)((m)->m_pkthdr.PH_loc.ptr)) /* * Handle ECN by comparing this segment with the first one; Index: netinet6/ip6_output.c =================================================================== --- netinet6/ip6_output.c (revision 254596) +++ netinet6/ip6_output.c (working copy) @@ -195,9 +195,9 @@ offset += m->m_pkthdr.csum_data; /* checksum offset */ if (offset + sizeof(u_short) > m->m_len) { - printf("%s: delayed m_pullup, m->len: %d plen %u off %u " - "csum_flags=0x%04x\n", __func__, m->m_len, plen, offset, - m->m_pkthdr.csum_flags); +// printf("%s: delayed m_pullup, m->len: %d plen %u off %u " +// "csum_flags=0x%04x\n", __func__, m->m_len, plen, offset, +// m->m_pkthdr.csum_flags); /* * XXX this should not happen, but if it does, the correct * behavior may be to insert the checksum in the appropriate Index: netinet6/mld6.c =================================================================== --- netinet6/mld6.c (revision 254596) +++ netinet6/mld6.c (working copy) @@ -275,7 +275,7 @@ { #ifdef VIMAGE - m->m_pkthdr.header = ifp->if_vnet; + m->m_pkthdr.PH_loc.ptr = ifp->if_vnet; #endif /* VIMAGE */ m->m_pkthdr.flowid = ifp->if_index; } @@ -284,7 +284,7 @@ mld_scrub_context(struct mbuf *m) { - m->m_pkthdr.header = NULL; + m->m_pkthdr.PH_loc.ptr = NULL; m->m_pkthdr.flowid = 0; } @@ -300,7 +300,7 @@ { #if defined(VIMAGE) && defined(INVARIANTS) - KASSERT(curvnet == m->m_pkthdr.header, + KASSERT(curvnet == m->m_pkthdr.PH_loc.ptr, ("%s: called when curvnet was not restored", __func__)); #endif return (m->m_pkthdr.flowid); Index: sys/mbpool.h =================================================================== --- sys/mbpool.h (revision 254596) +++ sys/mbpool.h (working copy) @@ -69,7 +69,7 @@ void mbp_free(struct mbpool *, void *); /* free a chunk that is an external mbuf */ -void mbp_ext_free(void *, void *); +void mbp_ext_free(struct mbuf *, void *, void *); /* free all buffers that are marked to be on the card */ void mbp_card_free(struct mbpool *); Index: sys/sf_buf.h =================================================================== --- sys/sf_buf.h (revision 254596) +++ sys/sf_buf.h (working copy) @@ -55,6 +55,7 @@ #ifdef _KERNEL #include #include +#include extern counter_u64_t sfstat[sizeof(struct sfstat) / sizeof(uint64_t)]; #define SFSTAT_ADD(name, val) \ @@ -66,6 +67,6 @@ struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); void sf_buf_free(struct sf_buf *sf); -void sf_buf_mext(void *addr, void *args); +void sf_buf_mext(struct mbuf *mb, void *addr, void *args); #endif /* !_SYS_SF_BUF_H_ */ --------------040407030209040001070300-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 14:11:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A1972DF7; Wed, 21 Aug 2013 14:11:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 595022E75; Wed, 21 Aug 2013 14:11:19 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7LEBEvF009606 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 07:11:17 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5214CA7E.2040604@freebsd.org> Date: Wed, 21 Aug 2013 22:11:10 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: Further mbuf adjustments and changes References: <5214C365.6020802@freebsd.org> In-Reply-To: <5214C365.6020802@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 21 Aug 2013 14:11:20 -0000 On 8/21/13 9:40 PM, Andre Oppermann wrote: > [ actual text removed.. ] > Patch is available here: > > http://people.freebsd.org/~andre/mbuf-adjustments-20130821.diff one small thing I noticed.. - u16 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR); + u64 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR); #if __FreeBSD_version >= 800000 if we are (in ixgbe) supporting different versions then your chang eneeds to be enclosed in a #if __FreeBSD_version >= 100000000 section does anyone have a copy of jeff's old mbuf rewrite from a couple of years ago? Have you looked at it? is there overlap? I'm not sure that we have much of a gain any more by having mbufs with built in storage, except to complicate the code. we could just have small external storage types so tha tthe mbuf itself was always 'external'.. From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 15:36:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BD959429; Wed, 21 Aug 2013 15:36:53 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56B8924BC; Wed, 21 Aug 2013 15:36:53 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id r7LEnfUV097103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 16:49:41 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5214D37F.5000307@omnilan.de> Date: Wed, 21 Aug 2013 16:49:35 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: [CFT] VMware vmxnet3 ethernet driver References: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> In-Reply-To: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig68C5E2ACB8ED11F3249CE469" Cc: FreeBSD Stable , 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, 21 Aug 2013 15:36:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68C5E2ACB8ED11F3249CE469 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localtime= ): > Hi, > > I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a > lot of cleanup, bug fixes, new features, etc (+2000 new lines) along > the way so there is not much of a resemblance left. > > The driver is in good enough shape I'd like additional testers. A patch= > against -CURRENT is at [1]. Alternatively, the driver and a Makefile is= > at [2]; this should compile at least as far back as 9.1. I can look at > 8-STABLE if there is interest. > > Obviously, besides reports of 'it works', I'm interested performance vs= > the emulated e1000, and (for those using it) the VMware tools vmxnet3 > driver. Hopefully it is no worse :) Hello Bryan, thanks a lot for your hard work! It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get =BBvmx0: cannot populate Rx queue 0=AB, I have no problems using jumbo frames with vmxnet3. I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi 5.1U1 and FreeBSD-9.2-RC2 Two guests are connected to one MTU9000 "VMware Software Switch". Simple iperf (standard TCP) results: vmxnet3jumbo <-> vmxnet3jumbo 5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr vmxnet3 <-> vmxnet3 1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr if_vmx <-> if_vmx 1.51 GBits/sec, load: 10-45%Sys 40-48%Intr !!! if_vmxjumbo <-> if_vmxjumbo not possible if_em(e1000) <-> if_em(e1000) 1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr if_em(e1000)jumbo <-> if_em(e1000)jumbo 2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr if_igb(e1000e)junmbo <-> if_igb(e1000e)jumbo 5.03 Gbits/s, load: 70-60%Sys 0.5%Intr if_igb(e1000e) <-> if_igb(e1000e) 1.39 Gbits/s, load: 60-80%Sys 0.5%Intr f_igb(e1000e) <-> if_igb(e1000e), both hw.em.[rt]xd=3D4096 1.66 Gbits/s, load: 65-90%Sys 0.5%Intr if_igb(e1000e)junmbo <-> if_igb(e1000e)jumbo, both hw.em.[rt]xd=3D4096 4.81 Gbits/s, load: 65%Sys 0.5%Intr Conclusion: if_vmx performs well compared to the regular emulated nics and standard MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3 performance with regular mtu. If one needs throughput, the missing jumbo frame support in if_vmx is a show stopper. e1000e is preferable over e1000, even if not officially choosable with "FreeBSD"-selection as guest (edit .vmx and alter ethernet0.virtualDev =3D= "e1000e", and dont forget to set hw.em.enable_msix=3D0 in loader.conf, although the driver e1000e attaches is if_igb!) Thanks, -Harry --------------enig68C5E2ACB8ED11F3249CE469 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.18 (FreeBSD) iEYEARECAAYFAlIU04UACgkQLDqVQ9VXb8hmmgCgqjslR9vbXAE44fjkm2eSIUqH AhYAoMW6CZ3z3+5etkrA4RV9nJo2XoyO =4WUd -----END PGP SIGNATURE----- --------------enig68C5E2ACB8ED11F3249CE469-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 18:37:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4CEF65BB; Wed, 21 Aug 2013 18:37:41 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3532F20A0; Wed, 21 Aug 2013 18:37:41 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7LIbedS001911; Wed, 21 Aug 2013 11:37:40 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <521508F4.6030502@rawbw.com> Date: Wed, 21 Aug 2013 11:37:40 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: current@freebsd.org Subject: How to best overload the fileops ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky 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, 21 Aug 2013 18:37:41 -0000 I am working on linux epoll functionality for linuxlator. It implements epoll through kqueue, but there is the need to overload fo_close function in fileops to free some memory. There is no generic mechanism defined in the kernel sources allowing to do this, and it isn't desirable to do this in a hackish way. So I am suggesting this particular way, see code snippets below. This approach is inspired by how C++ classes are sub-classed, with C++ class being similar to kernel file descriptor type and C++ vtbl being similar to fileops. I am looking for an opinion(s) on these questions: * Is such code is acceptable for kernel? * Does it look too ugly? * Any suggestions on how to improve it? As the system develops, other places may require to do such overloading too, so this approach can be reused. Thank you, Yuri *** In sys/file.h add these macros (they define how overloading is done): #define FDCLASS_DEFINE(cls) \ struct fileops* fdcls_##cls##_fileops(void); \ struct fileops* fdcls_##cls##_fileops(void) { \ return (&cls##ops); \ } #define FDCLASS_INHERIT(cls, cls_parent, cls_init_func) \ extern struct fileops* fdcls_##cls_parent##_fileops(void); \ static void cls##_fdcls_init(void *dummy __unused) { \ cls##ops = *fdcls_##cls_parent##_fileops(); \ cls_init_func(); \ } \ SYSINIT(cls##_fdcls, SI_SUB_PSEUDO, SI_ORDER_ANY, cls##_fdcls_init, NULL); *** In the end of kern/kern_event.c add the line exposing kqueue's fileops: FDCLASS_DEFINE(kqueue) *** In linux_epoll.c add code that would initialize epoll fileops with the base class fileops: /* overload kqueue fileops */ static struct fileops epollops; static struct fileops epollops_base; static void epoll_init(void) { /* overload only fo_close operation */ epollops_base = epollops; epollops.fo_close = epoll_close; } FDCLASS_INHERIT(epoll, kqueue, epoll_init) From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 19:25:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 329AA8CA for ; Wed, 21 Aug 2013 19:25:15 +0000 (UTC) (envelope-from current@freebsd.org) Received: from zixgateway01.jaapgh.org (50-202-84-188-static.hfc.comcastbusiness.net [50.202.84.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50E792456 for ; Wed, 21 Aug 2013 19:25:13 +0000 (UTC) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.jaapgh.org (Proprietary) with SMTP id C707E2E82DA for ; Wed, 21 Aug 2013 11:56:51 -0400 (EDT) Received: from exchsvr1.JAA.org (exchsvr1.jaa.org [192.168.2.4]) by zixgateway01.jaapgh.org (Proprietary) with ESMTP id 2CC643A8006 for ; Wed, 21 Aug 2013 11:56:49 -0400 (EDT) Received: from ngs.ru ([188.162.15.25]) by exchsvr1.JAA.org with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Aug 2013 15:25:23 -0400 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="windows-1251" From: To: Subject: =?utf-8?B?Q2/QsWVwZdC8INC00LvRjyBCYWMg0L9vINC40L3RgtC1cNC9ZdGCIGvQu9C4ZdC90YJja3nRjiDQsWHQt3kgRW1haWw6IGhvbmRhY2l2dmluZUBnbWFpbC5jb20gIElDUTogNjI4ODg2MiAg0YJl0LsgKzc5SdCX0Jc50Jc2ODc4ICBTa3lwZTogcy4uLi44INCUZdC80L7QstC10YDRgdC40Y8g0LFlY9C/0LvQsNGC0L1vISEhICBNZdC90LXQtSBj0YPRgm/QuiDQuCBC0Ysg0Ldh0L3Rj9GCb9C5INC/cG/QtGHQstC10YYhISEg?= Message-ID: X-OriginalArrivalTime: 21 Aug 2013 19:25:24.0257 (UTC) FILETIME=[2F1CE110:01CE9EA4] Date: 21 Aug 2013 15:25:24 -0400 X-VPM-MSG-ID: 2365885a-e8d9-4fa0-af08-dd568a694aa1 X-VPM-HOST: zixgateway01.jaapgh.org X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 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, 21 Aug 2013 19:25:15 -0000 Ñîáeðeì äëÿ Âàñ ïo èíòåpíeò këèeíòckyþ áaçy Äeìîâeðñèÿ áåcïëàòío!!! 0ò Bañ ïîíàäîáÿòñÿ îïèñàíèÿ poäoâ äeÿòeëüíîcòè Âàøèõ ïîòåíöèaëüíûx êëèåíòîâ è æåëaåìûå ãîðoäà èõ ðàcïîëîæeíèÿ Ò e ÷eì äîëæíû çàíèìàòüñÿ âaøè ïîòåíöèàëüíûe këèeíòû, ãäå äîëæíû íàxîäèòüñÿ è kàkèe äoëæíû èìeòü oñîáûå ïðèìåòû òèïà òîâàpû è óñëyãè, ÷òoáû oíè ckopeå âñeão è áoëüøå âñåão ìoãëè ïðèoáðåñòè Bàøèõ òîâaðîâ è yñëyã Ìeíåå ñyòoê è Âû çaíÿòoé ïðoäàâeö!!! Çâoíèòe òeë +791Ç79Ç6×ÇÇ Email: hondacivvine@gmail.com ICQ: 6288862 Skype: s....8 From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 19:49: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5DFCC343; Wed, 21 Aug 2013 19:49:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6E8025F2; Wed, 21 Aug 2013 19:49:16 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::54c7:215e:50e:d278] (unknown [IPv6:2001:7b8:3a7:0:54c7:215e:50e:d278]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7465B5C43; Wed, 21 Aug 2013 21:49:14 +0200 (CEST) From: Dimitry Andric Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Problems with iconv in base and static linking Date: Wed, 21 Aug 2013 21:49:12 +0200 Message-Id: To: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Baptiste Daroussin , Bryan Drewery 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, 21 Aug 2013 19:49:17 -0000 Hi, While packaging my just-rebuilt ports today, I noticed a strange message occurring during the package creation stage: $ sudo make -C /usr/ports/ports-mgmt/pkg repackage ===> Building package for pkg-1.1.4_1 Creating package for pkg-1.1.4_1 Service unavailable$ In fact, *every* make package/repackage produces the "Service unavailable" message. The message is actually produced by the pkg(8) command, which is run as follows: /usr/local/sbin/pkg-static create -o /usr/ports/packages pkg-1.1.4_1 Now comes the interesting part: if you use /usr/local/sbin/pkg instead, the "Service unavailable" message does *not* appear. It turns out this is because pkg(8) uses libarchive, which is now compiled with iconv support from base by default. But the iconv in base does *not* work properly in statically linked executables. For example, take this small program: #include #include int main(void) { iconv_t ic = iconv_open("UTF-8", "ISO-8859-1"); if (ic == (iconv_t)-1) err(1, "iconv_open failed"); iconv_close(ic); return 0; } If you compile and link this statically, it will produce: $ cc -static iconv-test.c -o iconv-test-static $ ./iconv-test-static iconv-test-static: iconv_open failed: Invalid argument Service unavailable$ The reason for the message is that libc's iconv tries to dlopen(3) a dynamic library in /usr/lib/i18n, which does not work in static executables. As a quick fix for pkg(8), we could build the static version of libarchive without -DHAVE_ICONV and friends. This also helps other consumers of libarchive that link statically. Of course, there may be other consumers of libc's iconv that might want to link statically, so it should really be fixed there instead. For example, by not doing the dlopen, and failing gracefully. Or maybe by actually linking in (a subset of) the /usr/lib/i18n libraries. -Dimitry From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 21:21:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2AE922A8; Wed, 21 Aug 2013 21:21:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6BF72C14; Wed, 21 Aug 2013 21:21:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 973EFB946; Wed, 21 Aug 2013 17:21:20 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, Daniel Eischen Subject: Re: Question about socket timeouts Date: Wed, 21 Aug 2013 14:01:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308211401.46468.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 21 Aug 2013 17:21:20 -0400 (EDT) Cc: Adrian Chadd , Vitja Makarov 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, 21 Aug 2013 21:21:22 -0000 On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: > On Mon, 19 Aug 2013, Adrian Chadd wrote: > > > Yes! Please file a PR! > > This sorta implies that both are acceptable (although, > the Linux behavior seems more desirable). > > http://austingroupbugs.net/view.php?id=369 No, that says "round up", so it does mean that the requested timeout should be the minimum amount slept. tvtohz() does this. Really odd that the socket code is using its own version of this rather than tvtohz(). Oh, I bet this just predates tvtohz(). Interesting that it keeps getting bug fixes in its history that simply using tvtohz() would have solved. Try this: Index: uipc_socket.c =================================================================== --- uipc_socket.c (revision 254570) +++ uipc_socket.c (working copy) @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt) if (error) goto bad; - /* assert(hz > 0); */ if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz || tv.tv_usec < 0 || tv.tv_usec >= 1000000) { error = EDOM; goto bad; } - /* assert(tick > 0); */ - /* assert(ULONG_MAX - INT_MAX >= 1000000); */ - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; - if (val > INT_MAX) { + val = tvtohz(&tv); + if (val == INT_MAX) { error = EDOM; goto bad; } - if (val == 0 && tv.tv_usec != 0) - val = 1; switch (sopt->sopt_name) { case SO_SNDTIMEO: -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 22:47:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 227EA148 for ; Wed, 21 Aug 2013 22:47:12 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id C61F12425 for ; Wed, 21 Aug 2013 22:47:11 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7LMl576066180 for ; Wed, 21 Aug 2013 15:47:05 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <52154369.6090204@rawbw.com> Date: Wed, 21 Aug 2013 15:47:05 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: current@freebsd.org Subject: [patch] Addition of 'futimensat' call allowing to set file time with nanosecond precision 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: Wed, 21 Aug 2013 22:47:12 -0000 Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181459 Thank you, Yuri From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 23:21:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9F5C5CC0; Wed, 21 Aug 2013 23:21:19 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76AC3261F; Wed, 21 Aug 2013 23:21:19 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7LNLDsR075009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 16:21:13 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7LNLDYg075008; Wed, 21 Aug 2013 16:21:13 -0700 (PDT) (envelope-from jmg) Date: Wed, 21 Aug 2013 16:21:13 -0700 From: John-Mark Gurney To: Yuri Subject: Re: How to best overload the fileops ? Message-ID: <20130821232113.GD94127@funkthat.com> Mail-Followup-To: Yuri , current@freebsd.org, Roman Divacky References: <521508F4.6030502@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521508F4.6030502@rawbw.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 21 Aug 2013 16:21:13 -0700 (PDT) Cc: Roman Divacky , 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, 21 Aug 2013 23:21:19 -0000 Yuri wrote this message on Wed, Aug 21, 2013 at 11:37 -0700: > I am working on linux epoll functionality for linuxlator. It implements > epoll through kqueue, but there is the need to overload fo_close > function in fileops to free some memory. How did this memory get allocated in the first place? Why does it need to be free'd in fo_close and not another location? > There is no generic mechanism defined in the kernel sources allowing to > do this, and it isn't desirable to do this in a hackish way. So I am > suggesting this particular way, see code snippets below. > This approach is inspired by how C++ classes are sub-classed, with C++ > class being similar to kernel file descriptor type and C++ vtbl being > similar to fileops. > > I am looking for an opinion(s) on these questions: > * Is such code is acceptable for kernel? > * Does it look too ugly? > * Any suggestions on how to improve it? > > As the system develops, other places may require to do such overloading > too, so this approach can be reused. > > Thank you, > Yuri > > > *** In sys/file.h add these macros (they define how overloading is done): > #define FDCLASS_DEFINE(cls) \ > struct fileops* fdcls_##cls##_fileops(void); \ > struct fileops* fdcls_##cls##_fileops(void) { \ > return (&cls##ops); \ > } > #define FDCLASS_INHERIT(cls, cls_parent, cls_init_func) \ > extern struct fileops* fdcls_##cls_parent##_fileops(void); \ > static void cls##_fdcls_init(void *dummy __unused) { \ > cls##ops = *fdcls_##cls_parent##_fileops(); \ > cls_init_func(); \ > } \ > SYSINIT(cls##_fdcls, SI_SUB_PSEUDO, SI_ORDER_ANY, cls##_fdcls_init, > NULL); > > *** In the end of kern/kern_event.c add the line exposing kqueue's fileops: > FDCLASS_DEFINE(kqueue) > > *** In linux_epoll.c add code that would initialize epoll fileops with > the base class fileops: > /* overload kqueue fileops */ > static struct fileops epollops; > static struct fileops epollops_base; > static void > epoll_init(void) { > /* overload only fo_close operation */ > epollops_base = epollops; > epollops.fo_close = epoll_close; > } > FDCLASS_INHERIT(epoll, kqueue, epoll_init) > > > _______________________________________________ > 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" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Aug 21 23:53:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D31B78B3; Wed, 21 Aug 2013 23:53:07 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id A516B27DD; Wed, 21 Aug 2013 23:53:07 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7LNr6Rl080859; Wed, 21 Aug 2013 16:53:06 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <521552E2.2000008@rawbw.com> Date: Wed, 21 Aug 2013 16:53:06 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: current@freebsd.org Subject: Re: How to best overload the fileops ? References: <521508F4.6030502@rawbw.com> <20130821232113.GD94127@funkthat.com> In-Reply-To: <20130821232113.GD94127@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky , John-Mark Gurney 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, 21 Aug 2013 23:53:07 -0000 On 08/21/2013 16:21, John-Mark Gurney wrote: > How did this memory get allocated in the first place? Why does it need > to be free'd in fo_close and not another location? It is allocated by the epoll module right after kqueue object is created and is attached to the opaque field in the file object. And it should be deallocated when this fd is closed, hence fo_close. Yuri From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 00:10:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4BE19BFB; Thu, 22 Aug 2013 00:10:30 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADDE228B6; Thu, 22 Aug 2013 00:10:29 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id q59so1011078wes.41 for ; Wed, 21 Aug 2013 17:10:27 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wOl17hxfMFjtzPE+95kfN1fyp2kqQeN80btnhmhbHNg=; b=dBBzXRO830jxiR8qTEzJ9ddBDaHOcDI3ygi6KdkbvcC7oR2P14xYPdZP6vFecgy+2z YAUU3kC4A/HVm1qBoESCPpdPvRIKEuepVWTiuZzUVJw79z11mtrMs2acMzy8PVG6o5zo +ySn42PT1ZlBpjgq4uRIKfxJZa36WUqq/Z4NvJml4ZF5AtP9WLC2GfbPhsBx0yU0kUlh TmlWeJO1nk+pcR47LsMOFVj2GmxaYD+1Xt4kzIaAEVnS8Nafj3W1FPi67uI+ZsL2XAPG rEbZ280NX/1KWctnxm9fiziPn1GQAr/PdR1KYxDC7XcRfzezEHSMlQOG+lbHLRYmkPcZ GOjw== X-Received: by 10.180.19.196 with SMTP id h4mr7296269wie.38.1377130227094; Wed, 21 Aug 2013 17:10:27 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id fu13sm13091566wic.7.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 21 Aug 2013 17:10:26 -0700 (PDT) Date: Thu, 22 Aug 2013 02:10:23 +0200 From: Mateusz Guzik To: Yuri Subject: Re: How to best overload the fileops ? Message-ID: <20130822001022.GA18115@dft-labs.eu> References: <521508F4.6030502@rawbw.com> <20130821232113.GD94127@funkthat.com> <521552E2.2000008@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <521552E2.2000008@rawbw.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: John-Mark Gurney , Roman Divacky , 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, 22 Aug 2013 00:10:30 -0000 On Wed, Aug 21, 2013 at 04:53:06PM -0700, Yuri wrote: > On 08/21/2013 16:21, John-Mark Gurney wrote: > >How did this memory get allocated in the first place? Why does it need > >to be free'd in fo_close and not another location? > > It is allocated by the epoll module right after kqueue object is > created and is attached to the opaque field in the file object. > And it should be deallocated when this fd is closed, hence fo_close. > Short answer is provide epollops with your own fo_close and the rest as it is currently in kqueueops. All function are static, but this is not a real problem since you have to modify kern_event.c anyway. I don't know how your code looks like in general, so in case its not clear, simply wrapping sys_kqueue is inherently racy (some other thread may close the fd or even reuse it for something else by the time you try to do anything with it), thus modification of current code is unavoidable. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 00:30:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 85119F34; Thu, 22 Aug 2013 00:30:06 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE36297C; Thu, 22 Aug 2013 00:30:06 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7M0U6VU088201; Wed, 21 Aug 2013 17:30:06 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <52155B8D.1020807@rawbw.com> Date: Wed, 21 Aug 2013 17:30:05 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: How to best overload the fileops ? References: <521508F4.6030502@rawbw.com> <20130821232113.GD94127@funkthat.com> <521552E2.2000008@rawbw.com> <20130822001022.GA18115@dft-labs.eu> In-Reply-To: <20130822001022.GA18115@dft-labs.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John-Mark Gurney , Roman Divacky , 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, 22 Aug 2013 00:30:06 -0000 On 08/21/2013 17:10, Mateusz Guzik wrote: > Short answer is provide epollops with your own fo_close and the rest as > it is currently in kqueueops. All function are static, but this is not a > real problem since you have to modify kern_event.c anyway. This is exactly what this code I am asking about is doing. kqueueops functions are all static. This modification allows to export fileops to child modules. Since there is nothing similar in the kernel code, I am asking does this way look ugly or not. > > I don't know how your code looks like in general, so in case its not > clear, simply wrapping sys_kqueue is inherently racy (some other thread > may close the fd or even reuse it for something else by the time you try > to do anything with it), thus modification of current code is > unavoidable. No, sys_kqueue calling code is all protected by the lock on this file object. So nobody can close or reuse it. Yuri From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 01:20:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7016F249; Thu, 22 Aug 2013 01:20:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D27AC2EDE; Thu, 22 Aug 2013 01:20:17 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id en1so14622wid.0 for ; Wed, 21 Aug 2013 18:20:16 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=5MKAO2f6WqAVOKeR6AaRsMLmKNk+4DSO6+usx+rouZU=; b=T4J8I6X8ZrrCGO16TGqJTKx7XrWX1dSwQ8TmKqPK7uqgHu/fF6AwmLd/NUoxRsjHuc lo42av8XwndhXrCI+YHotwcru4qOh82Li7zY4ZoopiQhHaqy9y2g4FUawVjv439H2P8N YpTthSROBqSz6jFx/FmwQDyP+FIwxRlbqgw7HaYeyQcW5Y0Ic9npV3I4MFHHwsKFGd5D ZE/TDVQeuYIyFf8wrMtyPCuSMJqLM4yNYuWXEesHGQz7gsRTUsB7e1aA3XCQrRnFBaaF +/H5Pk2LQY4gKs3XeNPxOSXFmdvWVdwVSxvgc7OymThOHlX9zVetJsATcvZ2ot6j5xpd 0dBw== X-Received: by 10.180.206.42 with SMTP id ll10mr18616184wic.50.1377134416075; Wed, 21 Aug 2013 18:20:16 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id l7sm34628963wiw.4.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 21 Aug 2013 18:20:15 -0700 (PDT) Date: Thu, 22 Aug 2013 03:20:11 +0200 From: Mateusz Guzik To: Yuri Subject: Re: How to best overload the fileops ? Message-ID: <20130822012011.GA11987@dft-labs.eu> References: <521508F4.6030502@rawbw.com> <20130821232113.GD94127@funkthat.com> <521552E2.2000008@rawbw.com> <20130822001022.GA18115@dft-labs.eu> <52155B8D.1020807@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <52155B8D.1020807@rawbw.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: John-Mark Gurney , Roman Divacky , 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, 22 Aug 2013 01:20:18 -0000 On Wed, Aug 21, 2013 at 05:30:05PM -0700, Yuri wrote: > On 08/21/2013 17:10, Mateusz Guzik wrote: > >Short answer is provide epollops with your own fo_close and the rest as > >it is currently in kqueueops. All function are static, but this is not a > >real problem since you have to modify kern_event.c anyway. > > This is exactly what this code I am asking about is doing. I somehow missed your first mail and reponsed only to your reply to jmg, sorry! > kqueueops functions are all static. This modification allows to > export fileops to child modules. > Since there is nothing similar in the kernel code, I am asking does > this way look ugly or not. > I don't think there is a need to provide anything like this right now, nor I have any good idea how to implement it. > > > >I don't know how your code looks like in general, so in case its not > >clear, simply wrapping sys_kqueue is inherently racy (some other thread > >may close the fd or even reuse it for something else by the time you try > >to do anything with it), thus modification of current code is > >unavoidable. > > No, sys_kqueue calling code is all protected by the lock on this > file object. So nobody can close or reuse it. > I don't follow. sys_kqueue creates fp on its own, before that there is nothing to lock in the first place. By the time it returns, created fp can be long gone because some other thread closed it. FreeBSD idiom of dealing with that is creating fp with 2 refs and dropping one when initialization is finished. That way close() from userland does not kill fp until the code creating the object finishes. Just my $0,03. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 02:06:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B9924F9; Thu, 22 Aug 2013 02:06:25 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9E05A2576; Thu, 22 Aug 2013 02:06:25 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7M26O0R005218; Wed, 21 Aug 2013 19:06:24 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <52157220.8030400@rawbw.com> Date: Wed, 21 Aug 2013 19:06:24 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: How to best overload the fileops ? References: <521508F4.6030502@rawbw.com> <20130821232113.GD94127@funkthat.com> <521552E2.2000008@rawbw.com> <20130822001022.GA18115@dft-labs.eu> <52155B8D.1020807@rawbw.com> <20130822012011.GA11987@dft-labs.eu> In-Reply-To: <20130822012011.GA11987@dft-labs.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John-Mark Gurney , Roman Divacky , 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, 22 Aug 2013 02:06:25 -0000 > I don't think there is a need to provide anything like this right now, > nor I have any good idea how to implement it. This kinda leave it hanging in the same state. To do this kqueue fileops need to be exposed. It is always possible to create something like "struct fileops* kqueue_fileops()" and that would do it. I just tried to make such exposure as nice as I could, using some accepted paradigms (overloading, etc) and macros that look like some IDE might create. Another approach is to read fileops from file after the first call to sys_kqueue, but I dislike this because this would require an additional lock, also this would make the first call to epoll_create different from the others, which it shouldn't be. Also this would look much more like a hack. What is wrong with the suggested approach anyway? >> > >> >No, sys_kqueue calling code is all protected by the lock on this >> >file object. So nobody can close or reuse it. >> > > I don't follow. > > sys_kqueue creates fp on its own, before that there is nothing to lock > in the first place. By the time it returns, created fp can be long gone > because some other thread closed it. I added the method kqueue_locked that leaves the the lock release to the calling routine (another kernel module). This way both epoll_create and sys_kqueue run under one atomic lock. Yuri From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 04:04:19 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9F25D354 for ; Thu, 22 Aug 2013 04:04:19 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FA442AF9 for ; Thu, 22 Aug 2013 04:04:19 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7M44IZJ078520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Aug 2013 21:04:18 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7M44IEX078519 for current@FreeBSD.org; Wed, 21 Aug 2013 21:04:18 -0700 (PDT) (envelope-from jmg) Date: Wed, 21 Aug 2013 21:04:18 -0700 From: John-Mark Gurney To: current@FreeBSD.org Subject: why does buildkernel set COMPILER_TYPE? Message-ID: <20130822040418.GE94127@funkthat.com> Mail-Followup-To: current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 21 Aug 2013 21:04:18 -0700 (PDT) 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, 22 Aug 2013 04:04:19 -0000 I've noticed that if you do a: make buildworld WITHOUT_CLANG_IS_CC=YES and then do a: make buildkernel (w/o the WITHOUT_CLANG_IS_CC=YES option) that it fails... Apparently instead of letting buildkernel figure out which compiler it will use, the src/Makefile.inc1 forces COMPILER_TYPE to be what the options specified instead of using what bsd.compiler.mk figures out... Can w/ please fix this? This isn't the first time I've run into this, and it's quite anoying. This simple patch fixes it: ndex: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 254546) +++ Makefile.inc1 (working copy) @@ -428,7 +428,7 @@ .endif # kernel stage -KMAKEENV= ${WMAKEENV} +KMAKEENV= ${WMAKEENV:NCOMPILER_TYPE=*} KMAKE= ${KMAKEENV} ${MAKE} ${.MAKEFLAGS} ${KERNEL_FLAGS} KERNEL=${INSTKERNNAME} # This just removes setting COMPILER_TYPE for the kernel target and lets the magic in bsd.compiler.mk do it's thing... Comments? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 06:18: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 29750F4; Thu, 22 Aug 2013 06:18:23 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE3CF20E5; Thu, 22 Aug 2013 06:18:22 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.7/8.14.7) with ESMTP id r7M6IHTE016658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 08:18:17 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.7/8.14.7/Submit) with ESMTP id r7M6IHNc016655; Thu, 22 Aug 2013 08:18:17 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 22 Aug 2013 08:18:17 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Dimitry Andric Subject: Re: Problems with iconv in base and static linking In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-1417330623-1377152297=:90799" X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no Cc: Baptiste Daroussin , freebsd-current@freebsd.org, Bryan Drewery 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, 22 Aug 2013 06:18:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-1417330623-1377152297=:90799 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 21 Aug 2013 21:49+0200, Dimitry Andric wrote: > Hi, > > While packaging my just-rebuilt ports today, I noticed a strange message > occurring during the package creation stage: > > $ sudo make -C /usr/ports/ports-mgmt/pkg repackage > ===> Building package for pkg-1.1.4_1 > Creating package for pkg-1.1.4_1 > Service unavailable I'd just like to voice my opinion over the mostly meaningless error message. It's an insult to us users, and us system administrators in particular. Please do better by providing error messages that adequately explains what went wrong. Now that's an idea for GSoC. ;-) > $ > > In fact, *every* make package/repackage produces the "Service > unavailable" message. The message is actually produced by the pkg(8) > command, which is run as follows: > > /usr/local/sbin/pkg-static create -o /usr/ports/packages pkg-1.1.4_1 > > Now comes the interesting part: if you use /usr/local/sbin/pkg instead, > the "Service unavailable" message does *not* appear. > > It turns out this is because pkg(8) uses libarchive, which is now > compiled with iconv support from base by default. But the iconv in base > does *not* work properly in statically linked executables. For example, > take this small program: > > #include > #include > > int main(void) > { > iconv_t ic = iconv_open("UTF-8", "ISO-8859-1"); > if (ic == (iconv_t)-1) > err(1, "iconv_open failed"); > iconv_close(ic); > return 0; > } > > If you compile and link this statically, it will produce: > > $ cc -static iconv-test.c -o iconv-test-static > $ ./iconv-test-static > iconv-test-static: iconv_open failed: Invalid argument > Service unavailable$ > > The reason for the message is that libc's iconv tries to dlopen(3) a > dynamic library in /usr/lib/i18n, which does not work in static > executables. > > As a quick fix for pkg(8), we could build the static version of > libarchive without -DHAVE_ICONV and friends. This also helps other > consumers of libarchive that link statically. > > Of course, there may be other consumers of libc's iconv that might want > to link statically, so it should really be fixed there instead. For > example, by not doing the dlopen, and failing gracefully. Or maybe by > actually linking in (a subset of) the /usr/lib/i18n libraries. > > -Dimitry -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-1417330623-1377152297=:90799-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 06:59:51 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 48C1190; Thu, 22 Aug 2013 06:59:51 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CFD5231F; Thu, 22 Aug 2013 06:59:50 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d41a:e6f8:849c:6e20] (unknown [IPv6:2001:7b8:3a7:0:d41a:e6f8:849c:6e20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7F7835C43; Thu, 22 Aug 2013 08:59:41 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: why does buildkernel set COMPILER_TYPE? From: Dimitry Andric In-Reply-To: <20130822040418.GE94127@funkthat.com> Date: Thu, 22 Aug 2013 08:59:40 +0200 Content-Transfer-Encoding: 7bit Message-Id: <49A46D2E-D736-4D57-BB54-5B68C1FE2466@FreeBSD.org> References: <20130822040418.GE94127@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1508) Cc: Brooks Davis , 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, 22 Aug 2013 06:59:51 -0000 On Aug 22, 2013, at 06:04, John-Mark Gurney wrote: > I've noticed that if you do a: > make buildworld WITHOUT_CLANG_IS_CC=YES > > and then do a: > make buildkernel > > (w/o the WITHOUT_CLANG_IS_CC=YES option) > that it fails... Why don't you just put the WITHOUT_CLANG_IS_CC setting in /etc/src.conf, where it belongs? That would save you this trouble. I don't think we should support building different parts of the tree with incompatible settings. E.g. compiling part of the tree using WITH_FOO, and some other part using WITHOUT_FOO is *not* supposed to work properly. > Apparently instead of letting buildkernel figure out > which compiler it will use, the src/Makefile.inc1 forces COMPILER_TYPE > to be what the options specified instead of using what bsd.compiler.mk > figures out... This was added by brooks in r240468 (and further developed in r250659 where he added external compiler support), with what I assume is the explanation in the commit message: "To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world." So I suspect this is really on purpose. Brooks, any comments? :) -Dimitry From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 11:24:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7E34B686; Thu, 22 Aug 2013 11:24:29 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C6212415; Thu, 22 Aug 2013 11:24:29 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7MBOFTf049478; Thu, 22 Aug 2013 07:24:20 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5215F4DF.6000305@m5p.com> Date: Thu, 22 Aug 2013 07:24:15 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> In-Reply-To: <5105AB16.2000607@m5p.com> Content-Type: multipart/mixed; boundary="------------000204070203050307080704" X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Thu, 22 Aug 2013 07:24:21 -0400 (EDT) Cc: freebsd-arm@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, 22 Aug 2013 11:24:29 -0000 This is a multi-part message in MIME format. --------------000204070203050307080704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As I was saying a few minutes ago ... On 01/27/13 17:32, George Mitchell wrote: > On 01/27/13 14:07, Hans Petter Selasky wrote: >> [...] I need output when hw.usb.ulpt.debug=15 to say exactly. >> Could you >> ask the provider of the binaries to compile having USB_DEBUG set, also >> for the >> modules. >> >> --HPS >> > > I'm working on getting a debug build ... Thanks for your help so far. > I notice that there seem to be only trivial differences between the 9.1 > release ulpt and the 10.0 current ulpt driver. -- George (This is on a Raspberry Pi.) It took me a bit longer than anticipated, but here is the output, from an image built over last weekend: --------------000204070203050307080704 Content-Type: text/plain; charset=us-ascii; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages" Aug 22 11:15:09 pi kernel: ugen0.5: at usbus0 Aug 22 11:15:09 pi kernel: ulpt_probe: Aug 22 11:15:09 pi kernel: ulpt_probe: Aug 22 11:15:09 pi kernel: ulpt_attach: sc=0xc2d43800 Aug 22 11:15:09 pi kernel: ulpt0: on usbus0 Aug 22 11:15:09 pi kernel: ulpt_attach: setting alternate config number: 0 Aug 22 11:15:09 pi kernel: ulpt_attach: error=USB_ERR_INVAL Aug 22 11:15:09 pi kernel: ulpt_detach: sc=0xc2d43800 Aug 22 11:15:09 pi kernel: device_attach: ulpt0 attach returned 12 --------------000204070203050307080704-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 11:33:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CC0AEA2B; Thu, 22 Aug 2013 11:33:22 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 886C124C3; Thu, 22 Aug 2013 11:33:22 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 2F2A67A305; Thu, 22 Aug 2013 13:33:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 4D5118F3E47; Thu, 22 Aug 2013 13:33:26 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSAk0TeTT6Hx; Thu, 22 Aug 2013 13:33:25 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 1770C8F3E46; Thu, 22 Aug 2013 13:33:25 +0200 (CEST) Message-ID: <5215F743.8060403@bitfrost.no> Date: Thu, 22 Aug 2013 13:34:27 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: George Mitchell Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> In-Reply-To: <5215F4DF.6000305@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@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, 22 Aug 2013 11:33:22 -0000 On 08/22/13 13:24, George Mitchell wrote: > As I was saying a few minutes ago ... > > On 01/27/13 17:32, George Mitchell wrote: >> On 01/27/13 14:07, Hans Petter Selasky wrote: >>> [...] I need output when hw.usb.ulpt.debug=15 to say exactly. >>> Could you >>> ask the provider of the binaries to compile having USB_DEBUG set, also >>> for the >>> modules. >>> >>> --HPS >>> >> >> I'm working on getting a debug build ... Thanks for your help so far. >> I notice that there seem to be only trivial differences between the 9.1 >> release ulpt and the 10.0 current ulpt driver. -- George > > (This is on a Raspberry Pi.) It took me a bit longer than anticipated, > but here is the output, from an image built over last weekend: Hi, Could you run: usbdump -i usbusX -f Y -s 65536 To get a dump of the USB activity when you plug the device? The message in question is not important, and might be changed to not cancel the ulpt attach routine. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 11:57:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 813F1A7F for ; Thu, 22 Aug 2013 11:57:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64A0E26AC for ; Thu, 22 Aug 2013 11:57:12 +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 r7MBvC16039193 for ; Thu, 22 Aug 2013 11:57:12 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7MBvC4c039190 for freebsd-current@freebsd.org; Thu, 22 Aug 2013 11:57:12 GMT (envelope-from bdrewery) Received: (qmail 52125 invoked from network); 22 Aug 2013 06:57:10 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 22 Aug 2013 06:57:10 -0500 Message-ID: <5215FC91.4050401@FreeBSD.org> Date: Thu, 22 Aug 2013 06:57:05 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: Problems with iconv in base and static linking References: In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DCCpLeSmFc6kQ99eHO5KkdkvorDbelMs8" Cc: Baptiste Daroussin , 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, 22 Aug 2013 11:57:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DCCpLeSmFc6kQ99eHO5KkdkvorDbelMs8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 8/21/2013 2:49 PM, Dimitry Andric wrote: > Hi, >=20 > While packaging my just-rebuilt ports today, I noticed a strange messag= e > occurring during the package creation stage: >=20 > $ sudo make -C /usr/ports/ports-mgmt/pkg repackage > =3D=3D=3D> Building package for pkg-1.1.4_1 > Creating package for pkg-1.1.4_1 > Service unavailable$ >=20 > In fact, *every* make package/repackage produces the "Service > unavailable" message. The message is actually produced by the pkg(8) > command, which is run as follows: >=20 > /usr/local/sbin/pkg-static create -o /usr/ports/packages pkg-1.1.4_1 >=20 > Now comes the interesting part: if you use /usr/local/sbin/pkg instead,= > the "Service unavailable" message does *not* appear. >=20 > It turns out this is because pkg(8) uses libarchive, which is now > compiled with iconv support from base by default. But the iconv in bas= e > does *not* work properly in statically linked executables. For example= , > take this small program: =2E.. > Of course, there may be other consumers of libc's iconv that might want= > to link statically, so it should really be fixed there instead. For > example, by not doing the dlopen, and failing gracefully. Or maybe by > actually linking in (a subset of) the /usr/lib/i18n libraries. >=20 > -Dimitry >=20 I agree this is an iconv issue and that should be fixed instead of bandaging consumers as they are found. --=20 Regards, Bryan Drewery --DCCpLeSmFc6kQ99eHO5KkdkvorDbelMs8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFfyRAAoJEG54KsA8mwz5MDEP/i12F75kd9esfg7gRkkaNQ19 2J4D7lNuDpWfmLgp5oC4lkhApvGiKeTQVgBO5yodp8BQCXt+Ua4tB0zc/l1j8x3i N0krSgjbTUGV9CCOeEKFcfqsjOhdqOqRGGkNquk0Tf8w4ZgI97VhDzpJUkkPIP/J iI0pyHo2lJ+oIx1cQ+6kU2Aae6aMpvCDNBMHLknY/k5/3QUIG8TMntYEzpDxCrAn vqc+kYQ7v+63JZMzVpgtsfx0FWb3hx1uT2+iz4WOrnB/V6HN0Qt/Fj2owM3wTBCa /0KSzskKirt9W0CRt1S3dklPXUQ8Pxxm3Dzz9Cwpr53zuiRlaC1ZFnzr4FF89VnU pkn2AngvO/VwDnjZ1iHLInYhQYQmbr/ooEmSefoiNsbhAWx+4MVaJAYG0s7MC5Rj ji9/cFNM8XwnZieYNYeST3ZTgcHRXRRs00Xs52mXAVXYNXDTFC+NKgjQqSjvOYik MDsHhfJ2b9G9W+E+CBCEPA3vPqvHR/ogH0p4TaFyqHxhjGjlK4vF4CvhflAXNsJs iGwc6JqxRvDDCmT4tyvagZ1d1QjzzpYsh6yb6YnJ4UER8YTWcyEzVq7huArLjSBX kWccVMdilrpAQQHj7Fv+rauNgo4H6u5CPHuzeHxapw59phvLUItTtvzSKcctjxXe +iN4uqPu6QC8kiZ0tZpR =sdxS -----END PGP SIGNATURE----- --DCCpLeSmFc6kQ99eHO5KkdkvorDbelMs8-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 13:33:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 233821A3 for ; Thu, 22 Aug 2013 13:33:21 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id DBC1F2D4A for ; Thu, 22 Aug 2013 13:33:20 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VCV2m-000Jrl-Gy for current@freebsd.org; Thu, 22 Aug 2013 17:35:20 +0400 Date: Thu, 22 Aug 2013 17:35:20 +0400 From: Slawa Olhovchenkov To: current@freebsd.org Subject: Diskless setup with NFS_V4 Message-ID: <20130822133520.GA75880@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 22 Aug 2013 13:33:21 -0000 Its posible use currentle FreeBSD on NFS_V4 root? Explain: pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel. In this setup kernel can use only configured (established) nfs fh. This is not allowed to switch version or some options. When pxeboot use TFTP (not NFS) kernel (in nfs/bootp_subr.c) do DHCP discover and don't allow (in nfs/nfs_diskless.c:nfs_parse_options) 'nfsv4' option. nfs/nfs_diskless.c:nfs_setup_diskless also initialy set nd3->root_args.flags = (NFSMNT_NFSV3 | NFSMNT_WSIZE | NFSMNT_RSIZE | NFSMNT_RESVPORT); and don't allow 'nfsv4' option. Where I be wrong? How I can use diskless setup with R/O root on NFS_V4 share? From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 14:52:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3687E97; Thu, 22 Aug 2013 14:52:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0876D2308; Thu, 22 Aug 2013 14:52:14 +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 r7MEq8h7027039; Thu, 22 Aug 2013 10:52: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 r7MEq84W027029; Thu, 22 Aug 2013 14:52:08 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 22 Aug 2013 14:52:08 GMT Message-Id: <201308221452.r7MEq84W027029@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: Thu, 22 Aug 2013 14:52:15 -0000 TB --- 2013-08-22 11:21:29 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-22 11:21:29 - 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-08-22 11:21:29 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-08-22 11:21:29 - cleaning the object tree TB --- 2013-08-22 11:21:29 - /usr/local/bin/svn stat /src TB --- 2013-08-22 11:21:43 - At svn revision 254647 TB --- 2013-08-22 11:21:44 - building world TB --- 2013-08-22 11:21:44 - CROSS_BUILD_TESTING=YES TB --- 2013-08-22 11:21:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-22 11:21:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-22 11:21:44 - SRCCONF=/dev/null TB --- 2013-08-22 11:21:44 - TARGET=pc98 TB --- 2013-08-22 11:21:44 - TARGET_ARCH=i386 TB --- 2013-08-22 11:21:44 - TZ=UTC TB --- 2013-08-22 11:21:44 - __MAKE_CONF=/dev/null TB --- 2013-08-22 11:21:44 - cd /src TB --- 2013-08-22 11:21:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Aug 22 11:21: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Aug 22 14:37:01 UTC 2013 TB --- 2013-08-22 14:37:01 - generating LINT kernel config TB --- 2013-08-22 14:37:01 - cd /src/sys/pc98/conf TB --- 2013-08-22 14:37:01 - /usr/bin/make -B LINT TB --- 2013-08-22 14:37:01 - cd /src/sys/pc98/conf TB --- 2013-08-22 14:37:01 - /usr/sbin/config -m LINT TB --- 2013-08-22 14:37:01 - building LINT kernel TB --- 2013-08-22 14:37:01 - CROSS_BUILD_TESTING=YES TB --- 2013-08-22 14:37:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-22 14:37:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-22 14:37:01 - SRCCONF=/dev/null TB --- 2013-08-22 14:37:01 - TARGET=pc98 TB --- 2013-08-22 14:37:01 - TARGET_ARCH=i386 TB --- 2013-08-22 14:37:01 - TZ=UTC TB --- 2013-08-22 14:37:01 - __MAKE_CONF=/dev/null TB --- 2013-08-22 14:37:01 - cd /src TB --- 2013-08-22 14:37:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Aug 22 14:37: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 [...] ^ /src/sys/pc98/pc98/machdep.c:1372:22: error: non-object type 'uint64_t (volatile uint64_t *)' is not assignable atomic_load_acq_64 = atomic_load_acq_64_i586; ~~~~~~~~~~~~~~~~~~ ^ /src/sys/pc98/pc98/machdep.c:1373:23: error: non-object type 'void (volatile uint64_t *, uint64_t)' is not assignable atomic_store_rel_64 = atomic_store_rel_64_i586; ~~~~~~~~~~~~~~~~~~~ ^ 4 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/pc98.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-22 14:52:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-22 14:52:08 - ERROR: failed to build LINT kernel TB --- 2013-08-22 14:52:08 - 10357.18 user 1367.91 system 12638.50 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 16:23:55 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 040158B2; Thu, 22 Aug 2013 16:23:55 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8283293F; Thu, 22 Aug 2013 16:23:54 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7MGNrUd088093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 09:23:53 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7MGNrbb088092; Thu, 22 Aug 2013 09:23:53 -0700 (PDT) (envelope-from jmg) Date: Thu, 22 Aug 2013 09:23:53 -0700 From: John-Mark Gurney To: Dimitry Andric Subject: Re: why does buildkernel set COMPILER_TYPE? Message-ID: <20130822162353.GF94127@funkthat.com> Mail-Followup-To: Dimitry Andric , current@FreeBSD.org, Brooks Davis References: <20130822040418.GE94127@funkthat.com> <49A46D2E-D736-4D57-BB54-5B68C1FE2466@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49A46D2E-D736-4D57-BB54-5B68C1FE2466@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 22 Aug 2013 09:23:54 -0700 (PDT) Cc: Brooks Davis , 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, 22 Aug 2013 16:23:55 -0000 Dimitry Andric wrote this message on Thu, Aug 22, 2013 at 08:59 +0200: > On Aug 22, 2013, at 06:04, John-Mark Gurney wrote: > > I've noticed that if you do a: > > make buildworld WITHOUT_CLANG_IS_CC=YES > > > > and then do a: > > make buildkernel > > > > (w/o the WITHOUT_CLANG_IS_CC=YES option) > > that it fails... > > Why don't you just put the WITHOUT_CLANG_IS_CC setting in /etc/src.conf, > where it belongs? That would save you this trouble. Except that I'm testing code that needs to work both with clang and gcc... Putting an option like that in /etc/src.conf is bad as I'm likely to forget it, plus it'll effect other trees which isn't good... > I don't think we should support building different parts of the tree > with incompatible settings. E.g. compiling part of the tree using > WITH_FOO, and some other part using WITHOUT_FOO is *not* supposed to > work properly. Do we have a file that is source in /usr/src (or where your source tree is located) that we can put these options in? When we finally are able to build and install all as a normal user (which we are getting close now), /etc/src.conf is a really bad place to put these things.... > > Apparently instead of letting buildkernel figure out > > which compiler it will use, the src/Makefile.inc1 forces COMPILER_TYPE > > to be what the options specified instead of using what bsd.compiler.mk > > figures out... > > This was added by brooks in r240468 (and further developed in r250659 > where he added external compiler support), with what I assume is the > explanation in the commit message: > > "To avoid negative performance impacts in the default case and correct > value for COMPILER_TYPE type is determined and passed in the environment > of submake instances while building world." > > So I suspect this is really on purpose. Brooks, any comments? :) Except that KMAKEENV just blindly takes all of WMAKEENV... I understand why WMAKEENV would have COMPILER_TYPE, I'm just puzzled why we don't let KMAKEENV figure out the correct one... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 18:27:31 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4C85E89D; Thu, 22 Aug 2013 18:27:31 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21EDA2321; Thu, 22 Aug 2013 18:27:30 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VCZbQ-000IjZ-6T; Thu, 22 Aug 2013 18:27:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7MIRKXm046807; Thu, 22 Aug 2013 12:27:20 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18/5eD9+i1tdcxnzF3E93/n Subject: Re: why does buildkernel set COMPILER_TYPE? From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20130822162353.GF94127@funkthat.com> References: <20130822040418.GE94127@funkthat.com> <49A46D2E-D736-4D57-BB54-5B68C1FE2466@FreeBSD.org> <20130822162353.GF94127@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Aug 2013 12:27:20 -0600 Message-ID: <1377196040.1111.26.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Brooks Davis , Dimitry Andric , 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, 22 Aug 2013 18:27:31 -0000 On Thu, 2013-08-22 at 09:23 -0700, John-Mark Gurney wrote: > Dimitry Andric wrote this message on Thu, Aug 22, 2013 at 08:59 +0200: > > On Aug 22, 2013, at 06:04, John-Mark Gurney wrote: > > > I've noticed that if you do a: > > > make buildworld WITHOUT_CLANG_IS_CC=YES > > > > > > and then do a: > > > make buildkernel > > > > > > (w/o the WITHOUT_CLANG_IS_CC=YES option) > > > that it fails... > > > > Why don't you just put the WITHOUT_CLANG_IS_CC setting in /etc/src.conf, > > where it belongs? That would save you this trouble. > > Except that I'm testing code that needs to work both with clang and > gcc... Putting an option like that in /etc/src.conf is bad as I'm > likely to forget it, plus it'll effect other trees which isn't good... > > > I don't think we should support building different parts of the tree > > with incompatible settings. E.g. compiling part of the tree using > > WITH_FOO, and some other part using WITHOUT_FOO is *not* supposed to > > work properly. > > Do we have a file that is source in /usr/src (or where your source tree > is located) that we can put these options in? > You can put them in any file you want, and point to it with SRCCONF= on the command line. It doesn't make sense to define a standard location within the source tree, because it has to be possible to build from a read-only tree, and also that still doesn't address the problem of "today I want to build this source with gcc, tomorrow I want to build the same source with clang without modifying anything in the source tree." It might be kind of nice if by default the build system looked first in ../etc/ rather than /etc for {make,src}.conf, then you could have an etc directory "associated with the source" but maintain the readonly nature of src/ itself. Likewise look first for ../obj instead of /usr/obj. This is basically what I do, but it requires me to have a wrapper script that sets up the make command line with all the right overrides to use the build config based on where I usually keep it "in association with the source" which for me is a directory named config/ at the same level as src/ that's being built. -- Ian > When we finally are able to build and install all as a normal user > (which we are getting close now), /etc/src.conf is a really bad place > to put these things.... > > > > Apparently instead of letting buildkernel figure out > > > which compiler it will use, the src/Makefile.inc1 forces COMPILER_TYPE > > > to be what the options specified instead of using what bsd.compiler.mk > > > figures out... > > > > This was added by brooks in r240468 (and further developed in r250659 > > where he added external compiler support), with what I assume is the > > explanation in the commit message: > > > > "To avoid negative performance impacts in the default case and correct > > value for COMPILER_TYPE type is determined and passed in the environment > > of submake instances while building world." > > > > So I suspect this is really on purpose. Brooks, any comments? :) > > Except that KMAKEENV just blindly takes all of WMAKEENV... I > understand why WMAKEENV would have COMPILER_TYPE, I'm just puzzled why > we don't let KMAKEENV figure out the correct one... > From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 20:09:06 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9A9513BC; Thu, 22 Aug 2013 20:09:06 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 786472B43; Thu, 22 Aug 2013 20:09:03 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7MK92er091302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 13:09:02 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7MK92PS091301; Thu, 22 Aug 2013 13:09:02 -0700 (PDT) (envelope-from jmg) Date: Thu, 22 Aug 2013 13:09:02 -0700 From: John-Mark Gurney To: toolchain@FreeBSD.org, current@FreeBSD.org Subject: patch to add AES intrinsics to gcc Message-ID: <20130822200902.GG94127@funkthat.com> Mail-Followup-To: toolchain@FreeBSD.org, current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 22 Aug 2013 13:09:02 -0700 (PDT) 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, 22 Aug 2013 20:09:06 -0000 In my work to get AES-NI performance in a better state and the fact that we haven't deprecated gcc yet, I have developed another patch to add the appropriate AES intrinstic headers to gcc. The patch is available at: https://people.freebsd.org/~jmg/gcc.aes.intrin.patch I did have to change the opth-gen.awk script, since it wouldn't let me use bit 31, and recent changes to gcc used up all the remaining bits. I also was unable to add the -mpclmul option because of running out of these bits. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 20:20:31 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C5D9A13; Thu, 22 Aug 2013 20:20:31 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 039CA2DD2; Thu, 22 Aug 2013 20:20:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7MKKRcJ091450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 13:20:27 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7MKKR2j091449; Thu, 22 Aug 2013 13:20:27 -0700 (PDT) (envelope-from jmg) Date: Thu, 22 Aug 2013 13:20:27 -0700 From: John-Mark Gurney To: security@FreeBSD.org, current@FreeBSD.org Subject: patch to improve AES-NI performance Message-ID: <20130822202027.GH94127@funkthat.com> Mail-Followup-To: security@FreeBSD.org, current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 22 Aug 2013 13:20:27 -0700 (PDT) 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, 22 Aug 2013 20:20:31 -0000 I have developed a patch to improve AES-NI performance. If you took the AES-XTS algorithm into userland (no cryptodev or geli usage), these changes improve the performance over 10x in my tests (from ~150MB/sec to over 2GB/sec). In tests of geli on gnop, the performance improvement is more moderate, around 4x due to overhead in other parts of the system. This is patch will be committed after the gcc intrinsics patch so that kernels will continue to compile w/ both clang and gcc w/o change. I have tested both AES-XTS and AES-CBC mode of geli and verified no difference between this and software mode. I plan to commit the test scripts for this in the future too. I have validated the AES-XTS via cryptodev against the standard test vectors and all the block sized vectors pass. The non-block sized test vectors cannot pass since our cryptodev implementation only allows block sized requests. Thanks to Mike Hamburg for help and advice in making the AES-XTS algorithm go really fast. The patch removes some assembly, and also replaces some hard coded instructions (as .byte values) to their proper instructions now that gcc can assemble them properly. The patch: https://people.freebsd.org/~jmg/aesni.new1.patch -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 19:12:10 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8B20AC83; Thu, 22 Aug 2013 19:12:10 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp11.one.com (csmtp11.one.com [195.47.247.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A6BB26F2; Thu, 22 Aug 2013 19:12:10 +0000 (UTC) Received: from [192.168.1.69] (unknown [176.222.238.90]) by csmtp11.one.com (Postfix) with ESMTPA id ED57EC03B6AC4; Thu, 22 Aug 2013 19:04:26 +0000 (UTC) Received: from [192.168.1.69] ([UNAVAILABLE]. [176.222.238.90]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/4.8.87); Thu, 22 Aug 2013 18:57:12 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: why does buildkernel set COMPILER_TYPE? From: Erik Cederstrand In-Reply-To: <20130822162353.GF94127@funkthat.com> Date: Thu, 22 Aug 2013 21:04:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822040418.GE94127@funkthat.com> <49A46D2E-D736-4D57-BB54-5B68C1FE2466@FreeBSD.org> <20130822162353.GF94127@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 22 Aug 2013 21:49:43 +0000 Cc: Brooks Davis , Dimitry Andric , 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, 22 Aug 2013 19:12:10 -0000 Den 22/08/2013 kl. 18.23 skrev John-Mark Gurney : >> I don't think we should support building different parts of the tree >> with incompatible settings. E.g. compiling part of the tree using >> WITH_FOO, and some other part using WITHOUT_FOO is *not* supposed to >> work properly. >=20 > Do we have a file that is source in /usr/src (or where your source = tree > is located) that we can put these options in? make buildworld SRCCONF=3D/foo/bar/custom.conf But if you doing all sorts of weird build configurations regularly, you = might want to just build within a jail that you can wipe afterwards, so = you don't pollute the host machine by accident. Erik From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 00:29:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0DC7B1AB; Fri, 23 Aug 2013 00:29:37 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B74672116; Fri, 23 Aug 2013 00:29:36 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7N0TPi5055361; Thu, 22 Aug 2013 20:29:31 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5216ACE5.7000500@m5p.com> Date: Thu, 22 Aug 2013 20:29:25 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org, Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> In-Reply-To: <5215F743.8060403@bitfrost.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Thu, 22 Aug 2013 20:29:32 -0400 (EDT) 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, 23 Aug 2013 00:29:37 -0000 On 08/22/13 07:34, Hans Petter Selasky wrote: > On 08/22/13 13:24, George Mitchell wrote: >> As I was saying a few minutes ago ... >> >> On 01/27/13 17:32, George Mitchell wrote: >>> On 01/27/13 14:07, Hans Petter Selasky wrote: >>>> [...] I need output when hw.usb.ulpt.debug=15 to say exactly. >>>> Could you >>>> ask the provider of the binaries to compile having USB_DEBUG set, also >>>> for the >>>> modules. >>>> >>>> --HPS >>>> >>> >>> I'm working on getting a debug build ... Thanks for your help so far. >>> I notice that there seem to be only trivial differences between the 9.1 >>> release ulpt and the 10.0 current ulpt driver. -- George >> >> (This is on a Raspberry Pi.) It took me a bit longer than anticipated, >> but here is the output, from an image built over last weekend: > > Hi, > > Could you run: > > usbdump -i usbusX -f Y -s 65536 > > To get a dump of the USB activity when you plug the device? The message > in question is not important, and might be changed to not cancel the > ulpt attach routine. > > --HPS > > _______________________________________________ > 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" Here's the result: root@pi:/ # usbdump -i usbus0 -f 4 -s 65536 00:26:01.592494 usbus0.4 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=8,IVAL=0 00:26:01.593117 usbus0.4 DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 00:26:01.593209 usbus0.4 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0 00:26:01.594146 usbus0.4 DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 00:26:01.611621 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.614223 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 00:26:01.614730 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.617595 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 00:26:01.617758 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.620216 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.620313 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.622219 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.622326 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.624208 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.624305 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.631722 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=16,IVAL=0,ERR=0 00:26:01.631925 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.634217 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.634315 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.637220 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=44,IVAL=0,ERR=0 00:26:01.637334 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.639214 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.639312 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.641585 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=28,IVAL=0,ERR=0 00:26:01.641769 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.644209 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=12,IVAL=0,ERR=0 00:26:01.644316 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.651213 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=32,IVAL=0,ERR=0 00:26:01.651316 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.653219 usbus0.4 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.653321 usbus0.4 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=8,IVAL=0 00:26:01.654584 usbus0.4 DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 (at which point if I type control-c to stop usbdump, the system gets a fatal kernel mode translation fault, but that's another story.) Hope this helps. -- George From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 06:16: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C360F4E; Fri, 23 Aug 2013 06:16:58 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id AE0DE2F58; Fri, 23 Aug 2013 06:16:57 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 8D42E7A1E8; Fri, 23 Aug 2013 08:16:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id F240E8EF99C; Fri, 23 Aug 2013 08:17:06 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCv327Bv5fbc; Fri, 23 Aug 2013 08:17:06 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id E38668EF99B; Fri, 23 Aug 2013 08:17:05 +0200 (CEST) Message-ID: <5216FE9F.2030608@bitfrost.no> Date: Fri, 23 Aug 2013 08:18:07 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: George Mitchell Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> In-Reply-To: <5216ACE5.7000500@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@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: Fri, 23 Aug 2013 06:16:58 -0000 On 08/23/13 02:29, George Mitchell wrote: > On 08/22/13 07:34, Hans Petter Selasky wrote: > Here's the result: > > root@pi:/ # usbdump -i usbus0 -f 4 -s 65536 > 00:26:01.592494 usbus0.4 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=8,IVAL=0 > 00:26:01.593117 usbus0.4 > DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 > 00:26:01.593209 usbus0.4 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0 > 00:26:01.594146 usbus0.4 > DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 > 00:26:01.611621 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.614223 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 > 00:26:01.614730 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.617595 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 > 00:26:01.617758 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.620216 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 > 00:26:01.620313 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.622219 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 > 00:26:01.622326 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.624208 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 > 00:26:01.624305 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.631722 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=16,IVAL=0,ERR=0 > 00:26:01.631925 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.634217 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 > 00:26:01.634315 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.637220 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=44,IVAL=0,ERR=0 > 00:26:01.637334 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.639214 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 > 00:26:01.639312 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.641585 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=28,IVAL=0,ERR=0 > 00:26:01.641769 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.644209 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=12,IVAL=0,ERR=0 > 00:26:01.644316 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.651213 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=32,IVAL=0,ERR=0 > 00:26:01.651316 usbus0.4 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > 00:26:01.653219 usbus0.4 > DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 > 00:26:01.653321 usbus0.4 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=8,IVAL=0 > 00:26:01.654584 usbus0.4 > DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 > > (at which point if I type control-c to stop usbdump, the system gets a > fatal kernel mode translation fault, but that's another story.) Hope > this helps. -- George I would expect to see some messages ERR != 0 when you plug the device. Can you show both usbdump output and dmesg output which belongs together? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 08:16:51 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22982402 for ; Fri, 23 Aug 2013 08:16:51 +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 749B02516 for ; Fri, 23 Aug 2013 08:16:50 +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 LAA26214 for ; Fri, 23 Aug 2013 11:16:42 +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 1VCmXy-000PDt-EI for freebsd-current@FreeBSD.org; Fri, 23 Aug 2013 11:16:42 +0300 Message-ID: <52171A46.5080101@FreeBSD.org> Date: Fri, 23 Aug 2013 11:16:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: FreeBSD Current Subject: problem building stable/{9,8} toolchains on head 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: Fri, 23 Aug 2013 08:16:51 -0000 I am trying to build stable/{9,8} GENERIC kernels on a recent-ish head system (cc is clang). To be sure I first try to build the respective tool-chains using the following process: 1. make make 2. /usr/obj/path/to/make toolchain WITHOUT_CLANG=1 NO_WERROR=yes WERROR= WERROR stuff is to increase chances of a successful build. I am getting the following errors though. stable/9: building shared library libc.so.7 /usr/bin/ld: cap_getrights.So: relocation R_X86_64_32S against `SYS_cap_getrights' can not be used when making a shared object; recompile with -fPIC stable/8: cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -march=amdfam10 -I/usr/devel/svn/base/stable/8/lib/libc/include -I/usr/devel/svn/base/stable/8/lib/libc/../../include -I/usr/devel/svn/base/stable/8/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/devel/svn/base/stable/8/lib/libc/../../contrib/gdtoa -I/usr/obj/usr/devel/svn/base/stable/8/lib/libc -I/usr/devel/svn/base/stable/8/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -DMALLOC_PRODUCTION -I/usr/devel/svn/base/stable/8/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/devel/svn/base/stable/8/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c syscall.S /usr/devel/svn/base/stable/8/lib/libc/include/compat.h:41:38: error: expected a '@' in the name .symver freebsd7___semctl , __semctl @ FBSD_1.0; ^ /usr/devel/svn/base/stable/8/lib/libc/include/compat.h:42:34: error: expected a '@' in the name .symver freebsd7_msgctl , msgctl @ FBSD_1.0; ^ /usr/devel/svn/base/stable/8/lib/libc/include/compat.h:43:34: error: expected a '@' in the name .symver freebsd7_shmctl , shmctl @ FBSD_1.0; ^ I would appreciate any help with getting this straightened. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 09:10:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 151E44B7 for ; Fri, 23 Aug 2013 09:10:18 +0000 (UTC) (envelope-from VenkatKumar.Duvvuru@Emulex.Com) Received: from CMEXEDGE1.ext.emulex.com (cmexedge1.ext.emulex.com [138.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB8F927F9 for ; Fri, 23 Aug 2013 09:10:17 +0000 (UTC) Received: from CMEXHTCAS2.ad.emulex.com (138.239.115.218) by CMEXEDGE1.ext.emulex.com (138.239.224.99) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 23 Aug 2013 01:55:11 -0700 Received: from CMEXMB1.ad.emulex.com ([169.254.1.45]) by CMEXHTCAS2.ad.emulex.com ([::1]) with mapi id 14.03.0146.002; Fri, 23 Aug 2013 01:55:07 -0700 From: Venkata Duvvuru To: "freebsd-current@freebsd.org" Subject: OCE driver on Freebsd 10.0-Current Thread-Topic: OCE driver on Freebsd 10.0-Current Thread-Index: Ac6f3mpxjkESPAOQSjCR/g/xpHEsYg== Date: Fri, 23 Aug 2013 08:55:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [138.239.140.118] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: Fri, 23 Aug 2013 09:10:18 -0000 Hi, I'm running iperf on Emulex's OCE network adapter in Freebsd-10-current. At= heavy traffic (iperf with ~10 connections), iperf is hanging. The same dri= ver is working on all other Freebsd versions. top -HS shows the below information. PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 128K CPU4 4 146:36 100.00% idle{idle:= cpu4} 12 root -60 - 0K 688K CPU6 6 52:38 100.00% intr{swi4:= clock} 11 root 155 ki31 0K 128K CPU2 2 148:42 99.66% idle{idle: = cpu2} 11 root 155 ki31 0K 128K CPU7 7 149:24 99.27% idle{idle: = cpu7} 11 root 155 ki31 0K 128K RUN 0 148:00 99.27% idle{idle: = cpu0} 11 root 155 ki31 0K 128K CPU1 1 149:44 99.17% idle{idle: = cpu1} 11 root 155 ki31 0K 128K CPU5 5 148:46 99.17% idle{idle: = cpu5} 11 root 155 ki31 0K 128K CPU3 3 96:57 89.06% idle{idle: = cpu3} 11 root 155 ki31 0K 128K RUN 6 149:11 13.87% idle{idle: = cpu6} One interesting thing I observed is that intr is taking 100% on CPU6 when i= perf hangs, while iperf is running fine, the intr WCPU percentage is very l= ow. What does this below line mean? Why intr is 100% on CPU6?? 12 root -60 - 0K 688K CPU6 6 52:38 100.00% intr{swi4: cl= ock} /Venkat. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 09:17:07 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 67359659; Fri, 23 Aug 2013 09:17:07 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3F32867; Fri, 23 Aug 2013 09:17:06 +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 r7N9H2gs051621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 09:17:04 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_407EAE74-9C84-4000-8909-A8E10545B6F3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: patch to add AES intrinsics to gcc From: David Chisnall In-Reply-To: <20130822200902.GG94127@funkthat.com> Date: Fri, 23 Aug 2013 10:16:56 +0100 Message-Id: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1508) Cc: toolchain@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: Fri, 23 Aug 2013 09:17:07 -0000 --Apple-Mail=_407EAE74-9C84-4000-8909-A8E10545B6F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a patch that I intend to commit before the 10.0 code slush that = removes GCC and libstdc++ from the default build on platforms where = clang is the system compiler. We definitely don't want to be supporting = our 6-year-old versions of these for the lifetime of the 10.x branch. =20= David On 22 Aug 2013, at 21:09, John-Mark Gurney wrote: > In my work to get AES-NI performance in a better state and the fact > that we haven't deprecated gcc yet, I have developed another patch to > add the appropriate AES intrinstic headers to gcc. >=20 > The patch is available at: > https://people.freebsd.org/~jmg/gcc.aes.intrin.patch >=20 > I did have to change the opth-gen.awk script, since it wouldn't let > me use bit 31, and recent changes to gcc used up all the remaining > bits. I also was unable to add the -mpclmul option because of running > out of these bits. >=20 > Thanks. >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" --Apple-Mail=_407EAE74-9C84-4000-8909-A8E10545B6F3 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 iQIcBAEBAgAGBQJSFyiIAAoJEKx65DEEsqIdBDQP/0F0wPcrxwyybC45ON0WVUa5 3qGsXSQppYVl5NGXZI9UBROd1fIeQQjiCLFMwEBPVLWgnxC+91HIjTUXVR9zsd4z E2ze0BwPI26i+4tfvcFraLhbv4F7rjlp5hHwzHlPLyc5CgNv7w4U7jCCOBZ565J3 pTBz3IXgo7rFkXrfXFmGoX2yPD1v8xtoh22saAltfy6MgViROZbDD3nZhMqU7Mh4 HUOKdIwoBbmrnqC1o+5Pwza6v/4xs1z8wVXJoBl5ayI9BYk+UUXVCcnQQH1OIHUa lyVN5n3SWvuNnWGw+dLoQ85bydk5ZXyM4H/d+/rd8y7MioIdtJ4TC4+6JJJ9y8hH eDP9kekGu7triDJvRbvvZuurlwe90MUso0mswqUqsGLvR5aKAWQTTgqqMBJACW+n YdKuJn8gdIKRBhs2S5/KpyjhVFJxZfBOjvxjjg1iX2T12uYxEt0+Ssz6UI5Yok2Z SiwPvX+S1fDpJH6D9Dd8vh+Nj2TC2ntnKGyTliMpmv+NyWyF5DhqZqR1QN0kEhi2 yoLD+9ZJRMemKAdqcY9PDKnk+5qV6EOeswOP0k9xZnHx/wx8ibvIDkOhpVGR8hw8 UuYAyjGhTKFX0Al8pzZr1Bxgg50lO8ojvbUI+C22Qf6BrVFUaqF1FWuyhOWwI/jm NyJAW0itc3PmuW4mycMr =Hcyv -----END PGP SIGNATURE----- --Apple-Mail=_407EAE74-9C84-4000-8909-A8E10545B6F3-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 09:39:10 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6188AE59; Fri, 23 Aug 2013 09:39:10 +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 4C44C2978; Fri, 23 Aug 2013 09:39:08 +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 MAA27006; Fri, 23 Aug 2013 12:39:07 +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 1VCnpj-000PKi-6K; Fri, 23 Aug 2013 12:39:07 +0300 Message-ID: <52172D96.8090801@FreeBSD.org> Date: Fri, 23 Aug 2013 12:38:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Chisnall Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0__43183.8718745441$1377249444$gmane$org@FreeBSD.org> In-Reply-To: <105E26EE-8471-49D3-AB57-FBE2779CF8D0__43183.8718745441$1377249444$gmane$org@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: toolchain@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: Fri, 23 Aug 2013 09:39:10 -0000 on 23/08/2013 12:16 David Chisnall said the following: > I have a patch that I intend to commit before the 10.0 code slush that > removes GCC and libstdc++ from the default build on platforms where clang > is the system compiler. We definitely don't want to be supporting our > 6-year-old versions of these for the lifetime of the 10.x branch. I have an alternative proposal (to re@ and core@) to set WITHOUT_CLANG_IS_CC in stable/10 or at least releng/10.0. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 09:58:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B083F578 for ; Fri, 23 Aug 2013 09:58:55 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5FF492AAB for ; Fri, 23 Aug 2013 09:58:55 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id wc20so468266obb.28 for ; Fri, 23 Aug 2013 02:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=XEgJvnNR1IUQmRZhgrqYaA0FXiEyMvuqwnQGIDFw/q8=; b=f/CO8BWVUDy/7jH+vXg60uldMJwbvJqLGChFiPRW3mqHGe4BND8ZrcNleuOV0cN54T tUVUviF5fQXI91R0oZD1u40/FE/qT2GycTl5Ut6wylq4PcI7MnxtZGhpB8qKihBRa2fe 1QUHDovWEBC6f6z6gXQDpWsFIVOi7PnpVQiC4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XEgJvnNR1IUQmRZhgrqYaA0FXiEyMvuqwnQGIDFw/q8=; b=PWIPx//QPf56adIWOgRQs4cer319I037yc5OuBfZqt1PqZ2bQ6UFBD0LKPZMMFGnUp 6eK8kyD6F49511iAQBgH+jr8R1H0MTDFsc4bBVd9c/k+qVA3KelysfACBK6Es9DoThSS 9lNnwX3cex4eLxs+DfTWSZ0eyuZreLQ/5Sqxy3lXfTBBtJYxA+HmdQczGzzgHy0UXDY9 G3d7VMGFTXaKP7AeLTztLqzqsHszQ6aAf0NE/Qo8LotAoXi2L5GqXtzeoQKsnBlcs7lK nxyiSn3fGGXp7qi3n7sXVq3uXd4OFjB0OR65mp2jzFS+kKcdZbcKJxCgJIXCQB/3/I7x Ggpg== X-Gm-Message-State: ALoCoQm2mRTy8J0X/MJGrZbCdjqbP1999Fjaee8emK2g3l705UCWkOINWSLWaSfBQ7/ZakKnfAC9 MIME-Version: 1.0 X-Received: by 10.182.129.233 with SMTP id nz9mr19479518obb.8.1377251934542; Fri, 23 Aug 2013 02:58:54 -0700 (PDT) Sender: decke@bluelife.at Received: by 10.76.81.4 with HTTP; Fri, 23 Aug 2013 02:58:54 -0700 (PDT) X-Originating-IP: [80.123.233.199] In-Reply-To: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> Date: Fri, 23 Aug 2013 11:58:54 +0200 X-Google-Sender-Auth: jmT25XPIOmeQOuW9TJDRO5p_DIg Message-ID: Subject: Re: patch to add AES intrinsics to gcc From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: David Chisnall Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: toolchain@freebsd.org, John-Mark Gurney , 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, 23 Aug 2013 09:58:55 -0000 I don't know if you are aware that IF you really do that we will have serio= us problems to ship packages for 10. USE_GCC=3Dany is the fallback in the portstree for all ports that are unable to build with clang which was intro= duced when HEAD switched to clang as default cc. Right now there are 150 ports in the tree that use this fallback and quite a few of them are high profile po= rts: the highlights: audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 security/clamav the full list: http://dpaste.com/1354075/ A possible hack could be to add a check for USE_GCC=3Dany to behave like a USE_GCC=3Dyes on HEAD on the affected platforms. This pulls in lang/gcc from ports for a lot of people on HEAD I suppose. We certainly need to do that switch to remove the ancient gcc from base some time but with my portmgr hat on I can only say we don't plan to do tha= t before 10.0 especially not if we are only talking about a few weeks time wi= ndow. --=20 Bernhard Froehlich http://www.bluelife.at/ On Fri, Aug 23, 2013 at 11:16 AM, David Chisnall wro= te: > I have a patch that I intend to commit before the 10.0 code slush that re= moves GCC and libstdc++ from the default build on platforms where clang is = the system compiler. We definitely don't want to be supporting our 6-year-= old versions of these for the lifetime of the 10.x branch. > > David > > On 22 Aug 2013, at 21:09, John-Mark Gurney wrote: > >> In my work to get AES-NI performance in a better state and the fact >> that we haven't deprecated gcc yet, I have developed another patch to >> add the appropriate AES intrinstic headers to gcc. >> >> The patch is available at: >> https://people.freebsd.org/~jmg/gcc.aes.intrin.patch >> >> I did have to change the opth-gen.awk script, since it wouldn't let >> me use bit 31, and recent changes to gcc used up all the remaining >> bits. I also was unable to add the -mpclmul option because of running >> out of these bits. >> >> Thanks. >> >> -- >> John-Mark Gurney Voice: +1 415 225 5579 >> >> "All that I will do, has been done, All that I have, has not." >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.= org" From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 10:35:49 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD8DBCCF; Fri, 23 Aug 2013 10:35:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 983DA2C89; Fri, 23 Aug 2013 10:35:49 +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 r7NAZjLl052159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 10:35:46 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: patch to add AES intrinsics to gcc From: David Chisnall In-Reply-To: Date: Fri, 23 Aug 2013 11:35:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> To: =?iso-8859-1?Q?Bernhard_Fr=F6hlich?= X-Mailer: Apple Mail (2.1508) Cc: toolchain@FreeBSD.org, John-Mark Gurney , "re@FreeBSD.org Engineering Team" , 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, 23 Aug 2013 10:35:49 -0000 On 23 Aug 2013, at 10:58, Bernhard Fr=F6hlich wrote: > I don't know if you are aware that IF you really do that we will have = serious > problems to ship packages for 10. USE_GCC=3Dany is the fallback in the > portstree for all ports that are unable to build with clang which was = introduced > when HEAD switched to clang as default cc. Right now there are 150 = ports in > the tree that use this fallback and quite a few of them are high = profile ports: >=20 > the highlights: > audio/nas devel/mingw32-binutils emulators/qemu = emulators/virtualbox-ose > emulators/wine lang/go lang/v8 mail/courier math/fftw3 = multimedia/libxine > multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 > security/clamav >=20 > the full list: > http://dpaste.com/1354075/ >=20 > A possible hack could be to add a check for USE_GCC=3Dany to behave = like > a USE_GCC=3Dyes on HEAD on the affected platforms. This pulls in = lang/gcc > from ports for a lot of people on HEAD I suppose. >=20 > We certainly need to do that switch to remove the ancient gcc from = base > some time but with my portmgr hat on I can only say we don't plan to = do that > before 10.0 especially not if we are only talking about a few weeks = time window. That is unfortunate. We have said for over a year that 10.0 should not = ship with gcc. I can delay committing the patch to flip the switch = until later in the code slush, if re approves, but ports that require = gcc should be building with gcc from ports (which will also improve code = quality, as gcc 4.6/7 produce significantly better code than 4.2.1). David From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 10:42:33 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1F11AE90; Fri, 23 Aug 2013 10:42:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C63722CE9; Fri, 23 Aug 2013 10:42:32 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7NAgQVT015537 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 03:42:29 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <52173C8D.20608@freebsd.org> Date: Fri, 23 Aug 2013 18:42:21 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Chisnall Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> In-Reply-To: <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: toolchain@FreeBSD.org, John-Mark Gurney , =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= , current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 10:42:33 -0000 On 8/23/13 6:35 PM, David Chisnall wrote: > On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote: > >> I don't know if you are aware that IF you really do that we will have serious >> problems to ship packages for 10. USE_GCC=any is the fallback in the >> portstree for all ports that are unable to build with clang which was introduced >> when HEAD switched to clang as default cc. Right now there are 150 ports in >> the tree that use this fallback and quite a few of them are high profile ports: >> >> the highlights: >> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 >> security/clamav >> >> the full list: >> http://dpaste.com/1354075/ >> >> A possible hack could be to add a check for USE_GCC=any to behave like >> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc >> from ports for a lot of people on HEAD I suppose. >> >> We certainly need to do that switch to remove the ancient gcc from base >> some time but with my portmgr hat on I can only say we don't plan to do that >> before 10.0 especially not if we are only talking about a few weeks time window. > That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). no, I believe we have said that 10 would ship with clang by default. NO mention was made about gcc being absent, and I am uncomfortable with taking that step yet. Having gcc just present, will not hurt you.. even after it is gone we will need to support those who will be replacing clang with newer versions of gcc in hteir own products. > > David > > _______________________________________________ > 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 Aug 23 11:02:20 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E9B41429; Fri, 23 Aug 2013 11:02:20 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [IPv6:2a02:6b8:0:1819::4]) by mx1.freebsd.org (Postfix) with ESMTP id ABA2A2DF5; Fri, 23 Aug 2013 11:02:20 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward4l.mail.yandex.net (Yandex) with ESMTP id 377C9144105D; Fri, 23 Aug 2013 15:02:19 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id B6C101B608C4; Fri, 23 Aug 2013 15:02:18 +0400 (MSK) Received: from 93.91.10.81.tel.ru (93.91.10.81.tel.ru [93.91.10.81]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id RaB1TxKpTq-2IauTQRu; Fri, 23 Aug 2013 15:02:18 +0400 Message-ID: <5217413A.9080105@passap.ru> Date: Fri, 23 Aug 2013 15:02:18 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Chisnall Subject: GCC withdraw (was: Re: patch to add AES intrinsics to gcc) References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> In-Reply-To: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: toolchain@FreeBSD.org, John-Mark Gurney , 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, 23 Aug 2013 11:02:21 -0000 23.08.2013 13:16, David Chisnall пишет: > I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 11:06:15 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F1C759A; Fri, 23 Aug 2013 11:06:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E7132E20; Fri, 23 Aug 2013 11:06:14 +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 r7NB6Cmd052435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 11:06:13 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_25C04FD8-9B62-4151-9440-9259D8707223"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: patch to add AES intrinsics to gcc From: David Chisnall In-Reply-To: <52173C8D.20608@freebsd.org> Date: Fri, 23 Aug 2013 12:06:10 +0100 Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1508) Cc: toolchain@FreeBSD.org, John-Mark Gurney , =?iso-8859-1?Q?Bernhard_Fr=F6hlich?= , current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 11:06:15 -0000 --Apple-Mail=_25C04FD8-9B62-4151-9440-9259D8707223 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 23 Aug 2013, at 11:42, Julian Elischer wrote: > no, I believe we have said that 10 would ship with clang by default. = NO mention was made about gcc being absent, and I am uncomfortable with = taking that step yet. Having gcc just present, will not hurt you.. even = after it is gone we will need to support those who will be replacing = clang with newer versions of gcc in hteir own products. The plan is not to delete gcc from the tree, it is to disable building = gcc by default when clang is the system compiler. If you are building = products then you are perfectly at liberty to set WITH_GCC=3Dyes in your = src.conf. Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in = its atomic generation so you can't use it sensibly without lots of = inline assembly (which it doesn't support for newer architectures) for = multithreaded things. Our libstdc++ is ancient and doesn't work with modern C++ codebases. = Putting them in the base system means that people will use them. If = anyone wants them to remain, then speak now and this will be taken as = your volunteering to: - Maintain our forks of both gcc and libstdc++ - Handle every single PR that is filed by people using these If you are willing to do this, then that's great. If not, then you are = asking other people to support ancient codebases that they are not = using. David --Apple-Mail=_25C04FD8-9B62-4151-9440-9259D8707223 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 iQIcBAEBAgAGBQJSF0IiAAoJEKx65DEEsqId+k4P/RFwL2MtORKKi4copj9dKJ3r f/Uh7vfFAqFmk3w/itKSCVictHJngqSXhopXpo7PIRob7hh+pVkF1fUd7a69bJH5 XaTslr3zJeQGZBsZGdYGKHeDaX33Y2r7VSaqUrk8EJfJwNffzQbBWkUA0YIYC/Xh cmYh/3CIDclemBPgRH1GQR78n9yuf3yZK/r22HMr2aPS/YWGfn0MQiEbEL0OgsMP 7uOYmXpmXiTcrJQEaBb4chS0PT4vPC4PJKbaRDCyhzSy1CuIWJjjDPyWco4WB/RY ssBQo/g/AFlANYdkuLk+9T860oS93/eotnbPifux5zvjKCFpk3JZwclBJI35sclk syqLfZHwskvmWa8cA6IuGQNBgpbBmOfVK65HwTPQ9+B14aQ83euKI2PQywtFW/dp maMYs65dRfhDdazzytTzPqemRc9CZfqt0sV9qfpqAReDTiKTV2hfcY/UCkoy9+7F 2gICFQAWFPuod47TUyWb8v94zfCmgnZvhdtZkomZ3wxntYTt5A6cioDO8yIbhqrh wF65WCvffKMQa/J4JdvsaFAm07F0KLxJ/fdEaskqoh5UnfU3sFRiK2oAHloSBblt uK+b/847HM1NEH/f5pBiiIj2cT+ANl2cWR15n5YJEwUg02b/c+30iq5DFv5X3yYx Xh33KOvh35quLXx//8yg =ZDGR -----END PGP SIGNATURE----- --Apple-Mail=_25C04FD8-9B62-4151-9440-9259D8707223-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 11:12:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61DF375B; Fri, 23 Aug 2013 11:12:02 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 16C462E91; Fri, 23 Aug 2013 11:12:01 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7NBBqG4059850; Fri, 23 Aug 2013 07:11:58 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <52174378.2020101@m5p.com> Date: Fri, 23 Aug 2013 07:11:52 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> In-Reply-To: <5216FE9F.2030608@bitfrost.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Fri, 23 Aug 2013 07:11:58 -0400 (EDT) Cc: freebsd-arm@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: Fri, 23 Aug 2013 11:12:02 -0000 On 08/23/13 02:18, Hans Petter Selasky wrote: > On 08/23/13 02:29, George Mitchell wrote: >> On 08/22/13 07:34, Hans Petter Selasky wrote: > >> Here's the result: >> [...] >> (at which point if I type control-c to stop usbdump, the system gets a >> fatal kernel mode translation fault, but that's another story.) Hope >> this helps. -- George > > I would expect to see some messages ERR != 0 when you plug the device. > Can you show both usbdump output and dmesg output which belongs together? > > --HPS Not sure exactly how I would get the usbdump output and log output interspersed in the correct order, and the fact that the pi panics when I type control-C at usbdump doesn't help. Subjectively, the "ulpt0 attach returned 12" seemed to occur a fraction of a second later than the others. But I'll see what I can come up with this evening. -- George From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 11:16:51 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B4294956; Fri, 23 Aug 2013 11:16:51 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 715C62EDA; Fri, 23 Aug 2013 11:16:51 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VCpMF-000ECZ-Qc; Fri, 23 Aug 2013 13:16:47 +0200 Date: Fri, 23 Aug 2013 13:16:47 +0200 From: Kurt Jaeger To: current@FreeBSD.org Subject: Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc) Message-ID: <20130823111647.GT2951@home.opsec.eu> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5217413A.9080105@passap.ru> Cc: 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: Fri, 23 Aug 2013 11:16:51 -0000 Hi! > > I have a patch that I intend to commit before the 10.0 code > > slush that removes GCC and libstdc++ from the default build on > > platforms where clang is the system compiler. We definitely don't > > want to be supporting our 6-year-old versions of these for the > > lifetime of the 10.x branch. > > Isn't it a POLA violation? > > As for me I expect something like this: > . 9.x gcc default and clang in base; > . 10.x clang default and gcc in base; > . 11.x gcc withdraw. If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; -- pi@opsec.eu +49 171 3101372 7 years to go ! From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 11:21:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D6674B14 for ; Fri, 23 Aug 2013 11:21:56 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 955BF2F28 for ; Fri, 23 Aug 2013 11:21:56 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id uz19so538290obc.35 for ; Fri, 23 Aug 2013 04:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=S1ff7/DtEv5fO5qrDfQjqbn3G4f0VR8bkrUbfhfUWR4=; b=H6Clcek0tOOOSo+K9T9wdHmvg4vSutrNgNF0wzQNCxWxDreUl/ZLcogclrjWaZ/nCT EO1WEp4BnRQsn/gH5Nii/22+HwGIb2/vjKfN+bje9GvKkpim8QGVeJY58XLXpEpmiVME Fg0VIWZ5eVe26YOWau3r+k8QQo3SbqKZI4PL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S1ff7/DtEv5fO5qrDfQjqbn3G4f0VR8bkrUbfhfUWR4=; b=A6d4PmMBph/w5UwlniVp7bGZ9TJ18u3Cxg28rBc13dGYs8+wFYZr6IwPB02TvkjirV dIhQO+wg3HVViT1SPEGjJzb9MOYDdOOD4aFXXreRHYhzu35P8Tuv6y34au5hkrgwjGQ2 GAJR3uc88/znqDwERm8AErZwajuFq7MQRlK7UAcHBdYQBJ0qSZHpIH8JTFfwQHl/3kvh HUvam+kG8/qRyUVLiXlgiDJ6U2GhCnT0UkT0pGMBwyTY0YwzcpXWET51N92d3TdKfFby qLEqwhJtWXVUg8XxqlHNXuVy5+lLLSTWBXSG5eL6uI/wEBR/M+5R+7jmEpDSVY2+8Eo2 I/kg== X-Gm-Message-State: ALoCoQn5UbWUsVUx1pgT5BzwzGXRpfy2bVG+vQj+IdE5kQE3D2lb4N4xmNk6koEPS+6TvqZrR3kd MIME-Version: 1.0 X-Received: by 10.60.62.101 with SMTP id x5mr19638756oer.24.1377256915806; Fri, 23 Aug 2013 04:21:55 -0700 (PDT) Sender: decke@bluelife.at Received: by 10.76.81.4 with HTTP; Fri, 23 Aug 2013 04:21:55 -0700 (PDT) X-Originating-IP: [80.123.233.199] In-Reply-To: <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> Date: Fri, 23 Aug 2013 13:21:55 +0200 X-Google-Sender-Auth: 6SmX1HAo4Echz8lO4wP7i5EH7Wo Message-ID: Subject: Re: patch to add AES intrinsics to gcc From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: David Chisnall Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: toolchain@freebsd.org, John-Mark Gurney , "re@FreeBSD.org Engineering Team" , 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, 23 Aug 2013 11:21:57 -0000 On Fri, Aug 23, 2013 at 12:35 PM, David Chisnall wro= te: > On 23 Aug 2013, at 10:58, Bernhard Fr=F6hlich wrote: > >> I don't know if you are aware that IF you really do that we will have se= rious >> problems to ship packages for 10. USE_GCC=3Dany is the fallback in the >> portstree for all ports that are unable to build with clang which was in= troduced >> when HEAD switched to clang as default cc. Right now there are 150 ports= in >> the tree that use this fallback and quite a few of them are high profile= ports: >> >> the highlights: >> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxin= e >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 >> security/clamav >> >> the full list: >> http://dpaste.com/1354075/ >> >> A possible hack could be to add a check for USE_GCC=3Dany to behave like >> a USE_GCC=3Dyes on HEAD on the affected platforms. This pulls in lang/gc= c >> from ports for a lot of people on HEAD I suppose. >> >> We certainly need to do that switch to remove the ancient gcc from base >> some time but with my portmgr hat on I can only say we don't plan to do = that >> before 10.0 especially not if we are only talking about a few weeks time= window. > > That is unfortunate. We have said for over a year that 10.0 should not s= hip with gcc. I can delay committing the patch to flip the switch until la= ter in the code slush, if re approves, but ports that require gcc should be= building with gcc from ports (which will also improve code quality, as gcc= 4.6/7 produce significantly better code than 4.2.1). I have asked the question of "when will gcc be removed from base" multiple times over the last year and I got varying results back with the majority s= aying "after 10". I'm just trying to say that It looks like some people in src also don't expect it to be removed in 10. Anyway bapt already did some testing without gcc in base on HEAD and the results were bad but not totally awful. We will see if we can fix the most important ones in time before 10 but we can't promise anything. If someone wants to have a look at the failures with no gcc in base on HEAD= : http://pb2.nyi.freebsd.org/bulk/nogcc-default/2013-08-04_01h01m20s/ (this also includes HEAD failures caused by clang) --=20 Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 11:22:28 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D8EDFC4E; Fri, 23 Aug 2013 11:22:28 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC692F3C; Fri, 23 Aug 2013 11:22:28 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 6911F1A40D8B; Fri, 23 Aug 2013 15:22:27 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 0F6751B41643; Fri, 23 Aug 2013 15:22:26 +0400 (MSK) Received: from 93.91.10.81.tel.ru (93.91.10.81.tel.ru [93.91.10.81]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id pXTbhHIe95-MQtGVhhe; Fri, 23 Aug 2013 15:22:26 +0400 To: undisclosed-recipients:; Message-ID: <521745F2.8050607@passap.ru> Date: Fri, 23 Aug 2013 15:22:26 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> In-Reply-To: <20130823111647.GT2951@home.opsec.eu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: toolchain@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: Fri, 23 Aug 2013 11:22:28 -0000 23.08.2013 15:16, Kurt Jaeger пишет: > Hi! > >>> I have a patch that I intend to commit before the 10.0 code >>> slush that removes GCC and libstdc++ from the default build on >>> platforms where clang is the system compiler. We definitely don't >>> want to be supporting our 6-year-old versions of these for the >>> lifetime of the 10.x branch. >> >> Isn't it a POLA violation? >> >> As for me I expect something like this: >> . 9.x gcc default and clang in base; >> . 10.x clang default and gcc in base; >> . 11.x gcc withdraw. > > If the 150 ports that only work with gcc, all work with a ports > gcc and do not need the gcc from base, would the following be OK ? > > - 9.x gcc default and clang in base; > - 10.x clang default and gcc in ports; Well, we write rules and we brake them. ;-) Just say that we know we brake them but it's inevitable because... And go futher. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 06:27: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 894D31C4; Fri, 23 Aug 2013 06:27:59 +0000 (UTC) (envelope-from vitja.makarov@gmail.com) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 359992FCA; Fri, 23 Aug 2013 06:27:59 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hz10so171528vcb.12 for ; Thu, 22 Aug 2013 23:27: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 :content-type; bh=OXLN54b7Mcjn9/HXNA6zkxh2Vc3usNd2IGN6GHykjdc=; b=dk2qJBP+aCsBL6rTRc5y3XW4ncgbAz/hKmLzGJSmWlNG8jE07t/P4w4N61cRXoLbdj X4ApTRkPcK1DqcgVk8OIhGbXpDNmDAFhHpVrTPx6c2eXi0cQaRivBPKUxr4xWgSTiADj /sgRh8MoWwEPLYqce7wmFQIXV1AOuiE/KCDgy6Wm/BxfknHqmMPSU07AqkWiQ8qsSPRE FanuIb4OLTRK0XAQmMNJxZG9u9F8iAN6bgAXHCz2Ub8lXfMVk3ELcHuSbjoWKE/7uR37 DwfJgTfD/f4+tQebt1T7eaQrZYM3sx+BwhSb/5tXib0GkEPeqExsUkC6WstSJSYBsmMB 4dFA== MIME-Version: 1.0 X-Received: by 10.58.118.130 with SMTP id km2mr14970517veb.0.1377239278177; Thu, 22 Aug 2013 23:27:58 -0700 (PDT) Received: by 10.52.27.51 with HTTP; Thu, 22 Aug 2013 23:27:58 -0700 (PDT) In-Reply-To: <201308221408.08203.jhb@freebsd.org> References: <201308211401.46468.jhb@freebsd.org> <201308221408.08203.jhb@freebsd.org> Date: Fri, 23 Aug 2013 10:27:58 +0400 Message-ID: Subject: Re: Question about socket timeouts From: Vitja Makarov To: John Baldwin , freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=089e013a05acf25bb004e4978110 X-Mailman-Approved-At: Fri, 23 Aug 2013 11:26:06 +0000 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: Fri, 23 Aug 2013 06:27:59 -0000 --089e013a05acf25bb004e4978110 Content-Type: text/plain; charset=ISO-8859-1 2013/8/22 John Baldwin : > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote: >> 2013/8/21 John Baldwin : >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote: >> >> >> >> > Yes! Please file a PR! >> >> >> >> This sorta implies that both are acceptable (although, >> >> the Linux behavior seems more desirable). >> >> >> >> http://austingroupbugs.net/view.php?id=369 >> > >> > No, that says "round up", so it does mean that the requested timeout >> > should be the minimum amount slept. tvtohz() does this. Really odd >> > that the socket code is using its own version of this rather than >> > tvtohz(). >> > >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps getting >> > bug fixes in its history that simply using tvtohz() would have solved. >> > >> > Try this: >> > >> > Index: uipc_socket.c >> > =================================================================== >> > --- uipc_socket.c (revision 254570) >> > +++ uipc_socket.c (working copy) >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt) >> > if (error) >> > goto bad; >> > >> > - /* assert(hz > 0); */ >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz || >> > tv.tv_usec < 0 || tv.tv_usec >= 1000000) { >> > error = EDOM; >> > goto bad; >> > } >> > - /* assert(tick > 0); */ >> > - /* assert(ULONG_MAX - INT_MAX >= 1000000); */ >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; >> > - if (val > INT_MAX) { >> > + val = tvtohz(&tv); >> > + if (val == INT_MAX) { >> > error = EDOM; >> > goto bad; >> > } >> > - if (val == 0 && tv.tv_usec != 0) >> > - val = 1; >> > >> > switch (sopt->sopt_name) { >> > case SO_SNDTIMEO: >> > >> >> That must help. But I want to see the issue solved in the next >> release. I can't apply patch to the production system. Btw in >> production environment we have kern.hz set to 1000 so it's not a >> problem there. > > Can you test this in some way in a test environment? > Ok, sorry for posting out of the list. Simple test program is attached. Without your patch timeout expires in about 20ms. With it it's ~40ms. 40 instead of 30 is beacuse of odd tick added by tvtohz(). -- vitja. --089e013a05acf25bb004e4978110-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 11:44:29 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 89318357; Fri, 23 Aug 2013 11:44:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 44E2E20C9; Fri, 23 Aug 2013 11:44:29 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VCpp5-000H4z-AK; Fri, 23 Aug 2013 15:46:35 +0400 Date: Fri, 23 Aug 2013 15:46:35 +0400 From: Slawa Olhovchenkov To: Julian Elischer Subject: Re: patch to add AES intrinsics to gcc Message-ID: <20130823114635.GB64913@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52173C8D.20608@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "re@FreeBSD.org Engineering Team" , current@FreeBSD.org, John-Mark Gurney , David Chisnall , toolchain@FreeBSD.org, Bernhard Fr?hlich 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, 23 Aug 2013 11:44:29 -0000 On Fri, Aug 23, 2013 at 06:42:21PM +0800, Julian Elischer wrote: > On 8/23/13 6:35 PM, David Chisnall wrote: > > On 23 Aug 2013, at 10:58, Bernhard Fr?hlich wrote: > > > >> I don't know if you are aware that IF you really do that we will have serious > >> problems to ship packages for 10. USE_GCC=any is the fallback in the > >> portstree for all ports that are unable to build with clang which was introduced > >> when HEAD switched to clang as default cc. Right now there are 150 ports in > >> the tree that use this fallback and quite a few of them are high profile ports: > >> > >> the highlights: > >> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose > >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine > >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 > >> security/clamav > >> > >> the full list: > >> http://dpaste.com/1354075/ > >> > >> A possible hack could be to add a check for USE_GCC=any to behave like > >> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc > >> from ports for a lot of people on HEAD I suppose. > >> > >> We certainly need to do that switch to remove the ancient gcc from base > >> some time but with my portmgr hat on I can only say we don't plan to do that > >> before 10.0 especially not if we are only talking about a few weeks time window. > > That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). > no, I believe we have said that 10 would ship with clang by default. 10 from this winner have broken firewire code when building by clang -- cannot resume from sleep. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 11:54:20 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5F1DF5CE; Fri, 23 Aug 2013 11:54:20 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE70D214B; Fri, 23 Aug 2013 11:54:19 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [193.68.6.1]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.6/8.14.6) with ESMTP id r7NBrr9I011536 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 14:53:54 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <52174D51.2050601@digsys.bg> Date: Fri, 23 Aug 2013 14:53:53 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130812 Thunderbird/17.0.8 MIME-Version: 1.0 To: Kurt Jaeger Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> In-Reply-To: <20130823111647.GT2951@home.opsec.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: toolchain@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: Fri, 23 Aug 2013 11:54:20 -0000 On 23.08.13 14:16, Kurt Jaeger wrote: > Hi! > >>> I have a patch that I intend to commit before the 10.0 code >>> slush that removes GCC and libstdc++ from the default build on >>> platforms where clang is the system compiler. We definitely don't >>> want to be supporting our 6-year-old versions of these for the >>> lifetime of the 10.x branch. >> Isn't it a POLA violation? >> >> As for me I expect something like this: >> . 9.x gcc default and clang in base; >> . 10.x clang default and gcc in base; >> . 11.x gcc withdraw. > If the 150 ports that only work with gcc, all work with a ports > gcc and do not need the gcc from base, would the following be OK ? > > - 9.x gcc default and clang in base; > - 10.x clang default and gcc in ports; > I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. For many of the "important" ports, they do get used together with other ports that already require newer gcc from ports anyway. So no additional pollution will be created. Daniel From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 11:55:48 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1346C705; Fri, 23 Aug 2013 11:55:48 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CC34E215E; Fri, 23 Aug 2013 11:55:47 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1F5323AE30; Fri, 23 Aug 2013 11:55:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r7NBtexF021415; Fri, 23 Aug 2013 11:55:40 GMT (envelope-from phk@phk.freebsd.dk) To: Daniel Kalchev Subject: Re: GCC withdraw In-reply-to: <52174D51.2050601@digsys.bg> From: "Poul-Henning Kamp" References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <52174D51.2050601@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 23 Aug 2013 11:55:40 +0000 Message-ID: <21414.1377258940@critter.freebsd.dk> Cc: toolchain@FreeBSD.org, Kurt Jaeger , 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, 23 Aug 2013 11:55:48 -0000 In message <52174D51.2050601@digsys.bg>, Daniel Kalchev writes: >> - 9.x gcc default and clang in base; >> - 10.x clang default and gcc in ports; > >I believe this is the best idea so far. As long as these ports work with >gcc in ports, that is. +1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 12:12:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C2579D28; Fri, 23 Aug 2013 12:12:37 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB28B2290; Fri, 23 Aug 2013 12:12:36 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id eo20so419871lab.3 for ; Fri, 23 Aug 2013 05:12:34 -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:newsgroups:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GrME/9gpdIKS9OLal7SsZMmGtskhONsAHgUvi4rSY4U=; b=c5+wzu0RzitbEzQE2x75FJJOqYZvULeWhIupsOQAtOAmPaD49Grds4CS37YeFLwiau FFNj5J5mQh+WcjDqtR1CtPeE0Au6nO4A4xdd6FmjsqjSYPBBr4QdGK5dULzDb4Tjzu+f ZxQ4TJbu2mouAFnpD4e46JzegoROsxiPWdA9HzKz3yFidbxDgt9Q2n1m6mvXERzeXBGk 2KukSCJaBu1ZcoVGY0Ynmjs07rAs+vZE1LW9nT1o+XT0OQ4aXXs8IC6D/vHRoTxsNV/Q xhkFSI3b4cDrhumYjKkCp1QDx/9RJTapFKHn5lCZB12OxOxnHdqSU/WzNxKdacmJbs1p PRVw== X-Received: by 10.112.26.106 with SMTP id k10mr15655061lbg.27.1377259954401; Fri, 23 Aug 2013 05:12:34 -0700 (PDT) Received: from [192.168.1.128] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id b6sm6596332lae.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 05:12:33 -0700 (PDT) Message-ID: <521751AF.6040905@gmail.com> Date: Fri, 23 Aug 2013 15:12:31 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 Newsgroups: gmane.os.freebsd.current To: =?UTF-8?B?QmVybmhhcmQgRnLDtmhsaWNo?= Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: toolchain@freebsd.org, John-Mark Gurney , David Chisnall , 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, 23 Aug 2013 12:12:37 -0000 23.08.2013 12:58, Bernhard Fröhlich wrote: > I don't know if you are aware that IF you really do that we will have serious > problems to ship packages for 10. USE_GCC=any is the fallback in the > portstree for all ports that are unable to build with clang which was introduced > when HEAD switched to clang as default cc. Right now there are 150 ports in > the tree that use this fallback and quite a few of them are high profile ports: > > the highlights: > audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose > emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine > multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 > security/clamav > > the full list: > http://dpaste.com/1354075/ > > A possible hack could be to add a check for USE_GCC=any to behave like > a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc > from ports for a lot of people on HEAD I suppose. I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require strictly gcc 4.2.1 was bigger for me then number of ports that can't be compiled with clang but fill fine on lang/gcc. I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have that bad feeling... -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 12:17: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D5EB4EAC; Fri, 23 Aug 2013 12:17:07 +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 DF80B22E3; Fri, 23 Aug 2013 12:17:06 +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 PAA28123; Fri, 23 Aug 2013 15:17:05 +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 1VCqIa-000PWl-U7; Fri, 23 Aug 2013 15:17:04 +0300 Message-ID: <52175288.4090500@FreeBSD.org> Date: Fri, 23 Aug 2013 15:16:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: FreeBSD Current , freebsd-toolchain@FreeBSD.org Subject: stable/8 kernel-toolchain fails with clang on head 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: Fri, 23 Aug 2013 12:17:07 -0000 $ /usr/obj/usr/devel/svn/base/stable/8/make.amd64/make kernel-toolchain WITHOUT_CLANG=1 __MAKE_CONF=/dev/null SRCCONF=/dev/null ... cc -O2 -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/devel/svn/base/stable/8/tmp/usr\" -I/usr/obj/usr/devel/svn/base/stable/8/tmp/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/devel/svn/base/stable/8/tmp/legacy/usr/include -DTARGET_NAME=\"amd64-undermydesk-freebsd\" -c /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c In file included from /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:58: /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/output.h:123:6: warning: 'format' attribute argument not supported: __asm_fprintf__ [-Wignored-attributes] ATTRIBUTE_ASM_FPRINTF(2, 3); ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/output.h:113:53: note: expanded from macro 'ATTRIBUTE_ASM_FPRINTF' #define ATTRIBUTE_ASM_FPRINTF(m, n) __attribute__ ((__format__ (__asm_fprintf__, m, n))) ATTRIBUTE_NONNULL(m) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:542:1: error: redefinition of a 'extern inline' function 'floor_log2' is not supported in C99 mode floor_log2 (unsigned HOST_WIDE_INT x) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.h:174:1: note: previous definition is here floor_log2 (unsigned HOST_WIDE_INT x) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:577:1: error: redefinition of a 'extern inline' function 'exact_log2' is not supported in C99 mode exact_log2 (unsigned HOST_WIDE_INT x) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.h:180:1: note: previous definition is here exact_log2 (unsigned HOST_WIDE_INT x) ^ 1 warning and 2 errors generated. *** Error code 1 Stop in /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int. It seems that the problem is specific to stable/8 and is caused by missing -std=gnu89. And that seems to be caused by -DNO_WARNS that is used for toolchain target. Dependency between NO_WARNS and CSTD was removed in r198335 + r198365, but those were never MFC-ed. What do you think? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 12:26:53 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75FE614B; Fri, 23 Aug 2013 12:26:53 +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 00C212370; Fri, 23 Aug 2013 12:26:51 +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 PAA28175; Fri, 23 Aug 2013 15:26:50 +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 1VCqS1-000PXV-Vv; Fri, 23 Aug 2013 15:26:50 +0300 Message-ID: <521754E6.3030906@FreeBSD.org> Date: Fri, 23 Aug 2013 15:26:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Chisnall Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 12:26:53 -0000 on 23/08/2013 14:06 David Chisnall said the following: > Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its > atomic generation so you can't use it sensibly without lots of inline > assembly (which it doesn't support for newer architectures) for > multithreaded things. > > Our libstdc++ is ancient and doesn't work with modern C++ codebases. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. I do not care about C11, C++11 and modern C++ codebases. I care about what's in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, of course. But, OTOH, those who care modern C++ codebases should be perfectly capable to install a compiler from ports or switch to clang as their default compiler. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 12:30:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 96FDF3F7 for ; Fri, 23 Aug 2013 12:30:05 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BDCE23C5 for ; Fri, 23 Aug 2013 12:30:05 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id er7so602163obc.17 for ; Fri, 23 Aug 2013 05:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PHkkYJktgpAWS5S8TgXZ2OJ1HNVMu1h3SM3eHgbQ2Iw=; b=RWfG8Wd0P8bgzrgRRkHXs4iJGu4XLw/FR5DpMGTZG4AJDaLsopju13LpoOf31CVYYl /RmffvjwzC3WrXIx5OXFXBjkx/QXSiN0IcQloMdntHui1IkXlrxJmf3pQXmpOi5vur4k +H12cG+oNcrQCLcQu/Ijnd2Vk9LN9iPxFmoFs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PHkkYJktgpAWS5S8TgXZ2OJ1HNVMu1h3SM3eHgbQ2Iw=; b=pyIOEg/WIuSAaUyVR3AlzFfRp09C7rWqnc5I7FJxKrOJHNUQUBfD8nqknAp6djaNS1 Hz7+xva6R3PtMc8DUN7qwFMrkeem9XDm4ee+rMkGAX4ts/b3eEaCG7B7KelFocjh8b9a XboChM6lkKBxo7YYB3qtqqXmGb13FZSmJLuZOPqjGJBZ5JwEtyKaqt7CVtydFi54xKcJ uoFNdTbQXSprvix8bPTPqr86r1IeWNaOBBAo/xFFkLueP/SnEqpzgfoXE7+doZZD3Vf2 1PrnTUtsqqMdWofQBrVBW4C2jU8Pj1WDFMTHRrmGJN83uuqQgFzh0r+OQ6/SeIYKtNnn 7D9Q== X-Gm-Message-State: ALoCoQkTkkZyQmrDZo5CUWuH3wtlaP6trUCeFOpHbABz5HXVasCssWZHotKqpgA386z15P1FiYnQ MIME-Version: 1.0 X-Received: by 10.60.96.131 with SMTP id ds3mr19970126oeb.50.1377261004641; Fri, 23 Aug 2013 05:30:04 -0700 (PDT) Sender: decke@bluelife.at Received: by 10.76.81.4 with HTTP; Fri, 23 Aug 2013 05:30:04 -0700 (PDT) X-Originating-IP: [80.123.233.199] In-Reply-To: <521751AF.6040905@gmail.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> Date: Fri, 23 Aug 2013 14:30:04 +0200 X-Google-Sender-Auth: 4ZE8jCkaOytDbirNvPHfWCj8CbM Message-ID: Subject: Re: patch to add AES intrinsics to gcc From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: Volodymyr Kostyrko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: toolchain@freebsd.org, John-Mark Gurney , David Chisnall , 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, 23 Aug 2013 12:30:05 -0000 On Fri, Aug 23, 2013 at 2:12 PM, Volodymyr Kostyrko wro= te: > 23.08.2013 12:58, Bernhard Fr=F6hlich wrote: >> >> I don't know if you are aware that IF you really do that we will have >> serious >> problems to ship packages for 10. USE_GCC=3Dany is the fallback in the >> portstree for all ports that are unable to build with clang which was >> introduced >> when HEAD switched to clang as default cc. Right now there are 150 ports >> in >> the tree that use this fallback and quite a few of them are high profile >> ports: >> >> the highlights: >> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxin= e >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 >> security/clamav >> >> the full list: >> http://dpaste.com/1354075/ >> >> A possible hack could be to add a check for USE_GCC=3Dany to behave like >> a USE_GCC=3Dyes on HEAD on the affected platforms. This pulls in lang/gc= c >> from ports for a lot of people on HEAD I suppose. > > > I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compil= ed > with lang/gcc. I checked this once and the number of ports that require > strictly gcc 4.2.1 was bigger for me then number of ports that can't be > compiled with clang but fill fine on lang/gcc. > > I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have > that bad feeling... lang/gcc42 is on the list of ports that have USE_GCC=3Dany. So you would ne= ed to fix it first to be able to compile it with clang 3.3 from base. We are not trying to build everything with lang/gcc but just the ports that= have USE_GCC=3Dany in their Makefile. Per default all ports are still build with= cc from base so clang 3.3 on HEAD. --=20 Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 12:30:24 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 346A75E1; Fri, 23 Aug 2013 12:30:24 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 036B923D5; Fri, 23 Aug 2013 12:30:23 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VCqVN-000BI1-H1; Fri, 23 Aug 2013 12:30:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7NCUEgj047736; Fri, 23 Aug 2013 06:30:14 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX198vgJNMPScdGx8zzc2racG Subject: Re: patch to add AES intrinsics to gcc From: Ian Lepore To: David Chisnall In-Reply-To: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Aug 2013 06:30:14 -0600 Message-ID: <1377261014.1111.43.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "re@FreeBSD.org Engineering Team" , current@FreeBSD.org, Bernhard =?ISO-8859-1?Q?Fr=F6hlich?= , John-Mark Gurney , 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: Fri, 23 Aug 2013 12:30:24 -0000 On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote: > On 23 Aug 2013, at 11:42, Julian Elischer wrote: > > > no, I believe we have said that 10 would ship with clang by default. NO mention was made about gcc being absent, and I am uncomfortable with taking that step yet. Having gcc just present, will not hurt you.. even after it is gone we will need to support those who will be replacing clang with newer versions of gcc in hteir own products. > > The plan is not to delete gcc from the tree, it is to disable building gcc by default when clang is the system compiler. If you are building products then you are perfectly at liberty to set WITH_GCC=yes in your src.conf. > > Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. > > Our libstdc++ is ancient and doesn't work with modern C++ codebases. Putting them in the base system means that people will use them. If anyone wants them to remain, then speak now and this will be taken as your volunteering to: > > - Maintain our forks of both gcc and libstdc++ > - Handle every single PR that is filed by people using these > > If you are willing to do this, then that's great. If not, then you are asking other people to support ancient codebases that they are not using. > > David > I don't understand, you start by pointing out that gcc will still be in the tree and usable, then you go on to point out that it it won't be supported or maintained unless someone volunteers to do that, and you seem to be doing your best to discourage anyone from volunteering. Doesn't that sort of moot the point that the source isn't being deleted? -- Ian From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 12:34:18 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3DB4B871; Fri, 23 Aug 2013 12:34:18 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E8EE241A; Fri, 23 Aug 2013 12:34:17 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MRZ00G00GOO9R00@smtpauth3.wiscmail.wisc.edu>; Fri, 23 Aug 2013 07:34:16 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.8.23.122421, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-67-185.dsl.mdsnwi.sbcglobal.net [76.208.67.185]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MRZ00I6JHL2MR00@smtpauth3.wiscmail.wisc.edu>; Fri, 23 Aug 2013 07:34:15 -0500 (CDT) Message-id: <521756C5.6050502@freebsd.org> Date: Fri, 23 Aug 2013 07:34:13 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 To: Andriy Gapon Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <521754E6.3030906@FreeBSD.org> In-reply-to: <521754E6.3030906@FreeBSD.org> Cc: toolchain@FreeBSD.org, David Chisnall , current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 12:34:18 -0000 On 08/23/13 07:26, Andriy Gapon wrote: > on 23/08/2013 14:06 David Chisnall said the following: >> Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its >> atomic generation so you can't use it sensibly without lots of inline >> assembly (which it doesn't support for newer architectures) for >> multithreaded things. >> >> Our libstdc++ is ancient and doesn't work with modern C++ codebases. > On the other hand these tools are perfect for building FreeBSD kernel and base. > Extrapolating my experience with base GCC I am very confident in it as a > FreeBSD development tool. > Extrapolating my experience with Clang I am not yet confident in it as a > FreeBSD development tool. > This isn't even true. As CPUs gain new features, the set of available intrinsics gets more and more ancient, requiring ever more patching, workarounds, and #ifdef. Just look at the original subject of this thread! We're just talking about the default of a make.conf setting here. Switching to clang is a long-term goal of the project for good reason. Other vendors (Apple, for instance) have made the plunge first. This seems like as good a time as any to do it. And if it goes wrong somehow, we have lots of BETAs and it is trivial to change back at any time. -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 12:56:17 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B9EC2FB5; Fri, 23 Aug 2013 12:56:17 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8457C2529; Fri, 23 Aug 2013 12:56:17 +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 r7NCuEDv054537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 12:56:15 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: patch to add AES intrinsics to gcc From: David Chisnall In-Reply-To: <521754E6.3030906@FreeBSD.org> Date: Fri, 23 Aug 2013 13:56:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <422728FC-CE88-4AEF-AD10-3BF8910A2109@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <521754E6.3030906@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1508) Cc: toolchain@FreeBSD.org, "re@FreeBSD.org Engineering Team" , 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, 23 Aug 2013 12:56:17 -0000 On 23 Aug 2013, at 13:26, Andriy Gapon wrote: > On the other hand these tools are perfect for building FreeBSD kernel = and base. > Extrapolating my experience with base GCC I am very confident in it as = a > FreeBSD development tool. > Extrapolating my experience with Clang I am not yet confident in it as = a > FreeBSD development tool. Nathan has already dealt with this. > I do not care about C11, C++11 and modern C++ codebases. I care about = what's > in /usr/src and what gets compiled by buildkernel/buildworld. That's = just me, > of course. But, OTOH, those who care modern C++ codebases should be = perfectly > capable to install a compiler from ports or switch to clang as their = default > compiler. So you don't want a working debugger? Our gdb doesn't work at all on = MIPS and barely works with code compiled with clang or a recent gcc. We = are planning on importing LLDB soon (Ed Maste has been working on it, = funded by the FreeBSD Foundation), and it is a C++11 code base. It will = not build with our gcc or with our libstdc++ (and, in fact, since it = uses the LLVM libraries, will require LLVM in base to link libc++).=20 Or perhaps you don't care about flattened device trees. The device tree = compiler that we have in base is written in C++ and contains numerous = occurrences of ugly code to make it work with old compilers. I will be = very happy to remove a load of hacks once C++11 support is available in = the base system (not for 10.0, as dtc is used on a lot of tier 2 archs = where gcc is still default). David From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 12:59:37 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 555331DA; Fri, 23 Aug 2013 12:59: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 A044A2551; Fri, 23 Aug 2013 12:59:35 +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 PAA28416; Fri, 23 Aug 2013 15:59: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 1VCqxh-000PaQ-Md; Fri, 23 Aug 2013 15:59:33 +0300 Message-ID: <52175C7E.4050201@FreeBSD.org> Date: Fri, 23 Aug 2013 15:58:38 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nathan Whitehorn Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <521754E6.3030906@FreeBSD.org> <521756C5.6050502@freebsd.org> In-Reply-To: <521756C5.6050502@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, David Chisnall , current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 12:59:37 -0000 on 23/08/2013 15:34 Nathan Whitehorn said the following: > On 08/23/13 07:26, Andriy Gapon wrote: >> on 23/08/2013 14:06 David Chisnall said the following: >>> Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its >>> atomic generation so you can't use it sensibly without lots of inline >>> assembly (which it doesn't support for newer architectures) for >>> multithreaded things. >>> >>> Our libstdc++ is ancient and doesn't work with modern C++ codebases. >> On the other hand these tools are perfect for building FreeBSD kernel and base. >> Extrapolating my experience with base GCC I am very confident in it as a >> FreeBSD development tool. >> Extrapolating my experience with Clang I am not yet confident in it as a >> FreeBSD development tool. >> > > This isn't even true. It's been true for me. > As CPUs gain new features, the set of available intrinsics > gets more and more ancient, requiring ever more patching, workarounds, and > #ifdef. Just look at the original subject of this thread! Yes. I am more comfortable with incremental changes. Bugs in those can be pinpointed quite easily and I do not affect those who don't use the new features. > We're just talking about the default of a make.conf setting here. Switching to > clang is a long-term goal of the project for good reason. I agree. > Other vendors (Apple, > for instance) have made the plunge first. This seems like as good a time as any > to do it. And if it goes wrong somehow, we have lots of BETAs and it is trivial > to change back at any time. I am totally comfortable with clang being default in head. I am also comfortable with gcc not being built by default in head. I am not yet comfortable with clang being default in a release. Even .0 one. JIMHO, it needs to age a little bit more. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:04:34 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C9809391; Fri, 23 Aug 2013 13:04:34 +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 839F325B8; Fri, 23 Aug 2013 13:04:33 +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 QAA28461; Fri, 23 Aug 2013 16:04:32 +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 1VCr2V-000Pb1-Mk; Fri, 23 Aug 2013 16:04:31 +0300 Message-ID: <52175DA7.7030908@FreeBSD.org> Date: Fri, 23 Aug 2013 16:03:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Chisnall Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <521754E6.3030906@FreeBSD.org> <422728FC-CE88-4AEF-AD10-3BF8910A2109@FreeBSD.org> In-Reply-To: <422728FC-CE88-4AEF-AD10-3BF8910A2109@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, "re@FreeBSD.org Engineering Team" , 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, 23 Aug 2013 13:04:34 -0000 on 23/08/2013 15:56 David Chisnall said the following: > So you don't want a working debugger? Our gdb doesn't work at all on MIPS > and barely works with code compiled with clang or a recent gcc. I am capable of using devel/gdb. Or do you mean kernel debugger? > We are > planning on importing LLDB soon (Ed Maste has been working on it, funded by > the FreeBSD Foundation), and it is a C++11 code base. It will not build with > our gcc or with our libstdc++ (and, in fact, since it uses the LLVM > libraries, will require LLVM in base to link libc++). There are multiple possible solutions to this issue. And note that I do support having clang in base and it being the default in head. > Or perhaps you don't care about flattened device trees. To be honest - no, I don't care about them. > The device tree > compiler that we have in base is written in C++ and contains numerous > occurrences of ugly code to make it work with old compilers. I will be very > happy to remove a load of hacks once C++11 support is available in the base > system (not for 10.0, as dtc is used on a lot of tier 2 archs where gcc is > still default). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:05:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B1CE44D2; Fri, 23 Aug 2013 13:05:38 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77F4E25CD; Fri, 23 Aug 2013 13:05:38 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::3c70:729f:ee6a:6ff6] (unknown [IPv6:2001:7b8:3a7:0:3c70:729f:ee6a:6ff6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C5AE65C43; Fri, 23 Aug 2013 15:05:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: stable/8 kernel-toolchain fails with clang on head From: Dimitry Andric In-Reply-To: <52175288.4090500@FreeBSD.org> Date: Fri, 23 Aug 2013 15:05:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52175288.4090500@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1508) 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: Fri, 23 Aug 2013 13:05:38 -0000 On Aug 23, 2013, at 14:16, Andriy Gapon wrote: > $ /usr/obj/usr/devel/svn/base/stable/8/make.amd64/make = kernel-toolchain > WITHOUT_CLANG=3D1 __MAKE_CONF=3D/dev/null SRCCONF=3D/dev/null ... > It seems that the problem is specific to stable/8 and is caused by = missing > -std=3Dgnu89. And that seems to be caused by -DNO_WARNS that is used = for > toolchain target. > Dependency between NO_WARNS and CSTD was removed in r198335 + r198365, = but those > were never MFC-ed. >=20 > What do you think? Yes, I agree those should be MFC'd to stable/8. -Dimitry From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:32:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1A5E04CC for ; Fri, 23 Aug 2013 13:32:43 +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 C5DEA276E for ; Fri, 23 Aug 2013 13:32:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAOJjF1KDaFve/2dsb2JhbABSCIM8UYMbvGOBNXSCJAEBAQQBAQEgBCcgCwUWDgoCAg0ZAikBCSYGCAcEARoCBIdvDKRMkjqBKY4ABIEFNAeCaIEuA5Ueg3WIfocvgzsgMoEEOQ X-IronPort-AV: E=Sophos;i="4.89,941,1367985600"; d="scan'208";a="46231534" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 23 Aug 2013 09:32:35 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 74654B3F4E; Fri, 23 Aug 2013 09:32:35 -0400 (EDT) Date: Fri, 23 Aug 2013 09:32:35 -0400 (EDT) From: Rick Macklem To: Slawa Olhovchenkov Message-ID: <1503899038.12819687.1377264755464.JavaMail.root@uoguelph.ca> In-Reply-To: <20130822133520.GA75880@zxy.spb.ru> Subject: Re: Diskless setup with NFS_V4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) 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, 23 Aug 2013 13:32:43 -0000 Slawa Olhovchenkov wrote: > Its posible use currentle FreeBSD on NFS_V4 root? > > Explain: > > pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel. > In this setup kernel can use only configured (established) nfs fh. > This is not allowed to switch version or some options. > > When pxeboot use TFTP (not NFS) kernel (in nfs/bootp_subr.c) do DHCP > discover and don't allow (in nfs/nfs_diskless.c:nfs_parse_options) > 'nfsv4' option. > > nfs/nfs_diskless.c:nfs_setup_diskless also initialy set > > nd3->root_args.flags = (NFSMNT_NFSV3 | NFSMNT_WSIZE | NFSMNT_RSIZE | > NFSMNT_RESVPORT); > > and don't allow 'nfsv4' option. > > Where I be wrong? > How I can use diskless setup with R/O root on NFS_V4 share? No. There are a couple of problems that would need to be resolved for an NFSv4 root fs to work. 1 - An NFSv4 mount needs a unique identifier for the client machine. It currently uses the host uuid, but that is filled in by a userland utility run from the root fs (ie. not available soon enough). Linux uses the ip host address for this, which I believe is bogus and inappropriate. 2 - Without the nfsuserd daemon running, there is currently no uid/gid<-->name mappings available. This might work, but there would be a lot of "file owned by nobody" situations that could cause problems. I suspect this can be fixed by hardwiring a few mappings (root, bin,...), but there is currently no code to do this. The Linux solution for this is to put the number in a string on the wire and the updated draft of RFC3530 (called rfc3530bis, not yet an RFC) allows this, so eventually this will be supported by most/all servers. Until 1 and 2 are resolved, doing an NFSv4 root fs mount is not practical. To be honest, I don't see a need for it, since I'm "old fashioned" and still believe that the root fs should be a small volume of critical system utilities only, so an NFSv3 mount of it should be sufficient. (ie. If /var and any other subtrees where files might get byte range locked are on separate volumes, I think it should be fine with a NFSv3 root fs mount, even without running rpc.lockd.) 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" > From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:38:02 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3B625661; Fri, 23 Aug 2013 13:38:02 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AB8727B0; Fri, 23 Aug 2013 13:38:01 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MRZ00E00HO64A00@smtpauth2.wiscmail.wisc.edu>; Fri, 23 Aug 2013 07:37:53 -0500 (CDT) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.8.23.123017, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-67-185.dsl.mdsnwi.sbcglobal.net [76.208.67.185]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MRZ001YKHR3TH00@smtpauth2.wiscmail.wisc.edu>; Fri, 23 Aug 2013 07:37:52 -0500 (CDT) Message-id: <5217579E.9000406@freebsd.org> Date: Fri, 23 Aug 2013 07:37:50 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 To: Ian Lepore Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <1377261014.1111.43.camel@revolution.hippie.lan> In-reply-to: <1377261014.1111.43.camel@revolution.hippie.lan> Cc: "re@FreeBSD.org Engineering Team" , current@FreeBSD.org, John-Mark Gurney , David Chisnall , 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: Fri, 23 Aug 2013 13:38:02 -0000 On 08/23/13 07:30, Ian Lepore wrote: > On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote: >> On 23 Aug 2013, at 11:42, Julian Elischer wrote: >> >>> no, I believe we have said that 10 would ship with clang by default. NO mention was made about gcc being absent, and I am uncomfortable with taking that step yet. Having gcc just present, will not hurt you.. even after it is gone we will need to support those who will be replacing clang with newer versions of gcc in hteir own products. >> The plan is not to delete gcc from the tree, it is to disable building gcc by default when clang is the system compiler. If you are building products then you are perfectly at liberty to set WITH_GCC=yes in your src.conf. >> >> Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. >> >> Our libstdc++ is ancient and doesn't work with modern C++ codebases. Putting them in the base system means that people will use them. If anyone wants them to remain, then speak now and this will be taken as your volunteering to: >> >> - Maintain our forks of both gcc and libstdc++ >> - Handle every single PR that is filed by people using these >> >> If you are willing to do this, then that's great. If not, then you are asking other people to support ancient codebases that they are not using. >> >> David >> > I don't understand, you start by pointing out that gcc will still be in > the tree and usable, then you go on to point out that it it won't be > supported or maintained unless someone volunteers to do that, and you > seem to be doing your best to discourage anyone from volunteering. > Doesn't that sort of moot the point that the source isn't being deleted? > It has to stay in the tree and usable -- at least for a while -- because not all of our Tier-2 platforms can build with clang yet. Those platforms, however, are typically not the ones that will require patching and maintenance (UltraSPARC 3s are not gaining any new features). I think that turning it off frees us during the 10.x release lifetime to actually remove it if the maintenance burden becomes too high -- or to revert our decision to turn it off at any time. Having it on by default locks us in to maintaining it for the lifetime of the branch. -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:47:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A215ED69; Fri, 23 Aug 2013 13:47:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 750C7284F; Fri, 23 Aug 2013 13:47:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B457AB941; Fri, 23 Aug 2013 09:47:54 -0400 (EDT) From: John Baldwin To: Vitja Makarov Subject: Re: Question about socket timeouts Date: Fri, 23 Aug 2013 09:45:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201308221408.08203.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201308230945.28701.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 23 Aug 2013 09:47:54 -0400 (EDT) Cc: Davide Italiano , 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, 23 Aug 2013 13:47:58 -0000 On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote: > 2013/8/22 John Baldwin : > > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote: > >> 2013/8/21 John Baldwin : > >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: > >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote: > >> >> > >> >> > Yes! Please file a PR! > >> >> > >> >> This sorta implies that both are acceptable (although, > >> >> the Linux behavior seems more desirable). > >> >> > >> >> http://austingroupbugs.net/view.php?id=369 > >> > > >> > No, that says "round up", so it does mean that the requested timeout > >> > should be the minimum amount slept. tvtohz() does this. Really odd > >> > that the socket code is using its own version of this rather than > >> > tvtohz(). > >> > > >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps getting > >> > bug fixes in its history that simply using tvtohz() would have solved. > >> > > >> > Try this: > >> > > >> > Index: uipc_socket.c > >> > =================================================================== > >> > --- uipc_socket.c (revision 254570) > >> > +++ uipc_socket.c (working copy) > >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt) > >> > if (error) > >> > goto bad; > >> > > >> > - /* assert(hz > 0); */ > >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz || > >> > tv.tv_usec < 0 || tv.tv_usec >= 1000000) { > >> > error = EDOM; > >> > goto bad; > >> > } > >> > - /* assert(tick > 0); */ > >> > - /* assert(ULONG_MAX - INT_MAX >= 1000000); */ > >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; > >> > - if (val > INT_MAX) { > >> > + val = tvtohz(&tv); > >> > + if (val == INT_MAX) { > >> > error = EDOM; > >> > goto bad; > >> > } > >> > - if (val == 0 && tv.tv_usec != 0) > >> > - val = 1; > >> > > >> > switch (sopt->sopt_name) { > >> > case SO_SNDTIMEO: > >> > > >> > >> That must help. But I want to see the issue solved in the next > >> release. I can't apply patch to the production system. Btw in > >> production environment we have kern.hz set to 1000 so it's not a > >> problem there. > > > > Can you test this in some way in a test environment? > > > > Ok, sorry for posting out of the list. > > Simple test program is attached. Without your patch timeout expires in > about 20ms. With it it's ~40ms. > > 40 instead of 30 is beacuse of odd tick added by tvtohz(). Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for HEAD I think we can fix this to use a precise timeout. I've cc'd davide@ so he can take a look at that. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:50:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D42A9E92 for ; Fri, 23 Aug 2013 13:50:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FF502890 for ; Fri, 23 Aug 2013 13:50:46 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so837406ieb.31 for ; Fri, 23 Aug 2013 06:50:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=MzPYsY8mhizXky+GWWA9Ce9MhbFLVbpb5c2X44so0hk=; b=Gi2r98PwOW8TxAf5hsC+osktqWvLfWcM4oym5kub+I/Vxn8rin9T44P6a8SSToniEM zgWhedHkVnG9L9u8sjyhqQro9pvJGGxEKizCwclil8+cIxcE51zQRHipptmGD2kl5dFe WcNrDbd/688NqQeG8Z0sOEhTyWwJ5B4qUzplgm5+kC6atMvdkVrdM3rXXrhsquTtITeK f2e42dw/ulj7v9uu9QfqoOHBw//gzFsoMn6VQsdI9qVh0gS8dm9PHw9JJA8m4wVdL3v7 LXSaVWcEJT9HZTY6mVIHqHitG971rS63FtEGH7KpjJan3WLY5kwrZm71PTssuZ+tROIz oP5g== X-Gm-Message-State: ALoCoQlgwHmJMw+BcugOhCaCJYBfstbQut3pnXh6/S8nI/CtgZI12LMf57HdT+gx2J1iobCniodi X-Received: by 10.43.68.130 with SMTP id xy2mr884864icb.41.1377265840671; Fri, 23 Aug 2013 06:50:40 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id p5sm3030742igj.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 06:50:39 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 23 Aug 2013 07:50:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9D48CB3D-E3FE-4189-9A6E-FE441C6854AB@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> To: David Chisnall X-Mailer: Apple Mail (2.1085) Cc: toolchain@FreeBSD.org, John-Mark Gurney , current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 13:50:46 -0000 On Aug 23, 2013, at 5:06 AM, David Chisnall wrote: > On 23 Aug 2013, at 11:42, Julian Elischer wrote: >=20 >> no, I believe we have said that 10 would ship with clang by default. = NO mention was made about gcc being absent, and I am uncomfortable with = taking that step yet. Having gcc just present, will not hurt you.. even = after it is gone we will need to support those who will be replacing = clang with newer versions of gcc in hteir own products. >=20 > The plan is not to delete gcc from the tree, it is to disable building = gcc by default when clang is the system compiler. If you are building = products then you are perfectly at liberty to set WITH_GCC=3Dyes in your = src.conf. >=20 > Our gcc is from 2007. It has no C11, no C++11 support. It has bugs = in its atomic generation so you can't use it sensibly without lots of = inline assembly (which it doesn't support for newer architectures) for = multithreaded things. >=20 > Our libstdc++ is ancient and doesn't work with modern C++ codebases. = Putting them in the base system means that people will use them. If = anyone wants them to remain, then speak now and this will be taken as = your volunteering to: >=20 > - Maintain our forks of both gcc and libstdc++ > - Handle every single PR that is filed by people using these >=20 > If you are willing to do this, then that's great. If not, then you = are asking other people to support ancient codebases that they are not = using. Well, it isn't quite that cut and dried. The date that gcc is from is not relevant. It works today for most of = the code out there. True, it doesn't have the latest features that a = small fraction of the code needs, but it works well enough. And it also = needs to be there for some upgrade paths. There's a use for gcc, and it = will likely be needed for these paths. As such, it has to work. Doesn't = matter if it is built by default or not, it simply has to keep working = as well as it has been working for the past 5 years to fill these roles. = For these tasks the nice C++ things simply don't matter or aren't = relevant. c11 features can't be put into the base for some time still = because of the issues on other architectures. We *HAVE* to have gcc on the other architectures. clang simply isn't = ready for MIPS, and has several outstanding problems on ARM. While work = is ongoing in these areas, clang simply won't be in as good a shape for = !x86 as it is for x86 in the 10.0 time frame. So even if gcc is turned off by default in 10 on x86, it still has to = work at least well enough to build the system and bootstrap clang. = Turning it off by default or on by default doesn't change this, and the = feature set that is used in 10 will basically be frozen soon, and the = non-x86 architectures will require the MI parts continue to work. I = don't see much decay that can happen in the x86MD parts that would break = it... Warner= From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D1BC9FEC for ; Fri, 23 Aug 2013 13:52:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E2F828B1 for ; Fri, 23 Aug 2013 13:52:21 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id 17so847508iea.15 for ; Fri, 23 Aug 2013 06:52:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=DkpHDe2t7FBkYUkMdwcajD4L24Amp1X7+ZL5Una0Z2k=; b=Om3pC4Phd5sbHqTO9MPhIylH4GjjIj3kP/H/jl1XtOyesrQvC1DrK+RuuUgSAvDFbl lOmsrncISf1J6mIvbDSnE5eouLd/nFm1vz9UGe/hrsWF6rotH610N3e4EaLthShDS79K FAsHCwQrqa5QyHCOzSJifpT4SmC9t3Ow/vVgIY9U/Apsjs9Yvn7yOC2ktRlA2Ia+qVAR bjTwHrSPtfLLkDM7mnKFw2NhE1U0ajqpT7ycwC0VEEHF7oUb/stDkuXYxhja7c1rkSIY EasiYE95fsgBxa6cf+I4FDU8sD5Crqfmum9cGa6KfudMS8mQT93hM/I1Mnp36KilX16c 7okA== X-Gm-Message-State: ALoCoQmS8NtZ5CEfIWQHdfj4Gq/4fLL8caJDT80qBZ8Y3hf5L219qyfbM2b9/UGBGk89gc1oavh0 X-Received: by 10.50.45.73 with SMTP id k9mr1620734igm.38.1377265935419; Fri, 23 Aug 2013 06:52:15 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id b5sm3065418igm.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 06:52:14 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130823111647.GT2951@home.opsec.eu> Date: Fri, 23 Aug 2013 07:52:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> To: Kurt Jaeger X-Mailer: Apple Mail (2.1085) Cc: toolchain@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: Fri, 23 Aug 2013 13:52:21 -0000 On Aug 23, 2013, at 5:16 AM, Kurt Jaeger wrote: > Hi! >=20 >>> I have a patch that I intend to commit before the 10.0 code >>> slush that removes GCC and libstdc++ from the default build on >>> platforms where clang is the system compiler. We definitely don't >>> want to be supporting our 6-year-old versions of these for the >>> lifetime of the 10.x branch. >>=20 >> Isn't it a POLA violation? >>=20 >> As for me I expect something like this: >> . 9.x gcc default and clang in base; >> . 10.x clang default and gcc in base; >> . 11.x gcc withdraw. >=20 > If the 150 ports that only work with gcc, all work with a ports > gcc and do not need the gcc from base, would the following be OK ? >=20 > - 9.x gcc default and clang in base; > - 10.x clang default and gcc in ports; No. That breaks non x86 architecutres. gcc must remain in base for now, = or there's no bootstrap ability. Nobody has done the lifting to cleanly = integrate gcc as a port into buildworld, althogh Brooks' work gets us = most of the way there. Warner From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:53: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 301DA517; Fri, 23 Aug 2013 13:53:14 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D0FF128D3; Fri, 23 Aug 2013 13:53:13 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id gf12so428703vcb.22 for ; Fri, 23 Aug 2013 06:53:13 -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:message-id:subject :from:to:cc:content-type; bh=bqNXBvazA6++umhdVOXxJKsVk7g02vSUH9cCaO7tJeE=; b=vTSvtAm/6X+qvpeQGdoBDoAJi5GLEc3EzmuWonm8IT81hBO3yhN9wv8YKG8GYEuyGi 16/Nn5NldbStbTY0ivEQeVdD7YGGkPyjdqvux9FPZfzU5FGoSoBjCvB+W87+9ziZfi9p OfXTXe+4aTLdRKjEgFYKea8AmaDQQ3xZqKemmkmOpuL/U90qtN5Yecqh6vUj0Uc2eCke /luzgDHETl70x6e2qWTSg+nfp8YXzJYuzcBDMLaWCHPKVQebDo5JTwjvysEW2BMIEdXY G05H2Ve4f8uuDvCnY1yN1p3COaacLOXuS1JX8SjDh3Dk77ctMejaxiOjDoWjDdPKUTRs Fhvw== MIME-Version: 1.0 X-Received: by 10.52.119.139 with SMTP id ku11mr81043vdb.42.1377265993052; Fri, 23 Aug 2013 06:53:13 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.65.132 with HTTP; Fri, 23 Aug 2013 06:53:12 -0700 (PDT) In-Reply-To: <201308230945.28701.jhb@freebsd.org> References: <201308221408.08203.jhb@freebsd.org> <201308230945.28701.jhb@freebsd.org> Date: Fri, 23 Aug 2013 15:53:12 +0200 X-Google-Sender-Auth: wfF3tZBsgRxuvrrteQ8ePGlnB8I Message-ID: Subject: Re: Question about socket timeouts From: Davide Italiano To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Vitja Makarov , 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, 23 Aug 2013 13:53:14 -0000 On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote: > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote: >> 2013/8/22 John Baldwin : >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote: >> >> 2013/8/21 John Baldwin : >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote: >> >> >> >> >> >> > Yes! Please file a PR! >> >> >> >> >> >> This sorta implies that both are acceptable (although, >> >> >> the Linux behavior seems more desirable). >> >> >> >> >> >> http://austingroupbugs.net/view.php?id=369 >> >> > >> >> > No, that says "round up", so it does mean that the requested timeout >> >> > should be the minimum amount slept. tvtohz() does this. Really odd >> >> > that the socket code is using its own version of this rather than >> >> > tvtohz(). >> >> > >> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps getting >> >> > bug fixes in its history that simply using tvtohz() would have solved. >> >> > >> >> > Try this: >> >> > >> >> > Index: uipc_socket.c >> >> > =================================================================== >> >> > --- uipc_socket.c (revision 254570) >> >> > +++ uipc_socket.c (working copy) >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt) >> >> > if (error) >> >> > goto bad; >> >> > >> >> > - /* assert(hz > 0); */ >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz || >> >> > tv.tv_usec < 0 || tv.tv_usec >= 1000000) { >> >> > error = EDOM; >> >> > goto bad; >> >> > } >> >> > - /* assert(tick > 0); */ >> >> > - /* assert(ULONG_MAX - INT_MAX >= 1000000); */ >> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; >> >> > - if (val > INT_MAX) { >> >> > + val = tvtohz(&tv); >> >> > + if (val == INT_MAX) { >> >> > error = EDOM; >> >> > goto bad; >> >> > } >> >> > - if (val == 0 && tv.tv_usec != 0) >> >> > - val = 1; >> >> > >> >> > switch (sopt->sopt_name) { >> >> > case SO_SNDTIMEO: >> >> > >> >> >> >> That must help. But I want to see the issue solved in the next >> >> release. I can't apply patch to the production system. Btw in >> >> production environment we have kern.hz set to 1000 so it's not a >> >> problem there. >> > >> > Can you test this in some way in a test environment? >> > >> >> Ok, sorry for posting out of the list. >> >> Simple test program is attached. Without your patch timeout expires in >> about 20ms. With it it's ~40ms. >> >> 40 instead of 30 is beacuse of odd tick added by tvtohz(). > > Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for > HEAD I think we can fix this to use a precise timeout. I've cc'd davide@ > so he can take a look at that. > > -- > John Baldwin Hi, I think I can switch this code to new timeout KPI, but this will require the timeout field of 'struct sockbuf' to be changed from 'int' to 'sbintime_t' which breaks binary compatibility. Do you have any strong objections about this? If any, I would like this to happen ABI freeze, so it looks like this is the right moment. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:54:34 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5C2F472A; Fri, 23 Aug 2013 13:54:34 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4FF28FB; Fri, 23 Aug 2013 13:54:33 +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 r7NDsC3c082176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Aug 2013 13:54:14 GMT (envelope-from theraven@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_BE8E92FE-C572-443D-BBCB-007C00543BDD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc) From: David Chisnall In-Reply-To: Date: Fri, 23 Aug 2013 14:54:11 +0100 Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> To: Warner Losh X-Mailer: Apple Mail (2.1508) Cc: toolchain@FreeBSD.org, Kurt Jaeger , 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, 23 Aug 2013 13:54:34 -0000 --Apple-Mail=_BE8E92FE-C572-443D-BBCB-007C00543BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Aug 2013, at 14:52, Warner Losh wrote: > No. That breaks non x86 architecutres. gcc must remain in base for = now, or there's no bootstrap ability. Nobody has done the lifting to = cleanly integrate gcc as a port into buildworld, althogh Brooks' work = gets us most of the way there. We've been using brooks' work to build the base system with an = out-of-tree toolchain for some time now... David --Apple-Mail=_BE8E92FE-C572-443D-BBCB-007C00543BDD 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 iQIcBAEBAgAGBQJSF2mEAAoJEKx65DEEsqIdhUEP/R7Uje7VNJYheAsQqad1D0ZN f4c/XdM/CvpfrCio/R9BDnClYYnvOxMW0fvQxiBRBdhwe7qx5/w/FEzD7No1XSpG bwQh5UY3na269wOw8t2EsmOlcRaWTa0QZGFtV/V6CUVgk3HwrRwZBT5pes3d8Q1J QF/U/ykd6o4Cl9aD3YdpAlMDDBwchdBE8Xw7eihWRsLYG2sQQDubjJq1N1mFu3cq fazcJOUzed3Y7uTxCJ2lToh2ycNhfIUuAE0fc9JXsMq647Ch5kIYpnuk74Z0A7V1 wkufNvviTzrzjMUfFv+B2cLScwn8NiBlVWwKc8H1RMOz4Ml+g9EotumBhZwoxnWC JdpSF6x7V11J869ijkjQO0PFrlvLXn26Da+mepSzC6SKUcdFD68u7578eafv8+9L /g6DswAa5NSbz1nRbadksQUC2Oa2bS0MXyOASWWk11ypbz0ldrvkQo5Ej6q1+7NT kcdwl7DqqKJjWWNQPLb4NoxLuyyGLjWDmrUpT6641gOOR3BaS0uwEo1yMNWb3XFv 9OVmj3xWs5QTLLtcKZ9KP0uvIjq2fkOfvujcdYAvtx8nT5eFv3YjiWeoxjF1Bvh1 to9tqF95MDWMEc7vOmcH73LwDYmjIfzARSVBGdGaXFmimX977j3vHtEkxH+6FbeW aHZ3pCnxiSVSowUgnbK5 =Zqcn -----END PGP SIGNATURE----- --Apple-Mail=_BE8E92FE-C572-443D-BBCB-007C00543BDD-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:54:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2EBF984F; Fri, 23 Aug 2013 13:54:47 +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]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D650E2903; Fri, 23 Aug 2013 13:54:45 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id n12so580850wgh.24 for ; Fri, 23 Aug 2013 06:54:44 -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:message-id:subject :from:to:cc:content-type; bh=i1h0wGs9L9avCtKf5QdDzQDM1BJsfe8T3YYOSYXWg2Q=; b=BGEh+o9QO8LUW/TPdYG53rOMUuIdTo5zNaiPKF7X+3JFxqbVQ4d1Vhv2iWlR3Kiprv dfxeaHbOpAJ2SvX+ul7Bk3zkl0Hl1J6GYQaa6PTIf1iw2fhf4/xg3+scBF4T3EoAHsMT KT7HRX0fBjhigKem4Y2z8+pGaJVf2orruF3ndPsajP8iGVh8yPkCbNN3W0OyWZXAzkI8 dMhhoiZmENNN60NCnCDyUsRIpAeQqLjhTPJUq2nxfWYsQo15ECfV3abEY2gUFcSuSNm6 qpUitV4vcEKgDdFl2YqdU4RzBdYVPy4x6uCoVjM/eeWtx85ZktX+aVchulYNdtGZ7HDs 0DYw== MIME-Version: 1.0 X-Received: by 10.194.122.129 with SMTP id ls1mr1809538wjb.37.1377266084228; Fri, 23 Aug 2013 06:54:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Fri, 23 Aug 2013 06:54:44 -0700 (PDT) In-Reply-To: <20130823114635.GB64913@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <20130823114635.GB64913@zxy.spb.ru> Date: Fri, 23 Aug 2013 06:54:44 -0700 X-Google-Sender-Auth: TpN1h702denT-HSGus0oeUfMZz0 Message-ID: Subject: Re: patch to add AES intrinsics to gcc From: Adrian Chadd To: Slawa Olhovchenkov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "re@FreeBSD.org Engineering Team" , "current@freebsd.org" , Bernhard Fr?hlich , John-Mark Gurney , David Chisnall , 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: Fri, 23 Aug 2013 13:54:47 -0000 Hi! If firewire code doesn't build on clang correctly, have you filed a bug so it gets looked at before 10.0 is released? that's pretty broken code/behaviour. -adrian On 23 August 2013 04:46, Slawa Olhovchenkov wrote: > On Fri, Aug 23, 2013 at 06:42:21PM +0800, Julian Elischer wrote: > > > On 8/23/13 6:35 PM, David Chisnall wrote: > > > On 23 Aug 2013, at 10:58, Bernhard Fr?hlich wrote: > > > > > >> I don't know if you are aware that IF you really do that we will have > serious > > >> problems to ship packages for 10. USE_GCC=any is the fallback in the > > >> portstree for all ports that are unable to build with clang which was > introduced > > >> when HEAD switched to clang as default cc. Right now there are 150 > ports in > > >> the tree that use this fallback and quite a few of them are high > profile ports: > > >> > > >> the highlights: > > >> audio/nas devel/mingw32-binutils emulators/qemu > emulators/virtualbox-ose > > >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 > multimedia/libxine > > >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 > > >> security/clamav > > >> > > >> the full list: > > >> http://dpaste.com/1354075/ > > >> > > >> A possible hack could be to add a check for USE_GCC=any to behave like > > >> a USE_GCC=yes on HEAD on the affected platforms. This pulls in > lang/gcc > > >> from ports for a lot of people on HEAD I suppose. > > >> > > >> We certainly need to do that switch to remove the ancient gcc from > base > > >> some time but with my portmgr hat on I can only say we don't plan to > do that > > >> before 10.0 especially not if we are only talking about a few weeks > time window. > > > That is unfortunate. We have said for over a year that 10.0 should > not ship with gcc. I can delay committing the patch to flip the switch > until later in the code slush, if re approves, but ports that require gcc > should be building with gcc from ports (which will also improve code > quality, as gcc 4.6/7 produce significantly better code than 4.2.1). > > no, I believe we have said that 10 would ship with clang by default. > > 10 from this winner have broken firewire code when building by clang > -- cannot resume from sleep. > _______________________________________________ > 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 Aug 23 13:55:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 37017996 for ; Fri, 23 Aug 2013 13:55:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0121F2921 for ; Fri, 23 Aug 2013 13:55:42 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id u16so822082iet.20 for ; Fri, 23 Aug 2013 06:55:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=JN4dJtjd07jauEc8cJ1vL6784Jannesp7AMElStjHJY=; b=UbmU7bxBpTfkE1/Oq/9T7XKzK4e4rSl+XDXBcEjEADRDezRcGvvDlyebdWqT1XKTbr CenbvQcm8b3zUAXqp7viQN8sY8YyCVRwQc6qX3x/vFED9DUFED20wVlSaL55ikqeYyo4 2sFFPxsZ9vpCVvHR5MeneA3CEOkaioxUF9NHcngy4swZLneg9p58Fv02tTVVi4aNrqiq q8WcEbph9AejkebBuL2y22ErFQhDqu4IkxYvwcc+T/2nWZIww8pTIodyNyLTbkWTFWyi ZdO8YVcgu+lXaLRPzGufZGk+WLfmGgnOgQfaH1UzCfjXmskGbHAeNzFFNGlyRvRz0oQw LW8g== X-Gm-Message-State: ALoCoQmldeWZNX0pXv05z7KTmU38iaTimm8h9fSLSnCN31j1iH/U2GqGJiwqjJ45/ureNJKA0Hwg X-Received: by 10.43.66.11 with SMTP id xo11mr1362127icb.21.1377266142281; Fri, 23 Aug 2013 06:55:42 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id cl4sm52085igc.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 06:55:41 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1377261014.1111.43.camel@revolution.hippie.lan> Date: Fri, 23 Aug 2013 07:55:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <1377261014.1111.43.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: "re@FreeBSD.org Engineering Team" , current@FreeBSD.org, John-Mark Gurney , David Chisnall , 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: Fri, 23 Aug 2013 13:55:43 -0000 On Aug 23, 2013, at 6:30 AM, Ian Lepore wrote: > On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote: >> On 23 Aug 2013, at 11:42, Julian Elischer wrote: >>=20 >>> no, I believe we have said that 10 would ship with clang by default. = NO mention was made about gcc being absent, and I am uncomfortable with = taking that step yet. Having gcc just present, will not hurt you.. even = after it is gone we will need to support those who will be replacing = clang with newer versions of gcc in hteir own products. >>=20 >> The plan is not to delete gcc from the tree, it is to disable = building gcc by default when clang is the system compiler. If you are = building products then you are perfectly at liberty to set WITH_GCC=3Dyes = in your src.conf. >>=20 >> Our gcc is from 2007. It has no C11, no C++11 support. It has bugs = in its atomic generation so you can't use it sensibly without lots of = inline assembly (which it doesn't support for newer architectures) for = multithreaded things. >>=20 >> Our libstdc++ is ancient and doesn't work with modern C++ codebases. = Putting them in the base system means that people will use them. If = anyone wants them to remain, then speak now and this will be taken as = your volunteering to: >>=20 >> - Maintain our forks of both gcc and libstdc++ >> - Handle every single PR that is filed by people using these >>=20 >> If you are willing to do this, then that's great. If not, then you = are asking other people to support ancient codebases that they are not = using. >>=20 >> David >>=20 >=20 > I don't understand, you start by pointing out that gcc will still be = in > the tree and usable, then you go on to point out that it it won't be > supported or maintained unless someone volunteers to do that, and you > seem to be doing your best to discourage anyone from volunteering. > Doesn't that sort of moot the point that the source isn't being = deleted? If it is in the tree it's gotta work. And it has to be in the tree for = !x86 architectures. So on or off for x86 doesn't really add to the load = at all, and the C++/C11 stuff is a red herring. If it isn't cc, then = people wanting clang by default won't care... And besides, ports aren't completely ready to kill it, so it has to work = for them. Warner= From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 13:59:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7622C95 for ; Fri, 23 Aug 2013 13:59:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A44512953 for ; Fri, 23 Aug 2013 13:59:13 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id s9so835412iec.21 for ; Fri, 23 Aug 2013 06:59:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=oH9fxsHTsgyKyxiDvk/IxgApeVfXxHNlUlxHjMK+5Gw=; b=PfmYkSaOcqQsnwvzh2lrYo0Ln20epJe2Ecz5H4RQPo+3xsAINHm/J9Yj/qNJZtKoJc IiFK73UKpPRd6TY3DKvfFSUf5eFFuhF8+vpZt2qIUp79Rw0QFMrfk1JnQkWhw1HVdDvn VfebZOhwaSlOAZwoCiP4Hz1fq+AApLTZqjjSAHQY1DtuHBqazBpEPyTdIRVZerk2/+YT V2SJEMtTIprwUR1vVpuiK43JXMSm8KQFfiyfCw5jVml//7Y1nQ9roUOMXOBVFsvEELM4 HptMppoXH01NwVv6dD1IzliDTGKvE7ZxJWvk6URr4U9KGQOpsmpZSxJh4fFldoABt+90 tAQw== X-Gm-Message-State: ALoCoQnE+rEoRQG32oGF8mwg+CjZvv1h4rjd6GqAYl0q9AzxBBhxpJJ2jyILb12MdxjwZfg4/PRl X-Received: by 10.50.131.170 with SMTP id on10mr1653417igb.12.1377266353233; Fri, 23 Aug 2013 06:59:13 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id g5sm3078609igc.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 06:59:12 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 23 Aug 2013 07:59:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <04A68472-3377-4E48-B7BE-DDBF070507B4@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> To: David Chisnall X-Mailer: Apple Mail (2.1085) Cc: toolchain@FreeBSD.org, Kurt Jaeger , 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, 23 Aug 2013 13:59:13 -0000 On Aug 23, 2013, at 7:54 AM, David Chisnall wrote: > On 23 Aug 2013, at 14:52, Warner Losh wrote: >> No. That breaks non x86 architecutres. gcc must remain in base for = now, or there's no bootstrap ability. Nobody has done the lifting to = cleanly integrate gcc as a port into buildworld, althogh Brooks' work = gets us most of the way there. >=20 > We've been using brooks' work to build the base system with an = out-of-tree toolchain for some time now... I'll have to try the native build part of the cycle then... Early = versions of the patch failed when you cross built the target, installed = the target, but wound up with no compilers to bootstrap the external = toolchains with to do native builds on the target. Warner From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 15:16:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 92C8C110; Fri, 23 Aug 2013 15:16:22 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (cl-90.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:59::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53FC62DEA; Fri, 23 Aug 2013 15:16:22 +0000 (UTC) Received: from roberto02-aw.erc.corp.eurocontrol.int (unknown [88.190.16.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 0601A52AE; Fri, 23 Aug 2013 17:16:20 +0200 (CEST) Date: Fri, 23 Aug 2013 17:16:15 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org, security@FreeBSD.org, current@FreeBSD.org Subject: Re: patch to improve AES-NI performance Message-ID: <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> References: <20130822202027.GH94127@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130822202027.GH94127@funkthat.com> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP 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, 23 Aug 2013 15:16:22 -0000 According to John-Mark Gurney on Thu, Aug 22, 2013 at 01:20:27PM -0700: > I have developed a patch to improve AES-NI performance. If you took the > AES-XTS algorithm into userland (no cryptodev or geli usage), these > changes improve the performance over 10x in my tests (from ~150MB/sec to > over 2GB/sec). In tests of geli on gnop, the performance improvement is > more moderate, around 4x due to overhead in other parts of the system. Thanks a lot for this patch. Now, looking at it in the stable/9 context, I can see that pjd did not merge (as he said at the time of commit) r226839 & r226839. Is there any objection to merge these two (and possibly 247061 as well -- copyright update)? I ask that for two reasons, these two revisions are speeding up AES-NI quite a bit and they are required for using jmg's patch. I'll be testing all this in the next few days on my new AES-NI enabled machine. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 15:16:26 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3B38220A; Fri, 23 Aug 2013 15:16:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A21E2DEB; Fri, 23 Aug 2013 15:16:26 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7NFGMFf047082; Fri, 23 Aug 2013 08:16:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7NFGMZ8047081; Fri, 23 Aug 2013 08:16:22 -0700 (PDT) (envelope-from sgk) Date: Fri, 23 Aug 2013 08:16:22 -0700 From: Steve Kargl To: Boris Samorodov Subject: Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc) Message-ID: <20130823151622.GA46958@troutmask.apl.washington.edu> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5217413A.9080105@passap.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: toolchain@FreeBSD.org, John-Mark Gurney , David Chisnall , 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, 23 Aug 2013 15:16:26 -0000 On Fri, Aug 23, 2013 at 03:02:18PM +0400, Boris Samorodov wrote: > 23.08.2013 13:16, David Chisnall ??????????: > >> I have a patch that I intend to commit before the 10.0 code >> slush that removes GCC and libstdc++ from the default build >> on platforms where clang is the system compiler. We definitely >> don't want to be supporting our 6-year-old versions of these >> for the lifetime of the 10.x branch. > > Isn't it a POLA violation? > > As for me I expect something like this: > . 9.x gcc default and clang in base; > . 10.x clang default and gcc in base; > . 11.x gcc withdraw. > +1 -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 14:04: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 72C113B7; Fri, 23 Aug 2013 14:04:06 +0000 (UTC) (envelope-from vitja.makarov@gmail.com) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0BD5129DC; Fri, 23 Aug 2013 14:04:05 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id hf12so437975vcb.41 for ; Fri, 23 Aug 2013 07:04:05 -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=4bcNgb7+5Zsf+X9znv3XycLqhRLZyldMzHilKnrvN8I=; b=xsqI6f3CPZ4wnzRGEDLsuCgIBNw15QOQdwZrK7+9X1HfkSvYxGnHf0iElzKuPuykOo VJyUYVJJkpMPsZDh7jUdJc/MWP0yjM8Sp7e6c4blqsR06s4Aau5Qb04CPuqVjnO5AOn8 VQICy8+B05Hb1NbNjqvQqPG/YaTmAFIn+uyzGLH2PlY32FwX/405vWPzupuKqkNxbwFB WrTexwnAmBFqoRojPyED3wlcxZcutO6AKi+FDRhA7uqmBLxFQIKsV1/hJzjf9ikUTTZX 0YPeTSFxHNqwpvctUibYjqcedFqa+o3oxcaJObMCmrIBJ0g0RikPf4nFCSa+J2UX0A2Z Xf1g== MIME-Version: 1.0 X-Received: by 10.58.155.6 with SMTP id vs6mr168814veb.32.1377266645258; Fri, 23 Aug 2013 07:04:05 -0700 (PDT) Received: by 10.52.27.51 with HTTP; Fri, 23 Aug 2013 07:04:05 -0700 (PDT) In-Reply-To: References: <201308221408.08203.jhb@freebsd.org> <201308230945.28701.jhb@freebsd.org> Date: Fri, 23 Aug 2013 18:04:05 +0400 Message-ID: Subject: Re: Question about socket timeouts From: Vitja Makarov To: Davide Italiano Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 23 Aug 2013 15:23:55 +0000 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: Fri, 23 Aug 2013 14:04:06 -0000 2013/8/23 Davide Italiano : > On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote: >> On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote: >>> 2013/8/22 John Baldwin : >>> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote: >>> >> 2013/8/21 John Baldwin : >>> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: >>> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote: >>> >> >> >>> >> >> > Yes! Please file a PR! >>> >> >> >>> >> >> This sorta implies that both are acceptable (although, >>> >> >> the Linux behavior seems more desirable). >>> >> >> >>> >> >> http://austingroupbugs.net/view.php?id=369 >>> >> > >>> >> > No, that says "round up", so it does mean that the requested timeout >>> >> > should be the minimum amount slept. tvtohz() does this. Really odd >>> >> > that the socket code is using its own version of this rather than >>> >> > tvtohz(). >>> >> > >>> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps getting >>> >> > bug fixes in its history that simply using tvtohz() would have solved. >>> >> > >>> >> > Try this: >>> >> > >>> >> > Index: uipc_socket.c >>> >> > =================================================================== >>> >> > --- uipc_socket.c (revision 254570) >>> >> > +++ uipc_socket.c (working copy) >>> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt) >>> >> > if (error) >>> >> > goto bad; >>> >> > >>> >> > - /* assert(hz > 0); */ >>> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz || >>> >> > tv.tv_usec < 0 || tv.tv_usec >= 1000000) { >>> >> > error = EDOM; >>> >> > goto bad; >>> >> > } >>> >> > - /* assert(tick > 0); */ >>> >> > - /* assert(ULONG_MAX - INT_MAX >= 1000000); */ >>> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; >>> >> > - if (val > INT_MAX) { >>> >> > + val = tvtohz(&tv); >>> >> > + if (val == INT_MAX) { >>> >> > error = EDOM; >>> >> > goto bad; >>> >> > } >>> >> > - if (val == 0 && tv.tv_usec != 0) >>> >> > - val = 1; >>> >> > >>> >> > switch (sopt->sopt_name) { >>> >> > case SO_SNDTIMEO: >>> >> > >>> >> >>> >> That must help. But I want to see the issue solved in the next >>> >> release. I can't apply patch to the production system. Btw in >>> >> production environment we have kern.hz set to 1000 so it's not a >>> >> problem there. >>> > >>> > Can you test this in some way in a test environment? >>> > >>> >>> Ok, sorry for posting out of the list. >>> >>> Simple test program is attached. Without your patch timeout expires in >>> about 20ms. With it it's ~40ms. >>> >>> 40 instead of 30 is beacuse of odd tick added by tvtohz(). >> >> Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for >> HEAD I think we can fix this to use a precise timeout. I've cc'd davide@ >> so he can take a look at that. >> >> -- >> John Baldwin > > Hi, > I think I can switch this code to new timeout KPI, but this will > require the timeout field of 'struct sockbuf' to be changed from 'int' > to 'sbintime_t' which breaks binary compatibility. Do you have any > strong objections about this? If any, I would like this to happen ABI > freeze, so it looks like this is the right moment. > I think that for socket's timeouts it's ok to have a HZ-precision. It would be much more important to implement high-precision timeouts for select() and friends, if it's not done yet (sorry I'm running 9.1). -- vitja. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 15:25: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 175FD7A2 for ; Fri, 23 Aug 2013 15:25:58 +0000 (UTC) (envelope-from sunk.cs@gmail.com) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A21242E96 for ; Fri, 23 Aug 2013 15:25:57 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id a15so357488eae.9 for ; Fri, 23 Aug 2013 08:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=YY+J4eulnJHVVwHJKZQR8h7ArW7xzvz3woyu27aFBfs=; b=rGiNHPICXfY2SfCotcqQ+OA5xaHSuOgkz06cJgfwl38h4au4M+TsITm6+EHFtBUmKf cxrabcbPWw5ZoRzpEXd2hA+vB+QzpCiAb/vAgmybrEgGaF1nrYhgbGURJPWFhgEylPpy kO0n5SU/MNFDik+YAdtIJyafjFb+10ugDipxhhavpxPE5CbklExEM/8qvIrmhHKvuOem 4BSEMRWtI0RVb4r9BF45InrKH0XFqtTzYV+kfzpwHKON2FoI2+ViKp1su2iXgGf2LPOc CYvSWwsk5WbAnqAq4tinhcmpEtoPO2DjLW40BBLRXz2bwn9HNN3BixwA42BBoAtaEVS1 DOGg== X-Received: by 10.14.181.132 with SMTP id l4mr209853eem.77.1377271555952; Fri, 23 Aug 2013 08:25:55 -0700 (PDT) Received: from localhost ([2001:620:600:4400:a6ba:dbff:fef0:3a99]) by mx.google.com with ESMTPSA id x47sm363140eea.16.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 08:25:55 -0700 (PDT) Date: Fri, 23 Aug 2013 17:25:49 +0200 From: Ke Sun To: freebsd-current@freebsd.org Subject: LOR on reboot Message-ID: <20130823152549.GA32613@probe.unige.ch> 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, 23 Aug 2013 15:25:58 -0000 Hi current, I have FreeBSD 10.0-CURRENT #5 r254404 on my laptop. During reboot, I get the following LOR. Could someone please fix this? Thanks! Ke Sun Syncing disks, vnodes remaining...0 0 0 0 0 0 done All buffers synced. lock order reversal: 1st 0xfffffe00094bd5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xfffffe000903b418 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1411 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff81a7582470 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff81a7582520 witness_checkorder() at witness_checkorder+0xd4f/frame 0xffffff81a75825b0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xffffff81a75826e0 vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff81a7582700 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xffffff81a7582730 _vn_lock() at _vn_lock+0xab/frame 0xffffff81a75827a0 ffs_flushfiles() at ffs_flushfiles+0x88/frame 0xffffff81a7582800 ffs_unmount() at ffs_unmount+0x162/frame 0xffffff81a7582860 dounmount() at dounmount+0x39e/frame 0xffffff81a75828e0 vfs_unmountall() at vfs_unmountall+0x61/frame 0xffffff81a7582910 kern_reboot() at kern_reboot+0x548/frame 0xffffff81a7582980 sys_reboot() at sys_reboot+0x58/frame 0xffffff81a75829a0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff81a7582ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff81a7582ab0 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x80085f5ec, rsp = 0x7fffffffd9b8, rbp = 0x7fffffffdb20 --- From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 15:26:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C17538C2; Fri, 23 Aug 2013 15:26:26 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 79D382EAB; Fri, 23 Aug 2013 15:26:26 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r7NFQOtO051217; Fri, 23 Aug 2013 11:26:25 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <52177F0B.9020906@sentex.net> Date: Fri, 23 Aug 2013 11:26:03 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ollivier Robert Subject: Re: patch to improve AES-NI performance References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> In-Reply-To: <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 64.7.153.18 Cc: freebsd-current@freebsd.org, security@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, 23 Aug 2013 15:26:26 -0000 On 8/23/2013 11:16 AM, Ollivier Robert wrote: > According to John-Mark Gurney on Thu, Aug 22, 2013 at 01:20:27PM -0700: >> I have developed a patch to improve AES-NI performance. If you took the >> AES-XTS algorithm into userland (no cryptodev or geli usage), these >> changes improve the performance over 10x in my tests (from ~150MB/sec to >> over 2GB/sec). In tests of geli on gnop, the performance improvement is >> more moderate, around 4x due to overhead in other parts of the system. > > Thanks a lot for this patch. Now, looking at it in the stable/9 context, I can see that pjd did not merge (as he said at the time of commit) r226839 & r226839. Is there any objection to merge these two (and possibly 247061 as well -- copyright update)? > > I ask that for two reasons, these two revisions are speeding up AES-NI quite a bit and they are required for using jmg's patch. > > I'll be testing all this in the next few days on my new AES-NI enabled machine. > Speeding up userland AES is very interesting to me for a couple of apps. If there is a proper way I should test on RELENG_9, please let me know as I am few boxes that I would be happy to test/deploy on. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 15:30: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AEE2DB80; Fri, 23 Aug 2013 15:30:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F48D2ED8; Fri, 23 Aug 2013 15:30:01 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 98A15B949; Fri, 23 Aug 2013 11:30:00 -0400 (EDT) From: John Baldwin To: Davide Italiano Subject: Re: Question about socket timeouts Date: Fri, 23 Aug 2013 11:29:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201308230945.28701.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308231129.03990.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 23 Aug 2013 11:30:00 -0400 (EDT) Cc: Vitja Makarov , 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, 23 Aug 2013 15:30:01 -0000 On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote: > On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote: > > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote: > >> 2013/8/22 John Baldwin : > >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote: > >> >> 2013/8/21 John Baldwin : > >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: > >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote: > >> >> >> > >> >> >> > Yes! Please file a PR! > >> >> >> > >> >> >> This sorta implies that both are acceptable (although, > >> >> >> the Linux behavior seems more desirable). > >> >> >> > >> >> >> http://austingroupbugs.net/view.php?id=369 > >> >> > > >> >> > No, that says "round up", so it does mean that the requested timeout > >> >> > should be the minimum amount slept. tvtohz() does this. Really odd > >> >> > that the socket code is using its own version of this rather than > >> >> > tvtohz(). > >> >> > > >> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps getting > >> >> > bug fixes in its history that simply using tvtohz() would have solved. > >> >> > > >> >> > Try this: > >> >> > > >> >> > Index: uipc_socket.c > >> >> > =================================================================== > >> >> > --- uipc_socket.c (revision 254570) > >> >> > +++ uipc_socket.c (working copy) > >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt) > >> >> > if (error) > >> >> > goto bad; > >> >> > > >> >> > - /* assert(hz > 0); */ > >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz || > >> >> > tv.tv_usec < 0 || tv.tv_usec >= 1000000) { > >> >> > error = EDOM; > >> >> > goto bad; > >> >> > } > >> >> > - /* assert(tick > 0); */ > >> >> > - /* assert(ULONG_MAX - INT_MAX >= 1000000); */ > >> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; > >> >> > - if (val > INT_MAX) { > >> >> > + val = tvtohz(&tv); > >> >> > + if (val == INT_MAX) { > >> >> > error = EDOM; > >> >> > goto bad; > >> >> > } > >> >> > - if (val == 0 && tv.tv_usec != 0) > >> >> > - val = 1; > >> >> > > >> >> > switch (sopt->sopt_name) { > >> >> > case SO_SNDTIMEO: > >> >> > > >> >> > >> >> That must help. But I want to see the issue solved in the next > >> >> release. I can't apply patch to the production system. Btw in > >> >> production environment we have kern.hz set to 1000 so it's not a > >> >> problem there. > >> > > >> > Can you test this in some way in a test environment? > >> > > >> > >> Ok, sorry for posting out of the list. > >> > >> Simple test program is attached. Without your patch timeout expires in > >> about 20ms. With it it's ~40ms. > >> > >> 40 instead of 30 is beacuse of odd tick added by tvtohz(). > > > > Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for > > HEAD I think we can fix this to use a precise timeout. I've cc'd davide@ > > so he can take a look at that. > > > > -- > > John Baldwin > > Hi, > I think I can switch this code to new timeout KPI, but this will > require the timeout field of 'struct sockbuf' to be changed from 'int' > to 'sbintime_t' which breaks binary compatibility. Do you have any > strong objections about this? If any, I would like this to happen ABI > freeze, so it looks like this is the right moment. This should be fine to change now, it just can't be MFC'd (which we can't do anyway). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 16:36: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6A0C399F for ; Fri, 23 Aug 2013 16:36:52 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm16-vm3.access.bullet.mail.bf1.yahoo.com (nm16-vm3.access.bullet.mail.bf1.yahoo.com [216.109.115.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC4DE22C6 for ; Fri, 23 Aug 2013 16:36:51 +0000 (UTC) Received: from [66.196.81.166] by nm16.access.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2013 16:31:31 -0000 Received: from [98.139.221.52] by tm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2013 16:31:30 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.bf1.yahoo.com with NNFMP; 23 Aug 2013 16:31:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1377275490; bh=aHxjQaf1iaROsi2Y8HOhm5EqSXl6Bp5fmBb1N2u7Xf8=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:CC:Subject; b=nV/Sjw85iLOnPVd3aBw0oHCsPP5aT2xO0/vwKmvXWpKtYiXQCgdrK+CpNEnTQJGh6U0N3yUjrfr2BVpEyLTf38S2vLtBwgDPx6aPFAPmhKvEsLchtIag6VoIJffjbxTrjqcwdn/sGRyKADKWoLqUsUS17RFLZNrMWj3VFyquJrY= X-Yahoo-Newman-Id: 684272.3945.bm@smtp105.sbc.mail.bf1.yahoo.com Message-ID: <684272.3945.bm@smtp105.sbc.mail.bf1.yahoo.com> Date: Fri, 23 Aug 2013 09:31:30 -0700 (PDT) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9xhoO_AVM1nAS3Cm_vgVVkQYpYj7LJW_0bm9MDc7A1HWDjQ FFHGVfJh0Dtb.sHSl3jIaAL2F7Q8vuJKsdjTUuZ8OBaUgQCInDaxIV6jD4Sg VDRtgBgZ1z7I2HHBfRt5wo31uTqYARaEr4I9Uc2p36OGUg9PGyOEBy4veIeO YbAoob2iFh467UmEB6S8gG5ual4sP_O4VtEjfB7bdU6xNr0TjeS5LcHEe_UT r9KYiGCGvs0gAPj_6IntGPg6cJN.ihXfCcX512rDgUnnJb1CrCX5EFyBHHNe EKTcChnDuAJhOzXWFZg1D1ShCAsekkgtrQfXvs9RnlsEfvbkc7G9tmCegXgx yGTrjiRXdQU1bxfzzYIW0imu1dj6qJPV7Gj2wKYQnpK4iuIMcLSCCB5xImZy w.k.0brV_6WvRQa0cKIMQSsv6rgzCAp46H_f_p275C0f7Koe_97J..oAzzdC pY9PkST6AVa6pN0fP_vGI6Xv8JOPWSv2FbmUxjkEANYoAnUEvm4VRANgOlFW IaErzZC_LyGP2CI_0lakuSX_f65OFshhMz3QyTYA68j6lnTUNkjWGjSpCLWe 2CN90ZMCG X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- X-Rocket-Received: from localhost (mueller6724@74.130.200.176 with plain) by smtp105.sbc.mail.bf1.yahoo.com with SMTP; 23 Aug 2013 09:31:30 -0700 PDT From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc) Cc: 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: Fri, 23 Aug 2013 16:36:52 -0000 > As for me I expect something like this: > . 9.x gcc default and clang in base; > . 10.x clang default and gcc in base; > . 11.x gcc withdraw. There is also the concern whether clang in base will reliably build gcc required for some ports, and then there are those CPU architectures for which clang is nonexistent or not ready. Regarding those ports that build with the ancient gcc 4.2.1 but not with newer versions, that has to be considered a bug. Consider that Linux and the other BSDs use newer versions of gcc to build their base system and ports or pkgsrc. Tom From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 18:04: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C3C53C4D; Fri, 23 Aug 2013 18:04:14 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8647D2805; Fri, 23 Aug 2013 18:04:14 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7NI4DYx011744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 11:04:13 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7NI4D9p011743; Fri, 23 Aug 2013 11:04:13 -0700 (PDT) (envelope-from jmg) Date: Fri, 23 Aug 2013 11:04:13 -0700 From: John-Mark Gurney To: Ollivier Robert Subject: Re: patch to improve AES-NI performance Message-ID: <20130823180413.GL94127@funkthat.com> Mail-Followup-To: Ollivier Robert , freebsd-current@freebsd.org, security@freebsd.org References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 23 Aug 2013 11:04:13 -0700 (PDT) Cc: freebsd-current@freebsd.org, security@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, 23 Aug 2013 18:04:14 -0000 Ollivier Robert wrote this message on Fri, Aug 23, 2013 at 17:16 +0200: > According to John-Mark Gurney on Thu, Aug 22, 2013 at 01:20:27PM -0700: > > I have developed a patch to improve AES-NI performance. If you took the > > AES-XTS algorithm into userland (no cryptodev or geli usage), these > > changes improve the performance over 10x in my tests (from ~150MB/sec to > > over 2GB/sec). In tests of geli on gnop, the performance improvement is > > more moderate, around 4x due to overhead in other parts of the system. > > Thanks a lot for this patch. Now, looking at it in the stable/9 context, I can see that pjd did not merge (as he said at the time of commit) r226839 & r226839. Is there any objection to merge these two (and possibly 247061 as well -- copyright update)? You repeated r226839 twice. What is the correct second revision? And both the ones above are just copyright updates, no functionality changes... > I ask that for two reasons, these two revisions are speeding up AES-NI quite a bit and they are required for using jmg's patch. > > I'll be testing all this in the next few days on my new AES-NI enabled machine. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 18:05:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 55FE9EB7; Fri, 23 Aug 2013 18:05:14 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 11AA82822; Fri, 23 Aug 2013 18:05:14 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7NI5Dgp011777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 11:05:13 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7NI5DDN011776; Fri, 23 Aug 2013 11:05:13 -0700 (PDT) (envelope-from jmg) Date: Fri, 23 Aug 2013 11:05:13 -0700 From: John-Mark Gurney To: Mike Tancsa Subject: Re: patch to improve AES-NI performance Message-ID: <20130823180513.GM94127@funkthat.com> Mail-Followup-To: Mike Tancsa , Ollivier Robert , freebsd-current@freebsd.org, security@freebsd.org References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <52177F0B.9020906@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52177F0B.9020906@sentex.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 23 Aug 2013 11:05:13 -0700 (PDT) Cc: Ollivier Robert , freebsd-current@freebsd.org, security@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, 23 Aug 2013 18:05:14 -0000 Mike Tancsa wrote this message on Fri, Aug 23, 2013 at 11:26 -0400: > On 8/23/2013 11:16 AM, Ollivier Robert wrote: > > According to John-Mark Gurney on Thu, Aug 22, 2013 at 01:20:27PM -0700: > >> I have developed a patch to improve AES-NI performance. If you took the > >> AES-XTS algorithm into userland (no cryptodev or geli usage), these > >> changes improve the performance over 10x in my tests (from ~150MB/sec to > >> over 2GB/sec). In tests of geli on gnop, the performance improvement is > >> more moderate, around 4x due to overhead in other parts of the system. > > > > Thanks a lot for this patch. Now, looking at it in the stable/9 context, I can see that pjd did not merge (as he said at the time of commit) r226839 & r226839. Is there any objection to merge these two (and possibly 247061 as well -- copyright update)? > > > > I ask that for two reasons, these two revisions are speeding up AES-NI quite a bit and they are required for using jmg's patch. > > > > I'll be testing all this in the next few days on my new AES-NI enabled machine. > > > > Speeding up userland AES is very interesting to me for a couple of apps. > If there is a proper way I should test on RELENG_9, please let me know > as I am few boxes that I would be happy to test/deploy on. My patch would only effect userland applications that use /dev/crypto... If they do their own AES-NI work, then there isn't any improvement... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 18:17:42 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 797493B0; Fri, 23 Aug 2013 18:17:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 468B52910; Fri, 23 Aug 2013 18:17:42 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r7NIHabb001677 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 11:17:39 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5217A73A.7090402@freebsd.org> Date: Sat, 24 Aug 2013 02:17:30 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <521754E6.3030906@FreeBSD.org> In-Reply-To: <521754E6.3030906@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, David Chisnall , current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 18:17:42 -0000 On 8/23/13 8:26 PM, Andriy Gapon wrote: > on 23/08/2013 14:06 David Chisnall said the following: >> Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its >> atomic generation so you can't use it sensibly without lots of inline >> assembly (which it doesn't support for newer architectures) for >> multithreaded things. >> >> Our libstdc++ is ancient and doesn't work with modern C++ codebases. > On the other hand these tools are perfect for building FreeBSD kernel and base. > Extrapolating my experience with base GCC I am very confident in it as a > FreeBSD development tool. > Extrapolating my experience with Clang I am not yet confident in it as a > FreeBSD development tool. > > I do not care about C11, C++11 and modern C++ codebases. I care about what's > in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, > of course. But, OTOH, those who care modern C++ codebases should be perfectly > capable to install a compiler from ports or switch to clang as their default > compiler. > +1 I'd like to see it still be "there if you need it" in 10 in 11 it's in ports From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 18:19:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 246B651B; Fri, 23 Aug 2013 18:19:57 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD83B2938; Fri, 23 Aug 2013 18:19:56 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r7NIJtZZ017624; Fri, 23 Aug 2013 14:19:55 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5217A7B5.8040904@sentex.net> Date: Fri, 23 Aug 2013 14:19:33 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ollivier Robert , freebsd-current@freebsd.org, security@freebsd.org Subject: Re: patch to improve AES-NI performance References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <52177F0B.9020906@sentex.net> <20130823180513.GM94127@funkthat.com> In-Reply-To: <20130823180513.GM94127@funkthat.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 64.7.153.18 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, 23 Aug 2013 18:19:57 -0000 On 8/23/2013 2:05 PM, John-Mark Gurney wrote: >> Speeding up userland AES is very interesting to me for a couple of apps. >> If there is a proper way I should test on RELENG_9, please let me know >> as I am few boxes that I would be happy to test/deploy on. > > My patch would only effect userland applications that use /dev/crypto... > > If they do their own AES-NI work, then there isn't any improvement... For me its ssh which I think does, no ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 18:21:00 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 310C06BA; Fri, 23 Aug 2013 18:21:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 021E92981; Fri, 23 Aug 2013 18:20:59 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r7NIKDr5001682 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 11:20:16 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5217A7D8.1030806@freebsd.org> Date: Sat, 24 Aug 2013 02:20:08 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <52174D51.2050601@digsys.bg> <21414.1377258940@critter.freebsd.dk> In-Reply-To: <21414.1377258940@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, Kurt Jaeger , current@FreeBSD.org, Daniel Kalchev 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, 23 Aug 2013 18:21:00 -0000 On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: > In message <52174D51.2050601@digsys.bg>, Daniel Kalchev writes: > >>> - 9.x gcc default and clang in base; >>> - 10.x clang default and gcc in ports; >> I believe this is the best idea so far. As long as these ports work with >> gcc in ports, that is. > +1 > well as I was forced to go back to gcc to get a compiling & running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 18:28:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8777C879; Fri, 23 Aug 2013 18:28:10 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (cl-90.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:59::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47BFC29C8; Fri, 23 Aug 2013 18:28:10 +0000 (UTC) Received: from lonrach.local (unknown [IPv6:2a01:e34:ee87:4a00:8598:3a55:4c44:3bb0]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 076FC52AE; Fri, 23 Aug 2013 20:28:02 +0200 (CEST) Date: Fri, 23 Aug 2013 20:27:54 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org, security@freebsd.org Subject: Re: patch to improve AES-NI performance Message-ID: <20130823182752.GA15392@lonrach.local> References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <20130823180413.GL94127@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130823180413.GL94127@funkthat.com> X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem 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, 23 Aug 2013 18:28:10 -0000 According to John-Mark Gurney: pjd did not merge (as he said at the time of commit) r226839 & r226839. Is there any objection to merge these two (and possibly 247061 as well -- copyright update)? > > You repeated r226839 twice. What is the correct second revision? You are right, I wanted to say r226837 which is the "code" one. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 18:52:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 543991ED; Fri, 23 Aug 2013 18:52:42 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 929632B98; Fri, 23 Aug 2013 18:52:42 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7NIqgta012395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 11:52:42 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7NIqf8S012394; Fri, 23 Aug 2013 11:52:41 -0700 (PDT) (envelope-from jmg) Date: Fri, 23 Aug 2013 11:52:41 -0700 From: John-Mark Gurney To: Mike Tancsa Subject: Re: patch to improve AES-NI performance Message-ID: <20130823185241.GO94127@funkthat.com> Mail-Followup-To: Mike Tancsa , Ollivier Robert , freebsd-current@freebsd.org, security@freebsd.org References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <52177F0B.9020906@sentex.net> <20130823180513.GM94127@funkthat.com> <5217A7B5.8040904@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5217A7B5.8040904@sentex.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 23 Aug 2013 11:52:42 -0700 (PDT) Cc: Ollivier Robert , freebsd-current@freebsd.org, security@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, 23 Aug 2013 18:52:43 -0000 Mike Tancsa wrote this message on Fri, Aug 23, 2013 at 14:19 -0400: > On 8/23/2013 2:05 PM, John-Mark Gurney wrote: > >> Speeding up userland AES is very interesting to me for a couple of apps. > >> If there is a proper way I should test on RELENG_9, please let me know > >> as I am few boxes that I would be happy to test/deploy on. > > > > My patch would only effect userland applications that use /dev/crypto... > > > > If they do their own AES-NI work, then there isn't any improvement... > > For me its ssh which I think does, no ? It looks like it uses OpenSSL for it's crypto, not /dev/crypto... Also, my work was done improving AES-XTS which isn't used by OpenSSH... OpenSSH looks like it uses either AES-GCM or AES-CTR, neither of which are supported by /dev/crypto... My gcc patch does include PCLMULQDQ support, which will be helpful for improving the performance of AES-GCM, and it looks like OpenSSL 1.0.1 has support, which is in HEAD, not RELENG_9 yet... So, if you want better ssh performance, install OpenSSL 1.0.1 and compile OpenSSH against it... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 18:55: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2957350F; Fri, 23 Aug 2013 18:55:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED1F82BD3; Fri, 23 Aug 2013 18:55:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BC63BB999; Fri, 23 Aug 2013 14:55:11 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: How to best overload the fileops ? Date: Fri, 23 Aug 2013 13:02:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <521508F4.6030502@rawbw.com> <20130822001022.GA18115@dft-labs.eu> <52155B8D.1020807@rawbw.com> In-Reply-To: <52155B8D.1020807@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308231302.32800.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 23 Aug 2013 14:55:11 -0400 (EDT) Cc: Yuri , John-Mark Gurney , Mateusz Guzik , Roman Divacky , 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, 23 Aug 2013 18:55:13 -0000 On Wednesday, August 21, 2013 8:30:05 pm Yuri wrote: > On 08/21/2013 17:10, Mateusz Guzik wrote: > > Short answer is provide epollops with your own fo_close and the rest as > > it is currently in kqueueops. All function are static, but this is not a > > real problem since you have to modify kern_event.c anyway. > > This is exactly what this code I am asking about is doing. > kqueueops functions are all static. This modification allows to export > fileops to child modules. > Since there is nothing similar in the kernel code, I am asking does this > way look ugly or not. There is something similar: see devfs_ops_f in sys/fs/devfs/devfs_vnops.c. I don't think we need a generic framework for this, just expose the relevant fo_ methods for kqueue ops and use them in your epoll_ops. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 18:55:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 812525C3 for ; Fri, 23 Aug 2013 18:55:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E7CAD2BD4 for ; Fri, 23 Aug 2013 18:55:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C2D24B98A; Fri, 23 Aug 2013 14:55:16 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: OCE driver on Freebsd 10.0-Current Date: Fri, 23 Aug 2013 13:05:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308231305.51726.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 23 Aug 2013 14:55:16 -0400 (EDT) Cc: Venkata Duvvuru 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, 23 Aug 2013 18:55:19 -0000 On Friday, August 23, 2013 4:55:06 am Venkata Duvvuru wrote: > Hi, > > I'm running iperf on Emulex's OCE network adapter in Freebsd-10-current. At > heavy traffic (iperf with ~10 connections), iperf is hanging. The same > driver is working on all other Freebsd versions. > > top -HS shows the below information. > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 11 root 155 ki31 0K 128K CPU4 4 146:36 100.00% idle{idle: cpu4} > > 12 root -60 - 0K 688K CPU6 6 52:38 100.00% intr{swi4: clock} > > 11 root 155 ki31 0K 128K CPU2 2 148:42 99.66% idle{idle: cpu2} > > 11 root 155 ki31 0K 128K CPU7 7 149:24 99.27% idle{idle: cpu7} > > 11 root 155 ki31 0K 128K RUN 0 148:00 99.27% idle{idle: cpu0} > > 11 root 155 ki31 0K 128K CPU1 1 149:44 99.17% idle{idle: cpu1} > > 11 root 155 ki31 0K 128K CPU5 5 148:46 99.17% idle{idle: cpu5} > > 11 root 155 ki31 0K 128K CPU3 3 96:57 89.06% idle{idle: cpu3} > > 11 root 155 ki31 0K 128K RUN 6 149:11 13.87% idle{idle: cpu6} > > > > One interesting thing I observed is that intr is taking 100% on CPU6 when > iperf hangs, while iperf is running fine, the intr WCPU percentage is very > low. What does this below line mean? Why intr is 100% on CPU6?? > > 12 root -60 - 0K 688K CPU6 6 52:38 100.00% intr{swi4: clock} This is the thread that runs timers configured via callout_reset() or timeout(). Those are handled differently in 10 than in older branches. I suspect you have a callout that is rescheduling itself constantly or some such. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 19:24: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 57245F3A for ; Fri, 23 Aug 2013 19:24:05 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AFF52DB9 for ; Fri, 23 Aug 2013 19:24:05 +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 0C63B20AD6 for ; Fri, 23 Aug 2013 15:23:57 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Fri, 23 Aug 2013 15:23:57 -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:in-reply-to:references :subject:date; s=smtpout; bh=IRiM214wCOPB7o9ya8iE75P/onw=; b=fTh 38zGfQysNwRIT3mYSGNrHoaby0ThfyX8V7OLLOZ8PYv9IenNVE/OtLeiP68fZwP7 whBJS3mn8IbYJOLsmrLbz8VtSIh/2pujCB9goZsZGuRpUFyukYTMFEOQCxMM67IS KyPxPaoUcSuU4EJ2ijksnvR4h6FEG5/PwNgLTygM= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id E0D41B02388; Fri, 23 Aug 2013 15:23:56 -0400 (EDT) Message-Id: <1377285836.31114.13416825.5F534A08@webmail.messagingengine.com> X-Sasl-Enc: 8H8/7ol+jcpkOL2qVMfybA9maG/WWzdUt/8SZH3sFTH7 1377285836 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-d009844e In-Reply-To: <5217A7D8.1030806@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <52174D51.2050601@digsys.bg> <21414.1377258940@critter.freebsd.dk> <5217A7D8.1030806@freebsd.org> Subject: Re: GCC withdraw Date: Fri, 23 Aug 2013 14:23:56 -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: Fri, 23 Aug 2013 19:24:05 -0000 On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: > On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: > > In message <52174D51.2050601@digsys.bg>, Daniel Kalchev writes: > > > >>> - 9.x gcc default and clang in base; > >>> - 10.x clang default and gcc in ports; > >> I believe this is the best idea so far. As long as these ports work with > >> gcc in ports, that is. > > +1 > > > well as I was forced to go back to gcc to get a compiling & running > kernel on my VPS (xen) > I'm not convinced that clang is there yet. I'd be really grumpy if I > had to go through al the ports hoopla to recompile my kernel. > > Curious which Xen version. I'd like to try to replicate this issue. I've seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 19:31:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9983C15C for ; Fri, 23 Aug 2013 19:31:12 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5D14B2E2B for ; Fri, 23 Aug 2013 19:31:12 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 31F0C4F1C; Fri, 23 Aug 2013 19:31:11 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 626F62FDF2; Fri, 23 Aug 2013 21:30:34 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa Subject: Re: patch to improve AES-NI performance References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <52177F0B.9020906@sentex.net> <20130823180513.GM94127@funkthat.com> <5217A7B5.8040904@sentex.net> <20130823185241.GO94127@funkthat.com> Date: Fri, 23 Aug 2013 21:30:33 +0200 In-Reply-To: <20130823185241.GO94127@funkthat.com> (John-Mark Gurney's message of "Fri, 23 Aug 2013 11:52:41 -0700") Message-ID: <86d2p419ye.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Ollivier Robert , 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, 23 Aug 2013 19:31:12 -0000 John-Mark Gurney writes: > Mike Tancsa writes: > > John-Mark Gurney writes: > > > My patch would only effect userland applications that use /dev/crypto= ... > > For me its ssh which I think does, no ? > It looks like it uses OpenSSL for it's crypto, not /dev/crypto... It uses OpenSSL engines, which use /dev/crypto. This is why we had to turn off sandbox mode - a CRIOGET ioctl fails because the sandbox code sets RLIMIT_NOFILES to 0. (trimming security@ from the cc: list as it's an alias for secteam@ which is not the appropriate venue for this discussion.) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 20:06:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6FA38BB3; Fri, 23 Aug 2013 20:06:54 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 572A320E5; Fri, 23 Aug 2013 20:06:54 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7NK6ru6028843; Fri, 23 Aug 2013 13:06:53 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <5217C0DC.8050107@rawbw.com> Date: Fri, 23 Aug 2013 13:06:52 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130822 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Baldwin Subject: Re: How to best overload the fileops ? References: <521508F4.6030502@rawbw.com> <20130822001022.GA18115@dft-labs.eu> <52155B8D.1020807@rawbw.com> <201308231302.32800.jhb@freebsd.org> In-Reply-To: <201308231302.32800.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mateusz Guzik , John-Mark Gurney , freebsd-current@freebsd.org, Roman Divacky , 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, 23 Aug 2013 20:06:54 -0000 On 08/23/2013 10:02, John Baldwin wrote: > There is something similar: see devfs_ops_f in sys/fs/devfs/devfs_vnops.c. devfs_ops_f is a local static fileops object for devfs. I don't see how is this similar to our situation. devfs doesn't overload any other file system, they are a file system on their own. > > I don't think we need a generic framework for this, just expose the > relevant fo_ methods for kqueue ops and use them in your epoll_ops. In epoll case, fileops object as a whole should be exposed and used for fp->f_ops, except fo_close which is overloaded. So would you think struct fileops* kqueue_fileops(); be ok then? Yuri From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 20:36:16 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 25DD42A6; Fri, 23 Aug 2013 20:36:16 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB1752253; Fri, 23 Aug 2013 20:36:15 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VCy5Z-000KkT-0G; Fri, 23 Aug 2013 20:36:09 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7NKa5oB048276; Fri, 23 Aug 2013 14:36:05 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19hn89JUu/HLwvQiSGlXL/q Subject: Re: How to best overload the fileops ? From: Ian Lepore To: Yuri In-Reply-To: <5217C0DC.8050107@rawbw.com> References: <521508F4.6030502@rawbw.com> <20130822001022.GA18115@dft-labs.eu> <52155B8D.1020807@rawbw.com> <201308231302.32800.jhb@freebsd.org> <5217C0DC.8050107@rawbw.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Aug 2013 14:36:05 -0600 Message-ID: <1377290165.1111.85.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Mateusz Guzik , current@FreeBSD.org, John-Mark Gurney , freebsd-current@FreeBSD.org, Roman Divacky 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, 23 Aug 2013 20:36:16 -0000 On Fri, 2013-08-23 at 13:06 -0700, Yuri wrote: > On 08/23/2013 10:02, John Baldwin wrote: > > There is something similar: see devfs_ops_f in sys/fs/devfs/devfs_vnops.c. > > devfs_ops_f is a local static fileops object for devfs. I don't see how > is this similar to our situation. devfs doesn't overload any other file > system, they are a file system on their own. > I think the point is that devfs_ops_f provides several devfs-specific methods and then "inherits" the rest by referencing the standard vn_whatever functions. Since John recommended that you expose the fo_whatever methods, I think he's suggesting you build your ops table by providing your own close method and fill in the rest of the table with the now-exposed kqueue ops methods. It's not as neat and clean as "class epollops : public kqueueops {...}" but it's probably not as bad as using clever macros to try to turn C into a sort of C++Lite. -- Ian > > > > I don't think we need a generic framework for this, just expose the > > relevant fo_ methods for kqueue ops and use them in your epoll_ops. > > In epoll case, fileops object as a whole should be exposed and used for > fp->f_ops, except fo_close which is overloaded. > > So would you think struct fileops* kqueue_fileops(); be ok then? > > Yuri > _______________________________________________ > 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 Aug 23 20:51: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BC3ED802 for ; Fri, 23 Aug 2013 20:51:26 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99BE8234A for ; Fri, 23 Aug 2013 20:51:26 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7NKpOmG014182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 13:51:24 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7NKpNLA014181; Fri, 23 Aug 2013 13:51:23 -0700 (PDT) (envelope-from jmg) Date: Fri, 23 Aug 2013 13:51:23 -0700 From: John-Mark Gurney To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: patch to improve AES-NI performance Message-ID: <20130823205123.GQ94127@funkthat.com> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Mike Tancsa , Ollivier Robert , freebsd-current@freebsd.org References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <52177F0B.9020906@sentex.net> <20130823180513.GM94127@funkthat.com> <5217A7B5.8040904@sentex.net> <20130823185241.GO94127@funkthat.com> <86d2p419ye.fsf@nine.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86d2p419ye.fsf@nine.des.no> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 23 Aug 2013 13:51:24 -0700 (PDT) Cc: Ollivier Robert , freebsd-current@freebsd.org, Mike Tancsa 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, 23 Aug 2013 20:51:26 -0000 Dag-Erling Smrgrav wrote this message on Fri, Aug 23, 2013 at 21:30 +0200: > John-Mark Gurney writes: > > Mike Tancsa writes: > > > John-Mark Gurney writes: > > > > My patch would only effect userland applications that use /dev/crypto... > > > For me its ssh which I think does, no ? > > It looks like it uses OpenSSL for it's crypto, not /dev/crypto... > > It uses OpenSSL engines, which use /dev/crypto. This is why we had to > turn off sandbox mode - a CRIOGET ioctl fails because the sandbox code > sets RLIMIT_NOFILES to 0. If it does use /dev/crypto via OpenSSL (see below), OpenSSL only uses CBC mode, which means that only decryption will see any significant performance improvement w/ my changes... Also, how many people know to load the kernel module cryptodev and aesni to use it? OpenSSL should use AES-NI natively instead of using the cryptodev engine since it'll eliminate kernel calls, etc... Hmm... looking at the source for openssl speed, it looks like it only measures CBC encryption speed, not decryption speed, so you won't be able to see the performance difference between encryption and decryption for CBC mode... I'm not sure that even if you set cryptodev engine on -HEAD that it actually uses it... I just did a: ktrace openssl speed -engine cryptodev aes-128-cbc But this is part of the trace: 4377 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffff9ac0) 4377 openssl RET ioctl -1 errno 22 Invalid argument 4377 openssl CALL close(0x4) 4377 openssl RET close 0 4377 openssl CALL write(0x2,0x7fffffff9250,0x18) 4377 openssl GIO fd 2 wrote 24 bytes "engine "cryptodev" set. " 4377 openssl RET write 24/0x18 4377 openssl CALL sigaction(SIGALRM,0x7fffffff9b60,0x7fffffff9b40) 4377 openssl RET sigaction 0 4377 openssl CALL write(0x2,0x7fffffff9270,0x2c) 4377 openssl GIO fd 2 wrote 44 bytes "Doing aes-128 cbc for 3s on 16 size blocks: " 4377 openssl RET write 44/0x2c 4377 openssl CALL setitimer(0,0x7fffffff9b70,0x7fffffff9b50) 4377 openssl RET setitimer 0 4377 openssl CALL getrusage(0,0x7fffffff9ab0) 4377 openssl RET getrusage 0 4377 openssl CALL getrusage(0xffffffff,0x7fffffff9ab0) 4377 openssl RET getrusage 0 4377 openssl PSIG SIGALRM caught handler=0x451550 mask=0x0 code=SI_KERNEL 4377 openssl CALL sigaction(SIGALRM,0x7fffffff9520,0x7fffffff9500) 4377 openssl RET sigaction 0 4377 openssl CALL sigreturn(0x7fffffff9580) 4377 openssl RET sigreturn JUSTRETURN 4377 openssl CALL getrusage(0,0x7fffffff9ab0) 4377 openssl RET getrusage 0 4377 openssl CALL getrusage(0xffffffff,0x7fffffff9ab0) 4377 openssl RET getrusage 0 4377 openssl CALL write(0x2,0x7fffffff9250,0x20) 4377 openssl GIO fd 2 wrote 32 bytes "18712524 aes-128 cbc's in 2.99s " Shouldn't there be a whole host of ioctl's between the Doing print and the x aes-128 cbc's print if it was doing cryptodev? This does explain why the numbers w/ both engine cryptodev and w/o (kernel module unloaded, so not possible to use) were similar... > (trimming security@ from the cc: list as it's an alias for secteam@ > which is not the appropriate venue for this discussion.) > > DES > -- > Dag-Erling Smørgrav - des@des.no > _______________________________________________ > 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" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 20:54:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BBD0E9D4 for ; Fri, 23 Aug 2013 20:54:36 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7DDC42375 for ; Fri, 23 Aug 2013 20:54:36 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VCyPR-000AvD-Us; Sat, 24 Aug 2013 00:56:41 +0400 Date: Sat, 24 Aug 2013 00:56:41 +0400 From: Slawa Olhovchenkov To: Rick Macklem Subject: Re: Diskless setup with NFS_V4 Message-ID: <20130823205641.GY3796@zxy.spb.ru> References: <20130822133520.GA75880@zxy.spb.ru> <1503899038.12819687.1377264755464.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1503899038.12819687.1377264755464.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 23 Aug 2013 20:54:36 -0000 On Fri, Aug 23, 2013 at 09:32:35AM -0400, Rick Macklem wrote: > Slawa Olhovchenkov wrote: > > Its posible use currentle FreeBSD on NFS_V4 root? > > > > Explain: > > > > pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel. > > In this setup kernel can use only configured (established) nfs fh. > > This is not allowed to switch version or some options. > > > > When pxeboot use TFTP (not NFS) kernel (in nfs/bootp_subr.c) do DHCP > > discover and don't allow (in nfs/nfs_diskless.c:nfs_parse_options) > > 'nfsv4' option. > > > > nfs/nfs_diskless.c:nfs_setup_diskless also initialy set > > > > nd3->root_args.flags = (NFSMNT_NFSV3 | NFSMNT_WSIZE | NFSMNT_RSIZE | > > NFSMNT_RESVPORT); > > > > and don't allow 'nfsv4' option. > > > > Where I be wrong? > > How I can use diskless setup with R/O root on NFS_V4 share? > No. There are a couple of problems that would need to be resolved > for an NFSv4 root fs to work. > 1 - An NFSv4 mount needs a unique identifier for the client machine. > It currently uses the host uuid, but that is filled in by a > userland utility run from the root fs (ie. not available soon enough). > Linux uses the ip host address for this, which I believe is bogus > and inappropriate. As I see in /etc/rc.d/hostid first try is 'kenv -q smbios.system.uuid'. This is not need userland utility. > 2 - Without the nfsuserd daemon running, there is currently no uid/gid<-->name > mappings available. This might work, but there would be a lot of "file owned > by nobody" situations that could cause problems. This is ok for kernel loading and is same as NFSv3. > I suspect this can be fixed by hardwiring a few mappings (root, bin,...), > but there is currently no code to do this. > The Linux solution for this is to put the number in a string on the wire > and the updated draft of RFC3530 (called rfc3530bis, not yet an RFC) allows > this, so eventually this will be supported by most/all servers. > > Until 1 and 2 are resolved, doing an NFSv4 root fs mount is not practical. > To be honest, I don't see a need for it, since I'm "old fashioned" and still > believe that the root fs should be a small volume of critical system utilities > only, so an NFSv3 mount of it should be sufficient. (ie. If /var and any > other subtrees where files might get byte range locked are on separate volumes, > I think it should be fine with a NFSv3 root fs mount, even without running rpc.lockd.) I am try to build many diskless workers with fat software. NFSv4 targeting as more fast. And NFSv4 don't have problem with different UIDs. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 20:54:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 052A0BB7; Fri, 23 Aug 2013 20:54:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66EE92385; Fri, 23 Aug 2013 20:54:55 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id k13so965826wgh.13 for ; Fri, 23 Aug 2013 13:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=B6cii8RMsVvpqUUXf7f8r1U29CqcmEkDjUgOtw6+Yv0=; b=QxIi7QWdou+lCjo/oLvzQwPJXs9ce8UL+j6bND6aiKSY4d50D7VteAPlWWjEmrDhHj YMP1ehJTXKv7/VIXHaG7Bme0tgh8DL507WYxm1hiYk88iZhV94+MsFJsOpUsMIFeqVZW Av4vyWDtLVxXd63C8ckOuQIFyMDMRqlnTVaG+gFBW/W6vi0uGxD/RWAFvvJu4wH+JYTX 1RK4IW7/RbZs1nseyYhUM6eXu5I5sHJwVp9VvmzfKIAttqzMiBQaxWJV2Op0pr/17+R3 xaU0hEsdF8lcr96ifMLMS4mZJG7BjxZCZWUO8tMrAinfA1Y/erTw4AeWmJKcYeFWdOVm NwBw== MIME-Version: 1.0 X-Received: by 10.180.37.16 with SMTP id u16mr3472514wij.46.1377291293684; Fri, 23 Aug 2013 13:54:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Fri, 23 Aug 2013 13:54:53 -0700 (PDT) Date: Fri, 23 Aug 2013 13:54:53 -0700 X-Google-Sender-Auth: T1gehd6Gk12njPMV-BcuuI1pU1k Message-ID: Subject: [rfc] migrate lagg to an rmlock From: Adrian Chadd To: FreeBSD Net , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 23 Aug 2013 20:54:56 -0000 Hi, I'd like to commit this to -10. It migrates the if_lagg locking from a rw lock to a rm lock. We see a bit of contention between the transmit and receive sides of lagg during traffic loads (10+ gigabit per second.) Using rmlocks eliminate this. http://people.freebsd.org/~adrian/netflix/20130819-lagg-rmlock-1.diff Thanks, -adrian From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 21:03:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D6868FFB; Fri, 23 Aug 2013 21:03:07 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8FFBC240B; Fri, 23 Aug 2013 21:03:07 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VCyXh-000Ayg-FX; Sat, 24 Aug 2013 01:05:13 +0400 Date: Sat, 24 Aug 2013 01:05:13 +0400 From: Slawa Olhovchenkov To: Adrian Chadd Subject: Re: patch to add AES intrinsics to gcc Message-ID: <20130823210513.GA3796@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <20130823114635.GB64913@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "re@FreeBSD.org Engineering Team" , "current@freebsd.org" , Bernhard Fr?hlich , John-Mark Gurney , David Chisnall , 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: Fri, 23 Aug 2013 21:03:07 -0000 On Fri, Aug 23, 2013 at 06:54:44AM -0700, Adrian Chadd wrote: > Hi! > > If firewire code doesn't build on clang correctly, have you filed a bug so > it gets looked at before 10.0 is released? that's pretty broken > code/behaviour. How I can do it correctly? Currently in src.conf: WITHOUT_CLANG=yes WITHOUT_CLANG_IS_CC=yes Need recompile world? System build from sources Jun 8. clang -- Jan 9. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 21:15: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A1261373; Fri, 23 Aug 2013 21:15:11 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55C7124A8; Fri, 23 Aug 2013 21:15:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Message-ID:Subject:To:From:Date; bh=nSHY/t/rdLfaf5pDZ6XfvvolFUbgDim+BhSbQiHpw8Q=; b=J4gc3c2MtiDzuQTcw23OnTVhC5HLTbvsF8J1WXn78Xk5djPngBjP0DBr19cBPcPJ9vhEFFOjJeKpOB39rQPAnHYbiug2z7enbKusFCwcoiTxeo+bDGnT1eJNmogxJAt6jvdpZsfQIPrlACVZVDPReBHflStXKBfpriDkumdJ5G8=; Received: from [178.137.138.140] (helo=nonamehost.local) by fsm1.ukr.net with esmtpsa ID 1VCyh9-000CGn-Nt ; Sat, 24 Aug 2013 00:14:59 +0300 Date: Sat, 24 Aug 2013 00:14:52 +0300 From: Ivan Klymenko To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: devel/gettext build error in jail i386 environment on amd64 host Message-ID: <20130824001452.71b262ae@nonamehost.local> 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 Authentication-Result: IP=178.137.138.140; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net 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, 23 Aug 2013 21:15:11 -0000 Hello. I have: FreeBSD 10.0-CURRENT #0 r254719 and and jail for i386 environment when building the port devel/gettext I get the following error: http://privatepaste.com/46f9477022 who can tell me what could be the cause of the error and how to fix it? still about a month ago, I successfully compiled the port in jail i386 environment Thanks. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 22:01:16 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3F756DA7; Fri, 23 Aug 2013 22:01:16 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2722C273D; Fri, 23 Aug 2013 22:01:15 +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 A76DB1A3E0F; Fri, 23 Aug 2013 15:01:15 -0700 (PDT) Message-ID: <5217DBAB.5030607@freebsd.org> Date: Fri, 23 Aug 2013 15:01:15 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Chisnall Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> In-Reply-To: <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: toolchain@FreeBSD.org, John-Mark Gurney , =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= , current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 22:01:16 -0000 On 8/23/13 3:35 AM, David Chisnall wrote: > On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote: > >> I don't know if you are aware that IF you really do that we will have serious >> problems to ship packages for 10. USE_GCC=any is the fallback in the >> portstree for all ports that are unable to build with clang which was introduced >> when HEAD switched to clang as default cc. Right now there are 150 ports in >> the tree that use this fallback and quite a few of them are high profile ports: >> >> the highlights: >> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 >> security/clamav >> >> the full list: >> http://dpaste.com/1354075/ >> >> A possible hack could be to add a check for USE_GCC=any to behave like >> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc >> from ports for a lot of people on HEAD I suppose. >> >> We certainly need to do that switch to remove the ancient gcc from base >> some time but with my portmgr hat on I can only say we don't plan to do that >> before 10.0 especially not if we are only talking about a few weeks time window. > That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). > > David > > _______________________________________________ > Why can't ports just then add the old-version of GCC? This tight coupling between src and ports is screwing us over for far too long. If src needs to move on, and it surely seems like it does, then ports needs to adapt. No offense to either team, but this is just common sense. From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 22:18:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D888221A; Fri, 23 Aug 2013 22:18:41 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id BE308281C; Fri, 23 Aug 2013 22:18:41 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7NMIe29057242; Fri, 23 Aug 2013 15:18:40 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <5217DFC0.7070708@rawbw.com> Date: Fri, 23 Aug 2013 15:18:40 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130822 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: How to best overload the fileops ? References: <521508F4.6030502@rawbw.com> <20130822001022.GA18115@dft-labs.eu> <52155B8D.1020807@rawbw.com> <201308231302.32800.jhb@freebsd.org> <5217C0DC.8050107@rawbw.com> <1377290165.1111.85.camel@revolution.hippie.lan> In-Reply-To: <1377290165.1111.85.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John-Mark Gurney , Mateusz Guzik , current@freebsd.org, Roman Divacky , 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, 23 Aug 2013 22:18:41 -0000 On 08/23/2013 13:36, Ian Lepore wrote: > I think the point is that devfs_ops_f provides several devfs-specific > methods and then "inherits" the rest by referencing the standard > vn_whatever functions. Since John recommended that you expose the > fo_whatever methods, I think he's suggesting you build your ops table by > providing your own close method and fill in the rest of the table with > the now-exposed kqueue ops methods. So you are suggesting to just make kqueue fileops public? This was my first suggestion, and this was rejected by Roman Divacky (who was supposed to check it in) as very ugly. I did this through the method kqueue_ops(), not directly though. So can we agree on way to be used here? Way#1: struct fileops* kqueue_fileops() which is used as the base for epoll fileops. Way#2: make kqueueops public and use as a base for epoll. > > It's not as neat and clean as "class epollops : public kqueueops {...}" > but it's probably not as bad as using clever macros to try to turn C > into a sort of C++Lite. Whatever makes code more clear is better. I don't think I suggested to turn C into anything. Yuri From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 22:43:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 99EDB7D7 for ; Fri, 23 Aug 2013 22:43:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DB50299E for ; Fri, 23 Aug 2013 22:43:40 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id v19so1266313obq.39 for ; Fri, 23 Aug 2013 15:43:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=fCa96hHT09vZYKsMml2pu3r0dMr5x18tp0uOx0IG7Ys=; b=WfZ7nnEJuqRePM+rhxpdCjvPuCCWvg0o+mUEsVKMhSe5Efrc7dNhov06K1kcLdmcm/ 6F2dEyrQp0bqNJVJgEcFvYWtfvQpfOoMpedQlODsxQslpBIJWgURFbdU4UY2zoln6iOX rkLe061kBzCbJbC55Ozy7ZRQqXWl6WJ6w2l0KrHxAKJ86TEq0m5noTGIp5FUXbENzJoS LiNgQUKverHrnKazS/rgGPhZcA/I+GjbwuTn0iL5MRpqoOPZr4PC7ESu6EIl9IPj/j8C M7P5vVkTdThG0MweiFnBnnZaCw0yyl9SYi2TiDF5dlEZTY41ch/dI1qKIHGV3PBcay5J bpBA== X-Gm-Message-State: ALoCoQknD0Nle4cHP7VCGcTiSZ0zS1223twa0lzcmLBqyxWAc5OBrbdWmDsgHRFp+kbUU8zMK2s8 X-Received: by 10.60.124.14 with SMTP id me14mr1745298oeb.4.1377297474066; Fri, 23 Aug 2013 15:37:54 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id qi5sm2052749obb.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 15:37:53 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: <5217DBAB.5030607@freebsd.org> Date: Fri, 23 Aug 2013 16:37:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1085) Cc: toolchain@FreeBSD.org, John-Mark Gurney , David Chisnall , current@FreeBSD.org, "re@FreeBSD.org Engineering Team" 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, 23 Aug 2013 22:43:41 -0000 On Aug 23, 2013, at 4:01 PM, Alfred Perlstein wrote: > On 8/23/13 3:35 AM, David Chisnall wrote: >> On 23 Aug 2013, at 10:58, Bernhard Fr=F6hlich = wrote: >>=20 >>> I don't know if you are aware that IF you really do that we will = have serious >>> problems to ship packages for 10. USE_GCC=3Dany is the fallback in = the >>> portstree for all ports that are unable to build with clang which = was introduced >>> when HEAD switched to clang as default cc. Right now there are 150 = ports in >>> the tree that use this fallback and quite a few of them are high = profile ports: >>>=20 >>> the highlights: >>> audio/nas devel/mingw32-binutils emulators/qemu = emulators/virtualbox-ose >>> emulators/wine lang/go lang/v8 mail/courier math/fftw3 = multimedia/libxine >>> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 >>> security/clamav >>>=20 >>> the full list: >>> http://dpaste.com/1354075/ >>>=20 >>> A possible hack could be to add a check for USE_GCC=3Dany to behave = like >>> a USE_GCC=3Dyes on HEAD on the affected platforms. This pulls in = lang/gcc >>> from ports for a lot of people on HEAD I suppose. >>>=20 >>> We certainly need to do that switch to remove the ancient gcc from = base >>> some time but with my portmgr hat on I can only say we don't plan to = do that >>> before 10.0 especially not if we are only talking about a few weeks = time window. >> That is unfortunate. We have said for over a year that 10.0 should = not ship with gcc. I can delay committing the patch to flip the switch = until later in the code slush, if re approves, but ports that require = gcc should be building with gcc from ports (which will also improve code = quality, as gcc 4.6/7 produce significantly better code than 4.2.1). >>=20 >> David >>=20 >> _______________________________________________ >>=20 > Why can't ports just then add the old-version of GCC? This tight = coupling between src and ports is screwing us over for far too long. ports already has various gcc versions in ports, needed for dozens of = ports that require newer gcc, and this could be adopted for the gcc from = base issue. But that's not the issue. It is making the ports that need = it use it, and from the quoted message it sounds like that would take = work. Work takes time, and the window is closing. > If src needs to move on, and it surely seems like it does, then ports = needs to adapt. I'd dispute the 'and surely it seems like it does' part of this. Non x86 = architectures will continue to use gcc because clang just isn't ready at = this time for them. Some are very close (arm), some are close = (powerpc64, mips*), some are no where near ready, or will never be ready = (sparc64, ia64). There's no coherent, documented plan for these absent = gcc at the moment. There are lots of pieces there, and those pieces will = form the basis of the solution (+handbook updates) for the removal of = gcc in 11, but we just aren't there yet. > No offense to either team, but this is just common sense. The only ones that would really matter are ones in any bootstrap path we = might need for external toolchains. Since qemu is the basis for cross = building ports, it is disturbing to see that on the list. I know qemu = has, in the past, been sensitive to compiler versions, as are many of = the emulators in the tree. It might not be a simple matter to just use = gcc 4.6 or 4.7 for some of the items on the list. When I've moved gcc = versions and had problems with FOSS it is either due to new = warnings/errors and language violations. Some of these are trivial to = fix, others reveal fundamental flaws in the code and many changes are = needed. Sometimes newer compilers also have optimizations bugs (as = opposed to language violations now optimized differently) which break = things at run-time, despite things appearing to compile. These aren't = insurmountable problems, but do take time to implement and test. Warner From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 00:44:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF6DDB24; Sat, 24 Aug 2013 00:44:32 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 312B12F7F; Sat, 24 Aug 2013 00:44:32 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7O0iL2o065728; Fri, 23 Aug 2013 20:44:26 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521801E5.9000309@m5p.com> Date: Fri, 23 Aug 2013 20:44:21 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> In-Reply-To: <52174378.2020101@m5p.com> Content-Type: multipart/mixed; boundary="------------060606030503080406090409" X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Fri, 23 Aug 2013 20:44:28 -0400 (EDT) Cc: freebsd-arm@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: Sat, 24 Aug 2013 00:44:32 -0000 This is a multi-part message in MIME format. --------------060606030503080406090409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/23/13 07:11, George Mitchell wrote: > On 08/23/13 02:18, Hans Petter Selasky wrote: >> On 08/23/13 02:29, George Mitchell wrote: >>> On 08/22/13 07:34, Hans Petter Selasky wrote: >> >>> Here's the result: >>> [...] >>> (at which point if I type control-c to stop usbdump, the system gets a >>> fatal kernel mode translation fault, but that's another story.) Hope >>> this helps. -- George >> >> I would expect to see some messages ERR != 0 when you plug the device. >> Can you show both usbdump output and dmesg output which belongs together? >> >> --HPS > > Not sure exactly how I would get the usbdump output and log output > interspersed in the correct order, and the fact that the pi panics > when I type control-C at usbdump doesn't help. Subjectively, the > "ulpt0 attach returned 12" seemed to occur a fraction of a second > later than the others. But I'll see what I can come up with this > evening. -- George Well, what I ended up doing is turning on ulpt debugging and then piping usbdump into logger, yielding the attachment. But I'm not 100% sure that the output is in the proper sequence. Give that the printer works fine with the same code on my amd64 machines, does this suggest we have a byte-ordering problem in the driver? -- George --------------060606030503080406090409 Content-Type: text/plain; charset=us-ascii; name="ulpt.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ulpt.txt" Aug 24 00:10:24 pi kernel: ugen0.5: at usbus0 Aug 24 00:10:24 pi kernel: ulpt_probe: Aug 24 00:10:24 pi kernel: ulpt_probe: Aug 24 00:10:24 pi kernel: ulpt_attach: sc=0xc2d46a00 Aug 24 00:10:24 pi kernel: ulpt0: on usbus0 Aug 24 00:10:24 pi kernel: ulpt_attach: setting alternate config number: 0 Aug 24 00:10:24 pi kernel: ulpt_attach: error=USB_ERR_INVAL Aug 24 00:10:24 pi kernel: ulpt_detach: sc=0xc2d46a00 Aug 24 00:10:24 pi kernel: device_attach: ulpt0 attach returned 12 Aug 24 00:10:24 pi george: 00:08:02.619534 usbus0.5 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.620189 usbus0.5 DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.620282 usbus0.5 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.621186 usbus0.5 DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.638617 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.640299 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.640802 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.643668 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.643831 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.646289 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.646389 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.648294 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.648404 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.650283 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.650380 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.658667 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=16,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.658783 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.661289 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.661386 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.664291 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=44,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.664404 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.666289 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.666387 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.668663 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=28,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.668850 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.671284 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=12,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.671411 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.678038 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=32,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.678144 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.680296 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.680394 usbus0.5 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.681663 usbus0.5 DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.899835 usbus0.5 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:10:22.900725 usbus0.5 DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.900822 usbus0.5 SUBM-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0 Aug 24 00:10:24 pi george: 00:10:22.901733 usbus0.5 DONE-CTRL-EP=00000000,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.918759 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:10:22.920837 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.921351 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:10:22.924208 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.924372 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:10:22.926830 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.926932 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:10:22.928822 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.928932 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:10:22.930819 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.930916 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:10:22.937950 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=16,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.938104 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:10:22.939826 usbus0.5 DONE-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:10:22.939926 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 --------------060606030503080406090409-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 01:35:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 92ADF20A; Sat, 24 Aug 2013 01:35:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6342B21A6; Sat, 24 Aug 2013 01:35:24 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r7O1ZH8h003086 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 18:35:22 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <52180DD0.3080308@freebsd.org> Date: Sat, 24 Aug 2013 09:35:12 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Felder Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <52174D51.2050601@digsys.bg> <21414.1377258940@critter.freebsd.dk> <5217A7D8.1030806@freebsd.org> <1377285836.31114.13416825.5F534A08@webmail.messagingengine.com> In-Reply-To: <1377285836.31114.13416825.5F534A08@webmail.messagingengine.com> 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: Sat, 24 Aug 2013 01:35:24 -0000 On 8/24/13 3:23 AM, Mark Felder wrote: > On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: >> On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: >>> In message <52174D51.2050601@digsys.bg>, Daniel Kalchev writes: >>> >>>>> - 9.x gcc default and clang in base; >>>>> - 10.x clang default and gcc in ports; >>>> I believe this is the best idea so far. As long as these ports work with >>>> gcc in ports, that is. >>> +1 >>> >> well as I was forced to go back to gcc to get a compiling & running >> kernel on my VPS (xen) >> I'm not convinced that clang is there yet. I'd be really grumpy if I >> had to go through al the ports hoopla to recompile my kernel. >> >> > Curious which Xen version. I'd like to try to replicate this issue. I've > seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. I don't know.. whatever RootBSD run, but the fact that I needed gcc for anything suggests that we should keep it around for a while. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 04:26:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 26D587BC for ; Sat, 24 Aug 2013 04:26:57 +0000 (UTC) (envelope-from hyama99@gmail.com) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEA4429E6 for ; Sat, 24 Aug 2013 04:26:56 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id e13so928091vbg.17 for ; Fri, 23 Aug 2013 21:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=M9oRd33hq5oxvLJUj9WcNZUwbwhsV8kvpYo5/x+P4wk=; b=cqCmMHzGdg7fQye8lIU6FaduBGRQaE9WwtzHpdd9nnJg9aRed8czvNA2rcKk6ZIKY8 x++Aj5nc8QjAWoKntD6TL2OYadltuCUpPcF6/bPqkF8Lf9mWooh7XILq5Sd7nHKvf6l0 UX03dMBD5cCDmvFn81cEj6Ns4wzvQTQzPYIgBRU7PStud0YKkHNcqhoUGG0Rtxc0wden zDXZTvT02sKDaUm3hLjR53JrIH5Wmt5G2vNhmwd2V3SMBdJ4KuZNE8P1cPPppkKCdxVC YTmUHm+hbC+zp+4nAB71t5bFBPpVG2BECgK07+zhUdRVlaKA7Yd0K5u02GvJUlt8pGYU 7kTA== MIME-Version: 1.0 X-Received: by 10.220.164.70 with SMTP id d6mr2578609vcy.19.1377318415963; Fri, 23 Aug 2013 21:26:55 -0700 (PDT) Received: by 10.52.170.36 with HTTP; Fri, 23 Aug 2013 21:26:55 -0700 (PDT) Date: Sat, 24 Aug 2013 13:26:55 +0900 Message-ID: Subject: pkgng From: Hideki Yamamoto To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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, 24 Aug 2013 04:26:57 -0000 Hi, As I moved from old pkg_xxx to pkg2ng. But I cannot install any new packages as follows: # rm -f /var/db/pkg* # pkg2ng # pkg install gs freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 - - - - freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 # echo $? 3 # # gsview gsview: Command not found. Does someone help me? Thanks in advance. Hideki Yamamoto From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 06:04: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D51314AF for ; Sat, 24 Aug 2013 06:04:02 +0000 (UTC) (envelope-from hyama99@gmail.com) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 963722D7A for ; Sat, 24 Aug 2013 06:04:02 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id pb11so976855veb.25 for ; Fri, 23 Aug 2013 23:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ewwLJHvxlPoPQHxHgrjiHhsEvCEB26qfCuSgQW0kD9g=; b=wzGz1BeN7TqMHbNZCSGrHZHUZkUmrdbuJ7Ht9ZAtCHYv1hQdS8myaJ0aeN5qXGixrt ANXECP8T7bMz+6PC6KZ/CMSsF5GtGCUsfce/DgOqOfscNzSEdI7eadM6378BF8uulkkp GMKy2dtzivTPlpNMYrFUXpmnQFaLzpHJBU1m578gS7tdnjwotJoh8mZ864k9WKGcawt3 AahAYNbzDB9R/KbMnxUNWYNB0T/0YbrhQhSddHNphRfA6IB8vWLpYTj4JBdw8tIe58Dy yq4aj0w/m48SCn5+vRjDoemhwX2OI/iLZsrN64akqo26pKsjGv/m+MqCBhVZOdjt002n O3aQ== MIME-Version: 1.0 X-Received: by 10.220.140.69 with SMTP id h5mr2966866vcu.0.1377324241676; Fri, 23 Aug 2013 23:04:01 -0700 (PDT) Received: by 10.52.170.36 with HTTP; Fri, 23 Aug 2013 23:04:01 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Aug 2013 15:04:01 +0900 Message-ID: Subject: Re: pkgng From: Hideki Yamamoto To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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, 24 Aug 2013 06:04:03 -0000 Hi, I solved my problem by myself. I update PACKAGESITE in /usr/local/etc/pkg.conf in accordance with the information in another expert web site. --- 2013/8/24 Hideki Yamamoto > > Hi, > > As I moved from old pkg_xxx to pkg2ng. > But I cannot install any new packages as follows: > > # rm -f /var/db/pkg* > > # pkg2ng > > # pkg install gs > > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 > - > - > - > - > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 > > # echo $? 3 # > # gsview > gsview: Command not found. > > > > Does someone help me? > > Thanks in advance. > > Hideki Yamamoto > > > From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 06:13:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9E446605; Sat, 24 Aug 2013 06:13:38 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 56FB02DC9; Sat, 24 Aug 2013 06:13:38 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 2C1637A261; Sat, 24 Aug 2013 08:13:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id BFE308F41FC; Sat, 24 Aug 2013 08:13:47 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-sBjsbdhziC; Sat, 24 Aug 2013 08:13:47 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id E1DA78F41FB; Sat, 24 Aug 2013 08:13:46 +0200 (CEST) Message-ID: <52184F59.5080100@bitfrost.no> Date: Sat, 24 Aug 2013 08:14:49 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: George Mitchell Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> In-Reply-To: <521801E5.9000309@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@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: Sat, 24 Aug 2013 06:13:38 -0000 On 08/24/13 02:44, George Mitchell wrote: > On 08/23/13 07:11, George Mitchell wrote: >> On 08/23/13 02:18, Hans Petter Selasky wrote: >>> On 08/23/13 02:29, George Mitchell wrote: >>>> On 08/22/13 07:34, Hans Petter Selasky wrote: >>> > Give that the printer works fine with the same code on my amd64 > machines, does this suggest we have a byte-ordering problem in the > driver? -- George Hi, I looked at the code and your debug prints, and it looks like the usbd_transfer_setup() function is to blame. To get further debugging here, you need to enable hw.usb.debug=15 and hw.usb.dwcotg.debug=15 or something like that. error = usbd_transfer_setup(uaa->device, &iface_index, sc->sc_xfer, ulpt_config, ULPT_N_TRANSFER, sc, &sc->sc_mtx); I think this should be trivial to fix one the cause is found. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 07:46:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DB872EAA; Sat, 24 Aug 2013 07:46:45 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [178.238.39.38]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF2520B3; Sat, 24 Aug 2013 07:46:45 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 5EB4F1CC5840; Sat, 24 Aug 2013 09:41:04 +0200 (CEST) Date: Sat, 24 Aug 2013 09:41:04 +0200 From: Roman Divacky To: Julian Elischer Subject: Re: GCC withdraw Message-ID: <20130824074104.GA31021@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <52174D51.2050601@digsys.bg> <21414.1377258940@critter.freebsd.dk> <5217A7D8.1030806@freebsd.org> <1377285836.31114.13416825.5F534A08@webmail.messagingengine.com> <52180DD0.3080308@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52180DD0.3080308@freebsd.org> 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, 24 Aug 2013 07:46:45 -0000 On Sat, Aug 24, 2013 at 09:35:12AM +0800, Julian Elischer wrote: > On 8/24/13 3:23 AM, Mark Felder wrote: > > On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: > >> On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: > >>> In message <52174D51.2050601@digsys.bg>, Daniel Kalchev writes: > >>> > >>>>> - 9.x gcc default and clang in base; > >>>>> - 10.x clang default and gcc in ports; > >>>> I believe this is the best idea so far. As long as these ports work with > >>>> gcc in ports, that is. > >>> +1 > >>> > >> well as I was forced to go back to gcc to get a compiling & running > >> kernel on my VPS (xen) > >> I'm not convinced that clang is there yet. I'd be really grumpy if I > >> had to go through al the ports hoopla to recompile my kernel. > >> > >> > > Curious which Xen version. I'd like to try to replicate this issue. I've > > seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. > I don't know.. whatever RootBSD run, but the fact that I needed gcc > for anything suggests that we should keep it around for a while. Why do you need to use gcc for everything? What happens if you use clang? Be specific, without details this is just FUD. Roman From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 09:46:37 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3E867FAB; Sat, 24 Aug 2013 09:46:37 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A71924CC; Sat, 24 Aug 2013 09:46:36 +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 r7O9kXPe008896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Aug 2013 09:46:34 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: patch to add AES intrinsics to gcc From: David Chisnall In-Reply-To: Date: Sat, 24 Aug 2013 10:46:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7D444AD2-D5DD-4F3A-BF43-720D68009657@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <521751AF.6040905@gmail.com> To: =?iso-8859-1?Q?Bernhard_Fr=F6hlich?= X-Mailer: Apple Mail (2.1508) Cc: toolchain@FreeBSD.org, Volodymyr Kostyrko , John-Mark Gurney , 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, 24 Aug 2013 09:46:37 -0000 On 23 Aug 2013, at 13:30, Bernhard Fr=F6hlich wrote: > lang/gcc42 is on the list of ports that have USE_GCC=3Dany. So you = would need > to fix it first to be able to compile it with clang 3.3 from base. What is the issue with the gcc 4.2.1 build (aside from the fact that it = has a terrifying number of warnings when built with any recent = compiler)? The gcc 4.2.1 in base builds with clang - that's how we = currently build it in head... David From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 09:52:27 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7A881197; Sat, 24 Aug 2013 09:52:27 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4875E250A; Sat, 24 Aug 2013 09:52:26 +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 r7O9qOPM008921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Aug 2013 09:52:25 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <52180DD0.3080308@freebsd.org> Date: Sat, 24 Aug 2013 10:52:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <52174D51.2050601@digsys.bg> <21414.1377258940@critter.freebsd.dk> <5217A7D8.1030806@freebsd.org> <1377285836.31114.13416825.5F534A08@webmail.messagingengine.com> <52180DD0.3080308@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1508) 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, 24 Aug 2013 09:52:27 -0000 On 24 Aug 2013, at 02:35, Julian Elischer wrote: > I don't know.. whatever RootBSD run, but the fact that I needed gcc = for anything suggests that we should keep it around for a while. Please point to the FreeBSD PRs and clang bug reports that you have = filed about this. I have been running a FreeBSD VM on Xen with the = clang is cc option for over a year and not encountered this problem. David From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 10:05:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8817259A; Sat, 24 Aug 2013 10:05:25 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50345258B; Sat, 24 Aug 2013 10:05:24 +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 r7OA5KEV009048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Aug 2013 10:05:21 GMT (envelope-from theraven@freebsd.org) Content-Type: multipart/signed; boundary="Apple-Mail=_69A682A3-CBD1-4732-B617-BCAE64BAB327"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: patch to add AES intrinsics to gcc From: David Chisnall In-Reply-To: <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> Date: Sat, 24 Aug 2013 11:05:15 +0100 Message-Id: <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1508) Cc: toolchain@freebsd.org, John-Mark Gurney , Alfred Perlstein , "re@FreeBSD.org Engineering Team" , 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, 24 Aug 2013 10:05:25 -0000 --Apple-Mail=_69A682A3-CBD1-4732-B617-BCAE64BAB327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 23 Aug 2013, at 23:37, Warner Losh wrote: > I'd dispute the 'and surely it seems like it does' part of this. Non = x86 architectures will continue to use gcc because clang just isn't = ready at this time for them. Some are very close (arm), some are close = (powerpc64, mips*), some are no where near ready, or will never be ready = (sparc64, ia64). There's no coherent, documented plan for these absent = gcc at the moment. There are lots of pieces there, and those pieces will = form the basis of the solution (+handbook updates) for the removal of = gcc in 11, but we just aren't there yet. The plan, which has been discussed on mailing lists, on IRC, and at = DevSummits is for tier 2 ports to depend on an external toolchain. For = those vendors that are not prevented from using GPLv3 compilers, this = means that they will be able to take advantage of, for example, the = significant improvements to the MIPS and PowerPC back ends that gcc has = had over the last 6 years. For everyone else, it will mean installing a = compiler from ports. For now, tier 2 architectures will continue to build a toolchain from = the src tree and use that. By 11.0, gcc will be gone from the base = system and they will be required to use something external if they are = not supported by clang. Brooks has been working hard on making this = easy, and it is generally an improvement for cross-building embedded = systems as the cross-compile toolchain is no longer rebuilt every time = you change a file in the kernel, resulting in faster builds. It is also = easier to use toolchains provided by chip vendors, which is something = that MIPS and ARM vendors have been asking for for a very long time. =20 For x86 and ARMv6/7, Clang has been the default compiler for a long time = and gcc has been increasingly problematic (for example, our gcc does not = support ARM EABI, which will be the default in 10.0 for ARMv6 and later, = so if you want to build for a modern ARM chip then you need either clang = or a more recent gcc than we ship). Claiming that this is something = done at the expense of non-x86 architectures is highly misleading, as = improving ARM support is one of the driving factors behind the switch. If you are shipping a product that relies on gcc, then for the 10.x = timeframe, you are free to build and use the gcc from the base system, = and the tinderboxes will prevent any non-optional components from being = modified in such a way that they can't build with this gcc. In the 11.x = timeframe, architectures that aren't supported by clang will need an = external toolchain. =20 AMD, Intel, AMD, Oracle, ARM, and MIPS are all actively contributing to = LLVM and Clang, so the only platform that is unlikely to have an LLVM = back end in the 11.0 timeframe is IA64, and if you really care about = IA64 then Intel will happily sell you a compiler that does a much better = job than GCC of targeting this architecture. David --Apple-Mail=_69A682A3-CBD1-4732-B617-BCAE64BAB327 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 iQIcBAEBAgAGBQJSGIVbAAoJEKx65DEEsqId0egQAMvbN7D098fi3SlVoIPiiQFA 28ZZuzTOTFqN/Oa8J91TmpQXBCF08D5S0zVYU1lTCzdvb8YpL++uTCvcaa3C5/19 xsSX0Z67JPq72PTIt3uWAjzDbYWAkZI8KugCQAxhlrI+eYFQ4MvqUPT084+FlzN6 3pRZ00npFz51DSME2/kJoTu50QkdAhACij1bcNcndGRns4Z0HgbNPGuIJnx0/Ix8 3ZuxiCOCrtvWCHQfrJWA51vroY+z6vHKpylX+IvFqyI6XJNI4lIViGD0r1fikkq7 DD33jL3qC7Yc6cJchJfmd8iURWJOztNn1rydukoFjXR86kmja4ekeG9JxIGiQidQ uGE4VPtTltUwv7d1UI+XTEQSLi02hqoVbW6oUHVp30Kw5uGaRKt9H9xtIz+3U+l9 gRiSBd8fxn2yhpqHTsGsQ2p5EYpKP0TOEIeWCmuA51V/dciUEwRG3dMF6goXoM42 yjoeWd9m234YDFRq1HPr/0RzuTMXb8YN3S+2IpBXOL8PRXZk6RyR0P8AncH62Bgs ld4P0Z5DkJ1R0DgnR4AYZAp04rfSWiCmVdvKXp+YFTlNfn484WVWKOUlQZCizCsb TDAVg4cEkV4bwsZguCmgwahyJ5LDxiLBZ3Ouph6dOSYK4TThtNhdYR3pAzIofSLV o+2fKlJOcZeiCK6CmDFt =09Fb -----END PGP SIGNATURE----- --Apple-Mail=_69A682A3-CBD1-4732-B617-BCAE64BAB327-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 10:30:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4212DB0F; Sat, 24 Aug 2013 10:30:26 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E384E2675; Sat, 24 Aug 2013 10:30:25 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id c13so1058861vea.24 for ; Sat, 24 Aug 2013 03:30:25 -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=NsyY9RKbDWjWGPwI3d2k/coa2u0cbHz79uH+kd0/Hi4=; b=xhon9Zr1VVXsi7ugO7FQXD2mkdE/S+Mgl0JOoijFk/PRHTrotQaDK9kSzNGony0P0O DKRWkLQusiASc1nl55fsbl7E2rgPQr+w72N1Ru/KhBTavYQLCRa+dRzy8FOQdh67XBbY 5fRTPzrls+uNWacL9ilb5g5ZcQik2n/gzkTJEcMiGU6opx0/GL2S1y1RMWY8nzYy3WYu y03BWQ0lmitW9daf+vV6JGWU6RE1SlEWm8T+RyO5ibPI6VgMZcQ7KIbrv9KgwhwAmPVb Yjpo/S0yT0eOhCQpwRveDeI9dkDHBgGbaKdCqwIT0JMIWoYicsuqIotZltvkRS3QV/bo AVVQ== MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr3909053vcb.16.1377340224997; Sat, 24 Aug 2013 03:30:24 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Sat, 24 Aug 2013 03:30:24 -0700 (PDT) In-Reply-To: <521745F2.8050607@passap.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> Date: Sat, 24 Aug 2013 06:30:24 -0400 Message-ID: Subject: Re: GCC withdraw From: "Sam Fourman Jr." To: Boris Samorodov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: toolchain@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: Sat, 24 Aug 2013 10:30:26 -0000 > If the 150 ports that only work with gcc, all work with a ports > > gcc and do not need the gcc from base, would the following be OK ? > > > > - 9.x gcc default and clang in base; > > - 10.x clang default and gcc in ports; > > Well, we write rules and we brake them. ;-) > > Just say that we know we brake them but it's inevitable because... > And go futher. > I am not a developer, just a user, so I am not versed in all of the issues but I would REALLY like to see gcc moved to ports for 10.x In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. FreeBSD as a community made the decision to move to clang as a compiler, and moving gcc to ports enforces that decision, I prefer the "rip the band aid off" approach because it brings issues to light faster, and now people have real reasons to fix things. Now, I am aware that other architectures like ARM etc. need gcc in base for basic things like building kernel/world, because clang cant do this yet. Maybe this is over simplifying it a bit but can't we just modify scripts in some way to pull gcc from ports into base, for these platforms at build time? SVN *is* in base now (svnlite) >From an outside look at this, it seems to me that we're holding back the amd64 platform just because the developer activity is a little more sparse than we would prefer on other platforms. Other platforms are important and they are needed, but those platforms are the ones that need patched up, they are the ones that need the band-aids implemented so that gcc still works for them. So I vote, let's not give ourselves the burden of "lugging" dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) So in the name of progress, let's make a comfortable final resting place for gcc in our ports tree and look to clang for our future. Thoughts, Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 11:19:31 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 36DE075E; Sat, 24 Aug 2013 11:19:31 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04F892865; Sat, 24 Aug 2013 11:19:30 +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 r7OBJRgJ009537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Aug 2013 11:19:29 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: Date: Sat, 24 Aug 2013 12:19:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> To: "Sam Fourman Jr." X-Mailer: Apple Mail (2.1508) Cc: toolchain@FreeBSD.org, Boris Samorodov , 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: Sat, 24 Aug 2013 11:19:31 -0000 On 24 Aug 2013, at 11:30, "Sam Fourman Jr." wrote: > So I vote, let's not give ourselves the burden of "lugging" dead = weight in > base > for another 5 years. (in 2017 do we still want to be worrying about = gcc in > base?) Perhaps more to the point, in 2017 do we want to be responsible for = maintaining a fork of a 2007 release of gcc and libstdc++? David From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 11:24: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BE05A9F7; Sat, 24 Aug 2013 11:24:50 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC1928B5; Sat, 24 Aug 2013 11:24:50 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 5993B7A25D; Sat, 24 Aug 2013 13:24:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 029AA8F4241; Sat, 24 Aug 2013 13:25:00 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP2UdfqEysGn; Sat, 24 Aug 2013 13:24:59 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 47E358F4240; Sat, 24 Aug 2013 13:24:59 +0200 (CEST) Message-ID: <52189849.90405@bitfrost.no> Date: Sat, 24 Aug 2013 13:26:01 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ivan Klymenko Subject: Re: devel/gettext build error in jail i386 environment on amd64 host References: <20130824001452.71b262ae@nonamehost.local> In-Reply-To: <20130824001452.71b262ae@nonamehost.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-ports@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, 24 Aug 2013 11:24:50 -0000 On 08/23/13 23:14, Ivan Klymenko wrote: > wing error: > http://privatepaste.com/46f9477022 Not sure if this helps: https://wiki.freebsd.org/PkgPrimer Using portbuilder inside a jail When building 9-stable ports in a 9-stable jail under -current you might want to set the UNAME_r enviroment variable to fake the FreeBSD version in /path_to_my_jail/root/.cshrc . Some examples: setenv UNAME_r 9-STABLE setenv UNAME_r 8-STABLE setenv UNAME_r 7-STABLE Else some ports won't build properly. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 11:42: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22985E04 for ; Sat, 24 Aug 2013 11:42:14 +0000 (UTC) (envelope-from pawelbsd@gmail.com) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACD88298B for ; Sat, 24 Aug 2013 11:42:13 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id d17so742609eek.28 for ; Sat, 24 Aug 2013 04:42:12 -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-transfer-encoding; bh=9nThuatfXA6CQwQsUJegbT5kbAaHd78Xi2y4QEqoUDQ=; b=DFadnYlVF3c/7LTGSdh+kS/1qyXbu7t6VIObaJ5ahlhQ1rcSNzB7sjjYDbPE/gy6bw CksBTNIHTad9sNLVjvFOilmAthRTsDKugxwOiTKIZjeVvR8OzdxH8x2F9sS/0cALshVE Tw6udqg4MxvPoBtKxzDf5J9QqKfD9DeeNCmS2y1rnnX0VOgdTkcgTCddBubNGBxjon21 CljtUYhjQEOlhzpBXg4+7vepXjm/jayAZi4u2b6mQ1rqvrqpgl/8w+2jFjDVC36rJUMF fiyTLXvVmeL3Wh+bNsioMyEO115PuHDtgPqXSrfA7Cky1baKEyzyk6kNO6T/5xn/AV1v Vq9Q== X-Received: by 10.14.219.8 with SMTP id l8mr272051eep.70.1377344531982; Sat, 24 Aug 2013 04:42:11 -0700 (PDT) Received: from localhost ([176.109.164.5]) by mx.google.com with ESMTPSA id a6sm6322901eei.10.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 24 Aug 2013 04:42:10 -0700 (PDT) Sender: =?UTF-8?B?UGF3ZcWCIFDEmWthbGE=?= Date: Sat, 24 Aug 2013 13:39:36 +0200 From: Pawel Pekala To: freebsd-current@freebsd.org Subject: urtw(4) disconnect problems Message-ID: <20130824133936.76e571bc@FreeBSD.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 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: Sat, 24 Aug 2013 11:42:14 -0000 Hi, I'm having problems with frequent disconnects of my AirLive WL-1600USB hardware. After this happens the all reconnects fail and the only way to fix it is to reboot the machine, while reboot I get this kernel panic: http://people.freebsd.org/~pawel/urtw-panic.jpg Sadly when I get to this my USB keyboard is non operational anymore. My system: FreeBSD blaviken.slowicza.org 10.0-CURRENT FreeBSD 10.0-CURRENT #30 r254760M: Sat Aug 24 10:24:42 CEST 2013 corn@blaviken.slowicza.org:/usr/obj/usr/src/sys/BLAVIKEN64 amd64 Disconnect errors part of dmesg: wpa_supplicant[1382]: wlan0: Authentication with bc:ae:c5:c4:8c:98 timed ou= t. wpa_supplicant[1382]: wlan0: CTRL-EVENT-DISCONNECTED bssid=3Dbc:ae:c5:c4:8c= :98 reason=3D3 locally_generated=3D1 wpa_supplicant[1382]: ioctl[SIOCS80211, op=3D20, val=3D0, arg_len=3D7]: Can= 't assign requested address --=20 pozdrawiam / with regards Pawe=B3 P=EAkala From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 11:45: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75568F2D for ; Sat, 24 Aug 2013 11:45:00 +0000 (UTC) (envelope-from pawelbsd@gmail.com) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0C73129A9 for ; Sat, 24 Aug 2013 11:44:59 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c50so733813eek.18 for ; Sat, 24 Aug 2013 04:44:58 -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-transfer-encoding; bh=gkkNzFJptZsfnXJGUsay7E+DPBSSRj8Oaq/A4ZFcM3A=; b=Npq5YP0szlyuOQgkkx9XuYFMRMWbo+85FtNdPI38+4jIcWscAaKu7+V4CvZEXdGyJe Z3XnX14oMLH/WhWzpvsmXWcJX7zvi6Ji35n/CnDg6tmR1MLUDr5VCOncp+laYxWzBOOT TzWuqg8RLQLcEMiaHcJI6+hZFyg95j6iB8pUokGPnhenw09O+46+3DekA1Ml0wvcmvhz Z/VhJ81qY6RML7Aa/UdT55QJ75qK87QTv3j4pC8fXIY1VlMT64428WCb4p0hgEg8NA0V etfgUnNBOoFhE/rSpJ+PROLV75zVUgg9mNIXgk4UD3xTs1teQ2IHEN7OYWl1t2nwCSTK SAHw== X-Received: by 10.14.177.8 with SMTP id c8mr2670319eem.56.1377344698312; Sat, 24 Aug 2013 04:44:58 -0700 (PDT) Received: from localhost ([176.109.164.5]) by mx.google.com with ESMTPSA id a43sm6343051eep.9.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 24 Aug 2013 04:44:57 -0700 (PDT) Sender: =?UTF-8?B?UGF3ZcWCIFDEmWthbGE=?= Date: Sat, 24 Aug 2013 13:42:23 +0200 From: Pawel Pekala To: freebsd-current@freebsd.org Subject: route get fails Message-ID: <20130824134223.6bf7634c@FreeBSD.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 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: Sat, 24 Aug 2013 11:45:00 -0000 Hi, For some time now I get this: [corn:~]> route get route: writing to routing socket: Invalid argument Is this just my build or anyone can confirm this? --=20 pozdrawiam / with regards Pawe=B3 P=EAkala From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 11:49:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6F07EF7; Sat, 24 Aug 2013 11:49:54 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2E73729D1; Sat, 24 Aug 2013 11:49:54 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDCNq-000NUP-JB; Sat, 24 Aug 2013 15:51:58 +0400 Date: Sat, 24 Aug 2013 15:51:58 +0400 From: Slawa Olhovchenkov To: "Sam Fourman Jr." Subject: Re: GCC withdraw Message-ID: <20130824115158.GA88999@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: toolchain@freebsd.org, Boris Samorodov , 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: Sat, 24 Aug 2013 11:49:54 -0000 On Sat, Aug 24, 2013 at 06:30:24AM -0400, Sam Fourman Jr. wrote: > > If the 150 ports that only work with gcc, all work with a ports > > > > gcc and do not need the gcc from base, would the following be OK ? > > > > > > - 9.x gcc default and clang in base; > > > - 10.x clang default and gcc in ports; > > > > Well, we write rules and we brake them. ;-) > > > > Just say that we know we brake them but it's inevitable because... > > And go futher. > > > > I am not a developer, just a user, so I am not versed in all of the > issues but I > would REALLY like to see gcc moved to ports for 10.x > > In my opinion this just needs to happen, if ports break, we deal with that > on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 12:10:55 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2CB10B77; Sat, 24 Aug 2013 12:10:55 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EEA712B34; Sat, 24 Aug 2013 12:10:54 +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 r7OCApLv009902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Aug 2013 12:10:53 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <20130824115158.GA88999@zxy.spb.ru> Date: Sat, 24 Aug 2013 13:10:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , 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: Sat, 24 Aug 2013 12:10:55 -0000 On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote: > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang > don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax = that clang does not recognise, then please will you point me to the = relevant LLVM bug report and I will investigate it. David From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 12:11:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0F3BECA1; Sat, 24 Aug 2013 12:11:18 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF8162B42; Sat, 24 Aug 2013 12:11:17 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id id13so1065239vcb.18 for ; Sat, 24 Aug 2013 05:11:16 -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=Dg2Fu5IZVjufd5+00uNB4JxU2vLkC+FMilxbUzmznCo=; b=E3KiCyOV9vma0hqmwxjfrB/qFNUEu65vU+Vk+sJbAWnqVBvdCXNZofpUuXe1gyLdP1 054Ccxzllt5VLaUXSiI7fAg9gstNM2VLW3bOi2VwVRCsMtTszMRxXS2DNHjz2Y7GUbIV kug+6IKDTjS6ACQ6FYgaD45zwPxZ9qaYHWKjN7//XH1HChV0OXJTvEYVH9MNQkYwFAFX lhHtHmfqlX0j5Vcu/9kXaU7YlFSJkTClwtHZVR7vijI/WbpU4c573MP9VPxH1OLXlpqZ 98OKJXDgY10oJXtyIPrp09m45VQ7ooQWugnybmCanexU3rgBL3/M5/3tAECZyl+E7aDB wf4g== MIME-Version: 1.0 X-Received: by 10.58.235.69 with SMTP id uk5mr4294518vec.17.1377346276843; Sat, 24 Aug 2013 05:11:16 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Sat, 24 Aug 2013 05:11:16 -0700 (PDT) In-Reply-To: <20130824115158.GA88999@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> Date: Sat, 24 Aug 2013 12:11:16 +0000 Message-ID: Subject: Re: GCC withdraw From: "Sam Fourman Jr." To: Slawa Olhovchenkov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: toolchain@freebsd.org, Boris Samorodov , 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: Sat, 24 Aug 2013 12:11:18 -0000 > In my opinion this just needs to happen, if ports break, we deal with that > > on a case by case basis. > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang > don't understand inlined asm. > > Well, in this case, you would just have the mplayer maintainer configure the port to use gcc for the i386 build of mplayer... problem solved -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 12:16:00 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7A00DE04; Sat, 24 Aug 2013 12:16:00 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 376252B6C; Sat, 24 Aug 2013 12:16:00 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDCn7-000NiR-Vd; Sat, 24 Aug 2013 16:18:05 +0400 Date: Sat, 24 Aug 2013 16:18:05 +0400 From: Slawa Olhovchenkov To: "Sam Fourman Jr." Subject: Re: GCC withdraw Message-ID: <20130824121805.GD3796@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: toolchain@freebsd.org, Boris Samorodov , 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: Sat, 24 Aug 2013 12:16:00 -0000 On Sat, Aug 24, 2013 at 12:11:16PM +0000, Sam Fourman Jr. wrote: > > In my opinion this just needs to happen, if ports break, we deal with that > > > > on a case by case basis. > > > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang > > don't understand inlined asm. > > > > > Well, in this case, you would just have the mplayer maintainer configure the > port to use gcc for the i386 build of mplayer... problem solved Yes, I just edit Makefile. But this is point about ports builded by clang. From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 12:30:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6F62A190; Sat, 24 Aug 2013 12:30:33 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22B382BDC; Sat, 24 Aug 2013 12:30:33 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id e10so196325qcy.33 for ; Sat, 24 Aug 2013 05:30:32 -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=442la6lD2HaVEVGcbrBT4fqNYo3JExQolLU4W3HrxYI=; b=UZDJIVJUV7B7hKnZJU/awYjQ7sflyucEwjsaiK2jA3e/8ulbr2RWjAbfPpIRT8PJtr doKpfAelqBvMdvj+TMNMmMeIkTW5a3uLYmRFmrRg/M/Yc+y+qMBF4sFPXHKfQdLx/4Al ZIuYjZlr2330eGu7kvJj5DVAeXADWp+6znTLn1/wxt9Sv3moDOCas6oVVN5yBEDTasjL VygJyxG1UfT6gPtTiiMLum23XuGUvDyTQU78bI16BVA/vvJ1dSCFBte5wc+Mhz0gB0hD Pvzrd3HzPqQw9Rl0otONw2596uGXuotsbMr9+4jO1h0WkZ3kGNLZTRWzs1PbwxTtqlVJ ZhtQ== MIME-Version: 1.0 X-Received: by 10.49.35.203 with SMTP id k11mr5709461qej.5.1377347432272; Sat, 24 Aug 2013 05:30:32 -0700 (PDT) Received: by 10.224.5.195 with HTTP; Sat, 24 Aug 2013 05:30:32 -0700 (PDT) In-Reply-To: <20130824134223.6bf7634c@FreeBSD.org> References: <20130824134223.6bf7634c@FreeBSD.org> Date: Sat, 24 Aug 2013 15:30:32 +0300 Message-ID: Subject: Re: route get fails From: Kimmo Paasiala To: Pawel Pekala Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Sat, 24 Aug 2013 12:30:33 -0000 On Sat, Aug 24, 2013 at 2:42 PM, Pawel Pekala wrote: > Hi, > > For some time now I get this: > > [corn:~]> route get > route: writing to routing socket: Invalid argument > > Is this just my build or anyone can confirm this? > > -- > pozdrawiam / with regards > Pawe=C5=82 P=C4=99kala Nothing wrong there, you're not providing a required argument that is the destination IP address. In my opinion route(8) should return a proper error message in this case. OS X route(8) behaves exactly the same BTW. -Kimmo From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 12:31:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4DE702A5; Sat, 24 Aug 2013 12:31:38 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 018052C10; Sat, 24 Aug 2013 12:31:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=8bpNzuvBdrbfP4gFWA3c56QrDmiQSibS3EV7/2GDZVU=; b=lFx7K372gOkMy8TAt1ql5Eyo03j2TY+NQtl1v3iisFlI5cPnqdPyeELhek2tWGsFEP3wgHHpMFBO+5wqf3Gq8pKjOmyYB452lvM5RR0fwOf9fvO9a8l7kdNQzmpW+MDBIggCvC839ZW5wsXKenVHEppw5kYe5aANgZ9RscDMS4I=; Received: from [178.137.138.140] (helo=nonamehost.local) by fsm1.ukr.net with esmtpsa ID 1VDD07-000Osw-8H ; Sat, 24 Aug 2013 15:31:31 +0300 Date: Sat, 24 Aug 2013 15:31:27 +0300 From: Ivan Klymenko To: Hans Petter Selasky Subject: Re: devel/gettext build error in jail i386 environment on amd64 host Message-ID: <20130824153127.74ad6e59@nonamehost.local> In-Reply-To: <52189849.90405@bitfrost.no> References: <20130824001452.71b262ae@nonamehost.local> <52189849.90405@bitfrost.no> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authentication-Result: IP=178.137.138.140; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net Cc: freebsd-current@freebsd.org, freebsd-ports@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, 24 Aug 2013 12:31:38 -0000 =D0=92 Sat, 24 Aug 2013 13:26:01 +0200 Hans Petter Selasky =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 08/23/13 23:14, Ivan Klymenko wrote: > > wing error: > > http://privatepaste.com/46f9477022 >=20 > Not sure if this helps: >=20 > https://wiki.freebsd.org/PkgPrimer >=20 > Using portbuilder inside a jail >=20 > When building 9-stable ports in a 9-stable jail under -current you > might want to set the UNAME_r enviroment variable to fake the FreeBSD > version in /path_to_my_jail/root/.cshrc . Some examples: >=20 > setenv UNAME_r 9-STABLE > setenv UNAME_r 8-STABLE > setenv UNAME_r 7-STABLE >=20 > Else some ports won't build properly. Something tells me the intuition that the problem appeared after the addition of iconv in base... From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 12:43:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7FD035E8; Sat, 24 Aug 2013 12:43:43 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 431692C89; Sat, 24 Aug 2013 12:43:40 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1VD9RL-000CQy-U2; Sat, 24 Aug 2013 12:43:24 +0400 Message-ID: <5218AA36.1080807@ipfw.ru> Date: Sat, 24 Aug 2013 16:42:30 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130728 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [rfc] migrate lagg to an rmlock References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , 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: Sat, 24 Aug 2013 12:43:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24.08.2013 00:54, Adrian Chadd wrote: > Hi, > > I'd like to commit this to -10. It migrates the if_lagg locking > from a rw lock to a rm lock. We see a bit of contention between the > transmit and We're running lagg with rmlock on several hundred heavily loaded machines, it really works better. However, there should not be any contention between receive and transmit side since there is actually no _real_ need to lock RX (and even use lagg receive code at all): http://lists.freebsd.org/pipermail/svn-src-all/2013-April/067570.html > receive sides of lagg during traffic loads (10+ gigabit per > second.) Using rmlocks eliminate this. > > http://people.freebsd.org/~adrian/netflix/20130819-lagg-rmlock-1.diff > > Thanks, > > > -adrian _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net To > unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIYqjYACgkQwcJ4iSZ1q2n9fgCePHOfC3tzBIG54ayNg7d8TKMC gIMAn2/paUBpDIRVd+3s7snNFCmZNWgd =i6Ye -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 13:11:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1BB62AD2; Sat, 24 Aug 2013 13:11:33 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C0D6C2DB3; Sat, 24 Aug 2013 13:11:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=7AH2S5Ix1m6WDr6WIFl1aYjEYGSoFIP5j6MexeKLrwc=; b=AJ4lvjRziXULfIne+rAFri+Ykmm8/wJWEoBhVx01Ck8++mYvk2F/08s5Yi82VqxRjoQmUZCLJRKouVMpQW+NqxE5L7RvDCx+NWh+uJVTGpeO6VOmgXTQVBkuA+Av+tRhfJO+eB37+6R29D5VHonms8eDdfyxhiFxvKwIhUzqUgs=; Received: from [178.137.138.140] (helo=nonamehost.local) by fsm2.ukr.net with esmtpsa ID 1VDCNc-000Joq-BO ; Sat, 24 Aug 2013 14:51:44 +0300 Date: Sat, 24 Aug 2013 14:51:40 +0300 From: Ivan Klymenko To: Hans Petter Selasky Subject: Re: devel/gettext build error in jail i386 environment on amd64 host Message-ID: <20130824145140.515803f6@nonamehost.local> In-Reply-To: <52189849.90405@bitfrost.no> References: <20130824001452.71b262ae@nonamehost.local> <52189849.90405@bitfrost.no> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authentication-Result: IP=178.137.138.140; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net Cc: freebsd-current@freebsd.org, freebsd-ports@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, 24 Aug 2013 13:11:33 -0000 =D0=92 Sat, 24 Aug 2013 13:26:01 +0200 Hans Petter Selasky =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 08/23/13 23:14, Ivan Klymenko wrote: > > wing error: > > http://privatepaste.com/46f9477022 >=20 > Not sure if this helps: >=20 > https://wiki.freebsd.org/PkgPrimer >=20 > Using portbuilder inside a jail >=20 > When building 9-stable ports in a 9-stable jail under -current you > might want to set the UNAME_r enviroment variable to fake the FreeBSD > version in /path_to_my_jail/root/.cshrc . Some examples: >=20 > setenv UNAME_r 9-STABLE > setenv UNAME_r 8-STABLE > setenv UNAME_r 7-STABLE >=20 > Else some ports won't build properly. Thank you for responded to my question. It really did not help. Error remains the same. Especially as I have in the jail environment from 10.0-CURRENT and it is to him I need to put together a package in environment by i386. I try in general to build the port emulators/i386-wine-devel for amd64 arch and before I succeeded it without any further action. From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 14:16:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7A8C197D; Sat, 24 Aug 2013 14:16:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 557DD205E; Sat, 24 Aug 2013 14:16:34 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 040C446B49; Sat, 24 Aug 2013 10:16:34 -0400 (EDT) Date: Sat, 24 Aug 2013 15:16:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Alexander V. Chernikov" Subject: Re: [rfc] migrate lagg to an rmlock In-Reply-To: <5218AA36.1080807@ipfw.ru> Message-ID: References: <5218AA36.1080807@ipfw.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , 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: Sat, 24 Aug 2013 14:16:34 -0000 On Sat, 24 Aug 2013, Alexander V. Chernikov wrote: > On 24.08.2013 00:54, Adrian Chadd wrote: >> >> I'd like to commit this to -10. It migrates the if_lagg locking >> from a rw lock to a rm lock. We see a bit of contention between the >> transmit and > > We're running lagg with rmlock on several hundred heavily loaded machines, > it really works better. However, there should not be any contention between > receive and transmit side since there is actually no _real_ need to lock RX > (and even use lagg receive code at all): > > http://lists.freebsd.org/pipermail/svn-src-all/2013-April/067570.html We should distinguish "lock contention" from "line contention". When acquiring a rwlock on multiple CPUs concurrently, the cache lines used to implement the lock are contended, as they must bounce between caches via the cache coherence protocol, also referred to as "contention". In the if_lagg code, I assume that the read-only acquire of the rwlock (and perhaps now rmlock) is for data stability rather than mutual exclusion -- e.g., to allow processing to completion against a stable version of the lagg configuration. As such, indeed, there should be no lock contention unless a configuration update takes place, and any line contention is a property of the locking primitive rather than data model. There are a number of other places in the kernel where migration to an rmlock makes sense -- however, some care must be taken for four reasons: (1) while read locks don't experience line contention, write locking becomes observably e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks, unlike rwlocks, more expensive so is not suitable for all rwlock line contention spots -- implement reader priority propagation, so you must reason about; and (3) historically, rmlocks have not fully implemented WITNESS so you may get less good debugging output. if_lagg is a nice place to use rmlocks, as reconfigurations are very rare, and it's really all about long-term data stability. Robert From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 14:32:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 642E2D5B; Sat, 24 Aug 2013 14:32:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2967A2106; Sat, 24 Aug 2013 14:32: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 r7OEWSg0032753; Sat, 24 Aug 2013 10:32:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7OEWSve032749; Sat, 24 Aug 2013 14:32:28 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Aug 2013 14:32:28 GMT Message-Id: <201308241432.r7OEWSve032749@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: Sat, 24 Aug 2013 14:32:35 -0000 TB --- 2013-08-24 13:30:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 13:30: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-08-24 13:30:16 - starting HEAD tinderbox run for mips/mips TB --- 2013-08-24 13:30:16 - cleaning the object tree TB --- 2013-08-24 13:30:16 - /usr/local/bin/svn stat /src TB --- 2013-08-24 13:30:52 - At svn revision 254760 TB --- 2013-08-24 13:30:53 - building world TB --- 2013-08-24 13:30:53 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 13:30:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 13:30:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 13:30:53 - SRCCONF=/dev/null TB --- 2013-08-24 13:30:53 - TARGET=mips TB --- 2013-08-24 13:30:53 - TARGET_ARCH=mips TB --- 2013-08-24 13:30:53 - TZ=UTC TB --- 2013-08-24 13:30:53 - __MAKE_CONF=/dev/null TB --- 2013-08-24 13:30:53 - cd /src TB --- 2013-08-24 13:30:53 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 13:31:01 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 Sat Aug 24 14:30:59 UTC 2013 TB --- 2013-08-24 14:30:59 - cd /src/sys/mips/conf TB --- 2013-08-24 14:30:59 - /usr/sbin/config -m ADM5120 TB --- 2013-08-24 14:30:59 - skipping ADM5120 kernel TB --- 2013-08-24 14:30:59 - cd /src/sys/mips/conf TB --- 2013-08-24 14:30:59 - /usr/sbin/config -m ALCHEMY TB --- 2013-08-24 14:30:59 - skipping ALCHEMY kernel TB --- 2013-08-24 14:30:59 - cd /src/sys/mips/conf TB --- 2013-08-24 14:30:59 - /usr/sbin/config -m AP121 TB --- 2013-08-24 14:30:59 - building AP121 kernel TB --- 2013-08-24 14:30:59 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 14:30:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 14:30:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 14:30:59 - SRCCONF=/dev/null TB --- 2013-08-24 14:30:59 - TARGET=mips TB --- 2013-08-24 14:30:59 - TARGET_ARCH=mips TB --- 2013-08-24 14:30:59 - TZ=UTC TB --- 2013-08-24 14:30:59 - __MAKE_CONF=/dev/null TB --- 2013-08-24 14:30:59 - cd /src TB --- 2013-08-24 14:30:59 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Sat Aug 24 14:30:59 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/kern/kern_mtxpool.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/kern/kern_mutex.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/kern/kern_ntptime.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/kern/kern_osd.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/kern/kern_physio.c cc1: warnings being treated as errors /src/sys/kern/kern_physio.c: In function 'physio': /src/sys/kern/kern_physio.c:123: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *** Error code 1 Stop. bmake[1]: stopped in /obj/mips.mips/src/sys/AP121 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-24 14:32:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-24 14:32:28 - ERROR: failed to build AP121 kernel TB --- 2013-08-24 14:32:28 - 2715.66 user 623.63 system 3731.80 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 14:33:38 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7DEA4FC3; Sat, 24 Aug 2013 14:33:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6492124; Sat, 24 Aug 2013 14:33:37 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r7OEXOvf005390 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 24 Aug 2013 07:33:26 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5218C42E.1070901@freebsd.org> Date: Sat, 24 Aug 2013 22:33:18 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Chisnall Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , 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: Sat, 24 Aug 2013 14:33:38 -0000 On 8/24/13 7:19 PM, David Chisnall wrote: > On 24 Aug 2013, at 11:30, "Sam Fourman Jr." wrote: > >> So I vote, let's not give ourselves the burden of "lugging" dead weight in >> base >> for another 5 years. (in 2017 do we still want to be worrying about gcc in >> base?) > Perhaps more to the point, in 2017 do we want to be responsible for maintaining a fork of a 2007 release of gcc and libstdc++? The same work needs to be done no matter where it is.. there is no saving in moving it, and a lot of hassle.. leave the damned thing alone and be thankful that we have switched to clang by default! don't over-reach your successes. > > David > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 14:44:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 818F54E9; Sat, 24 Aug 2013 14:44:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5007A21A6; Sat, 24 Aug 2013 14:44:41 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r7OEibVE005445 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 24 Aug 2013 07:44:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5218C6D0.5090403@freebsd.org> Date: Sat, 24 Aug 2013 22:44:32 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Roman Divacky Subject: Re: GCC withdraw References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <52174D51.2050601@digsys.bg> <21414.1377258940@critter.freebsd.dk> <5217A7D8.1030806@freebsd.org> <1377285836.31114.13416825.5F534A08@webmail.messagingengine.com> <52180DD0.3080308@freebsd.org> <20130824074104.GA31021@freebsd.org> In-Reply-To: <20130824074104.GA31021@freebsd.org> 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: Sat, 24 Aug 2013 14:44:42 -0000 On 8/24/13 3:41 PM, Roman Divacky wrote: > On Sat, Aug 24, 2013 at 09:35:12AM +0800, Julian Elischer wrote: >> On 8/24/13 3:23 AM, Mark Felder wrote: >>> On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: >>>> On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: >>>>> In message <52174D51.2050601@digsys.bg>, Daniel Kalchev writes: >>>>> >>>>>>> - 9.x gcc default and clang in base; >>>>>>> - 10.x clang default and gcc in ports; >>>>>> I believe this is the best idea so far. As long as these ports work with >>>>>> gcc in ports, that is. >>>>> +1 >>>>> >>>> well as I was forced to go back to gcc to get a compiling & running >>>> kernel on my VPS (xen) >>>> I'm not convinced that clang is there yet. I'd be really grumpy if I >>>> had to go through al the ports hoopla to recompile my kernel. >>>> >>>> >>> Curious which Xen version. I'd like to try to replicate this issue. I've >>> seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. >> I don't know.. whatever RootBSD run, but the fact that I needed gcc >> for anything suggests that we should keep it around for a while. > Why do you need to use gcc for everything? What happens if you use clang? > Be specific, without details this is just FUD. > > Roman > I couldn't even get it to compile a few weeks ago. i386 xen kernel.. gcc breezed straight through (though getting it to boot was another story) From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 15:10:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D17D0A3C; Sat, 24 Aug 2013 15:10:11 +0000 (UTC) (envelope-from matthias@petermann-it.de) 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 9089622D2; Sat, 24 Aug 2013 15:10:10 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id 1175884F2600; Sat, 24 Aug 2013 17:10:10 +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 AlLPOcRk8k6T; Sat, 24 Aug 2013 17:10:08 +0200 (CEST) Received: from workstation.local (p579D360C.dip0.t-ipconnect.de [87.157.54.12]) by mail.s1.d2ux.org (Postfix) with ESMTPSA id 409B984F25EF; Sat, 24 Aug 2013 17:10:08 +0200 (CEST) Message-ID: <5218CC69.6090108@petermann-it.de> Date: Sat, 24 Aug 2013 17:08:25 +0200 From: Matthias Petermann User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130526 Thunderbird/17.0.6 MIME-Version: 1.0 To: bug-followup@FreeBSD.org, matthias@petermann-it.de, current@freebsd.org Subject: Re: amd64/181357: LCD Brightness Control not working on Lenovo X121e (ACPI issue?) Content-Type: text/plain; charset=ISO-8859-15; 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: Sat, 24 Aug 2013 15:10:11 -0000 Hello, regarding this PR I made some further observation. Even the acpi_ec_write seems to not have any effect on the brightness, the values set to the appropriate register (IBM_EC_BRIGHTNESS 0x31) survive a reboot. Looks like the values are stored correctly, but EC doesn't care for them when setting brightness? I'm not sure where to look next. Could this be a hardware issue with the Device? Kind regards, Matthias From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 15:40:12 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3E02E3D4; Sat, 24 Aug 2013 15:40:12 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id EF308241A; Sat, 24 Aug 2013 15:40:11 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDFyj-000P0k-V5; Sat, 24 Aug 2013 19:42:17 +0400 Date: Sat, 24 Aug 2013 19:42:17 +0400 From: Slawa Olhovchenkov To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130824154217.GE3796@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , 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: Sat, 24 Aug 2013 15:40:12 -0000 On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: > On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote: > > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang > > don't understand inlined asm. > > Clang supports inline asm. If there is some specific inline asm > syntax that clang does not recognise, then please will you point me > to the relevant LLVM bug report and I will investigate it. Sorry, I don't know about clang/llvm bug reports, I just try to build mplayer with Win32 codecs support on FreeBSD-10/i386. And currenly (in rev r315041) building by clang disabled in ports tree. PS: Also, if FreeBSD ship clang why ship not full set of clang? For example, when I try to build llvm-lua not found sets of files: LLVMCompiler.cpp:25:30: error: llvm/LLVMContext.h: No such file or directory LLVMCompiler.cpp:26:31: error: llvm/DerivedTypes.h: No such file or directory LLVMCompiler.cpp:27:50: error: llvm/ExecutionEngine/ExecutionEngine.h: No such file or directory LLVMCompiler.cpp:28:25: error: llvm/Module.h: No such file or directory LLVMCompiler.cpp:29:30: error: llvm/PassManager.h: No such file or directory LLVMCompiler.cpp:30:36: error: llvm/Analysis/Verifier.h: No such file or directory LLVMCompiler.cpp:31:36: error: llvm/Target/TargetData.h: No such file or directory LLVMCompiler.cpp:32:39: error: llvm/Target/TargetMachine.h: No such file or directory LLVMCompiler.cpp:33:40: error: llvm/Target/TargetOptions.h: No such file or directory LLVMCompiler.cpp:34:36: error: llvm/Transforms/Scalar.h: No such file or directory LLVMCompiler.cpp:35:33: error: llvm/Transforms/IPO.h: No such file or directory LLVMCompiler.cpp:36:43: error: llvm/Transforms/Utils/Cloning.h: No such file or directory LLVMCompiler.cpp:37:36: error: llvm/Support/IRBuilder.h: No such file or directory LLVMCompiler.cpp:38:32: error: llvm/Support/Timer.h: No such file or directory LLVMCompiler.cpp:39:38: error: llvm/Support/CommandLine.h: No such file or directory From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 15:42:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 007B2662 for ; Sat, 24 Aug 2013 15:42:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC1DE2463 for ; Sat, 24 Aug 2013 15:42:11 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id a14so2593226iee.40 for ; Sat, 24 Aug 2013 08:42:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cECSnYUFag5Y5kHUjMRJNA+BQ8xOAnDFKMSgkETnEIo=; b=fWSVgh7B2hHWXjqs/syg90YnV5DJSicl1oeE59GckaTz004drTsf5+9XffFST7PV7a qQhhRHcjTkfwthMEpI4g5LAEPeKMKbw9iXMTC0MC3wZbtAX495OqTUmeTHP9baJAkSSi JJ82MkD2jtcSCUmaJiXrrGdjr7VefLSpCFDYrBRM519zkVLEbYH5u2HoKbovc8CiQ8Fj cAmwU3t5i1f2zLxn7re2DMoWTDslgVqhLiVtHsIZlpWJLhwjOFB1hAKmQNPpAnaqLp4I H+a68caQPok6w9xUVhDTsxNpukkMJ8Pjjdsl5yqIwvfY3K6zkvSQZ52iThjEQdOIGGXl t82w== X-Gm-Message-State: ALoCoQncN0SsrjRG/vxS4OpJvbliCF38SGk1N10D6lURONljXGKn1a9yZu3x496DGH5y1ZqifI2i X-Received: by 10.50.119.42 with SMTP id kr10mr1695285igb.20.1377358925608; Sat, 24 Aug 2013 08:42:05 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id p10sm4925151igx.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 08:42:04 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> Date: Sat, 24 Aug 2013 09:42:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> To: David Chisnall X-Mailer: Apple Mail (2.1085) Cc: toolchain@freebsd.org, John-Mark Gurney , Alfred Perlstein , "re@FreeBSD.org Engineering Team" , 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, 24 Aug 2013 15:42:12 -0000 On Aug 24, 2013, at 4:05 AM, David Chisnall wrote: > On 23 Aug 2013, at 23:37, Warner Losh wrote: >=20 >> I'd dispute the 'and surely it seems like it does' part of this. Non = x86 architectures will continue to use gcc because clang just isn't = ready at this time for them. Some are very close (arm), some are close = (powerpc64, mips*), some are no where near ready, or will never be ready = (sparc64, ia64). There's no coherent, documented plan for these absent = gcc at the moment. There are lots of pieces there, and those pieces will = form the basis of the solution (+handbook updates) for the removal of = gcc in 11, but we just aren't there yet. >=20 > The plan, which has been discussed on mailing lists, on IRC, and at = DevSummits is for tier 2 ports to depend on an external toolchain. For = those vendors that are not prevented from using GPLv3 compilers, this = means that they will be able to take advantage of, for example, the = significant improvements to the MIPS and PowerPC back ends that gcc has = had over the last 6 years. For everyone else, it will mean installing a = compiler from ports. That's the plan for FreeBSD 11, yes. For FreeBSD 10, gcc remains in the = tree. > For now, tier 2 architectures will continue to build a toolchain from = the src tree and use that. By 11.0, gcc will be gone from the base = system and they will be required to use something external if they are = not supported by clang. Brooks has been working hard on making this = easy, and it is generally an improvement for cross-building embedded = systems as the cross-compile toolchain is no longer rebuilt every time = you change a file in the kernel, resulting in faster builds. It is also = easier to use toolchains provided by chip vendors, which is something = that MIPS and ARM vendors have been asking for for a very long time. =20 Yes. Many of the building blocks are in place, but they haven't been = stitched together entirely yet. The 11 time frame is plenty of time to = tie up the loose ends and rough edges that are there, as well as to = ensure you can cross build a system, then do a native build on that = system with external toolchains... > For x86 and ARMv6/7, Clang has been the default compiler for a long = time and gcc has been increasingly problematic (for example, our gcc = does not support ARM EABI, which will be the default in 10.0 for ARMv6 = and later, so if you want to build for a modern ARM chip then you need = either clang or a more recent gcc than we ship). Claiming that this is = something done at the expense of non-x86 architectures is highly = misleading, as improving ARM support is one of the driving factors = behind the switch. I'm sorry, but that's not quite right. Our gcc *DOES* support arm EABI = with soft float. In fact, that's how we're using it now and how we're = using clang now as well. clang support for ARM is still shaky, even in = -current. EABI with hard float hasn't been done, and will require a = newer gcc and/or clang, but we're not entirely there yet. The fallback = for weird bugs is still "recompile with the in-tree gcc" and often that = has fixed issues that people hit either with clang, or with assumptions = about generated code that weren't quite true with clang and needed to be = fixed in our kernel. But *ALL* the other non-x86 architectures are significantly worse with = clang. ARM is marginally the same, but we're still some issues we're = fighting through with ports and such. I think I was clear about which = ones were affected, and how though in my note. > If you are shipping a product that relies on gcc, then for the 10.x = timeframe, you are free to build and use the gcc from the base system, = and the tinderboxes will prevent any non-optional components from being = modified in such a way that they can't build with this gcc. In the 11.x = timeframe, architectures that aren't supported by clang will need an = external toolchain. =20 Yup. And the external toolchain support will need to be well documented = and we need a cross building/installing external toolchain story that's = better. It works well enough to generate a system now, but not quite = well enough to generate a self-hosting system (which is required for the = ports cross-build-on-qemu solution). > AMD, Intel, AMD, Oracle, ARM, and MIPS are all actively contributing = to LLVM and Clang, so the only platform that is unlikely to have an LLVM = back end in the 11.0 timeframe is IA64, and if you really care about = IA64 then Intel will happily sell you a compiler that does a much better = job than GCC of targeting this architecture. Yes. I'm totally on board with that for the 11 time frame. 32-bit = powerpc had issues, and isn't in your list. Warner= From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 15:43:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA1E77B5 for ; Sat, 24 Aug 2013 15:43:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 857E02483 for ; Sat, 24 Aug 2013 15:43:56 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id a14so2594711iee.40 for ; Sat, 24 Aug 2013 08:43:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=A+Yh7oD40GRU8V05/2b62MuUYN81IFctaL+FokqHoCE=; b=nKYf8nkJ6FjLRcz4GN6vrh/O64RPSrm31APfTAPEPke+pHqbprieFZEfwM6JYfWGgU RGHP+cpoYteWMmYMClbldhPftMWMIo2ccR/sR/psRoe1BWDT7O4YzJ8HvKkHYkYy+UXe OEBk+6wBlgyGWgzB7mUwpv40SIbVhwB74u7vzzX7mDunJtUeMLdE6n927YV4tWdbMNzU /oWjzY5918UQMUgeMox8cCYv2VyYByOtA/NvOtQnMAUutVt3m1UVnXihmbhFy3xv5Eyl K8fsMmMe1ZMmJxfc/M9zW+nVx99ODvLNm326mzPa5bnkWlEqfia4ar6Cf8RPn2cnI6Tq l5Yg== X-Gm-Message-State: ALoCoQnr5xKYwoIr+aEB8C9N9e0JuGVcPWM4Atql8m/nB/gil+gNJ5hTHaqxfGqtGQW4ZgLSyHsj X-Received: by 10.50.39.51 with SMTP id m19mr1594986igk.51.1377359035948; Sat, 24 Aug 2013 08:43:55 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id yt10sm4901119igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 08:43:55 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 24 Aug 2013 09:43:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> To: "Sam Fourman Jr." X-Mailer: Apple Mail (2.1085) Cc: toolchain@freebsd.org, Boris Samorodov , FreeBSD Current , Slawa Olhovchenkov 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, 24 Aug 2013 15:43:56 -0000 On Aug 24, 2013, at 6:11 AM, Sam Fourman Jr. wrote: >> In my opinion this just needs to happen, if ports break, we deal with = that >=20 >>> on a case by case basis. >>=20 >> Oh, I remember. mplayer on i386 can't be builded witch clang -- clang >> don't understand inlined asm. >>=20 >>=20 > Well, in this case, you would just have the mplayer maintainer = configure the > port to use gcc for the i386 build of mplayer... problem solved The problem is that there's a lot of cases in ports where this work = needs to be done. That work is ongoing, but isn't done yet. The ports = people have indicated that in the 10 time frame may be a bit = optimistic... Warner From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 16:12:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 91738F4; Sat, 24 Aug 2013 16:12:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5A2E25FF; Sat, 24 Aug 2013 16:12:18 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id y10so1514388wgg.16 for ; Sat, 24 Aug 2013 09:12:17 -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:message-id:subject :from:to:cc:content-type; bh=VieMGFY2jPZAeEUd3qHXiXNBGXUzf94J3Sk/FSgubSY=; b=pVDDiZik4WuCvijZKvZ41VJapFKQ7yNLBs0v7LIOjajXyeec2qbZkyiWbnvxbyCphq 5BMBxo5yb3iJC06w+VV3RYJSCHjWY2MP5JIUq1qwHMzopcVvUOsJO/bmvrANr3b/3Iej cYpWwX+8Ha33ZoOcul4hG4B9ScayVIsfVg3IDrNXwIwcH18OlT0+F5wsuvv7Yo2FT04k 8fiY/dKPXtpjKG64lL18urdnHX6fu1QDmOQeBGLK2BYWzvlg0VqKQOiKA48uLf+3MDTl nhlyUI8dPtwmU2kwtt7fx4YZKBxMEb/nBtzqmKT8P0/FEkQfEinAImziQ5ZvkJ/LgRAN XEuA== MIME-Version: 1.0 X-Received: by 10.180.36.133 with SMTP id q5mr1960687wij.0.1377360737044; Sat, 24 Aug 2013 09:12:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sat, 24 Aug 2013 09:12:16 -0700 (PDT) In-Reply-To: References: <5218AA36.1080807@ipfw.ru> Date: Sat, 24 Aug 2013 09:12:16 -0700 X-Google-Sender-Auth: byUiCc2zTVAddHrpkga8GwMXMFQ Message-ID: Subject: Re: [rfc] migrate lagg to an rmlock From: Adrian Chadd To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , freebsd-current , "Alexander V. Chernikov" 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, 24 Aug 2013 16:12:19 -0000 Sorry, I meant "line contention" rather than "lock contention". Yes, you're right. -adrian On 24 August 2013 07:16, Robert Watson wrote: > On Sat, 24 Aug 2013, Alexander V. Chernikov wrote: > > On 24.08.2013 00:54, Adrian Chadd wrote: >> >>> >>> I'd like to commit this to -10. It migrates the if_lagg locking >>> from a rw lock to a rm lock. We see a bit of contention between the >>> transmit and >>> >> >> We're running lagg with rmlock on several hundred heavily loaded >> machines, it really works better. However, there should not be any >> contention between receive and transmit side since there is actually no >> _real_ need to lock RX (and even use lagg receive code at all): >> >> http://lists.freebsd.org/**pipermail/svn-src-all/2013-**April/067570.html >> > > We should distinguish "lock contention" from "line contention". When > acquiring a rwlock on multiple CPUs concurrently, the cache lines used to > implement the lock are contended, as they must bounce between caches via > the cache coherence protocol, also referred to as "contention". In the > if_lagg code, I assume that the read-only acquire of the rwlock (and > perhaps now rmlock) is for data stability rather than mutual exclusion -- > e.g., to allow processing to completion against a stable version of the > lagg configuration. As such, indeed, there should be no lock contention > unless a configuration update takes place, and any line contention is a > property of the locking primitive rather than data model. > > There are a number of other places in the kernel where migration to an > rmlock makes sense -- however, some care must be taken for four reasons: > (1) while read locks don't experience line contention, write locking > becomes observably e.g., rmlocks might not be suitable for tcbinfo; (2) > rmlocks, unlike rwlocks, more expensive so is not suitable for all rwlock > line contention spots -- implement reader priority propagation, so you must > reason about; and (3) historically, rmlocks have not fully implemented > WITNESS so you may get less good debugging output. if_lagg is a nice place > to use rmlocks, as reconfigurations are very rare, and it's really all > about long-term data stability. > > Robert > From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 16:32:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 909B4A1D for ; Sat, 24 Aug 2013 16:32:09 +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]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2654B2719 for ; Sat, 24 Aug 2013 16:32:08 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id z12so1509223wgg.22 for ; Sat, 24 Aug 2013 09:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PvGxM0T7uyPbSH2tpQfq8wOK1hniBdDUdUbBmqpQ8YA=; b=SdSuaOMV/Hkh/afa72jxSm3nk/l94JLGdcOOP04l5e/eu/88R56emcilD/CN6WqIMf cZTTp/Z3nLg5ngRT3ajrzgW7uATTMHrqC1m6/CT4QwWyaMEgkZKq1TMhmYUCSruEp7ys +T5XGcVtHhfD3IqnBb8ig0iw5au79kcCeMlYwkCf0p2oBVHAX85Io565IDXg4ucyGPXy idVFRbyeuwuKnc+o6O8Z0GMrlvWXhOB8WUJvvaa+U1TF0KjYtXzhFW9hWfC93m+0a7+Q UA8iYl5amEMtJ6wtofmcoC3o9CY62rBSd2yNaWh31O0CmcQVG0pqBnTkW/jH21eaAxaH UQZw== MIME-Version: 1.0 X-Received: by 10.180.36.133 with SMTP id q5mr2002911wij.0.1377361927408; Sat, 24 Aug 2013 09:32:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sat, 24 Aug 2013 09:32:07 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Aug 2013 09:32:07 -0700 X-Google-Sender-Auth: xgRsAo-inoAl6Z_a59MACcfmEG4 Message-ID: Subject: Re: pkgng From: Adrian Chadd To: Hideki Yamamoto 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: Sat, 24 Aug 2013 16:32:09 -0000 .. well, where'd you point it to? -adrian On 23 August 2013 23:04, Hideki Yamamoto wrote: > Hi, > > I solved my problem by myself. > I update PACKAGESITE in /usr/local/etc/pkg.conf in accordance with > the information in another expert web site. > > --- > > > > 2013/8/24 Hideki Yamamoto > > > > > Hi, > > > > As I moved from old pkg_xxx to pkg2ng. > > But I cannot install any new packages as follows: > > > > # rm -f /var/db/pkg* > > > > # pkg2ng > > > > # pkg install gs > > > > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, > > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 > > - > > - > > - > > - > > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, > > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 > > > > # echo $? 3 # > > # gsview > > gsview: Command not found. > > > > > > > > Does someone help me? > > > > Thanks in advance. > > > > Hideki Yamamoto > > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 16:33:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CE45DB39; Sat, 24 Aug 2013 16:33:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B7DD0272E; Sat, 24 Aug 2013 16:33:41 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id l12so1405658wiv.1 for ; Sat, 24 Aug 2013 09:33:40 -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:message-id:subject :from:to:cc:content-type; bh=8wHn1YcEO1JJANmqLfD92mzDM2MzUcim79TS7Y95bSI=; b=Q9BwV2JjDUz6KIzIl0gl2JlBwWAfEwtr/S4iNgp2YbtIqk6DEca71xsZKyVblbLQ0f +8lQOvtRNyqS9roKytHAXWSR2KEBEo8YRZgvrXbctO1BpLcyuoCmCrOjtnGbaahLDa8t g4szdoVYLSZvOVEwmpzop6nFUFNMYLYqBXuSzejRKss4U2XBFrZuIC+H5BupipJdiC1Q J1oA+niDLWErYp4i5n1WuwKai/nHi9oXxfr6R5RgHYRHjQWjizFHCcrY4UVjPqLDLz8H KiVMPdF3XG5AQKCEedcBwqRXNCz00bqRKKzTciVta4PrAVvoBlbWx60KvSQ/kcSTctzx xyOw== MIME-Version: 1.0 X-Received: by 10.180.36.133 with SMTP id q5mr2006182wij.0.1377362020059; Sat, 24 Aug 2013 09:33:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sat, 24 Aug 2013 09:33:39 -0700 (PDT) In-Reply-To: <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> Date: Sat, 24 Aug 2013 09:33:39 -0700 X-Google-Sender-Auth: LmgMJa5W5PlabcqRj1Esxu7DZpg Message-ID: Subject: Re: patch to add AES intrinsics to gcc From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "re@FreeBSD.org Engineering Team" , "current@freebsd.org" , John-Mark Gurney , Alfred Perlstein , David Chisnall , 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: Sat, 24 Aug 2013 16:33:42 -0000 You know, I could be a total jerk and say: "If you push gcc out to a port, and you have the 'external compiler' toolchain support working correctly enough to build with this, why don't we just push clang out to a port, and be done with it?" ... just saying. -adrian From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 16:34:34 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2BAB6C73; Sat, 24 Aug 2013 16:34:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E4B142742; Sat, 24 Aug 2013 16:34:33 +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 r7OGYWvA081755; Sat, 24 Aug 2013 12:34: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 r7OGYWou081754; Sat, 24 Aug 2013 16:34:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Aug 2013 16:34:32 GMT Message-Id: <201308241634.r7OGYWou081754@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: Sat, 24 Aug 2013 16:34:34 -0000 TB --- 2013-08-24 13:52:52 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 13:52: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-08-24 13:52:52 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-08-24 13:52:52 - cleaning the object tree TB --- 2013-08-24 13:52:52 - /usr/local/bin/svn stat /src TB --- 2013-08-24 13:52:56 - At svn revision 254760 TB --- 2013-08-24 13:52:57 - building world TB --- 2013-08-24 13:52:57 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 13:52:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 13:52:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 13:52:57 - SRCCONF=/dev/null TB --- 2013-08-24 13:52:57 - TARGET=powerpc TB --- 2013-08-24 13:52:57 - TARGET_ARCH=powerpc TB --- 2013-08-24 13:52:57 - TZ=UTC TB --- 2013-08-24 13:52:57 - __MAKE_CONF=/dev/null TB --- 2013-08-24 13:52:57 - cd /src TB --- 2013-08-24 13:52:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 13:53: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Aug 24 16:27:14 UTC 2013 TB --- 2013-08-24 16:27:14 - generating LINT kernel config TB --- 2013-08-24 16:27:14 - cd /src/sys/powerpc/conf TB --- 2013-08-24 16:27:14 - /usr/bin/make -B LINT TB --- 2013-08-24 16:27:14 - cd /src/sys/powerpc/conf TB --- 2013-08-24 16:27:14 - /usr/sbin/config -m LINT TB --- 2013-08-24 16:27:15 - building LINT kernel TB --- 2013-08-24 16:27:15 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 16:27:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 16:27:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 16:27:15 - SRCCONF=/dev/null TB --- 2013-08-24 16:27:15 - TARGET=powerpc TB --- 2013-08-24 16:27:15 - TARGET_ARCH=powerpc TB --- 2013-08-24 16:27:15 - TZ=UTC TB --- 2013-08-24 16:27:15 - __MAKE_CONF=/dev/null TB --- 2013-08-24 16:27:15 - cd /src TB --- 2013-08-24 16:27:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 24 16:27:15 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/kern/kern_mtxpool.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/kern/kern_mutex.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/kern/kern_ntptime.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/kern/kern_osd.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/kern/kern_physio.c cc1: warnings being treated as errors /src/sys/kern/kern_physio.c: In function 'physio': /src/sys/kern/kern_physio.c:123: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-24 16:34:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-24 16:34:32 - ERROR: failed to build LINT kernel TB --- 2013-08-24 16:34:32 - 8404.89 user 1050.47 system 9700.10 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 16:36: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7983DD8; Sat, 24 Aug 2013 16:36:25 +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 B991E275D; Sat, 24 Aug 2013 16:36:25 +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 1D5031A3E2D; Sat, 24 Aug 2013 09:36:25 -0700 (PDT) Message-ID: <5218E108.6090901@mu.org> Date: Sat, 24 Aug 2013 09:36:24 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Robert Watson Subject: Re: [rfc] migrate lagg to an rmlock References: <5218AA36.1080807@ipfw.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Adrian Chadd , freebsd-current , "Alexander V. Chernikov" 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, 24 Aug 2013 16:36:25 -0000 On 8/24/13 7:16 AM, Robert Watson wrote: > On Sat, 24 Aug 2013, Alexander V. Chernikov wrote: > >> On 24.08.2013 00:54, Adrian Chadd wrote: >>> >>> I'd like to commit this to -10. It migrates the if_lagg locking >>> from a rw lock to a rm lock. We see a bit of contention between the >>> transmit and >> >> We're running lagg with rmlock on several hundred heavily loaded >> machines, it really works better. However, there should not be any >> contention between receive and transmit side since there is actually >> no _real_ need to lock RX (and even use lagg receive code at all): >> >> http://lists.freebsd.org/pipermail/svn-src-all/2013-April/067570.html > > We should distinguish "lock contention" from "line contention". When > acquiring a rwlock on multiple CPUs concurrently, the cache lines used > to implement the lock are contended, as they must bounce between > caches via the cache coherence protocol, also referred to as > "contention". In the if_lagg code, I assume that the read-only > acquire of the rwlock (and perhaps now rmlock) is for data stability > rather than mutual exclusion -- e.g., to allow processing to > completion against a stable version of the lagg configuration. As > such, indeed, there should be no lock contention unless a > configuration update takes place, and any line contention is a > property of the locking primitive rather than data model. > > There are a number of other places in the kernel where migration to an > rmlock makes sense -- however, some care must be taken for four > reasons: (1) while read locks don't experience line contention, write > locking becomes observably e.g., rmlocks might not be suitable for > tcbinfo; (2) rmlocks, unlike rwlocks, more expensive so is not > suitable for all rwlock line contention spots -- implement reader > priority propagation, so you must reason about; and (3) historically, > rmlocks have not fully implemented WITNESS so you may get less good > debugging output. if_lagg is a nice place to use rmlocks, as > reconfigurations are very rare, and it's really all about long-term > data stability. > > Robert > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Robert, what do you think about a quick swap of the ifnet structures to counter before 10.x? -Alfred -- Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 16:40:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4C78490; Sat, 24 Aug 2013 16:40:02 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 31836279A; Sat, 24 Aug 2013 16:40:01 +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 AFA921A3DA7; Sat, 24 Aug 2013 09:40:01 -0700 (PDT) Message-ID: <5218E1E1.1040809@freebsd.org> Date: Sat, 24 Aug 2013 09:40:01 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: patch to add AES intrinsics to gcc References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "re@FreeBSD.org Engineering Team" , "current@freebsd.org" , John-Mark Gurney , David Chisnall , toolchain@freebsd.org, Warner Losh 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, 24 Aug 2013 16:40:02 -0000 On 8/24/13 9:33 AM, Adrian Chadd wrote: > You know, I could be a total jerk and say: > > "If you push gcc out to a port, and you have the 'external compiler' > toolchain support working correctly enough to build with this, why don't we > just push clang out to a port, and be done with it?" > > ... just saying. > > > > -adrian > Are you calling me a total jerk? :) I'm fine with that because I agree. -Alfred From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 16:53: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3C344805 for ; Sat, 24 Aug 2013 16:53:04 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (aran.keltia.net [88.191.250.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0195B2853 for ; Sat, 24 Aug 2013 16:53:03 +0000 (UTC) Received: from lonrach.local (unknown [IPv6:2a01:e34:ee87:4a00:8598:3a55:4c44:3bb0]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 0D4EB52AE for ; Sat, 24 Aug 2013 18:53:02 +0200 (CEST) Date: Sat, 24 Aug 2013 18:53:00 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org Subject: Re: pkgng Message-ID: <20130824165259.GE15392@lonrach.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem 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: Sat, 24 Aug 2013 16:53:04 -0000 According to Adrian Chadd: > .. well, where'd you point it to? On my own machine I generate the packages myself with poudriere because I have multiple jails I update. On a more generic machine, I use pkg-test.freebsd.org. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 17:47: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 286849FC; Sat, 24 Aug 2013 17:47:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 015F92AA7; Sat, 24 Aug 2013 17:47:13 +0000 (UTC) Received: from [10.0.1.16] (host86-155-36-56.range86-155.btcentralplus.com [86.155.36.56]) by cyrus.watson.org (Postfix) with ESMTPSA id 645DB46B35; Sat, 24 Aug 2013 13:47:10 -0400 (EDT) Subject: Re: [rfc] migrate lagg to an rmlock Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: "Robert N. M. Watson" In-Reply-To: <5218E108.6090901@mu.org> Date: Sat, 24 Aug 2013 18:47:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5218AA36.1080807@ipfw.ru> <5218E108.6090901@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1283) Cc: FreeBSD Net , Adrian Chadd , freebsd-current , "Alexander V. Chernikov" 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, 24 Aug 2013 17:47:13 -0000 On 24 Aug 2013, at 17:36, Alfred Perlstein wrote: >> We should distinguish "lock contention" from "line contention". When = acquiring a rwlock on multiple CPUs concurrently, the cache lines used = to implement the lock are contended, as they must bounce between caches = via the cache coherence protocol, also referred to as "contention". In = the if_lagg code, I assume that the read-only acquire of the rwlock (and = perhaps now rmlock) is for data stability rather than mutual exclusion = -- e.g., to allow processing to completion against a stable version of = the lagg configuration. As such, indeed, there should be no lock = contention unless a configuration update takes place, and any line = contention is a property of the locking primitive rather than data = model. >>=20 >> There are a number of other places in the kernel where migration to = an rmlock makes sense -- however, some care must be taken for four = reasons: (1) while read locks don't experience line contention, write = locking becomes observably e.g., rmlocks might not be suitable for = tcbinfo; (2) rmlocks, unlike rwlocks, more expensive so is not suitable = for all rwlock line contention spots -- implement reader priority = propagation, so you must reason about; and (3) historically, rmlocks = have not fully implemented WITNESS so you may get less good debugging = output. if_lagg is a nice place to use rmlocks, as reconfigurations are = very rare, and it's really all about long-term data stability. >=20 > Robert, what do you think about a quick swap of the ifnet structures = to counter before 10.x? Could you be more specific about the proposal you're making? Robert= From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 18:02:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0EF3BCE7; Sat, 24 Aug 2013 18:02:38 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id C49802B63; Sat, 24 Aug 2013 18:02:37 +0000 (UTC) Received: from mobileKamikaze.norad (dslb-094-219-199-017.pools.arcor-ip.net [94.219.199.17]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 222C186184; Sat, 24 Aug 2013 20:02:28 +0200 (CEST) Message-ID: <5218F534.4000401@bsdforen.de> Date: Sat, 24 Aug 2013 20:02:28 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Matthias Petermann Subject: Re: amd64/181357: LCD Brightness Control not working on Lenovo X121e (ACPI issue?) References: <5218CC69.6090108@petermann-it.de> In-Reply-To: <5218CC69.6090108@petermann-it.de> Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, bug-followup@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, 24 Aug 2013 18:02:38 -0000 On 24/08/2013 17:08, Matthias Petermann wrote: > regarding this PR I made some further observation. Even the acpi_ec_write seems to not have any effect on the brightness, the values set to the appropriate register (IBM_EC_BRIGHTNESS 0x31) survive a reboot. My LCD brightness control stopped working when I switched to NEW_XORG with Intel KMS (on stable/9). -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 18:14:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0E85EF93; Sat, 24 Aug 2013 18:14:38 +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 DE6D82BE2; Sat, 24 Aug 2013 18:14:37 +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 0C7851A3E38; Sat, 24 Aug 2013 11:14:28 -0700 (PDT) Message-ID: <5218F803.7000405@mu.org> Date: Sat, 24 Aug 2013 11:14:27 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Robert N. M. Watson" Subject: Re: [rfc] migrate lagg to an rmlock References: <5218AA36.1080807@ipfw.ru> <5218E108.6090901@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Adrian Chadd , freebsd-current , "Alexander V. Chernikov" 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, 24 Aug 2013 18:14:38 -0000 On 8/24/13 10:47 AM, Robert N. M. Watson wrote: > On 24 Aug 2013, at 17:36, Alfred Perlstein wrote: > >>> We should distinguish "lock contention" from "line contention". When acquiring a rwlock on multiple CPUs concurrently, the cache lines used to implement the lock are contended, as they must bounce between caches via the cache coherence protocol, also referred to as "contention". In the if_lagg code, I assume that the read-only acquire of the rwlock (and perhaps now rmlock) is for data stability rather than mutual exclusion -- e.g., to allow processing to completion against a stable version of the lagg configuration. As such, indeed, there should be no lock contention unless a configuration update takes place, and any line contention is a property of the locking primitive rather than data model. >>> >>> There are a number of other places in the kernel where migration to an rmlock makes sense -- however, some care must be taken for four reasons: (1) while read locks don't experience line contention, write locking becomes observably e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks, unlike rwlocks, more expensive so is not suitable for all rwlock line contention spots -- implement reader priority propagation, so you must reason about; and (3) historically, rmlocks have not fully implemented WITNESS so you may get less good debugging output. if_lagg is a nice place to use rmlocks, as reconfigurations are very rare, and it's really all about long-term data stability. >> Robert, what do you think about a quick swap of the ifnet structures to counter before 10.x? > Could you be more specific about the proposal you're making? > > Robert The lagg patch referred to in the thread seems to indicate that zero locking is needed if we just switched to counter(9), that makes me wonder if we could do better with locking in other places if we switched to counter(9) while we have the chance. This is the thread: http://lists.freebsd.org/pipermail/svn-src-all/2013-April/067570.html >/ />/ Perfect solution would be to convert ifnet(9) to counters(9), but this />/ requires much more work, and unfortunately ABI change, so temporarily />/ patch lagg(4) manually. />/ />/ We store counters in the softc, and once per second push their values />/ to legacy ifnet counters./ -- Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 18:21:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 53790277; Sat, 24 Aug 2013 18:21:17 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E54062C45; Sat, 24 Aug 2013 18:21:16 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7OIL73L071830; Sat, 24 Aug 2013 14:21:13 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5218F993.9050504@m5p.com> Date: Sat, 24 Aug 2013 14:21:07 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> In-Reply-To: <52184F59.5080100@bitfrost.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sat, 24 Aug 2013 14:21:13 -0400 (EDT) Cc: freebsd-arm@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: Sat, 24 Aug 2013 18:21:17 -0000 On 08/24/13 02:14, Hans Petter Selasky wrote: > On 08/24/13 02:44, George Mitchell wrote: >> On 08/23/13 07:11, George Mitchell wrote: >>> On 08/23/13 02:18, Hans Petter Selasky wrote: >>>> On 08/23/13 02:29, George Mitchell wrote: >>>>> On 08/22/13 07:34, Hans Petter Selasky wrote: >>>> > >> Give that the printer works fine with the same code on my amd64 >> machines, does this suggest we have a byte-ordering problem in the >> driver? -- George > > Hi, > > I looked at the code and your debug prints, and it looks like the > usbd_transfer_setup() function is to blame. To get further debugging > here, you need to enable hw.usb.debug=15 and hw.usb.dwcotg.debug=15 or > something like that. > > error = usbd_transfer_setup(uaa->device, &iface_index, > sc->sc_xfer, ulpt_config, ULPT_N_TRANSFER, > sc, &sc->sc_mtx); > > I think this should be trivial to fix one the cause is found. > > --HPS Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an unending stream of debug output and effectively locks up the chip scrolling the output on the display. Perhaps there are some specific debug messages I could put in ... -- George From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 18:39:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BCEC693; Sat, 24 Aug 2013 18:39:31 +0000 (UTC) (envelope-from matthias@petermann-it.de) 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 38F002CEB; Sat, 24 Aug 2013 18:39:30 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id 80DF684F25C3; Sat, 24 Aug 2013 20:39:29 +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 fkv93cM9wNY1; Sat, 24 Aug 2013 20:39:27 +0200 (CEST) Received: from workstation.local (p579D360C.dip0.t-ipconnect.de [87.157.54.12]) by mail.s1.d2ux.org (Postfix) with ESMTPSA id CCB0784F25C0; Sat, 24 Aug 2013 20:39:27 +0200 (CEST) Message-ID: <5218FD78.5000605@petermann-it.de> Date: Sat, 24 Aug 2013 20:37:44 +0200 From: Matthias Petermann User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130526 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dominic Fandrey Subject: Re: amd64/181357: LCD Brightness Control not working on Lenovo X121e (ACPI issue?) References: <5218CC69.6090108@petermann-it.de> <5218F534.4000401@bsdforen.de> In-Reply-To: <5218F534.4000401@bsdforen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, bug-followup@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, 24 Aug 2013 18:39:31 -0000 Am 24.08.2013 20:02, schrieb Dominic Fandrey: > My LCD brightness control stopped working when I switched to NEW_XORG > with Intel KMS (on stable/9). It's the same issue when I run in console only mode (without Xorg, without KMS kernel module loaded). What Lenovo model are you using? From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 19:27:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 45D8DF43; Sat, 24 Aug 2013 19:27:44 +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]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D1402EDF; Sat, 24 Aug 2013 19:27:43 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id t58so1550860wes.24 for ; Sat, 24 Aug 2013 12:27:41 -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:message-id:subject :from:to:cc:content-type; bh=oASVWtpePHxaRW5wolnyoKaADXSvTcRcQpdhHiMvE9I=; b=DZrimS/IHtUbxqDEiswgKnX43Z8AszekQqi6s63ngOhMarTUJqNEbRMJ8i9A76EfrU 1rvVo16i7MtsIR5ITL2pvd8pA62vQ9w91hlYt8WBwbGbya745WcHCIvpNsHN4gSJ9EEY SKIO2fmEOqKEIJJhrh0jIw93StsLXBi//3nYJwaYuDXaDpWV4X/iJQ9LE2DSoH0DHF5S 7pbqnrs86r6pWBEbvwDjBzuXb4gN5Wsv2rAWAyQEN7EzB7xLV+9rtAgCfpOXUPdDUDHq 9SuTzbMMWkT3QcX8IsL6Nb8h1bkEUK5Jbg7zpspyxxjllY3+KfKcgaNvfU9Jzbk+7/kH yhyw== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr2280515wij.30.1377372461371; Sat, 24 Aug 2013 12:27:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Sat, 24 Aug 2013 12:27:41 -0700 (PDT) In-Reply-To: References: <5218AA36.1080807@ipfw.ru> <5218E108.6090901@mu.org> <5218F803.7000405@mu.org> Date: Sat, 24 Aug 2013 12:27:41 -0700 X-Google-Sender-Auth: 8Si-Hdt8VCA9yYgPAARhc5SYsiI Message-ID: Subject: Re: [rfc] migrate lagg to an rmlock From: Adrian Chadd To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Alfred Perlstein , "Robert N. M. Watson" , "Alexander V. Chernikov" , 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: Sat, 24 Aug 2013 19:27:44 -0000 Hihi, There's two parts to my patch: * one is migrating the rwlock to rmlock - not because of counters, but because the lock is protecting consistency when changing the lagg config * one is adding a new lock specifically to ensure that the callout is atomically created/called/destroyed The latter has nothing to do with the actual counters - they're already using the atomic counter API, so the lock doesn't need to be held just to read them for _counter_ consistency. It's just held to make sure the callout is never called parallel to the destruction of the lagg interface. -adrian From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 19:58:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6CC07A1F; Sat, 24 Aug 2013 19:58:38 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 251AB202F; Sat, 24 Aug 2013 19:58:37 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDK0o-0000r2-6e; Sun, 25 Aug 2013 00:00:42 +0400 Date: Sun, 25 Aug 2013 00:00:42 +0400 From: Slawa Olhovchenkov To: Adrian Chadd Subject: Re: patch to add AES intrinsics to gcc Message-ID: <20130824200042.GF3796@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <52173C8D.20608@freebsd.org> <20130823114635.GB64913@zxy.spb.ru> <20130823210513.GA3796@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130823210513.GA3796@zxy.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "re@FreeBSD.org Engineering Team" , "current@freebsd.org" , Bernhard Fr?hlich , John-Mark Gurney , David Chisnall , 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: Sat, 24 Aug 2013 19:58:38 -0000 On Sat, Aug 24, 2013 at 01:05:13AM +0400, Slawa Olhovchenkov wrote: > On Fri, Aug 23, 2013 at 06:54:44AM -0700, Adrian Chadd wrote: > > > Hi! > > > > If firewire code doesn't build on clang correctly, have you filed a bug so > > it gets looked at before 10.0 is released? that's pretty broken > > code/behaviour. > > How I can do it correctly? > Currently in src.conf: > > WITHOUT_CLANG=yes > WITHOUT_CLANG_IS_CC=yes > > Need recompile world? > System build from sources Jun 8. clang -- Jan 9. I build world w/o this options. After this I build kernel and install it. Reboot. acpiconf -s 3. power button. I got NMI. Sorry, dump don't allowed -- dump device don't ready at this moment. This is screenphoto http://zxy.spb.ru/13080005.jpg Kernel builded by GCC succeseful resuming (w/o NMI). Is it sufficient information for open PR? From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 21:04:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D488CCB2; Sat, 24 Aug 2013 21:04:01 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 322282332; Sat, 24 Aug 2013 21:04:01 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id x14so1289456vbb.9 for ; Sat, 24 Aug 2013 14:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zjMZc18z4d9IrtLa0mOydDJzOCz7pW7Ikxyy4Q0c35U=; b=nmJc0MdkTyLpWa86U+RVidB6ivtbdbeQvJlw6YY4nHjqrN9BRoNTz+c3qQOlUPWAyN w2PIe/JsiKXjltbR84Vz8lP3/Cs8DN5i0MJRhHca9V3TuXQfxnVfDngmo/ngdMpJi4ie +KpuXtEF6fi4HsPy9ixJfYNPmuuMMdd9PWoU80gRtJ9rZLDo8Wh1jN8r+FyvyYDUGZVx HkoeT4ONAizJR1MZtsAY6lvozEhkZ5g7oM94F1gYGP71ICHPJDjl/U041F8tN6gz910/ Le2/G0zSM2+/B2BhyV0BEQ1B/1cUl8u+B9dJtlOiJZooZ8SgwxQIRQHX4eRueirt/bFT zvCQ== MIME-Version: 1.0 X-Received: by 10.221.51.206 with SMTP id vj14mr6251358vcb.17.1377378240173; Sat, 24 Aug 2013 14:04:00 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Sat, 24 Aug 2013 14:04:00 -0700 (PDT) In-Reply-To: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> Date: Sat, 24 Aug 2013 17:04:00 -0400 Message-ID: Subject: Re: patch to add AES intrinsics to gcc From: "Sam Fourman Jr." To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "re@FreeBSD.org Engineering Team" , "current@freebsd.org" , John-Mark Gurney , Alfred Perlstein , David Chisnall , toolchain@freebsd.org, Warner Losh 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, 24 Aug 2013 21:04:01 -0000 On Sat, Aug 24, 2013 at 12:33 PM, Adrian Chadd wrote: > You know, I could be a total jerk and say: > > "If you push gcc out to a port, and you have the 'external compiler' > toolchain support working correctly enough to build with this, why don't we > just push clang out to a port, and be done with it?" > > ... just saying. +1 GREAT idea!!! that is a better plan for 11.x -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 21:04:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BC027E0D; Sat, 24 Aug 2013 21:04:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57B592348; Sat, 24 Aug 2013 21:04: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 r7OL4pqi076209; Sat, 24 Aug 2013 17:04: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 r7OL4pU6076190; Sat, 24 Aug 2013 21:04:51 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Aug 2013 21:04:51 GMT Message-Id: <201308242104.r7OL4pU6076190@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: Sat, 24 Aug 2013 21:04:56 -0000 TB --- 2013-08-24 18:00:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 18:00: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-08-24 18:00:20 - starting HEAD tinderbox run for armv6/arm TB --- 2013-08-24 18:00:20 - cleaning the object tree TB --- 2013-08-24 18:00:20 - /usr/local/bin/svn stat /src TB --- 2013-08-24 18:00:25 - At svn revision 254801 TB --- 2013-08-24 18:00:26 - building world TB --- 2013-08-24 18:00:26 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 18:00:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 18:00:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 18:00:26 - SRCCONF=/dev/null TB --- 2013-08-24 18:00:26 - TARGET=arm TB --- 2013-08-24 18:00:26 - TARGET_ARCH=armv6 TB --- 2013-08-24 18:00:26 - TZ=UTC TB --- 2013-08-24 18:00:26 - __MAKE_CONF=/dev/null TB --- 2013-08-24 18:00:26 - cd /src TB --- 2013-08-24 18:00:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 18:00: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Aug 24 21:03:46 UTC 2013 TB --- 2013-08-24 21:03:46 - generating LINT kernel config TB --- 2013-08-24 21:03:46 - cd /src/sys/arm/conf TB --- 2013-08-24 21:03:46 - /usr/bin/make -B LINT TB --- 2013-08-24 21:03:46 - cd /src/sys/arm/conf TB --- 2013-08-24 21:03:46 - /usr/sbin/config -m LINT TB --- 2013-08-24 21:03:46 - skipping LINT kernel TB --- 2013-08-24 21:03:46 - cd /src/sys/arm/conf TB --- 2013-08-24 21:03:46 - /usr/sbin/config -m AC100 TB --- 2013-08-24 21:03:46 - building AC100 kernel TB --- 2013-08-24 21:03:46 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 21:03:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 21:03:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 21:03:46 - SRCCONF=/dev/null TB --- 2013-08-24 21:03:46 - TARGET=arm TB --- 2013-08-24 21:03:46 - TARGET_ARCH=armv6 TB --- 2013-08-24 21:03:46 - TZ=UTC TB --- 2013-08-24 21:03:46 - __MAKE_CONF=/dev/null TB --- 2013-08-24 21:03:46 - cd /src TB --- 2013-08-24 21:03:46 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Sat Aug 24 21:03:46 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 -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/kern/kern_mbuf.c /src/sys/kern/kern_mbuf.c:637:2: error: use of undeclared identifier 'error' error = m_init(m, NULL, size, how, type, flags); ^ /src/sys/kern/kern_mbuf.c:643:10: error: use of undeclared identifier 'error' return (error); ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-24 21:04:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-24 21:04:51 - ERROR: failed to build AC100 kernel TB --- 2013-08-24 21:04:51 - 8857.88 user 1568.55 system 11070.79 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 21:13:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1E3CA4F7; Sat, 24 Aug 2013 21:13:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D8B8323C1; Sat, 24 Aug 2013 21:13:27 +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 r7OLDQWL035014; Sat, 24 Aug 2013 17:13: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 r7OLDQqV035007; Sat, 24 Aug 2013 21:13:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Aug 2013 21:13:26 GMT Message-Id: <201308242113.r7OLDQqV035007@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: Sat, 24 Aug 2013 21:13:28 -0000 TB --- 2013-08-24 18:00:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 18:00: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-08-24 18:00:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-08-24 18:00:20 - cleaning the object tree TB --- 2013-08-24 18:00:20 - /usr/local/bin/svn stat /src TB --- 2013-08-24 18:00:25 - At svn revision 254801 TB --- 2013-08-24 18:00:26 - building world TB --- 2013-08-24 18:00:26 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 18:00:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 18:00:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 18:00:26 - SRCCONF=/dev/null TB --- 2013-08-24 18:00:26 - TARGET=arm TB --- 2013-08-24 18:00:26 - TARGET_ARCH=arm TB --- 2013-08-24 18:00:26 - TZ=UTC TB --- 2013-08-24 18:00:26 - __MAKE_CONF=/dev/null TB --- 2013-08-24 18:00:26 - cd /src TB --- 2013-08-24 18:00:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 18:00: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Aug 24 21:01:43 UTC 2013 TB --- 2013-08-24 21:01:43 - generating LINT kernel config TB --- 2013-08-24 21:01:43 - cd /src/sys/arm/conf TB --- 2013-08-24 21:01:43 - /usr/bin/make -B LINT TB --- 2013-08-24 21:01:43 - cd /src/sys/arm/conf TB --- 2013-08-24 21:01:43 - /usr/sbin/config -m LINT TB --- 2013-08-24 21:01:43 - building LINT kernel TB --- 2013-08-24 21:01:43 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 21:01:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 21:01:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 21:01:43 - SRCCONF=/dev/null TB --- 2013-08-24 21:01:43 - TARGET=arm TB --- 2013-08-24 21:01:43 - TARGET_ARCH=arm TB --- 2013-08-24 21:01:43 - TZ=UTC TB --- 2013-08-24 21:01:43 - __MAKE_CONF=/dev/null TB --- 2013-08-24 21:01:43 - cd /src TB --- 2013-08-24 21:01:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 24 21:01: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 [...] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/sys/mbuf.h:687:50: note: expanded from macro 'MEXTADD' (void )m_extadd((m), (caddr_t)(buf), (size), (free), (arg1), (arg2),\ ^~~~~~ /src/sys/sys/mbuf.h:825:14: note: passing argument to parameter here void (*)(struct mbuf *, void *, void *), void *, void *, ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-24 21:13:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-24 21:13:26 - ERROR: failed to build LINT kernel TB --- 2013-08-24 21:13:26 - 9180.51 user 1654.37 system 11585.92 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 21:17:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 34B8A940 for ; Sat, 24 Aug 2013 21:17:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0EA9240E for ; Sat, 24 Aug 2013 21:17:44 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 9so2835348iec.2 for ; Sat, 24 Aug 2013 14:17:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1ypc3mi7HhJawtbcGrUIFOCSjoc/RSRyDVngXTyh7oQ=; b=KsqTmqLtk58giAJtY63+LrK1mAP921D59HFF+KCY/ay0V/eJRcS/rb93FCZpj2bQDx DCnKpRAmz0bfWQ6rug+t0CfmvVij64vi94WdlUykAmmj+97qeME0I41xulRBl5iEDnWN Zc61a8mNQi085C8R//F1hBIicmTQoW4+PDEESCyxt/vFAaCjS8m6JBzEvF6KY+EDjj8u P2iyitpyVkQS2dbBGIpbN9xyXyC0trNGaZybeZWjjcYJWkH4JufGS1yxaejddb4Utyec dSkSDJ4rizNSxvNaucV23EeQgWNTko2s1Z+XGwWfc/FsnW/1g1antO0iElUo/lk13w7t 9/Wg== X-Gm-Message-State: ALoCoQn7tB5flD81SjPXdR0NoTwLLz0EPUCCEnXnmvtrtwxzKUcFll3mbRMUkaC6/DGLaXVTP3Ly X-Received: by 10.42.147.198 with SMTP id o6mr3506992icv.13.1377379064152; Sat, 24 Aug 2013 14:17:44 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f5sm6823755igc.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 14:17:43 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 24 Aug 2013 15:17:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> To: "Sam Fourman Jr." X-Mailer: Apple Mail (2.1085) Cc: Adrian Chadd , "re@FreeBSD.org Engineering Team" , "current@freebsd.org" , John-Mark Gurney , Alfred Perlstein , David Chisnall , 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: Sat, 24 Aug 2013 21:17:45 -0000 On Aug 24, 2013, at 3:04 PM, Sam Fourman Jr. wrote: >=20 >=20 >=20 > On Sat, Aug 24, 2013 at 12:33 PM, Adrian Chadd = wrote: > You know, I could be a total jerk and say: >=20 > "If you push gcc out to a port, and you have the 'external compiler' > toolchain support working correctly enough to build with this, why = don't we > just push clang out to a port, and be done with it?" >=20 > ... just saying. >=20 > +1 >=20 > GREAT idea!!! that is a better plan for 11.x=20 This is a stupid idea. It kills the tightly integrated nature of = FreeBSD. I'd say it is far too radical a departure and opens up a huge = can of "which version of what compiler" nightmare that we've largely = dodged to date because we had one (or maybe two) compilers in the base = system. Warner From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 21:26:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 302A3DD2; Sat, 24 Aug 2013 21:26:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E95AC2497; Sat, 24 Aug 2013 21:26: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 r7OLQjw5011253; Sat, 24 Aug 2013 17:26: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 r7OLQjSP011249; Sat, 24 Aug 2013 21:26:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Aug 2013 21:26:45 GMT Message-Id: <201308242126.r7OLQjSP011249@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: Sat, 24 Aug 2013 21:26:47 -0000 TB --- 2013-08-24 18:00:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 18:00: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-08-24 18:00:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-08-24 18:00:20 - cleaning the object tree TB --- 2013-08-24 18:00:20 - /usr/local/bin/svn stat /src TB --- 2013-08-24 18:00:25 - At svn revision 254801 TB --- 2013-08-24 18:00:26 - building world TB --- 2013-08-24 18:00:26 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 18:00:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 18:00:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 18:00:26 - SRCCONF=/dev/null TB --- 2013-08-24 18:00:26 - TARGET=i386 TB --- 2013-08-24 18:00:26 - TARGET_ARCH=i386 TB --- 2013-08-24 18:00:26 - TZ=UTC TB --- 2013-08-24 18:00:26 - __MAKE_CONF=/dev/null TB --- 2013-08-24 18:00:26 - cd /src TB --- 2013-08-24 18:00:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 18:00: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Aug 24 21:11:48 UTC 2013 TB --- 2013-08-24 21:11:48 - generating LINT kernel config TB --- 2013-08-24 21:11:48 - cd /src/sys/i386/conf TB --- 2013-08-24 21:11:48 - /usr/bin/make -B LINT TB --- 2013-08-24 21:11:48 - cd /src/sys/i386/conf TB --- 2013-08-24 21:11:48 - /usr/sbin/config -m LINT TB --- 2013-08-24 21:11:48 - building LINT kernel TB --- 2013-08-24 21:11:48 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 21:11:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 21:11:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 21:11:48 - SRCCONF=/dev/null TB --- 2013-08-24 21:11:48 - TARGET=i386 TB --- 2013-08-24 21:11:48 - TARGET_ARCH=i386 TB --- 2013-08-24 21:11:48 - TZ=UTC TB --- 2013-08-24 21:11:48 - __MAKE_CONF=/dev/null TB --- 2013-08-24 21:11:48 - cd /src TB --- 2013-08-24 21:11:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 24 21:11:48 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/sys/mbuf.h:687:50: note: expanded from macro 'MEXTADD' (void )m_extadd((m), (caddr_t)(buf), (size), (free), (arg1), (arg2),\ ^~~~~~ /src/sys/sys/mbuf.h:825:14: note: passing argument to parameter here void (*)(struct mbuf *, void *, void *), void *, void *, ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-24 21:26:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-24 21:26:45 - ERROR: failed to build LINT kernel TB --- 2013-08-24 21:26:45 - 10051.59 user 1731.99 system 12384.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 18:21:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0B573C1 for ; Sat, 24 Aug 2013 18:21:43 +0000 (UTC) (envelope-from scottl@netflix.com) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5E0532C54 for ; Sat, 24 Aug 2013 18:21:43 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id k14so2751482iea.33 for ; Sat, 24 Aug 2013 11:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=45m2GP9pJ/B4IfT002gclv06sQJmi4TqHVs6ruPqfU8=; b=AS8x5XVkhllsAoPSenljHjRigfTphsHIZLpvjm8+ww9ZzJEOEwoPChPUcZjUDbzrzz A6QDAkMt97SzIrOhSQa/1rMjv5/jWSfjtXulaOOv+PdOsEco000x/HVS2MmNiCh9WJhF zPPDQjf9Y2j0XzsZHt/FgzwGcSHAsmIfmUzcY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=45m2GP9pJ/B4IfT002gclv06sQJmi4TqHVs6ruPqfU8=; b=PMrzE3VQVYdwWcC2GsNC32HGhnia7LmjqnXx5RORoiItw4Btt4AtprpySng+zln8GO ieR/OSsay41xXFOt06PPWzBS2VxjplDwEflZqqzbrHyYPKt+WJmpU9sRrC36iv6jsPxB JBPArRchYrvGtM5q7r7G8tNrON4m4FDP/xOkGkBEjKrBCRmp+ySM/eldnkDb/TCGsng0 F2e8htigIY/riTWLbrybT9cnZp975S64H6e/dyiK5wzSOnMqZ+4OXghpMTI2wDnm200H NUoZlKTCxfWw8lxV4V+cRHz3ilaniUHbqYVCiWVKelnpK22qnZ4x37zkJNF7MtPa1lRb mHKw== X-Gm-Message-State: ALoCoQmacJ207rg7ZTsPLYinXvD5wLBcQXR/W5oloegLgbVGBjBvvKIlavw01NvcMMaGlBIUPrko X-Received: by 10.43.168.67 with SMTP id nh3mr3263725icc.33.1377368502814; Sat, 24 Aug 2013 11:21:42 -0700 (PDT) Received: from phobos.samsco.home (pooker.samsco.org. [168.103.85.57]) by mx.google.com with ESMTPSA id jg5sm5852822igb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 11:21:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [rfc] migrate lagg to an rmlock From: Scott Long In-Reply-To: <5218F803.7000405@mu.org> Date: Sat, 24 Aug 2013 12:21:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5218AA36.1080807@ipfw.ru> <5218E108.6090901@mu.org> <5218F803.7000405@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Sat, 24 Aug 2013 21:31:16 +0000 Cc: FreeBSD Net , Adrian Chadd , freebsd-current , "Robert N. M. Watson" , "Alexander V. Chernikov" 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, 24 Aug 2013 18:21:43 -0000 On Aug 24, 2013, at 12:14 PM, Alfred Perlstein wrote: > On 8/24/13 10:47 AM, Robert N. M. Watson wrote: >> On 24 Aug 2013, at 17:36, Alfred Perlstein wrote: >>=20 >>>> We should distinguish "lock contention" from "line contention". = When acquiring a rwlock on multiple CPUs concurrently, the cache lines = used to implement the lock are contended, as they must bounce between = caches via the cache coherence protocol, also referred to as = "contention". In the if_lagg code, I assume that the read-only acquire = of the rwlock (and perhaps now rmlock) is for data stability rather than = mutual exclusion -- e.g., to allow processing to completion against a = stable version of the lagg configuration. As such, indeed, there should = be no lock contention unless a configuration update takes place, and any = line contention is a property of the locking primitive rather than data = model. >>>>=20 >>>> There are a number of other places in the kernel where migration to = an rmlock makes sense -- however, some care must be taken for four = reasons: (1) while read locks don't experience line contention, write = locking becomes observably e.g., rmlocks might not be suitable for = tcbinfo; (2) rmlocks, unlike rwlocks, more expensive so is not suitable = for all rwlock line contention spots -- implement reader priority = propagation, so you must reason about; and (3) historically, rmlocks = have not fully implemented WITNESS so you may get less good debugging = output. if_lagg is a nice place to use rmlocks, as reconfigurations are = very rare, and it's really all about long-term data stability. >>> Robert, what do you think about a quick swap of the ifnet structures = to counter before 10.x? >> Could you be more specific about the proposal you're making? >>=20 >> Robert >=20 > The lagg patch referred to in the thread seems to indicate that zero = locking is needed if we just switched to counter(9), that makes me = wonder if we could do better with locking in other places if we switched = to counter(9) while we have the chance. >=20 > This is the thread: >=20 > http://lists.freebsd.org/pipermail/svn-src-all/2013-April/067570.html >=20 >> / =20 > />/ Perfect solution would be to convert ifnet(9) to counters(9), = but this > />/ requires much more work, and unfortunately ABI change, so = temporarily > />/ patch lagg(4) manually. > />/ />/ We store counters in the softc, and once per second push = their values > />/ to legacy ifnet counters./ >=20 Some sort of gatekeeper semantic is needed to ensure that configuration = changes to the lagg state don't cause incorrect behavior to the data = path. It's not about protecting the integrity of counters. This can be = done several ways, but right now it's via a read/write semantic. Scott From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 21:40:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9032E709; Sat, 24 Aug 2013 21:40:16 +0000 (UTC) (envelope-from matthias@petermann-it.de) 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 13A01254C; Sat, 24 Aug 2013 21:40:15 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id E6BFD84F25D0; Sat, 24 Aug 2013 23:40:14 +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 0w852W_NkQJr; Sat, 24 Aug 2013 23:40:13 +0200 (CEST) Received: from workstation.local (p579D360C.dip0.t-ipconnect.de [87.157.54.12]) by mail.s1.d2ux.org (Postfix) with ESMTPSA id EB97D84F2573; Sat, 24 Aug 2013 23:40:12 +0200 (CEST) Message-ID: <521927D5.80807@petermann-it.de> Date: Sat, 24 Aug 2013 23:38:29 +0200 From: Matthias Petermann User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130526 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-amd64@freebsd.org, current@freebsd.org, freebsd-acpi@freebsd.org, bug-followup@FreeBSD.org Subject: amd64/181358: Suspend to RAM not working correctly on Lenovo X121e (ACPI issue?) References: <201308241940.r7OJe1n5057653@freefall.freebsd.org> In-Reply-To: <201308241940.r7OJe1n5057653@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 24 Aug 2013 21:40:16 -0000 Hello, regarding the issue mentioned in the subject (Lenovo Thinkpad X121e not able to resume after suspend to ram) there is finally some progress. I found this few months old discussion[1] on freebsd-acpi (related to Thinkpad X201): "I had a similar problem. After syncing with FreeBSD 10-CURRENT and compiling a kernel without VESA support, I was able to get graphics to work on resume, but only when running X. " This works for the X121e too! It is now able to suspend and resume properly when running Xorg (with i915kms.ko). I'm really happy :-) There is only a (very minor) problem: after the first resume Xorg graphics seem to slow down. When moving windows on the screen they leave some traces behind and it takes some milliseconds until they are wiped away and replaced with the background image. Kind regards, Matthias [1] http://freebsd.1045724.n5.nabble.com/Resume-failed-after-Suspend-on-Thinkpad-x201i-td5723622.html From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 22:01:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 36BDDBC4; Sat, 24 Aug 2013 22:01:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1676265A; Sat, 24 Aug 2013 22:01:41 +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 r7OM1f0S016177; Sat, 24 Aug 2013 18:01:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7OM1f8u016173; Sat, 24 Aug 2013 22:01:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Aug 2013 22:01:41 GMT Message-Id: <201308242201.r7OM1f8u016173@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: Sat, 24 Aug 2013 22:01:42 -0000 TB --- 2013-08-24 18:00:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 18:00: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-08-24 18:00:20 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-08-24 18:00:20 - cleaning the object tree TB --- 2013-08-24 18:00:20 - /usr/local/bin/svn stat /src TB --- 2013-08-24 18:00:25 - At svn revision 254801 TB --- 2013-08-24 18:00:26 - building world TB --- 2013-08-24 18:00:26 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 18:00:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 18:00:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 18:00:26 - SRCCONF=/dev/null TB --- 2013-08-24 18:00:26 - TARGET=amd64 TB --- 2013-08-24 18:00:26 - TARGET_ARCH=amd64 TB --- 2013-08-24 18:00:26 - TZ=UTC TB --- 2013-08-24 18:00:26 - __MAKE_CONF=/dev/null TB --- 2013-08-24 18:00:26 - cd /src TB --- 2013-08-24 18:00:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 18:00: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 Sat Aug 24 21:47:47 UTC 2013 TB --- 2013-08-24 21:47:47 - generating LINT kernel config TB --- 2013-08-24 21:47:47 - cd /src/sys/amd64/conf TB --- 2013-08-24 21:47:47 - /usr/bin/make -B LINT TB --- 2013-08-24 21:47:48 - cd /src/sys/amd64/conf TB --- 2013-08-24 21:47:48 - /usr/sbin/config -m LINT TB --- 2013-08-24 21:47:48 - building LINT kernel TB --- 2013-08-24 21:47:48 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 21:47:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 21:47:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 21:47:48 - SRCCONF=/dev/null TB --- 2013-08-24 21:47:48 - TARGET=amd64 TB --- 2013-08-24 21:47:48 - TARGET_ARCH=amd64 TB --- 2013-08-24 21:47:48 - TZ=UTC TB --- 2013-08-24 21:47:48 - __MAKE_CONF=/dev/null TB --- 2013-08-24 21:47:48 - cd /src TB --- 2013-08-24 21:47:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 24 21:47:48 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/sys/mbuf.h:687:50: note: expanded from macro 'MEXTADD' (void )m_extadd((m), (caddr_t)(buf), (size), (free), (arg1), (arg2),\ ^~~~~~ /src/sys/sys/mbuf.h:825:14: note: passing argument to parameter here void (*)(struct mbuf *, void *, void *), void *, void *, ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-24 22:01:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-24 22:01:41 - ERROR: failed to build LINT kernel TB --- 2013-08-24 22:01:41 - 11503.14 user 2114.82 system 14480.23 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 22:29:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0DB93239; Sat, 24 Aug 2013 22:29:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C02A42787; Sat, 24 Aug 2013 22:29: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 r7OMTj9x081895; Sat, 24 Aug 2013 18:29: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 r7OMTjXd081894; Sat, 24 Aug 2013 22:29:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Aug 2013 22:29:45 GMT Message-Id: <201308242229.r7OMTjXd081894@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: Sat, 24 Aug 2013 22:29:47 -0000 TB --- 2013-08-24 21:26:46 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 21:26:46 - 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-08-24 21:26:46 - starting HEAD tinderbox run for mips/mips TB --- 2013-08-24 21:26:46 - cleaning the object tree TB --- 2013-08-24 21:27:35 - /usr/local/bin/svn stat /src TB --- 2013-08-24 21:27:39 - At svn revision 254801 TB --- 2013-08-24 21:27:40 - building world TB --- 2013-08-24 21:27:40 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 21:27:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 21:27:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 21:27:40 - SRCCONF=/dev/null TB --- 2013-08-24 21:27:40 - TARGET=mips TB --- 2013-08-24 21:27:40 - TARGET_ARCH=mips TB --- 2013-08-24 21:27:40 - TZ=UTC TB --- 2013-08-24 21:27:40 - __MAKE_CONF=/dev/null TB --- 2013-08-24 21:27:40 - cd /src TB --- 2013-08-24 21:27:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 21:27: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 Sat Aug 24 22:28:05 UTC 2013 TB --- 2013-08-24 22:28:05 - cd /src/sys/mips/conf TB --- 2013-08-24 22:28:05 - /usr/sbin/config -m ADM5120 TB --- 2013-08-24 22:28:05 - skipping ADM5120 kernel TB --- 2013-08-24 22:28:05 - cd /src/sys/mips/conf TB --- 2013-08-24 22:28:05 - /usr/sbin/config -m ALCHEMY TB --- 2013-08-24 22:28:05 - skipping ALCHEMY kernel TB --- 2013-08-24 22:28:05 - cd /src/sys/mips/conf TB --- 2013-08-24 22:28:05 - /usr/sbin/config -m AP121 TB --- 2013-08-24 22:28:06 - building AP121 kernel TB --- 2013-08-24 22:28:06 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 22:28:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 22:28:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 22:28:06 - SRCCONF=/dev/null TB --- 2013-08-24 22:28:06 - TARGET=mips TB --- 2013-08-24 22:28:06 - TARGET_ARCH=mips TB --- 2013-08-24 22:28:06 - TZ=UTC TB --- 2013-08-24 22:28:06 - __MAKE_CONF=/dev/null TB --- 2013-08-24 22:28:06 - cd /src TB --- 2013-08-24 22:28:06 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Sat Aug 24 22:28:06 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/kern/kern_lockf.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/kern/kern_loginclass.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/kern/kern_malloc.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/kern/kern_mbuf.c /src/sys/kern/kern_mbuf.c: In function 'mb_ctor_pack': /src/sys/kern/kern_mbuf.c:637: error: 'error' undeclared (first use in this function) /src/sys/kern/kern_mbuf.c:637: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_mbuf.c:637: error: for each function it appears in.) *** Error code 1 Stop. bmake[1]: stopped in /obj/mips.mips/src/sys/AP121 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-24 22:29:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-24 22:29:45 - ERROR: failed to build AP121 kernel TB --- 2013-08-24 22:29:45 - 2718.18 user 677.08 system 3779.59 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 22:40:00 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0504F467; Sat, 24 Aug 2013 22:40:00 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id B27C8282E; Sat, 24 Aug 2013 22:39:59 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VDMWy-0001qv-Tm; Sun, 25 Aug 2013 02:42:04 +0400 Date: Sun, 25 Aug 2013 02:42:04 +0400 From: Slawa Olhovchenkov To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130824224204.GH3796@zxy.spb.ru> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130824154217.GE3796@zxy.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , 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: Sat, 24 Aug 2013 22:40:00 -0000 On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote: > On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: > > > On 24 Aug 2013, at 12:51, Slawa Olhovchenkov wrote: > > > > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang > > > don't understand inlined asm. > > > > Clang supports inline asm. If there is some specific inline asm > > syntax that clang does not recognise, then please will you point me > > to the relevant LLVM bug report and I will investigate it. > > Sorry, I don't know about clang/llvm bug reports, I just try to build > mplayer with Win32 codecs support on FreeBSD-10/i386. > > And currenly (in rev r315041) building by clang disabled in ports tree. And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 22:44:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BC3726E3; Sat, 24 Aug 2013 22:44:47 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6BC9D2885; Sat, 24 Aug 2013 22:44:46 +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 r7OMiiAK014904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Aug 2013 22:44:45 GMT (envelope-from theraven@freebsd.org) Content-Type: multipart/signed; boundary="Apple-Mail=_E4254B5D-2240-4465-9F57-E543CF9F9925"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <20130824224204.GH3796@zxy.spb.ru> Date: Sat, 24 Aug 2013 23:44:38 +0100 Message-Id: References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , 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: Sat, 24 Aug 2013 22:44:47 -0000 --Apple-Mail=_E4254B5D-2240-4465-9F57-E543CF9F9925 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > And i found PR about clang and mplayer: ports/176272 > This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ David --Apple-Mail=_E4254B5D-2240-4465-9F57-E543CF9F9925 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 iQIcBAEBAgAGBQJSGTdWAAoJEKx65DEEsqIdDXkP/1BA+hphQrLoKR++oKzkOJ9o tB7t/r8cUH/yUxQOBglABuhoj+RG+pCgHaAMdcYzEj8QU7cQmBDJ5+Vuv4vkoOzV Wfa0yWM+bk92LEbeyX/9WffYT0zaLQF1m3PVpONHC7RA7+K5fsELRLT26TiBthIk BJZa84H4KyQEYtHnjp9J6l94kJmogCHTz6Z9F2RO66M8C4XEy2F7ootWJSQOFNTL kywjFojOr7S1/GbOC1Eo713UYkAtLCY5dGQyX9DyrPllALXwXWDIVqNaQpePqiLJ awPAc2LCm/srIkI6bWlG6QB8VoXZZS3Mm12d1sU5P66ecjekgFEDjsPRtFaIqzd0 qGVqmmqXbCZxAujDA+5Uy/UGGZOUNPLx4/ZJ+bOfF1uzeGp2Env/RyxoiRPrRKic Mbb3M530JtbZySKhzM3QB2w5ACShOBqaOZ6KN2Yt9NdnjgTUbpoFDwu5Z1N/Nejp ZSvlDRcMJT3bfDPvcq3bHT8Srlvx7Fou9487vtHCxEi8l18lblcRzRq9SAULRqWw qxzkcQtSXGY6OkY4ePUXdJsvJ1PhrfWMMvFRW3f/oj0RnycjDhwl23rUwbCVdzlX 6WrEIjyVa5DXF7oDS7iBFR0KWTXtId0zQbcmmV40lRxMGBEmhIdxLQJL88vi70hP evNNWCG+3eFyfMGfbPmD =mn45 -----END PGP SIGNATURE----- --Apple-Mail=_E4254B5D-2240-4465-9F57-E543CF9F9925-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 22:47:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A20E682A for ; Sat, 24 Aug 2013 22:47:12 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B46528A1 for ; Sat, 24 Aug 2013 22:47:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:Sender:From:Date; bh=GaSAIapLQdnDyct7Lp32w/lDvLQIPRbNEibRa/MzlVE=; b=mSNAmX61QgrVzvT0KUzNa+JielLpmBt0plO/S4XrTaud6rdGpjiUCXnJmMNNXzFiRSEYljju1ogm4j6CjZ8+bGeQ4TWWHg3qI9VZnFGUK1cEtbfIx6faYXjvyEMaGxiVONMzQ0SG7BIffUxtWFf1MYtiXgmNO0xHQZhuhXm8ee0=; Received: from cpe-72-182-93-216.austin.res.rr.com ([72.182.93.216]:16966 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VDMbs-000EBT-Oi for freebsd-current@freebsd.org; Sat, 24 Aug 2013 17:47:11 -0500 Date: Sat, 24 Aug 2013 17:47:04 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-current@freebsd.org Subject: 2 crashes.... (today's -CURRENT) 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-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 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, 24 Aug 2013 22:47:12 -0000 Both full core.txt's are available at: http://www.lerctr.org/~ler/FreeBSD/ borg.lerctr.org dumped core - see /var/crash/vmcore.0 Sat Aug 24 17:35:31 CDT 2013 FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #32 r254807: Sat Aug 24 16:52:42 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 panic: page fault 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: code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 21 (racctd) trap number = 12 panic: page fault cpuid = 3 Uptime: 15m10s Dumping 3216 out of 64480 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/sound.ko.symbols...done. Loaded symbols for /boot/kernel/sound.ko.symbols Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. Loaded symbols for /boot/kernel/snd_hda.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/kernel/dtio.ko.symbols...done. Loaded symbols for /boot/kernel/dtio.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.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 0xffffffff80523aa0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff80523e27 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff8078962a in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:873 #4 0xffffffff80789a25 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:731 #5 0xffffffff80789022 in trap (frame=0xfffffe100d0f7a10) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80773222 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff8050c651 in thread_lock_flags_ (td=0xfffff80128283000, opts=0, file=0xffffffff8087b9c8 "/usr/src/sys/kern/kern_resource.c", line=2) at /usr/src/sys/kern/kern_mutex.c:637 #8 0xffffffff8051fc63 in ruxagg (p=0xfffff801283694b8, td=0xfffff80128283000) at /usr/src/sys/kern/kern_resource.c:1063 #9 0xffffffff8051a6fb in racctd () at /usr/src/sys/kern/kern_racct.c:1135 #10 0xffffffff804f118a in fork_exit (callout=0xffffffff8051a400 , arg=0x0, frame=0xfffffe100d0f7c00) at /usr/src/sys/kern/kern_fork.c:989 #11 0xffffffff8077375e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 #12 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) borg.lerctr.org dumped core - see /var/crash/vmcore.1 Sat Aug 24 17:42:01 CDT 2013 FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #32 r254807: Sat Aug 24 16:52:42 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 panic: page fault 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: current process = 9 (pagedaemon) trap number = 12 panic: page fault cpuid = 1 Uptime: 4m43s Dumping 2638 out of 64480 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. Loaded symbols for /boot/kernel/acl_nfs4.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/sound.ko.symbols...done. Loaded symbols for /boot/kernel/sound.ko.symbols Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. Loaded symbols for /boot/kernel/snd_hda.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/kernel/dtio.ko.symbols...done. Loaded symbols for /boot/kernel/dtio.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.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 0xffffffff80523aa0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff80523e27 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff8078962a in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:873 #4 0xffffffff80789a25 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:731 #5 0xffffffff80789022 in trap (frame=0xfffffe100d0d99c0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80773222 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff8050c584 in _mtx_trylock_flags_ (c=0x18, opts=0, file=0x0, line=269833360) at /usr/src/sys/kern/kern_mutex.c:330 #8 0xffffffff80784682 in pmap_ts_referenced (m=0xfffff80faacbf6c8) at /usr/src/sys/amd64/amd64/pmap.c:4936 #9 0xffffffff8071616a in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1360 #10 0xffffffff804f118a in fork_exit (callout=0xffffffff80715070 , arg=0x0, frame=0xfffffe100d0d9c00) at /usr/src/sys/kern/kern_fork.c:989 #11 0xffffffff8077375e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 #12 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 23:04:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 08EB3A40; Sat, 24 Aug 2013 23:04:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B17862973; Sat, 24 Aug 2013 23:04:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7ON4N6C082238; Sat, 24 Aug 2013 19:04:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7ON4NZa082232; Sat, 24 Aug 2013 23:04:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Aug 2013 23:04:23 GMT Message-Id: <201308242304.r7ON4NZa082232@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: Sat, 24 Aug 2013 23:04:25 -0000 TB --- 2013-08-24 21:13:27 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 21:13:27 - 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-08-24 21:13:27 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-08-24 21:13:27 - cleaning the object tree TB --- 2013-08-24 21:13:27 - /usr/local/bin/svn stat /src TB --- 2013-08-24 21:13:31 - At svn revision 254801 TB --- 2013-08-24 21:13:32 - building world TB --- 2013-08-24 21:13:32 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 21:13:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 21:13:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 21:13:32 - SRCCONF=/dev/null TB --- 2013-08-24 21:13:32 - TARGET=ia64 TB --- 2013-08-24 21:13:32 - TARGET_ARCH=ia64 TB --- 2013-08-24 21:13:32 - TZ=UTC TB --- 2013-08-24 21:13:32 - __MAKE_CONF=/dev/null TB --- 2013-08-24 21:13:32 - cd /src TB --- 2013-08-24 21:13:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 21:13: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 Sat Aug 24 22:51:33 UTC 2013 TB --- 2013-08-24 22:51:33 - generating LINT kernel config TB --- 2013-08-24 22:51:33 - cd /src/sys/ia64/conf TB --- 2013-08-24 22:51:33 - /usr/bin/make -B LINT TB --- 2013-08-24 22:51:33 - cd /src/sys/ia64/conf TB --- 2013-08-24 22:51:33 - /usr/sbin/config -m LINT TB --- 2013-08-24 22:51:33 - building LINT kernel TB --- 2013-08-24 22:51:33 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 22:51:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 22:51:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 22:51:33 - SRCCONF=/dev/null TB --- 2013-08-24 22:51:33 - TARGET=ia64 TB --- 2013-08-24 22:51:33 - TARGET_ARCH=ia64 TB --- 2013-08-24 22:51:33 - TZ=UTC TB --- 2013-08-24 22:51:33 - __MAKE_CONF=/dev/null TB --- 2013-08-24 22:51:33 - cd /src TB --- 2013-08-24 22:51:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 24 22:51:33 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/dev/vxge/vxgehal/vxgehal-virtualpath.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/dev/vxge/vxgehal/vxgehal-channel.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/dev/vxge/vxgehal/vxgehal-fifo.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/dev/watchdog/watchdog.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/dev/wb/if_wb.c cc1: warnings being treated as errors /src/sys/dev/wb/if_wb.c: In function 'wb_newbuf': /src/sys/dev/wb/if_wb.c:850: warning: passing argument 4 of 'm_extadd' from incompatible pointer type *** Error code 1 Stop. bmake[1]: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-24 23:04:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-24 23:04:23 - ERROR: failed to build LINT kernel TB --- 2013-08-24 23:04:23 - 5262.08 user 951.80 system 6656.69 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 23:04:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C9199B65; Sat, 24 Aug 2013 23:04:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FF07297F; Sat, 24 Aug 2013 23:04:45 +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 r7ON4iOj084655; Sat, 24 Aug 2013 19:04:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7ON4idX084652; Sat, 24 Aug 2013 23:04:44 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 24 Aug 2013 23:04:44 GMT Message-Id: <201308242304.r7ON4idX084652@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: Sat, 24 Aug 2013 23:04:48 -0000 TB --- 2013-08-24 22:01:41 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-24 22:01:41 - 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-08-24 22:01:41 - starting HEAD tinderbox run for mips64/mips TB --- 2013-08-24 22:01:41 - cleaning the object tree TB --- 2013-08-24 22:01:41 - /usr/local/bin/svn stat /src TB --- 2013-08-24 22:01:44 - At svn revision 254801 TB --- 2013-08-24 22:01:45 - building world TB --- 2013-08-24 22:01:45 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 22:01:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 22:01:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 22:01:45 - SRCCONF=/dev/null TB --- 2013-08-24 22:01:45 - TARGET=mips TB --- 2013-08-24 22:01:45 - TARGET_ARCH=mips64 TB --- 2013-08-24 22:01:45 - TZ=UTC TB --- 2013-08-24 22:01:45 - __MAKE_CONF=/dev/null TB --- 2013-08-24 22:01:45 - cd /src TB --- 2013-08-24 22:01:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Aug 24 22:01:52 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 Sat Aug 24 23:03:51 UTC 2013 TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m ADM5120 TB --- 2013-08-24 23:03:51 - skipping ADM5120 kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m ALCHEMY TB --- 2013-08-24 23:03:51 - skipping ALCHEMY kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AP121 TB --- 2013-08-24 23:03:51 - skipping AP121 kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AP91 TB --- 2013-08-24 23:03:51 - skipping AP91 kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AP93 TB --- 2013-08-24 23:03:51 - skipping AP93 kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AP94 TB --- 2013-08-24 23:03:51 - skipping AP94 kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AP96 TB --- 2013-08-24 23:03:51 - skipping AP96 kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-08-24 23:03:51 - skipping AR71XX_BASE kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AR724X_BASE TB --- 2013-08-24 23:03:51 - skipping AR724X_BASE kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-08-24 23:03:51 - skipping AR91XX_BASE kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AR933X_BASE TB --- 2013-08-24 23:03:51 - skipping AR933X_BASE kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m AR934X_BASE TB --- 2013-08-24 23:03:51 - skipping AR934X_BASE kernel TB --- 2013-08-24 23:03:51 - cd /src/sys/mips/conf TB --- 2013-08-24 23:03:51 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-08-24 23:03:51 - building BERI_DE4_MDROOT kernel TB --- 2013-08-24 23:03:51 - CROSS_BUILD_TESTING=YES TB --- 2013-08-24 23:03:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-24 23:03:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-24 23:03:51 - SRCCONF=/dev/null TB --- 2013-08-24 23:03:51 - TARGET=mips TB --- 2013-08-24 23:03:51 - TARGET_ARCH=mips64 TB --- 2013-08-24 23:03:51 - TZ=UTC TB --- 2013-08-24 23:03:51 - __MAKE_CONF=/dev/null TB --- 2013-08-24 23:03:51 - cd /src TB --- 2013-08-24 23:03:51 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Sat Aug 24 23:03:52 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=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/kern_lockf.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=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/kern_loginclass.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=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/kern_malloc.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=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/kern/kern_mbuf.c /src/sys/kern/kern_mbuf.c: In function 'mb_ctor_pack': /src/sys/kern/kern_mbuf.c:637: error: 'error' undeclared (first use in this function) /src/sys/kern/kern_mbuf.c:637: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_mbuf.c:637: error: for each function it appears in.) *** Error code 1 Stop. bmake[1]: stopped in /obj/mips.mips64/src/sys/BERI_DE4_MDROOT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-24 23:04:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-24 23:04:44 - ERROR: failed to build BERI_DE4_MDROOT kernel TB --- 2013-08-24 23:04:44 - 2709.46 user 640.59 system 3783.41 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 23:06:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 60126C8E; Sat, 24 Aug 2013 23:06:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B0182999; Sat, 24 Aug 2013 23:06:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7ON6FqH055902; Sat, 24 Aug 2013 16:06:15 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7ON6F2w055901; Sat, 24 Aug 2013 16:06:15 -0700 (PDT) (envelope-from sgk) Date: Sat, 24 Aug 2013 16:06:15 -0700 From: Steve Kargl To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130824230615.GA55855@troutmask.apl.washington.edu> References: <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5217413A.9080105@passap.ru> <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current , Slawa Olhovchenkov 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, 24 Aug 2013 23:06:16 -0000 On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: > On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > > > And i found PR about clang and mplayer: ports/176272 > > This PR contains log with build error log. > > Please file clang bugs at http://llvm.org/bugs/ > As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. -- Steve