From owner-freebsd-current@FreeBSD.ORG Sun Sep 30 13:04:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D277E106566C; Sun, 30 Sep 2012 13:04:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 986B68FC08; Sun, 30 Sep 2012 13:04:54 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q8UD4m9U041784; Sun, 30 Sep 2012 06:04:48 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q8UD4meH041783; Sun, 30 Sep 2012 06:04:48 -0700 (PDT) (envelope-from david) Date: Sun, 30 Sep 2012 06:04:48 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20120930130448.GQ1645@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8so8ZvRz607RvwFp" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: clang reports reports errors (buildkernel @r241067) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 13:04:54 -0000 --8so8ZvRz607RvwFp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable E.g.: =2E.. =3D=3D=3D> bios (all) =3D=3D=3D> bios/smapi (all) ctfconvert -L VERSION -g hdacc.o clang -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DH= AVE_KERNEL_OPTION_HEADERS -include /common/S4/obj/usr/src/sys/CANARY/opt_gl= obal.h -I. -I@ -I@/contrib/altq -fno-common -g -I/common/S4/obj/usr/src/sys= /CANARY -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -f= stack-protector -std=3Diso9899:1999 -Qunused-arguments -fstack-protector -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-erro= r-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equali= ty -no-integrated-as -c /usr/src/sys/modules/bios/smapi/../../../i386/bios= /smapi_bios.S clang -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -= Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qu= al -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/usr/src/sys -I/usr/= src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_gl= obal.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fs= tack-protector -Werror /usr/src/sys/dev/sound/pcm/ac97.c ctfconvert -L VERSION -g smapi_bios.o ctfconvert -L VERSION -g ac97.o clang -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DH= AVE_KERNEL_OPTION_HEADERS -include /common/S4/obj/usr/src/sys/CANARY/opt_gl= obal.h -I. -I@ -I@/contrib/altq -fno-common -g -I/common/S4/obj/usr/src/sys= /CANARY -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -f= stack-protector -std=3Diso9899:1999 -Qunused-arguments -fstack-protector -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-erro= r-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equali= ty -c /usr/src/sys/modules/bios/smapi/../../../i386/bios/smapi.c ctfconvert -L VERSION -g hdac.o /usr/src/sys/modules/bios/smapi/../../../i386/bios/smapi.c:295:3: warning: = implicit declaration of function 'free' is invalid in C99 [-Wimplicit-funct= ion-declaration] free(devs, M_TEMP); ^ /usr/src/sys/modules/bios/smapi/../../../i386/bios/smapi.c:295:14: error: u= se of undeclared identifier 'M_TEMP' free(devs, M_TEMP); ^ 1 warning and 1 error generated. clang -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -= Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qu= al -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/usr/src/sys -I/usr/= src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_gl= obal.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fs= tack-protector -Werror /usr/src/sys/dev/sound/pcm/ac97_patch.c *** [smapi.o] Error code 1 1 error *** [all] Error code 2 1 error *** [all] Error code 2 1 error *** [modules-all] Error code 2 clang -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -= Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qu= al -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/usr/src/sys -I/usr/= src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_gl= obal.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fs= tack-protector -Werror /usr/src/sys/dev/sound/pcm/channel.c ctfconvert -L VERSION -g ac97_patch.o ctfconvert -L VERSION -g channel.o ctfconvert -L VERSION -g hdaa.o 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error It looks to me as if sys/i386/bios/smapi.c lacks #include #include (ref. free(9)) -- but I'm not all that much of a kernel hacker, so I may well be off-base here. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --8so8ZvRz607RvwFp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBoQ28ACgkQmprOCmdXAD3eLgCcDZ8QjG023721Z9xxOPzV8F6W mpEAn0I388727bP/hXPJtQBcViZYkRa1 =+1DK -----END PGP SIGNATURE----- --8so8ZvRz607RvwFp-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 30 16:37:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 638FD1065672 for ; Sun, 30 Sep 2012 16:37:56 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id C86948FC14 for ; Sun, 30 Sep 2012 16:37:54 +0000 (UTC) Received: from free.fr (unknown [82.235.65.2]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0D885D48144 for ; Sun, 30 Sep 2012 18:37:49 +0200 (CEST) From: Raoul MEGELAS To: freebsd-current@freebsd.org Date: Sun, 30 Sep 2012 18:37:48 +0200 Sender: root@free.fr Message-Id: <20120930163750.0D885D48144@smtp5-g21.free.fr> Subject: gpart on macbook air X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 16:37:56 -0000 Hi all, i installed CURRENT on a macbook air (internal ssd as you know): i noticed the following: 1. on freebsd, deleting a partition with gpart: say gpart delete -i 4 ada0 dammage the osx boot. of cours, booting with a backup disk and repairing the disk make it functional again. any light woukd be appreciated on this topic. 2. my gpart partitions table looks like this: => 34 490234685 ada0 GPT (233G) 34 6 - free - (3.0k) 40 409600 1 efi (200M) 409640 449218744 2 apple-hfs (214G) 449628384 1269536 3 apple-boot (619M) 450897920 256 4 freebsd-boot (128k) 450898176 1024000 5 freebsd-swap (500M) 451922176 38312543 6 freebsd-ufs (18G) no special mbr: planty of 00 and at offset 1be only the efi table, mapping the entire disk. the refit sourceforge project soft, does not recognizes the gpt freebsd-boot. and i cannot find how to boot from the internal drive. i hope i am sufficiently clear? of course, i can boot at this time from an external FreeBSD drive with a mbr and a label; this works. Is it a solution to solve this problem other booting from an external drive/Usb keyflash card? Thanks a lot for your time and reply. Raoul rmgls Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 51C85106564A for ; Sun, 30 Sep 2012 17:43:57 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7DC1214DA8C; Sun, 30 Sep 2012 17:43:56 +0000 (UTC) Message-ID: <506884D6.8090507@FreeBSD.org> Date: Sun, 30 Sep 2012 21:43:50 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: Raoul MEGELAS References: <20120930163750.0D885D48144@smtp5-g21.free.fr> In-Reply-To: <20120930163750.0D885D48144@smtp5-g21.free.fr> X-Enigmail-Version: 1.4 OpenPGP: id=10C8A17A Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: gpart on macbook air X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 17:43:57 -0000 On 30.09.2012 20:37, Raoul MEGELAS wrote: > i installed CURRENT on a macbook air > (internal ssd as you know): > i noticed the following: > > 1. on freebsd, deleting a partition with gpart: say > gpart delete -i 4 ada0 > dammage the osx boot. > of cours, booting with a backup disk and repairing the disk > make it functional again. > any light woukd be appreciated on this topic. Hi, When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Sun Sep 30 19:07:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D285106566B; Sun, 30 Sep 2012 19:07:05 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7CE8FC08; Sun, 30 Sep 2012 19:07:02 +0000 (UTC) Received: from free.fr (unknown [82.235.65.2]) by smtp5-g21.free.fr (Postfix) with ESMTP id 82A69D480FF; Sun, 30 Sep 2012 21:06:58 +0200 (CEST) To: "Andrey V. Elsukov" From: Raoul MEGELAS Date: Sun, 30 Sep 2012 21:06:57 +0200 Sender: root@free.fr Message-Id: <20120930190658.82A69D480FF@smtp5-g21.free.fr> Cc: freebsd-current@freebsd.org Subject: Re: gpart on macbook air X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 19:07:05 -0000 On Sun, 30 Sep 2012 21:43:50 +0400 "Andrey V. Elsukov" wrote: > On 30.09.2012 20:37, Raoul MEGELAS wrote: > > i installed CURRENT on a macbook air > > (internal ssd as you know): > > i noticed the following: > > > > 1. on freebsd, deleting a partition with gpart: say > > gpart delete -i 4 ada0 > > dammage the osx boot. > > of cours, booting with a backup disk and repairing the disk > > make it functional again. > > any light woukd be appreciated on this topic. > > Hi, > > When you are deleting a partition, the kernel completely overwrites the > partition table and PMBR area. You can compare first 34 blocks before > deletion and after to see what is going on. > > -- > WBR, Andrey V. Elsukov Hi Andrey, I can understand that, but i would have thought that the deletion of the concerned partition was written preserving others??? something like: - read the gpt table - find the offset - zeroes the partition entry - rewrites the table? is not that logic? if it is not so, i does not understand this behaviour. Thanks. raoul rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 06:54:59 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 03FDD106568F for ; Mon, 1 Oct 2012 06:54:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9271814D840; Mon, 1 Oct 2012 06:54:30 +0000 (UTC) Message-ID: <50693E26.4020207@FreeBSD.org> Date: Sun, 30 Sep 2012 23:54:30 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: matt References: <5059194F.4090002@FreeBSD.org> <50595E93.9080908@gmail.com> <50595F83.9030008@FreeBSD.org> <5059636B.4020902@gmail.com> In-Reply-To: <5059636B.4020902@gmail.com> X-Enigmail-Version: 1.4.4 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: squealing/whistling audio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 06:54:59 -0000 On 09/18/2012 23:17, matt wrote: > On 09/18/12 23:00, Doug Barton wrote: >> On 9/18/2012 10:56 PM, matt wrote: >>> On 09/18/12 18:01, Doug Barton wrote: >>>> Sometime in the last couple of months an old problem has resurfaced on >>>> HEAD, a sort of squealing/whistling sound in the audio, even without >>>> anything playing. The sound is similar to the wind whistling through >>>> something. >>>> >>>> Before I blindly go off on a bisecting spree, does anyone have a >>>> suggestion as to where I might look? >>>> >>>> Doug >>>> >>>> >>> Electrically that's usually oscillation (too high gain or too much >>> electrical feedback) or an unshielded input. >> Sorry, I should have been more clear. This problem doesn't occur in >> windows, or linux, and last time I checked, didn't occur in freebsd 8. I >> have everything irrlevant zeroed out in mixer. >> >> Doug >> > It was worth a shot. It is possible that each OS (and version) is > setting the associations up properly though except HEAD on your machine. > Is it a laptop or a desktop board? Desktop. > Any difference in the nid configuration between freebsd 8 and HEAD? No. > Does changing any of the hw.snd sysctls (latency, exact rate, vpc_0db) > have any effect on the sound? It doesn't affect the squeal. > http://freshbsd.org/commit/freebsd/r230551 might be worth a look. Didn't help. > I > couldn't find anything newer that looked like it would have an effect. > Their are some earlier commits around January that are dealing with > signal gain that could also have an effect. > > Otherwise, I'm not sure where else to look. Thanks anyway. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 08:29:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BB95106566C for ; Mon, 1 Oct 2012 08:29:11 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id B745B8FC0C for ; Mon, 1 Oct 2012 08:29:10 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 5FB48B805E; Mon, 1 Oct 2012 12:29:03 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 55B9DB8027; Mon, 1 Oct 2012 12:29:03 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 3761BBA0D9; Mon, 1 Oct 2012 12:29:03 +0400 (MSK) Received: from [127.0.0.1] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id 02FA2BA0BE; Mon, 1 Oct 2012 12:29:02 +0400 (MSK) Message-ID: <5069544E.9030501@FreeBSD.org> Date: Mon, 01 Oct 2012 12:29:02 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Raoul MEGELAS References: <20120930190658.82A69D480FF@smtp5-g21.free.fr> In-Reply-To: <20120930190658.82A69D480FF@smtp5-g21.free.fr> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-current@freebsd.org Subject: Re: gpart on macbook air X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 08:29:11 -0000 On 30.09.2012 23:06, Raoul MEGELAS wrote: >> When you are deleting a partition, the kernel completely overwrites the >> partition table and PMBR area. You can compare first 34 blocks before >> deletion and after to see what is going on. > > I can understand that, but i would have thought > that the deletion of the concerned partition was written preserving others??? > > something like: > > - read the gpt table > - find the offset > - zeroes the partition entry > - rewrites the table? > > is not that logic? > > if it is not so, i does not understand this behaviour. Hi, Raoul, The kernel has a copy of the partition table in the memory. When you are deleting some partition, it removes the partition entry from the memory, constructs updated GPT header and table, calculates checksums and writes this data into corresponding places. Any way, this should correctly work. My guess is that Apple's boot loader detects some changes and just doesn't want to work. If you think that gpart incorrectly works, please make a copy of first 34 blocks before and after deletion and send them to me. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 09:46:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA459106564A; Mon, 1 Oct 2012 09:46:34 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id BEA128FC14; Mon, 1 Oct 2012 09:46:32 +0000 (UTC) Received: from free.fr (unknown [82.235.65.2]) by smtp5-g21.free.fr (Postfix) with ESMTP id 45AEBD4815C; Mon, 1 Oct 2012 11:46:28 +0200 (CEST) To: "Andrey V. Elsukov" From: Raoul MEGELAS Date: Mon, 01 Oct 2012 11:46:27 +0200 Sender: root@free.fr Message-Id: <20121001094628.45AEBD4815C@smtp5-g21.free.fr> Cc: freebsd-current@freebsd.org Subject: Re: gpart on macbook air X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:46:35 -0000 On Mon, 01 Oct 2012 12:29:02 +0400 From: "Andrey V. Elsukov" wrote: On 30.09.2012 23:06, Raoul MEGELAS wrote: >>> When you are deleting a partition, the kernel completely overwrites the >>> partition table and PMBR area. You can compare first 34 blocks before >>> deletion and after to see what is going on. >> >> I can understand that, but i would have thought >> that the deletion of the concerned partition was written preserving others??? >> >> something like: >> >> - read the gpt table >> - find the offset >> - zeroes the partition entry >> - rewrites the table? >> >> is not that logic? >> >> if it is not so, i does not understand this behaviour. > Hi, Raoul, > > The kernel has a copy of the partition table in the memory. > When you are deleting some partition, it removes the partition entry > from the memory, constructs updated GPT header and table, calculates > checksums and writes this data into corresponding places. > Any way, this should correctly work. > > My guess is that Apple's boot loader detects some changes and > just doesn't want to work. If you think that gpart incorrectly works, > please make a copy of first 34 blocks before and after deletion and > send them to me. Hi Andrey, thanks for your clear explaination; that make sense. in all case i will backup my 18g freebsd partition and and delete it. as soon as possible will send privately the two copy of the first 34 blocks of the disk, before and after deletion. Thanks again. Raoul rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 09:47:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56BF91065670 for ; Mon, 1 Oct 2012 09:47:51 +0000 (UTC) (envelope-from reytsman@solvex.travel) Received: from mail.solvex.travel (mail.solvex.travel [93.153.180.116]) by mx1.freebsd.org (Postfix) with ESMTP id 133BE8FC1A for ; Mon, 1 Oct 2012 09:47:49 +0000 (UTC) Received: from servermail2.Solvex.local (192.168.12.8) by serveredge-zag.solvex.local (192.168.12.16) with Microsoft SMTP Server (TLS) id 14.0.722.0; Mon, 1 Oct 2012 13:47:50 +0400 Received: from SERVERMAIL3.Solvex.local ([fe80::840:c797:9012:d0a]) by servermail2.solvex.local ([fe80::90fa:439b:e017:73d8%10]) with mapi id 14.01.0355.002; Mon, 1 Oct 2012 13:47:50 +0400 From: Alexey Reytsman To: "freebsd-current@freebsd.org" Thread-Topic: high interrupts load xhci Thread-Index: Ac2fuJVnxh1pbZiKTFaGTM1X7zmtHQ== Date: Mon, 1 Oct 2012 09:47:49 +0000 Message-ID: Accept-Language: ru-RU, en-US Content-Language: ru-RU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.12.59] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: high interrupts load xhci X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:47:51 -0000 SGVsbG8uDQpJIGhhdmUgYSB2ZXJ5IGhpZ2ggaW50ZXJydXB0cyBsb2FkIG9uIG15IEZyZWVCU0Qg bWFjaGluZS4gSXQgaGFwcGVucyB3aGVuIEkgcGx1ZyBhbnkgVVNCIGRldmljZSAobGlrZSBhIGtl eWJvYXJkKSwgYW5kIHRoZSBsb2FkIGlzIHN0aWxsIGhpZ2ggYWZ0ZXIgZGlzY29ubmVjdGluZyB0 aGUgZGV2aWNlLiBJdCBiZWNvbWVzIG5vcm1hbCBhZnRlciByZWJvb3QuDQpNeSBzeXN0ZW0gYmFz ZWQgb24gQVNVUyBQOFo2OC1WIFByby9HZW4zIG1vdGhlcmJvYXJkLg0KTVlLRVJORUwgaXMgdGhl IEdFTkVSSUMga2VybmVsIHdpdGggaXBmdyBzdXBwb3J0Lg0KDQpTb3JyeSBmb3IgYmFkIEVuZ2xp c2guDQpTb21lIGRlYnVnIGluZm9ybWF0aW9uIGJlbG93Og0KDQojIHVuYW1lIC1hDQpGcmVlQlNE IHNlcnZlcmdhdGUgOS4wLVJFTEVBU0UgRnJlZUJTRCA5LjAtUkVMRUFTRSAjMDogV2VkIE1hciAy OCAxNTowMDozNiBNU0sgMjAxMiByb290QHNlcnZlcmdhdGU6L3Vzci9zcmMvc3lzL2FtZDY0L2Nv bXBpbGUvTVlLRVJORUwgYW1kNjQNCg0KIyB2bXN0YXQgLWkNCmludGVycnVwdCAgICAgICAgICAg ICAgICAgICAgICAgICAgdG90YWwgICAgICAgcmF0ZQ0KaXJxMTY6IHhoY2kxICAgICAgICAgICAg ICAgICAxMjAyNzU3NzkzMCAgICAgIDE5NjIwDQppcnEyMzogZWhjaTAgZWhjaTEgICAgICAgICAg ICAgICAxODUzMzA2ICAgICAgICAgIDMNCmNwdTA6dGltZXIgICAgICAgICAgICAgICAgICAgICA2 Mjg1NjQ4MzYgICAgICAgMTAyNQ0KaXJxMjU2OiBlbTA6cnggMCAgICAgICAgICAgICAgICA1NjA2 NDAwNSAgICAgICAgIDkxDQppcnEyNTc6IGVtMDp0eCAwICAgICAgICAgICAgICAgIDQzNTUwNzg2 ICAgICAgICAgNzENCmlycTI1ODogZW0wOmxpbmsgICAgICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgMA0KaXJxMjYyOiBlbTI6cnggMCAgICAgICAgICAgICAgIDU1MzkwNDQ0OSAgICAgICAg OTAzDQppcnEyNjM6IGVtMjp0eCAwICAgICAgICAgICAgICAgNTEyMTY2OTg3ICAgICAgICA4MzUN CmlycTI2NDogZW0yOmxpbmsgICAgICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgMA0KaXJx MjY1OiBlbTM6cnggMCAgICAgICAgICAgICAgIDMwODczNzg2NyAgICAgICAgNTAzDQppcnEyNjY6 IGVtMzp0eCAwICAgICAgICAgICAgICAgNjA3MDg1NDk5ICAgICAgICA5OTANCmlycTI2ODogYWhj aTAgICAgICAgICAgICAgICAgICAgIDU4ODUwMDggICAgICAgICAgOQ0KY3B1MTp0aW1lciAgICAg ICAgICAgICAgICAgICAgIDEzMDE0NjEyMiAgICAgICAgMjEyDQpjcHUzOnRpbWVyICAgICAgICAg ICAgICAgICAgICAgMTAzMzA2MzM1ICAgICAgICAxNjgNCmNwdTI6dGltZXIgICAgICAgICAgICAg ICAgICAgICAgNjAwNzI5MTIgICAgICAgICA5Nw0KVG90YWwgICAgICAgICAgICAgICAgICAgICAg ICAxNTAzODkxNjA0NSAgICAgIDI0NTMzDQoNCg0KIyBzeXNjdGwgaHcudXNiLnhoY2kuZGVidWc9 MTYgOyBzbGVlcCAxOyBzeXNjdGwgaHcudXNiLnhoY2kuZGVidWc9MA0KDQovdmFyL2xvZy9tZXNz YWdlcw0KDQpPY3QgIDEgMTI6NDY6Mjggc2VydmVyZ2F0ZSBrZXJuZWw6IHhoY2lfaW50ZXJydXB0 OiByZWFsIGludGVycnVwdCAoc3RzPTB4MDAwMDAwMDAsIGltYW49MHgwMDAwMDAwMikNCg0KT2N0 ICAxIDEyOjQ2OjI5IHNlcnZlcmdhdGUgbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDQyMzkgdGltZXMN Cg0KDQojIHN5c2N0bCBody51c2IueGhjaS5kZWJ1Zz0xNiA7IHNsZWVwIDIgOyBzeXNjdGwgaHcu dXNiLnhoY2kuZGVidWc9MA0KL3Zhci9sb2cvbWVzc2FnZXMNCk9jdCAgMSAxMjo0Nzo0MiBzZXJ2 ZXJnYXRlIGxhc3QgbWVzc2FnZSByZXBlYXRlZCA4NDkwIHRpbWVzDQoNCiMgc3lzdGF0IC12bXN0 YXQNCiAgICAxIHVzZXJzICAgIExvYWQgIDAuNjMgIDAuNTUgIDAuNTUgICAgICAgICAgICAgICAg ICBPY3QgIDEgMTM6NDENCg0KTWVtOktCICAgIFJFQUwgICAgICAgICAgICBWSVJUVUFMICAgICAg ICAgICAgICAgICAgICAgICBWTiBQQUdFUiAgIFNXQVAgUEFHRVINCiAgICAgICAgVG90ICAgU2hh cmUgICAgICBUb3QgICAgU2hhcmUgICAgRnJlZSAgICAgICAgICAgaW4gICBvdXQgICAgIGluICAg b3V0DQpBY3QgMTQ4NTg3NiAgMTU5MTg0ICA1NzQwNTUyICAgMTc2NTUyIDI4NTc3MjAgIGNvdW50 DQpBbGwgMTU4NTg0NCAgMTY1MDM2IDEwNzk2NjFrICAgMjEwMzY4ICAgICAgICAgIHBhZ2VzDQpQ cm9jOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEludGVycnVwdHMNCiAgciAgIHAgICBkICAgcyAgIHcgICBDc3cgIFRycCAgU3lzICBJ bnQgIFNvZiAgRmx0ICAgICAgICBjb3cgICAgMTc1ayB0b3RhbA0KICAgICAgICAgICAgMTQwICAg ICAgMzUzayAgIDQxICA5MzggMTcyayAxMDQ0ICAgIDMgICAgICAyIHpmb2QgICAxNjVrIHhoY2kx IDE2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgb3pmb2QgICAgIDMgZWhjaTAgZWhjaQ0KMC4xJVN5cyAgMTcuMCVJbnRyICAwLjAlVXNl ciAgMC4wJU5pY2UgODIuOSVJZGxlICAgICAgICAlb3pmb2QgIDExMjcgY3B1MDp0aW1lcg0KfCAg ICB8ICAgIHwgICAgfCAgICB8ICAgIHwgICAgfCAgICB8ICAgIHwgICAgfCAgICB8ICAgICAgIGRh ZWZyICAgODA5IGVtMDpyeCAwDQorKysrKysrKysgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgcHJjZnIgICA0NzMgZW0wOnR4IDANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA0MSBkdGJ1ZiAgICAgICAgMiB0b3RmciAgICAgICBl bTA6bGluaw0KTmFtZWkgICAgIE5hbWUtY2FjaGUgICBEaXItY2FjaGUgICAgMjA0OTMxIGRlc3Zu ICAgICAgICAgIHJlYWN0ICAxNDk2IGVtMjpyeCAwDQogICBDYWxscyAgICBoaXRzICAgJSAgICBo aXRzICAgJSAgICAxNzI1MDEgbnVtdm4gICAgICAgICAgcGR3YWsgIDE1MzcgZW0yOnR4IDANCiAg ICAgMzkxICAgICAzODUgIDk4ICAgICAgICAgICAgICAgICA0OTI2NyBmcmV2biAgICAgICAgICBw ZHBncyAgICAgICBlbTI6bGluaw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGludHJuICAxMzM5IGVtMzpyeCAwDQpEaXNrcyAgYWRhMCAg YWRhMSBwYXNzMCBwYXNzMSAgICAgICAgICAgICAgICAgICAgICA4NzU5NjAgd2lyZSAgIDIyMDEg ZW0zOnR4IDANCktCL3QgIDMwLjczIDMwLjczICAwLjAwICAwLjAwICAgICAgICAgICAgICAgICAg ICAgMTEyMjU4NCBhY3QgICAgICAgOSBhaGNpMCAyNjgNCnRwcyAgICAgICA0ICAgICA0ICAgICAw ICAgICAwICAgICAgICAgICAgICAgICAgICAgMzE0NTY3MiBpbmFjdCAgIDk2MiBjcHUxOnRpbWVy DQpNQi9zICAgMC4xMyAgMC4xMyAgMC4wMCAgMC4wMCAgICAgICAgICAgICAgICAgICAgICAgICAy NzYgY2FjaGUgICAyNTQgY3B1Mzp0aW1lcg0KJWJ1c3kgICAgIDAgICAgIDAgICAgIDAgICAgIDAg ICAgICAgICAgICAgICAgICAgICAyODU3NDQ0IGZyZWUgICAgMTA1IGNwdTI6dGltZXINCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDgzNzE1MiBidWYN Cg0KIyBwY2ljb25mIC1sdg0KaG9zdGIwQHBjaTA6MDowOjA6IGNsYXNzPTB4MDYwMDAwIGNhcmQ9 MHg4NDRkMTA0MyBjaGlwPTB4MDEwMDgwODYgcmV2PTB4MDkgaGRyPTB4MDANCnZlbmRvciA9ICdJ bnRlbCBDb3Jwb3JhdGlvbicNCmRldmljZSA9ICcybmQgR2VuZXJhdGlvbiBDb3JlIFByb2Nlc3Nv ciBGYW1pbHkgRFJBTSBDb250cm9sbGVyJw0KY2xhc3MgPSBicmlkZ2UNCnN1YmNsYXNzID0gSE9T VC1QQ0kNCi0gLSAtIC0gLQ0KeGhjaTBAcGNpMDo0OjA6MDogY2xhc3M9MHgwYzAzMzAgY2FyZD0w eDg0ODgxMDQzIGNoaXA9MHgxMDQyMWIyMSByZXY9MHgwMCBoZHI9MHgwMA0KdmVuZG9yID0gJ0FT TWVkaWEgVGVjaG5vbG9neSBJbmMuJw0KZGV2aWNlID0gJ0FTTTEwNDIgU3VwZXJTcGVlZCBVU0Ig SG9zdCBDb250cm9sbGVyJw0KY2xhc3MgPSBzZXJpYWwgYnVzDQpzdWJjbGFzcyA9IFVTQg0KLSAt IC0gLSAtDQp4aGNpMUBwY2kwOjc6MDowOiBjbGFzcz0weDBjMDMzMCBjYXJkPTB4ODQ4ODEwNDMg Y2hpcD0weDEwNDIxYjIxIHJldj0weDAwIGhkcj0weDAwDQp2ZW5kb3IgPSAnQVNNZWRpYSBUZWNo bm9sb2d5IEluYy4nDQpkZXZpY2UgPSAnQVNNMTA0MiBTdXBlclNwZWVkIFVTQiBIb3N0IENvbnRy b2xsZXInDQpjbGFzcyA9IHNlcmlhbCBidXMNCnN1YmNsYXNzID0gVVNCDQoNCg0K From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 06:00:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E59D10656D6 for ; Mon, 1 Oct 2012 06:00:37 +0000 (UTC) (envelope-from radiomlodychbandytow@o2.pl) Received: from moh2-ve2.go2.pl (moh2-ve2.go2.pl [193.17.41.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3774A8FC12 for ; Mon, 1 Oct 2012 06:00:37 +0000 (UTC) Received: from moh2-ve2.go2.pl (unknown [10.0.0.200]) by moh2-ve2.go2.pl (Postfix) with ESMTP id 3B897B03811 for ; Mon, 1 Oct 2012 07:51:36 +0200 (CEST) Received: from unknown (unknown [10.0.0.74]) by moh2-ve2.go2.pl (Postfix) with SMTP for ; Mon, 1 Oct 2012 07:51:36 +0200 (CEST) Received: from unknown [93.175.69.74] by poczta.o2.pl with ESMTP id Ypnhvx; Mon, 01 Oct 2012 07:51:36 +0200 Message-ID: <50692F65.50103@o2.pl> Date: Mon, 01 Oct 2012 07:51:33 +0200 From: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20120905073430.D14B910657D3@hub.freebsd.org> In-Reply-To: <20120905073430.D14B910657D3@hub.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-O2-Trust: 1, 39 X-O2-SPF: neutral X-Mailman-Approved-At: Mon, 01 Oct 2012 11:48:14 +0000 Subject: Re: freebsd-current Digest, Vol 464, Issue 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 06:00:37 -0000 On 2012-09-05 09:34, freebsd-current-request@freebsd.org wrote: > Hi all, > > I recently performed a series of compiler performance tests on FreeBSD > 10.0-CURRENT, particularly comparing gcc 4.2.1 and gcc 4.7.1 against > clang 3.1 and clang 3.2. Hey, you've got a cool idea, but the implementation ain't good...you can't compare optimising compilers w/out comparing optimisation quality. If you don't go all-out in one dimension, both are necessary. You conclude that Clang is faster. But maybe if you lowered optimisation level on gcc, it would become faster and stronger than Clang at the same time? We don't know, it hasn't been tested. Regards, -- Twoje radio From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 12:58:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC8851065677 for ; Mon, 1 Oct 2012 12:58:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 83BC48FC1A for ; Mon, 1 Oct 2012 12:58:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D460CB94B; Mon, 1 Oct 2012 08:58:16 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 1 Oct 2012 08:04:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; 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: <201210010804.08925.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Oct 2012 08:58:16 -0400 (EDT) Cc: Kim Culhan Subject: Re: panic possibly on on bridge member removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:58:17 -0000 On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote: > After a few hours of operation involving tap0 added to the bridge > running openvpn > and shutting down openvpn which removes tap0 from the bridge, the > machine is found to have a panic: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x188 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff82a14f96 > stack pointer = 0x28:0xffffff8000285670 > frame pointer = 0x28:0xffffff80002856b0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (swi5: fast taskq) > [ thread pid 12 tid 100022 ] > Stopped at bridge_enqueue+0x86: calll *0x188(%r12) > db> bt > Tracing pid 12 tid 100022 td 0xfffffe0003aff000 > bridge_enqueue() at bridge_enqueue+0x86 Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 13:08:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F508106566B; Mon, 1 Oct 2012 13:08:31 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C598A8FC12; Mon, 1 Oct 2012 13:08:30 +0000 (UTC) Received: by vbmv11 with SMTP id v11so6827990vbm.13 for ; Mon, 01 Oct 2012 06:08:30 -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=xzAwm+c7y0xZQa6UVJUf9x2GQMa5QARN6Qq7BCVYMZI=; b=Z4QAHirDD2BL92CnqKnEWGXqo/FkXYQI2d1kxZ53oyWsKG9AlCpVV6xm7R6Km637YZ x8PuE+V6rsI+ZovXyMU5VpTiOAPp4OCyTLVIFwwH4deE0vY7qLrs92AeAoV6wTyRHDL0 pdjph0zOIkynYbjCJzSDPM+lr6LrdtirCXrrIs0ezXiH7ybZdDoIC5nBKcaQE/C6QmF/ sC4/rVk3by2GTW7jRFtTZ+xnIGjqflOoS1nehYKQpL3CJHOQjf3P8CmfomaQ8GYmrGnI QupjTLH385CXgxqER7nC7/hBL+pas8x0CDG7e7qlHN6N8xL40ngYMLIpmBUdua9RczPu Tw3w== MIME-Version: 1.0 Received: by 10.52.68.201 with SMTP id y9mr6775506vdt.68.1349096910071; Mon, 01 Oct 2012 06:08:30 -0700 (PDT) Received: by 10.58.226.163 with HTTP; Mon, 1 Oct 2012 06:08:30 -0700 (PDT) In-Reply-To: <201210010804.08925.jhb@freebsd.org> References: <201210010804.08925.jhb@freebsd.org> Date: Mon, 1 Oct 2012 09:08:30 -0400 Message-ID: From: Kim Culhan To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: panic possibly on on bridge member removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 13:08:31 -0000 On Mon, Oct 1, 2012 at 8:04 AM, John Baldwin wrote: > On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote: >> After a few hours of operation involving tap0 added to the bridge >> running openvpn >> and shutting down openvpn which removes tap0 from the bridge, the >> machine is found to have a panic: >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x188 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff82a14f96 >> stack pointer = 0x28:0xffffff8000285670 >> frame pointer = 0x28:0xffffff80002856b0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 12 (swi5: fast taskq) >> [ thread pid 12 tid 100022 ] >> Stopped at bridge_enqueue+0x86: calll *0x188(%r12) >> db> bt >> Tracing pid 12 tid 100022 td 0xfffffe0003aff000 >> bridge_enqueue() at bridge_enqueue+0x86 > > Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'? > > -- > John Baldwin (gdb) l *bridge_enqueue+0x86 No symbol "bridge_enqueue" in current context. (gdb) -- -kim From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 13:10:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62E4010656D6; Mon, 1 Oct 2012 13:10:30 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id 451668FC15; Mon, 1 Oct 2012 13:10:27 +0000 (UTC) Received: from free.fr (unknown [82.235.65.2]) by smtp5-g21.free.fr (Postfix) with ESMTP id BD6C3D481A3; Mon, 1 Oct 2012 15:10:23 +0200 (CEST) To: "Andrey V. Elsukov" From: Raoul MEGELAS Date: Mon, 01 Oct 2012 15:10:22 +0200 Sender: root@free.fr Message-Id: <20121001131023.BD6C3D481A3@smtp5-g21.free.fr> Cc: freebsd-current@freebsd.org Subject: Re: gpart on macbook air X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 13:10:30 -0000 on Mon, 01 Oct 2012 12:29:02 +0400 "Andrey V. Elsukov" wrote: On 30.09.2012 23:06, Raoul MEGELAS wrote: >>> When you are deleting a partition, the kernel completely overwrites the >>> partition table and PMBR area. You can compare first 34 blocks before >>> deletion and after to see what is going on. >> >> I can understand that, but i would have thought >> that the deletion of the concerned partition was written preserving others??? >> >> something like: >> >> - read the gpt table >> - find the offset >> - zeroes the partition entry >> - rewrites the table? >> >> is not that logic? >> >> if it is not so, i does not understand this behaviour. > Hi, Raoul, > > The kernel has a copy of the partition table in the memory. > When you are deleting some partition, it removes the partition entry > from the memory, constructs updated GPT header and table, calculates > checksums and writes this data into corresponding places. > Any way, this should correctly work. > > My guess is that Apple's boot loader detects some changes and > just doesn't want to work. If you think that gpart incorrectly works, > please make a copy of first 34 blocks before and after deletion and > send them to me. Hi Andrey, You helped me to find the point: Apple maps the starting point of the first partition in the MBR like this: 000001be 00 fe ff ff ee fe ff ff 01 when gpart maps: 000001be: 80 00 02 00 ee ff ff ff 01 it is a 251G drive. a solution would be to inspect the gpt table and if an osx-boot is present to leave the starting point unchanged? i tested it on osx 10.8. Please note than geom mark active the partition when osx zeroes the 1be byte. but with this byte set or unset, osx starts (perhaps non checked at all). Regards Raoul rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 14:55:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA8E0106566B for ; Mon, 1 Oct 2012 14:55:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A4EF78FC17 for ; Mon, 1 Oct 2012 14:55:06 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C17F8B977; Mon, 1 Oct 2012 10:55:05 -0400 (EDT) From: John Baldwin To: Kim Culhan Date: Mon, 1 Oct 2012 09:49:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201210010804.08925.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210010949.08943.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Oct 2012 10:55:06 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: panic possibly on on bridge member removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:55:07 -0000 On Monday, October 01, 2012 9:08:30 am Kim Culhan wrote: > On Mon, Oct 1, 2012 at 8:04 AM, John Baldwin wrote: > > On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote: > >> After a few hours of operation involving tap0 added to the bridge > >> running openvpn > >> and shutting down openvpn which removes tap0 from the bridge, the > >> machine is found to have a panic: > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 1; apic id = 01 > >> fault virtual address = 0x188 > >> fault code = supervisor read data, page not present > >> instruction pointer = 0x20:0xffffffff82a14f96 > >> stack pointer = 0x28:0xffffff8000285670 > >> frame pointer = 0x28:0xffffff80002856b0 > >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> current process = 12 (swi5: fast taskq) > >> [ thread pid 12 tid 100022 ] > >> Stopped at bridge_enqueue+0x86: calll *0x188(%r12) > >> db> bt > >> Tracing pid 12 tid 100022 td 0xfffffe0003aff000 > >> bridge_enqueue() at bridge_enqueue+0x86 > > > > Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'? > > > > -- > > John Baldwin > > (gdb) l *bridge_enqueue+0x86 > No symbol "bridge_enqueue" in current context. > (gdb) Oh, are you using if_bridge.ko as a module? If so, you can try running 'gdb /boot/kernel/if_bridge.ko' instead. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 15:05:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89B10106566B; Mon, 1 Oct 2012 15:05:31 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 23EF58FC08; Mon, 1 Oct 2012 15:05:30 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so7435071vcb.13 for ; Mon, 01 Oct 2012 08:05:30 -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=RJZPosAQ2ysERHg7zJFYNSuDb5mf6defgtnF3h3EFJY=; b=qkFIJalcpJs+CYQtKQbMeMGqHkUgQd0FQ5rsa6dwiKFRLN+TiaeHRiC5z4HhENNhsD viiAjFnPRCxryT+uYc31gV7qDA+KdxJE4bRtDGNfg8+B7Eb7L3Jg2hCeBlFazh4oxUyU KyCNNiC/n8Ea4SLMwmwrcxPaOXDyMVOPFBzmp+11CXOp1kY81M98aLauAjpfzLaaDQA8 P/ScXGacovV2cOAND558BWsQ1z9ZvQHmZd/VXXHVKKLgAKCwJOmKiP8MoHvoyGOwR0Eu YjUXYcX2ChKSP9XwfMNr2uSpk3pvy0/McM/FnKE6UOpK/EeIHQ9F67s4p3M4lhsIevIF XVkQ== MIME-Version: 1.0 Received: by 10.220.40.14 with SMTP id i14mr8435564vce.68.1349103930181; Mon, 01 Oct 2012 08:05:30 -0700 (PDT) Received: by 10.58.226.163 with HTTP; Mon, 1 Oct 2012 08:05:30 -0700 (PDT) In-Reply-To: <201210010949.08943.jhb@freebsd.org> References: <201210010804.08925.jhb@freebsd.org> <201210010949.08943.jhb@freebsd.org> Date: Mon, 1 Oct 2012 11:05:30 -0400 Message-ID: From: Kim Culhan To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: panic possibly on on bridge member removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:05:31 -0000 On Mon, Oct 1, 2012 at 9:49 AM, John Baldwin wrote: > On Monday, October 01, 2012 9:08:30 am Kim Culhan wrote: >> On Mon, Oct 1, 2012 at 8:04 AM, John Baldwin wrote: >> > On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote: >> >> After a few hours of operation involving tap0 added to the bridge >> >> running openvpn >> >> and shutting down openvpn which removes tap0 from the bridge, the >> >> machine is found to have a panic: >> >> >> >> Fatal trap 12: page fault while in kernel mode >> >> cpuid = 1; apic id = 01 >> >> fault virtual address = 0x188 >> >> fault code = supervisor read data, page not present >> >> instruction pointer = 0x20:0xffffffff82a14f96 >> >> stack pointer = 0x28:0xffffff8000285670 >> >> frame pointer = 0x28:0xffffff80002856b0 >> >> code segment = base 0x0, limit 0xfffff, type 0x1b >> >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> >> processor eflags = interrupt enabled, resume, IOPL = 0 >> >> current process = 12 (swi5: fast taskq) >> >> [ thread pid 12 tid 100022 ] >> >> Stopped at bridge_enqueue+0x86: calll *0x188(%r12) >> >> db> bt >> >> Tracing pid 12 tid 100022 td 0xfffffe0003aff000 >> >> bridge_enqueue() at bridge_enqueue+0x86 >> > >> > Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'? >> > >> > -- >> > John Baldwin >> >> (gdb) l *bridge_enqueue+0x86 >> No symbol "bridge_enqueue" in current context. >> (gdb) > > Oh, are you using if_bridge.ko as a module? If so, you can try running 'gdb > /boot/kernel/if_bridge.ko' instead. (gdb) l *bridge_enqueue+0x86 0x2f96 is in bridge_enqueue (/usr/src/sys/modules/if_bridge/../../net/if_bridge.c:1810). 1805 continue; 1806 } 1807 m->m_flags &= ~M_VLANTAG; 1808 } 1809 1810 if ((err = dst_ifp->if_transmit(dst_ifp, m))) { 1811 m_freem(m0); 1812 break; 1813 } 1814 } (gdb) -- -lo, From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 15:11:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C1801065672; Mon, 1 Oct 2012 15:11:37 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 93FC48FC12; Mon, 1 Oct 2012 15:11:36 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm2so3396275wib.1 for ; Mon, 01 Oct 2012 08:11:34 -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=Da9tSUFqpOeKavLTJEsihv98cOdL//ClQUW9DyzZ+NI=; b=vmUwKIANFAfvqbJ1JofF+sNqqK6jG5W+g3NRZ9AkkVxTvcosEuGDHY9ZwYaS4zYZd9 TdV98VuX9eH1V2LiWVGmzVBMa0JH3QYY+idOPod7NQ1oGrPLztMTC7Z3+1OYHq5rLbo1 WRf40nUUg6gCsXq5ExA/WXCikNM5Q857pl2Dowj1mNBPdj3WCTQmAiz/6SofIkV4/RUJ DaPhS0h53pEPLbOzdbN6XdvfwaMZ7F8ZZmLR/pp8T7r2KaYCoyDdjhyRG6RxfRgbbkCt WAKDHjF7rnMBSWKrdXjuv/z0OflTotxAW+Jokhe4FcqG1pm3giAQ5D1ea5op0xwqwgIM icpA== MIME-Version: 1.0 Received: by 10.216.214.209 with SMTP id c59mr7787892wep.214.1349104294638; Mon, 01 Oct 2012 08:11:34 -0700 (PDT) Received: by 10.194.54.104 with HTTP; Mon, 1 Oct 2012 08:11:34 -0700 (PDT) In-Reply-To: <201209071540.43013.jhb@freebsd.org> References: <201209071405.28831.jhb@freebsd.org> <20120907184120.GD33100@deviant.kiev.zoral.com.ua> <201209071540.43013.jhb@freebsd.org> Date: Mon, 1 Oct 2012 17:11:34 +0200 Message-ID: From: Svatopluk Kraus To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: [patch] mmap() MAP_TEXT implementation (to use for shared libraries) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:11:37 -0000 On Fri, Sep 7, 2012 at 9:40 PM, John Baldwin wrote: > On Friday, September 07, 2012 2:41:20 pm Konstantin Belousov wrote: >> > I think these would be rare? There's no good reason for anything to write to >> > a shared library that I can think of. install(1) does an atomic rename to swap >> > in the new libraries already. >> >> After a second thought, I do not like your proposal as well. +x is set for >> shebang scripts, and allowing PROT_EXEC to set VV_TEXT for them means >> that such scripts are subject for write denial. > > Yeah, that's fair. Also, I hunted around to find the description of MAP_TEXT > in Solaris 11. It seems from reading that that MAP_TEXT on Solaris isn't used > to prevent writes ala VV_TEXT. Instead, it is used as a hint that is > apparently used to use superpages for text. > > -- > John Baldwin Hi, I'd like to finish this thread somehow. For security sake, it looks that bounding VV_TEXT with MAP_TEXT is not good idea. Now, I see only two possibilities how to solve the shared libraries issue in general. 1. To have one more permission flag, first for files on which VV_TEXT can be set and second for files on which VV_TEXT may not be set. 2. To activate shared libraries in kernel. The whole situation is following. There are two basic kinds of binaries in system. The first ones only need to be activated, the second ones need to be interpreted by an interpreter which is activated already. While activation is a concern of kernel and should be done in kernel, an interpretation is a concern of an interpreter and as such is done in userland. Unfortunately, even so different in nature, both share x+ permission and can't be distinguished by it. The shared libraries issue is that even they can be activated only, they are interpreted by dynamic linker instead. As VV_TEXT is kernel flag and can be set safely by kernel only, there is no way how to protect them by the flag in this situation. Svata From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 16:41:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2168E106566C; Mon, 1 Oct 2012 16:41:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DFB5E8FC1E; Mon, 1 Oct 2012 16:41:07 +0000 (UTC) Received: by pbbrp8 with SMTP id rp8so9066189pbb.13 for ; Mon, 01 Oct 2012 09:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WR/orYhcTBXfo2IOWLZDvvbFc0bZbzr1H2Ei3UxQZgw=; b=mUwyvD4Dgyn8UuInIuB05yFeqfkrUL31SQBgaNunjcE0edOM2GmQDBJIQLa9q+p0n8 wRuRPeQU0pNUpOO/ZNIFi4qEAFhKzC6rE984DIDKgmbbaOlRUS3INkF5bcn3l5SR/lyx UUuw/kYMk38zDVCXy/lntzloDDyg99JcEwak8B0OJwsLoCCrgWgeEIE5IQl56T5GJFdy zy4imM7mfV2JP1jKW4EyckfDCjceU0VmpeHX7pW/+3nizrCDB5WFz9CsyEnOLRWMR8r+ BioheIUE4ANP1MjanAoMO++nlF1JDNjtnwi/KG+cnED2sh7OkSbfq44wVI5BWKXiK/wJ g90g== MIME-Version: 1.0 Received: by 10.68.197.167 with SMTP id iv7mr42265430pbc.113.1349109667226; Mon, 01 Oct 2012 09:41:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.16.40 with HTTP; Mon, 1 Oct 2012 09:41:07 -0700 (PDT) In-Reply-To: References: <201210010804.08925.jhb@freebsd.org> <201210010949.08943.jhb@freebsd.org> Date: Mon, 1 Oct 2012 09:41:07 -0700 X-Google-Sender-Auth: 0KJG-tGD4G5BuzkyX8o9TX-4pM8 Message-ID: From: Adrian Chadd To: Kim Culhan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: panic possibly on on bridge member removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 16:41:08 -0000 Sounds like dst_ifp is NULL at that point? Adrian From owner-freebsd-current@FreeBSD.ORG Mon Oct 1 18:38:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DBF0106568D; Mon, 1 Oct 2012 18:38:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4258E8FC1A; Mon, 1 Oct 2012 18:38:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9209AB949; Mon, 1 Oct 2012 14:38:07 -0400 (EDT) From: John Baldwin To: Kim Culhan Date: Mon, 1 Oct 2012 14:29:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201210010949.08943.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210011429.31513.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Oct 2012 14:38:07 -0400 (EDT) Cc: freebsd-current@freebsd.org, Gleb Smirnoff Subject: Re: panic possibly on on bridge member removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 18:38:08 -0000 On Monday, October 01, 2012 11:05:30 am Kim Culhan wrote: > On Mon, Oct 1, 2012 at 9:49 AM, John Baldwin wrote: > > On Monday, October 01, 2012 9:08:30 am Kim Culhan wrote: > >> On Mon, Oct 1, 2012 at 8:04 AM, John Baldwin wrote: > >> > On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote: > >> >> After a few hours of operation involving tap0 added to the bridge > >> >> running openvpn > >> >> and shutting down openvpn which removes tap0 from the bridge, the > >> >> machine is found to have a panic: > >> >> > >> >> Fatal trap 12: page fault while in kernel mode > >> >> cpuid = 1; apic id = 01 > >> >> fault virtual address = 0x188 > >> >> fault code = supervisor read data, page not present > >> >> instruction pointer = 0x20:0xffffffff82a14f96 > >> >> stack pointer = 0x28:0xffffff8000285670 > >> >> frame pointer = 0x28:0xffffff80002856b0 > >> >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> >> current process = 12 (swi5: fast taskq) > >> >> [ thread pid 12 tid 100022 ] > >> >> Stopped at bridge_enqueue+0x86: calll *0x188(%r12) > >> >> db> bt > >> >> Tracing pid 12 tid 100022 td 0xfffffe0003aff000 > >> >> bridge_enqueue() at bridge_enqueue+0x86 > >> > > >> > Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'? > >> > > >> > -- > >> > John Baldwin > >> > >> (gdb) l *bridge_enqueue+0x86 > >> No symbol "bridge_enqueue" in current context. > >> (gdb) > > > > Oh, are you using if_bridge.ko as a module? If so, you can try running 'gdb > > /boot/kernel/if_bridge.ko' instead. > > (gdb) l *bridge_enqueue+0x86 > 0x2f96 is in bridge_enqueue > (/usr/src/sys/modules/if_bridge/../../net/if_bridge.c:1810). > 1805 continue; > 1806 } > 1807 m->m_flags &= ~M_VLANTAG; > 1808 } > 1809 > 1810 if ((err = dst_ifp->if_transmit(dst_ifp, m))) { > 1811 m_freem(m0); > 1812 break; > 1813 } > 1814 } > (gdb) Hmm, try this perhaps. I think there is a race where the departing bridge member can be destroyed before the bridge code is finishing using it. The way the bridge driver is supposed to prevent that is by ensuring that bridge_ifdetach() doesn't return until all other references to the detaching interface are known to be released in the bridge code. I think what is happening for you is that a bridge_enqueue() performed outside the lock is running into dst_ifp that has been if_free()'d and had its if_transmit set to zero when it was reallocated for something else. Index: if_bridge.c =================================================================== --- if_bridge.c (revision 241096) +++ if_bridge.c (working copy) @@ -1833,6 +1833,7 @@ static void bridge_dummynet(struct mbuf *m, struct ifnet *ifp) { struct bridge_softc *sc; + int error = 0; sc = ifp->if_bridge; @@ -1846,18 +1847,30 @@ bridge_dummynet(struct mbuf *m, struct ifnet *ifp) return; } + BRIDGE_LOCK(sc); + BRIDGE_LOCK2REF(sc, error); + if (error) { + m_freem(m); + return; + } + if (PFIL_HOOKED(&V_inet_pfil_hook) #ifdef INET6 || PFIL_HOOKED(&V_inet6_pfil_hook) #endif ) { - if (bridge_pfil(&m, sc->sc_ifp, ifp, PFIL_OUT) != 0) + if (bridge_pfil(&m, sc->sc_ifp, ifp, PFIL_OUT) != 0) { + BRIDGE_UNREF(sc); return; - if (m == NULL) + } + if (m == NULL) { + BRIDGE_UNREF(sc); return; + } } bridge_enqueue(sc, ifp, m); + BRIDGE_UNREF(sc); } /* @@ -1971,8 +1984,13 @@ sendunicast: return (0); } - BRIDGE_UNLOCK(sc); + BRIDGE_LOCK2REF(sc, error); + if (error) { + m_freem(m); + return (0); + } bridge_enqueue(sc, dst_if, m); + BRIDGE_UNREF(sc); return (0); } @@ -2000,8 +2018,13 @@ bridge_transmit(struct ifnet *ifp, struct mbuf *m) eh = mtod(m, struct ether_header *); dst_if = bridge_rtlookup(sc, eh->ether_dhost, 1); - BRIDGE_UNLOCK(sc); - error = bridge_enqueue(sc, dst_if, m); + BRIDGE_LOCK2REF(sc, error); + if (error) + m_freem(m); + else { + error = bridge_enqueue(sc, dst_if, m); + BRIDGE_UNREF(sc); + } } else bridge_broadcast(sc, ifp, m, 0); @@ -2145,20 +2168,29 @@ bridge_forward(struct bridge_softc *sc, struct bri dbif->bif_stp.bp_state == BSTP_IFSTATE_DISCARDING) goto drop; - BRIDGE_UNLOCK(sc); + BRIDGE_LOCK2REF(sc, error); + if (error) { + m_freem(m); + return; + } if (PFIL_HOOKED(&V_inet_pfil_hook) #ifdef INET6 || PFIL_HOOKED(&V_inet6_pfil_hook) #endif ) { - if (bridge_pfil(&m, ifp, dst_if, PFIL_OUT) != 0) + if (bridge_pfil(&m, ifp, dst_if, PFIL_OUT) != 0) { + BRIDGE_UNREF(sc); return; - if (m == NULL) + } + if (m == NULL) { + BRIDGE_UNREF(sc); return; + } } bridge_enqueue(sc, dst_if, m); + BRIDGE_UNREF(sc); return; drop: -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 2 06:59:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A27D106566B; Tue, 2 Oct 2012 06:59:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 61B948FC0C; Tue, 2 Oct 2012 06:59:32 +0000 (UTC) Received: by padbi1 with SMTP id bi1so5639394pad.13 for ; Mon, 01 Oct 2012 23:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Ux9xK3D3Ywh43kb6aX4dIxDNhYII9fk5ncjeLhNWjNU=; b=WAomFShkD4WbHyTBaaHduWYDhaHMMpJVemJN9vBQdMFzRoFaEK8w10NRCF4D81oT23 UQn/IbsYuzejTtBzoZxnyKLRj9uOBywG5X43JQiezYcgjRrvMdLqwx3a4d7KunW6kbXO rRW7w3oEgTYkT6a9SBnDDR1rYg931ekSzlupW7IYZ+O5d21bPG/BAFvOx8VuHpWZGCFy +ySC826kvvQAZMCy+wzZYjz4TSFNSuie7qOhV7WxrfvUagNFOm7mn23bv02WVWPpR59E jpkQ+H61cNcrgRMEEzwZ168rlmwnFW5EWxV5yQPvsAk5XUMpeN6fE2KGM7h71qGrJtd7 OJmQ== Received: by 10.68.225.3 with SMTP id rg3mr2040844pbc.27.1349161172034; Mon, 01 Oct 2012 23:59:32 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id gv1sm473149pbc.38.2012.10.01.23.59.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 23:59:31 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 02 Oct 2012 15:59:18 -0700 From: YongHyeon PYUN Date: Tue, 2 Oct 2012 15:59:18 -0700 To: sbruno@freebsd.org Message-ID: <20121002225918.GA15610@michelle.cdnetworks.com> References: <20120914212716.GB7612@michelle.cdnetworks.com> <1348073071.5775.4.camel@powernoodle.corp.yahoo.com> <1348790974.10543.16.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1348790974.10543.16.camel@powernoodle.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-current@freebsd.org" Subject: Re: Call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 06:59:32 -0000 On Thu, Sep 27, 2012 at 05:09:34PM -0700, Sean Bruno wrote: > On Wed, 2012-09-19 at 09:44 -0700, Sean Bruno wrote: > > On Fri, 2012-09-14 at 14:27 -0700, YongHyeon PYUN wrote: > > > All, > > > > > > There were lots of reports that stock bge(4) does not work on Dell > > > Rx20/HP DL 360 G8. With the help of Broadcom and BCM5719/BCM5720 > > > users I managed to address the issue but I had to touch very > > > sensitive part of driver. Before committing the change to tree I'd > > > like to know whether this change introduces regressions on old > > > bge(4) controllers. If you're bge(4) user, please try latest WIP > > > version at the following URL and let me know how it goes on your > > > box. I'm especially interested in whether there is any ASF/IPMI > > > regression on BCM570x/571x. > > > > > > http://people.freebsd.org/~yongari/bge/if_bge.c > > > http://people.freebsd.org/~yongari/bge/if_bgereg.h > > > http://people.freebsd.org/~yongari/bge/brgphy.c > > > > > We're starting to gather data and have a couple of machines (pciconf, > ifconfig, dmesg) here that may provide some insights. Everything seems > to be working at a cursory level. > > http://people.freebsd.org/~sbruno/new_bge/ Thanks for testing! Sean, do you have a box with BCM5703/5704/5714/5715 controller? If the answer is yes, would you give it spin on the box? Due to the reset sequence changes I'd like to know whether there are any regressions on these controllers. The reset sequence change will also affect BCM5906/5906M controller. I guess bge(4) didn't completely reset BCM5906 such that it may have resulted in RX CPU handing under device resume. The WIP version wouldn't completely solve resume issue but it would make one step forward to right direction. > > We have seen 2 instances of one or more of the HP machines failing and > dropping off the network. however, we don't have specifics yet. > > Sean From owner-freebsd-current@FreeBSD.ORG Tue Oct 2 12:34:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F39D5106566C; Tue, 2 Oct 2012 12:34:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C268F8FC12; Tue, 2 Oct 2012 12:34:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q92CY4e6079575; Tue, 2 Oct 2012 08:34:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q92CY4Xa079552; Tue, 2 Oct 2012 12:34:04 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 2 Oct 2012 12:34:04 GMT Message-Id: <201210021234.q92CY4Xa079552@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 12:34:12 -0000 TB --- 2012-10-02 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-10-02 06:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-02 06:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-10-02 06:40:00 - cleaning the object tree TB --- 2012-10-02 06:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-10-02 06:40:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-10-02 06:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-10-02 06:43:19 - /usr/local/bin/svn update /src TB --- 2012-10-02 06:43:33 - At svn revision 241122 TB --- 2012-10-02 06:43:34 - building world TB --- 2012-10-02 06:43:34 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 06:43:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 06:43:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 06:43:34 - SRCCONF=/dev/null TB --- 2012-10-02 06:43:34 - TARGET=i386 TB --- 2012-10-02 06:43:34 - TARGET_ARCH=i386 TB --- 2012-10-02 06:43:34 - TZ=UTC TB --- 2012-10-02 06:43:34 - __MAKE_CONF=/dev/null TB --- 2012-10-02 06:43:34 - cd /src TB --- 2012-10-02 06:43:34 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 2 06:43:36 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Oct 2 09:20:20 UTC 2012 TB --- 2012-10-02 09:20:20 - generating LINT kernel config TB --- 2012-10-02 09:20:20 - cd /src/sys/i386/conf TB --- 2012-10-02 09:20:20 - /usr/bin/make -B LINT TB --- 2012-10-02 09:20:20 - cd /src/sys/i386/conf TB --- 2012-10-02 09:20:20 - /usr/sbin/config -m LINT TB --- 2012-10-02 09:20:20 - building LINT kernel TB --- 2012-10-02 09:20:20 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 09:20:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 09:20:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 09:20:20 - SRCCONF=/dev/null TB --- 2012-10-02 09:20:20 - TARGET=i386 TB --- 2012-10-02 09:20:20 - TARGET_ARCH=i386 TB --- 2012-10-02 09:20:20 - TZ=UTC TB --- 2012-10-02 09:20:20 - __MAKE_CONF=/dev/null TB --- 2012-10-02 09:20:20 - cd /src TB --- 2012-10-02 09:20:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 2 09:20:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Oct 2 09:55:03 UTC 2012 TB --- 2012-10-02 09:55:03 - cd /src/sys/i386/conf TB --- 2012-10-02 09:55:03 - /usr/sbin/config -m LINT-NOINET TB --- 2012-10-02 09:55:03 - building LINT-NOINET kernel TB --- 2012-10-02 09:55:03 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 09:55:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 09:55:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 09:55:03 - SRCCONF=/dev/null TB --- 2012-10-02 09:55:03 - TARGET=i386 TB --- 2012-10-02 09:55:03 - TARGET_ARCH=i386 TB --- 2012-10-02 09:55:03 - TZ=UTC TB --- 2012-10-02 09:55:03 - __MAKE_CONF=/dev/null TB --- 2012-10-02 09:55:03 - cd /src TB --- 2012-10-02 09:55:03 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Oct 2 09:55:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Tue Oct 2 10:27:53 UTC 2012 TB --- 2012-10-02 10:27:53 - cd /src/sys/i386/conf TB --- 2012-10-02 10:27:53 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-10-02 10:27:53 - building LINT-NOINET6 kernel TB --- 2012-10-02 10:27:53 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 10:27:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 10:27:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 10:27:53 - SRCCONF=/dev/null TB --- 2012-10-02 10:27:53 - TARGET=i386 TB --- 2012-10-02 10:27:53 - TARGET_ARCH=i386 TB --- 2012-10-02 10:27:53 - TZ=UTC TB --- 2012-10-02 10:27:53 - __MAKE_CONF=/dev/null TB --- 2012-10-02 10:27:53 - cd /src TB --- 2012-10-02 10:27:53 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Oct 2 10:27:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Tue Oct 2 10:59:56 UTC 2012 TB --- 2012-10-02 10:59:56 - cd /src/sys/i386/conf TB --- 2012-10-02 10:59:56 - /usr/sbin/config -m LINT-NOIP TB --- 2012-10-02 10:59:56 - building LINT-NOIP kernel TB --- 2012-10-02 10:59:56 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 10:59:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 10:59:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 10:59:56 - SRCCONF=/dev/null TB --- 2012-10-02 10:59:56 - TARGET=i386 TB --- 2012-10-02 10:59:56 - TARGET_ARCH=i386 TB --- 2012-10-02 10:59:56 - TZ=UTC TB --- 2012-10-02 10:59:56 - __MAKE_CONF=/dev/null TB --- 2012-10-02 10:59:56 - cd /src TB --- 2012-10-02 10:59:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Tue Oct 2 10:59:56 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Tue Oct 2 11:29:36 UTC 2012 TB --- 2012-10-02 11:29:36 - cd /src/sys/i386/conf TB --- 2012-10-02 11:29:36 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-10-02 11:29:36 - building LINT-VIMAGE kernel TB --- 2012-10-02 11:29:36 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 11:29:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 11:29:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 11:29:36 - SRCCONF=/dev/null TB --- 2012-10-02 11:29:36 - TARGET=i386 TB --- 2012-10-02 11:29:36 - TARGET_ARCH=i386 TB --- 2012-10-02 11:29:36 - TZ=UTC TB --- 2012-10-02 11:29:36 - __MAKE_CONF=/dev/null TB --- 2012-10-02 11:29:36 - cd /src TB --- 2012-10-02 11:29:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Tue Oct 2 11:29:37 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Tue Oct 2 12:02:06 UTC 2012 TB --- 2012-10-02 12:02:06 - cd /src/sys/i386/conf TB --- 2012-10-02 12:02:06 - /usr/sbin/config -m GENERIC TB --- 2012-10-02 12:02:06 - building GENERIC kernel TB --- 2012-10-02 12:02:06 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 12:02:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 12:02:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 12:02:06 - SRCCONF=/dev/null TB --- 2012-10-02 12:02:06 - TARGET=i386 TB --- 2012-10-02 12:02:06 - TARGET_ARCH=i386 TB --- 2012-10-02 12:02:06 - TZ=UTC TB --- 2012-10-02 12:02:06 - __MAKE_CONF=/dev/null TB --- 2012-10-02 12:02:06 - cd /src TB --- 2012-10-02 12:02:06 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Oct 2 12:02:06 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Oct 2 12:31:27 UTC 2012 TB --- 2012-10-02 12:31:27 - cd /src/sys/i386/conf TB --- 2012-10-02 12:31:27 - /usr/sbin/config -m PAE TB --- 2012-10-02 12:31:27 - building PAE kernel TB --- 2012-10-02 12:31:27 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 12:31:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 12:31:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 12:31:27 - SRCCONF=/dev/null TB --- 2012-10-02 12:31:27 - TARGET=i386 TB --- 2012-10-02 12:31:27 - TARGET_ARCH=i386 TB --- 2012-10-02 12:31:27 - TZ=UTC TB --- 2012-10-02 12:31:27 - __MAKE_CONF=/dev/null TB --- 2012-10-02 12:31:27 - cd /src TB --- 2012-10-02 12:31:27 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Tue Oct 2 12:31:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ctfconvert -L VERSION -g mps_mapping.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mps/mps_pci.c ctfconvert -L VERSION -g mps_pci.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mps/mps_sas.c cc1: warnings being treated as errors /src/sys/dev/mps/mps_sas.c: In function 'mpssas_send_smpcmd': /src/sys/dev/mps/mps_sas.c:2733: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] /src/sys/dev/mps/mps_sas.c:2741: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] *** Error code 1 Stop in /obj/i386.i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-02 12:34:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-02 12:34:04 - ERROR: failed to build PAE kernel TB --- 2012-10-02 12:34:04 - 15942.98 user 2227.31 system 21243.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Oct 2 18:10:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F11281065672 for ; Tue, 2 Oct 2012 18:10:43 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 92D758FC0C for ; Tue, 2 Oct 2012 18:10:43 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q92IANQ9050595; Tue, 2 Oct 2012 11:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1349201424; bh=3/cDXHsv1yV8XzIP0TNEnNlJTPyx8hqJpUnPqnAQllc=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Date:Message-ID:Mime-Version:Content-Transfer-Encoding; b=bV7TTVJ2t/4HshcwNvBXl2XI8FmEuB5aat+ArxNjn3nMSySTlGWPALADaa9kBQRz1 Iq8n/5U3eh145v4IHIqNDoeBMPD0qSCAvEEHUtB0F98Z3uA+nR/8bnaqQRDkMSXhs7 W9LdLOHn/h8l2Nuv59BZnjHj1vJI2BB0R0GcarFY= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20121002225918.GA15610@michelle.cdnetworks.com> References: <20120914212716.GB7612@michelle.cdnetworks.com> <1348073071.5775.4.camel@powernoodle.corp.yahoo.com> <1348790974.10543.16.camel@powernoodle.corp.yahoo.com> <20121002225918.GA15610@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 02 Oct 2012 11:10:23 -0700 Message-ID: <1349201423.4246.5.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 201424000 Cc: "freebsd-current@freebsd.org" Subject: Re: Call for bge(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "sbruno@freebsd.org" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:10:44 -0000 On Tue, 2012-10-02 at 15:59 -0700, YongHyeon PYUN wrote: > Sean, do you have a box with BCM5703/5704/5714/5715 controller? I have a 5704C in an HP DL380G4 here that seems to be working. I'll have to poke around further to see what else I have lying around. bge0: mem 0xfdef0000-0xfdefffff irq 25 at device 1.0 on pci3 bge0: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X 133 MHz miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:0f:20:f6:e6:23 bge1: mem 0xfdee0000-0xfdeeffff irq 26 at device 1.1 on pci3 bge1: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X 133 MHz miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:0f:20:f6:e6:22 From owner-freebsd-current@FreeBSD.ORG Tue Oct 2 21:47:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 322191065688; Tue, 2 Oct 2012 21:47:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 023F88FC22; Tue, 2 Oct 2012 21:47: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 q92LlE91005243; Tue, 2 Oct 2012 17:47:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q92LlETf005241; Tue, 2 Oct 2012 21:47:14 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 2 Oct 2012 21:47:14 GMT Message-Id: <201210022147.q92LlETf005241@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 21:47:15 -0000 TB --- 2012-10-02 16:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-10-02 16:00:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-02 16:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-10-02 16:00:00 - cleaning the object tree TB --- 2012-10-02 16:06:21 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-10-02 16:06:21 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-10-02 16:06:21 - /usr/local/bin/svn cleanup /src TB --- 2012-10-02 16:07:00 - /usr/local/bin/svn update /src TB --- 2012-10-02 16:07:07 - At svn revision 241134 TB --- 2012-10-02 16:07:08 - building world TB --- 2012-10-02 16:07:08 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 16:07:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 16:07:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 16:07:08 - SRCCONF=/dev/null TB --- 2012-10-02 16:07:08 - TARGET=i386 TB --- 2012-10-02 16:07:08 - TARGET_ARCH=i386 TB --- 2012-10-02 16:07:08 - TZ=UTC TB --- 2012-10-02 16:07:08 - __MAKE_CONF=/dev/null TB --- 2012-10-02 16:07:08 - cd /src TB --- 2012-10-02 16:07:08 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 2 16:07:09 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Oct 2 18:34:26 UTC 2012 TB --- 2012-10-02 18:34:26 - generating LINT kernel config TB --- 2012-10-02 18:34:26 - cd /src/sys/i386/conf TB --- 2012-10-02 18:34:26 - /usr/bin/make -B LINT TB --- 2012-10-02 18:34:26 - cd /src/sys/i386/conf TB --- 2012-10-02 18:34:26 - /usr/sbin/config -m LINT TB --- 2012-10-02 18:34:26 - building LINT kernel TB --- 2012-10-02 18:34:26 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 18:34:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 18:34:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 18:34:26 - SRCCONF=/dev/null TB --- 2012-10-02 18:34:26 - TARGET=i386 TB --- 2012-10-02 18:34:26 - TARGET_ARCH=i386 TB --- 2012-10-02 18:34:26 - TZ=UTC TB --- 2012-10-02 18:34:26 - __MAKE_CONF=/dev/null TB --- 2012-10-02 18:34:26 - cd /src TB --- 2012-10-02 18:34:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 2 18:34:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Oct 2 19:08:48 UTC 2012 TB --- 2012-10-02 19:08:48 - cd /src/sys/i386/conf TB --- 2012-10-02 19:08:48 - /usr/sbin/config -m LINT-NOINET TB --- 2012-10-02 19:08:48 - building LINT-NOINET kernel TB --- 2012-10-02 19:08:48 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 19:08:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 19:08:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 19:08:48 - SRCCONF=/dev/null TB --- 2012-10-02 19:08:48 - TARGET=i386 TB --- 2012-10-02 19:08:48 - TARGET_ARCH=i386 TB --- 2012-10-02 19:08:48 - TZ=UTC TB --- 2012-10-02 19:08:48 - __MAKE_CONF=/dev/null TB --- 2012-10-02 19:08:48 - cd /src TB --- 2012-10-02 19:08:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Oct 2 19:08:48 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Tue Oct 2 19:40:57 UTC 2012 TB --- 2012-10-02 19:40:57 - cd /src/sys/i386/conf TB --- 2012-10-02 19:40:57 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-10-02 19:40:57 - building LINT-NOINET6 kernel TB --- 2012-10-02 19:40:57 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 19:40:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 19:40:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 19:40:57 - SRCCONF=/dev/null TB --- 2012-10-02 19:40:57 - TARGET=i386 TB --- 2012-10-02 19:40:57 - TARGET_ARCH=i386 TB --- 2012-10-02 19:40:57 - TZ=UTC TB --- 2012-10-02 19:40:57 - __MAKE_CONF=/dev/null TB --- 2012-10-02 19:40:57 - cd /src TB --- 2012-10-02 19:40:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Oct 2 19:40:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Tue Oct 2 20:13:00 UTC 2012 TB --- 2012-10-02 20:13:00 - cd /src/sys/i386/conf TB --- 2012-10-02 20:13:00 - /usr/sbin/config -m LINT-NOIP TB --- 2012-10-02 20:13:00 - building LINT-NOIP kernel TB --- 2012-10-02 20:13:00 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 20:13:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 20:13:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 20:13:00 - SRCCONF=/dev/null TB --- 2012-10-02 20:13:00 - TARGET=i386 TB --- 2012-10-02 20:13:00 - TARGET_ARCH=i386 TB --- 2012-10-02 20:13:00 - TZ=UTC TB --- 2012-10-02 20:13:00 - __MAKE_CONF=/dev/null TB --- 2012-10-02 20:13:00 - cd /src TB --- 2012-10-02 20:13:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Tue Oct 2 20:13:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Tue Oct 2 20:42:47 UTC 2012 TB --- 2012-10-02 20:42:47 - cd /src/sys/i386/conf TB --- 2012-10-02 20:42:47 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-10-02 20:42:47 - building LINT-VIMAGE kernel TB --- 2012-10-02 20:42:47 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 20:42:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 20:42:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 20:42:47 - SRCCONF=/dev/null TB --- 2012-10-02 20:42:47 - TARGET=i386 TB --- 2012-10-02 20:42:47 - TARGET_ARCH=i386 TB --- 2012-10-02 20:42:47 - TZ=UTC TB --- 2012-10-02 20:42:47 - __MAKE_CONF=/dev/null TB --- 2012-10-02 20:42:47 - cd /src TB --- 2012-10-02 20:42:47 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Tue Oct 2 20:42:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Tue Oct 2 21:15:20 UTC 2012 TB --- 2012-10-02 21:15:20 - cd /src/sys/i386/conf TB --- 2012-10-02 21:15:20 - /usr/sbin/config -m GENERIC TB --- 2012-10-02 21:15:20 - building GENERIC kernel TB --- 2012-10-02 21:15:20 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 21:15:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 21:15:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 21:15:20 - SRCCONF=/dev/null TB --- 2012-10-02 21:15:20 - TARGET=i386 TB --- 2012-10-02 21:15:20 - TARGET_ARCH=i386 TB --- 2012-10-02 21:15:20 - TZ=UTC TB --- 2012-10-02 21:15:20 - __MAKE_CONF=/dev/null TB --- 2012-10-02 21:15:20 - cd /src TB --- 2012-10-02 21:15:20 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Oct 2 21:15:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Oct 2 21:44:40 UTC 2012 TB --- 2012-10-02 21:44:40 - cd /src/sys/i386/conf TB --- 2012-10-02 21:44:40 - /usr/sbin/config -m PAE TB --- 2012-10-02 21:44:40 - building PAE kernel TB --- 2012-10-02 21:44:40 - CROSS_BUILD_TESTING=YES TB --- 2012-10-02 21:44:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-02 21:44:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-02 21:44:40 - SRCCONF=/dev/null TB --- 2012-10-02 21:44:40 - TARGET=i386 TB --- 2012-10-02 21:44:40 - TARGET_ARCH=i386 TB --- 2012-10-02 21:44:40 - TZ=UTC TB --- 2012-10-02 21:44:40 - __MAKE_CONF=/dev/null TB --- 2012-10-02 21:44:40 - cd /src TB --- 2012-10-02 21:44:40 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Tue Oct 2 21:44:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ctfconvert -L VERSION -g mps_mapping.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mps/mps_pci.c ctfconvert -L VERSION -g mps_pci.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mps/mps_sas.c cc1: warnings being treated as errors /src/sys/dev/mps/mps_sas.c: In function 'mpssas_send_smpcmd': /src/sys/dev/mps/mps_sas.c:2733: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] /src/sys/dev/mps/mps_sas.c:2741: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] *** Error code 1 Stop in /obj/i386.i386/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-02 21:47:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-02 21:47:13 - ERROR: failed to build PAE kernel TB --- 2012-10-02 21:47:13 - 15941.45 user 2230.59 system 20833.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 02:36:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F9F106566B; Wed, 3 Oct 2012 02:36:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 60C358FC08; Wed, 3 Oct 2012 02:36:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q932aJoo029313; Tue, 2 Oct 2012 22:36:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q932aJdC029312; Wed, 3 Oct 2012 02:36:19 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 3 Oct 2012 02:36:19 GMT Message-Id: <201210030236.q932aJdC029312@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 02:36:21 -0000 TB --- 2012-10-03 01:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-10-03 01:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-03 01:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-10-03 01:10:00 - cleaning the object tree TB --- 2012-10-03 01:10:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-10-03 01:10:00 - cd /tinderbox/HEAD/arm/arm TB --- 2012-10-03 01:10:00 - /usr/local/bin/svn cleanup /src TB --- 2012-10-03 01:13:31 - /usr/local/bin/svn update /src TB --- 2012-10-03 01:13:58 - At svn revision 241147 TB --- 2012-10-03 01:13:59 - building world TB --- 2012-10-03 01:13:59 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 01:13:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 01:13:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 01:13:59 - SRCCONF=/dev/null TB --- 2012-10-03 01:13:59 - TARGET=arm TB --- 2012-10-03 01:13:59 - TARGET_ARCH=arm TB --- 2012-10-03 01:13:59 - TZ=UTC TB --- 2012-10-03 01:13:59 - __MAKE_CONF=/dev/null TB --- 2012-10-03 01:13:59 - cd /src TB --- 2012-10-03 01:13:59 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 3 01:13:59 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Oct 3 02:13:55 UTC 2012 TB --- 2012-10-03 02:13:55 - cd /src/sys/arm/conf TB --- 2012-10-03 02:13:55 - /usr/sbin/config -m AC100 TB --- 2012-10-03 02:13:55 - skipping AC100 kernel TB --- 2012-10-03 02:13:55 - cd /src/sys/arm/conf TB --- 2012-10-03 02:13:55 - /usr/sbin/config -m ARMADAXP TB --- 2012-10-03 02:13:55 - skipping ARMADAXP kernel TB --- 2012-10-03 02:13:55 - cd /src/sys/arm/conf TB --- 2012-10-03 02:13:55 - /usr/sbin/config -m ATMEL TB --- 2012-10-03 02:13:55 - building ATMEL kernel TB --- 2012-10-03 02:13:55 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 02:13:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 02:13:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 02:13:55 - SRCCONF=/dev/null TB --- 2012-10-03 02:13:55 - TARGET=arm TB --- 2012-10-03 02:13:55 - TARGET_ARCH=arm TB --- 2012-10-03 02:13:55 - TZ=UTC TB --- 2012-10-03 02:13:55 - __MAKE_CONF=/dev/null TB --- 2012-10-03 02:13:55 - cd /src TB --- 2012-10-03 02:13:55 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Wed Oct 3 02:13:56 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Wed Oct 3 02:17:30 UTC 2012 TB --- 2012-10-03 02:17:30 - cd /src/sys/arm/conf TB --- 2012-10-03 02:17:30 - /usr/sbin/config -m AVILA TB --- 2012-10-03 02:17:30 - skipping AVILA kernel TB --- 2012-10-03 02:17:30 - cd /src/sys/arm/conf TB --- 2012-10-03 02:17:30 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-10-03 02:17:30 - skipping BEAGLEBONE kernel TB --- 2012-10-03 02:17:30 - cd /src/sys/arm/conf TB --- 2012-10-03 02:17:30 - /usr/sbin/config -m BWCT TB --- 2012-10-03 02:17:30 - building BWCT kernel TB --- 2012-10-03 02:17:30 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 02:17:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 02:17:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 02:17:30 - SRCCONF=/dev/null TB --- 2012-10-03 02:17:30 - TARGET=arm TB --- 2012-10-03 02:17:30 - TARGET_ARCH=arm TB --- 2012-10-03 02:17:30 - TZ=UTC TB --- 2012-10-03 02:17:30 - __MAKE_CONF=/dev/null TB --- 2012-10-03 02:17:30 - cd /src TB --- 2012-10-03 02:17:30 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Wed Oct 3 02:17:30 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Wed Oct 3 02:19:40 UTC 2012 TB --- 2012-10-03 02:19:40 - cd /src/sys/arm/conf TB --- 2012-10-03 02:19:40 - /usr/sbin/config -m CAMBRIA TB --- 2012-10-03 02:19:40 - skipping CAMBRIA kernel TB --- 2012-10-03 02:19:40 - cd /src/sys/arm/conf TB --- 2012-10-03 02:19:40 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-10-03 02:19:40 - building CNS11XXNAS kernel TB --- 2012-10-03 02:19:40 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 02:19:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 02:19:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 02:19:40 - SRCCONF=/dev/null TB --- 2012-10-03 02:19:40 - TARGET=arm TB --- 2012-10-03 02:19:40 - TARGET_ARCH=arm TB --- 2012-10-03 02:19:40 - TZ=UTC TB --- 2012-10-03 02:19:40 - __MAKE_CONF=/dev/null TB --- 2012-10-03 02:19:40 - cd /src TB --- 2012-10-03 02:19:40 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Wed Oct 3 02:19:41 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Wed Oct 3 02:22:07 UTC 2012 TB --- 2012-10-03 02:22:07 - cd /src/sys/arm/conf TB --- 2012-10-03 02:22:07 - /usr/sbin/config -m CRB TB --- 2012-10-03 02:22:07 - skipping CRB kernel TB --- 2012-10-03 02:22:07 - cd /src/sys/arm/conf TB --- 2012-10-03 02:22:07 - /usr/sbin/config -m DB-78XXX TB --- 2012-10-03 02:22:07 - building DB-78XXX kernel TB --- 2012-10-03 02:22:07 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 02:22:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 02:22:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 02:22:07 - SRCCONF=/dev/null TB --- 2012-10-03 02:22:07 - TARGET=arm TB --- 2012-10-03 02:22:07 - TARGET_ARCH=arm TB --- 2012-10-03 02:22:07 - TZ=UTC TB --- 2012-10-03 02:22:07 - __MAKE_CONF=/dev/null TB --- 2012-10-03 02:22:07 - cd /src TB --- 2012-10-03 02:22:07 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Wed Oct 3 02:22:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Wed Oct 3 02:24:52 UTC 2012 TB --- 2012-10-03 02:24:52 - cd /src/sys/arm/conf TB --- 2012-10-03 02:24:52 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-10-03 02:24:52 - building DB-88F5XXX kernel TB --- 2012-10-03 02:24:52 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 02:24:52 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 02:24:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 02:24:52 - SRCCONF=/dev/null TB --- 2012-10-03 02:24:52 - TARGET=arm TB --- 2012-10-03 02:24:52 - TARGET_ARCH=arm TB --- 2012-10-03 02:24:52 - TZ=UTC TB --- 2012-10-03 02:24:52 - __MAKE_CONF=/dev/null TB --- 2012-10-03 02:24:52 - cd /src TB --- 2012-10-03 02:24:52 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Wed Oct 3 02:24:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Wed Oct 3 02:27:36 UTC 2012 TB --- 2012-10-03 02:27:36 - cd /src/sys/arm/conf TB --- 2012-10-03 02:27:36 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-10-03 02:27:36 - building DB-88F6XXX kernel TB --- 2012-10-03 02:27:36 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 02:27:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 02:27:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 02:27:36 - SRCCONF=/dev/null TB --- 2012-10-03 02:27:36 - TARGET=arm TB --- 2012-10-03 02:27:36 - TARGET_ARCH=arm TB --- 2012-10-03 02:27:36 - TZ=UTC TB --- 2012-10-03 02:27:36 - __MAKE_CONF=/dev/null TB --- 2012-10-03 02:27:36 - cd /src TB --- 2012-10-03 02:27:36 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Wed Oct 3 02:27:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Wed Oct 3 02:30:32 UTC 2012 TB --- 2012-10-03 02:30:32 - cd /src/sys/arm/conf TB --- 2012-10-03 02:30:32 - /usr/sbin/config -m DOCKSTAR TB --- 2012-10-03 02:30:32 - building DOCKSTAR kernel TB --- 2012-10-03 02:30:32 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 02:30:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 02:30:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 02:30:32 - SRCCONF=/dev/null TB --- 2012-10-03 02:30:32 - TARGET=arm TB --- 2012-10-03 02:30:32 - TARGET_ARCH=arm TB --- 2012-10-03 02:30:32 - TZ=UTC TB --- 2012-10-03 02:30:32 - __MAKE_CONF=/dev/null TB --- 2012-10-03 02:30:32 - cd /src TB --- 2012-10-03 02:30:32 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Wed Oct 3 02:30:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Wed Oct 3 02:33:09 UTC 2012 TB --- 2012-10-03 02:33:09 - cd /src/sys/arm/conf TB --- 2012-10-03 02:33:09 - /usr/sbin/config -m EA3250 TB --- 2012-10-03 02:33:09 - building EA3250 kernel TB --- 2012-10-03 02:33:09 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 02:33:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 02:33:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 02:33:09 - SRCCONF=/dev/null TB --- 2012-10-03 02:33:09 - TARGET=arm TB --- 2012-10-03 02:33:09 - TARGET_ARCH=arm TB --- 2012-10-03 02:33:09 - TZ=UTC TB --- 2012-10-03 02:33:09 - __MAKE_CONF=/dev/null TB --- 2012-10-03 02:33:09 - cd /src TB --- 2012-10-03 02:33:09 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Wed Oct 3 02:33:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Wed Oct 3 02:35:49 UTC 2012 TB --- 2012-10-03 02:35:49 - cd /src/sys/arm/conf TB --- 2012-10-03 02:35:49 - /usr/sbin/config -m EB9200 TB --- 2012-10-03 02:35:49 - building EB9200 kernel TB --- 2012-10-03 02:35:49 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 02:35:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 02:35:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 02:35:49 - SRCCONF=/dev/null TB --- 2012-10-03 02:35:49 - TARGET=arm TB --- 2012-10-03 02:35:49 - TARGET_ARCH=arm TB --- 2012-10-03 02:35:49 - TZ=UTC TB --- 2012-10-03 02:35:49 - __MAKE_CONF=/dev/null TB --- 2012-10-03 02:35:49 - cd /src TB --- 2012-10-03 02:35:49 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Wed Oct 3 02:35:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror ata_if.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-all.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-dma.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-lowlevel.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-queue.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-sata.c /src/sys/dev/ata/ata-sata.c: In function 'ata_sata_phy_reset': /src/sys/dev/ata/ata-sata.c:158: error: 'struct ata_channel' has no member named 'user' *** Error code 1 Stop in /obj/arm.arm/src/sys/EB9200. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-03 02:36:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-03 02:36:19 - ERROR: failed to build EB9200 kernel TB --- 2012-10-03 02:36:19 - 3580.05 user 742.07 system 5178.31 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 07:19:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DAC6106564A; Wed, 3 Oct 2012 07:19:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 18B778FC12; Wed, 3 Oct 2012 07:19:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q937Ju4o050345; Wed, 3 Oct 2012 03:19:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q937JuYo050337; Wed, 3 Oct 2012 07:19:56 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 3 Oct 2012 07:19:56 GMT Message-Id: <201210030719.q937JuYo050337@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 07:19:57 -0000 TB --- 2012-10-03 01:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-10-03 01:10:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-03 01:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-10-03 01:10:00 - cleaning the object tree TB --- 2012-10-03 01:16:43 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-10-03 01:16:43 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-10-03 01:16:43 - /usr/local/bin/svn cleanup /src TB --- 2012-10-03 01:17:29 - /usr/local/bin/svn update /src TB --- 2012-10-03 01:17:47 - At svn revision 241147 TB --- 2012-10-03 01:17:48 - building world TB --- 2012-10-03 01:17:48 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 01:17:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 01:17:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 01:17:48 - SRCCONF=/dev/null TB --- 2012-10-03 01:17:48 - TARGET=i386 TB --- 2012-10-03 01:17:48 - TARGET_ARCH=i386 TB --- 2012-10-03 01:17:48 - TZ=UTC TB --- 2012-10-03 01:17:48 - __MAKE_CONF=/dev/null TB --- 2012-10-03 01:17:48 - cd /src TB --- 2012-10-03 01:17:48 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 3 01:17:49 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Oct 3 03:45:24 UTC 2012 TB --- 2012-10-03 03:45:24 - generating LINT kernel config TB --- 2012-10-03 03:45:24 - cd /src/sys/i386/conf TB --- 2012-10-03 03:45:24 - /usr/bin/make -B LINT TB --- 2012-10-03 03:45:24 - cd /src/sys/i386/conf TB --- 2012-10-03 03:45:24 - /usr/sbin/config -m LINT TB --- 2012-10-03 03:45:24 - building LINT kernel TB --- 2012-10-03 03:45:24 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 03:45:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 03:45:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 03:45:24 - SRCCONF=/dev/null TB --- 2012-10-03 03:45:24 - TARGET=i386 TB --- 2012-10-03 03:45:24 - TARGET_ARCH=i386 TB --- 2012-10-03 03:45:24 - TZ=UTC TB --- 2012-10-03 03:45:24 - __MAKE_CONF=/dev/null TB --- 2012-10-03 03:45:24 - cd /src TB --- 2012-10-03 03:45:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 3 03:45:24 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Wed Oct 3 04:19:40 UTC 2012 TB --- 2012-10-03 04:19:40 - cd /src/sys/i386/conf TB --- 2012-10-03 04:19:40 - /usr/sbin/config -m LINT-NOINET TB --- 2012-10-03 04:19:40 - building LINT-NOINET kernel TB --- 2012-10-03 04:19:40 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 04:19:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 04:19:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 04:19:40 - SRCCONF=/dev/null TB --- 2012-10-03 04:19:40 - TARGET=i386 TB --- 2012-10-03 04:19:40 - TARGET_ARCH=i386 TB --- 2012-10-03 04:19:40 - TZ=UTC TB --- 2012-10-03 04:19:40 - __MAKE_CONF=/dev/null TB --- 2012-10-03 04:19:40 - cd /src TB --- 2012-10-03 04:19:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Oct 3 04:19:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Wed Oct 3 04:51:36 UTC 2012 TB --- 2012-10-03 04:51:36 - cd /src/sys/i386/conf TB --- 2012-10-03 04:51:36 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-10-03 04:51:36 - building LINT-NOINET6 kernel TB --- 2012-10-03 04:51:36 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 04:51:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 04:51:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 04:51:36 - SRCCONF=/dev/null TB --- 2012-10-03 04:51:36 - TARGET=i386 TB --- 2012-10-03 04:51:36 - TARGET_ARCH=i386 TB --- 2012-10-03 04:51:36 - TZ=UTC TB --- 2012-10-03 04:51:36 - __MAKE_CONF=/dev/null TB --- 2012-10-03 04:51:36 - cd /src TB --- 2012-10-03 04:51:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Wed Oct 3 04:51:37 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Wed Oct 3 05:23:58 UTC 2012 TB --- 2012-10-03 05:23:58 - cd /src/sys/i386/conf TB --- 2012-10-03 05:23:58 - /usr/sbin/config -m LINT-NOIP TB --- 2012-10-03 05:23:58 - building LINT-NOIP kernel TB --- 2012-10-03 05:23:58 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 05:23:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 05:23:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 05:23:58 - SRCCONF=/dev/null TB --- 2012-10-03 05:23:58 - TARGET=i386 TB --- 2012-10-03 05:23:58 - TARGET_ARCH=i386 TB --- 2012-10-03 05:23:58 - TZ=UTC TB --- 2012-10-03 05:23:58 - __MAKE_CONF=/dev/null TB --- 2012-10-03 05:23:58 - cd /src TB --- 2012-10-03 05:23:58 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Wed Oct 3 05:23:58 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Wed Oct 3 05:54:12 UTC 2012 TB --- 2012-10-03 05:54:12 - cd /src/sys/i386/conf TB --- 2012-10-03 05:54:12 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-10-03 05:54:12 - building LINT-VIMAGE kernel TB --- 2012-10-03 05:54:12 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 05:54:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 05:54:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 05:54:12 - SRCCONF=/dev/null TB --- 2012-10-03 05:54:12 - TARGET=i386 TB --- 2012-10-03 05:54:12 - TARGET_ARCH=i386 TB --- 2012-10-03 05:54:12 - TZ=UTC TB --- 2012-10-03 05:54:12 - __MAKE_CONF=/dev/null TB --- 2012-10-03 05:54:12 - cd /src TB --- 2012-10-03 05:54:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Wed Oct 3 05:54:12 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Wed Oct 3 06:26:27 UTC 2012 TB --- 2012-10-03 06:26:27 - cd /src/sys/i386/conf TB --- 2012-10-03 06:26:27 - /usr/sbin/config -m GENERIC TB --- 2012-10-03 06:26:27 - building GENERIC kernel TB --- 2012-10-03 06:26:27 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 06:26:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 06:26:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 06:26:27 - SRCCONF=/dev/null TB --- 2012-10-03 06:26:27 - TARGET=i386 TB --- 2012-10-03 06:26:27 - TARGET_ARCH=i386 TB --- 2012-10-03 06:26:27 - TZ=UTC TB --- 2012-10-03 06:26:27 - __MAKE_CONF=/dev/null TB --- 2012-10-03 06:26:27 - cd /src TB --- 2012-10-03 06:26:27 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Oct 3 06:26:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Wed Oct 3 06:54:47 UTC 2012 TB --- 2012-10-03 06:54:47 - cd /src/sys/i386/conf TB --- 2012-10-03 06:54:47 - /usr/sbin/config -m PAE TB --- 2012-10-03 06:54:47 - building PAE kernel TB --- 2012-10-03 06:54:47 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 06:54:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 06:54:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 06:54:47 - SRCCONF=/dev/null TB --- 2012-10-03 06:54:47 - TARGET=i386 TB --- 2012-10-03 06:54:47 - TARGET_ARCH=i386 TB --- 2012-10-03 06:54:47 - TZ=UTC TB --- 2012-10-03 06:54:47 - __MAKE_CONF=/dev/null TB --- 2012-10-03 06:54:47 - cd /src TB --- 2012-10-03 06:54:47 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Wed Oct 3 06:54:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Wed Oct 3 07:03:43 UTC 2012 TB --- 2012-10-03 07:03:43 - cd /src/sys/i386/conf TB --- 2012-10-03 07:03:43 - /usr/sbin/config -m XBOX TB --- 2012-10-03 07:03:43 - building XBOX kernel TB --- 2012-10-03 07:03:43 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 07:03:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 07:03:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 07:03:43 - SRCCONF=/dev/null TB --- 2012-10-03 07:03:43 - TARGET=i386 TB --- 2012-10-03 07:03:43 - TARGET_ARCH=i386 TB --- 2012-10-03 07:03:43 - TZ=UTC TB --- 2012-10-03 07:03:43 - __MAKE_CONF=/dev/null TB --- 2012-10-03 07:03:43 - cd /src TB --- 2012-10-03 07:03:43 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Wed Oct 3 07:03:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Wed Oct 3 07:07:48 UTC 2012 TB --- 2012-10-03 07:07:48 - cd /src/sys/i386/conf TB --- 2012-10-03 07:07:48 - /usr/sbin/config -m XEN TB --- 2012-10-03 07:07:48 - building XEN kernel TB --- 2012-10-03 07:07:48 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 07:07:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 07:07:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 07:07:48 - SRCCONF=/dev/null TB --- 2012-10-03 07:07:48 - TARGET=i386 TB --- 2012-10-03 07:07:48 - TARGET_ARCH=i386 TB --- 2012-10-03 07:07:48 - TZ=UTC TB --- 2012-10-03 07:07:48 - __MAKE_CONF=/dev/null TB --- 2012-10-03 07:07:48 - cd /src TB --- 2012-10-03 07:07:48 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Wed Oct 3 07:07:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] objcopy --only-keep-debug ataisa.ko.debug ataisa.ko.symbols objcopy --strip-debug --add-gnu-debuglink=ataisa.ko.symbols ataisa.ko.debug ataisa.ko ===> ata/atapci (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ata/atapci/../../../dev/ata/ata-pci.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ata/atapci/../../../dev/ata/ata-dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ata/atapci/../../../dev/ata/ata-sata.c /src/sys/modules/ata/atapci/../../../dev/ata/ata-sata.c: In function 'ata_sata_phy_reset': /src/sys/modules/ata/atapci/../../../dev/ata/ata-sata.c:158: error: 'struct ata_channel' has no member named 'user' *** Error code 1 Stop in /src/sys/modules/ata/atapci. *** Error code 1 Stop in /src/sys/modules/ata. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-03 07:19:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-03 07:19:56 - ERROR: failed to build XEN kernel TB --- 2012-10-03 07:19:56 - 16652.21 user 2320.05 system 22195.25 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 11:57:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7CFB106564A; Wed, 3 Oct 2012 11:57:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6688FC1C; Wed, 3 Oct 2012 11:57:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q93Bvopk088100; Wed, 3 Oct 2012 07:57:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q93Bvosg088099; Wed, 3 Oct 2012 11:57:50 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 3 Oct 2012 11:57:50 GMT Message-Id: <201210031157.q93Bvosg088099@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 11:57:52 -0000 TB --- 2012-10-03 10:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-10-03 10:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-03 10:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-10-03 10:30:00 - cleaning the object tree TB --- 2012-10-03 10:33:36 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-10-03 10:33:36 - cd /tinderbox/HEAD/arm/arm TB --- 2012-10-03 10:33:36 - /usr/local/bin/svn cleanup /src TB --- 2012-10-03 10:34:23 - /usr/local/bin/svn update /src TB --- 2012-10-03 10:34:30 - At svn revision 241157 TB --- 2012-10-03 10:34:31 - building world TB --- 2012-10-03 10:34:31 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 10:34:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 10:34:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 10:34:31 - SRCCONF=/dev/null TB --- 2012-10-03 10:34:31 - TARGET=arm TB --- 2012-10-03 10:34:31 - TARGET_ARCH=arm TB --- 2012-10-03 10:34:31 - TZ=UTC TB --- 2012-10-03 10:34:31 - __MAKE_CONF=/dev/null TB --- 2012-10-03 10:34:31 - cd /src TB --- 2012-10-03 10:34:31 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 3 10:34:32 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Oct 3 11:35:20 UTC 2012 TB --- 2012-10-03 11:35:20 - cd /src/sys/arm/conf TB --- 2012-10-03 11:35:20 - /usr/sbin/config -m AC100 TB --- 2012-10-03 11:35:20 - skipping AC100 kernel TB --- 2012-10-03 11:35:20 - cd /src/sys/arm/conf TB --- 2012-10-03 11:35:20 - /usr/sbin/config -m ARMADAXP TB --- 2012-10-03 11:35:20 - skipping ARMADAXP kernel TB --- 2012-10-03 11:35:20 - cd /src/sys/arm/conf TB --- 2012-10-03 11:35:20 - /usr/sbin/config -m ATMEL TB --- 2012-10-03 11:35:20 - building ATMEL kernel TB --- 2012-10-03 11:35:20 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 11:35:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 11:35:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 11:35:20 - SRCCONF=/dev/null TB --- 2012-10-03 11:35:20 - TARGET=arm TB --- 2012-10-03 11:35:20 - TARGET_ARCH=arm TB --- 2012-10-03 11:35:20 - TZ=UTC TB --- 2012-10-03 11:35:20 - __MAKE_CONF=/dev/null TB --- 2012-10-03 11:35:20 - cd /src TB --- 2012-10-03 11:35:20 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Wed Oct 3 11:35:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Wed Oct 3 11:38:50 UTC 2012 TB --- 2012-10-03 11:38:50 - cd /src/sys/arm/conf TB --- 2012-10-03 11:38:50 - /usr/sbin/config -m AVILA TB --- 2012-10-03 11:38:50 - skipping AVILA kernel TB --- 2012-10-03 11:38:50 - cd /src/sys/arm/conf TB --- 2012-10-03 11:38:50 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-10-03 11:38:50 - skipping BEAGLEBONE kernel TB --- 2012-10-03 11:38:50 - cd /src/sys/arm/conf TB --- 2012-10-03 11:38:50 - /usr/sbin/config -m BWCT TB --- 2012-10-03 11:38:50 - building BWCT kernel TB --- 2012-10-03 11:38:50 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 11:38:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 11:38:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 11:38:50 - SRCCONF=/dev/null TB --- 2012-10-03 11:38:50 - TARGET=arm TB --- 2012-10-03 11:38:50 - TARGET_ARCH=arm TB --- 2012-10-03 11:38:50 - TZ=UTC TB --- 2012-10-03 11:38:50 - __MAKE_CONF=/dev/null TB --- 2012-10-03 11:38:50 - cd /src TB --- 2012-10-03 11:38:50 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Wed Oct 3 11:38:51 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Wed Oct 3 11:41:00 UTC 2012 TB --- 2012-10-03 11:41:00 - cd /src/sys/arm/conf TB --- 2012-10-03 11:41:00 - /usr/sbin/config -m CAMBRIA TB --- 2012-10-03 11:41:01 - skipping CAMBRIA kernel TB --- 2012-10-03 11:41:01 - cd /src/sys/arm/conf TB --- 2012-10-03 11:41:01 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-10-03 11:41:01 - building CNS11XXNAS kernel TB --- 2012-10-03 11:41:01 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 11:41:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 11:41:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 11:41:01 - SRCCONF=/dev/null TB --- 2012-10-03 11:41:01 - TARGET=arm TB --- 2012-10-03 11:41:01 - TARGET_ARCH=arm TB --- 2012-10-03 11:41:01 - TZ=UTC TB --- 2012-10-03 11:41:01 - __MAKE_CONF=/dev/null TB --- 2012-10-03 11:41:01 - cd /src TB --- 2012-10-03 11:41:01 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Wed Oct 3 11:41:01 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Wed Oct 3 11:43:28 UTC 2012 TB --- 2012-10-03 11:43:28 - cd /src/sys/arm/conf TB --- 2012-10-03 11:43:28 - /usr/sbin/config -m CRB TB --- 2012-10-03 11:43:28 - skipping CRB kernel TB --- 2012-10-03 11:43:28 - cd /src/sys/arm/conf TB --- 2012-10-03 11:43:28 - /usr/sbin/config -m DB-78XXX TB --- 2012-10-03 11:43:29 - building DB-78XXX kernel TB --- 2012-10-03 11:43:29 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 11:43:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 11:43:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 11:43:29 - SRCCONF=/dev/null TB --- 2012-10-03 11:43:29 - TARGET=arm TB --- 2012-10-03 11:43:29 - TARGET_ARCH=arm TB --- 2012-10-03 11:43:29 - TZ=UTC TB --- 2012-10-03 11:43:29 - __MAKE_CONF=/dev/null TB --- 2012-10-03 11:43:29 - cd /src TB --- 2012-10-03 11:43:29 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Wed Oct 3 11:43:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Wed Oct 3 11:46:19 UTC 2012 TB --- 2012-10-03 11:46:19 - cd /src/sys/arm/conf TB --- 2012-10-03 11:46:19 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-10-03 11:46:19 - building DB-88F5XXX kernel TB --- 2012-10-03 11:46:19 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 11:46:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 11:46:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 11:46:19 - SRCCONF=/dev/null TB --- 2012-10-03 11:46:19 - TARGET=arm TB --- 2012-10-03 11:46:19 - TARGET_ARCH=arm TB --- 2012-10-03 11:46:19 - TZ=UTC TB --- 2012-10-03 11:46:19 - __MAKE_CONF=/dev/null TB --- 2012-10-03 11:46:19 - cd /src TB --- 2012-10-03 11:46:19 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Wed Oct 3 11:46:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Wed Oct 3 11:49:04 UTC 2012 TB --- 2012-10-03 11:49:04 - cd /src/sys/arm/conf TB --- 2012-10-03 11:49:04 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-10-03 11:49:04 - building DB-88F6XXX kernel TB --- 2012-10-03 11:49:04 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 11:49:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 11:49:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 11:49:04 - SRCCONF=/dev/null TB --- 2012-10-03 11:49:04 - TARGET=arm TB --- 2012-10-03 11:49:04 - TARGET_ARCH=arm TB --- 2012-10-03 11:49:04 - TZ=UTC TB --- 2012-10-03 11:49:04 - __MAKE_CONF=/dev/null TB --- 2012-10-03 11:49:04 - cd /src TB --- 2012-10-03 11:49:04 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Wed Oct 3 11:49:04 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Wed Oct 3 11:52:00 UTC 2012 TB --- 2012-10-03 11:52:00 - cd /src/sys/arm/conf TB --- 2012-10-03 11:52:00 - /usr/sbin/config -m DOCKSTAR TB --- 2012-10-03 11:52:00 - building DOCKSTAR kernel TB --- 2012-10-03 11:52:00 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 11:52:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 11:52:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 11:52:00 - SRCCONF=/dev/null TB --- 2012-10-03 11:52:00 - TARGET=arm TB --- 2012-10-03 11:52:00 - TARGET_ARCH=arm TB --- 2012-10-03 11:52:00 - TZ=UTC TB --- 2012-10-03 11:52:00 - __MAKE_CONF=/dev/null TB --- 2012-10-03 11:52:00 - cd /src TB --- 2012-10-03 11:52:00 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Wed Oct 3 11:52:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Wed Oct 3 11:54:38 UTC 2012 TB --- 2012-10-03 11:54:38 - cd /src/sys/arm/conf TB --- 2012-10-03 11:54:38 - /usr/sbin/config -m EA3250 TB --- 2012-10-03 11:54:38 - building EA3250 kernel TB --- 2012-10-03 11:54:38 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 11:54:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 11:54:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 11:54:38 - SRCCONF=/dev/null TB --- 2012-10-03 11:54:38 - TARGET=arm TB --- 2012-10-03 11:54:38 - TARGET_ARCH=arm TB --- 2012-10-03 11:54:38 - TZ=UTC TB --- 2012-10-03 11:54:38 - __MAKE_CONF=/dev/null TB --- 2012-10-03 11:54:38 - cd /src TB --- 2012-10-03 11:54:38 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Wed Oct 3 11:54:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Wed Oct 3 11:57:20 UTC 2012 TB --- 2012-10-03 11:57:20 - cd /src/sys/arm/conf TB --- 2012-10-03 11:57:20 - /usr/sbin/config -m EB9200 TB --- 2012-10-03 11:57:20 - building EB9200 kernel TB --- 2012-10-03 11:57:20 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 11:57:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 11:57:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 11:57:20 - SRCCONF=/dev/null TB --- 2012-10-03 11:57:20 - TARGET=arm TB --- 2012-10-03 11:57:20 - TARGET_ARCH=arm TB --- 2012-10-03 11:57:20 - TZ=UTC TB --- 2012-10-03 11:57:20 - __MAKE_CONF=/dev/null TB --- 2012-10-03 11:57:20 - cd /src TB --- 2012-10-03 11:57:20 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Wed Oct 3 11:57:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror ata_if.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-all.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-dma.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-lowlevel.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-queue.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=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-sata.c /src/sys/dev/ata/ata-sata.c: In function 'ata_sata_phy_reset': /src/sys/dev/ata/ata-sata.c:158: error: 'struct ata_channel' has no member named 'user' *** Error code 1 Stop in /obj/arm.arm/src/sys/EB9200. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-03 11:57:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-03 11:57:50 - ERROR: failed to build EB9200 kernel TB --- 2012-10-03 11:57:50 - 3585.72 user 743.74 system 5270.01 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 12:23:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31F3A106566B; Wed, 3 Oct 2012 12:23:48 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id B705D8FC0A; Wed, 3 Oct 2012 12:23:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id DAB842A82AA4; Wed, 3 Oct 2012 14:23:39 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ERNYHBIasij; Wed, 3 Oct 2012 14:23:39 +0200 (SAST) Received: from clue.co.za (l2tp.clue.co.za [41.154.88.20]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 2D77C2A82A86; Wed, 3 Oct 2012 14:23:39 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TJNzG-0001L6-2p; Wed, 03 Oct 2012 14:23:38 +0200 To: FreeBSD Tinderbox From: Ian FREISLICH In-Reply-To: <201210031157.q93Bvosg088099@freebsd-current.sentex.ca> References: <201210031157.q93Bvosg088099@freebsd-current.sentex.ca> X-Attribution: BOFH Date: Wed, 03 Oct 2012 14:23:38 +0200 Message-Id: Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:23:48 -0000 FreeBSD Tinderbox wrote: > 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-sh ow-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contri b/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-comm on -finline-limit=8000 --param inline-unit-growth=100 --param large-function-gr owth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/dev/ata/ata-sata.c > /src/sys/dev/ata/ata-sata.c: In function 'ata_sata_phy_reset': > /src/sys/dev/ata/ata-sata.c:158: error: 'struct ata_channel' has no member na med 'user' > *** Error code 1 ata_channel member user is only defined if ATA_CAM is defined. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 16:32:45 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FEF4106564A; Wed, 3 Oct 2012 16:32:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BFB8C8FC0A; Wed, 3 Oct 2012 16:32:44 +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 q93GWcEw013526; Wed, 3 Oct 2012 12:32:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q93GWbT2013518; Wed, 3 Oct 2012 16:32:37 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 3 Oct 2012 16:32:37 GMT Message-Id: <201210031632.q93GWbT2013518@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:32:45 -0000 TB --- 2012-10-03 10:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-10-03 10:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-03 10:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-10-03 10:30:00 - cleaning the object tree TB --- 2012-10-03 10:37:16 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-10-03 10:37:16 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-10-03 10:37:16 - /usr/local/bin/svn cleanup /src TB --- 2012-10-03 10:38:12 - /usr/local/bin/svn update /src TB --- 2012-10-03 10:38:19 - At svn revision 241157 TB --- 2012-10-03 10:38:20 - building world TB --- 2012-10-03 10:38:20 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 10:38:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 10:38:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 10:38:20 - SRCCONF=/dev/null TB --- 2012-10-03 10:38:20 - TARGET=i386 TB --- 2012-10-03 10:38:20 - TARGET_ARCH=i386 TB --- 2012-10-03 10:38:20 - TZ=UTC TB --- 2012-10-03 10:38:20 - __MAKE_CONF=/dev/null TB --- 2012-10-03 10:38:20 - cd /src TB --- 2012-10-03 10:38:20 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 3 10:38:21 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Oct 3 13:05:07 UTC 2012 TB --- 2012-10-03 13:05:07 - generating LINT kernel config TB --- 2012-10-03 13:05:07 - cd /src/sys/i386/conf TB --- 2012-10-03 13:05:07 - /usr/bin/make -B LINT TB --- 2012-10-03 13:05:07 - cd /src/sys/i386/conf TB --- 2012-10-03 13:05:07 - /usr/sbin/config -m LINT TB --- 2012-10-03 13:05:07 - building LINT kernel TB --- 2012-10-03 13:05:07 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 13:05:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 13:05:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 13:05:07 - SRCCONF=/dev/null TB --- 2012-10-03 13:05:07 - TARGET=i386 TB --- 2012-10-03 13:05:07 - TARGET_ARCH=i386 TB --- 2012-10-03 13:05:07 - TZ=UTC TB --- 2012-10-03 13:05:07 - __MAKE_CONF=/dev/null TB --- 2012-10-03 13:05:07 - cd /src TB --- 2012-10-03 13:05:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 3 13:05:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Wed Oct 3 13:39:23 UTC 2012 TB --- 2012-10-03 13:39:23 - cd /src/sys/i386/conf TB --- 2012-10-03 13:39:23 - /usr/sbin/config -m LINT-NOINET TB --- 2012-10-03 13:39:23 - building LINT-NOINET kernel TB --- 2012-10-03 13:39:23 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 13:39:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 13:39:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 13:39:23 - SRCCONF=/dev/null TB --- 2012-10-03 13:39:23 - TARGET=i386 TB --- 2012-10-03 13:39:23 - TARGET_ARCH=i386 TB --- 2012-10-03 13:39:23 - TZ=UTC TB --- 2012-10-03 13:39:23 - __MAKE_CONF=/dev/null TB --- 2012-10-03 13:39:23 - cd /src TB --- 2012-10-03 13:39:23 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Oct 3 13:39:23 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Wed Oct 3 14:11:12 UTC 2012 TB --- 2012-10-03 14:11:12 - cd /src/sys/i386/conf TB --- 2012-10-03 14:11:12 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-10-03 14:11:12 - building LINT-NOINET6 kernel TB --- 2012-10-03 14:11:12 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 14:11:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 14:11:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 14:11:12 - SRCCONF=/dev/null TB --- 2012-10-03 14:11:12 - TARGET=i386 TB --- 2012-10-03 14:11:12 - TARGET_ARCH=i386 TB --- 2012-10-03 14:11:12 - TZ=UTC TB --- 2012-10-03 14:11:12 - __MAKE_CONF=/dev/null TB --- 2012-10-03 14:11:12 - cd /src TB --- 2012-10-03 14:11:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Wed Oct 3 14:11:12 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Wed Oct 3 14:43:31 UTC 2012 TB --- 2012-10-03 14:43:31 - cd /src/sys/i386/conf TB --- 2012-10-03 14:43:31 - /usr/sbin/config -m LINT-NOIP TB --- 2012-10-03 14:43:31 - building LINT-NOIP kernel TB --- 2012-10-03 14:43:31 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 14:43:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 14:43:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 14:43:31 - SRCCONF=/dev/null TB --- 2012-10-03 14:43:31 - TARGET=i386 TB --- 2012-10-03 14:43:31 - TARGET_ARCH=i386 TB --- 2012-10-03 14:43:31 - TZ=UTC TB --- 2012-10-03 14:43:31 - __MAKE_CONF=/dev/null TB --- 2012-10-03 14:43:31 - cd /src TB --- 2012-10-03 14:43:31 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Wed Oct 3 14:43:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Wed Oct 3 15:13:57 UTC 2012 TB --- 2012-10-03 15:13:57 - cd /src/sys/i386/conf TB --- 2012-10-03 15:13:57 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-10-03 15:13:57 - building LINT-VIMAGE kernel TB --- 2012-10-03 15:13:57 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 15:13:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 15:13:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 15:13:57 - SRCCONF=/dev/null TB --- 2012-10-03 15:13:57 - TARGET=i386 TB --- 2012-10-03 15:13:57 - TARGET_ARCH=i386 TB --- 2012-10-03 15:13:57 - TZ=UTC TB --- 2012-10-03 15:13:57 - __MAKE_CONF=/dev/null TB --- 2012-10-03 15:13:57 - cd /src TB --- 2012-10-03 15:13:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Wed Oct 3 15:13:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Wed Oct 3 15:46:09 UTC 2012 TB --- 2012-10-03 15:46:09 - cd /src/sys/i386/conf TB --- 2012-10-03 15:46:09 - /usr/sbin/config -m GENERIC TB --- 2012-10-03 15:46:09 - building GENERIC kernel TB --- 2012-10-03 15:46:09 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 15:46:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 15:46:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 15:46:09 - SRCCONF=/dev/null TB --- 2012-10-03 15:46:09 - TARGET=i386 TB --- 2012-10-03 15:46:09 - TARGET_ARCH=i386 TB --- 2012-10-03 15:46:09 - TZ=UTC TB --- 2012-10-03 15:46:09 - __MAKE_CONF=/dev/null TB --- 2012-10-03 15:46:09 - cd /src TB --- 2012-10-03 15:46:09 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Oct 3 15:46:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Wed Oct 3 16:14:40 UTC 2012 TB --- 2012-10-03 16:14:40 - cd /src/sys/i386/conf TB --- 2012-10-03 16:14:40 - /usr/sbin/config -m PAE TB --- 2012-10-03 16:14:40 - building PAE kernel TB --- 2012-10-03 16:14:40 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 16:14:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 16:14:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 16:14:40 - SRCCONF=/dev/null TB --- 2012-10-03 16:14:40 - TARGET=i386 TB --- 2012-10-03 16:14:40 - TARGET_ARCH=i386 TB --- 2012-10-03 16:14:40 - TZ=UTC TB --- 2012-10-03 16:14:40 - __MAKE_CONF=/dev/null TB --- 2012-10-03 16:14:40 - cd /src TB --- 2012-10-03 16:14:40 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Wed Oct 3 16:14:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Wed Oct 3 16:22:45 UTC 2012 TB --- 2012-10-03 16:22:45 - cd /src/sys/i386/conf TB --- 2012-10-03 16:22:45 - /usr/sbin/config -m XBOX TB --- 2012-10-03 16:22:46 - building XBOX kernel TB --- 2012-10-03 16:22:46 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 16:22:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 16:22:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 16:22:46 - SRCCONF=/dev/null TB --- 2012-10-03 16:22:46 - TARGET=i386 TB --- 2012-10-03 16:22:46 - TARGET_ARCH=i386 TB --- 2012-10-03 16:22:46 - TZ=UTC TB --- 2012-10-03 16:22:46 - __MAKE_CONF=/dev/null TB --- 2012-10-03 16:22:46 - cd /src TB --- 2012-10-03 16:22:46 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Wed Oct 3 16:22:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Wed Oct 3 16:26:10 UTC 2012 TB --- 2012-10-03 16:26:10 - cd /src/sys/i386/conf TB --- 2012-10-03 16:26:10 - /usr/sbin/config -m XEN TB --- 2012-10-03 16:26:10 - building XEN kernel TB --- 2012-10-03 16:26:10 - CROSS_BUILD_TESTING=YES TB --- 2012-10-03 16:26:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-03 16:26:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-03 16:26:10 - SRCCONF=/dev/null TB --- 2012-10-03 16:26:10 - TARGET=i386 TB --- 2012-10-03 16:26:10 - TARGET_ARCH=i386 TB --- 2012-10-03 16:26:10 - TZ=UTC TB --- 2012-10-03 16:26:10 - __MAKE_CONF=/dev/null TB --- 2012-10-03 16:26:10 - cd /src TB --- 2012-10-03 16:26:10 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Wed Oct 3 16:26:10 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] objcopy --only-keep-debug ataisa.ko.debug ataisa.ko.symbols objcopy --strip-debug --add-gnu-debuglink=ataisa.ko.symbols ataisa.ko.debug ataisa.ko ===> ata/atapci (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ata/atapci/../../../dev/ata/ata-pci.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ata/atapci/../../../dev/ata/ata-dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ata/atapci/../../../dev/ata/ata-sata.c /src/sys/modules/ata/atapci/../../../dev/ata/ata-sata.c: In function 'ata_sata_phy_reset': /src/sys/modules/ata/atapci/../../../dev/ata/ata-sata.c:158: error: 'struct ata_channel' has no member named 'user' *** Error code 1 Stop in /src/sys/modules/ata/atapci. *** Error code 1 Stop in /src/sys/modules/ata. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-10-03 16:32:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-10-03 16:32:37 - ERROR: failed to build XEN kernel TB --- 2012-10-03 16:32:37 - 16656.00 user 2309.23 system 21757.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 19:17:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DAA31065670 for ; Wed, 3 Oct 2012 19:17:45 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id 0C18F8FC08 for ; Wed, 3 Oct 2012 19:17:44 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 6820 invoked from network); 3 Oct 2012 21:17:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1349291861; bh=3fhp+zlRH3mKeKrU/bPBS88aqlRD6YPd5xL+C3+e2HY=; h=From:To:CC:Subject; b=k8YZs8ewmqSK6DVHAJ7YUIQV+DggDQrp7Hqxqpk7Y3wIDu9FSgLfxLwf67H/z+7sF lUJWYMxZDHM72hxt2NZxxNNAmWMasjp1GnuzpU2z7LjHj8piKY1efcp99Ijzo9pqxF 1ge0JDdSzuxdWe9GTZ6w7/V3sn10AEE4zmXHLkPY= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 3 Oct 2012 21:17:41 +0200 Message-ID: <506C8F4F.3040703@wp.pl> Date: Wed, 03 Oct 2012 21:17:35 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: lev@FreeBSD.org References: <80840563.20120920002200@serebryakov.spb.ru> In-Reply-To: <80840563.20120920002200@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121003-1, 2012-10-03), Outbound message X-Antivirus-Status: Clean X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [cWMk] Cc: freebsd-current@FreeBSD.org Subject: Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:17:45 -0000 W dniu 2012-09-19 22:22, Lev Serebryakov pisze: > Hello, Freebsd-current. > > I've upgraded my FreeBSD-CURRENT Virtual machine, which I use to > build router's NanoBSD image, to today's morning (MSK time, GMT+4) > revision. Unfortunately, I cannot provide exact version, as sources > are in this unbootable VM too :) > > Kernel is GENERIC. > > VBox configuration is rather stander: 2 CPUs, ICH9, 2GB of RAM. > Host is Windows 7/64bit. > > Booting hangs after (new?) line: > > atrtc0: port 0x70-0x71 on acpi0 > Hi, still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host Do you have any solution? Regards, -- Marek Salwerowicz From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 19:30:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED690106564A for ; Wed, 3 Oct 2012 19:30:07 +0000 (UTC) (envelope-from chris@chrysalisnet.org) Received: from mail.hostingfreak.net (mail.hostingfreak.net [78.46.185.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8685B8FC14 for ; Wed, 3 Oct 2012 19:30:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chrysalisnet.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:Sender:From; bh=p2P+r4koyHKgE/pgGOdRff42tRx72ZCUjuMNz1fcwag=; b=Y4EM71EjTWItVFLT+1Lxx23ghopoGtBcH+tFaNGQtc571rbjlPuW4O3n7K+u/8N/fLxcvlNMf7yxS0MVKel/MdlQGknKLEIIGIp1KpSh79fJH+hrySZU2QyUog9rBthz; Received: from cpc14-leic14-2-0-cust191.8-1.cable.virginmedia.com ([82.30.112.192]:53672 helo=i5PC) (HELO=i5PC) by 78.46.185.200 with esmtpsa (Exim) }(envelope-from ) id 1TJTwQ-0004Oy-4B for freebsd-current@freebsd.org; Wed, 03 Oct 2012 19:45:06 +0100 From: Sender: "Chris" To: Date: Wed, 3 Oct 2012 19:45:01 +0100 Message-ID: <03e101cda197$326dc240$974946c0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac2hly+VJdt7ycw6RTqptHJQiziK4w== Content-Language: en-gb X-Antivirus-Scanner: Scanned with Exiscan. Clean mail though you should still use an Antivirus X-bounce-key: hostingfreak.net-1;chris@chrysalisnet.org;1349292607;3e2d532f; X-Mailman-Approved-At: Wed, 03 Oct 2012 19:40:31 +0000 Subject: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:30:08 -0000 Hi everyone. Actually 65k sockets is incredibly easy to reach. I manage some servers for a very large website, it currently has several http servers clustered to handle daily traffic and this is only dynamic content, static has its own servers, databases also have own servers. We recently started using memcached to cache some queries and we found on default server limits sockets were saturated extremely quickly, on the linux servers bumping it to a few hundred K solved the issue, wasnt possible on bsd. We did manage to get it down to only needing about 20k by setting extremely low timeout values. In addition we had to migrate all our mysql servers from freebsd to debian because they were hitting some arbitary OS limit but I could never figure out what, sys% usage went through the roof when this limit was hit, issue didnt occur on debian. I feel recently freebsd is more focused on desktop's and as such developer's never develop for a heavy server usage scenario, and I keep coming across hardcoded low limits. As rightly pointed out default values now days are useless 128 for somaxconn? maybe ok for a desktop. Freebsd also has issues with high numbers of cpu cores, very high locking overheads, the problem is the modern hardware is focusing on more and more cores and as such much more work on a server so a OS has to handle more and more processing and data, this includes more bigger connection queues and so on. FreeBSD just isnt scaling with more powerful hardware. Also forgetting as well DDOS attack scenarios where a high queue size is useful. I have used FreeBSD since the 4.x days and have been forced to migrate OS on several servers as FreeBSD to be blunt couldnt handle the load on those servers. It does seem as if developers of the OS are getting out of touch in respect to modern hosting enviromnents. I cant tell app developers to fix their apps to work on FreeBSD, they dont care, if it works fine on windows and linux then the app isnt broken as far as they are concerned. The more FreeBSD dev's have this aatitude of not adapting the less machines will run the OS. I hate many things about debian but at the end of the day I have to use what can handle the load or I lose my job. I do accept its entirely possible some tunables could fix any issues I have come across but believe me I have spent 100s of man hours on issues, and tuned everything I could find. To me this 32767 limit on somaxconn seems restrive and I vote for it been bumped to at least 8x that amount as a minimum. A more suitable default would probably be around 1024 as well instead of 128. Dead lingering connections in timewait etc. all use one of these, and that can very easily get into the 1000s. Chris From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 20:01:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48D3F1065674; Wed, 3 Oct 2012 20:01:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id E97AC8FC1B; Wed, 3 Oct 2012 20:01:39 +0000 (UTC) Received: by oagn9 with SMTP id n9so8432303oag.13 for ; Wed, 03 Oct 2012 13:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EZFDkdXYfASTgzGisFEhsYsaVriToztG9OWZGvRAoOE=; b=NoWnS46D5wduDE+cJF1gCG6TQbcrjlNNHuYKy99lAgOHqj6RKER41Cdn+wreWJZDmE s6YJC22AvFBxg4G5/6nBwLBc+8r/WTEduzk+fWTSJsuOzZXdFkrOTYTbS6IZPuAqOjDC vfn8zAB0mFMXmBaalbinoLylK+1P0iYF0JsoU2O3pszFiqn3u4AUPBfgPaShEQ1ggrjj N1It6dN9VmHLjvZcoSrq1sEN3kBySABrhShqdp8voFqw+m7xnvXY2VB7HhLelWMhTZyX GBDw7F49Q4NmRsJ8EEru/FIRCSmYBX6aneYk8nYbAgBLDaVF6wqOEjWk3C+mt5djIXei wNDw== MIME-Version: 1.0 Received: by 10.182.218.37 with SMTP id pd5mr2490917obc.24.1349294498995; Wed, 03 Oct 2012 13:01:38 -0700 (PDT) Received: by 10.76.142.201 with HTTP; Wed, 3 Oct 2012 13:01:38 -0700 (PDT) In-Reply-To: <03e101cda197$326dc240$974946c0$@org> References: <03e101cda197$326dc240$974946c0$@org> Date: Wed, 3 Oct 2012 13:01:38 -0700 Message-ID: From: Garrett Cooper To: freebsd@chrysalisnet.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Gleb Smirnoff Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:01:40 -0000 On Wed, Oct 3, 2012 at 11:45 AM, wrote: > Hi everyone. > > Actually 65k sockets is incredibly easy to reach. > > I manage some servers for a very large website, it currently has several > http servers clustered to handle daily traffic and this is only dynamic > content, static has its own servers, databases also have own servers. > > We recently started using memcached to cache some queries and we found on > default server limits sockets were saturated extremely quickly, on the linux > servers bumping it to a few hundred K solved the issue, wasnt possible on > bsd. We did manage to get it down to only needing about 20k by setting > extremely low timeout values. > > In addition we had to migrate all our mysql servers from freebsd to debian > because they were hitting some arbitary OS limit but I could never figure > out what, sys% usage went through the roof when this limit was hit, issue > didnt occur on debian. I feel recently freebsd is more focused on desktop's > and as such developer's never develop for a heavy server usage scenario, and > I keep coming across hardcoded low limits. As rightly pointed out default > values now days are useless 128 for somaxconn? maybe ok for a desktop. > > Freebsd also has issues with high numbers of cpu cores, very high locking > overheads, the problem is the modern hardware is focusing on more and more > cores and as such much more work on a server so a OS has to handle more and > more processing and data, this includes more bigger connection queues and so > on. FreeBSD just isnt scaling with more powerful hardware. Also forgetting > as well DDOS attack scenarios where a high queue size is useful. > > I have used FreeBSD since the 4.x days and have been forced to migrate OS on > several servers as FreeBSD to be blunt couldnt handle the load on those > servers. It does seem as if developers of the OS are getting out of touch > in respect to modern hosting enviromnents. I cant tell app developers to > fix their apps to work on FreeBSD, they dont care, if it works fine on > windows and linux then the app isnt broken as far as they are concerned. > The more FreeBSD dev's have this aatitude of not adapting the less machines > will run the OS. I hate many things about debian but at the end of the day > I have to use what can handle the load or I lose my job. > > I do accept its entirely possible some tunables could fix any issues I have > come across but believe me I have spent 100s of man hours on issues, and > tuned everything I could find. > > To me this 32767 limit on somaxconn seems restrive and I vote for it been > bumped to at least 8x that amount as a minimum. A more suitable default > would probably be around 1024 as well instead of 128. Dead lingering > connections in timewait etc. all use one of these, and that can very easily > get into the 1000s. Here's where it's being held at 65535 (sys/kern/kern_uipc.c): 3276 static int 3277 sysctl_somaxconn(SYSCTL_HANDLER_ARGS) 3278 { 3279 int error; 3280 int val; 3281 3282 val = somaxconn; 3283 error = sysctl_handle_int(oidp, &val, 0, req); 3284 if (error || !req->newptr ) 3285 return (error); 3286 3287 if (val < 1 || val > USHRT_MAX) 3288 return (EINVAL); 3289 More details about the need for this limit are in http://svnweb.freebsd.org/base?view=revision&revision=140730 . It looks like this needs to be enhanced to support more than USHRT_MAX, which will require socket structure changes and other fun things, but should be possible... I've CCed glebius for comment on this. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 20:03:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23B731065673 for ; Wed, 3 Oct 2012 20:03:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB1288FC21 for ; Wed, 3 Oct 2012 20:03:08 +0000 (UTC) Received: by pbbrp8 with SMTP id rp8so11823320pbb.13 for ; Wed, 03 Oct 2012 13:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZI7Cf4WMN0tRqnsflz9ziP+VHPC8EFGO8Xd2Mf6bL4g=; b=PKaw09JLkEWb6MK6BkGL5R6Jy9bZrB9LwjODaG1Zb8jOIWbRSKNvr7e794AEcIhga9 jIh9OA6Pxwq6YnnrqAHGCBQAHPxSgPEDmXe4DvWCow5x4wb2dFaYN9BvvLZN2mRKyC+H sBmr/8cBzyPC+i/MWVSikebY8DP7dtV2P7j5cmZV+JIXu6H+EKf1/rNP/0kaMbKlGkjS wKxTko9Ew1dmoenD9LbNk966YYb507p1y9TEwqaPUeoN/5HGNfqc7OT8tLU2KMCdWgTN 3yMOOLVnf7EgBZLvfnKN91p2L52AsS+R+roQQWyJpNOf7oURcJmKYMKQ8lOwzlUknqwT bZ2A== MIME-Version: 1.0 Received: by 10.66.85.10 with SMTP id d10mr7508527paz.52.1349294588701; Wed, 03 Oct 2012 13:03:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.223.136 with HTTP; Wed, 3 Oct 2012 13:03:08 -0700 (PDT) In-Reply-To: <03e101cda197$326dc240$974946c0$@org> References: <03e101cda197$326dc240$974946c0$@org> Date: Wed, 3 Oct 2012 13:03:08 -0700 X-Google-Sender-Auth: UsErPmZUw2pxZ4dG1RyYx9cq79U Message-ID: From: Adrian Chadd To: freebsd@chrysalisnet.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:03:09 -0000 Hi, somaxconn is the connection queue depth. If it's sitting at a couple hundred thousand then something else is going crazily wrong. I understand your frustration, but there's a lot of instances where the application just isn't doing things "right" and the OS tries to hide it as much as psosible. Blowing out somaxconn to chew up a whole lot of resources seems a bit silly. I'd rather investigate why the userland application is not servicing the connect queue often enough. I've written network services that supported tens of thousands of new TCP connections a second on a LAN and I never once had to bump somaxconn past 32767. I'm not saying that it won't apply to your scenario, I'm just trying to explain that there's likely more going on. Adrian On 3 October 2012 11:45, wrote: > Hi everyone. > > Actually 65k sockets is incredibly easy to reach. > > I manage some servers for a very large website, it currently has several > http servers clustered to handle daily traffic and this is only dynamic > content, static has its own servers, databases also have own servers. > > We recently started using memcached to cache some queries and we found on > default server limits sockets were saturated extremely quickly, on the linux > servers bumping it to a few hundred K solved the issue, wasnt possible on > bsd. We did manage to get it down to only needing about 20k by setting > extremely low timeout values. > > In addition we had to migrate all our mysql servers from freebsd to debian > because they were hitting some arbitary OS limit but I could never figure > out what, sys% usage went through the roof when this limit was hit, issue > didnt occur on debian. I feel recently freebsd is more focused on desktop's > and as such developer's never develop for a heavy server usage scenario, and > I keep coming across hardcoded low limits. As rightly pointed out default > values now days are useless 128 for somaxconn? maybe ok for a desktop. > > Freebsd also has issues with high numbers of cpu cores, very high locking > overheads, the problem is the modern hardware is focusing on more and more > cores and as such much more work on a server so a OS has to handle more and > more processing and data, this includes more bigger connection queues and so > on. FreeBSD just isnt scaling with more powerful hardware. Also forgetting > as well DDOS attack scenarios where a high queue size is useful. > > I have used FreeBSD since the 4.x days and have been forced to migrate OS on > several servers as FreeBSD to be blunt couldnt handle the load on those > servers. It does seem as if developers of the OS are getting out of touch > in respect to modern hosting enviromnents. I cant tell app developers to > fix their apps to work on FreeBSD, they dont care, if it works fine on > windows and linux then the app isnt broken as far as they are concerned. > The more FreeBSD dev's have this aatitude of not adapting the less machines > will run the OS. I hate many things about debian but at the end of the day > I have to use what can handle the load or I lose my job. > > I do accept its entirely possible some tunables could fix any issues I have > come across but believe me I have spent 100s of man hours on issues, and > tuned everything I could find. > > To me this 32767 limit on somaxconn seems restrive and I vote for it been > bumped to at least 8x that amount as a minimum. A more suitable default > would probably be around 1024 as well instead of 128. Dead lingering > connections in timewait etc. all use one of these, and that can very easily > get into the 1000s. > > Chris > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 20:05:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26C36106564A for ; Wed, 3 Oct 2012 20:05:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 064C58FC12 for ; Wed, 3 Oct 2012 20:05:54 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id A81411B829; Wed, 3 Oct 2012 13:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1349294753; bh=6TcTU9FwnSgEOUQSclCyS5k5xgxXcykH0O0zVrC4jOU=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=H22m9HRdH/vYt5/0AHK14/z/WJ1mXuqgcxN3QBgpYM4+ZuZmyW0a3MO4ArK0Z81As DPhxnpGd+c4Lo3Xb/TDFJvbEI8kPxFR9IAbPydtyH9qAmHVFm5cyyAbj3//lMq5pgO UFTwzAwiAoplNk5tISQsmSn+sVnhGRCz7K+NzBvc= Message-ID: <506C9AA0.9060200@delphij.net> Date: Wed, 03 Oct 2012 13:05:52 -0700 From: Xin Li Organization: The freeBSD Project User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.7) Gecko/20120830 Thunderbird/10.0.7 MIME-Version: 1.0 To: freebsd@chrysalisnet.org References: <03e101cda197$326dc240$974946c0$@org> In-Reply-To: <03e101cda197$326dc240$974946c0$@org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:05:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 10/03/12 11:45, freebsd@chrysalisnet.org wrote: > Hi everyone. > > Actually 65k sockets is incredibly easy to reach. No, this is not kern.ipc.maxsockets. kern.ipc.somaxconn is for "baclkog" and not the maximum connections. Accumulating 64K of pending connection request without giving them some love (e.g. accept()) means there is something wrong. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQbJqgAAoJEG80Jeu8UPuz+x0H/2y+aJC1/yotlnjZcjzAmhm2 WpI8l2WNO7oezUH9t6z8SI543Ky0mLjq52oVJTlBWyXuFkGNQdtKJgrbm5hLAiCz FPojm0p/y3T/ujosunPQl0e/yws6odbEdpGrjSCGJ0VXPQrsWj7NqAJNcDn5hW6m 2wYDkkY9gIxgdfLh8GINvEGO1uY0fyKaPZesepzUsAOOSj/fVdvRK7gSKqaHwDdW u8VCvfrgD1I1rKj57ymVsf/lpIVPDAv020rJzDnNWWM1dekqzvM7xZ5HiZgkdCca rTZQGJM3wujuHrjkHP3U5LDMflRWdOHzU236m7vw6jR7ll1xU5GljeNuwp95wFo= =8tip -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 20:06:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D955B106578D; Wed, 3 Oct 2012 20:06:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id A60118FC08; Wed, 3 Oct 2012 20:06:11 +0000 (UTC) Received: by padbi1 with SMTP id bi1so7662872pad.13 for ; Wed, 03 Oct 2012 13:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZPMuAamP7BUHTGi9jWbaC0afymLbd3LmcOcwV89d6z0=; b=JAe/VwijMruqteuxzt8r23t058Gx4o43Sq63cuBQ0iCwaS46uVvyTpxZzFfh8to3aC TVoIxnQeAEOYWXcUAkxojaloQYR8qxTlzZrTip8E5b5H+fEBh0bLAnXV0Rw1sVpVGOxX L894qZinmp7Cd15Thw4dwMPTqKPPy/lpXBoFeXRkueu+7YP2AgqpEbSagQK1TG/eMKUa BhjIWYAnO9OONfekRP6z4cjD0Zpg0f7sm6GU1njVMOPWv7VnrsLdp2eIXh3XgW+QmgKY kJqSHTpVL6xTgdYriAo3PC9TVNEBRdyI6wNA24iCcZ7X9CanaZ/xQ6kbJ2vMJIbCpHXP zB+Q== MIME-Version: 1.0 Received: by 10.68.135.39 with SMTP id pp7mr15539022pbb.127.1349294771091; Wed, 03 Oct 2012 13:06:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.223.136 with HTTP; Wed, 3 Oct 2012 13:06:11 -0700 (PDT) In-Reply-To: References: <03e101cda197$326dc240$974946c0$@org> Date: Wed, 3 Oct 2012 13:06:11 -0700 X-Google-Sender-Auth: GIzcduuJrWZH3G6wSKtViFEGgA0 Message-ID: From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd@chrysalisnet.org, freebsd-current@freebsd.org, Gleb Smirnoff Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:06:12 -0000 On 3 October 2012 13:01, Garrett Cooper wrote: > > Here's where it's being held at 65535 (sys/kern/kern_uipc.c): > > 3276 static int > 3277 sysctl_somaxconn(SYSCTL_HANDLER_ARGS) > 3278 { > 3279 int error; > 3280 int val; > 3281 > 3282 val = somaxconn; > 3283 error = sysctl_handle_int(oidp, &val, 0, req); > 3284 if (error || !req->newptr ) > 3285 return (error); > 3286 > 3287 if (val < 1 || val > USHRT_MAX) > 3288 return (EINVAL); > 3289 > > More details about the need for this limit are in > http://svnweb.freebsd.org/base?view=revision&revision=140730 . > > It looks like this needs to be enhanced to support more than > USHRT_MAX, which will require socket structure changes and other fun > things, but should be possible... I've CCed glebius for comment on > this. Again, somaxconn is _not the number of sockets_. It's the backlog allowed in the incoming connection queue for a given socket. That's it. If you pass listen a backlog value of -1 or greater than somaxconn, then the queue depth gets pinned at somaxconn. There's something else going on.. Adrian From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 20:14:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C06B0106572A for ; Wed, 3 Oct 2012 20:14:25 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9768FC12 for ; Wed, 3 Oct 2012 20:14:24 +0000 (UTC) Received: (qmail 61788 invoked from network); 3 Oct 2012 21:55:53 -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 ; 3 Oct 2012 21:55:53 -0000 Message-ID: <506C9CE4.6080400@freebsd.org> Date: Wed, 03 Oct 2012 22:15:32 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adrian Chadd References: <03e101cda197$326dc240$974946c0$@org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd@chrysalisnet.org, freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:14:25 -0000 On 03.10.2012 22:03, Adrian Chadd wrote: > Hi, > > somaxconn is the connection queue depth. If it's sitting at a couple > hundred thousand then something else is going crazily wrong. > > I understand your frustration, but there's a lot of instances where > the application just isn't doing things "right" and the OS tries to > hide it as much as psosible. Blowing out somaxconn to chew up a whole > lot of resources seems a bit silly. I'd rather investigate why the > userland application is not servicing the connect queue often enough. > > I've written network services that supported tens of thousands of new > TCP connections a second on a LAN and I never once had to bump > somaxconn past 32767. I'm not saying that it won't apply to your > scenario, I'm just trying to explain that there's likely more going > on. I guess the problem is rather kern.ipc.maxsockets which is only 25600. The name somaxconn is confusing as it specifies the listen queue limit instead of the maximum number of connections as the it suggests. This would also explain the persisting problems Chris described. maxsockets should be bumped up quite a bit by default IMO. How far needs some analysis because there are some dependencies and memory requirements. -- Andre > Adrian > > On 3 October 2012 11:45, wrote: >> Hi everyone. >> >> Actually 65k sockets is incredibly easy to reach. >> >> I manage some servers for a very large website, it currently has several >> http servers clustered to handle daily traffic and this is only dynamic >> content, static has its own servers, databases also have own servers. >> >> We recently started using memcached to cache some queries and we found on >> default server limits sockets were saturated extremely quickly, on the linux >> servers bumping it to a few hundred K solved the issue, wasnt possible on >> bsd. We did manage to get it down to only needing about 20k by setting >> extremely low timeout values. >> >> In addition we had to migrate all our mysql servers from freebsd to debian >> because they were hitting some arbitary OS limit but I could never figure >> out what, sys% usage went through the roof when this limit was hit, issue >> didnt occur on debian. I feel recently freebsd is more focused on desktop's >> and as such developer's never develop for a heavy server usage scenario, and >> I keep coming across hardcoded low limits. As rightly pointed out default >> values now days are useless 128 for somaxconn? maybe ok for a desktop. >> >> Freebsd also has issues with high numbers of cpu cores, very high locking >> overheads, the problem is the modern hardware is focusing on more and more >> cores and as such much more work on a server so a OS has to handle more and >> more processing and data, this includes more bigger connection queues and so >> on. FreeBSD just isnt scaling with more powerful hardware. Also forgetting >> as well DDOS attack scenarios where a high queue size is useful. >> >> I have used FreeBSD since the 4.x days and have been forced to migrate OS on >> several servers as FreeBSD to be blunt couldnt handle the load on those >> servers. It does seem as if developers of the OS are getting out of touch >> in respect to modern hosting enviromnents. I cant tell app developers to >> fix their apps to work on FreeBSD, they dont care, if it works fine on >> windows and linux then the app isnt broken as far as they are concerned. >> The more FreeBSD dev's have this aatitude of not adapting the less machines >> will run the OS. I hate many things about debian but at the end of the day >> I have to use what can handle the load or I lose my job. >> >> I do accept its entirely possible some tunables could fix any issues I have >> come across but believe me I have spent 100s of man hours on issues, and >> tuned everything I could find. >> >> To me this 32767 limit on somaxconn seems restrive and I vote for it been >> bumped to at least 8x that amount as a minimum. A more suitable default >> would probably be around 1024 as well instead of 128. Dead lingering >> connections in timewait etc. all use one of these, and that can very easily >> get into the 1000s. >> >> Chris >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 20:47:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D42B106567A; Wed, 3 Oct 2012 20:47:50 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BEB88FC12; Wed, 3 Oct 2012 20:47:49 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so8894318obb.13 for ; Wed, 03 Oct 2012 13:47:49 -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=N2OoG9ZTWGxkBRNoXbRULHsHN0cV/MrtqSiNO8L24sY=; b=BD2TaC45n5mgF3UycvZcgxRFCJnTGw1e8G36fSG29hBOkjJ5yMrMqiOGLkBZH0XlEM ibz0z5osp/lhrQlhG8bGG6yw6s9wAd0FVxmnxZ3hYasnQYqUxDoWb4fjgJfBvRlMlLFM f2WvZOiy/p1V/Ey1afahWNDK/37OFjbT4NYQE7L0OwoUs305J9yE1Nu7vHwaQUA1jBaF ftET3VmW9AqfEFzLmrk5ImeRPXGkkQtNMOhEYjEmR3br/fbgmjtuS+6srxItUZaUfwvf KeDSPGp7Axz9pQXS076d9lteumzoAPOVug2IOWPbW8l8bmw1XsJCpRB3XbOoH1BSGJZ3 Sr+w== MIME-Version: 1.0 Received: by 10.182.218.37 with SMTP id pd5mr2594898obc.24.1349297269310; Wed, 03 Oct 2012 13:47:49 -0700 (PDT) Received: by 10.76.142.201 with HTTP; Wed, 3 Oct 2012 13:47:49 -0700 (PDT) In-Reply-To: References: <03e101cda197$326dc240$974946c0$@org> Date: Wed, 3 Oct 2012 13:47:49 -0700 Message-ID: From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd@chrysalisnet.org, freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:47:50 -0000 On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd wrote: > Hi, > > somaxconn is the connection queue depth. If it's sitting at a couple > hundred thousand then something else is going crazily wrong. > > I understand your frustration, but there's a lot of instances where > the application just isn't doing things "right" and the OS tries to > hide it as much as psosible. Blowing out somaxconn to chew up a whole > lot of resources seems a bit silly. I'd rather investigate why the > userland application is not servicing the connect queue often enough. > > I've written network services that supported tens of thousands of new > TCP connections a second on a LAN and I never once had to bump > somaxconn past 32767. I'm not saying that it won't apply to your > scenario, I'm just trying to explain that there's likely more going > on. Or the TTL of TCP connections might be too high for the volume of connections received. Someone else on net@ reported that changing this value to more aggressively reap sockets improved performance greatly (at the cost that more connections potentially needing to be reestablished and/or getting dropped on the floor if things go too high volume). But yeah... the listen(2) queue might be too high, or the application might be accept(2)'ing too much and thus the queue is backing up too much. I was merely providing the pointer to "why" things are the way they are. Thanks, Garrett "so many knobs, so little time" Cooper From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 21:04:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96C1E1065672; Wed, 3 Oct 2012 21:04:09 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 74FC08FC12; Wed, 3 Oct 2012 21:04:09 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 18A5A1BC93; Wed, 3 Oct 2012 14:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1349298249; bh=wzIaN+SF54WKw8Y4qq2gzL1kc+MILwoqlPNK3KaqCJs=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=c/Gl1+BbqhRVoGcKSSFp6trF/5UwwSIrEZ28t28Wj9bdsG7UrYv8JFpNgxhN2cokp wlMVI7/mhJfuUtxDJFK1CCC+25hxMbZ30T3UU+WHIbZqGhPVY1u5PT5Iqos9fBU8tO Qv+q7D2Dq/OW3WXnKpmoLXmcWinYOY1sVRg+aK/w= Message-ID: <506CA848.5040604@delphij.net> Date: Wed, 03 Oct 2012 14:04:08 -0700 From: Xin Li Organization: The freeBSD Project User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.7) Gecko/20120830 Thunderbird/10.0.7 MIME-Version: 1.0 To: Garrett Cooper References: <03e101cda197$326dc240$974946c0$@org> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd@chrysalisnet.org, Adrian Chadd , freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 21:04:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/03/12 13:47, Garrett Cooper wrote: > On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd > wrote: >> Hi, >> >> somaxconn is the connection queue depth. If it's sitting at a >> couple hundred thousand then something else is going crazily >> wrong. >> >> I understand your frustration, but there's a lot of instances >> where the application just isn't doing things "right" and the OS >> tries to hide it as much as psosible. Blowing out somaxconn to >> chew up a whole lot of resources seems a bit silly. I'd rather >> investigate why the userland application is not servicing the >> connect queue often enough. >> >> I've written network services that supported tens of thousands of >> new TCP connections a second on a LAN and I never once had to >> bump somaxconn past 32767. I'm not saying that it won't apply to >> your scenario, I'm just trying to explain that there's likely >> more going on. > > Or the TTL of TCP connections might be too high for the volume of > connections received. Someone else on net@ reported that changing > this value to more aggressively reap sockets improved performance > greatly (at the cost that more connections potentially needing to > be reestablished and/or getting dropped on the floor if things go > too high volume). That's a different topic I think. On busy web servers it's fairly typical to have a lot of TCP sockets staying in TIME_WAIT state for extended time and the usual tuning would be to set MSL to about 2 seconds at the expense of sacrificing slow clients who can't make 3-way handshake in time (*), etc. The TTL of IP packet have nothing to do with this though, and our default (64) is saner than many other operating systems. > But yeah... the listen(2) queue might be too high, or the > application might be accept(2)'ing too much and thus the queue is > backing up too much. I was merely providing the pointer to "why" > things are the way they are. Well, not accept'ing fast enough is a big problem and has to be solved. Think about this example: at a shopping center there are a lot of customers waiting for checkout. The right solution is not to draw zigzag lines or to remodel the shopping center's building and create a large "waiting room" in order to increase the capacity of the queue, but to increase the number of cashiers or prioritize simple cases (like, if you have less than 10 items for checkout, go this queue). (*) which is actually not a bad idea because the usual web visitors would just walk away in that case and this can also be used as a leverage for attacks. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQbKhIAAoJEG80Jeu8UPuzcZMH/1yzMaKmgyJhfHL3P05SDUdZ nKx4EEg/4KyA7jkodNzbQONr/icem3uUZ/TnwxTkZ7Aq9Ezg8nqF8RXFXPUqE7V2 H3aptIkRqVt/02SRb1Y3Cd7meqt6ikEQcfQZxT9cFDQWc8BXduyh6J0P6pvaiXSS he8LVeg5SfT1o43lf8q4N6I/mlPmc2EKhzcrxeNwXOL3jqjHJ7NNPjIX8l4cu6a/ g6JvkDwSVyve6L91b7Jrp1y505aYRlAIioIH9CTcYJx/nQMjXFLYEsJA5dley/sw 1c3IilJ8zJFzLzNmjaUF0emY4QcMYX5eA/gododDEXWF+WjZs2Qv+/w1Fu9McKQ= =dCYl -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 22:03:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E970D106566C; Wed, 3 Oct 2012 22:03:49 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0CA8FC14; Wed, 3 Oct 2012 22:03:49 +0000 (UTC) Received: by vbmv11 with SMTP id v11so10980158vbm.13 for ; Wed, 03 Oct 2012 15:03:42 -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=PAWzIXwSoKrlWxZXP2D9CgVl7aG/8g9E6WJOTQImblU=; b=FCWh4IjYUfUgJ0VpPhl4Vicb6eZbGhMgDbpmCvp+KTCOYo5xSPsc2ju1PlEZ0MDqj7 tewuH+1XWOqBvlZt2ZJ9mlG3TTWoqOvrhQDTZGDAalzwZCuoTBzfTQo93yazk0lULZ+T 5K69xHHFyEkWdupFHHZQJkhGxg/3rEBvdLoDLfdU1FN0AIsz2MC2UCr8BKCJsliMvUgF 3P4zvn/q50MiDAzAsu0TwRtJ690KbGbLtLSISPuPAXktNMZ1qIuXq1O6i5+EGlPLIybj 2Hk10foA8mpaK2nRpva8Xdq0VgQqj+uuieVCLlhTNXc4XG5mZU1wTulCZRwQjoTtYG3G RUZg== MIME-Version: 1.0 Received: by 10.220.154.6 with SMTP id m6mr1890354vcw.51.1349301822788; Wed, 03 Oct 2012 15:03:42 -0700 (PDT) Received: by 10.58.207.114 with HTTP; Wed, 3 Oct 2012 15:03:42 -0700 (PDT) In-Reply-To: <506CA848.5040604@delphij.net> References: <03e101cda197$326dc240$974946c0$@org> <506CA848.5040604@delphij.net> Date: Wed, 3 Oct 2012 18:03:42 -0400 Message-ID: From: Ryan Stone To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , freebsd@chrysalisnet.org, Adrian Chadd , freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 22:03:50 -0000 >> Or the TTL of TCP connections might be too high for the volume of >> connections received. Someone else on net@ reported that changing >> this value to more aggressively reap sockets improved performance >> greatly (at the cost that more connections potentially needing to >> be reestablished and/or getting dropped on the floor if things go >> too high volume). > > That's a different topic I think. On busy web servers it's fairly > typical to have a lot of TCP sockets staying in TIME_WAIT state for > extended time and the usual tuning would be to set MSL to about 2 > seconds at the expense of sacrificing slow clients who can't make > 3-way handshake in time (*), etc. The TTL of IP packet have nothing > to do with this though, and our default (64) is saner than many other > operating systems. Presumably RTT was meant here instead of TTL. From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 22:27:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53E9C1065670; Wed, 3 Oct 2012 22:27:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7838FC12; Wed, 3 Oct 2012 22:27:20 +0000 (UTC) Received: by ieak10 with SMTP id k10so18438684iea.13 for ; Wed, 03 Oct 2012 15:27:20 -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=w0X+gp4FAQVUoQwjPn0BQAU+z5Ked1yBnKOS3Egs0nw=; b=s8zLFimjPDAt/3n3WzAgj0ZotdfofuDS4mMChqVb2DyWjBNChRnqML13FmhctMVnV+ B1m9jv+bEhDE4ntNnKfU97s5qlSQnwG72GzdjX5/N33plMPdHSLF1prFzoMKw8uO2iqA Z8o1CBJ/xiYUrAhI9dcyN1Gv755yvZOjnrT2B4bxUFZgf9tUu7ih5vn5faCdCIKTVKvu up9iPNdSjQuOQkrbUc4ySw/A7UFUhh9KyLFdJ21qYJdmQv5Fw/N3f64hjoQ2UqpBYW5p hioDSN3f2mrtRFz+Ia2XY7FGDyGyoMAFVGDIv/Fq5VsuzmaqrinvB5SEyMVzGeTXAK2C OBQA== MIME-Version: 1.0 Received: by 10.50.197.231 with SMTP id ix7mr3417781igc.54.1349303240239; Wed, 03 Oct 2012 15:27:20 -0700 (PDT) Received: by 10.64.51.39 with HTTP; Wed, 3 Oct 2012 15:27:20 -0700 (PDT) In-Reply-To: References: <03e101cda197$326dc240$974946c0$@org> <506CA848.5040604@delphij.net> Date: Wed, 3 Oct 2012 15:27:20 -0700 Message-ID: From: Garrett Cooper To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd@chrysalisnet.org, Adrian Chadd , freebsd-current@freebsd.org, d@delphij.net Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 22:27:21 -0000 On Wed, Oct 3, 2012 at 3:03 PM, Ryan Stone wrote: >>> Or the TTL of TCP connections might be too high for the volume of >>> connections received. Someone else on net@ reported that changing >>> this value to more aggressively reap sockets improved performance >>> greatly (at the cost that more connections potentially needing to >>> be reestablished and/or getting dropped on the floor if things go >>> too high volume). >> >> That's a different topic I think. On busy web servers it's fairly >> typical to have a lot of TCP sockets staying in TIME_WAIT state for >> extended time and the usual tuning would be to set MSL to about 2 >> seconds at the expense of sacrificing slow clients who can't make >> 3-way handshake in time (*), etc. The TTL of IP packet have nothing >> to do with this though, and our default (64) is saner than many other >> operating systems. > > Presumably RTT was meant here instead of TTL. Yes, I screwed up my nomenclature and TIME_WAIT was what I was trying to note. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 09:22:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE24B1065677 for ; Thu, 4 Oct 2012 09:22:06 +0000 (UTC) (envelope-from boris.t.ru@mail.ru) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id 434088FC25 for ; Thu, 4 Oct 2012 08:06:37 +0000 (UTC) Received: from smtp18.mail.ru (smtp18.mail.ru [94.100.176.155]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id A3133A5EF05 for ; Thu, 4 Oct 2012 09:53:48 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=FUnlmNu/lk9EP80kvs5OXE1ic0StqluxekuGi8+qijc=; b=2CGjFIgqzBOluWgLyowHpSGGuoeXesjK7/b1G/phgrOwITjzljYG0hTenmKgggfqXnoTBteNbXqN9ciif7BX5lJszcdVHWcU+Opnowz340cJj7RYf7VTmqHrgsrJ5JQA; Received: from [82.112.40.144] (port=19271 helo=elephant.dev) by smtp18.mail.ru with esmtpa (envelope-from ) id 1TJeNQ-0002Rc-Rh for current@freebsd.org; Thu, 04 Oct 2012 09:53:41 +0400 Message-ID: <506D2468.90703@mail.ru> Date: Thu, 04 Oct 2012 11:53:44 +0600 From: Talovikov Boris Aleksandrovich User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: Subject: fusefs-sshfs crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 09:22:07 -0000 root@hummingbird:boris# uname -a FreeBSD hummingbird.dev 10.0-CURRENT FreeBSD 10.0-CURRENT #41 r241078: Mon Oct 1 21:18:05 YEKT 2012 root@hummingbird.dev:/usr/obj/usr/src/sys/HUMMINGBIRD i386 root@hummingbird:boris# tail /var/log/messages ... Oct 4 11:29:04 hummingbird su: boris to root on /dev/pts/1 root@hummingbird:boris# sshfs boris@elephant:/home/boris/ /mnt/ boris@elephant.localnetwork's password: root@hummingbird:boris# ls /mnt ls: /mnt: Bad file descriptor root@hummingbird:boris# tail /var/log/messages ... Oct 4 11:29:04 hummingbird su: boris to root on /dev/pts/1 Oct 4 11:29:46 hummingbird kernel: pid 593 (sshfs), uid 0: exited on signal 11 (core dumped) root@hummingbird:boris# mount -lv ... /dev/fuse0 on /mnt (fusefs.sshfs, local, synchronous, fsid 04ff00eded000000) root@hummingbird:boris# umount -f /mnt root@hummingbird:boris# gdb -e /usr/local/bin/sshfs -c /sshfs.core 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 "i386-marcel-freebsd". Core was generated by `sshfs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libfuse.so.2...done. Loaded symbols for /usr/local/lib/libfuse.so.2 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libintl.so.9...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/local/lib/libpcre.so.1...done. Loaded symbols for /usr/local/lib/libpcre.so.1 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0804ecd5 in ?? () [New Thread 2902a300 (LWP 100808/sshfs)] [New Thread 2902a080 (LWP 100807/sshfs)] [New Thread 28c03580 (LWP 100806/sshfs)] [New Thread 28c03080 (LWP 100344/sshfs)] (gdb) bt #0 0x0804ecd5 in ?? () #1 0x08056b78 in ?? () #2 0x00000000 in ?? () #3 0x28c31a30 in ?? () #4 0x281a5dde in __pthread_mutex_lock (mutex=0xa5a5a5a5) at /usr/src/lib/libthr/thread/thr_mutex.c:436 #5 0x0805001f in ?? () #6 0xa5a5a5a5 in ?? () #7 0x000189c7 in ?? () #8 0x00000000 in ?? () #9 0x2809aa40 in .got () from /usr/local/lib/libfuse.so.2 #10 0x29008000 in ?? () #11 0xbf8fce90 in ?? () #12 0xbf8fcc98 in ?? () #13 0x0805267f in ?? () #14 0x08056cf8 in ?? () #15 0xbf8fce90 in ?? () #16 0xbf8fccb8 in ?? () #17 0x00000000 in ?? () #18 0x00000000 in ?? () #19 0xa5a5a5a5 in ?? () #20 0xbf8fccc8 in ?? () #21 0x08052ecd in ?? () #22 0x2982a100 in ?? () #23 0xbf8fcd28 in ?? () #24 0xbf8fcdbc in ?? () #25 0x2807127f in ?? () #26 0x29808020 in ?? () #27 0x2809aa40 in .got () from /usr/local/lib/libfuse.so.2 #28 0xbf8fccc8 in ?? () #29 0xffffffdd in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0xbf8fccf8 in ?? () #33 0x2807f451 in fuse_fs_fgetattr (fs=0x2982a100, path=0xbf8fcd28 "", buf=0xbf8fcdbc, fi=0x2807127f) at fuse.c:1555 Sorry bad speak English. From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 10:53:22 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21BD9106566B for ; Thu, 4 Oct 2012 10:53:22 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id C93718FC0A for ; Thu, 4 Oct 2012 10:53:21 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 1518714E83B5; Thu, 4 Oct 2012 12:53:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k-w4Zu4lQX05; Thu, 4 Oct 2012 12:53:20 +0200 (CEST) Received: from [192.168.1.106] (5403A6BE.catv.pool.telekom.hu [84.3.166.190]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 9702B14E83AD; Thu, 4 Oct 2012 12:53:20 +0200 (CEST) Message-ID: <506D6AA3.7010504@FreeBSD.org> Date: Thu, 04 Oct 2012 12:53:23 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Oleg Moskalenko Subject: [HEADSUP] Upcoming GNU sort removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 10:53:22 -0000 Hi, it has been more than 3 months ago that BSD sort became default in HEAD and no serious complaints have been raised against it since then so I plan to permanently remove GNU sort from head in the next days. If you have any objection, please raise it now. Gabor From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 14:50:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 469C01065678; Thu, 4 Oct 2012 14:50:59 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 13F968FC08; Thu, 4 Oct 2012 14:50:59 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q94EopEP053509; Thu, 4 Oct 2012 07:50:51 -0700 (PDT) (envelope-from freebsd@penx.com) From: Dennis Glatting To: Gabor Kovesdan In-Reply-To: <506D6AA3.7010504@FreeBSD.org> References: <506D6AA3.7010504@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 04 Oct 2012 07:50:50 -0700 Message-ID: <1349362250.83035.3.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q94EopEP053509 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@penx.com Cc: Oleg Moskalenko , current@freebsd.org Subject: Re: [HEADSUP] Upcoming GNU sort removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 14:50:59 -0000 On Thu, 2012-10-04 at 12:53 +0200, Gabor Kovesdan wrote: > Hi, > > it has been more than 3 months ago that BSD sort became default in HEAD > and no serious complaints have been raised against it since then so I > plan to permanently remove GNU sort from head in the next days. If you > have any objection, please raise it now. > Initially I had problems with multi TB files (--unique, five to ten files) but I haven't had to do that in two(?) months. I will be getting back to that project in a month or so. It challanges a system's resources. :) From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 16:16:35 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC55D1065679 for ; Thu, 4 Oct 2012 16:16:35 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 79E8D8FC17 for ; Thu, 4 Oct 2012 16:16:35 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 2FD6D14E83BF; Thu, 4 Oct 2012 18:16:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A3Z6V0YuMzDp; Thu, 4 Oct 2012 18:16:26 +0200 (CEST) Received: from [192.168.1.106] (5403A6BE.catv.pool.telekom.hu [84.3.166.190]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id A141814E83B9; Thu, 4 Oct 2012 18:16:26 +0200 (CEST) Message-ID: <506DB65D.7000009@FreeBSD.org> Date: Thu, 04 Oct 2012 18:16:29 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Dennis Glatting References: <506D6AA3.7010504@FreeBSD.org> <1349362250.83035.3.camel@btw.pki2.com> In-Reply-To: <1349362250.83035.3.camel@btw.pki2.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Oleg Moskalenko , current@freebsd.org Subject: Re: [HEADSUP] Upcoming GNU sort removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 16:16:35 -0000 Em 04-10-2012 16:50, Dennis Glatting escreveu: > On Thu, 2012-10-04 at 12:53 +0200, Gabor Kovesdan wrote: >> > Hi, >> > >> > it has been more than 3 months ago that BSD sort became default in HEAD >> > and no serious complaints have been raised against it since then so I >> > plan to permanently remove GNU sort from head in the next days. If you >> > have any objection, please raise it now. >> > > Initially I had problems with multi TB files (--unique, five to ten > files) but I haven't had to do that in two(?) months. I will be getting > back to that project in a month or so. > > It challanges a system's resources. :) And did it go much better with base GNU sort? It's quite an extreme case... :) Multi GB is also rare not speaking about multi TB... Gabor From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 16:26:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F01BE1065670 for ; Thu, 4 Oct 2012 16:26:24 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id A9E548FC08 for ; Thu, 4 Oct 2012 16:26:24 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so2038989iea.13 for ; Thu, 04 Oct 2012 09:26:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6FXpO5xyQUvoSCFL1+pwgZmQdiL8n1xxIEdClEI20MQ=; b=Yq9e+xEzGTU2htROSogW+XwqGH1u+NHfb0ZFMZplWelj4NapLqMkBt4kuisnSGhejX MwQURLcS3RSgLPicfL6w002IYG/PEqnqr71TKzQCT//00KuXwaN4NbSd8J9pyQHU+f15 yOezPfmDBtt8DLKEvrwoF5NI9/A0XpQbzKN7gzQmGTuSY0/zeL5ySx1yAFVPyhLR6ra6 6lehuQmHpV0T3IOzEh5UvfN0dsy5uexFlM+GKFIEn72Xz8KJ9BFj3AzrdBgNw05dRziv TmxUFtf3NAqTvPpgjK3GeBGcPfZC/rVUVSK2/pJDZvfYmA2HU/cT6af2DefO/9oqzlDw OpLA== MIME-Version: 1.0 Received: by 10.50.237.70 with SMTP id va6mr13527279igc.8.1349367983739; Thu, 04 Oct 2012 09:26:23 -0700 (PDT) Received: by 10.64.49.67 with HTTP; Thu, 4 Oct 2012 09:26:23 -0700 (PDT) X-Originating-IP: [93.221.172.216] In-Reply-To: <506DB65D.7000009@FreeBSD.org> References: <506D6AA3.7010504@FreeBSD.org> <1349362250.83035.3.camel@btw.pki2.com> <506DB65D.7000009@FreeBSD.org> Date: Thu, 4 Oct 2012 18:26:23 +0200 Message-ID: From: "C. P. Ghost" To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlu1wod4fieN4J7/bZA/Cl9X9TziDooNNbj9s3Peui5G4XKcdD3fPJdkgfQh6MS/2qaes3o Cc: current@freebsd.org Subject: Re: [HEADSUP] Upcoming GNU sort removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 16:26:25 -0000 On Thu, Oct 4, 2012 at 6:16 PM, Gabor Kovesdan wrote: > Em 04-10-2012 16:50, Dennis Glatting escreveu: >> On Thu, 2012-10-04 at 12:53 +0200, Gabor Kovesdan wrote: >>> > Hi, >>> > >>> > it has been more than 3 months ago that BSD sort became default in HEAD >>> > and no serious complaints have been raised against it since then so I >>> > plan to permanently remove GNU sort from head in the next days. If you >>> > have any objection, please raise it now. >>> > >> Initially I had problems with multi TB files (--unique, five to ten >> files) but I haven't had to do that in two(?) months. I will be getting >> back to that project in a month or so. >> >> It challanges a system's resources. :) > > And did it go much better with base GNU sort? It's quite an extreme > case... :) Multi GB is also rare not speaking about multi TB... Yup. Plus nothing prevents us from using GNU sort from ports for those extremely rare cases. AFAICS, BSD sort is great for most of the workloads and is a perfect replacement for GNU sort. Good work! BTW, its good to see BSD-licensed tools gradually replacing GNU tools in base. Though I'd have really preferred to see resources directed towards getting XEN/Dom0 support to FreeBSD/amd64. This really needs some love, IMHO. ;-) > Gabor Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 17:46:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62D0F1065670 for ; Thu, 4 Oct 2012 17:46:27 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1AA358FC0C for ; Thu, 4 Oct 2012 17:46:26 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so1041621obb.13 for ; Thu, 04 Oct 2012 10:46:26 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Gfrefs/NUBI++xjJmU4tbbfMffUmOxr+diyd9VJbVXo=; b=eGy0ZNxvYwqiK3FPMhPGc+dvTAeeEZ870ePQv/xL1JB5SvMU/j1g+2LUCLq+jrUh7q d0xjpzyMA5DsyjcMQStjrUTvk9exj4HdKt6pKO5gD9cUArPAYnl/UkI3BJc4qD5UN5qZ Z2LmSvopPrx37UOyEu7CKe97cuaJnQauGWY4vP6jagoGlO2dSPMXgXSyEsj9JXtQ4VTP OUj3xqFKnKrS5yoaV0/AEA7X50/CIi9M1cc03gKz9GG97CsHOWpTO0lUgwNx0zrw6u1u TvZ85lfZ2wKJEu6OLg3aVmAw412wYydrK6YxG71xOrsiy6os4Y/249/DBTDy4xOekJWZ +76Q== Received: by 10.182.40.6 with SMTP id t6mr4985895obk.100.1349372786463; Thu, 04 Oct 2012 10:46:26 -0700 (PDT) Received: from [192.168.1.62] ([209.194.41.80]) by mx.google.com with ESMTPS id q6sm5551184oec.7.2012.10.04.10.46.25 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 10:46:25 -0700 (PDT) Message-ID: <506DCB6B.3030403@gmail.com> Date: Thu, 04 Oct 2012 12:46:19 -0500 From: Chuck Burns User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <506D6AA3.7010504@FreeBSD.org> <1349362250.83035.3.camel@btw.pki2.com> <506DB65D.7000009@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [HEADSUP] Upcoming GNU sort removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 17:46:27 -0000 On 10/4/2012 11:26 AM, C. P. Ghost wrote: > BTW, its good to see BSD-licensed tools gradually replacing GNU > tools in base. Though I'd have really preferred to see resources > directed towards getting XEN/Dom0 support to FreeBSD/amd64. > This really needs some love, IMHO. ;-) > >> Gabor > > Thanks, > -cpghost. > Then give it some love yourself! No one is stopping you! :) -- Chuck Burns From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 18:10:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42BD51065670 for ; Thu, 4 Oct 2012 18:10:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id ECE148FC1C for ; Thu, 4 Oct 2012 18:10:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4IABrQbVCDaFvO/2dsb2JhbABFhg+3bAQEghGCSoELAg0ZAl+IGJZ6jkOSe4EhjyiBEgOVaZAsgwmBew X-IronPort-AV: E=Sophos;i="4.80,537,1344225600"; d="scan'208";a="182039757" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 04 Oct 2012 14:10:11 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A32DAB3F36 for ; Thu, 4 Oct 2012 14:10:11 -0400 (EDT) Date: Thu, 4 Oct 2012 14:10:11 -0400 (EDT) From: Rick Macklem To: FreeBSD-Current Message-ID: <1597538279.1739903.1349374211640.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Subject: svn MFC to stable/8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:10:13 -0000 Hi, Hopefully someone familiar with svn can help. When I try to MFC a kernel change to stable/8, it works, but I end up with tons of mergeinfo. (It looks like every directory under sys.) Does this matter or is there a trick to avoid this? Thanks in advance for any help, rick ps: I seem to MFC fine to stable/9. I only see this for stable/8. From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 16:41:04 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FE93106564A for ; Thu, 4 Oct 2012 16:41:04 +0000 (UTC) (envelope-from levitch@iglou.com) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5F28FC12 for ; Thu, 4 Oct 2012 16:41:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=xUQq9vDfoz60BPoxduaCe/xbWexw9DnxPjj7CLXDbJk=; b=EXEr8Y8JbYYtbNDMO2oE0dOL8lSz0Xqs2cmevoix3bwnEAgVfYIHjHyHMQprqVdpWiC2FCXmeuU0GjGiKiTQo/s3ojn26Shvf1YXnxBulIH/0IwCyWJVlKdib4eJzp9+1jdLpCTcHRPJxAfm0xV4RdkMcnrOLZK9glyDf4hFan0=; Received: from iglou1.iglou.com ([192.107.41.3]:51662 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1TJo7j-0007l3-VA by authid with igloumta_auth for current@FreeBSD.org; Thu, 04 Oct 2012 12:18:07 -0400 Received: from shell1.iglou.com ([192.107.41.17]:50647 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1TJo7j-0003Pz-JR for current@FreeBSD.org; Thu, 04 Oct 2012 12:18:07 -0400 Date: Thu, 4 Oct 2012 12:18:07 -0400 (EDT) From: Darrel X-X-Sender: levitch@shell1 To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-Mailman-Approved-At: Thu, 04 Oct 2012 18:10:23 +0000 Cc: Subject: memory warnings r240891 | dmesgg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 16:41:04 -0000 Hello, Swap was created twice on this 9.0 release candidate install- once as part of zfs and also as encrypted hard drive space. (30) @ 12:01:50> swapinfo Device 1K-blocks Used Avail Capacity /dev/zvol/bigD/swap 4194304 0 4194304 0% /dev/gpt/swap0.eli 3145728 0 3145728 0% /dev/gpt/swap1.eli 3145728 0 3145728 0% Total 10485760 0 10485760 0% Since then, all references to OpenBSD Packet Filter have been removed and the system is now r240891 ************************************************************* FreeBSD 10.0-CURRENT #1 r240891: Tue Sep 25 00:51:03 EDT 2012 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD Sempron(tm) Processor 2800+ (1599.86-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20fc2 Family = 0xf Model = 0x2c Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 real memory = 1073741824 (1024 MB) avail memory = 937144320 (893 MB ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded hpt27xx: no controller detected. GEOM_ELI: Device gpt/swap0.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: software GEOM_ELI: Device gpt/swap1.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: software warning: total configured swap (2621440 pages) exceeds maximum recommended amount (1852656 pages). warning: increase kern.maxswzone or reduce amount of swap. ************************************************************* Apparently kern.maxswzone is currently equal to 0. How might I tweak it just enough to fix this? Also, I have been disregarding the prefetch notice about zfs. I have not seen any adverse results. Darrel From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 18:17:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99D16106566B for ; Thu, 4 Oct 2012 18:17:17 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0C48FC1A for ; Thu, 4 Oct 2012 18:17:17 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q94IH0Hl007620; Thu, 4 Oct 2012 11:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1349374621; bh=fSQsIqZMbdtAT5DuGzeZ+yqGvQK7GiE09jMiQvKzAR8=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Date:Message-ID:Mime-Version:Content-Transfer-Encoding; b=lJJDtc/ix2Qiw88S2HYEfNnmBHMBJUHGH/sGibhqaNp7Fhn0j9mnvRkUummdTmwwH P7PztWPddIviwbQVuE/gzFUr8RZ6DgZRO1Y0XGQnlOhOjQthqeOXnisWw4fXFwdfKw gfaJiaSw/TLkPbGw5tL36628oJdGZLrBoD0/I5QY= From: Sean Bruno To: Rick Macklem In-Reply-To: <1597538279.1739903.1349374211640.JavaMail.root@erie.cs.uoguelph.ca> References: <1597538279.1739903.1349374211640.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset="UTF-8" Date: Thu, 04 Oct 2012 11:16:59 -0700 Message-ID: <1349374619.5234.0.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 374620005 Cc: FreeBSD-Current Subject: Re: svn MFC to stable/8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:17:17 -0000 On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote: > Hi, > > Hopefully someone familiar with svn can help. When I try to MFC > a kernel change to stable/8, it works, but I end up with tons of > mergeinfo. (It looks like every directory under sys.) > > Does this matter or is there a trick to avoid this? > > Thanks in advance for any help, rick > ps: I seem to MFC fine to stable/9. I only see this for stable/8. > _______________________________________________ Can you post your attempted svn merge command? Sean From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 18:35:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2BA2106566C; Thu, 4 Oct 2012 18:35:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5F83B8FC08; Thu, 4 Oct 2012 18:35:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAOvVbVCDaFvO/2dsb2JhbABFhg+6BYIgAQEFI1YbGAICDRkCWRmIBaU3kn6BIY0Zgg+BEgOVaZAsgwmBew X-IronPort-AV: E=Sophos;i="4.80,537,1344225600"; d="scan'208";a="182044519" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 04 Oct 2012 14:35:47 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 481DCB4032; Thu, 4 Oct 2012 14:35:47 -0400 (EDT) Date: Thu, 4 Oct 2012 14:35:47 -0400 (EDT) From: Rick Macklem To: sbruno@freebsd.org Message-ID: <1605359247.1742784.1349375747279.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1349374619.5234.0.camel@powernoodle.corp.yahoo.com> 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 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: FreeBSD-Current Subject: Re: svn MFC to stable/8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:35:48 -0000 Sean Bruno wrote: > On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote: > > Hi, > > > > Hopefully someone familiar with svn can help. When I try to MFC > > a kernel change to stable/8, it works, but I end up with tons of > > mergeinfo. (It looks like every directory under sys.) > > > > Does this matter or is there a trick to avoid this? > > > > Thanks in advance for any help, rick > > ps: I seem to MFC fine to stable/9. I only see this for stable/8. > > _______________________________________________ > > Can you post your attempted svn merge command? > > Sean Same as I've always used. When at the top of an updated stable/8 checkout tree... # svn merge -c240720 svn+ssh://rmacklem@svn.freebsd.org/base/head/sys sys Also, after I reverse merge via: # svn merge -c-240720 svn+ssh://rmacklem@svn.freebsd.org/base/head/sys sys # svn status . M sys M sys/dev/sound - so I end up doing an "rm -r" of the tree, followed by a fresh checkout. (Before, the status wouldn't see anything modified after I would reverse the merge out.) rick From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 18:42:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2169E1065674 for ; Thu, 4 Oct 2012 18:42:22 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE36C8FC0A for ; Thu, 4 Oct 2012 18:42:21 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1022903pbb.13 for ; Thu, 04 Oct 2012 11:42:21 -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=RRlMY8gRJPOQ57MIMSnFH+3r94s/VaNh9wZK+TbyJck=; b=cEzs5w6CAPXN2c3vgBgk7j+ZXslrsjnceSAOFrNDadx4ckgHQ1SiwZWaRnQ54OGdB4 x+V/Qb5x/z7aILWvwPXx5auOwftlHNqsAAOG8EbOn0NlfJ8nPJPsu0jM+LZoTPmncuib sGvjrrYCnl126FG7SMexbVL0KyDd43sNZLddQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=RRlMY8gRJPOQ57MIMSnFH+3r94s/VaNh9wZK+TbyJck=; b=VETHCdzxZ/abyCCLYM7K3zTIYMn7KwNDLxxVPsF6V36otrgeD6M8yRqmT2GywqAwHR Y8pw+VpAPkRSA2gDS6bDmCfoFiSnujzopSJdZYKlhZIWL9X0Idc526KeRDKW30LUKOrW o29i3xOy85HrNAZm+W8hQwYj5pG+x589Rs8IFjc3m6MAEJZYy2FzlCQY45y0SyqKxYAO yYkdqCLfJlh56tfvXFn7CZ5AaPrpMNqaK9PD0oXFO43/3utp//Fkgtr6A0ErKqqPl429 TGBJHw2bbgpa0TdJOP5jlrKylvxh3fUH2TE+8LArTDaDlRkrIvEwCMLzkszzhY6eI0f8 DlMQ== Received: by 10.68.242.231 with SMTP id wt7mr24051120pbc.99.1349376141336; Thu, 04 Oct 2012 11:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.190.164 with HTTP; Thu, 4 Oct 2012 11:41:51 -0700 (PDT) In-Reply-To: <1605359247.1742784.1349375747279.JavaMail.root@erie.cs.uoguelph.ca> References: <1349374619.5234.0.camel@powernoodle.corp.yahoo.com> <1605359247.1742784.1349375747279.JavaMail.root@erie.cs.uoguelph.ca> From: Eitan Adler Date: Thu, 4 Oct 2012 14:41:51 -0400 Message-ID: To: Rick Macklem Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmovlTPD8zEbkg+Q97eIbRND/bcq4i175DiztCJCGuCIkWr/IEP2F2TzTei6sgg3K80esh6 Cc: FreeBSD-Current Subject: Re: svn MFC to stable/8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:42:22 -0000 On 4 October 2012 14:35, Rick Macklem wrote: > Sean Bruno wrote: >> On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote: >> > Hi, >> > >> > Hopefully someone familiar with svn can help. When I try to MFC >> > a kernel change to stable/8, it works, but I end up with tons of >> > mergeinfo. (It looks like every directory under sys.) >> > >> > Does this matter or is there a trick to avoid this? >> > >> > Thanks in advance for any help, rick >> > ps: I seem to MFC fine to stable/9. I only see this for stable/8. >> > _______________________________________________ >> >> Can you post your attempted svn merge command? >> >> Sean > Same as I've always used. When at the top of an updated stable/8 > checkout tree... > # svn merge -c240720 svn+ssh://rmacklem@svn.freebsd.org/base/head/sys sys > > Also, after I reverse merge via: > # svn merge -c-240720 svn+ssh://rmacklem@svn.freebsd.org/base/head/sys sys > # svn status . > M sys > M sys/dev/sound > - so I end up doing an "rm -r" of the tree, followed by a fresh checkout. > (Before, the status wouldn't see anything modified after I would reverse > the merge out.) FYI you could just do svn revert -R, no need for rm -r svn merge -c240720 svn+ssh://svn.freebsd.org/base/head/sys stable8/sys worked for me. Note that lack of a '-' after the 'c' from 'svn help merge': If ARG is negative this is like -r ARG:ARG-1 -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 18:51:26 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D6961065675 for ; Thu, 4 Oct 2012 18:51:26 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 247F08FC17 for ; Thu, 4 Oct 2012 18:51:26 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:7107:bef8:8938:7a33]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id DFE144AC31; Thu, 4 Oct 2012 22:51:24 +0400 (MSK) Date: Thu, 4 Oct 2012 22:51:19 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <13310645740.20121004225119@serebryakov.spb.ru> To: Marek Salwerowicz In-Reply-To: <506C8F4F.3040703@wp.pl> References: <80840563.20120920002200@serebryakov.spb.ru> <506C8F4F.3040703@wp.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org Subject: Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:51:26 -0000 Hello, Marek. You wrote 3 =EE=EA=F2=FF=E1=F0=FF 2012 =E3., 23:17:35: >> atrtc0: port 0x70-0x71 on acpi0 MS> still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host MS> Do you have any solution? In my case it was local patch for exotic embedded chipset... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 19:31:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCEBF1065672 for ; Thu, 4 Oct 2012 19:31:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B2F8E8FC16 for ; Thu, 4 Oct 2012 19:31:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D8A48B946; Thu, 4 Oct 2012 15:31:32 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 4 Oct 2012 14:57:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <1597538279.1739903.1349374211640.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1597538279.1739903.1349374211640.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201210041457.09340.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Oct 2012 15:31:32 -0400 (EDT) Cc: Rick Macklem Subject: Re: svn MFC to stable/8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 19:31:34 -0000 On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote: > Hi, > > Hopefully someone familiar with svn can help. When I try to MFC > a kernel change to stable/8, it works, but I end up with tons of > mergeinfo. (It looks like every directory under sys.) > > Does this matter or is there a trick to avoid this? > > Thanks in advance for any help, rick > ps: I seem to MFC fine to stable/9. I only see this for stable/8. Someone screwed up the mergeinfo on stable/8/sys/dev due to svn 1.6 not working well with newer merges from 1.7. The simplest solution is to just update your client to svn 1.7. Otherwise, you can commit what you have now with 1.6. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 19:51:11 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A0E810656C0 for ; Thu, 4 Oct 2012 19:51:11 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5033B8FC1C for ; Thu, 4 Oct 2012 19:51:11 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so2710866iea.13 for ; Thu, 04 Oct 2012 12:51:10 -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=xyuyfPaZhj+a28oCIsvz2GXFPtduZNzx5FCuPpn1vGc=; b=qrHheT6A97sVHaGl/xpPLaeuzel/pXOLsiztAY85lPRig6ZybnNXly1C7vGJR4t3Fx C2ZCjyAjgcpsjgwvNSfzn9FNhwrkto2+1qg+PeAcfM7KGdDeNDRYnQSBNPKAyKB3Jn8d VvqnFm+FZi33JqnZYNIO0G/rMhg5Qvtzn4YoTVHe0FJOzhFZLVa4DWUE3CI4a/cnEXy2 VYPtNPQCYrNeGKME8xAeA9nLE7Yp2U1KyICsKTODMt2/iqzr/3egYseSZKKcEHhwynL+ 17gGIh5wLTswS3g111iah2ixgDo+H7GukP5nR/HAtDHKUSvKl7zRm77r3Q8qTmRIpqs+ iEcw== MIME-Version: 1.0 Received: by 10.50.5.180 with SMTP id t20mr6627354igt.31.1349380269841; Thu, 04 Oct 2012 12:51:09 -0700 (PDT) Received: by 10.64.81.17 with HTTP; Thu, 4 Oct 2012 12:51:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Oct 2012 23:51:09 +0400 Message-ID: From: Sergey Kandaurov To: Darrel Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: memory warnings r240891 | dmesgg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 19:51:11 -0000 On 4 October 2012 20:18, Darrel wrote: > Hello, > > Swap was created twice on this 9.0 release candidate install- once as > part of zfs and also as encrypted hard drive space. > > (30) @ 12:01:50> swapinfo > Device 1K-blocks Used Avail Capacity > /dev/zvol/bigD/swap 4194304 0 4194304 0% > /dev/gpt/swap0.eli 3145728 0 3145728 0% > /dev/gpt/swap1.eli 3145728 0 3145728 0% > Total 10485760 0 10485760 0% [...] > ************************************************************* > FreeBSD 10.0-CURRENT #1 r240891: Tue Sep 25 00:51:03 EDT 2012 > [...] > real memory = 1073741824 (1024 MB) > avail memory = 937144320 (893 MB [...] > > warning: total configured swap (2621440 pages) exceeds maximum > recommended amount (1852656 pages). > > warning: increase kern.maxswzone or reduce amount of swap. > > ************************************************************* > > Apparently kern.maxswzone is currently equal to 0. How might I tweak it > just enough to fix this? So, reduce amount of swap :) This is because kernel needs some memory to manage swap too. Currently for amd64 this roughly reduces to the following rule (My apologies in advance for the extra simplification): 100MB RAM per 800MB swap space. So, with your current amount of RAM (893MB) it is recommended to setup no more than 7144 MB of swap. [1] [1] Let's look at vm/swap_pager.c:swapon_check_swzone(npages). Here npages is the total swap pages you want to setup. The warning will trigger if (npages > maxpages / 2) becomes true. maxpages is the maximum pages the system can use for swap management. It is calculated as: maxpages = uma_zone_get_max(swap_zone) * SWAP_META_PAGES; By default SWAP_META_PAGES is 32 on amd64, and swap_zone limit calculates as available memory pages in system divided by two (assuming that maxswzone is zero (by default on amd64) and cannot further affect the limit). So that with X total pages in system, the maximum Y swap pages you are advised to have is: Y = X * SWAP_META_PAGES / 2 / 2, or X * 8 (on amd64). -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 20:24:12 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7FD91065670 for ; Thu, 4 Oct 2012 20:24:12 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id 55C128FC0C for ; Thu, 4 Oct 2012 20:24:12 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 16765 invoked from network); 4 Oct 2012 22:24:10 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1349382250; bh=fFHIzpWSZqcAB+DLLg+OLopNF4NoVPOiK+Xv1VVCPnY=; h=From:To:CC:Subject; b=gSbYCVgm+TwyGgTiHQ5A3uLOl3nDCdJVzOeZMWUnyrzUgz/3zVc1s/NOFBPuScqai EDv7hG/e/HfshPBCQDDDp1J+pCdMhZwZXg9bA5fO0XAlsSN9JXDbGY9UmF6smRVoGw u1D4HOmuL4aHBA3FZxl7svbFuY5hzZrisvPoNHDw= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 4 Oct 2012 22:24:10 +0200 Message-ID: <506DF061.4080403@wp.pl> Date: Thu, 04 Oct 2012 22:24:01 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: lev@FreeBSD.org References: <80840563.20120920002200@serebryakov.spb.ru> <506C8F4F.3040703@wp.pl> <13310645740.20121004225119@serebryakov.spb.ru> In-Reply-To: <13310645740.20121004225119@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121004-0, 2012-10-04), Outbound message X-Antivirus-Status: Clean X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [wWNk] Cc: freebsd-current@FreeBSD.org Subject: Re: [SPAM]Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 20:24:12 -0000 W dniu 2012-10-04 20:51, Lev Serebryakov pisze: > Hello, Marek. > You wrote 3 îêòÿáðÿ 2012 ã., 23:17:35: > >>> atrtc0: port 0x70-0x71 on acpi0 > MS> still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host > MS> Do you have any solution? > In my case it was local patch for exotic embedded chipset... Can you send me the patch so I can have a look if I don't use the same chipset ? Regards, -- Marek Salwerowicz From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 20:46:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80FB41065673; Thu, 4 Oct 2012 20:46:17 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id B87C18FC12; Thu, 4 Oct 2012 20:46:16 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q94Kk7cA098561; Thu, 4 Oct 2012 14:46:08 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) 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 q94Kk4d9075306; Thu, 4 Oct 2012 14:46:04 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Marek Salwerowicz In-Reply-To: <506DF061.4080403@wp.pl> References: <80840563.20120920002200@serebryakov.spb.ru> <506C8F4F.3040703@wp.pl> <13310645740.20121004225119@serebryakov.spb.ru> <506DF061.4080403@wp.pl> Content-Type: text/plain; charset="koi8-r" Date: Thu, 04 Oct 2012 14:46:03 -0600 Message-ID: <1349383564.2363.111.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: lev@freebsd.org, freebsd-current@freebsd.org Subject: Re: [SPAM]Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 20:46:17 -0000 On Thu, 2012-10-04 at 22:24 +0200, Marek Salwerowicz wrote: > W dniu 2012-10-04 20:51, Lev Serebryakov pisze: > > Hello, Marek. > > You wrote 3 ÏËÔÑÂÒÑ 2012 Ç., 23:17:35: > > > >>> atrtc0: port 0x70-0x71 on acpi0 > > MS> still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host > > MS> Do you have any solution? > > In my case it was local patch for exotic embedded chipset... > Can you send me the patch so I can have a look if I don't use the same > chipset ? > > Regards, It is the patch attached to this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=170705 The patch fixes a problem with old AMD Geode chipsets, but causes a hang at atrtc attach when run under virtualbox, and I haven't had time yet to install and learn to use vbox enough to debug it. -- Ian From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 22:06:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50B5B106566B; Thu, 4 Oct 2012 22:06:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E11A38FC1C; Thu, 4 Oct 2012 22:06:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EADoHblCDaFvO/2dsb2JhbABFhg+6D4IgAQEBBAEBASArIAsbDgoCAg0ZAikBCSYGCAcEARoCBIdkC6UxknSBIYodGoRxgRIDkzyCLYEVjxeDCYFHNA X-IronPort-AV: E=Sophos;i="4.80,537,1344225600"; d="scan'208";a="184770855" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 04 Oct 2012 18:06:56 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8B754B4045; Thu, 4 Oct 2012 18:06:56 -0400 (EDT) Date: Thu, 4 Oct 2012 18:06:56 -0400 (EDT) From: Rick Macklem To: John Baldwin Message-ID: <1794336473.1759341.1349388416433.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201210041457.09340.jhb@freebsd.org> 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 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: svn MFC to stable/8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:06:58 -0000 John Baldwin wrote: > On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote: > > Hi, > > > > Hopefully someone familiar with svn can help. When I try to MFC > > a kernel change to stable/8, it works, but I end up with tons of > > mergeinfo. (It looks like every directory under sys.) > > > > Does this matter or is there a trick to avoid this? > > > > Thanks in advance for any help, rick > > ps: I seem to MFC fine to stable/9. I only see this for stable/8. > > Someone screwed up the mergeinfo on stable/8/sys/dev due to svn 1.6 > not working well with newer merges from 1.7. The simplest solution > is to just update your client to svn 1.7. Otherwise, you can commit > what you have now with 1.6. > Thanks yet again John. I used svn1.7 and it didn't have all the dirs. It only listed directory properties for sys and sys/fs, which I hope was ok, since I committed it. rick > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 22:22:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75C1F1065670 for ; Thu, 4 Oct 2012 22:22:10 +0000 (UTC) (envelope-from peter@vps.rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id EA11B8FC08 for ; Thu, 4 Oct 2012 22:22:09 +0000 (UTC) Received: from vps.rulingia.com (localhost [127.0.0.1]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q94MLsI8074873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 08:21:54 +1000 (EST) (envelope-from peter@vps.rulingia.com) Received: (from peter@localhost) by vps.rulingia.com (8.14.5/8.14.5/Submit) id q94MLrd0074872; Fri, 5 Oct 2012 08:21:53 +1000 (EST) (envelope-from peter) Date: Fri, 5 Oct 2012 08:21:53 +1000 From: Peter Jeremy To: freebsd@chrysalisnet.org Message-ID: <20121004222153.GB74702@vps.rulingia.com> References: <03e101cda197$326dc240$974946c0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03e101cda197$326dc240$974946c0$@org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:22:10 -0000 On 2012-Oct-03 19:45:01 +0100, freebsd@chrysalisnet.org wrote: >In addition we had to migrate all our mysql servers from freebsd to debian >because they were hitting some arbitary OS limit but I could never figure >out what, sys% usage went through the roof when this limit was hit, issue >didnt occur on debian. Did you report this issue on any of the FreeBSD mailing lists? Reporting a problem doesn't guarantee that it will be fixed (unfortunately) but not reporting a problem makes it extremely unlikely that it will be fixed. > I feel recently freebsd is more focused on desktop's >and as such developer's never develop for a heavy server usage scenario, This isn't intentionally true but it's true that few developers run large servers so they may not run into some issues that only impact large systems. Again, it's up to people who do run such systems to provide feedback about bottlenecks & issues they hit so that they can be fixed. >I keep coming across hardcoded low limits. As rightly pointed out default There are lots of defaults that were set some time (potentially decades) ago and may no longer be optimal. It's unrealistic to expect that all the defaults are correct in all circumstances and this is one area where end users can help by flagging defaults that they find need tuning. >values now days are useless 128 for somaxconn? maybe ok for a desktop. But, as others have pointed out, this isn't one of them. Can you please provide more details on a use scenario where a listen(2) backlog exceeding 128 is reasonable. > I cant tell app developers to >fix their apps to work on FreeBSD, they dont care, if it works fine on >windows and linux then the app isnt broken as far as they are concerned. FreeBSD is not Windows or Linux and never will be. There are lots of grey areas in the various standards that *BSD, Linux, Solaris, Windows etc comply with and some OSs interpret these grey areas differently to others (in some areas, it seems Linux has deliberately done things differently to other Unices for no obvious reason, and the GNU embrace-and-extend philosophy doesn't help). Writing portable code takes more than adding some .ac/.am files to an arbitrary blob of code and just because a developer thinks their app isn't broken doesn't make them right. BTW, I note that this was sent to -current? Are you running HEAD on production servers? If so, your feedback on issues you encounter would be appreciated so that they can be corrected before they make it into a RELEASE. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 22:46:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38FF81065672 for ; Thu, 4 Oct 2012 22:46:46 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id CDED98FC19 for ; Thu, 4 Oct 2012 22:46:45 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q94MkHAD024569 for ; Thu, 4 Oct 2012 15:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1349390778; bh=jpg8wIBmaxSbzhGzlgSf5rGVVj2eL4A96UcuXJvTtfg=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=aT4fEfVHNB82aaGq72On+FGzSvfG5qHZxOBNRloLTSzaapLJlbfvvjJXh7v8cm0jb pPJQW6Oq8Usdp5OYIUyjB8zmrvhoMJiHQ/MXggZ52BXl8m6ZNNpuLMeFuUWnfYxyfc Mr6I+bS/pji30Zz3o3kEFWOd0/sE7kO/iskO+H30= From: Sean Bruno To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Thu, 04 Oct 2012 15:46:17 -0700 Message-ID: <1349390777.5234.9.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 390778001 Subject: [CFT]hwpmc update for sandybridge-e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:46:46 -0000 So, I did the bear minimum and kind of hacked things together without understanding precisely what I was doing, and I was able to massage the sandybridge-e CPUs into giving me some basic functions. Comments or concerns before I commit this? http://people.freebsd.org/~sbruno/pmc_sandybridge.txt Sean p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 22:49:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AFF11065670 for ; Thu, 4 Oct 2012 22:49:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4DC4E8FC08 for ; Thu, 4 Oct 2012 22:49:04 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so1150294pad.13 for ; Thu, 04 Oct 2012 15: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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GJJbpSnJ0XD/nvFLTyBPyO/i+01FFXZdbzSojUQYb3o=; b=ymEaj79B9D8WXjEm7hfZRrBWXM1FsTWfpNpbam/soEJqK2wAEsuVOLaLwjWYVFgNV6 00ryjdmcTKtaOlc8GF8Crbv3qh0Ul9ulUd9nZlKTZxSeP7dUo9qqy8EGg2F5Sw6360NY yChKo2AkHHjX4AI1L04GExYU8/6ldeX14hLY+HExdB/dD3N4wcSbCneMh8JoysXPEbBT NqY8OcNT2WqleFDUW7xZuM5ghNspRHIf0quDzRNxFTasIh0LsAVbUWUa1nylHdCNHBRh uH8Sl90XE0OyfG7W2Dca97DYbwWpvmMSd4EsJlzht/UGfUwLma5IkEVPTpcBsW8+1wwK TrRA== MIME-Version: 1.0 Received: by 10.68.204.132 with SMTP id ky4mr25352049pbc.164.1349390943954; Thu, 04 Oct 2012 15:49:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.223.136 with HTTP; Thu, 4 Oct 2012 15:49:03 -0700 (PDT) In-Reply-To: <20121004222153.GB74702@vps.rulingia.com> References: <03e101cda197$326dc240$974946c0$@org> <20121004222153.GB74702@vps.rulingia.com> Date: Thu, 4 Oct 2012 15:49:03 -0700 X-Google-Sender-Auth: slbyHmLPBKBhJhgF68jlAMpZJtY Message-ID: From: Adrian Chadd To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd@chrysalisnet.org, freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:49:04 -0000 On 4 October 2012 15:21, Peter Jeremy wrote: > On 2012-Oct-03 19:45:01 +0100, freebsd@chrysalisnet.org wrote: >>In addition we had to migrate all our mysql servers from freebsd to debian >>because they were hitting some arbitary OS limit but I could never figure >>out what, sys% usage went through the roof when this limit was hit, issue >>didnt occur on debian. > > Did you report this issue on any of the FreeBSD mailing lists? > Reporting a problem doesn't guarantee that it will be fixed > (unfortunately) but not reporting a problem makes it extremely > unlikely that it will be fixed. Right, if you don't report that issue then the likelihood of it being fixed is low. It wouldn't be the first time that I've seen FreeBSD expose some bug in some not-quite-right multi-threaded code because it doesn't behave "like linux", regardless of what the specification says. :-) Adrian From owner-freebsd-current@FreeBSD.ORG Thu Oct 4 23:46:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E8AF106566B; Thu, 4 Oct 2012 23:46:11 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 250488FC12; Thu, 4 Oct 2012 23:46:10 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so1713521vcb.13 for ; Thu, 04 Oct 2012 16:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1wHeOCuqyVsiSBL78JuI8Xw7n2LOiaHnx6NuPw7xI5g=; b=cGXy9BLX3IcF06VhmWqvGSBI+v4O0h9wZiKvDw854zLpzGindflFhTjzD8Wz+0vrBh V2R/599YdrNoVjUVZVopoC05IGOjcPWPH9r9xI7lk4AFNqyHkZIPhExf5TSpACAkA0n7 bKVX6cnJbaU7moMyOYMHVajVdMjAOBpTkLvwwNqeAwGtfMjO3vajf1yMyJZqa+u8iyFo yH3H0FsnTKBnYFT/Dmrmkl1cXSvw9pm3FoEn4qGOhptKMFpG8wtTB2fmnbr8d6EJWIc1 U9/TJdml4K1fcagnvCv932wXfMmGwjoiNVMRBwe3NR5p3AyHppWePO4eW8Jwo0qBeTnA MSuQ== MIME-Version: 1.0 Received: by 10.220.154.2 with SMTP id m2mr4180372vcw.18.1349394369962; Thu, 04 Oct 2012 16:46:09 -0700 (PDT) Sender: jim.harris@gmail.com Received: by 10.59.10.98 with HTTP; Thu, 4 Oct 2012 16:46:09 -0700 (PDT) In-Reply-To: <1349390777.5234.9.camel@powernoodle.corp.yahoo.com> References: <1349390777.5234.9.camel@powernoodle.corp.yahoo.com> Date: Thu, 4 Oct 2012 16:46:09 -0700 X-Google-Sender-Auth: UuW7WcM_sbMyFag8iEleqyFfjG8 Message-ID: From: Jim Harris To: sbruno@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-current@freebsd.org" Subject: Re: [CFT]hwpmc update for sandybridge-e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 23:46:11 -0000 On Thu, Oct 4, 2012 at 3:46 PM, Sean Bruno wrote: > So, I did the bear minimum and kind of hacked things together without > understanding precisely what I was doing, and I was able to massage the > sandybridge-e CPUs into giving me some basic functions. > > Comments or concerns before I commit this? fabient@ already added some Ivy Bridge support to hwpmc. You may want to rebase based on his changes. I'd suggest SANDYBRIDGE_XEON, rather than SANDYBRIDGE_E only because I think it will make it more clear/correct. I'd also suggest putting something in uncore_pcpu_fini to not clear the EVSEL MSRs for SNB Xeon. By adding the new CPU type like you did, it has the effect of using the WSM EVSEL MSRs here (see the SELECTSEL macro in hwpmc_uncore.c). This is likely harmless, but isn't correct, and would be safer to just not clear the EVSEL MSRs at all, since there are no uncore events defined for your new CPU type anyways. Regards, -Jim > http://people.freebsd.org/~sbruno/pmc_sandybridge.txt > > Sean > > p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. > > _______________________________________________ > 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 Oct 5 03:09:26 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD07D106567E; Fri, 5 Oct 2012 03:09:26 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1D3438FC1C; Fri, 5 Oct 2012 03:09:22 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q9539Df7012562; Thu, 4 Oct 2012 20:09:13 -0700 (PDT) (envelope-from freebsd@penx.com) From: Dennis Glatting To: Gabor Kovesdan In-Reply-To: <506DB65D.7000009@FreeBSD.org> References: <506D6AA3.7010504@FreeBSD.org> <1349362250.83035.3.camel@btw.pki2.com> <506DB65D.7000009@FreeBSD.org> Date: Thu, 04 Oct 2012 20:09:13 -0700 Message-ID: <1349406553.89315.5.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q9539Df7012562 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@penx.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Oleg Moskalenko , current@FreeBSD.org Subject: Re: [HEADSUP] Upcoming GNU sort removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 03:09:26 -0000 On Thu, 2012-10-04 at 18:16 +0200, Gabor Kovesdan wrote: > Em 04-10-2012 16:50, Dennis Glatting escreveu: > > On Thu, 2012-10-04 at 12:53 +0200, Gabor Kovesdan wrote: > >> > Hi, > >> > > >> > it has been more than 3 months ago that BSD sort became default in HEAD > >> > and no serious complaints have been raised against it since then so I > >> > plan to permanently remove GNU sort from head in the next days. If you > >> > have any objection, please raise it now. > >> > > > Initially I had problems with multi TB files (--unique, five to ten > > files) but I haven't had to do that in two(?) months. I will be getting > > back to that project in a month or so. > > > > It challanges a system's resources. :) > > And did it go much better with base GNU sort? It's quite an extreme > case... :) Multi GB is also rare not speaking about multi TB... > Yes. However my problem now is ZFS stability -- typically locking up, case example today: last pid: 67998; load averages: 0.00, 0.00, 0.00 up 1+19:50:51 19:02:10 80 processes: 1 running, 79 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 146M Active, 2765M Inact, 35G Wired, 371M Buf, 86G Free ARC: 32G Total, 4141M MRU, 27G MFU, 55M Anon, 485M Header, 614M Other Swap: 233G Total, 233G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 17517 root 17 42 4 217M 128M tx->tx 21 25.3H 0.00% pbzip2 17568 root 17 52 4 201M 116M tx->tx 24 25.2H 0.00% pbzip2 17508 root 17 46 4 201M 116M tx->tx 33 24.6H 0.00% pbzip2 17544 root 17 52 4 205M 120M tx->tx 37 24.6H 0.00% pbzip2 17532 root 17 52 4 209M 123M tx->tx 35 24.5H 0.00% pbzip2 etc. From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 08:00:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A82761065670; Fri, 5 Oct 2012 08:00:39 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 656E88FC12; Fri, 5 Oct 2012 08:00:38 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 1AA15270434F; Fri, 5 Oct 2012 10:00:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) From: Fabien Thomas In-Reply-To: <1349390777.5234.9.camel@powernoodle.corp.yahoo.com> Date: Fri, 5 Oct 2012 10:00:38 +0200 Message-Id: References: <1349390777.5234.9.camel@powernoodle.corp.yahoo.com> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Davide Italiano , freebsd-current Subject: Re: [CFT]hwpmc update for sandybridge-e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 08:00:39 -0000 Le 5 oct. 2012 =E0 00:46, Sean Bruno a =E9crit : > So, I did the bear minimum and kind of hacked things together without > understanding precisely what I was doing, and I was able to massage = the > sandybridge-e CPUs into giving me some basic functions. >=20 > Comments or concerns before I commit this? >=20 > http://people.freebsd.org/~sbruno/pmc_sandybridge.txt Hi Sean, The only modification required is this one http://svnweb.freebsd.org/base?view=3Drevision&revision=3D237196 but davide@ removed it for a problem that need to be looked at. Fabien >=20 > Sean >=20 > p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. >=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" From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 08:05:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69E0B1065738; Fri, 5 Oct 2012 08:05:58 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 102008FC0C; Fri, 5 Oct 2012 08:05:58 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 52B88270437F; Fri, 5 Oct 2012 10:05:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) From: Fabien Thomas In-Reply-To: Date: Fri, 5 Oct 2012 10:05:57 +0200 Message-Id: References: <1349390777.5234.9.camel@powernoodle.corp.yahoo.com> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Davide Italiano , freebsd-current Subject: Re: [CFT]hwpmc update for sandybridge-e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 08:05:58 -0000 Le 5 oct. 2012 =E0 10:00, Fabien Thomas a =E9crit : >=20 > Le 5 oct. 2012 =E0 00:46, Sean Bruno a =E9crit : >=20 >> So, I did the bear minimum and kind of hacked things together without >> understanding precisely what I was doing, and I was able to massage = the >> sandybridge-e CPUs into giving me some basic functions. >>=20 >> Comments or concerns before I commit this? >>=20 >> http://people.freebsd.org/~sbruno/pmc_sandybridge.txt >=20 > Hi Sean, >=20 > The only modification required is this one > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D237196 >=20 > but davide@ removed it for a problem that need to be looked at. Looking at the doc this CPU require a full set of PMC as the list of = event are different. So this mean full manpage, full event list, =85 Doc: " The events in Table 19-3 apply to processors with CPUID signature of DisplayFamily_DisplayModel encoding = with the following values: 06_2AH and 06_2DH. The events in Table 19-4 apply to = processors with CPUID signature 06_2AH. The events in Table 19-5 apply to = processors with CPUID signature 06_2DH. " Required change will be the same as this commit if you want to look at = it: http://svnweb.freebsd.org/base?view=3Drevision&revision=3D240164 >=20 >=20 > Fabien >>=20 >> Sean >>=20 >> p.s. I'm trying to hunt down some IvyBridge boxes to finish this = off. >>=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" >=20 From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 10:57:50 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13773106566B; Fri, 5 Oct 2012 10:57:50 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id D00338FC08; Fri, 5 Oct 2012 10:57:49 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so1819506pad.13 for ; Fri, 05 Oct 2012 03:57:49 -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=m5TOSJOy/NyhF98RBg78ofGIXr2tCC8cRZHMy8MBNDY=; b=OPV5hNe7fBoRO7UDG/3OLrJgxX+zQSMo/TdW3+sXN/dMYGNEx3abCa22Moo0RbMLkB BhXLpV22hWqAQMieYC+3IBqOHYJiPXCMKE25POa0nq0pMUSWwhijk2RiRYbvhIJ/DvWA HNhyAaKilOyJnGZJ649RXYONynJ6AwIPeIhYQCakTrKPkKvP3ukPWxg2QiWEonLVxaAL sQeVrnN17jqYQp0cf0BCmN/FfZME77bW/ARM2Wp9CF65QmT9eCkzulISna60rCDMbNPk uEv5soT2MhT9jRMDbkiBaaY6hYCLROxmn0CBIDV+ceaOkYD4SD25AylM2luC46aDxs1B zhhg== Received: by 10.68.222.105 with SMTP id ql9mr29448287pbc.97.1349434669628; Fri, 05 Oct 2012 03:57:49 -0700 (PDT) Received: from [192.168.1.128] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id jv10sm5903571pbc.23.2012.10.05.03.57.46 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 03:57:48 -0700 (PDT) Message-ID: <506EBD27.8040806@gmail.com> Date: Fri, 05 Oct 2012 13:57:43 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120924 Thunderbird/15.0.1 MIME-Version: 1.0 To: Gabor Kovesdan References: <506D6AA3.7010504@FreeBSD.org> In-Reply-To: <506D6AA3.7010504@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Oleg Moskalenko , current@FreeBSD.org Subject: Re: [HEADSUP] Upcoming GNU sort removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 10:57:50 -0000 04.10.2012 13:53, Gabor Kovesdan wrote: > it has been more than 3 months ago that BSD sort became default in HEAD > and no serious complaints have been raised against it since then so I > plan to permanently remove GNU sort from head in the next days. If you > have any objection, please raise it now. http://scan.freebsd.your.org/freebsd-head/usr.bin.grep/2012-01-12-amd64/ /usr/src/usr.bin/grep/regex/xmalloc.c:341:7: warning: Use of memory after it is freed hash_table_del(xmalloc_table, ptr); ^ ~~~ 1 warning generated. /usr/src/usr.bin/grep/regex/tre-fastmatch.c:534:3: warning: Result of 'malloc' is converted to a pointer of type 'unsigned int', which is incompatible with sizeof operand type 'int' FILL_BMGS; ^~~~~~~~~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:343:19: note: expanded from macro 'FILL_BMGS' fg->sbmGs = xmalloc(fg->len * sizeof(int)); \ ^ /usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 'xmalloc' #define xmalloc(size) malloc(size) ^~~~~~ ~~~~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:537:3: warning: Result of 'malloc' is converted to a pointer of type 'unsigned int', which is incompatible with sizeof operand type 'int' FILL_BMGS_WIDE; ^~~~~~~~~~~~~~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:359:18: note: expanded from macro 'FILL_BMGS_WIDE' fg->bmGs = xmalloc(fg->wlen * sizeof(int)); \ ^ /usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 'xmalloc' #define xmalloc(size) malloc(size) ^~~~~~ ~~~~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:707:3: warning: Memory is never released; potential leak of memory pointed to by 'tmp' STORE_MBS_PAT; ^~~~~~~~~~~~~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:97:14: note: expanded from macro 'STORE_MBS_PAT' return REG_ESPACE; \ ^~~~~~~~~~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:766:3: warning: Result of 'malloc' is converted to a pointer of type 'unsigned int', which is incompatible with sizeof operand type 'int' FILL_BMGS; ^~~~~~~~~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:343:19: note: expanded from macro 'FILL_BMGS' fg->sbmGs = xmalloc(fg->len * sizeof(int)); \ ^ /usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 'xmalloc' #define xmalloc(size) malloc(size) ^~~~~~ ~~~~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:769:3: warning: Result of 'malloc' is converted to a pointer of type 'unsigned int', which is incompatible with sizeof operand type 'int' FILL_BMGS_WIDE; ^~~~~~~~~~~~~~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:359:18: note: expanded from macro 'FILL_BMGS_WIDE' fg->bmGs = xmalloc(fg->wlen * sizeof(int)); \ ^ /usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 'xmalloc' #define xmalloc(size) malloc(size) ^~~~~~ ~~~~ 5 warnings generated. How about fixing http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/167921 ? > /usr/bin/grep "/tmp/ports/.amd_mnt/faz/host/usr/ports/textproc/docbook-410/work/\\." Segmentation fault (core dumped) > uname -a FreeBSD ar1l0u 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r241156M: Wed Oct 3 13:58:16 EEST 2012 arcade@ar1l0u:/usr/obj/usr/src/sys/MINIMAL amd64 > gdb /usr/obj/usr/src/usr.bin/grep/grep grep.core 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"...(no debugging symbols found)... Core was generated by `grep'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/lib/liblzma.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/liblzma.so.5 Reading symbols from /usr/lib/libbz2.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbz2.so.4 Reading symbols from /usr/lib/libgnuregex.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000000004069d2 in tre_compile_fast () (gdb) bt full #0 0x00000000004069d2 in tre_compile_fast () No symbol table info available. #1 0x0000000000404d06 in tre_fastncomp () No symbol table info available. #2 0x00000000004035b3 in main () No symbol table info available. -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 11:50:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52DED1065672 for ; Fri, 5 Oct 2012 11:50:19 +0000 (UTC) (envelope-from levitch@iglou.com) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id 0C3708FC16 for ; Fri, 5 Oct 2012 11:50:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:From:Date; bh=O7yU+NBzrBVy73V4+g3UGR3A/maKl4t0TRCfVx/3m5I=; b=J3D8OUCXm+YR2QFVYafAcwxgDYbggaVkJKbPfYdOFwMZOfa7MiwEcjxDMeGI9e3Bn1cpSw9NITgUm3BYCaZihU5OhfUxsyeMlWdNp+/Chfxa+f3AkcvtFfmXeihYLhXMdJpkNwFHjx1CdiJm8bgB+8/gtbbtf1kzEhPZYXBuYWk=; Received: from iglou3.iglou.com ([192.107.41.6]:56454 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1TK6Q5-0004A4-B3 by authid with igloumta_auth for current@freebsd.org; Fri, 05 Oct 2012 07:50:17 -0400 Received: from shell1.iglou.com ([192.107.41.17]:62271 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1TK6Q5-0007He-04; Fri, 05 Oct 2012 07:50:17 -0400 Date: Fri, 5 Oct 2012 07:50:16 -0400 (EDT) From: Darrel X-X-Sender: levitch@shell1 To: Sergey Kandaurov In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-Mailman-Approved-At: Fri, 05 Oct 2012 12:00:24 +0000 Cc: current@freebsd.org Subject: Re: memory warnings r240891 | dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:50:19 -0000 >> (30) @ 12:01:50> swapinfo >> Device 1K-blocks Used Avail Capacity >> /dev/zvol/bigD/swap 4194304 0 4194304 0% >> /dev/gpt/swap0.eli 3145728 0 3145728 0% >> /dev/gpt/swap1.eli 3145728 0 3145728 0% >> Total 10485760 0 10485760 0% > [...] >> ************************************************************* >> FreeBSD 10.0-CURRENT #1 r240891: Tue Sep 25 00:51:03 EDT 2012 >> warning: increase kern.maxswzone or reduce amount of swap. >> >> ************************************************************* >> >> Apparently kern.maxswzone is currently equal to 0. How might I tweak it >> just enough to fix this? > > So, reduce amount of swap :) > > This is because kernel needs some memory to manage swap too. > Currently for amd64 this roughly reduces to the following rule > (My apologies in advance for the extra simplification): > > 100MB RAM per 800MB swap space. > > So, with your current amount of RAM (893MB) it is recommended to setup > no more than 7144 MB of swap. [1] > Thanks for the good ideas. Thus far, # zfs get volsize bigD/swap NAME PROPERTY VALUE SOURCE bigD/swap volsize 4G local # zfs set volsize=1100m bigD/swap # zfs get volsize bigD/swap NAME PROPERTY VALUE SOURCE bigD/swap volsize 1.07G local (73) @ 6:55:44> swapinfo -h Device 1K-blocks Used Avail Capacity /dev/#C:0x6c 4194304 808k 4G 0% /dev/gpt/swap0.eli 3145728 772k 3G 0% /dev/gpt/swap1.eli 3145728 800k 3G 0% Total 10485760 2.3M 10G 0% - yes, it appeared that something weird happened to the file name # zfs destroy -V bigD/swap - file in use or some error # reboot # swapinfo -h Device 1K-blocks Used Avail Capacity /dev/zvol/bigD/swap 1126400 0B 1.1G 0% /dev/gpt/swap0.eli 3145728 0B 3.0G 0% /dev/gpt/swap1.eli 3145728 0B 3.0G 0% Total 7417856 0B 7.1G 0% So the zvol swap size was reduced, but the swzone error still exists. Also, the zfs create and destroy commands availed nothing- perhaps there were subsequent or subcommands to run there. Is there a good method to reduce the encrypted swap, perhaps? I might like to have a total of 3g encrypted swap plus 3g zvol swap. Darrel From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 12:26:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3077B106566B for ; Fri, 5 Oct 2012 12:26:47 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id D7BE28FC08 for ; Fri, 5 Oct 2012 12:26:46 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TK6zQ-0001e3-Pp for freebsd-current@freebsd.org; Fri, 05 Oct 2012 14:26:48 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Oct 2012 14:26:48 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Oct 2012 14:26:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 05 Oct 2012 14:26:34 +0200 Lines: 37 Message-ID: References: <03e101cda197$326dc240$974946c0$@org> <506C9CE4.6080400@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF975A8945D65D6A7F67DFB72" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: <506C9CE4.6080400@freebsd.org> X-Enigmail-Version: 1.4.3 Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:26:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF975A8945D65D6A7F67DFB72 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/10/2012 22:15, Andre Oppermann wrote: > I guess the problem is rather kern.ipc.maxsockets which is only 25600. > maxsockets should be bumped up quite a bit by default IMO. How far need= s > some analysis because there are some dependencies and memory > requirements. So, how about a heuristic, 20,000 + (5000 for every GB of RAM)? A small, 16 GB machine (yes, 16 GB is "small" nowadays) would have 100,000, which should be enough. --------------enigF975A8945D65D6A7F67DFB72 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.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBu0foACgkQ/QjVBj3/HSzqpwCggL+MT3+qs48L9KZbO0RDE0ae SsYAnjoxZVk65OtcaP4LWTAt7RjCy3Xm =37QX -----END PGP SIGNATURE----- --------------enigF975A8945D65D6A7F67DFB72-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 13:51:13 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 769AC106566C; Fri, 5 Oct 2012 13:51:13 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 40A558FC0A; Fri, 5 Oct 2012 13:51:13 +0000 (UTC) Received: from glenbarber.us (75-146-225-65-Philadelphia.hfc.comcastbusiness.net [75.146.225.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 88A1C23F645; Fri, 5 Oct 2012 09:51:12 -0400 (EDT) Date: Fri, 5 Oct 2012 09:51:10 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <20121005135110.GA1339@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: FreeBSD 10-CURRENT and 9-STABLE snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:51:13 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, A number of FreeBSD users have displayed interest in the availability and testing of -STABLE and -CURRENT snapshot releases. I have been working on generating snapshots regularly, and now would like to announce their availability for those interested in testing. Please note, as always with the -STABLE and -CURRENT branches, these snapshots are not intended for production systems. The snapshots available are: - 10.0-CURRENT amd64 - 10.0-CURRENT i386 - 9.1-PRERELEASE amd64 - 9.1-PRERELEASE i386 Note that the 9.1-PRERELEASE snapshots are the stable/9 branch, not what will eventually be 9.1-RELEASE. I do not yet have snapshots for the 8-STABLE branch, but am working on the magic to make that happen as well. There are also no bootonly ISOs, since the necessary distribution sets are not available on the FreeBSD FTP servers, so I cannot direct the installer to a different location very easily. The URL for the snapshots is: https://snapshots.glenbarber.us/Latest/ The SHA256 of the xz(1)-compressed install medium follows, and is also included in a plain-text file on the site. FreeBSD-10.0-CURRENT-amd64-memstick.xz = 8779f5925cb903c64d647392f6af825d5e74019d6d13222045d69091b03a81ff FreeBSD-10.0-CURRENT-amd64-release.iso.xz = cc3934c947563c23f92ba1cd8ca7ded3999dfbc050e2b2647c294e442f267040 FreeBSD-10.0-CURRENT-i386-memstick.xz = 9eb7ff8e28c0c524d2794828acb601b9b7079c1d00017e3bf84b974ff4412e42 FreeBSD-10.0-CURRENT-i386-release.iso.xz = 0d1334fea13e16cb0d06a3f3c3fb7b0e1223baf06a06a889a6cffa6981348ae5 FreeBSD-9.1-PRERELEASE-amd64-memstick.xz = f5f1e7acbaaac6eb61c5194199eb6ef090af242efc9808dc1af5caeee126e15e FreeBSD-9.1-PRERELEASE-amd64-release.iso.xz = 0cfa5b258428741e0345b29eed241188d5944fcb15a70b079d39d56195f0cccc FreeBSD-9.1-PRERELEASE-i386-memstick.xz = 4e98ffe63b186b0e26f22c3ddfb0582019bf352d1ea39da2757817c809872b67 FreeBSD-9.1-PRERELEASE-i386-release.iso.xz = 0bce6f2a9626705484ff7cac18623f714e289ef6ddc0b6199d78eba37ded2ca4 The "Latest" directory on the site will always point to the latest batch of snapshots, which right now my goal is to regenerate every few days (I do not have a definitive timeframe in mind yet). I hope these are useful to the FreeBSD community. Feedback on this is welcome, as always. Cheers, Glen PS: Please report any issues regarding downloading to me directly. --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQbuXOAAoJEFJPDDeguUajaqMIAK9Ycwb5dSt5X/KzGtnJSe+i gMMSshUXKk7CzEKqLwQstN6BmhfW2iTlR0qvQeAmNuQGWAZCXY64Tokj3yxd5cfE aU/RMOwUMrkCA6xBYtxvjoyPRmETFnFxXtm6exud2qM4MPhtvsW+QGq0OfDj2wL2 ksgWyiG/FdcR9DtrwP9x6e7TK/ejdahlIc5grc9SzDERnhgzSQ87jbfQaAv/AIBN 6CBQ9WMSVwWZoLzdJPEZZJO8G5ENB8qnt/I8wKcmXJLsiJ3cjcDRpFKe8Qxr9KcT l+fF9SDKJHlD0pjN2z4RtrJtkXxaKIc/Ct0Cp2kxy5N/M7B9LOdv/DCEN7uPyxU= =pgPk -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 14:11:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBD9A106566C; Fri, 5 Oct 2012 14:11:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A79248FC14; Fri, 5 Oct 2012 14:11:16 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so2136353pbb.13 for ; Fri, 05 Oct 2012 07:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SGmvpax0szVpythFSy1T8h0cIqZ46szHFdv6sP03WfA=; b=vJLotuLJl7LtwRitXOW8opcZyDsJxQSEbCeafrHs1Tt9umzQvmU4f6DAcMjnf1q/fV 8aTpWJdlOnuJBwpAnv7GvN9Rb/ZSdcYb7QKPP5V2SURbr+N28jKOfva38NtAGU54astQ yeIom8126+XakClmAOfD8X+q1jLPgcHOUSomiZIW0tCuXhFZeUm1sBwkWTOAXq8GYLv6 ohrGJgcVNrrkOw+IIRVOB6eR47pGSzwkkLEHlW8Xb+QFfH1/KWtSnS/FC3zSpNiYezUE 4aqvM6pox7AlUltmk72eizz8zW3RSbEuPNVSrHHzzCZ/z7XO67XnT8DzUde030SbZcXy N7Pg== MIME-Version: 1.0 Received: by 10.68.232.71 with SMTP id tm7mr31278701pbc.118.1349446276230; Fri, 05 Oct 2012 07:11:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.223.136 with HTTP; Fri, 5 Oct 2012 07:11:16 -0700 (PDT) In-Reply-To: References: <03e101cda197$326dc240$974946c0$@org> <506C9CE4.6080400@freebsd.org> Date: Fri, 5 Oct 2012 07:11:16 -0700 X-Google-Sender-Auth: 70c__NgxbL4dMb8vTyp9M0AWrKg Message-ID: From: Adrian Chadd To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:11:17 -0000 On 5 October 2012 05:26, Ivan Voras wrote: > On 03/10/2012 22:15, Andre Oppermann wrote: > >> I guess the problem is rather kern.ipc.maxsockets which is only 25600. > >> maxsockets should be bumped up quite a bit by default IMO. How far needs >> some analysis because there are some dependencies and memory >> requirements. > > So, how about a heuristic, 20,000 + (5000 for every GB of RAM)? > > A small, 16 GB machine (yes, 16 GB is "small" nowadays) would have > 100,000, which should be enough. Well, it depends on what the server is being used for, right? If it's a small object proxy/web server sure. But if it's a streaming server you may only need a few thousand sockets but very deep send buffers. Honestly, I'd really like the OP to come to us with workloads that aren't working and get them fixed. We're a pretty smart bunch over here and it's highly likely that both he and we would learn from the process. :) And double honestly, it may be nice to print out a "running out of sockets!" warning, as well as a "running out of mbufs!" warning. Rate limited, so people don't get spammed. But a gentle notification that they should retune some stuff would be user-friendly. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 14:16:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A701E106566B; Fri, 5 Oct 2012 14:16:05 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7135E8FC18; Fri, 5 Oct 2012 14:16:05 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so2060277pad.13 for ; Fri, 05 Oct 2012 07:16:05 -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:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=PuKnJ9IZvCC9OB0+6iHBUOcdrxix0WRbLww5fQlBgps=; b=xPkScEvk5vitpiaPmMzgxZFj1JA7i6q1n3lXIx801ZfNOltUdxTz0xbNuBmoEflaCJ 4CpKrFNp2eEUrmG0HR7BP/jXN2F5jFnG0PdwDpg/m02Hqf+wEtF6fD0KHnn5pBXr8LAB Lha5oUBsIFsKMxL36l7CWEk4pkFCtNpgvfAuc+rjlMOmR74UxH9RKNGFlY3eMd7K7DKy h8StL3+qXj/M8Xz6oafzlM3MoHwfHumVjHFSNkFK1HEu29qNnWv2zcp2stEPlcYxYJCv RFuHxpG4hajdS65thHzjwjgqCVRlgCSwnmsJ1VQONN2KdSQxUkbE/rElx8BPqLjMjq69 WWPA== Received: by 10.68.211.163 with SMTP id nd3mr28948341pbc.84.1349446565093; Fri, 05 Oct 2012 07:16:05 -0700 (PDT) Received: from [192.168.1.128] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id tw5sm6125244pbc.48.2012.10.05.07.16.01 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:16:03 -0700 (PDT) Message-ID: <506EEB99.5090207@gmail.com> Date: Fri, 05 Oct 2012 17:15:53 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120924 Thunderbird/15.0.1 MIME-Version: 1.0 References: <506D6AA3.7010504@FreeBSD.org> <506EBD27.8040806@gmail.com> In-Reply-To: <506EBD27.8040806@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Oleg Moskalenko , Gabor Kovesdan , current@FreeBSD.org Subject: Re: [HEADSUP] Upcoming GNU sort removal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:16:05 -0000 05.10.2012 13:57, Volodymyr Kostyrko wrote: > 04.10.2012 13:53, Gabor Kovesdan wrote: >> it has been more than 3 months ago that BSD sort became default in HEAD >> and no serious complaints have been raised against it since then so I >> plan to permanently remove GNU sort from head in the next days. If you >> have any objection, please raise it now. > > http://scan.freebsd.your.org/freebsd-head/usr.bin.grep/2012-01-12-amd64/ Please excuse me for this, I misread the subject. -- Sphinx of black quartz, judge my vow. From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 14:29:51 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AA7F106566C; Fri, 5 Oct 2012 14:29:51 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 23A728FC14; Fri, 5 Oct 2012 14:29:50 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id BB11428423; Fri, 5 Oct 2012 16:29:47 +0200 (CEST) Received: from [192.168.1.2] (static-84-242-120-26.net.upcbroadband.cz [84.242.120.26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 3BE2D2842A; Fri, 5 Oct 2012 16:29:46 +0200 (CEST) Message-ID: <506EEED9.6060208@quip.cz> Date: Fri, 05 Oct 2012 16:29:45 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Glen Barber References: <20121005135110.GA1339@glenbarber.us> In-Reply-To: <20121005135110.GA1339@glenbarber.us> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 10-CURRENT and 9-STABLE snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:29:51 -0000 Glen Barber wrote: > Hi, > > A number of FreeBSD users have displayed interest in the availability > and testing of -STABLE and -CURRENT snapshot releases. > > I have been working on generating snapshots regularly, and now would > like to announce their availability for those interested in testing. > > Please note, as always with the -STABLE and -CURRENT branches, these > snapshots are not intended for production systems. > > The snapshots available are: > > - 10.0-CURRENT amd64 > - 10.0-CURRENT i386 > - 9.1-PRERELEASE amd64 > - 9.1-PRERELEASE i386 > > Note that the 9.1-PRERELEASE snapshots are the stable/9 branch, not what > will eventually be 9.1-RELEASE. > > I do not yet have snapshots for the 8-STABLE branch, but am working on > the magic to make that happen as well. There are also no bootonly ISOs, > since the necessary distribution sets are not available on the FreeBSD > FTP servers, so I cannot direct the installer to a different location > very easily. > > The URL for the snapshots is: > > https://snapshots.glenbarber.us/Latest/ It would be nice to have them hosted on FreeBSD.org site as official source. Unofficial snapshots can be downloaded from https://pub.allbsd.org/FreeBSD-snapshots/ for a long time (bootonly.iso too) Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 16:17:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6A09106566C for ; Fri, 5 Oct 2012 16:17:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C80C8FC19 for ; Fri, 5 Oct 2012 16:17:36 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E651CB949; Fri, 5 Oct 2012 12:17:35 -0400 (EDT) From: John Baldwin To: Rick Macklem Date: Fri, 5 Oct 2012 11:46:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <1794336473.1759341.1349388416433.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1794336473.1759341.1349388416433.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201210051146.33771.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 05 Oct 2012 12:17:36 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: svn MFC to stable/8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 16:17:36 -0000 On Thursday, October 04, 2012 6:06:56 pm Rick Macklem wrote: > John Baldwin wrote: > > On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote: > > > Hi, > > > > > > Hopefully someone familiar with svn can help. When I try to MFC > > > a kernel change to stable/8, it works, but I end up with tons of > > > mergeinfo. (It looks like every directory under sys.) > > > > > > Does this matter or is there a trick to avoid this? > > > > > > Thanks in advance for any help, rick > > > ps: I seem to MFC fine to stable/9. I only see this for stable/8. > > > > Someone screwed up the mergeinfo on stable/8/sys/dev due to svn 1.6 > > not working well with newer merges from 1.7. The simplest solution > > is to just update your client to svn 1.7. Otherwise, you can commit > > what you have now with 1.6. > > > Thanks yet again John. I used svn1.7 and it didn't have all the dirs. > It only listed directory properties for sys and sys/fs, > which I hope was ok, since I committed it. Yep. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 5 18:41:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 288BA1065670 for ; Fri, 5 Oct 2012 18:41:54 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 85B5C8FC12 for ; Fri, 5 Oct 2012 18:41:52 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id q95IZ28Y086263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 20:35:03 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id q95IYlB9036924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 20:34:47 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id q95IYlod054774; Fri, 5 Oct 2012 20:34:47 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id q95IYj8O054773; Fri, 5 Oct 2012 20:34:45 +0200 (CEST) (envelope-from ticso) Date: Fri, 5 Oct 2012 20:34:45 +0200 From: Bernd Walter To: Peter Jeremy Message-ID: <20121005183445.GJ49639@cicely7.cicely.de> References: <03e101cda197$326dc240$974946c0$@org> <20121004222153.GB74702@vps.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121004222153.GB74702@vps.rulingia.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd@chrysalisnet.org, freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:41:54 -0000 On Fri, Oct 05, 2012 at 08:21:53AM +1000, Peter Jeremy wrote: > On 2012-Oct-03 19:45:01 +0100, freebsd@chrysalisnet.org wrote: > >In addition we had to migrate all our mysql servers from freebsd to debian > >because they were hitting some arbitary OS limit but I could never figure > >out what, sys% usage went through the roof when this limit was hit, issue > >didnt occur on debian. It's a well known point that linux isn't serving time correctly where FreeBSD requires much more load to do it right. It is also well known that MySQL asks for time horrible often. Don't know what they expect this to serve, when it's either slow or wrong, but they do it. Maybe we have hacked around this issue - there are lots of people doing workload tests comparing Databases on Linux and FreeBSD and in the end it always is more or less equal when everything is configured right. Our installed defaults for MySQL migh be different than with Debian and also OS tuning is very different. Sometimes even hardware selection can make big difference when comparing OS, if one OS has a slow driver for a given hardware, or one has a lazy driver ignoring data consistency. > Did you report this issue on any of the FreeBSD mailing lists? > Reporting a problem doesn't guarantee that it will be fixed > (unfortunately) but not reporting a problem makes it extremely > unlikely that it will be fixed. > > > I feel recently freebsd is more focused on desktop's > >and as such developer's never develop for a heavy server usage scenario, > > This isn't intentionally true but it's true that few developers run > large servers so they may not run into some issues that only impact > large systems. Again, it's up to people who do run such systems to > provide feedback about bottlenecks & issues they hit so that they can > be fixed. > > >I keep coming across hardcoded low limits. As rightly pointed out default > > There are lots of defaults that were set some time (potentially > decades) ago and may no longer be optimal. It's unrealistic to expect > that all the defaults are correct in all circumstances and this is one > area where end users can help by flagging defaults that they find need > tuning. > > >values now days are useless 128 for somaxconn? maybe ok for a desktop. > > But, as others have pointed out, this isn't one of them. Can you > please provide more details on a use scenario where a listen(2) > backlog exceeding 128 is reasonable. It's simple math. If the accept loop sleeps for 1 second a connection backlog of 128 ist good for 128 connections per second. However accept loops sleeping for 1 second for high rate servers mean there is something programmed wrong - more likely accept loops sleep for 1-5ms, so 128 is good for at least 25600 connetions per second. Requiring more than 65536 with well done programming means that you try to handle more than 13107200 connections per second. Such a connection rate sounds even unlikely given the number of IP packets required on the network interface just to establish the connections. Furthermore - the typical high transaction service these days are webservers and there you can benefit from keepalive very much. If on the other hand your well written accept loop isn't fast enough because of high CPU load, then the machine is simply overloaded and queuing more connections won't serve you anything but changing symptoms. In any case it ends in bad programming or extremly untypical use case. Yes - we do not support bad programmed applications or every imaginable extreme use case out of the box, that's right. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sat Oct 6 01:32:47 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65FE6106566C; Sat, 6 Oct 2012 01:32:47 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id EC31E8FC08; Sat, 6 Oct 2012 01:32:46 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id CBCCAE6593; Sat, 6 Oct 2012 02:36:06 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=3mtoPAZbF5MP 9TWlSA6Jr5jd5tE=; b=D+zcPmwkoHd+prg6r1S42qMzTDf9d51OjqMxW/D8vBSN zPv8dRfb8zLgw9bK9hFV910AbnygCxT8x1tdf3IP/re7nnkTo0DXBKECrfHHbBiV lSkpbKkkwd5sZyEGPLmacQ5lG0s/SS0g8OLsnnhF7hCzOtUTgJOzHjC9Xm4tE6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=MQZRyz f9tcJfi/Z2QbGICELIMRUUPJGoZd9iyGo7E8zaFzVjRNfM4lRH/fv3PJAKAtNboN YaIKhMzQ1rg2D4z4R6QdF7sY7AE3SITTveah9Eqhuk7cpjYT7Qt/YoeUw3YiE8gc 9XnXzYCUAeig4szid2JPtJShv4Xgv1SVJs2Ws= Received: from [192.168.2.33] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id A2E6FE657B; Sat, 6 Oct 2012 02:36:06 +0100 (BST) Message-ID: <506F8A3D.30104@cran.org.uk> Date: Sat, 06 Oct 2012 02:32:45 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <20121005135110.GA1339@glenbarber.us> <506EEED9.6060208@quip.cz> In-Reply-To: <506EEED9.6060208@quip.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 10-CURRENT and 9-STABLE snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 01:32:47 -0000 On 05/10/2012 15:29, Miroslav Lachman wrote: > Unofficial snapshots can be downloaded from > https://pub.allbsd.org/FreeBSD-snapshots/ for a long time > (bootonly.iso too) I'm baffled as to why those aren't just made official. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Oct 6 09:21:04 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B1C2106566B; Sat, 6 Oct 2012 09:21:04 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 21C388FC28; Sat, 6 Oct 2012 09:21:04 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 8C02123F645; Sat, 6 Oct 2012 05:21:01 -0400 (EDT) Date: Sat, 6 Oct 2012 05:20:58 -0400 From: Glen Barber To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20121006092058.GE1390@glenbarber.us> References: <20121005135110.GA1339@glenbarber.us> <506EEED9.6060208@quip.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qOrJKOH36bD5yhNe" Content-Disposition: inline In-Reply-To: <506EEED9.6060208@quip.cz> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 10-CURRENT and 9-STABLE snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 09:21:04 -0000 --qOrJKOH36bD5yhNe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 05, 2012 at 04:29:45PM +0200, Miroslav Lachman wrote: > It would be nice to have them hosted on FreeBSD.org site as official=20 > source. I agree 100%. > Unofficial snapshots can be downloaded from=20 > https://pub.allbsd.org/FreeBSD-snapshots/ for a long time (bootonly.iso t= oo) >=20 I am not sure how the bootonly.iso for -CURRENT and -STABLE can point to a non-FreeBSD FTP site without patching the source prior to the release build. If there is a clean way to do this without modifying the src/ tree prior to the build phase, I am happy to also provide bootonly.iso images and the necessary hierarchy for the various distribution sets. Glen --qOrJKOH36bD5yhNe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQb/f6AAoJEFJPDDeguUajxeoH/23e+5DvUGicMkX8Yd+vcx/k ogMSpOlEZcUnylQjLYhC/fow9NpZubicLbzSwDSt9vpW4Kc3kb0L/KIExm5c1PmN odvVHAcCI38a196blfMXtdVDqebny8V1+wJlnuPDbrMf2jYJFsRb7xtgrDs1Mp4d jud+DtwOKYqZ/WPcR9SjZGqnQm73ene9eKIXs+VxVh8UMixkkzsAOA6qt9+LOmQm BQIi6Rt8mi9a/BLtPGZ4g7RCY3711P+7Gxn0yCBM3yLzgiFX2qUsTDMwJ3QjLnVt clBIa82znpZo/sk6U/ev71HfBR9aQLypANr86Xc0bqPyowqNZ1lqKW2GIGsYBYA= =AUBX -----END PGP SIGNATURE----- --qOrJKOH36bD5yhNe-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 6 10:52:40 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2F911065672; Sat, 6 Oct 2012 10:52:40 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 970F18FC12; Sat, 6 Oct 2012 10:52:39 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TKRzk-000aKr-Jn>; Sat, 06 Oct 2012 12:52:32 +0200 Received: from e178027101.adsl.alicedsl.de ([85.178.27.101] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TKRzk-003Y2P-GC>; Sat, 06 Oct 2012 12:52:32 +0200 Message-ID: <50700D6F.1010702@zedat.fu-berlin.de> Date: Sat, 06 Oct 2012 12:52:31 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Bruce Cran References: <20121005135110.GA1339@glenbarber.us> <506EEED9.6060208@quip.cz> <506F8A3D.30104@cran.org.uk> In-Reply-To: <506F8A3D.30104@cran.org.uk> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig83599EFED4833D49E0AB1BCF" X-Originating-IP: 85.178.27.101 Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: FreeBSD 10-CURRENT and 9-STABLE snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 10:52:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig83599EFED4833D49E0AB1BCF Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Am 10/06/12 03:32, schrieb Bruce Cran: > On 05/10/2012 15:29, Miroslav Lachman wrote: >> Unofficial snapshots can be downloaded from >> https://pub.allbsd.org/FreeBSD-snapshots/ for a long time >> (bootonly.iso too) >=20 > I'm baffled as to why those aren't just made official. >=20 Since a couple of time for now, the links shown on the official webpage target into void. it would be easy to replace the great void with a link to a third party with the note that it is a third party. oh --------------enig83599EFED4833D49E0AB1BCF 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.19 (FreeBSD) iQEcBAEBAgAGBQJQcA1vAAoJEOgBcD7A/5N8ulIH/R1fMKgTwZqMTx0mB7veGrTB 4szc+80bJ5wgXHpjriwKVnKp9OlXUb1jjniPK+yakV7xNYGEYKZlCwD66xr+RWDZ TJS2Z9cWAnr5cnVyClaYVKUFxoC7e+ER1nQDlNUbyy0gFdmxgV1h4s+7K7osJYAj 6MTCT9ZzFVPQEN+X4irBHS3kCD1q19H4yscV/TsqF6Zebh+AcMw/uh3g2QYYl5nd N2M0oIg7JjlKGxX0eZ3kc3WPbxWCPQ0WKKUDFYY2p0pJamZIXxmn2AA/uW4jbI9d 2qmZWbS8TtTO1z5XVIc0sobqlOO1DAQL+VyyZ1bKLq96m09guBP0VukXbBT3qQ8= =WDN+ -----END PGP SIGNATURE----- --------------enig83599EFED4833D49E0AB1BCF-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 6 17:17:16 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 115EA1065672 for ; Sat, 6 Oct 2012 17:17:16 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C60708FC08 for ; Sat, 6 Oct 2012 17:17:15 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id DE8067300A; Sat, 6 Oct 2012 19:28:34 +0200 (CEST) Date: Sat, 6 Oct 2012 19:28:34 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20121006172834.GB63649@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: sysctl-controlled key-value store ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 17:17:16 -0000 Hi, in order to control some netmap feature (namely, which interfaces are attached to VALE switches), i would considering the use of a sysctl interface triggering a sysctl-proc, something of the form dev.netmap.switch.xyz=em0 ix1 dev.netmap.switch.foo=ix2 re0 where "xyz" and "foo" are the names of the netmap switch instances. Thing is, right now those names are created dynamically when users configure a netmap port, and I would like to have the same dynamic behaviour with the sysctl, so that an access to a not-yet-existent dev.netmap.switch.xyz node should both create the node and add a value. Is this possible (either now or with a modest modification to the sysctl infrastructure) ? Or should I use a workaround, say have a sysctl node that acts as a 'gate' and the procedure will create (readonly) values e.g. dev.netmap.switch.config="xyz: em0 ix1" # creates dev.netmap.switch.xyz=em0 ix1 dev.netmap.switch.config="xyz: ix1" # updates dev.netmap.switch.xyz=ix1 dev.netmap.switch.config="xyz:" # deletes dev.netmap.switch.xyz= cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Oct 6 23:57:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1573106566B for ; Sat, 6 Oct 2012 23:57:43 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 927728FC12 for ; Sat, 6 Oct 2012 23:57:43 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3296505pad.13 for ; Sat, 06 Oct 2012 16:57:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=BbFnUnE7/n2vB0lNrdBYVNbGLHHKrJlWfvK1Pz94IXU=; b=NgdN2JRfR8I+RQHag9lcBdidrme7QAAPbEQ0KOddUErEINamA+eRXHvToZFIiCezWI kKt0e5KGd7VO6xM6ce7bhRcQovdAoS3oLgujkFvvANRLzvvmSg1jKlTAO+Rr/MERyNVy xtQ37HshSpPQCNyFL8EL3t8nKbXnDZQAo1NEkXaFIk3xWyxNf3N5ggBSIA96QW1T5rpA AE6F9F4QIOzc0MdW0GXxqsVKX7oR5v3FozLPogTrsTr2i2BBTWfrqLdA9OmNMbLwJE30 FIML6xqAaDHSOYStp9cD1aFRxJPQ6N96ELIRX149Hje3WmsDnIeYYvuBVAK3CqbQkaAr 0iAQ== MIME-Version: 1.0 Received: by 10.66.87.132 with SMTP id ay4mr32047453pab.82.1349567862395; Sat, 06 Oct 2012 16:57:42 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.237.41 with HTTP; Sat, 6 Oct 2012 16:57:42 -0700 (PDT) In-Reply-To: <20121006172834.GB63649@onelab2.iet.unipi.it> References: <20121006172834.GB63649@onelab2.iet.unipi.it> Date: Sun, 7 Oct 2012 12:57:42 +1300 X-Google-Sender-Auth: WNBlJgkIAJyYIjr6V850NEXMEW4 Message-ID: From: Andrew Thompson To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmR3PtnVnDmORVRzvfo2N+TjTZ81PXnK9KtVYKaCVfxo2uUnZ8b6MBz3YPmGksGzm25X3z5 Cc: current@freebsd.org Subject: Re: sysctl-controlled key-value store ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 23:57:43 -0000 On 7 October 2012 06:28, Luigi Rizzo wrote: > Hi, > in order to control some netmap feature (namely, which interfaces > are attached to VALE switches), i would considering the use of > a sysctl interface triggering a sysctl-proc, something of the form > > dev.netmap.switch.xyz=em0 ix1 > dev.netmap.switch.foo=ix2 re0 Is it possible to use ifconfig? If a VALE switch was a pseudo interface and you added real interfaces to it then it would be consistent with the current networking fu. Andrew