From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 04:20:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7C8948D5 for ; Sun, 3 Mar 2013 04:20:54 +0000 (UTC) (envelope-from peter@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 D913D283 for ; Sun, 3 Mar 2013 04:20:52 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r234KnXv026142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Mar 2013 15:20:50 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r234Ki2T056927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Mar 2013 15:20:44 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r234KhkF056926; Sun, 3 Mar 2013 15:20:43 +1100 (EST) (envelope-from peter) Date: Sun, 3 Mar 2013 15:20:43 +1100 From: Peter Jeremy To: deeptech71 Subject: Re: access to hard drives is "blocked" by writes to a flash drive Message-ID: <20130303042043.GH286@server.rulingia.com> References: <51323712.5000406@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5" Content-Disposition: inline In-Reply-To: <51323712.5000406@gmail.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 04:20:54 -0000 --O3RTKUHj+75w1tg5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Mar-02 18:29:54 +0100, deeptech71 wrote: >When one of my flash drives is being heavily written to; typically by >``svn update'' on /usr/src, located on the flash drive; the following >can be said about filesystem behavior: > >- ``svn update'' seems to be able to quickly update a bunch of files, > but is then unable to continue for a period of time. This behavior > is cyclical, and cycles several times, depending on the amount of > updating work to be done for a particular run of ``svn update''. This sounds like normal flash behaviour: You can only write to erased blocks. The SSD firmware attempts to keep a free pool of erased blocks but if you write too fast, you empty the free pool and need to wait for the wear-levelling algorithm to move blocks around and erase them. Enabling TRIM (the '-t' flag on tunefs) will help if the drive supports TRIM (if it doesn't, it'll probably just lockup). Otherwise, you need to either put up with it or upgrade to a better SSD. I run into this regularly with the low-end SuperTalent drive in my Netbook but have never seen it with the OCZ Agility4 that I use for L2ARC in my fileserver. --=20 Peter Jeremy --O3RTKUHj+75w1tg5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEyz5sACgkQ/opHv/APuIepRwCgq4di5e+pL8o+ePdFM1SB9cE0 FsoAn0VHmyOLoTUPFsXPVauG6t6iYyYF =8t5b -----END PGP SIGNATURE----- --O3RTKUHj+75w1tg5-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 09:53:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 735C83BE; Sun, 3 Mar 2013 09:53:30 +0000 (UTC) Date: Sun, 3 Mar 2013 09:53:30 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130303095330.GA57026@FreeBSD.org> References: <20130219082302.GA86501@FreeBSD.org> <20130220043739.GA1469@michelle.cdnetworks.com> <20130220060853.GA83110@FreeBSD.org> <20130221083335.GA3226@michelle.cdnetworks.com> <20130221124344.GA93056@FreeBSD.org> <20130222011308.GA3259@michelle.cdnetworks.com> <20130222015607.GC66767@FreeBSD.org> <20130225082344.GC1426@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130225082344.GC1426@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 09:53:30 -0000 On Mon, Feb 25, 2013 at 05:23:44PM +0900, YongHyeon PYUN wrote: > Then have no idea at this moment. Can you try other OS and check > whether it can establish a gigabit link? I did not have a chance to try other OS, because machine paniced during tinderbuilding of a large port. Unfortunately I don't have a backtrace, as I needed to ask my friends to reboot it (I myself do not have direct access to it right now). However, after reboot ale0 come up at 1000baseT , with patched driver (longer delays in ale_phy_reset()). I've reverted this change and rebooted again, but it again come up as GigE. I cannot power down the box completely, since there is no one around who can bring it back right now (press the power button). That said, it looks quite weird to me at this point. Previously it was rebooted a few times, and link speed was always 100mbps. Patching the driver and re-kldloading it did not help, but after reboot, link speed is 1000ish even with unpatched driver. :-/ ./danfe From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 12:00:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 6A1DEED8; Sun, 3 Mar 2013 12:00:10 +0000 (UTC) Date: Sun, 3 Mar 2013 12:00:10 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130303120010.GA84560@FreeBSD.org> References: <20130219082302.GA86501@FreeBSD.org> <20130220043739.GA1469@michelle.cdnetworks.com> <20130220060853.GA83110@FreeBSD.org> <20130221083335.GA3226@michelle.cdnetworks.com> <20130221124344.GA93056@FreeBSD.org> <20130222011308.GA3259@michelle.cdnetworks.com> <20130222015607.GC66767@FreeBSD.org> <20130225082344.GC1426@michelle.cdnetworks.com> <20130303095330.GA57026@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130303095330.GA57026@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 12:00:10 -0000 On Sun, Mar 03, 2013 at 09:53:30AM +0000, Alexey Dokuchaev wrote: > However, after reboot ale0 come up at 1000baseT , with patched > driver (longer delays in ale_phy_reset()). I've reverted this change and > rebooted again, but it again come up as GigE. Alas, after "make kernel", link come up as 100mbps again, playing with delays and rebooting (several times) did not make it GigE. I'm not sure what's actually affecting it. :-( ./danfe From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 13:28:16 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F08EDA3 for ; Sun, 3 Mar 2013 13:28:16 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2E873F for ; Sun, 3 Mar 2013 13:28:15 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UC8xa-000Ngd-SN; Sun, 03 Mar 2013 13:28:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r23DSBsg089816; Sun, 3 Mar 2013 06:28:12 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/MDO4WFekzg7aevDk2COyT Subject: Re: access to hard drives is "blocked" by writes to a flash drive From: Ian Lepore To: Peter Jeremy In-Reply-To: <20130303042043.GH286@server.rulingia.com> References: <51323712.5000406@gmail.com> <20130303042043.GH286@server.rulingia.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Mar 2013 06:28:11 -0700 Message-ID: <1362317291.1195.216.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: deeptech71 , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 13:28:16 -0000 On Sun, 2013-03-03 at 15:20 +1100, Peter Jeremy wrote: > On 2013-Mar-02 18:29:54 +0100, deeptech71 wrote: > > >When one of my flash drives is being heavily written to; typically by > >``svn update'' on /usr/src, located on the flash drive; the following > >can be said about filesystem behavior: > > > >- ``svn update'' seems to be able to quickly update a bunch of files, > > but is then unable to continue for a period of time. This behavior > > is cyclical, and cycles several times, depending on the amount of > > updating work to be done for a particular run of ``svn update''. > > This sounds like normal flash behaviour: You can only write to erased > blocks. The SSD firmware attempts to keep a free pool of erased blocks > but if you write too fast, you empty the free pool and need to wait for > the wear-levelling algorithm to move blocks around and erase them. > > Enabling TRIM (the '-t' flag on tunefs) will help if the drive supports > TRIM (if it doesn't, it'll probably just lockup). Otherwise, you need > to either put up with it or upgrade to a better SSD. > > I run into this regularly with the low-end SuperTalent drive in my > Netbook but have never seen it with the OCZ Agility4 that I use for > L2ARC in my fileserver. > I run into this behavior all the time too, mostly on arm systems that have an sd card or usb thumb driver as their main/only drive. It's especially annoying when you try to launch a program that isn't in the filesystem cache already, and you have to wait 10-20 seconds for it to be read in. I stop just short of calling that "normal" because it seems like we should be able to do better somehow... I don't think the problem is on the flash device itself (like waiting for some big internal cache to drain), it acts more like there aren't enough buffers on the OS side (they're all tied up waiting to be written), or it's a bio-queue sort problem, or maybe it's somehow intentional that writes have precedence over reads (that might make more sense on a system without a big disparity between read and write speed, especially given that writing for the purpose of swapping is important to free up memory). The fact that a huge backlog of writes to a slow flash-based device can block reads from faster devices makes me think this is somehow related to available buffers in the OS. I wonder if this could be one of those situations where reducing the amount of buffers improves responsiveness (if not necessarily overall throughput). -- Ian From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 13:35:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81FD8EFC; Sun, 3 Mar 2013 13:35:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 42F78780; Sun, 3 Mar 2013 13:35:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r23DZJ4l051690; Sun, 3 Mar 2013 08:35:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23DZIuA051689; Sun, 3 Mar 2013 13:35:18 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 13:35:18 GMT Message-Id: <201303031335.r23DZIuA051689@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 13:35:26 -0000 TB --- 2013-03-03 12:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 12:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 12:00:18 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-03 12:00:18 - cleaning the object tree TB --- 2013-03-03 12:00:18 - /usr/local/bin/svn stat /src TB --- 2013-03-03 12:00:22 - At svn revision 247709 TB --- 2013-03-03 12:00:23 - building world TB --- 2013-03-03 12:00:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 12:00:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 12:00:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 12:00:23 - SRCCONF=/dev/null TB --- 2013-03-03 12:00:23 - TARGET=arm TB --- 2013-03-03 12:00:23 - TARGET_ARCH=arm TB --- 2013-03-03 12:00:23 - TZ=UTC TB --- 2013-03-03 12:00:23 - __MAKE_CONF=/dev/null TB --- 2013-03-03 12:00:23 - cd /src TB --- 2013-03-03 12:00:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 12:00:27 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -c kdigest-commands.c cc -O -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/arm.arm/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/arm.arm/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 13:35:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 13:35:18 - ERROR: failed to build world TB --- 2013-03-03 13:35:18 - 4647.85 user 820.34 system 5700.31 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 13:35:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F21BF01; Sun, 3 Mar 2013 13:35:32 +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 37390784; Sun, 3 Mar 2013 13:35:29 +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 r23DZNjQ051774; Sun, 3 Mar 2013 08:35:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23DZNYf051773; Sun, 3 Mar 2013 13:35:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 13:35:23 GMT Message-Id: <201303031335.r23DZNYf051773@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 13:35:32 -0000 TB --- 2013-03-03 12:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 12:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 12:00:18 - starting HEAD tinderbox run for armv6/arm TB --- 2013-03-03 12:00:18 - cleaning the object tree TB --- 2013-03-03 12:00:18 - /usr/local/bin/svn stat /src TB --- 2013-03-03 12:00:22 - At svn revision 247709 TB --- 2013-03-03 12:00:23 - building world TB --- 2013-03-03 12:00:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 12:00:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 12:00:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 12:00:23 - SRCCONF=/dev/null TB --- 2013-03-03 12:00:23 - TARGET=arm TB --- 2013-03-03 12:00:23 - TARGET_ARCH=armv6 TB --- 2013-03-03 12:00:23 - TZ=UTC TB --- 2013-03-03 12:00:23 - __MAKE_CONF=/dev/null TB --- 2013-03-03 12:00:23 - cd /src TB --- 2013-03-03 12:00:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 12:00:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -c kdigest-commands.c cc -O -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/arm.armv6/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/arm.armv6/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/arm.armv6/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/arm.armv6/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/arm.armv6/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/arm.armv6/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/arm.armv6/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/arm.armv6/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 13:35:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 13:35:23 - ERROR: failed to build world TB --- 2013-03-03 13:35:23 - 4643.58 user 820.38 system 5704.56 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 13:35:58 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1BE091D9; Sun, 3 Mar 2013 13:35:58 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D92DF7AA; Sun, 3 Mar 2013 13:35:57 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B40178A57C; Sun, 3 Mar 2013 13:35:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r23DZnYd052868; Sun, 3 Mar 2013 13:35:49 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Lepore Subject: Re: access to hard drives is "blocked" by writes to a flash drive In-reply-to: <1362317291.1195.216.camel@revolution.hippie.lan> From: "Poul-Henning Kamp" References: <51323712.5000406@gmail.com> <20130303042043.GH286@server.rulingia.com> <1362317291.1195.216.camel@revolution.hippie.lan> Date: Sun, 03 Mar 2013 13:35:49 +0000 Message-ID: <52867.1362317749@critter.freebsd.dk> Cc: deeptech71 , freebsd-current@FreeBSD.org, Peter Jeremy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Mar 2013 13:35:58 -0000 Content-Type: text/plain; charset=ISO-8859-1 -------- In message <1362317291.1195.216.camel@revolution.hippie.lan>, Ian Lepore writes : >I run into this behavior all the time too, mostly on arm systems that >have an sd card or usb thumb driver as their main/only drive. This is really a FAQ and I belive I have answered it N times already: There are, broadly speaking, two classes of flash-storage: "Camera-grade" and "the real thing". "Camera-grade" have a very limited "Flash adaptation layer" which typically only can hold one flash-block open for writing at a time, and is typically found in CF and SD cards, USB sticks etc. Some of them gets further upset if the filesystem is not the FAT they expect, because they implement "M-Systems" (patented) trick with monitoring block deletes in FAT to simulate a TRIM facility. A number of products exist with such designs, typically a CF-style, is put behind a SATA-PATA bridge and sold as 2.5" SSD SATA devices. "Transcend" have done this for instance. If you use this class of devices for anything real, gstat will show you I/O write-times of several seconds in periodic pile-ups, even 100 seconds if you are doing something heavy. For various reasons (see: Lemming-syncer) FreeBSD will block all I/O traffic to other disks too, when these pileups gets too bad. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 13:54:58 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B37BF9FE for ; Sun, 3 Mar 2013 13:54:58 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF01862 for ; Sun, 3 Mar 2013 13:54:58 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UC9NL-000F38-Kq; Sun, 03 Mar 2013 13:54:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r23DsmJY089857; Sun, 3 Mar 2013 06:54:48 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18dI2Y7kSR1vC35tfeCWf66 Subject: Re: access to hard drives is "blocked" by writes to a flash drive From: Ian Lepore To: Poul-Henning Kamp In-Reply-To: <52867.1362317749@critter.freebsd.dk> References: <51323712.5000406@gmail.com> <20130303042043.GH286@server.rulingia.com> <1362317291.1195.216.camel@revolution.hippie.lan> <52867.1362317749@critter.freebsd.dk> Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Mar 2013 06:54:47 -0700 Message-ID: <1362318887.1195.221.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: deeptech71 , freebsd-current@FreeBSD.org, Peter Jeremy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Mar 2013 13:54:58 -0000 On Sun, 2013-03-03 at 13:35 +0000, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > -------- > In message <1362317291.1195.216.camel@revolution.hippie.lan>, Ian Lepore writes > : > > >I run into this behavior all the time too, mostly on arm systems that > >have an sd card or usb thumb driver as their main/only drive. > > This is really a FAQ and I belive I have answered it N times already: > > There are, broadly speaking, two classes of flash-storage: "Camera-grade" > and "the real thing". > > "Camera-grade" have a very limited "Flash adaptation layer" which typically > only can hold one flash-block open for writing at a time, and is typically > found in CF and SD cards, USB sticks etc. > > Some of them gets further upset if the filesystem is not the FAT they > expect, because they implement "M-Systems" (patented) trick with monitoring > block deletes in FAT to simulate a TRIM facility. > > A number of products exist with such designs, typically a CF-style, is > put behind a SATA-PATA bridge and sold as 2.5" SSD SATA devices. > "Transcend" have done this for instance. > > If you use this class of devices for anything real, gstat will show > you I/O write-times of several seconds in periodic pile-ups, even > 100 seconds if you are doing something heavy. > > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > traffic to other disks too, when these pileups gets too bad. Hmmm, so the problem has been known and unfixed for 10 years. That's not encouraging. One of the messages in the lemming-syncer mail thread might explain why I've been seeing this a lot lately in hobbyist work, but not so much at $work where we use sd cards heavily... we use very short syncer timeouts on SD and CF storage at $work: kern.metadelay: 3 kern.dirdelay: 4 kern.filedelay: 5 I might play with similar settings on some of my arm boards here. -- Ian From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 14:10:43 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0038FE11; Sun, 3 Mar 2013 14:10:42 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BAF8B8E3; Sun, 3 Mar 2013 14:10:42 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id BD0C389EAF; Sun, 3 Mar 2013 14:10:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r23EAea5052962; Sun, 3 Mar 2013 14:10:40 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Lepore Subject: Re: access to hard drives is "blocked" by writes to a flash drive In-reply-to: <1362318887.1195.221.camel@revolution.hippie.lan> From: "Poul-Henning Kamp" References: <51323712.5000406@gmail.com> <20130303042043.GH286@server.rulingia.com> <1362317291.1195.216.camel@revolution.hippie.lan> <52867.1362317749@critter.freebsd.dk> <1362318887.1195.221.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 03 Mar 2013 14:10:40 +0000 Message-ID: <52961.1362319840@critter.freebsd.dk> Cc: deeptech71 , freebsd-current@FreeBSD.org, Peter Jeremy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Mar 2013 14:10:43 -0000 In message <1362318887.1195.221.camel@revolution.hippie.lan>, Ian Lepore writes : >Hmmm, so the problem has been known and unfixed for 10 years. It's hard to fix, because a lot of stuff has been tangled up cyclically in the disk-I/O relevant layers. The "umapped buf" stuff which is (finally!) happening, is the path to fixing it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 14:28:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 15A271C4; Sun, 3 Mar 2013 14:28:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5050D969; Sun, 3 Mar 2013 14:28:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r23ESQdl037491; Sun, 3 Mar 2013 09:28:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23ESQrc037490; Sun, 3 Mar 2013 14:28:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 14:28:26 GMT Message-Id: <201303031428.r23ESQrc037490@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 14:28:28 -0000 TB --- 2013-03-03 12:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 12:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 12:00:18 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-03 12:00:18 - cleaning the object tree TB --- 2013-03-03 12:00:18 - /usr/local/bin/svn stat /src TB --- 2013-03-03 12:00:22 - At svn revision 247709 TB --- 2013-03-03 12:00:23 - building world TB --- 2013-03-03 12:00:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 12:00:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 12:00:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 12:00:23 - SRCCONF=/dev/null TB --- 2013-03-03 12:00:23 - TARGET=i386 TB --- 2013-03-03 12:00:23 - TARGET_ARCH=i386 TB --- 2013-03-03 12:00:23 - TZ=UTC TB --- 2013-03-03 12:00:23 - __MAKE_CONF=/dev/null TB --- 2013-03-03 12:00:23 - cd /src TB --- 2013-03-03 12:00:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 12:00:27 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -Qunused-arguments -fstack-protector -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/i386.i386/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/i386.i386/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/i386.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/i386.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/i386.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/i386.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/i386.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/i386.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 14:28:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 14:28:26 - ERROR: failed to build world TB --- 2013-03-03 14:28:26 - 7425.98 user 995.81 system 8888.00 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 14:28:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 75DEC2C5; Sun, 3 Mar 2013 14:28:35 +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 35BDE96E; Sun, 3 Mar 2013 14:28:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r23ESY5q037736; Sun, 3 Mar 2013 09:28:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23ESY0Y037735; Sun, 3 Mar 2013 14:28:34 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 14:28:34 GMT Message-Id: <201303031428.r23ESY0Y037735@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 14:28:35 -0000 TB --- 2013-03-03 12:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 12:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 12:00:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-03-03 12:00:18 - cleaning the object tree TB --- 2013-03-03 12:00:18 - /usr/local/bin/svn stat /src TB --- 2013-03-03 12:00:22 - At svn revision 247709 TB --- 2013-03-03 12:00:23 - building world TB --- 2013-03-03 12:00:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 12:00:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 12:00:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 12:00:23 - SRCCONF=/dev/null TB --- 2013-03-03 12:00:23 - TARGET=amd64 TB --- 2013-03-03 12:00:23 - TARGET_ARCH=amd64 TB --- 2013-03-03 12:00:23 - TZ=UTC TB --- 2013-03-03 12:00:23 - __MAKE_CONF=/dev/null TB --- 2013-03-03 12:00:23 - cd /src TB --- 2013-03-03 12:00:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 12:00:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -Qunused-arguments -fstack-protector -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/amd64.amd64/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/amd64.amd64/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/amd64.amd64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/amd64.amd64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/amd64.amd64/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/amd64.amd64/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/amd64.amd64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/amd64.amd64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 14:28:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 14:28:34 - ERROR: failed to build world TB --- 2013-03-03 14:28:34 - 7427.40 user 985.48 system 8896.12 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 14:40:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA8264AD; Sun, 3 Mar 2013 14:40:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3EFB79D6; Sun, 3 Mar 2013 14:40:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r23EeKxD017696; Sun, 3 Mar 2013 09:40:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23EeKw8017677; Sun, 3 Mar 2013 14:40:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 14:40:20 GMT Message-Id: <201303031440.r23EeKw8017677@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 14:40:22 -0000 TB --- 2013-03-03 13:35:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 13:35:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 13:35:23 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-03-03 13:35:23 - cleaning the object tree TB --- 2013-03-03 13:35:23 - /usr/local/bin/svn stat /src TB --- 2013-03-03 13:35:26 - At svn revision 247709 TB --- 2013-03-03 13:35:27 - building world TB --- 2013-03-03 13:35:27 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 13:35:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 13:35:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 13:35:27 - SRCCONF=/dev/null TB --- 2013-03-03 13:35:27 - TARGET=ia64 TB --- 2013-03-03 13:35:27 - TARGET_ARCH=ia64 TB --- 2013-03-03 13:35:27 - TZ=UTC TB --- 2013-03-03 13:35:27 - __MAKE_CONF=/dev/null TB --- 2013-03-03 13:35:27 - cd /src TB --- 2013-03-03 13:35:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 13:35:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -c kdigest-commands.c cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/ia64.ia64/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/ia64.ia64/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/ia64.ia64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/ia64.ia64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/ia64.ia64/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/ia64.ia64/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/ia64.ia64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/ia64.ia64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 14:40:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 14:40:20 - ERROR: failed to build world TB --- 2013-03-03 14:40:20 - 3127.15 user 527.43 system 3896.68 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 15:16:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 40C585BC; Sun, 3 Mar 2013 15:16:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 00E0AB1D; Sun, 3 Mar 2013 15:16:47 +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 r23FGlp1062080; Sun, 3 Mar 2013 10:16:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23FGlLi062077; Sun, 3 Mar 2013 15:16:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 15:16:47 GMT Message-Id: <201303031516.r23FGlLi062077@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 15:16:48 -0000 TB --- 2013-03-03 14:28:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 14:28:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 14:28:26 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-03 14:28:26 - cleaning the object tree TB --- 2013-03-03 14:28:27 - /usr/local/bin/svn stat /src TB --- 2013-03-03 14:28:38 - At svn revision 247709 TB --- 2013-03-03 14:28:39 - building world TB --- 2013-03-03 14:28:39 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 14:28:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 14:28:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 14:28:39 - SRCCONF=/dev/null TB --- 2013-03-03 14:28:39 - TARGET=mips TB --- 2013-03-03 14:28:39 - TARGET_ARCH=mips TB --- 2013-03-03 14:28:39 - TZ=UTC TB --- 2013-03-03 14:28:39 - __MAKE_CONF=/dev/null TB --- 2013-03-03 14:28:39 - cd /src TB --- 2013-03-03 14:28:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 14:28:44 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -c kdigest-commands.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/mips.mips/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/mips.mips/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/mips.mips/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/mips.mips/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/mips.mips/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/mips.mips/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/mips.mips/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 15:16:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 15:16:47 - ERROR: failed to build world TB --- 2013-03-03 15:16:47 - 2090.98 user 518.67 system 2900.20 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 15:16:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C43A6A5; Sun, 3 Mar 2013 15:16:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 44AE0B1E; Sun, 3 Mar 2013 15:16:47 +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 r23FGkOX062041; Sun, 3 Mar 2013 10:16:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23FGkoY062040; Sun, 3 Mar 2013 15:16:46 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 15:16:46 GMT Message-Id: <201303031516.r23FGkoY062040@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 15:16:50 -0000 TB --- 2013-03-03 14:28:35 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 14:28:35 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 14:28:35 - starting HEAD tinderbox run for mips64/mips TB --- 2013-03-03 14:28:35 - cleaning the object tree TB --- 2013-03-03 14:28:35 - /usr/local/bin/svn stat /src TB --- 2013-03-03 14:28:38 - At svn revision 247709 TB --- 2013-03-03 14:28:39 - building world TB --- 2013-03-03 14:28:39 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 14:28:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 14:28:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 14:28:39 - SRCCONF=/dev/null TB --- 2013-03-03 14:28:39 - TARGET=mips TB --- 2013-03-03 14:28:39 - TARGET_ARCH=mips64 TB --- 2013-03-03 14:28:39 - TZ=UTC TB --- 2013-03-03 14:28:39 - __MAKE_CONF=/dev/null TB --- 2013-03-03 14:28:39 - cd /src TB --- 2013-03-03 14:28:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 14:28:44 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -c kdigest-commands.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips64/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/mips.mips64/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/mips.mips64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/mips.mips64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/mips.mips64/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/mips.mips64/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/mips.mips64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/mips.mips64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 15:16:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 15:16:46 - ERROR: failed to build world TB --- 2013-03-03 15:16:46 - 2099.05 user 521.19 system 2891.63 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 16:08:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E7F36D6; Sun, 3 Mar 2013 16:08:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7BDDE1; Sun, 3 Mar 2013 16:08:21 +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 r23G8KoF084929; Sun, 3 Mar 2013 11:08:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23G8KgO084928; Sun, 3 Mar 2013 16:08:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 16:08:20 GMT Message-Id: <201303031608.r23G8KgO084928@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 16:08:21 -0000 TB --- 2013-03-03 13:35:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 13:35:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 13:35:19 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-03 13:35:19 - cleaning the object tree TB --- 2013-03-03 13:35:19 - /usr/local/bin/svn stat /src TB --- 2013-03-03 13:35:22 - At svn revision 247709 TB --- 2013-03-03 13:35:23 - building world TB --- 2013-03-03 13:35:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 13:35:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 13:35:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 13:35:23 - SRCCONF=/dev/null TB --- 2013-03-03 13:35:23 - TARGET=pc98 TB --- 2013-03-03 13:35:23 - TARGET_ARCH=i386 TB --- 2013-03-03 13:35:23 - TZ=UTC TB --- 2013-03-03 13:35:23 - __MAKE_CONF=/dev/null TB --- 2013-03-03 13:35:23 - cd /src TB --- 2013-03-03 13:35:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 13:35:27 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -Qunused-arguments -fstack-protector -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/pc98.i386/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/pc98.i386/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/pc98.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/pc98.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/pc98.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/pc98.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/pc98.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/pc98.i386/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 16:08:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 16:08:20 - ERROR: failed to build world TB --- 2013-03-03 16:08:20 - 7676.16 user 987.78 system 9181.20 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 16:08:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EFF107E4; Sun, 3 Mar 2013 16:08:35 +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 C86F5DE2; Sun, 3 Mar 2013 16:08:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r23G8ZAa085098; Sun, 3 Mar 2013 11:08:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23G8ZtO085097; Sun, 3 Mar 2013 16:08:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 16:08:35 GMT Message-Id: <201303031608.r23G8ZtO085097@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 16:08:36 -0000 TB --- 2013-03-03 15:16:47 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 15:16:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 15:16:47 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-03-03 15:16:47 - cleaning the object tree TB --- 2013-03-03 15:16:47 - /usr/local/bin/svn stat /src TB --- 2013-03-03 15:16:50 - At svn revision 247709 TB --- 2013-03-03 15:16:51 - building world TB --- 2013-03-03 15:16:51 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 15:16:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 15:16:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 15:16:51 - SRCCONF=/dev/null TB --- 2013-03-03 15:16:51 - TARGET=sparc64 TB --- 2013-03-03 15:16:51 - TARGET_ARCH=sparc64 TB --- 2013-03-03 15:16:51 - TZ=UTC TB --- 2013-03-03 15:16:51 - __MAKE_CONF=/dev/null TB --- 2013-03-03 15:16:51 - cd /src TB --- 2013-03-03 15:16:51 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 15:16:56 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -fstack-protector -c kdigest-commands.c cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -fstack-protector -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/sparc64.sparc64/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/sparc64.sparc64/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/sparc64.sparc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/sparc64.sparc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/sparc64.sparc64/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/sparc64.sparc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/sparc64.sparc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/sparc64.sparc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 16:08:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 16:08:35 - ERROR: failed to build world TB --- 2013-03-03 16:08:35 - 2393.22 user 442.20 system 3107.91 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 16:43:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2527C2D0; Sun, 3 Mar 2013 16:43:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D9BC8EF2; Sun, 3 Mar 2013 16:43:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r23Ghf06023988; Sun, 3 Mar 2013 11:43:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23GhfrR023987; Sun, 3 Mar 2013 16:43:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 16:43:41 GMT Message-Id: <201303031643.r23GhfrR023987@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 16:43:43 -0000 TB --- 2013-03-03 14:40:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 14:40:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 14:40:20 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-03-03 14:40:20 - cleaning the object tree TB --- 2013-03-03 14:40:20 - /usr/local/bin/svn stat /src TB --- 2013-03-03 14:40:23 - At svn revision 247709 TB --- 2013-03-03 14:40:24 - building world TB --- 2013-03-03 14:40:24 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 14:40:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 14:40:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 14:40:24 - SRCCONF=/dev/null TB --- 2013-03-03 14:40:24 - TARGET=powerpc TB --- 2013-03-03 14:40:24 - TARGET_ARCH=powerpc TB --- 2013-03-03 14:40:24 - TZ=UTC TB --- 2013-03-03 14:40:24 - __MAKE_CONF=/dev/null TB --- 2013-03-03 14:40:24 - cd /src TB --- 2013-03-03 14:40:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 14:40:29 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -fstack-protector -c kdigest-commands.c cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -fstack-protector -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/powerpc.powerpc/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/powerpc.powerpc/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/powerpc.powerpc/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/powerpc.powerpc/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/powerpc.powerpc/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/powerpc.powerpc/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/powerpc.powerpc/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/powerpc.powerpc/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 16:43:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 16:43:41 - ERROR: failed to build world TB --- 2013-03-03 16:43:41 - 6364.33 user 820.51 system 7400.86 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 17:18:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14032A7A; Sun, 3 Mar 2013 17:18:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E0113FBB; Sun, 3 Mar 2013 17:18:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r23HIJmn061038; Sun, 3 Mar 2013 12:18:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r23HIJJU061037; Sun, 3 Mar 2013 17:18:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 17:18:19 GMT Message-Id: <201303031718.r23HIJJU061037@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 17:18:21 -0000 TB --- 2013-03-03 15:16:46 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 15:16:46 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-03 15:16:46 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-03-03 15:16:46 - cleaning the object tree TB --- 2013-03-03 15:16:46 - /usr/local/bin/svn stat /src TB --- 2013-03-03 15:16:50 - At svn revision 247709 TB --- 2013-03-03 15:16:51 - building world TB --- 2013-03-03 15:16:51 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 15:16:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 15:16:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 15:16:51 - SRCCONF=/dev/null TB --- 2013-03-03 15:16:51 - TARGET=powerpc TB --- 2013-03-03 15:16:51 - TARGET_ARCH=powerpc64 TB --- 2013-03-03 15:16:51 - TZ=UTC TB --- 2013-03-03 15:16:51 - __MAKE_CONF=/dev/null TB --- 2013-03-03 15:16:51 - cd /src TB --- 2013-03-03 15:16:51 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 15:16:56 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -fstack-protector -c kdigest-commands.c cc -O2 -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -fstack-protector -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/powerpc.powerpc64/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/powerpc.powerpc64/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/powerpc.powerpc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/powerpc.powerpc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/powerpc.powerpc64/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/powerpc.powerpc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/powerpc.powerpc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/powerpc.powerpc64/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 17:18:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 17:18:19 - ERROR: failed to build world TB --- 2013-03-03 17:18:19 - 6426.06 user 726.63 system 7292.84 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 19:25:11 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D183A39C; Sun, 3 Mar 2013 19:25:11 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) by mx1.freebsd.org (Postfix) with ESMTP id 933DE38F; Sun, 3 Mar 2013 19:25:11 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1UCEWs-0002JE-Fc; Sun, 03 Mar 2013 22:25:03 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:Subject:Cc:To:From; bh=uvH//GqQpU4SA/N20OilrWPutBBQJzkueeylrGKu62U=; b=WH9lYQltB1VqqivYOBTTuNC1Cnc143Tx3MMhj+yO1PopjNPf4/FUBci8T72z8SN/c69qIRNXYSqVwkoR1XrTYDAOD32z7oR+fSv2JX1+XWi3FIPUY/ynxPBsNWloO1XIsoov37UuvqwOOQda3zAGumDHJEWUbXC0fZT+h6YgLrA=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1UCEUA-000Fgt-O5; Sun, 03 Mar 2013 19:22:16 +0000 From: Jan Beich To: Pawel Jakub Dawidek Subject: Re: HEADS UP: Capsicum overhaul. Date: Sun, 03 Mar 2013 22:18:02 +0300 References: <20130302020544.GF16664@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1UCEUA-000Fgt-O5@internal.tormail.org> Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 19:25:11 -0000 Pawel Jakub Dawidek writes: > I just committed pretty large change that affects not only Capsicum, but > also descriptor handling code in the kernel. If you will find some > strange problems after r243611 (like panics, unexpected application > errors, etc.) I may be at fault. I'll be looking at current@ mailing > list closly, so report here if you find problems that look related to my > change. tmux started to behave weirdly, sometimes failing to attach: $ printenv PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin OLDPWD=/ DISPLAY=:0 PWD=/home/foo TERM=xterm USER=foo HOME=/home/foo SHELL=/bin/sh $ ktrace -i tmux -L test -f /dev/null $ echo $? 1 $ kdump -r | pastebinit -a 'tmux fails to attach' http://pastebin.com/U3nCPrFY $ env -i TERM=$TERM ktrace -i /usr/local/bin/tmux -L test -f /dev/null $ ^D [exited] $ kdump -r | pastebinit -a 'tmux fails to attach (workaround)' http://pastebin.com/w1dsUAU4 I've tried so far: * booting allbsd.org snapshot -> no joy * enabling capsicum options -> no joy * reverting recent capsicum commits -> works fine From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 19:43:40 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB9DA949 for ; Sun, 3 Mar 2013 19:43:40 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 88EA165B for ; Sun, 3 Mar 2013 19:43:40 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 2391C2B4; Sun, 3 Mar 2013 20:40:29 +0100 (CET) Date: Sun, 3 Mar 2013 20:44:48 +0100 From: Pawel Jakub Dawidek To: Jan Beich Subject: Re: HEADS UP: Capsicum overhaul. Message-ID: <20130303194448.GH1883@garage.freebsd.pl> References: <20130302020544.GF16664@garage.freebsd.pl> <1UCEUA-000Fgt-O5@internal.tormail.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82evfD9Ogz2JrdWZ" Content-Disposition: inline In-Reply-To: <1UCEUA-000Fgt-O5@internal.tormail.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 19:43:40 -0000 --82evfD9Ogz2JrdWZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 03, 2013 at 10:18:02PM +0300, Jan Beich wrote: > Pawel Jakub Dawidek writes: >=20 > > I just committed pretty large change that affects not only Capsicum, but > > also descriptor handling code in the kernel. If you will find some > > strange problems after r243611 (like panics, unexpected application > > errors, etc.) I may be at fault. I'll be looking at current@ mailing > > list closly, so report here if you find problems that look related to my > > change. >=20 > tmux started to behave weirdly, sometimes failing to attach: >=20 > $ printenv > PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin > OLDPWD=3D/ > DISPLAY=3D:0 > PWD=3D/home/foo > TERM=3Dxterm > USER=3Dfoo > HOME=3D/home/foo > SHELL=3D/bin/sh >=20 > $ ktrace -i tmux -L test -f /dev/null > $ echo $? > 1 > $ kdump -r | pastebinit -a 'tmux fails to attach' > http://pastebin.com/U3nCPrFY >=20 > $ env -i TERM=3D$TERM ktrace -i /usr/local/bin/tmux -L test -f /dev/null > $ ^D > [exited] > $ kdump -r | pastebinit -a 'tmux fails to attach (workaround)' > http://pastebin.com/w1dsUAU4 >=20 > I've tried so far: >=20 > * booting allbsd.org snapshot -> no joy > * enabling capsicum options -> no joy > * reverting recent capsicum commits -> works fine Yes, it was already reported to me and I'm investigating the problem. Thanks. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --82evfD9Ogz2JrdWZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEzqDAACgkQForvXbEpPzRc2gCeNdRmZFUUzr35ud3XFmBdST5a +6EAoM/CkuVJzMweSvFc7O38x8D2N9Jm =v2/c -----END PGP SIGNATURE----- --82evfD9Ogz2JrdWZ-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 20:28:29 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A58865A7; Sun, 3 Mar 2013 20:28:29 +0000 (UTC) (envelope-from prvs=1774e98e91=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0ADAA7C9; Sun, 3 Mar 2013 20:28:28 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002512105.msg; Sun, 03 Mar 2013 20:28:21 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 03 Mar 2013 20:28:21 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=1774e98e91=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <7424F21A82384B67A5A5C7B3B791CDE5@multiplay.co.uk> From: "Steven Hartland" To: "Ian Lepore" , "Poul-Henning Kamp" References: <51323712.5000406@gmail.com> <20130303042043.GH286@server.rulingia.com> <1362317291.1195.216.camel@revolution.hippie.lan> <52867.1362317749@critter.freebsd.dk> <1362318887.1195.221.camel@revolution.hippie.lan> Subject: Re: access to hard drives is "blocked" by writes to a flash drive Date: Sun, 3 Mar 2013 20:28:11 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: deeptech71 , freebsd-current@FreeBSD.org, Peter Jeremy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 03 Mar 2013 20:28:29 -0000 ----- Original Message ----- From: "Ian Lepore" To: "Poul-Henning Kamp" Cc: "deeptech71" ; ; "Peter Jeremy" Sent: Sunday, March 03, 2013 1:54 PM Subject: Re: access to hard drives is "blocked" by writes to a flash drive > On Sun, 2013-03-03 at 13:35 +0000, Poul-Henning Kamp wrote: >> Content-Type: text/plain; charset=ISO-8859-1 >> -------- >> In message <1362317291.1195.216.camel@revolution.hippie.lan>, Ian Lepore writes >> : >> >> >I run into this behavior all the time too, mostly on arm systems that >> >have an sd card or usb thumb driver as their main/only drive. >> >> This is really a FAQ and I belive I have answered it N times already: >> >> There are, broadly speaking, two classes of flash-storage: "Camera-grade" >> and "the real thing". >> >> "Camera-grade" have a very limited "Flash adaptation layer" which typically >> only can hold one flash-block open for writing at a time, and is typically >> found in CF and SD cards, USB sticks etc. >> >> Some of them gets further upset if the filesystem is not the FAT they >> expect, because they implement "M-Systems" (patented) trick with monitoring >> block deletes in FAT to simulate a TRIM facility. >> >> A number of products exist with such designs, typically a CF-style, is >> put behind a SATA-PATA bridge and sold as 2.5" SSD SATA devices. >> "Transcend" have done this for instance. >> >> If you use this class of devices for anything real, gstat will show >> you I/O write-times of several seconds in periodic pile-ups, even >> 100 seconds if you are doing something heavy. >> >> For various reasons (see: Lemming-syncer) FreeBSD will block all I/O >> traffic to other disks too, when these pileups gets too bad. > > Hmmm, so the problem has been known and unfixed for 10 years. That's > not encouraging. One of the messages in the lemming-syncer mail thread > might explain why I've been seeing this a lot lately in hobbyist work, > but not so much at $work where we use sd cards heavily... we use very > short syncer timeouts on SD and CF storage at $work: > > kern.metadelay: 3 > kern.dirdelay: 4 > kern.filedelay: 5 > > I might play with similar settings on some of my arm boards here. Interesting, are these relevant for all filesystems e.g. ZFS? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 23:43:59 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D86E46BF for ; Sun, 3 Mar 2013 23:43:59 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8855CF08 for ; Sun, 3 Mar 2013 23:43:59 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id F3BC3333; Mon, 4 Mar 2013 00:40:53 +0100 (CET) Date: Mon, 4 Mar 2013 00:45:13 +0100 From: Pawel Jakub Dawidek To: Jan Beich Subject: Re: HEADS UP: Capsicum overhaul. Message-ID: <20130303234513.GJ1883@garage.freebsd.pl> References: <20130302020544.GF16664@garage.freebsd.pl> <1UCEUA-000Fgt-O5@internal.tormail.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BEa57a89OpeoUzGD" Content-Disposition: inline In-Reply-To: <1UCEUA-000Fgt-O5@internal.tormail.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 23:43:59 -0000 --BEa57a89OpeoUzGD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 03, 2013 at 10:18:02PM +0300, Jan Beich wrote: > Pawel Jakub Dawidek writes: >=20 > > I just committed pretty large change that affects not only Capsicum, but > > also descriptor handling code in the kernel. If you will find some > > strange problems after r243611 (like panics, unexpected application > > errors, etc.) I may be at fault. I'll be looking at current@ mailing > > list closly, so report here if you find problems that look related to my > > change. >=20 > tmux started to behave weirdly, sometimes failing to attach: I committed a work-around in r247740, but the root of the problem is yet to be found. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --BEa57a89OpeoUzGD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEz4IkACgkQForvXbEpPzRv0wCgnsROCoiJZxU5ym5CC2Rp+j+t o7MAoI+S8YKk/ttcZqHD9rM7Ye/3A0GX =Fa8N -----END PGP SIGNATURE----- --BEa57a89OpeoUzGD-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 23:47:03 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 806188BE; Sun, 3 Mar 2013 23:47:03 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5452CF32; Sun, 3 Mar 2013 23:47:03 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 0A12F6103; Sun, 3 Mar 2013 18:47:01 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=fNHgRStR4JofvG4KTOW9BtJAWLC9ZnUKzoUiBeTPUnHosTjsz1S5OVO+PKA2dMDux niMJ3J2i0wE9V8nBlHowp4E0bSJ2xYnl04flolJcUOMd+PTm8lYo7Gy2znO76J/ Message-ID: <5133E0F4.6050807@protected-networks.net> Date: Sun, 03 Mar 2013 18:47:00 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130302 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek , current@FreeBSD.org Subject: kernel build failure X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 23:47:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SVN r247736 prompts this .. cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99 -Wall - -Wredundant-decls -Wnested-externs -Wstrict-prototypes - -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef - -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs - -fdiagnostics-show-option -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_global.h -mno-aes -mno-avx - -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/uipc_usrreq.c /usr/src/sys/kern/uipc_usrreq.c:1689:18: error: use of undeclared identifier 'fdep'; did you mean 'fde'? filecaps_free(&fdep->fde_caps); ^~~~ fde /usr/src/sys/kern/uipc_usrreq.c:1682:36: note: 'fde' declared here unp_freerights(struct filedescent *fde, int fdcount) ^ 1 error generated. *** [uipc_usrreq.o] Error code 1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEARECAAYFAlEz4PQACgkQQv9rrgRC1JL6KACgjI2VCpCeKJCAaZIS+EBRP93N xN8An1s0Q9CNgIP1F5Ep6ypuLQ9Agxde =2ptT -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Mar 3 23:50:53 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5375A47 for ; Sun, 3 Mar 2013 23:50:53 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id B22FEF54 for ; Sun, 3 Mar 2013 23:50:53 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id BF216338; Mon, 4 Mar 2013 00:47:48 +0100 (CET) Date: Mon, 4 Mar 2013 00:52:08 +0100 From: Pawel Jakub Dawidek To: Michael Butler Subject: Re: kernel build failure Message-ID: <20130303235208.GK1883@garage.freebsd.pl> References: <5133E0F4.6050807@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+RZeZVNR8VILNfK" Content-Disposition: inline In-Reply-To: <5133E0F4.6050807@protected-networks.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 23:50:54 -0000 --x+RZeZVNR8VILNfK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 03, 2013 at 06:47:00PM -0500, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > SVN r247736 prompts this .. >=20 > cc -c -O2 -pipe -fno-strict-aliasing -march=3Dpentium4 -std=3Dc99 -Wall > - -Wredundant-decls -Wnested-externs -Wstrict-prototypes > - -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > - -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > - -fdiagnostics-show-option -Wno-error-tautological-compare > - -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. > - -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > - -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-aes -mno-avx > - -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror > /usr/src/sys/kern/uipc_usrreq.c > /usr/src/sys/kern/uipc_usrreq.c:1689:18: error: use of undeclared > identifier 'fdep'; did you mean 'fde'? > filecaps_free(&fdep->fde_caps); > ^~~~ > fde > /usr/src/sys/kern/uipc_usrreq.c:1682:36: note: 'fde' declared here > unp_freerights(struct filedescent *fde, int fdcount) > ^ > 1 error generated. This was because I divided larger change into smaller changes. r247738 should be fine. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --x+RZeZVNR8VILNfK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEz4igACgkQForvXbEpPzQX/QCfRzfm35iV5bhhY6/fdCL/3bDK H30An3ATKBqirvsXXQLhqT4NR1sq0+gT =8HFA -----END PGP SIGNATURE----- --x+RZeZVNR8VILNfK-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 00:50:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF2C5339; Mon, 4 Mar 2013 00:50:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by mx1.freebsd.org (Postfix) with ESMTP id A220C132; Mon, 4 Mar 2013 00:50:57 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id xa12so2752742pbc.36 for ; Sun, 03 Mar 2013 16:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Bs2Y0WxD/vQFCDCdxwJZpCXy3R4bk1P2k4BR6gCT68E=; b=s8IfYgTRD3uqX56/8bbqIOyzKENRuA/yHOAHh7cLqVc2hWZgAj0qxcPH56/wnoP/YH UIE5b1kBkuH4SqxliHqSvCZriB4EFaLC5Zvq3QM/YIu/UCiCZw4jESLW4UxvyRehkEfL Vd+0pp6J0qR7yZcRdSeUVOAZYaFB1hlsIvQv09uDhg+KuH6hKvQ/W04XA5qHAOJ7rC3N 7xj4oiJ8hc97n0/DErWImrq+x/JhTkDpc8GFejL2qgUaN+3Mg4poF4SCWWgtsBpzOnfH PLhLSfxW7Nx3qfRD0Wo/0iIBcbnEUzcNA9Tru4jx3v4GZ3tdXOx8bJGtcc3BD1Wb+vwL GmHw== X-Received: by 10.68.204.234 with SMTP id lb10mr25539544pbc.64.1362358251294; Sun, 03 Mar 2013 16:50:51 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id u10sm21713972pax.14.2013.03.03.16.50.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Mar 2013 16:50:50 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 04 Mar 2013 09:50:44 +0900 From: YongHyeon PYUN Date: Mon, 4 Mar 2013 09:50:44 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304005044.GA4589@michelle.cdnetworks.com> References: <20130219082302.GA86501@FreeBSD.org> <20130220043739.GA1469@michelle.cdnetworks.com> <20130220060853.GA83110@FreeBSD.org> <20130221083335.GA3226@michelle.cdnetworks.com> <20130221124344.GA93056@FreeBSD.org> <20130222011308.GA3259@michelle.cdnetworks.com> <20130222015607.GC66767@FreeBSD.org> <20130225082344.GC1426@michelle.cdnetworks.com> <20130303095330.GA57026@FreeBSD.org> <20130303120010.GA84560@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <20130303120010.GA84560@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 00:50:57 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Mar 03, 2013 at 12:00:10PM +0000, Alexey Dokuchaev wrote: > On Sun, Mar 03, 2013 at 09:53:30AM +0000, Alexey Dokuchaev wrote: > > However, after reboot ale0 come up at 1000baseT , with patched > > driver (longer delays in ale_phy_reset()). I've reverted this change and > > rebooted again, but it again come up as GigE. > > Alas, after "make kernel", link come up as 100mbps again, playing with > delays and rebooting (several times) did not make it GigE. I'm not sure > what's actually affecting it. :-( Would you try attached patch? > > ./danfe --OXfL5xGRrasGEqWY Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="atphy.diff" Index: sys/dev/mii/atphy.c =================================================================== --- sys/dev/mii/atphy.c (revision 247382) +++ sys/dev/mii/atphy.c (working copy) @@ -287,9 +287,11 @@ atphy_reset(struct mii_softc *sc) uint32_t reg; int i; +#if 0 /* Take PHY out of power down mode. */ PHY_WRITE(sc, 29, 0x29); PHY_WRITE(sc, 30, 0); +#endif reg = PHY_READ(sc, ATPHY_SCR); /* Enable automatic crossover. */ --OXfL5xGRrasGEqWY-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 01:53:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id C28E9EAD; Mon, 4 Mar 2013 01:53:44 +0000 (UTC) Date: Mon, 4 Mar 2013 01:53:44 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304015344.GA62059@FreeBSD.org> References: <20130220043739.GA1469@michelle.cdnetworks.com> <20130220060853.GA83110@FreeBSD.org> <20130221083335.GA3226@michelle.cdnetworks.com> <20130221124344.GA93056@FreeBSD.org> <20130222011308.GA3259@michelle.cdnetworks.com> <20130222015607.GC66767@FreeBSD.org> <20130225082344.GC1426@michelle.cdnetworks.com> <20130303095330.GA57026@FreeBSD.org> <20130303120010.GA84560@FreeBSD.org> <20130304005044.GA4589@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130304005044.GA4589@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 01:53:44 -0000 On Mon, Mar 04, 2013 at 09:50:44AM +0900, YongHyeon PYUN wrote: > On Sun, Mar 03, 2013 at 12:00:10PM +0000, Alexey Dokuchaev wrote: > > Alas, after "make kernel", link come up as 100mbps again, playing with > > delays and rebooting (several times) did not make it GigE. I'm not sure > > what's actually affecting it. :-( > > Would you try attached patch? Yes, it did help. With 2000us delays (I didn't revert them since you didn't ask), machine came up after "make kernel" and reboot with ale0 in GigE mode. I'll be happy to conduct more tests for you, if needed, thanks! ./danfe From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 02:11:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 93EF244C; Mon, 4 Mar 2013 02:11:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 53F85336; Mon, 4 Mar 2013 02:11:12 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id wz12so2769425pbc.31 for ; Sun, 03 Mar 2013 18:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=WCHa52rQHwKD+SlWp0b8tBNCxFZW+YWW5BIBUEPA70c=; b=Ug9jPSAKGsLSUV3P6eLTfV/9QwYOc3umTyLALXE8v5SqM39jNZTPyK6uRmkAeHnfv8 zeHiIDcQJvFfwaJWu0yDZYSUv3Kovm9URdWI0kKnID1gCmg5z6gpK/nDA4nS0knMCPeQ NrphZymTOCaawN+DZmudkIbBGhEKfv5tmbBQ+SwP9YEQ0HU5+tlfJBOpxBMjzeUDEKwa 2ZEQOmCJfv6G4nRReHkt/OgiqTAOKVTpWBq1n/reyXB5K5XRc963JTjblyKeB8kWUYJW nwuB/b77txO22rsysNf85NRwhcus/g3IU0wqma29XH/QFx4sBy1wVvOYCSClmK3KaSLW xZoQ== X-Received: by 10.66.79.135 with SMTP id j7mr30464766pax.0.1362363066464; Sun, 03 Mar 2013 18:11:06 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id iu10sm20442278pbc.13.2013.03.03.18.11.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Mar 2013 18:11:05 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 04 Mar 2013 11:10:59 +0900 From: YongHyeon PYUN Date: Mon, 4 Mar 2013 11:10:59 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304021059.GC4589@michelle.cdnetworks.com> References: <20130220060853.GA83110@FreeBSD.org> <20130221083335.GA3226@michelle.cdnetworks.com> <20130221124344.GA93056@FreeBSD.org> <20130222011308.GA3259@michelle.cdnetworks.com> <20130222015607.GC66767@FreeBSD.org> <20130225082344.GC1426@michelle.cdnetworks.com> <20130303095330.GA57026@FreeBSD.org> <20130303120010.GA84560@FreeBSD.org> <20130304005044.GA4589@michelle.cdnetworks.com> <20130304015344.GA62059@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130304015344.GA62059@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 02:11:12 -0000 On Mon, Mar 04, 2013 at 01:53:44AM +0000, Alexey Dokuchaev wrote: > On Mon, Mar 04, 2013 at 09:50:44AM +0900, YongHyeon PYUN wrote: > > On Sun, Mar 03, 2013 at 12:00:10PM +0000, Alexey Dokuchaev wrote: > > > Alas, after "make kernel", link come up as 100mbps again, playing with > > > delays and rebooting (several times) did not make it GigE. I'm not sure > > > what's actually affecting it. :-( > > > > Would you try attached patch? > > Yes, it did help. With 2000us delays (I didn't revert them since you didn't Great! But it seems 2ms delays is too much. > ask), machine came up after "make kernel" and reboot with ale0 in GigE mode. > > I'll be happy to conduct more tests for you, if needed, thanks! Could you revert the change(2000us delays) and try it again? If that change works I still have to find a specific PHY model to exclude the blind PHY wakeup. > > ./danfe From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 02:46:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id B624C9A; Mon, 4 Mar 2013 02:46:31 +0000 (UTC) Date: Mon, 4 Mar 2013 02:46:31 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304024631.GA78040@FreeBSD.org> References: <20130221083335.GA3226@michelle.cdnetworks.com> <20130221124344.GA93056@FreeBSD.org> <20130222011308.GA3259@michelle.cdnetworks.com> <20130222015607.GC66767@FreeBSD.org> <20130225082344.GC1426@michelle.cdnetworks.com> <20130303095330.GA57026@FreeBSD.org> <20130303120010.GA84560@FreeBSD.org> <20130304005044.GA4589@michelle.cdnetworks.com> <20130304015344.GA62059@FreeBSD.org> <20130304021059.GC4589@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130304021059.GC4589@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 02:46:31 -0000 On Mon, Mar 04, 2013 at 11:10:59AM +0900, YongHyeon PYUN wrote: > On Mon, Mar 04, 2013 at 01:53:44AM +0000, Alexey Dokuchaev wrote: > > Yes, it did help. With 2000us delays (I didn't revert them [...] > > Great! But it seems 2ms delays is too much. Could you revert the change > (2000us delays) and try it again? Reverting if_ale.c, making kernel, and reboot gave me 100baseTX again; :-( second reboot (with the same kernel) did not help. Bumping delays to 2ms (just to make sure) restored GigE mode upon 1st reboot after "make kernel". ./danfe From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 03:01:44 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D02A4D2; Mon, 4 Mar 2013 03:01:44 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 550DD7EF; Mon, 4 Mar 2013 03:01:44 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r2431Rjm008175; Sun, 3 Mar 2013 19:01:31 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303040301.r2431Rjm008175@gw.catspoiler.org> Date: Sun, 3 Mar 2013 19:01:27 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: phk@phk.freebsd.dk In-Reply-To: <52867.1362317749@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 03:01:44 -0000 On 3 Mar, Poul-Henning Kamp wrote: > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > traffic to other disks too, when these pileups gets too bad. The Lemming-syncer problem should have mostly been fixed by 231160 in head (231952 in stable/9 and 231967 in stable/8) a little over a year ago. The exceptions are atime updates, mmaped files with dirty pages, and quotas. Under certain workloads I still notice periodic bursts of seek noise. After thinking about it for a bit, I suspect that it could be atime updates, but I haven't tried to confirm that. When using TCQ or NCQ, perhaps we should limit the number of outstanding writes per device to leave some slots open for reads. We should probably also prioritize reads over writes unless we are under memory pressure. From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 03:53:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8CFEDDE2 for ; Mon, 4 Mar 2013 03:53:20 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8CC9D1 for ; Mon, 4 Mar 2013 03:53:19 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id b57so3494743eek.18 for ; Sun, 03 Mar 2013 19:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/f/H8o7gqdcydv3zIf6IbOlV6YdGFyWtPKv5jaacMjM=; b=PE7DErzr2bpEVd9vJObOXsysrHZeE/4sFBXn2/sm8vxEBTjfMRYFJHYprV18DJnbTy H+tAdhOMtjpYXXH+w0RJtKiCAcDcTbEe98VkPBUzu+Mbu842sm9VI5hrVK8v8dyHwvaK LZkHZEMzyYr+s7wjV01FxP/N5McCtJpbKp9pRhfkyUCnTu1sFyIRCqlaBEUujfxe3CTJ C4u/uG/2vb36471jULnTBbU1AV1CbHwTo/wzhcj033+GIFXVzxH367Yz/CcZRN4Elhm5 KHxLhTxbDo1ppjlNe4w11+I4pAbMxvm8jQpQro7D1Uh34uzYsHNuwbJM1f385bfcEAsJ FLlw== X-Received: by 10.14.1.130 with SMTP id 2mr54264778eed.15.1362369198945; Sun, 03 Mar 2013 19:53:18 -0800 (PST) Received: from [192.168.1.80] (dsl4E5CC75B.pool.t-online.hu. [78.92.199.91]) by mx.google.com with ESMTPS id m46sm29807113eeo.16.2013.03.03.19.53.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 19:53:17 -0800 (PST) Message-ID: <51341AA6.7080601@gmail.com> Date: Mon, 04 Mar 2013 04:53:10 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: access to hard drives is "blocked" by writes to a flash drive References: <201303040301.r2431Rjm008175@gw.catspoiler.org> In-Reply-To: <201303040301.r2431Rjm008175@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 03:53:20 -0000 On 03/04/2013 04:01, Don Lewis wrote: > The Lemming-syncer problem should have mostly been fixed by 231160 in > head (231952 in stable/9 and 231967 in stable/8) a little over a year > ago. The exceptions are atime updates, mmaped files with dirty pages, > and quotas. Under certain workloads I still notice periodic bursts of > seek noise. After thinking about it for a bit, I suspect that it could > be atime updates, but I haven't tried to confirm that. atime is disabled on all mount points. Subversion doesn't use mmapped files, does it? No quotas are in use. atime is retarded anyway. There ought to be a kernel configuration (no)option SUPPORT_ATIME. From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 05:23:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE4E87D5; Mon, 4 Mar 2013 05:23:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7C819CC3; Mon, 4 Mar 2013 05:23:41 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id bg4so2911226pad.40 for ; Sun, 03 Mar 2013 21:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=wfAQ8Ww8eyxtUa4DCVR/D9Cloc0wqF67W9c2K1r/1ko=; b=e3RZJwtgBI3cILullvKDd4T0xLz/5cDsZUd0KUXJA2ImpOKj+c72uL4pfoYMzTd9KC iFSEqCaJcxvDjBND1Y1dopKF6D3GoXYOzPQf6UyIpFD2PKgoK1eYmwLqjDtntef8ezUc nDeDqD9kCsGvt04O+FuW+UFmdG8jUdl571231DeocQUx1v6xRm4qZFR8osqddcVzkFY3 05io5JF1cB/uNRid5o4q2wDp15np8zSZv1DxEvah+r787dDHeGuqp5vHWHlclGGX9Uk4 tDw3kih34WMNu6J+DlWQ7VTmh1wnn+0i1bAQbj9g2zmhTVxp8rjSsFbupz2oq5OCN+zx I3ZQ== X-Received: by 10.68.163.68 with SMTP id yg4mr16990380pbb.77.1362374615420; Sun, 03 Mar 2013 21:23:35 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id mz8sm18360541pbc.9.2013.03.03.21.23.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Mar 2013 21:23:34 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 04 Mar 2013 14:23:28 +0900 From: YongHyeon PYUN Date: Mon, 4 Mar 2013 14:23:28 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304052328.GA1445@michelle.cdnetworks.com> References: <20130221124344.GA93056@FreeBSD.org> <20130222011308.GA3259@michelle.cdnetworks.com> <20130222015607.GC66767@FreeBSD.org> <20130225082344.GC1426@michelle.cdnetworks.com> <20130303095330.GA57026@FreeBSD.org> <20130303120010.GA84560@FreeBSD.org> <20130304005044.GA4589@michelle.cdnetworks.com> <20130304015344.GA62059@FreeBSD.org> <20130304021059.GC4589@michelle.cdnetworks.com> <20130304024631.GA78040@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <20130304024631.GA78040@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 05:23:41 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 04, 2013 at 02:46:31AM +0000, Alexey Dokuchaev wrote: > On Mon, Mar 04, 2013 at 11:10:59AM +0900, YongHyeon PYUN wrote: > > On Mon, Mar 04, 2013 at 01:53:44AM +0000, Alexey Dokuchaev wrote: > > > Yes, it did help. With 2000us delays (I didn't revert them [...] > > > > Great! But it seems 2ms delays is too much. Could you revert the change > > (2000us delays) and try it again? > > Reverting if_ale.c, making kernel, and reboot gave me 100baseTX again; :-( > second reboot (with the same kernel) did not help. Bumping delays to 2ms > (just to make sure) restored GigE mode upon 1st reboot after "make kernel". > Ok, here is final diff which combines two things you've tested. So revert any changes before applying it. Let me know how it goes on your box. > ./danfe --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ale.pr.diff3" Index: sys/dev/ale/if_ale.c =================================================================== --- sys/dev/ale/if_ale.c (revision 247382) +++ sys/dev/ale/if_ale.c (working copy) @@ -406,11 +406,11 @@ ale_phy_reset(struct ale_softc *sc) CSR_WRITE_2(sc, ALE_GPHY_CTRL, GPHY_CTRL_HIB_EN | GPHY_CTRL_HIB_PULSE | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_PLL_ON); - DELAY(1000); + DELAY(2000); CSR_WRITE_2(sc, ALE_GPHY_CTRL, GPHY_CTRL_EXT_RESET | GPHY_CTRL_HIB_EN | GPHY_CTRL_HIB_PULSE | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_PLL_ON); - DELAY(1000); + DELAY(2000); #define ATPHY_DBG_ADDR 0x1D #define ATPHY_DBG_DATA 0x1E @@ -635,7 +635,7 @@ ale_attach(device_t dev) /* Set up MII bus. */ error = mii_attach(dev, &sc->ale_miibus, ifp, ale_mediachange, ale_mediastatus, BMSR_DEFCAPMASK, sc->ale_phyaddr, MII_OFFSET_ANY, - MIIF_DOPAUSE); + MIIF_DOPAUSE | MIIF_MACPRIV0); if (error != 0) { device_printf(dev, "attaching PHYs failed\n"); goto fail; Index: sys/dev/mii/atphy.c =================================================================== --- sys/dev/mii/atphy.c (revision 247382) +++ sys/dev/mii/atphy.c (working copy) @@ -100,8 +100,14 @@ atphy_probe(device_t dev) static int atphy_attach(device_t dev) { + struct mii_attach_args *ma; + u_int flags; - mii_phy_dev_attach(dev, MIIF_NOMANPAUSE, &atphy_funcs, 1); + ma = device_get_ivars(dev); + flags = MIIF_NOMANPAUSE; + if ((miibus_get_flags(dev) & MIIF_MACPRIV0) != 0) + flags |= MIIF_PHYPRIV0; + mii_phy_dev_attach(dev, flags, &atphy_funcs, 1); return (0); } @@ -287,9 +293,11 @@ atphy_reset(struct mii_softc *sc) uint32_t reg; int i; - /* Take PHY out of power down mode. */ - PHY_WRITE(sc, 29, 0x29); - PHY_WRITE(sc, 30, 0); + if ((sc->mii_flags & MIIF_PHYPRIV0) != 0) { + /* Take PHY out of power down mode. */ + PHY_WRITE(sc, 29, 0x29); + PHY_WRITE(sc, 30, 0); + } reg = PHY_READ(sc, ATPHY_SCR); /* Enable automatic crossover. */ --/9DWx/yDrRhgMJTb-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 05:35:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 78B4CB30; Mon, 4 Mar 2013 05:35:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C6F80D19; Mon, 4 Mar 2013 05:35:53 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r245Znv8090459; Mon, 4 Mar 2013 07:35:49 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r245Znv8090459 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r245Zl0W090457; Mon, 4 Mar 2013 07:35:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 4 Mar 2013 07:35:47 +0200 From: Konstantin Belousov To: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive Message-ID: <20130304053547.GY2930@kib.kiev.ua> References: <52867.1362317749@critter.freebsd.dk> <201303040301.r2431Rjm008175@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L4xCDQ7GT+ph8Lmk" Content-Disposition: inline In-Reply-To: <201303040301.r2431Rjm008175@gw.catspoiler.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 05:35:54 -0000 --L4xCDQ7GT+ph8Lmk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 03, 2013 at 07:01:27PM -0800, Don Lewis wrote: > On 3 Mar, Poul-Henning Kamp wrote: >=20 > > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > > traffic to other disks too, when these pileups gets too bad. >=20 > The Lemming-syncer problem should have mostly been fixed by 231160 in > head (231952 in stable/9 and 231967 in stable/8) a little over a year > ago. The exceptions are atime updates, mmaped files with dirty pages, > and quotas. Under certain workloads I still notice periodic bursts of > seek noise. After thinking about it for a bit, I suspect that it could > be atime updates, but I haven't tried to confirm that. I never got a definition what a Lemming syncer term means. The (current) syncer model is to iterate over the list of the active vnodes, i.e. vnodes for which an open file exists, or a mapping is established, and initiate the neccessary writes. The iterations over the active list is performed several times during the same sync run over the filesystem, this is considered acceptable. (Mostly) independently, the syncer thread iterates over the list of the dirty buffers and writes them. The "wdrain" wait is independend from the syncer model used. It is entered by a thread which intends to write in some future, but the wait is performed before the entry into VFS is performed, in particular, before any VFS resources are acquired. The wait sleeps when the total amount of the buffer space for which the writes are active (runningbufspace counter) exceeds the hirunningbufspace threshold. This way buffer cache tries to avoid creating too long queue of the write requests. If there is some device which has high latency with the write completion, then it is easy to see that, for the load which creates intensive queue of writes to the said device, regardless of amount of writes to other devices, runningbufspace quickly gets populated with the buffers targeted to the slow device. Then, the "wdrain" wait mechanism kicks in, slowing all writers until the queue is processed. It could be argued that the current typical value of 16MB for the hirunningbufspace is too low, but experiments with increasing it did not provided any measureable change in the throughput or latency for some loads. And, just to wrestle with the misinformation, the unmapped buffer work has nothing to do with either syncer or runningbufspace. >=20 > When using TCQ or NCQ, perhaps we should limit the number of outstanding > writes per device to leave some slots open for reads. We should > probably also prioritize reads over writes unless we are under memory > pressure. Reads are allowed to start even when the runningbufspace is overflown. --L4xCDQ7GT+ph8Lmk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRNDKyAAoJEJDCuSvBvK1BWqwQAJF7jUjb3dPjdxakgYS1fm2y Zx4KsWcq7+UOx6HYrmNms5NBXD/zpj/o4wFQrZ3R0UJBhAlmNJkdvXP149TnNRjc ufb6aLKQU+UikcKK1gExJ96R3/JiBPRYcvCcSRWEcp+F8Q2cRzHDh+g8FdJGCE7l J6+skc4GfacEzzIthzBJTHPq/AfdPzxNcr5zktPJskNvi9E6EJsw07AeWF3nB0so eysCKcYxJYxrFkQHuzAaEIvUlUtuUlioK9Xhj5fAOsbtV/3pua0q7cdQq4jcm8hT 1hcY1eXl3D+PloPoaTz4GVqNUn5LQ0a4YR05HGx7zF6dHQVm0JomdvOAIApqSpDP G7XFHhz7nV3KNPdFfaNuXrfeOY7HMGy8jZpq+WGmltnfR8KxjcwtgMJuRuR7yGdq WPscdno8YD9AP3JoAKQvy0Z6LM65ygitEA8zB+R+iVLFA3P6LAhYMLRhFjBHGobL A36EF1O/C55pv9X3bj6XK2jf/HjJHMAmrmTsxEgGcLlBNLO+EgLZYWgIjj8qGWoT 38evTjYethL3dQj8KN66Xw+OBVQMJXKSCV0vv7eOHMbLpcGk5hSRJd/EASyOAYYr XzFR2MsApAd7x/Hx4cGBXXQLyfyIZ0S6qbwXibDdYb6423cwp+68xbOaJqJsJABq KrZQpWI3jGvX0cyqI6nT =1C5w -----END PGP SIGNATURE----- --L4xCDQ7GT+ph8Lmk-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 05:59:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id E521AFB4; Mon, 4 Mar 2013 05:59:48 +0000 (UTC) Date: Mon, 4 Mar 2013 05:59:48 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304055948.GA76042@FreeBSD.org> References: <20130222011308.GA3259@michelle.cdnetworks.com> <20130222015607.GC66767@FreeBSD.org> <20130225082344.GC1426@michelle.cdnetworks.com> <20130303095330.GA57026@FreeBSD.org> <20130303120010.GA84560@FreeBSD.org> <20130304005044.GA4589@michelle.cdnetworks.com> <20130304015344.GA62059@FreeBSD.org> <20130304021059.GC4589@michelle.cdnetworks.com> <20130304024631.GA78040@FreeBSD.org> <20130304052328.GA1445@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130304052328.GA1445@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 05:59:49 -0000 On Mon, Mar 04, 2013 at 02:23:28PM +0900, YongHyeon PYUN wrote: > Ok, here is final diff which combines two things you've tested. > So revert any changes before applying it. > Let me know how it goes on your box. Hmm, apparently something went wrong, as I'm back to 100baseTX after make kernel and reboot... ./danfe From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 06:29:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C9850664; Mon, 4 Mar 2013 06:29:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by mx1.freebsd.org (Postfix) with ESMTP id 996E0E56; Mon, 4 Mar 2013 06:29:51 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id wy12so2884749pbc.35 for ; Sun, 03 Mar 2013 22:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=YAaGHxbZQlb5azYLVh5pW2UoIbzQSEFgGIwTqu0L7tk=; b=pzJWa1snOk+7Xw+IPFLM3EnV5bYQIRa0d68fYXjGAnkBa9djwRqrz4ya0JBPPV2rE8 8Uw2b2T30q/Fwlu6YK1zaYop8H5yLrfNO8BUCYGxYbmTNm7HWSeKR3BNr4s8VtyHy643 BXsKoyOb0p4SngO5TsiXFJJMoAt0FB0ZbpTynLezrJxoHaCngk4UvGYVZYw7cxlU2H7q xZUbqoZXQZt2ySnNmujx/NiUPiXij1fm4dMdfyGSG3bTOjppewszEb+uqFBvWWf8dJrC NGH5Jb+Zxozvvyu1kFqOClBpsA7bsfmhu/+UzALBSzUo/zPnROS2PPP2tIttkp7kBFdX l61w== X-Received: by 10.66.162.232 with SMTP id yd8mr31221874pab.100.1362378591074; Sun, 03 Mar 2013 22:29:51 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id b9sm21221046pba.6.2013.03.03.22.29.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Mar 2013 22:29:50 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 04 Mar 2013 15:29:44 +0900 From: YongHyeon PYUN Date: Mon, 4 Mar 2013 15:29:44 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304062944.GB1445@michelle.cdnetworks.com> References: <20130222015607.GC66767@FreeBSD.org> <20130225082344.GC1426@michelle.cdnetworks.com> <20130303095330.GA57026@FreeBSD.org> <20130303120010.GA84560@FreeBSD.org> <20130304005044.GA4589@michelle.cdnetworks.com> <20130304015344.GA62059@FreeBSD.org> <20130304021059.GC4589@michelle.cdnetworks.com> <20130304024631.GA78040@FreeBSD.org> <20130304052328.GA1445@michelle.cdnetworks.com> <20130304055948.GA76042@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="U+BazGySraz5kW0T" Content-Disposition: inline In-Reply-To: <20130304055948.GA76042@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 06:29:51 -0000 --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 04, 2013 at 05:59:48AM +0000, Alexey Dokuchaev wrote: > On Mon, Mar 04, 2013 at 02:23:28PM +0900, YongHyeon PYUN wrote: > > Ok, here is final diff which combines two things you've tested. > > So revert any changes before applying it. > > Let me know how it goes on your box. > > Hmm, apparently something went wrong, as I'm back to 100baseTX after make > kernel and reboot... Hmm, updated diff again. > > ./danfe --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ale.pr.diff4" Index: sys/dev/ale/if_ale.c =================================================================== --- sys/dev/ale/if_ale.c (revision 247382) +++ sys/dev/ale/if_ale.c (working copy) @@ -406,11 +406,13 @@ ale_phy_reset(struct ale_softc *sc) CSR_WRITE_2(sc, ALE_GPHY_CTRL, GPHY_CTRL_HIB_EN | GPHY_CTRL_HIB_PULSE | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_PLL_ON); - DELAY(1000); + CSR_READ_2(sc, ALE_GPHY_CTRL); + DELAY(2000); CSR_WRITE_2(sc, ALE_GPHY_CTRL, GPHY_CTRL_EXT_RESET | GPHY_CTRL_HIB_EN | GPHY_CTRL_HIB_PULSE | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_PLL_ON); - DELAY(1000); + CSR_READ_2(sc, ALE_GPHY_CTRL); + DELAY(2000); #define ATPHY_DBG_ADDR 0x1D #define ATPHY_DBG_DATA 0x1E @@ -635,7 +637,7 @@ ale_attach(device_t dev) /* Set up MII bus. */ error = mii_attach(dev, &sc->ale_miibus, ifp, ale_mediachange, ale_mediastatus, BMSR_DEFCAPMASK, sc->ale_phyaddr, MII_OFFSET_ANY, - MIIF_DOPAUSE); + MIIF_DOPAUSE | MIIF_MACPRIV0); if (error != 0) { device_printf(dev, "attaching PHYs failed\n"); goto fail; @@ -1515,6 +1517,7 @@ ale_setwol(struct ale_softc *sc) GPHY_CTRL_HIB_PULSE | GPHY_CTRL_PHY_PLL_ON | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_IDDQ | GPHY_CTRL_PCLK_SEL_DIS | GPHY_CTRL_PWDOWN_HW); + CSR_READ_2(sc, ALE_GPHY_CTRL); return; } @@ -1547,6 +1550,7 @@ ale_setwol(struct ale_softc *sc) GPHY_CTRL_HIB_PULSE | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_IDDQ | GPHY_CTRL_PCLK_SEL_DIS | GPHY_CTRL_PWDOWN_HW); + CSR_READ_2(sc, ALE_GPHY_CTRL); } /* Request PME. */ pmstat = pci_read_config(sc->ale_dev, pmc + PCIR_POWER_STATUS, 2); Index: sys/dev/mii/atphy.c =================================================================== --- sys/dev/mii/atphy.c (revision 247382) +++ sys/dev/mii/atphy.c (working copy) @@ -100,8 +100,14 @@ atphy_probe(device_t dev) static int atphy_attach(device_t dev) { + struct mii_attach_args *ma; + u_int flags; - mii_phy_dev_attach(dev, MIIF_NOMANPAUSE, &atphy_funcs, 1); + ma = device_get_ivars(dev); + flags = MIIF_NOMANPAUSE; + if ((miibus_get_flags(dev) & MIIF_MACPRIV0) != 0) + flags |= MIIF_PHYPRIV0; + mii_phy_dev_attach(dev, flags, &atphy_funcs, 1); return (0); } @@ -287,9 +293,11 @@ atphy_reset(struct mii_softc *sc) uint32_t reg; int i; - /* Take PHY out of power down mode. */ - PHY_WRITE(sc, 29, 0x29); - PHY_WRITE(sc, 30, 0); + if ((sc->mii_flags & MIIF_PHYPRIV0) != 0) { + /* Take PHY out of power down mode. */ + PHY_WRITE(sc, 29, 0x29); + PHY_WRITE(sc, 30, 0); + } reg = PHY_READ(sc, ATPHY_SCR); /* Enable automatic crossover. */ --U+BazGySraz5kW0T-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 06:46:42 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CA0379E3; Mon, 4 Mar 2013 06:46:42 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 22591EBD; Mon, 4 Mar 2013 06:46:41 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id E32E089EAF; Mon, 4 Mar 2013 06:46:39 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r246kbQ8063374; Mon, 4 Mar 2013 06:46:37 GMT (envelope-from phk@phk.freebsd.dk) To: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive In-reply-to: <201303040301.r2431Rjm008175@gw.catspoiler.org> From: "Poul-Henning Kamp" References: <201303040301.r2431Rjm008175@gw.catspoiler.org> Date: Mon, 04 Mar 2013 06:46:37 +0000 Message-ID: <63373.1362379597@critter.freebsd.dk> Cc: deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 06:46:42 -0000 Content-Type: text/plain; charset=ISO-8859-1 -------- In message <201303040301.r2431Rjm008175@gw.catspoiler.org>, Don Lewis writes: >When using TCQ or NCQ, perhaps we should limit the number of outstanding >writes per device to leave some slots open for reads. We should >probably also prioritize reads over writes unless we are under memory >pressure. Camera-grade flash seldom support either, they are strictly serial. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 06:59:40 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 7F985C49; Mon, 4 Mar 2013 06:59:40 +0000 (UTC) Date: Mon, 4 Mar 2013 06:59:40 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304065940.GA13417@FreeBSD.org> References: <20130225082344.GC1426@michelle.cdnetworks.com> <20130303095330.GA57026@FreeBSD.org> <20130303120010.GA84560@FreeBSD.org> <20130304005044.GA4589@michelle.cdnetworks.com> <20130304015344.GA62059@FreeBSD.org> <20130304021059.GC4589@michelle.cdnetworks.com> <20130304024631.GA78040@FreeBSD.org> <20130304052328.GA1445@michelle.cdnetworks.com> <20130304055948.GA76042@FreeBSD.org> <20130304062944.GB1445@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130304062944.GB1445@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 06:59:40 -0000 On Mon, Mar 04, 2013 at 03:29:44PM +0900, YongHyeon PYUN wrote: > On Mon, Mar 04, 2013 at 05:59:48AM +0000, Alexey Dokuchaev wrote: > > On Mon, Mar 04, 2013 at 02:23:28PM +0900, YongHyeon PYUN wrote: > > > Ok, here is final diff which combines two things you've tested. > > > So revert any changes before applying it. > > > Let me know how it goes on your box. > > > > Hmm, apparently something went wrong, as I'm back to 100baseTX after make > > kernel and reboot... > > Hmm, updated diff again. Better this time, I'm having 1000baseT again! :-) ./danfe From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 07:12:52 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72598FAC; Mon, 4 Mar 2013 07:12:52 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 53555F8F; Mon, 4 Mar 2013 07:12:52 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r247CejP008718; Sun, 3 Mar 2013 23:12:44 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303040712.r247CejP008718@gw.catspoiler.org> Date: Sun, 3 Mar 2013 23:12:40 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: kostikbel@gmail.com In-Reply-To: <20130304053547.GY2930@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 07:12:52 -0000 On 4 Mar, Konstantin Belousov wrote: > On Sun, Mar 03, 2013 at 07:01:27PM -0800, Don Lewis wrote: >> On 3 Mar, Poul-Henning Kamp wrote: >> >> > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O >> > traffic to other disks too, when these pileups gets too bad. >> >> The Lemming-syncer problem should have mostly been fixed by 231160 in >> head (231952 in stable/9 and 231967 in stable/8) a little over a year >> ago. The exceptions are atime updates, mmaped files with dirty pages, >> and quotas. Under certain workloads I still notice periodic bursts of >> seek noise. After thinking about it for a bit, I suspect that it could >> be atime updates, but I haven't tried to confirm that. > I never got a definition what a Lemming syncer term means. The (current) > syncer model is to iterate over the list of the active vnodes, i.e. > vnodes for which an open file exists, or a mapping is established, and > initiate the neccessary writes. The iterations over the active list is > performed several times during the same sync run over the filesystem, > this is considered acceptable. Prior to 231160, the syncer thread would call sync_vnode() for the syncer vnode of each mountpoint every 30 seconds, depending on where the syncer vnode was in the worklist. sync_vnode() would in turn call VOP_FSYNC(-, MNT_LAZY, -) on the syncer vnode, which got mapped to sync_fsync(). sync_fsync() would then call vfs_msync() to perform an msync on all vnodes under the mount point, and then called VFS_SYNC(-, MNT_LAZY), which maps to a call to ffs_sync(). ffs_sync() would then ignore the MNT_LAZY flage and just blindly iterate over all the vnodes owned by the mountpoint, calling ffs_syncvnode() on any of them that had an IN_* flag set or had any dirty buffers. The result is that once every 30 seconds all of the dirty files under a mount point would be flushed to disk in one big blast. There have been a lot of improvements with 231160 and later changes, but I still notice periodic increases in seek noise under some workloads, but I haven't had a chance to investigate. > (Mostly) independently, the syncer thread iterates over the list of the > dirty buffers and writes them. It did that as well, prior to 231160. > The "wdrain" wait is independend from the syncer model used. It is entered > by a thread which intends to write in some future, but the wait is performed > before the entry into VFS is performed, in particular, before any VFS > resources are acquired. The wait sleeps when the total amount of the > buffer space for which the writes are active (runningbufspace counter) > exceeds the hirunningbufspace threshold. This way buffer cache tries to > avoid creating too long queue of the write requests. > > If there is some device which has high latency with the write completion, > then it is easy to see that, for the load which creates intensive queue > of writes to the said device, regardless of amount of writes to other > devices, runningbufspace quickly gets populated with the buffers targeted > to the slow device. Then, the "wdrain" wait mechanism kicks in, slowing > all writers until the queue is processed. Reserving at least sume space for each device might be beneficial to prevent one slow device from blocking writes to others, but in this case it sounds like reads are also getting blocked. > It could be argued that the current typical value of 16MB for the > hirunningbufspace is too low, but experiments with increasing it did > not provided any measureable change in the throughput or latency for > some loads. The correct value is probably proportional to the write bandwidth available. > And, just to wrestle with the misinformation, the unmapped buffer work > has nothing to do with either syncer or runningbufspace. > >> >> When using TCQ or NCQ, perhaps we should limit the number of outstanding >> writes per device to leave some slots open for reads. We should >> probably also prioritize reads over writes unless we are under memory >> pressure. > > Reads are allowed to start even when the runningbufspace is overflown. I think reads are probably correctly self limiting in low memory situations because they'll be blocked when trying to allocate buffer space to read the data into. From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 07:14:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C5BDE175; Mon, 4 Mar 2013 07:14:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by mx1.freebsd.org (Postfix) with ESMTP id 99FA6FC1; Mon, 4 Mar 2013 07:14:50 +0000 (UTC) Received: by mail-da0-f48.google.com with SMTP id w4so2394288dam.35 for ; Sun, 03 Mar 2013 23:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=r5nqzP9plS3aGrvni8GmPB59lwdHXWAUGimTaxYaJHo=; b=IupOiY7yAWl7lahXwDBlXKlkLhNdWscIBQK0dWz935TwGoeub8YhbJgaPcskU1L28z TaFea+/ZZQxxsYPcgPPDCxU/B5u2kJWFjp+dfTsiZ6k6jIR1mxlZEZ+fMxS1pUR5vgWL vfZ444m6F09bkqKY+qTsSH2o/G0XtMhRuxlFoBqUiIjcXKry3gAxXNa5uv1k5DSPeoQi Laub/0M1KzgQ6KfXCHDc059IywQBfIyordJ1haaojENwiPv3TZljixLGJVd9sReNy0A0 8PB/p9PKhP1bgyVTKt8WpIZQm89laFaMWuZd+kJap0v/ViptU5Q+LMqQz/IrzuF8aUA9 aqHw== X-Received: by 10.66.162.133 with SMTP id ya5mr30761051pab.104.1362380799231; Sun, 03 Mar 2013 23:06:39 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id c3sm22856074pax.9.2013.03.03.23.06.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Mar 2013 23:06:38 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 04 Mar 2013 16:06:32 +0900 From: YongHyeon PYUN Date: Mon, 4 Mar 2013 16:06:32 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304070632.GC1445@michelle.cdnetworks.com> References: <20130303095330.GA57026@FreeBSD.org> <20130303120010.GA84560@FreeBSD.org> <20130304005044.GA4589@michelle.cdnetworks.com> <20130304015344.GA62059@FreeBSD.org> <20130304021059.GC4589@michelle.cdnetworks.com> <20130304024631.GA78040@FreeBSD.org> <20130304052328.GA1445@michelle.cdnetworks.com> <20130304055948.GA76042@FreeBSD.org> <20130304062944.GB1445@michelle.cdnetworks.com> <20130304065940.GA13417@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130304065940.GA13417@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 07:14:50 -0000 On Mon, Mar 04, 2013 at 06:59:40AM +0000, Alexey Dokuchaev wrote: > On Mon, Mar 04, 2013 at 03:29:44PM +0900, YongHyeon PYUN wrote: > > On Mon, Mar 04, 2013 at 05:59:48AM +0000, Alexey Dokuchaev wrote: > > > On Mon, Mar 04, 2013 at 02:23:28PM +0900, YongHyeon PYUN wrote: > > > > Ok, here is final diff which combines two things you've tested. > > > > So revert any changes before applying it. > > > > Let me know how it goes on your box. > > > > > > Hmm, apparently something went wrong, as I'm back to 100baseTX after make > > > kernel and reboot... > > > > Hmm, updated diff again. > > Better this time, I'm having 1000baseT again! :-) > Thanks a lot for testing and patience! Could you reboot multiple times and check whether you reliably get a gigabit link? > ./danfe From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 07:35:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44C025B5 for ; Mon, 4 Mar 2013 07:35:26 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id A3D9AFC for ; Mon, 4 Mar 2013 07:35:25 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id fr10so4619689lab.40 for ; Sun, 03 Mar 2013 23:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=eT70pzG7ZbyvbnSMq6Bjv0ZZksmpDgbg0Nwv7Kgoms0=; b=d2t3J6j6yTiBzKVPlK9Gtj863n8p3Wn5r/3hPo9GUJqDWUOAVs1+b9z73NeuSHrV7d pWZdQiwilaA1TeyjdJR+e346GcvTAo/S/tT1Dnx6p9LzIiB3yD8TImxNYcf3V5hHujxY I/PdnIB0wTs4U20OANt9TtFg3UTbd4z482sw08VcNfoNcIwHw+TvayRuP1NEZT2ppB8C 678hqWu90pCKM5UBNBSj5vyzZdZ5kqVvNFvGHlPz52ATgynOpdcAiQNNfehOAUCC5sxO tTi4v8tXMVH2CghZDe5m58sumPj6EJZWdzBxCuQaShbRkqpZy81i/CYjVbKcfGfyxRtx LsbA== MIME-Version: 1.0 X-Received: by 10.152.110.6 with SMTP id hw6mr17053221lab.43.1362382524634; Sun, 03 Mar 2013 23:35:24 -0800 (PST) Sender: c.jayachandran@gmail.com Received: by 10.112.51.6 with HTTP; Sun, 3 Mar 2013 23:35:24 -0800 (PST) Date: Mon, 4 Mar 2013 13:05:24 +0530 X-Google-Sender-Auth: dT3QozX76VABnJeLSz4oK5dY8Mg Message-ID: Subject: [PATCH] kenv issue when there is no static environment From: "Jayachandran C." To: FreeBSD Current Content-Type: multipart/mixed; boundary=bcaec54b48d06ddddd04d71466c4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Mar 2013 07:35:26 -0000 --bcaec54b48d06ddddd04d71466c4 Content-Type: text/plain; charset=ISO-8859-1 Planning to check the attached patch later this week, please let me know if there any objections. ---- In case where there are no static kernel environment entries, the function init_dynamic_kenv() adds an incorrect entry at position 0 of the dynamic kernel environment. This entry is usually empty and confuses kenv(1). The entries added later by kenv(1) does not seem to be added, even though they are. The environment passed to the kernel can be empty when it is loaded from a bootloader other than loader(8). JC. --bcaec54b48d06ddddd04d71466c4 Content-Type: application/octet-stream; name="kenv-fix.patch" Content-Disposition: attachment; filename="kenv-fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdvbcwrf0 SW5kZXg6IHN5cy9rZXJuL2tlcm5fZW52aXJvbm1lbnQuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMva2Vy bi9rZXJuX2Vudmlyb25tZW50LmMJKHJldmlzaW9uIDI0Nzc2NSkKKysrIHN5cy9rZXJuL2tlcm5f ZW52aXJvbm1lbnQuYwkod29ya2luZyBjb3B5KQpAQCAtMjMxLDIwICsyMzEsMjMgQEAgaW5pdF9k eW5hbWljX2tlbnYodm9pZCAqZGF0YSBfX3VudXNlZCkKIAlrZW52cCA9IG1hbGxvYygoS0VOVl9T SVpFICsgMSkgKiBzaXplb2YoY2hhciAqKSwgTV9LRU5WLAogCQlNX1dBSVRPSyB8IE1fWkVSTyk7 CiAJaSA9IDA7Ci0JZm9yIChjcCA9IGtlcm5fZW52cDsgY3AgIT0gTlVMTDsgY3AgPSBrZXJuZW52 X25leHQoY3ApKSB7Ci0JCWxlbiA9IHN0cmxlbihjcCkgKyAxOwotCQlpZiAobGVuID4gS0VOVl9N TkFNRUxFTiArIDEgKyBLRU5WX01WQUxMRU4gKyAxKSB7Ci0JCQlwcmludGYoIldBUk5JTkc6IHRv byBsb25nIGtlbnYgc3RyaW5nLCBpZ25vcmluZyAlc1xuIiwKLQkJCSAgICBjcCk7Ci0JCQljb250 aW51ZTsKKwlpZiAoZW52X3BvcyA+IDApIHsKKwkJZm9yIChjcCA9IGtlcm5fZW52cDsgY3AgIT0g TlVMTDsgY3AgPSBrZXJuZW52X25leHQoY3ApKSB7CisJCQlsZW4gPSBzdHJsZW4oY3ApICsgMTsK KwkJCWlmIChsZW4gPiBLRU5WX01OQU1FTEVOICsgMSArIEtFTlZfTVZBTExFTiArIDEpIHsKKwkJ CQlwcmludGYoCisJCQkJIldBUk5JTkc6IHRvbyBsb25nIGtlbnYgc3RyaW5nLCBpZ25vcmluZyAl c1xuIiwKKwkJCQkgICAgY3ApOworCQkJCWNvbnRpbnVlOworCQkJfQorCQkJaWYgKGkgPCBLRU5W X1NJWkUpIHsKKwkJCQlrZW52cFtpXSA9IG1hbGxvYyhsZW4sIE1fS0VOViwgTV9XQUlUT0spOwor CQkJCXN0cmNweShrZW52cFtpKytdLCBjcCk7CisJCQl9IGVsc2UKKwkJCQlwcmludGYoCisJCQkJ IldBUk5JTkc6IHRvbyBtYW55IGtlbnYgc3RyaW5ncywgaWdub3JpbmcgJXNcbiIsCisJCQkJICAg IGNwKTsKIAkJfQotCQlpZiAoaSA8IEtFTlZfU0laRSkgewotCQkJa2VudnBbaV0gPSBtYWxsb2Mo bGVuLCBNX0tFTlYsIE1fV0FJVE9LKTsKLQkJCXN0cmNweShrZW52cFtpKytdLCBjcCk7Ci0JCX0g ZWxzZQotCQkJcHJpbnRmKAotCQkJICAgICJXQVJOSU5HOiB0b28gbWFueSBrZW52IHN0cmluZ3Ms IGlnbm9yaW5nICVzXG4iLAotCQkJICAgIGNwKTsKIAl9CiAJa2VudnBbaV0gPSBOVUxMOwogCg== --bcaec54b48d06ddddd04d71466c4-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 08:18:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 64CEC475; Mon, 4 Mar 2013 08:18:58 +0000 (UTC) Date: Mon, 4 Mar 2013 08:18:58 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130304081858.GA23857@FreeBSD.org> References: <20130303120010.GA84560@FreeBSD.org> <20130304005044.GA4589@michelle.cdnetworks.com> <20130304015344.GA62059@FreeBSD.org> <20130304021059.GC4589@michelle.cdnetworks.com> <20130304024631.GA78040@FreeBSD.org> <20130304052328.GA1445@michelle.cdnetworks.com> <20130304055948.GA76042@FreeBSD.org> <20130304062944.GB1445@michelle.cdnetworks.com> <20130304065940.GA13417@FreeBSD.org> <20130304070632.GC1445@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130304070632.GC1445@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 08:18:58 -0000 On Mon, Mar 04, 2013 at 04:06:32PM +0900, YongHyeon PYUN wrote: > On Mon, Mar 04, 2013 at 06:59:40AM +0000, Alexey Dokuchaev wrote: > > Better this time, I'm having 1000baseT again! :-) > > Thanks a lot for testing and patience! > Could you reboot multiple times and check whether you reliably get > a gigabit link? Yes, multiple reboots was a good idea, it's not very stable: 1st reboot: 100baseTX (!) 2nd reboot: 1000baseT 3rd reboot: 1000baseT 4th reboot: 1000baseT 5th reboot: 100baseTX (!) 6th reboot: 100baseTX (!) 7th reboot: 1000baseT 8th reboot: 100baseTX (!) 9th reboot: 1000baseT 10th reboot: 1000baseT I've tried various combinations of just reboot, shutdown -r +1m and pinging some host while waiting for reboot. ./danfe From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 08:38:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A36E2896; Mon, 4 Mar 2013 08:38:17 +0000 (UTC) (envelope-from peter@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 3EBFB65D; Mon, 4 Mar 2013 08:38:16 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r248c7u7034504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Mar 2013 19:38:08 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r248c2HL045173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Mar 2013 19:38:03 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r248c2Of045172; Mon, 4 Mar 2013 19:38:02 +1100 (EST) (envelope-from peter) Date: Mon, 4 Mar 2013 19:38:02 +1100 From: Peter Jeremy To: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive Message-ID: <20130304083802.GA44865@server.rulingia.com> References: <20130304053547.GY2930@kib.kiev.ua> <201303040712.r247CejP008718@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <201303040712.r247CejP008718@gw.catspoiler.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 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Mar 2013 08:38:17 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Mar-03 23:12:40 -0800, Don Lewis wrote: >On 4 Mar, Konstantin Belousov wrote: >> It could be argued that the current typical value of 16MB for the >> hirunningbufspace is too low, but experiments with increasing it did >> not provided any measureable change in the throughput or latency for >> some loads. > >The correct value is probably proportional to the write bandwidth >available. The problem is that write bandwidth varies widely depending on the workload. For spinning rust, this will vary between maybe 64KBps (512B random writes) and 100-150MBps (single-theaded large sequential writes). The (low-end) SSD in my Netbook also has about 100:1 variance due to erase blocking. How do you tune hirunningbufspace in the face of 2 or 3 orders of magnitude variance in throughput? Especially since SSDs don't gradually degrade - they hit a brick wall. --=20 Peter Jeremy --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlE0XWoACgkQ/opHv/APuIeHbACcCk/rPZvdWOaw39O04JSSk131 WZsAn1uwrzYpq9e+yPGGdfsz6a4rtRuC =MVQ7 -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 13:44:39 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1DDB91E9; Mon, 4 Mar 2013 13:44:39 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D73A718F2; Mon, 4 Mar 2013 13:44:38 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 26AE589EAF; Mon, 4 Mar 2013 13:44:32 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r24DiUSq025328; Mon, 4 Mar 2013 13:44:30 GMT (envelope-from phk@phk.freebsd.dk) To: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive In-reply-to: <201303040712.r247CejP008718@gw.catspoiler.org> From: "Poul-Henning Kamp" References: <201303040712.r247CejP008718@gw.catspoiler.org> Date: Mon, 04 Mar 2013 13:44:30 +0000 Message-ID: <25327.1362404670@critter.freebsd.dk> Cc: kostikbel@gmail.com, deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 13:44:39 -0000 Content-Type: text/plain; charset=ISO-8859-1 -------- In message <201303040712.r247CejP008718@gw.catspoiler.org>, Don Lewis writes: >Prior to 231160, the syncer thread would call sync_vnode() for the >syncer vnode of each mountpoint every 30 seconds [...] I agree that the lemming syncer is better, but the fundamental mistake of only having one syncer thread is probably the root-cause in this case: One camera-grade flash syncing may take (a lot) more than 30 seconds. One mountpoint having trouble (of whatever kind) should not affect the rest of the mountpoints. I'm not sure if the syncer is untangled enough that we can have per mount-point threads yet, but as soon as we can, we should do that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 13:49:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1613B348 for ; Mon, 4 Mar 2013 13:49:50 +0000 (UTC) (envelope-from isabell@issyl0.co.uk) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx1.freebsd.org (Postfix) with ESMTP id BCEB7193D for ; Mon, 4 Mar 2013 13:49:49 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id l6so3387436vcl.17 for ; Mon, 04 Mar 2013 05:49:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=DioQTY+wgCO7jSel/CTscrjyiF2Xu6dBG4Yow/s5vw8=; b=NaYfL2BLwh+AT+Hc680aQ0R2F3kvgRMfqaJyvCMuA/r68bNZnHZsUdjb7rfreZAnng OrJDqpSVDugq6UMnckwbVPDeHWUAcYjszHfbF/Pav/YcXeUaJ12lqJ01h/jn+9RX4yZA ixPtuAMKDE9Upej01gtEoj4+rzB8ePVMhWbglXCLsG3LXCTSgbV5zDceGqzJ5ZjUOqqU G8yaiYP3P4Y9wWdeXd+4M74msBoC96+5FJ+A2FVa5cq3i+QOjBdbmKRc8GxqaLbb4AkZ /WJxxpbAyIv4+BI75l4vsT0QWQEwSjds3dgRnQIh98g9ijBl4JUZzTV7C11Dab2EtOL+ Iu0Q== MIME-Version: 1.0 X-Received: by 10.220.116.5 with SMTP id k5mr7718621vcq.55.1362404988940; Mon, 04 Mar 2013 05:49:48 -0800 (PST) Sender: isabell@issyl0.co.uk Received: by 10.220.250.138 with HTTP; Mon, 4 Mar 2013 05:49:48 -0800 (PST) X-Originating-IP: [2.29.6.249] Date: Mon, 4 Mar 2013 13:49:48 +0000 X-Google-Sender-Auth: 7LX9Z-YX-bFUn-7rILEEDB9MoqY Message-ID: Subject: FreeBSD Quarterly Status Report, July-September 2012. From: Isabell Long To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkXNDZee3Tbj6dwAZ7HmtGYnQmLBE7/Fcgr0/OU1B9/VHP4qvi3oI3dGT/ZP4MsiLZNh7CX Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 13:49:50 -0000 FreeBSD Quarterly Status Report, July-September 2012. Introduction This report covers FreeBSD-related projects between July and September 2012. This is the third of the four reports planned for 2012. Highlights from this quarter include successful participation in Google Summer of Code, major work in areas of the source and ports trees, and a Developer Summit attended by over 30 developers. Thanks to all the reporters for the excellent work! This report contains 12 entries and we hope you enjoy reading it. __________________________________________________________________ Projects * FreeBSD on Altera FPGAs * Native iSCSI Target * Parallel rc.d execution FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Foundation * The FreeBSD Core Team Kernel * FreeBSD on ARMv6/ARMv7 Documentation * The FreeBSD Japanese Documentation Project Ports * KDE/FreeBSD * Ports Collection Miscellaneous * FreeBSD Developer Summit, Cambridge, UK FreeBSD in Google Summer of Code * Google Summer of Code 2012 __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: https://wiki.freebsd.org/BugBusting Contact: Eitan Adler Contact: Gavin Atkinson Contact: Oleksandr Tymoshenko In August, Eitan Adler (eadler@) and Oleksandr Tymoshenko (gonzo@) joined the Bugmeister team. At the same time, Remko Lodder and Volker Werth stepped down. We extend our thanks to Volker and Remko for their work in the past, and welcome Oleksandr and Eitan. Eitan and Oleksandr have been working hard on migrating from GNATS, and have made significant progress on evaluating new software, and creating scripts to export data from GNATS. The bugbusting team continue work on trying to make the contents of the GNATS PR database cleaner, more accessible and easier for committers to find and resolve PRs, by tagging PRs to indicate the areas involved, and by ensuring that there is sufficient info within each PR to resolve each issue. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Further research into tools suitable to replace GNATS. 2. Get more users involved with triaging PRs as they come in. 3. Assist committers with closing PRs. __________________________________________________________________ FreeBSD Developer Summit, Cambridge, UK URL: https://wiki.freebsd.org/201208DevSummit Contact: Robert Watson In the end of August, there was an "off-season" Developer Summit held in Cambridge, UK at the University of Cambridge Computer Laboratory. This was a three-day event, with a documentation summit scheduled for the day before. The three days of the main event were split into three sessions, with two tracks in each. Some of them even involved ARM developers from the neighborhoods which proven to be productive, and led to further engagement between the FreeBSD community and ARM. The schedule was finalized on the first day, spawning a plethora of topics to discuss, followed by splitting into groups. A short summary from each of the groups was presented in the final session and then published at the event's home page on the FreeBSD wiki. This summit contributed greatly to arriving to a tentative plan for throwing the switch to make clang the default compiler on HEAD. This was further discussed on the mailing list, and has now happened, bringing us one big step closer to a GPL-free FreeBSD 10. As part of the program, an afternoon of short talks from researchers in the Cambridge Computer Laboratory involved either operating systems work in general or FreeBSD in particular. Robert Watson showed off a tablet running FreeBSD on a MIPS-compatible soft-core processor running on an Altera FPGA. In association with the event, a dinner was hosted by St. John's college and co-sponsored by Google and the FreeBSD Foundation. The day after the conference, a trip was organized to Bletchley Park, which was celebrating Turing's centenary in 2012. __________________________________________________________________ FreeBSD Foundation URL: http://www.freebsdfoundation.org/press/2012Jul-newsletter.shtml Contact: Deb Goodkin The Foundation hosted and sponsored the Cambridge FreeBSD developer summit in August 2012. We were represented at the following conferences: OSCON July 2012, Texas LinuxFest, and Ohio LinuxFest. We negotiated/supervised Foundation funded projects: Distributed Security Audit Logging, Capsicum Component Framework, Native iSCSI Target Scoping, and Growing UFS Filesystems Online. We negotiated, supervised, and funded hardware needs for FreeBSD co-location centers. We welcomed Kirk McKusick to our board of directors. He took over the responsibility of managing our investments. We visited companies to discuss their FreeBSD use and to help facilitate collaboration with the Project. We managed FreeBSD vendor community mailing list and meetings. We created a high quality FreeBSD 9 brochure to help promote FreeBSD. Published our semi-annual newsletter that highlighted Foundation funded projects, travel grants for developers, conferences sponsored and other ways the Foundation supported the FreeBSD Project. We hired a technical writer to help with FreeBSD marketing/promotional material. We began work on redesigning our website. __________________________________________________________________ FreeBSD on Altera FPGAs URL: http://www.cl.cam.ac.uk/research/security/ctsrd/ URL: http://www.cl.cam.ac.uk/research/security/ctsrd/cheri.html Contact: Brooks Davis Contact: Robert Watson Contact: Bjoern Zeeb In the course of developing the CHERI processor as part of the CTSRD project SRI International's Computer Science Laboratory and the University of Cambridge Computer Laboratory have developed support for a number of general purpose IP cores for Altera FPGAs including the Altera Triple Speed Ethernet (ATSE) MAC core, the Altera University Program SD Card core, and the Altera JTAG UART. We have also added support for general access to memory mapped devices on the Avalon bus via the avgen bus. We have implemented both nexus and flattened device tree (FDT) attachments for these devices. In addition to these softcore we have developed support for the Terasic multi-touch LCD and are working to provide support for the Terasic HDMI Transmitter Daughter Card. Both of these work with common development and/or reference boards for Altera FPGAs. They do require additional IP cores which we plan to release to the open source community in the near future. With exception of the ATSE and HDMI drivers we have merged all of these changes to FreeBSD-CURRENT. We anticipate that these drivers will be useful for users who with to run FreeBSD on either hard or soft core CPUs on Altera FPGAs. This work has been sponsored by DARPA, AFRL, and Google. __________________________________________________________________ FreeBSD on ARMv6/ARMv7 Contact: freebsd-arm mailing list Support for ARMv6 and ARMv7 architecture has been merged from project branch to HEAD. This code covers the following parts: * General ARMv6/ARMv7 kernel bits (pmap, cache, assembler routines, etc...) * ARM Generic Interrupt Controller driver * Improved thread-local storage for cpus >=ARMv6 * Driver for SMSC LAN95XX and LAN8710A ethernet controllers * Marvell MV78x60 support (multiuser, ARMADA XP kernel config) * TI OMAP4 and AM335x support (multiuser, no GPU or graphics support, kernel configs for Pandaboard and Beaglebone) * LPC32x0 support (multiuser, frame buffer works with SSD1289 LCD controller. Embedded Artists EA3250 kernel config) This work was a result of a joint effort by many people, including but not limited to: Grzegorz Bernacki (gber@), Aleksander Dutkowski, Ben R. Gray (bgray@), Olivier Houchard (cognet@), Rafal Jaworowski (raj@) and Semihalf team, Tim Kientzle (kientzle@), Jakub Wojciech Klama (jceel@), Ian Lepore (ian@), Warner Losh (imp@), Damjan Marion (dmarion@), Lukasz Plachno, Stanislav Sedov (stas@), Mark Tinguely and Andrew Turner (andrew@). Thanks to all, who contributed by submitting code, testing and giving valuable advice. Open tasks: 1. More hardware bring-ups and more drivers 2. Finish SMP support 3. VFP/NEON support __________________________________________________________________ Google Summer of Code 2012 URL: http://www.freebsd.org/projects/summerofcode.html URL: https://wiki.freebsd.org/SummerOfCode2012 Contact: FreeBSD Summer of Code Administrators Over the Summer of 2012, FreeBSD were once again granted a place to participate in the Google Summer of Code program. We received a total of 32 project proposals, and were ultimately given 15 slots for university students to work on open source projects mentored by existing FreeBSD developers. We were able to accept a wide spread of proposals, covering both the base system and the ports infrastructure. We had students working on file systems, file integrity checking, and parallelization in the ports collection. Students worked on kernel infrastructure, including one project to support CPU resource limits on users, processes and jails, and one student improving the BSD callout(9) and timer facilities. Two students worked on the ARM platform, widely used in embedded systems and smart phones; one student worked on a significant cleanup and improvements to the Flattened Device Tree implementation code, while the other ported FreeBSD to the OMAP3-based BeagleBoard-xM device. One student worked on improving IPv6 support in userland tools, whilst another worked on BIOS emulation for the BHyVE BSD-licensed hypervisor, new in FreeBSD 10. Other students worked on EFI boot support, userland lock profiling and an automated kernel crash reporting system. Overall, a significant proportion of the code produced has or will be integrated into FreeBSD in one form or another. All of the work is available in our Summer Of Code Subversion repository, and some of the work has already been merged back into the main repositories. FreeBSD is once again grateful to Google for being selected to participate in Summer of Code 2012. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The KDE/FreeBSD team have continued to improve the experience of KDE software and Qt under FreeBSD. The latest round of improvements include: * Fixes for building Qt with libc++ and C++11 * Fixes for Solid-related crashes * Fix battery detection in battery monitor plasmoid The team has also made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.9.1 (area51) and 4.8.4 (ports) * Qt: 4.8.3 (area51) * PyQt: 4.9.4 (area51); QScintilla 2.6.2 (area51); SIP: 4.13.3 (area51) * Calligra: 2.4.3, 2.5-RC2, 2.5.0. 2.5.1, 2.5.2 (area51) and 2.4.3, 2.5.0, 2.5.1 (ports) * Amarok: 2.6.0 (area51) * CMake: 2.8.9 (ports) * Digikam (and KIPI-plugins): 2.7.0, 2.8.0, 2.9.0 (area51) and 2.7.0, 2.9.0 (ports) * QtCreator: 2.6.0-beta (area51) * many smaller ports The team is always looking for more testers and porters so please contact us at kde@FreeBSD.org and visit our home page at http://FreeBSD.kde.org. Open tasks: 1. Please see 2012 Q4 Status Report 2. Updating out-of-date ports, see PortScout for a list __________________________________________________________________ Native iSCSI Target Contact: Edward Tomasz Napieral/a During the July-September time period, the Native iSCSI Target project was officially started under sponsorship from the FreeBSD Foundation. Before the end of September I've written ctld(8), the userspace part of the target, responsible for handling configuration, accepting incoming connections, performing authentication and iSCSI parameter negotiation, and handing off connections to the kernel. For the time being, I've reused some parts of protocol-handling code from the istgt project; since ctld(8) only handles the Login phase, the code can be rewritten in a much simpler and shorter way in the future. __________________________________________________________________ Parallel rc.d execution URL: https://github.com/buganini/rcexecr URL: https://github.com/kil/rcorder Contact: Kuan-Chung Chiu Contact: Kilian There are two implementations to make rc.d execution parallel. Compared to Kil's rcorder, rcexecr brings more concurrence and provides more flexibility than older "early_late_divider" mechanism but require more invasive /etc patch. Both implementations have switch to toggle parallel execution. Further modification/integration needs more discussion. Open tasks: 1. Refine /etc/rc.d/* to eliminate unnecessary waiting. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr Contact: Thomas Abthorpe Contact: Port Management Team The ports tree approaches 24,000 ports, while the PR count still is above 1000. In Q3 we added 2 new committers and took in two commits bit for safe keeping. The Ports Management team had performed multiple -exp runs, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Beat Gaetzi took over the role of sending out fail mails, a role that Pav Lucistnik had previously held. Beat also undertook the task of converting the Ports tree from CVS to Subversion. Florent Thoumie stepped down from his role on portmgr, he was instrumental in maintaining the legacy pkg_* code. Open tasks: 1. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ The FreeBSD Core Team Contact: Core Team Along with the change in the Core Team membership, several related roles changed hands. Gabor Pali assumed the role of core secretary from Gavin Atkinson, and David Chisnall replaced Robert Watson as liaison to the FreeBSD Foundation. The Core Team felt there was no longer a need for a formal security team liaison, so that role was retired. In the third quarter, the Core Team granted access for 2 new committers and took 2 commit bits into safekeeping. The Core Team worked with the Port Management Team and Cluster Administrators to set a date to stop providing CVS exports for the ports repository, which is February 28, 2013. In the meantime, the CVS export for 9.1-RELEASE was restored. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki Web page (htdocs): Newsflash and some other updates in the English version were translated to keep them up-to-date. Especially "security incident on FreeBSD infrastructure" was translated and published in a timely manner. FreeBSD Handbook: Big update in the "advanced-networking". With this update, merging translation results from the handbook in the local repository of Japanese documentation project into the main repository was completed. This chapter is still outdated and needs more work. The other sections have also constantly been updated. Especially, new subsection "Using pkgng for Binary Package Management" was added to "ports" section and "Using subversion" subsection was added to "mirrors" section. Article: Some progress was made in "Writing FreeBSD Problem Reports" and "Writing FreeBSD Problem Reports" articles. Open tasks: 1. Further translation work of outdated documents in the ja_JP.eucJP subtree. __________________________________________________________________ From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 13:54:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C31A567A for ; Mon, 4 Mar 2013 13:54:04 +0000 (UTC) (envelope-from isabell@issyl0.co.uk) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id 854711997 for ; Mon, 4 Mar 2013 13:54:04 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id p1so2792458vcq.20 for ; Mon, 04 Mar 2013 05:54:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=TAF5gStlzh2lRTRynJnPHC8g/JD6grypvGawb0QOpBE=; b=glirFYUqRvvcsF1YSi4sTGR/hZH4KtcVkpfyYGEtl5Fs2O7uQvjr6lBsRp1Z9r7sX7 DG+buE9l/cAWWGFojJa9nA9uRYGZBzfpvveA4mGGtrfo+lgBsIwcAAeIAFhIn8rp8IUA RmcasxvY+i9FPfb1m63I0/E9WQtfEeHiygtDMlmyabUKmpijSequRilui8ucZWnCTyRJ 8DDyFk0tB3LRB6KsBcYaLK4X63Dg5i3rCjFo6sapYJc9KY0xUv4PPUPTX879/YU0srhT WXYAFJ8qtXxl6MlUHsU3/PRSYSLm+wq5brfNr0CnJIYk/tMPBie3XL8TBjxKlbix/Qiu wcaQ== MIME-Version: 1.0 X-Received: by 10.220.242.73 with SMTP id lh9mr7566953vcb.49.1362405243743; Mon, 04 Mar 2013 05:54:03 -0800 (PST) Sender: isabell@issyl0.co.uk Received: by 10.220.250.138 with HTTP; Mon, 4 Mar 2013 05:54:03 -0800 (PST) X-Originating-IP: [2.29.6.249] Date: Mon, 4 Mar 2013 13:54:03 +0000 X-Google-Sender-Auth: OHpE0Y1ylrkCvNGJ-qAPGcvxdCs Message-ID: Subject: FreeBSD Quarterly Status Report, October-December 2012. From: Isabell Long To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkbk1floD+lU21WqRoqTHqGwbNQ8zTnJOTLcy6r6xxP3jCQAf9n/3XyEVlAs4hqkoUAgW9d Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 13:54:04 -0000 FreeBSD Quarterly Status Report, October-December 2012. Introduction This report covers FreeBSD-related projects between October and December 2012. This is the last of four reports planned for 2012. Highlights from this status report include a very successful EuroBSDCon 2012 conference and associated FreeBSD Developer Summit, both held in Warsaw, Poland. Other highlights are several projects related to the FreeBSD port to the ARM architecture, extending support for platforms, boards and CPUs, improvements to the performance of the pf(4) firewall, and a new native iSCSI target. Thanks to all the reporters for the excellent work! This report contains 27 entries and we hope you enjoy reading it. The deadline for submissions covering the period between January and March 2013 is April 21st, 2013. __________________________________________________________________ Projects * BHyVe * Native iSCSI Target * NFS Version 4 * pxe_http -- booting FreeBSD from apache * UEFI * Unprivileged install and image creation Userland Programs * BSD-licenced patch(1) * bsdconfig(8) FreeBSD Team Reports * FreeBSD Core Team * FreeBSD Documentation Engineering * FreeBSD Foundation * Postmaster Kernel * AMD GPUs kernel-modesetting support * Common Flash Interface (CFI) driver improvements * SMP-Friendly pf(4) * Unmapped I/O Documentation * The FreeBSD Japanese Documentation Project Architectures * Compiler improvements for FreeBSD/ARMv6 * FreeBSD on AARCH64 * FreeBSD on BeagleBone * FreeBSD on Raspberry Pi Ports * FreeBSD Haskell Ports * KDE/FreeBSD * Ports Collection * Xfce Miscellaneous * EuroBSDcon 2012 * FreeBSD Developer Summit, Warsaw __________________________________________________________________ AMD GPUs kernel-modesetting support URL: https://wiki.FreeBSD.org/AMD_GPU URL: http://people.FreeBSD.org/~kib/misc/ttm.1.patch Contact: Alexander Kabaev Contact: Jean-S=E9bastien P=E9dron Contact: Konstantin Belousov Jean-S=E9bastien P=E9dron started to port the AMD GPUs driver from Linux= to FreeBSD 10-CURRENT in January 2013. This work is based on a previous effort by Alexander Kabaev. Konstantin Belousov provided the initial port of the TTM memory manager. As of this writing, the driver is building but the tested device fails to attach. Status updates will be posted to the FreeBSD wiki. __________________________________________________________________ BHyVe URL: https://wiki.FreeBSD.org/BHyVe URL: http://www.bhyve.org/ Contact: Neel Natu Contact: Peter Grehan BHyVe is a type-2 hypervisor for FreeBSD/amd64 hosts with Intel VT-x and EPT CPU support. The bhyve project branch was merged into CURRENT on Jan 18. Work is progressing on performance, ease of use, AMD SVM support, and being able to run non-FreeBSD operating systems. Open tasks: 1. 1. Booting Linux/*BSD/Windows 2. 2. Moving the codebase to a more modular design consisting of a small base and loadable modules 3. 3. Various hypervisor features such as suspend/resume/live migration/sparse disk support __________________________________________________________________ BSD-licenced patch(1) URL: http://code.google.com/p/bsd-patch/ Contact: Pedro Giffuni Contact: Gabor Kovesdan Contact: Xin Li FreeBSD has been using for a while a very old version of GNU patch that is partially under the GPLv2. The original GNU patch utility is based on an initial implementation by Larry Wall that was not actually copyleft. OpenBSD did many enhancements to an older non-copyleft version of patch, this version was later adopted and further refined by DragonFlyBSD and NetBSD but there was no centralized development of the tool and FreeBSD kept working independently. In less than a week we took the version in DragonFlyBSD and adapted the FreeBSD enhancements to make it behave nearer to the version used natively in FreeBSD. Most of the work was done by Pedro Giffuni, adapting patches from sepotvin@ and ed@, and additional contributions were done by Christoph Mallon, Gabor Kovesdan and Xin Li. As a result of this we now have a new version of patch committed in head/usr.bin/patch that you can try by using WITH_BSD_PATCH in your builds. The new patch(1) doesn't support the FreeBSD-specific -I and -S options which don't seem necessary. In GNU patch -I actually means 'ignore whitespaces' and we now support it too. Open tasks: 1. Testing. A lot more testing. __________________________________________________________________ bsdconfig(8) URL: http://svnweb.FreeBSD.org/base/head/usr.sbin/bsdconfig/ URL: http://freshports.org/sysutils/bsdconfig/ URL: http://druidbsd.sf.net/download/bsdconfig/ Contact: Devin Teske bsdconfig(8) is actively being developed in HEAD under the WITH_BSDCONFIG build-requirement. Snapshots are occasionally taken and made available through the ports system to make testing on 9.0-RELEASE or higher easier on the testers. Currently HEAD is far beyond the version 0.7.3 sitting in ports. Upcoming changes will push this to version 0.8 bringing in the necessary frameworks required for in-depth package management and distribution maintenance (read: one step closer to full 1.0 release). __________________________________________________________________ Common Flash Interface (CFI) driver improvements Contact: Brooks Davis The Common Flash Interface provides a common programming interface for a wide range of NOR flash devices commonly found in embedded systems. I have developed a number of improvements to the cfi(4) device when used on Intel StrataFlash parts. Unnecessary erase cycles are now avoided, devices that require single word writes only write changed words, and multi-word writes are supported for Intel and Sharp devices. Additionally the timeout code has been reworked and no longer imposes unneeded latency on operations taking less than 100us. With all of these changes streaming write speed has improved by more than an order of magnitude. Once these changes are reviewed they will be committed to HEAD. This work was sponsored by DARPA and AFRL. __________________________________________________________________ Compiler improvements for FreeBSD/ARMv6 Contact: Andrew Turner FreeBSD/ARM architecture is now supported by the in-tree clang compiler. ARM EABI support is now available for both clang and gcc along with the older and less documented OABI. There are several outstanding issues, once they are fixed EABI will be made default. Open tasks: 1. Test EABI builds 2. Fix exception handling for EABI 3. Test clang builds 4. Get clang to work natively on EABI-based ARM system. Currently it works only as cross-compiler for ARM EABI. __________________________________________________________________ EuroBSDcon 2012 URL: http://2012.eurobsdcon.org/ URL: http://www.youtube.com/user/eurobsdcon Contact: EuroBSDcon Organizers Contact: Gabor Pali The 11th European BSD Conference took place in Warsaw, Poland at the Warsaw University of Technology with a large number of visitors. It started up with two tracks of tutorials, featuring FreeNAS, pfSense, DTrace, PF, development of NetBSD drivers, and an overall introduction to the FreeBSD operating system given by Kirk McKusick. There we also had opening and closing keynotes, supplemented with 22 talks on different topics related to FreeBSD, OpenBSD, NetBSD, FreeNAS and PC-BSD: BHyVe, configuration management with puppet, improvements in the OpenBSD cryptographic framework, tuning ZFS, server load balancing in DNS, running FreeBSD on embedded systems, e.g MIPS and ARM, and challenges in identity management and authentication. The conference also had a dedicated track presented by the attendees of the FreeBSD developer summit and open to all, where one could learn more about what is happening currently in the Project: results of Google Summer of Code 2012, architectural changes in the FreeBSD documentation tree, ILNP, advancements in package building and development of pkg(8), and a status report on the USB stack. __________________________________________________________________ FreeBSD Core Team Contact: Core Team In the fourth quarter, the Core Team granted access for 7 new committers, and took 1 commit bit in for safekeeping. The Core Team oversaw the response to the security incident in November in cooperation with the security team, port managers, and cluster administrators. For more information on the fallouts and response see the official announcement. As a result, 9.1-RELEASE was delayed until late December and was released with a limited set of binary packages. The Core Team continues to work with developers to rebuild, review, and restore the package building infrastructure along with redports/QAT. __________________________________________________________________ FreeBSD Developer Summit, Warsaw URL: http://wiki.FreeBSD.org/201210DevSummit Contact: Gabor Pali We had 53 FreeBSD developers and invited guests attending the FreeBSD Developer Summit organized as part of EuroBSDcon 2012 in Warsaw, Poland at the Warsaw University of Technology. This year EuroBSDcon organizers again offered us their generous support in helping with keeping the event running smooth, helping with registrations, renting the venue, and providing food for keeping attendees satisfied and happy. The Warsaw developer summit spanned over 3 days and had 9 working groups on various topics. We improved last year's layout inherited from the Canadian summits because it has worked well earlier but could use some further refinements. On both the first and second days, we ran the working groups, ranging from the standard matters, discussing issues with the USB stack, the compiler toolchain, the Ports Collection, or the documentation to some experimental ones, e.g. arranging an operating systems course focusing on FreeBSD. In addition to this, similarly to last year, one of the working groups was about gathering vendors to present their ideas and engage in discussion with the developers on their needs from the Project. Finally, on the third day, there were a number of exciting work-in-progress reports given in a dedicated Developer Summit track at the main conference. Photos and slides for the most of the talks are available on the home page of the summit. __________________________________________________________________ FreeBSD Documentation Engineering URL: http://www.FreeBSD.org/internal/doceng.html Contact: Glen Barber Contact: Marc Fonvieille Contact: G=E1bor K=F6vesd=E1n Contact: Hiroki Sato The translations/, projects/ and user/ directories of the doc repository have been opened with the announced policies in effect. These branches are now actively used for translations work, editing the upcoming printed version of the Handbook, and some doc infrastructure improvements. The next phase of the infrastructure improvements is in progress. It will migrate to real XML tools (with the exception of Jade) for validation and rendering. At the same time, the DocBook schema will be updated to 4.5. After long discussions, Google Analytics has been enabled on FreeBSD.org webpages but access to statistical data has to be solicited from the Documentation Engineering Team on an individual and one time basis. Since July, we have added two doc committers and one translator. Open tasks: 1. Help the ongoing work on printed edition of the Handbook. 2. Finish the migration to XML tools. __________________________________________________________________ FreeBSD Foundation Contact: Deb Goodkin A strong year-end fundraising campaign led to the raising $770,000 in 2012. Thank you to everyone who made a donation to support FreeBSD! We published our year-end newsletter that highlighted everything we did to support the FreeBSD Project and community during the second half of the year. We were a Gold Sponsor for EuroBSDCon. We also attended the conference and developer summit. Erwin Lansing organized and chaired the Ports and Package Summit and Vendor Summit at EuroBSDCon 2012. We attended MeetBSD developer summit November 2012. George Neville-Neil organized and the Foundation sponsored the Bay Area Vendor Summit November 2012. We were represented at LISA. Kirk McKusick taught a tutorial and gave a keynote at EuroBSDCon 2012, and Justin Gibbs gave a talk at ZFS Day, October 2012. We talked to DNS server software vendors and participated in discussions on our DNS implementation, specifically with regard to DNSSEC validation, at CENTR Tech September 2012 (Amsterdam, the Netherlands) and EuroBSDCon. We visited companies to discuss their FreeBSD use and to help facilitate collaboration with the Project. Robert Watson published ACM Queue and Communications of the ACM: A decade of OS access-control extensibility and Kirk McKusick published ACM Queue and Communications of the ACM: Disks from the Perspective of a File System. We negotiated/supervised Foundation funded projects: porting FreeBSD to the Efika ARM platform, Capsicum Component Framework, Native iSCSI Target implementation, and EUFI. We negotiated/supervised/funded hardware needs in FreeBSD co-location centers. Many board members provided support for recovery efforts following the security compromise of FreeBSD.org systems in late 2012. We completed negotiation and provided legal counsel for the new website privacy policy for the FreeBSD Project. We are now an industrial partner in the Cambridge/Imperial/Edinburgh EPSRC REMS project on the Rigorous Engineering of Mainstream Systems. We coordinated the Foundation's discussion of Jira/Java; conclusion, will continue to be supportive of OpenJDK and not restart proprietary JDK support. We implemented a donor management database to help with our fundraising efforts. We also began working on automating the donation process. We started the Faces of FreeBSD Series where we share the story of a Foundation grant recipient periodically. This allows us to spotlight people who received Foundation funding to work on development projects, run conferences, travel to conferences, and advocate for FreeBSD. We hired two technical staff members. __________________________________________________________________ FreeBSD Haskell Ports URL: http://wiki.FreeBSD.org/Haskell URL: https://github.com/FreeBSD-haskell/FreeBSD-haskell/ Contact: G=E1bor P=C1LI Contact: Ashish SHUKLA We are proud to announce that the FreeBSD Haskell Team has updated the Haskell Platform to 2012.4.0.0, GHC to 7.4.2 as well as updated existing ports to their latest stable versions. All Haskell ports are also updated to use new OPTIONS framework, and now, building with dynamic libraries (DYNAMIC) is on by default. GHC also uses GCC 4.6 and binutils 2.22 from ports. We also added a number of new Haskell ports, and their count in FreeBSD Ports tree is now 368. Open tasks: 1. Test GHC to work with clang/LLVM. 2. Commit pending Haskell ports to the FreeBSD Ports tree. 3. Add more ports to the Ports Collection. __________________________________________________________________ FreeBSD on AARCH64 URL: https://github.com/zxombie/aarch64-freebsd-sandbox URL: http://www.arm.com/products/tools/models/fast-models/foundation-model.p hp Contact: Andrew Turner Work has started on porting FreeBSD to AARCH64, ARM's new 64-bit architecture, using the ARMv8 Foundation Model software. GCC and binutils have been ported to FreeBSD and work started on kernel initialization, including MMU setup. Open tasks: 1. Get the MMU working 2. Get system register documentation from ARM 3. Port clang AArch64 to FreeBSD 4. Bring the code into a FreeBSD project branch __________________________________________________________________ FreeBSD on BeagleBone Contact: Tim Kientzle Contact: Oleksandr Tymoshenko Contact: Damjan Marion Contact: Brett Wynkoop FreeBSD on BeagleBone is benefiting from the general work on ARM stability being done by many people, and is proving to be a nice testbed for our ARMv7 support. All ongoing work is happening now directly in -CURRENT and we expect it to be in pretty good shape by the time 10.0 ships. The network driver is now pretty stable; the system should be useful as a small network device. Occasional system snapshots are being built and advertised for people to test. Ask on freebsd-arm@ if you'd like to try the newest one. Open tasks: 1. We need someone to finish the USB driver. Ask if you'd like to take this over. 2. MMCSD performance is still rather poor. 3. There's been discussion of how to improve the GPIO configuration and pinmux handling to simplify hardware experimentation. If we had more people to help build drivers, we could start supporting some of the BeagleBone capes. 4. Mostly we just need people to use it and report any issues they encounter. __________________________________________________________________ FreeBSD on Raspberry Pi Contact: Oleksandr Tymoshenko FreeBSD is running on Raspberry Pi and supports the following peripherals: * USB controller * SDHC controller * Network * Framebuffer (HDMI and composite) * GPIO * VCHI interface Videocore tests (OpenGL, video decoding, audio, display access) work with current VCHI driver implementation. Open tasks: 1. Add DMA mode support to USB driver. Some proof-of-concept code is done but more work required to finish it. 2. Re-implement VCHI driver with more FreeBSD-friendly locking. 3. Implement more drivers: SPI, PWM, audio. __________________________________________________________________ Google Summer of Code 2013 URL: http://www.FreeBSD.org/projects/summerofcode.html URL: http://google-opensource.blogspot.co.uk/2013/02/flip-bits-not-burgers-g oogle-summer-of.html URL: http://www.google-melange.com/gsoc/homepage/google/gsoc2013 URL: http://en.wikipedia.org/wiki/Google_Summer_of_Code Contact: FreeBSD Summer of Code Administrators Since 2005 Google has run its yearly Summer of Code program, in which Google awards stipends to students who successfully complete projects with participating Open Source organisations. FreeBSD has participated in GSoC every year since its inception, and with the announcement that Google will once again run the program in 2013 hopes to participate once more. Google have not yet opened the application period for mentoring organisations, but once it does FreeBSD plans to apply. Assuming that we are successful in our application to participate, we will publish a large list of ideas for possible projects shortly after. Students may then apply to do one of those projects, or suggest their own idea for a project. After the application period, FreeBSD will discover how many student slots we have been allocated, at which point successful students will take some time to plan their project, gather required information and discuss their plans with their mentors, before having around 12 weeks to develop their code. In the eight years of FreeBSD's participation in Google Summer of Code, approximately 150 students have successfully complete projects with us, covering a wide spread of areas of both the source and ports trees. Of these, 22 students continued participating with FreeBSD and subsequently became full FreeBSD committers, many later going on to mentor Summer of Code students themselves. Whether FreeBSD has been successful in being selected to be a participating organisation in Google Summer of Code 2013 should be announced in early April. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The KDE/FreeBSD team have continued to improve the experience of KDE software and Qt under FreeBSD. The latest round of improvements include: * Fix handling of Removable property in solid engine * Fix management of backlight with UPower (requires acpi_video(4)) * Installing spell-checking dictionaries with a dependency of KDE-locale ports The team has also made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.9.2 (area51) * PyQt: 4.9.5 (area51); SIP: 4.14 (area51) * KDevelop: 4.4.0, 4.4.1 (area51); KDevPlatform: 1.4.0, 1.4.1 (area51) * Calligra: 2.5.3, 2.5.4 (area51) * CMake: 2.8.10.1 * Many smaller ports The team is always looking for more testers and porters so please contact us at kde@FreeBSD.org and visit our home page at http://FreeBSD.kde.org. Open tasks: 1. Updating out-of-date ports, see PortScout for a list __________________________________________________________________ Native iSCSI Target Contact: Edward Tomasz Napieral/a During the October-December time period, the Native iSCSI Target project progressed to the working prototype stage. Most of this time was spent writing kernel-based part, an iSCSI frontend to the CAM Target Layer. The frontend handles iSCSI Full Feature phase after ctld(8) hands off the connection. The istgt-derived code in ctld(8) was rewritten from scratch; now it's much shorter and more readable. The ctladm(8) utility gained iSCSI-specific subcommands to handle tasks such as listing iSCSI sessions or forcing disconnection. The target works correctly with the FreeBSD initiator. __________________________________________________________________ NFS Version 4 Contact: Rick Macklem The NFSv4.1 client, including support for pNFS for the Files Layout only, has now been committed to head/current. Work on NFSv4.1 server support has just been started and will hopefully be ready for head/current this summer. The client side disk caching of delegated files is progressing and the code is under projects/nfsv4-packrats in the subversion repository. Someone is working on server side referrals and, as such, I hope this might make it into 10.0 as well. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr Contact: Thomas Abthorpe Contact: Port Management Team The ports tree crossed the threshold of 24,000 ports, while the PR count still is close to 1600. In Q4 we added five new committers and took in two commit bits for safe keeping. In the tradition of recruiting new portmgr@ at conferences, we added Bernhard Froehlich to our ranks. He is the one responsible for redports.org Pav Lucistnik stepped down from his role on portmgr, he was one of our principles doing -exp runs and well known for sending failmails. In the well publicised compromise, the pointyhat machines were broken into and subsequently taken down, isolated and sanitised. As a pre-emptive move redports/QAT were also taken down. Work is under way to restore the services. Mark Linimon began a from-scratch test install on one of his own spare machines with the purpose of documenting all the missing steps from the portbuild article. While doing so, he further overhauled the codebase to both make it easier to install, and to further refactor it in light of a security review (still ongoing at time of this writing). Once this is complete, the next task will be to reinstall all existing machines from scratch. Open tasks: 1. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ Postmaster Contact: David Wolfskill The postmaster team has expanded, with the addition of Florian Smeets (flo@FreeBSD.org). We have implemented a Mailman "handler" to drop duplicate messages when both copies are sent to the same list (under both the "long" (e.g., "freebsd-current") and "short" (e.g., "current") names). We have created several new mailing lists: * freebsd-course: educational course on FreeBSD * freebsd-numerics: Discussions of high quality implementation of libm functions. * freebsd-snapshots: FreeBSD Development Snapshot Announcements * freebsd-tcltk: FreeBSD-specific Tcl/Tk discussions We have also removed old mailing lists: * freebsd-binup * freebsd-www (merged into freebsd-doc) __________________________________________________________________ pxe_http -- booting FreeBSD from apache URL: http://svnweb.FreeBSD.org/base/user/sbruno/pxe_http_head/ Contact: Sean Bruno Currently works with VirtualBox VMs and Apache 2.2 port. Open tasks: 1. Lots and lots of compile warnings exist with clang and gcc. This really needs to be investigated. 2. Better support for other webservers. Currently needs Apache to work. 3. Needs another pass at basic documentation. Current documentation is actually quite good from the original 4. Network stack needs audit. I'm not sure if the HTTP/TCP/UDP/IP code is original or based on something else. __________________________________________________________________ SMP-Friendly pf(4) Contact: Gleb Smirnoff The project is aimed at moving the pf(4) packet filter out of a single mutex, as well as in general improving of the FreeBSD port. The project has reached its main goal. The pf(4) is no longer covered by single mutex and contention on network stack on pf(4) is now very low. The code is production ready. The projects/pf branch had been merged to the head branch and will be available in 10.0-RELEASE. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki The ja_JP.eucJP subtree has constantly been updated since the last status report. In FreeBSD Handbook, translation work of the "users" section has been completed. "linuxemu" and "serialcomms" were updated and subsection "Subversion mirror site" was newly added to "mirrors" section. Open tasks: 1. Further translation work of outdated documents in the ja_JP.eucJP subtree. __________________________________________________________________ UEFI URL: https://wiki.FreeBSD.org/UEFI URL: http://svnweb.FreeBSD.org/base/projects/uefi/ Contact: Benno Rice There is code in the projects/uefi branch that can build a working 64-bit loader for UEFI. This loader can load a kernel and boot to a mountroot prompt on a serial console on a system with <=3D 1GB of RAM. Full multiuser has not yet been tested. Work is progressing towards having a working syscons. The issue preventing boot on systems with > 1GB of RAM has not yet been found. UEFI-compatible boot media can be generated using in-tree tools, however there are issues with detecting the CD filesystem and using it as the load default. The 64-bit UEFI loader can load a 32-bit kernel but currently cannot hand over to it due to a lack of code to switch to 32-bit mode. Further research is required into Secure Boot. __________________________________________________________________ Unmapped I/O URL: http://people.FreeBSD.org/~kib/misc/unmapped.13.patch Contact: Jeff Roberson Contact: Konstantin Belousov A well-known performance problem of FreeBSD on large SMP hardware is the need to invalidate TLB for all CPUs when instantiating and destroying the VMIO buffers. Invalidation is performed by sending inter-processor interrupt broadcast, which disrupts the execution path of each CPU, and induces latency on the request itself. Since most I/O requests processing require creation of the buffers to hold the data in the kernel, TLB invalidation becomes an obstacle for I/O scalability on many-CPU machines. The work done for flushing the TLBs is especially meaningless since most mappings created are not used for anything but copying the data from the usermode to the kernel page cache forth and back. Most architectures have already established facilities to perform such copies using much faster techniques, for instance, the direct map on amd64, or specially reserved per-CPU page frames or TLB entries on other architectures. Jeff Roberson unified the machine-specific parts of the busdma(9), making a common set of low-level functions available on each architecture. This was committed as r246713. The end result is that the new types of the load functions can be added in the single, machine-independent place. In particular, it is easy to modify the drivers to accept the 'unmapped' bio requests, which lists the vm pages for the device dma engine, instead of the virtual address of the kernel buffer. Konstantin Belousov developed the changes for buffer cache which allow the VMIO buffers to not map the referenced pages, and used the feature for UFS. Per-architecture pmap_copy_pages(9) methods were added to facilitate fast copying between user I/O buffers and pages of unmapped buffers. The unmapped buffers create the unmapped bio requests for the drivers, support for which was made possible by Jeff's patch. Tests show that even on a small 4-core machine, the system time for reading files on UFS is reduced by 30%. Open tasks: 1. Test the patch, in particular, on non-x86 architectures. __________________________________________________________________ Unprivileged install and image creation Contact: Brooks Davis In order to make it easier to build releases and embedded system disk images I have been adding infrastructure to allow the install and packaging stages to the FreeBSD build progress to run without root privilege. To this end I have added two options to the toplevel build system: The -DDB_FROM_SRC option allows the install to proceed when the required set of passwd and group entires does not match the host system. The -DNO_ROOT option causes files to be installed as the running user and for metadata such as owner, group, suid bits, and file flags to be logged in a ${DESTDIR}/METALOG file. This work required the import of NetBSD's mtree and the addition of a number of features from NetBSD to install. I have added all FreeBSD features to NetBSD's mtree and imported it as nmtree. Before FreeBSD 10.0 is released I will replace our version. I have also added all required features to install. Changes to makefs were required to parse the contents of the METALOG file. These new features required importing new versions of the pwcache(3) and vis(3) APIs from NetBSD so those portions of libc. In addition to modifying build infrastructure to use the new features of mtree and install. I corrected a number of cases of files being installed by programs other than install or being installed more than once. A few known instances of duplicate directories in the output exist, but the results are usable in some contexts. I plan to MFC these changes as far back as the stable/8 branch to make it possible to build all supported releases without root privilege. This work was sponsored by DARPA and AFRL. Open tasks: 1. Add support for -DNO_ROOT to src/release/Makefile so that releases can be built without root privilege. 2. Create a tool to install partition tables and file system images in disk image files without the use of mdctl, gpart, and dd. __________________________________________________________________ Xfce URL: https://wiki.FreeBSD.org/Xfce Contact: A major update has been made to Thunar (file manager for the Xfce Desktop Environment). 1.6.x series introduce lots of improvements, most noticeably is tabs support, and the performance has been improved. Open tasks: 1. Try to fix HSTS (HTTP Strict Transport Security) feature in Midori with Vala 0.12.1 (works fine with Vala >=3D 0.14.x) 2. Replace libxfce4gui (deprecated and not maintained by upstream) by libxfce4ui in order to enhance support for Xfce >=3D 4.10. 3. Test core and plugins (panel, Thunar) with GLib >=3D 4.32 (to replac= e deprecated and removed functions introduced since GLib 2.30). 4. Fix gtk-xfce-engine with Gtk+ >=3D 3.6. __________________________________________________________________ From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 14:15:28 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 09A50103; Mon, 4 Mar 2013 14:15:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 749A31AC4; Mon, 4 Mar 2013 14:15:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r24EFLuB038772; Mon, 4 Mar 2013 16:15:21 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r24EFLuB038772 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r24EFJ80038709; Mon, 4 Mar 2013 16:15:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 4 Mar 2013 16:15:19 +0200 From: Konstantin Belousov To: Poul-Henning Kamp Subject: Re: access to hard drives is "blocked" by writes to a flash drive Message-ID: <20130304141519.GA3794@kib.kiev.ua> References: <201303040712.r247CejP008718@gw.catspoiler.org> <25327.1362404670@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <25327.1362404670@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: deeptech71@gmail.com, Don Lewis , freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 14:15:28 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 04, 2013 at 01:44:30PM +0000, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=3DISO-8859-1 > -------- > In message <201303040712.r247CejP008718@gw.catspoiler.org>, Don Lewis wri= tes: >=20 > >Prior to 231160, the syncer thread would call sync_vnode() for the > >syncer vnode of each mountpoint every 30 seconds [...] >=20 > I agree that the lemming syncer is better, but the fundamental mistake of > only having one syncer thread is probably the root-cause in this case: > One camera-grade flash syncing may take (a lot) more than 30 seconds. >=20 > One mountpoint having trouble (of whatever kind) should not affect > the rest of the mountpoints. >=20 > I'm not sure if the syncer is untangled enough that we can have > per mount-point threads yet, but as soon as we can, we should do that. The problem with "wdrain" is not due to any algorithm in the syncer. I explained it in some details in other mail. --huq684BweRXVnRxX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRNKx2AAoJEJDCuSvBvK1B4kEP/jI/E6OuUPHAKxRxhKgwdqT4 na1z1cFRq0tfznZ6S1SrPREGkwQkBaXgDhdKZcF01cjRcbrgYmF0VTBeS6lUzWUr ibqzHS2USCthRMnH8ENgUxr2ExIx0S0HbwIMzQkt0KQfE/JZsxxraO08iwaOWJTC VJXalPGl9QEJkpRKccl1UPF4KrIZn3T5HbYqA2tGZQiK0UyNmU6xty1EYSG/M3yf A8/JZUpdAwPicDIvRdDniMgu7CX4JLvbFTjr/sfCH9VOThdbaqZZzZz2GuSqn5cq bi9GAkEJd4loeVA+5RAy4RSQwKeZacQQPT+8F+O1Y32NHWdOgKKb8zg+B2qwAnm4 GdPKWYq9lYfUHSimtH5jwMdBUW6wBF8JI9baDQXmUlrjvhLN3jDt/HRm+y1b/Y4k GzbyBCPMygQKj/Axq5RvGUdeGBcRtUwhe6UE89P7CSy4DnLF5YJKTUy59Unf/F0c r2K5vT2BsRyuW0V+hItBjaa2AtwcLMcmy/Jfbf2f/juHTWx3tYdoVypheZ8O3wRn U1T7ohNgueS8JoD+9KEh7/Wz/iH/cei0YSO5V3vRv5g2t+ykEkM5SGyayR4wcs12 1oYMGpq6hl7vReX3WOVMnAtERHaqfK9LE2sg7JNG/3TVyhqj0sqQ+RqpgxzXEC5t QppEiB2V8JVSeanDDNFr =e4gL -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 15:10:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C49AD662; Mon, 4 Mar 2013 15:10:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA751F38; Mon, 4 Mar 2013 15:10:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r24FAKxq016811; Mon, 4 Mar 2013 10:10:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r24FAJds016806; Mon, 4 Mar 2013 15:10:19 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Mar 2013 15:10:19 GMT Message-Id: <201303041510.r24FAJds016806@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:10:26 -0000 TB --- 2013-03-04 13:20:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 13:20:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-04 13:20:20 - starting HEAD tinderbox run for armv6/arm TB --- 2013-03-04 13:20:20 - cleaning the object tree TB --- 2013-03-04 13:20:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 13:20:24 - At svn revision 247790 TB --- 2013-03-04 13:20:25 - building world TB --- 2013-03-04 13:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 13:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 13:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 13:20:25 - SRCCONF=/dev/null TB --- 2013-03-04 13:20:25 - TARGET=arm TB --- 2013-03-04 13:20:25 - TARGET_ARCH=armv6 TB --- 2013-03-04 13:20:25 - TZ=UTC TB --- 2013-03-04 13:20:25 - __MAKE_CONF=/dev/null TB --- 2013-03-04 13:20:25 - cd /src TB --- 2013-03-04 13:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 13:20:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Mar 4 15:09:36 UTC 2013 TB --- 2013-03-04 15:09:36 - generating LINT kernel config TB --- 2013-03-04 15:09:36 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:36 - /usr/bin/make -B LINT TB --- 2013-03-04 15:09:37 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:37 - /usr/sbin/config -m LINT TB --- 2013-03-04 15:09:37 - skipping LINT kernel TB --- 2013-03-04 15:09:37 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:37 - /usr/sbin/config -m AC100 TB --- 2013-03-04 15:09:37 - building AC100 kernel TB --- 2013-03-04 15:09:37 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 15:09:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 15:09:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 15:09:37 - SRCCONF=/dev/null TB --- 2013-03-04 15:09:37 - TARGET=arm TB --- 2013-03-04 15:09:37 - TARGET_ARCH=armv6 TB --- 2013-03-04 15:09:37 - TZ=UTC TB --- 2013-03-04 15:09:37 - __MAKE_CONF=/dev/null TB --- 2013-03-04 15:09:37 - cd /src TB --- 2013-03-04 15:09:37 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Mon Mar 4 15:09:37 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thr.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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thread.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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_time.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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_timeout.c /src/sys/kern/kern_timeout.c: In function 'softclock_call_cc': /src/sys/kern/kern_timeout.c:659: error: 'sbt1' undeclared (first use in this function) /src/sys/kern/kern_timeout.c:659: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_timeout.c:659: error: for each function it appears in.) *** [kern_timeout.o] Error code 1 Stop in /obj/arm.armv6/src/sys/AC100. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 15:10:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 15:10:19 - ERROR: failed to build AC100 kernel TB --- 2013-03-04 15:10:19 - 5357.04 user 948.99 system 6599.22 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 15:16:22 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2B89080E; Mon, 4 Mar 2013 15:16:22 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id F36A11F99; Mon, 4 Mar 2013 15:16:21 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCX7l-000Izr-5O; Mon, 04 Mar 2013 15:16:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r24FGHaU091570; Mon, 4 Mar 2013 08:16:17 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+zywGXsN5SBd4z+krwkjYe Subject: Re: access to hard drives is "blocked" by writes to a flash drive From: Ian Lepore To: Don Lewis In-Reply-To: <201303040301.r2431Rjm008175@gw.catspoiler.org> References: <201303040301.r2431Rjm008175@gw.catspoiler.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Mar 2013 08:16:17 -0700 Message-ID: <1362410177.1195.234.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Mar 2013 15:16:22 -0000 On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote: > On 3 Mar, Poul-Henning Kamp wrote: > > > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > > traffic to other disks too, when these pileups gets too bad. > > The Lemming-syncer problem should have mostly been fixed by 231160 in > head (231952 in stable/9 and 231967 in stable/8) a little over a year > ago. The exceptions are atime updates, mmaped files with dirty pages, > and quotas. Under certain workloads I still notice periodic bursts of > seek noise. After thinking about it for a bit, I suspect that it could > be atime updates, but I haven't tried to confirm that. > > When using TCQ or NCQ, perhaps we should limit the number of outstanding > writes per device to leave some slots open for reads. We should > probably also prioritize reads over writes unless we are under memory > pressure. > Then either those changes didn't have the intended effect, or the problem we're seeing with lack of system responsiveness when there's a large backlog of writes to a slow device is not the lemming-syncer problem. It's also not a lack of TCQ/NCQ slots, given that no such thing exists with SD card IO. When this is going on, the process driving the massive output spends almost all its time in a wdrain wait, and if you try to launch an app that isn't already in cache, a siginfo generally shows it to be in a getblk wait. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 15:18:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2799A9CF; Mon, 4 Mar 2013 15:18:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F40E41FC6; Mon, 4 Mar 2013 15:18:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r24FImGs050516; Mon, 4 Mar 2013 10:18:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r24FIm0b050515; Mon, 4 Mar 2013 15:18:48 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Mar 2013 15:18:48 GMT Message-Id: <201303041518.r24FIm0b050515@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:18:49 -0000 TB --- 2013-03-04 13:20:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 13:20:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-04 13:20:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-04 13:20:20 - cleaning the object tree TB --- 2013-03-04 13:20:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 13:20:24 - At svn revision 247790 TB --- 2013-03-04 13:20:25 - building world TB --- 2013-03-04 13:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 13:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 13:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 13:20:25 - SRCCONF=/dev/null TB --- 2013-03-04 13:20:25 - TARGET=arm TB --- 2013-03-04 13:20:25 - TARGET_ARCH=arm TB --- 2013-03-04 13:20:25 - TZ=UTC TB --- 2013-03-04 13:20:25 - __MAKE_CONF=/dev/null TB --- 2013-03-04 13:20:25 - cd /src TB --- 2013-03-04 13:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 13:20:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Mar 4 15:09:36 UTC 2013 TB --- 2013-03-04 15:09:36 - generating LINT kernel config TB --- 2013-03-04 15:09:36 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:36 - /usr/bin/make -B LINT TB --- 2013-03-04 15:09:37 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:37 - /usr/sbin/config -m LINT TB --- 2013-03-04 15:09:37 - building LINT kernel TB --- 2013-03-04 15:09:37 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 15:09:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 15:09:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 15:09:37 - SRCCONF=/dev/null TB --- 2013-03-04 15:09:37 - TARGET=arm TB --- 2013-03-04 15:09:37 - TARGET_ARCH=arm TB --- 2013-03-04 15:09:37 - TZ=UTC TB --- 2013-03-04 15:09:37 - __MAKE_CONF=/dev/null TB --- 2013-03-04 15:09:37 - cd /src TB --- 2013-03-04 15:09:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 15:09:37 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thread.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_time.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/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 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_timeout.c /src/sys/kern/kern_timeout.c: In function 'softclock_call_cc': /src/sys/kern/kern_timeout.c:659: error: 'sbt1' undeclared (first use in this function) /src/sys/kern/kern_timeout.c:659: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_timeout.c:659: error: for each function it appears in.) *** [kern_timeout.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 15:18:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 15:18:48 - ERROR: failed to build LINT kernel TB --- 2013-03-04 15:18:48 - 5776.47 user 998.45 system 7107.85 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 15:37:25 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3A4E33E6; Mon, 4 Mar 2013 15:37:25 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id EEB961A3; Mon, 4 Mar 2013 15:37:24 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCXS8-0002CQ-BC; Mon, 04 Mar 2013 15:37:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r24FbKwU091664; Mon, 4 Mar 2013 08:37:20 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+SuL5EiCRgBk44yqw3LSog Subject: Re: access to hard drives is "blocked" by writes to a flash drive From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20130304053547.GY2930@kib.kiev.ua> References: <52867.1362317749@critter.freebsd.dk> <201303040301.r2431Rjm008175@gw.catspoiler.org> <20130304053547.GY2930@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Mar 2013 08:37:20 -0700 Message-ID: <1362411440.1195.244.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: deeptech71@gmail.com, Don Lewis , freebsd-current@FreeBSD.org, peter@rulingia.com, phk@phk.freebsd.dk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Mar 2013 15:37:25 -0000 On Mon, 2013-03-04 at 07:35 +0200, Konstantin Belousov wrote: > On Sun, Mar 03, 2013 at 07:01:27PM -0800, Don Lewis wrote: > > On 3 Mar, Poul-Henning Kamp wrote: > > > > > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > > > traffic to other disks too, when these pileups gets too bad. > > > > The Lemming-syncer problem should have mostly been fixed by 231160 in > > head (231952 in stable/9 and 231967 in stable/8) a little over a year > > ago. The exceptions are atime updates, mmaped files with dirty pages, > > and quotas. Under certain workloads I still notice periodic bursts of > > seek noise. After thinking about it for a bit, I suspect that it could > > be atime updates, but I haven't tried to confirm that. > I never got a definition what a Lemming syncer term means. The (current) > syncer model is to iterate over the list of the active vnodes, i.e. > vnodes for which an open file exists, or a mapping is established, and > initiate the neccessary writes. The iterations over the active list is > performed several times during the same sync run over the filesystem, > this is considered acceptable. > > (Mostly) independently, the syncer thread iterates over the list of the > dirty buffers and writes them. > > The "wdrain" wait is independend from the syncer model used. It is entered > by a thread which intends to write in some future, but the wait is performed > before the entry into VFS is performed, in particular, before any VFS > resources are acquired. The wait sleeps when the total amount of the > buffer space for which the writes are active (runningbufspace counter) > exceeds the hirunningbufspace threshold. This way buffer cache tries to > avoid creating too long queue of the write requests. > > If there is some device which has high latency with the write completion, > then it is easy to see that, for the load which creates intensive queue > of writes to the said device, regardless of amount of writes to other > devices, runningbufspace quickly gets populated with the buffers targeted > to the slow device. Then, the "wdrain" wait mechanism kicks in, slowing > all writers until the queue is processed. > > It could be argued that the current typical value of 16MB for the > hirunningbufspace is too low, but experiments with increasing it did > not provided any measureable change in the throughput or latency for > some loads. > Useful information. I might argue that 16MB is too big, not too small. If you've got a device that only does 2MB/sec write throughput, that's an 8 second backlog. Lest you think such slow devices aren't in everyday use, a couple years ago I struggled mightily to get an sd card driver on an embedded system UP to that speed (from 300K/sec). > And, just to wrestle with the misinformation, the unmapped buffer work > has nothing to do with either syncer or runningbufspace. > > > > > When using TCQ or NCQ, perhaps we should limit the number of outstanding > > writes per device to leave some slots open for reads. We should > > probably also prioritize reads over writes unless we are under memory > > pressure. > > Reads are allowed to start even when the runningbufspace is overflown. That seems to indicate that the problem isn't a failure of the runningbufspace regulation mechanism, because when this problem happens it's most noticible because reads take many seconds (often the read is an attempt to launch a tool to figure out why performance is bad). Hmm, on the other hand, I can't g'tee that I had 'noatime' on the mounts when I've seen this, so maybe I'd better not point any fingers at specific code until I have better information. I kind of like the suggestion someone else made of having a NOATIME kernel config option. I can't make a strong case for it, but it appeals to me. If it would allow signifcant pieces of kernel or filesystem code to be eliminated at compile time it would be worth it. If it complicated the code without such savings, probably not worth it. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 15:54:53 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A1042B32 for ; Mon, 4 Mar 2013 15:54:53 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 53F082AC for ; Mon, 4 Mar 2013 15:54:53 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCXj2-000Ejz-Gj; Mon, 04 Mar 2013 15:54:52 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r24Fsm5V091673; Mon, 4 Mar 2013 08:54:48 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX191feHa+Zz1f9duFDb4oX1u Subject: Re: access to hard drives is "blocked" by writes to a flash drive From: Ian Lepore To: Steven Hartland In-Reply-To: <7424F21A82384B67A5A5C7B3B791CDE5@multiplay.co.uk> References: <51323712.5000406@gmail.com> <20130303042043.GH286@server.rulingia.com> <1362317291.1195.216.camel@revolution.hippie.lan> <52867.1362317749@critter.freebsd.dk> <1362318887.1195.221.camel@revolution.hippie.lan> <7424F21A82384B67A5A5C7B3B791CDE5@multiplay.co.uk> Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Mar 2013 08:54:47 -0700 Message-ID: <1362412487.1195.257.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: deeptech71 , Poul-Henning Kamp , freebsd-current@FreeBSD.org, Peter Jeremy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Mar 2013 15:54:53 -0000 On Sun, 2013-03-03 at 20:28 +0000, Steven Hartland wrote: > ----- Original Message ----- > From: "Ian Lepore" > To: "Poul-Henning Kamp" > Cc: "deeptech71" ; ; "Peter Jeremy" > Sent: Sunday, March 03, 2013 1:54 PM > Subject: Re: access to hard drives is "blocked" by writes to a flash drive > > > > On Sun, 2013-03-03 at 13:35 +0000, Poul-Henning Kamp wrote: > >> Content-Type: text/plain; charset=ISO-8859-1 > >> -------- > >> In message <1362317291.1195.216.camel@revolution.hippie.lan>, Ian Lepore writes > >> : > >> > >> >I run into this behavior all the time too, mostly on arm systems that > >> >have an sd card or usb thumb driver as their main/only drive. > >> > >> This is really a FAQ and I belive I have answered it N times already: > >> > >> There are, broadly speaking, two classes of flash-storage: "Camera-grade" > >> and "the real thing". > >> > >> "Camera-grade" have a very limited "Flash adaptation layer" which typically > >> only can hold one flash-block open for writing at a time, and is typically > >> found in CF and SD cards, USB sticks etc. > >> > >> Some of them gets further upset if the filesystem is not the FAT they > >> expect, because they implement "M-Systems" (patented) trick with monitoring > >> block deletes in FAT to simulate a TRIM facility. > >> > >> A number of products exist with such designs, typically a CF-style, is > >> put behind a SATA-PATA bridge and sold as 2.5" SSD SATA devices. > >> "Transcend" have done this for instance. > >> > >> If you use this class of devices for anything real, gstat will show > >> you I/O write-times of several seconds in periodic pile-ups, even > >> 100 seconds if you are doing something heavy. > >> > >> For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > >> traffic to other disks too, when these pileups gets too bad. > > > > Hmmm, so the problem has been known and unfixed for 10 years. That's > > not encouraging. One of the messages in the lemming-syncer mail thread > > might explain why I've been seeing this a lot lately in hobbyist work, > > but not so much at $work where we use sd cards heavily... we use very > > short syncer timeouts on SD and CF storage at $work: > > > > kern.metadelay: 3 > > kern.dirdelay: 4 > > kern.filedelay: 5 > > > > I might play with similar settings on some of my arm boards here. > > Interesting, are these relevant for all filesystems e.g. ZFS? > > Regards > Steve I'm not sure, I know almost nothing about zfs. I do know we used those tunings for a specific reason and I sure wouldn't recommend them for general use. There's a comment block at the top of kern/vfs_subr.c with some information on those delay values and how they're used that you might find useful. I think in general such small numbers on a system doing lots of IO would be counter-productive. In our case we arrived at those tunings this way... We have embedded systems with CF and SD cards as their only mass storage, and we do a relatively small amount of writing to the cards (occasional config changes, low-volume routine logging via syslog, not much else). Occasionally when newsyslog kicks in there'll be a short burst of IO to compress and rotate, then back to a trickle again. Once upon a time we mounted the filesystem without softupdates and with the sync option. That was fairly robust against users pulling the plug right after making a config change, but very very slow during syslog rotation, sometimes to the point of peturbing our apps (the CF cards run in PIO mode, and a burst of PIO activity is hard on time-critical apps). So we switched using softupdates and turned off the sync option. That was nicer to our apps, but left a long window during which updates didn't get flushed to the card. So we lowered those 3 tuning values to the lowest numbers supported by the code (as I vaguely remember it, this was years ago), not to get any sort of change in performance, but to reduce the window during which data just sat around in memory waiting for potential further updates before being flushed. The further updates would never happen for us, so the long delays had no benefit. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 16:21:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 41595927; Mon, 4 Mar 2013 16:21:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 125E568A; Mon, 4 Mar 2013 16:21:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r24GL1jo022280; Mon, 4 Mar 2013 11:21:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r24GL1Dn022279; Mon, 4 Mar 2013 16:21:01 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Mar 2013 16:21:01 GMT Message-Id: <201303041621.r24GL1Dn022279@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:21:02 -0000 TB --- 2013-03-04 13:20:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 13:20:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-04 13:20:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-04 13:20:20 - cleaning the object tree TB --- 2013-03-04 13:20:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 13:20:24 - At svn revision 247790 TB --- 2013-03-04 13:20:25 - building world TB --- 2013-03-04 13:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 13:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 13:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 13:20:25 - SRCCONF=/dev/null TB --- 2013-03-04 13:20:25 - TARGET=i386 TB --- 2013-03-04 13:20:25 - TARGET_ARCH=i386 TB --- 2013-03-04 13:20:25 - TZ=UTC TB --- 2013-03-04 13:20:25 - __MAKE_CONF=/dev/null TB --- 2013-03-04 13:20:25 - cd /src TB --- 2013-03-04 13:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 13:20:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Mar 4 16:06:42 UTC 2013 TB --- 2013-03-04 16:06:42 - generating LINT kernel config TB --- 2013-03-04 16:06:42 - cd /src/sys/i386/conf TB --- 2013-03-04 16:06:42 - /usr/bin/make -B LINT TB --- 2013-03-04 16:06:42 - cd /src/sys/i386/conf TB --- 2013-03-04 16:06:42 - /usr/sbin/config -m LINT TB --- 2013-03-04 16:06:42 - building LINT kernel TB --- 2013-03-04 16:06:42 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 16:06:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 16:06:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 16:06:42 - SRCCONF=/dev/null TB --- 2013-03-04 16:06:42 - TARGET=i386 TB --- 2013-03-04 16:06:42 - TARGET_ARCH=i386 TB --- 2013-03-04 16:06:42 - TZ=UTC TB --- 2013-03-04 16:06:42 - __MAKE_CONF=/dev/null TB --- 2013-03-04 16:06:42 - cd /src TB --- 2013-03-04 16:06:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 16:06:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/kern/kern_timeout.c:659:2: error: use of undeclared identifier 'sbt1'; did you mean 'bt1'? sbt1 = sbinuptime(); ^~~~ bt1 /src/sys/kern/kern_timeout.c:604:13: note: 'bt1' declared here sbintime_t bt1, bt2; ^ 1 error generated. *** [kern_timeout.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 16:21:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 16:21:01 - ERROR: failed to build LINT kernel TB --- 2013-03-04 16:21:01 - 8699.79 user 1337.14 system 10840.34 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 16:53:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 11DEF6B4; Mon, 4 Mar 2013 16:53:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DE4647E7; Mon, 4 Mar 2013 16:53:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r24GrPJ3003690; Mon, 4 Mar 2013 11:53:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r24GrPmk003637; Mon, 4 Mar 2013 16:53:25 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Mar 2013 16:53:25 GMT Message-Id: <201303041653.r24GrPmk003637@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:53:26 -0000 TB --- 2013-03-04 13:20:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 13:20:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-04 13:20:20 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-03-04 13:20:20 - cleaning the object tree TB --- 2013-03-04 13:20:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 13:20:24 - At svn revision 247790 TB --- 2013-03-04 13:20:25 - building world TB --- 2013-03-04 13:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 13:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 13:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 13:20:25 - SRCCONF=/dev/null TB --- 2013-03-04 13:20:25 - TARGET=amd64 TB --- 2013-03-04 13:20:25 - TARGET_ARCH=amd64 TB --- 2013-03-04 13:20:25 - TZ=UTC TB --- 2013-03-04 13:20:25 - __MAKE_CONF=/dev/null TB --- 2013-03-04 13:20:25 - cd /src TB --- 2013-03-04 13:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 13:20:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Mar 4 16:40:28 UTC 2013 TB --- 2013-03-04 16:40:28 - generating LINT kernel config TB --- 2013-03-04 16:40:28 - cd /src/sys/amd64/conf TB --- 2013-03-04 16:40:28 - /usr/bin/make -B LINT TB --- 2013-03-04 16:40:28 - cd /src/sys/amd64/conf TB --- 2013-03-04 16:40:28 - /usr/sbin/config -m LINT TB --- 2013-03-04 16:40:29 - building LINT kernel TB --- 2013-03-04 16:40:29 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 16:40:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 16:40:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 16:40:29 - SRCCONF=/dev/null TB --- 2013-03-04 16:40:29 - TARGET=amd64 TB --- 2013-03-04 16:40:29 - TARGET_ARCH=amd64 TB --- 2013-03-04 16:40:29 - TZ=UTC TB --- 2013-03-04 16:40:29 - __MAKE_CONF=/dev/null TB --- 2013-03-04 16:40:29 - cd /src TB --- 2013-03-04 16:40:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 16:40:29 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/kern/kern_timeout.c:659:2: error: use of undeclared identifier 'sbt1'; did you mean 'bt1'? sbt1 = sbinuptime(); ^~~~ bt1 /src/sys/kern/kern_timeout.c:604:13: note: 'bt1' declared here sbintime_t bt1, bt2; ^ 1 error generated. *** [kern_timeout.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 16:53:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 16:53:25 - ERROR: failed to build LINT kernel TB --- 2013-03-04 16:53:25 - 10055.72 user 1720.80 system 12784.50 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 17:08:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E2CE9D54; Mon, 4 Mar 2013 17:08:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B2B5A8B7; Mon, 4 Mar 2013 17:08:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r24H8gcp096437; Mon, 4 Mar 2013 12:08:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r24H8gx2096432; Mon, 4 Mar 2013 17:08:42 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Mar 2013 17:08:42 GMT Message-Id: <201303041708.r24H8gx2096432@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:08:44 -0000 TB --- 2013-03-04 15:18:48 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 15:18:48 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-04 15:18:48 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-03-04 15:18:48 - cleaning the object tree TB --- 2013-03-04 15:18:48 - /usr/local/bin/svn stat /src TB --- 2013-03-04 15:18:53 - At svn revision 247790 TB --- 2013-03-04 15:18:54 - building world TB --- 2013-03-04 15:18:54 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 15:18:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 15:18:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 15:18:54 - SRCCONF=/dev/null TB --- 2013-03-04 15:18:54 - TARGET=ia64 TB --- 2013-03-04 15:18:54 - TARGET_ARCH=ia64 TB --- 2013-03-04 15:18:54 - TZ=UTC TB --- 2013-03-04 15:18:54 - __MAKE_CONF=/dev/null TB --- 2013-03-04 15:18:54 - cd /src TB --- 2013-03-04 15:18:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 15:18:58 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Mar 4 16:54:14 UTC 2013 TB --- 2013-03-04 16:54:14 - generating LINT kernel config TB --- 2013-03-04 16:54:14 - cd /src/sys/ia64/conf TB --- 2013-03-04 16:54:14 - /usr/bin/make -B LINT TB --- 2013-03-04 16:54:14 - cd /src/sys/ia64/conf TB --- 2013-03-04 16:54:14 - /usr/sbin/config -m LINT TB --- 2013-03-04 16:54:14 - building LINT kernel TB --- 2013-03-04 16:54:14 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 16:54:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 16:54:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 16:54:14 - SRCCONF=/dev/null TB --- 2013-03-04 16:54:14 - TARGET=ia64 TB --- 2013-03-04 16:54:14 - TARGET_ARCH=ia64 TB --- 2013-03-04 16:54:14 - TZ=UTC TB --- 2013-03-04 16:54:14 - __MAKE_CONF=/dev/null TB --- 2013-03-04 16:54:14 - cd /src TB --- 2013-03-04 16:54:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 16:54:14 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_thr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_thread.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_time.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_timeout.c /src/sys/kern/kern_timeout.c: In function 'softclock_call_cc': /src/sys/kern/kern_timeout.c:659: error: 'sbt1' undeclared (first use in this function) /src/sys/kern/kern_timeout.c:659: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_timeout.c:659: error: for each function it appears in.) *** [kern_timeout.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 17:08:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 17:08:42 - ERROR: failed to build LINT kernel TB --- 2013-03-04 17:08:42 - 5214.79 user 979.37 system 6594.21 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 17:27:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E892E400; Mon, 4 Mar 2013 17:27:03 +0000 (UTC) (envelope-from shonnur@chelsio.com) Received: from stargate.chelsio.com (stargate.chelsio.com [67.207.112.58]) by mx1.freebsd.org (Postfix) with ESMTP id AE873999; Mon, 4 Mar 2013 17:27:03 +0000 (UTC) Received: from maui.asicdesigners.com (maui.asicdesigners.com [10.192.180.15]) by stargate.chelsio.com (8.13.1/8.13.1) with SMTP id r24GlJwK023643; Mon, 4 Mar 2013 08:47:19 -0800 Received: from corona.asicdesigners.com ([10.192.160.6]) by maui.asicdesigners.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Mar 2013 08:47:18 -0800 Received: from NICE.asicdesigners.com (10.192.160.7) by corona.asicdesigners.com (10.192.160.6) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 4 Mar 2013 08:47:18 -0800 Received: from NICE.asicdesigners.com ([fe80::51b2:ba95:9d72:babc]) by nice.asicdesigners.com ([fe80::51b2:ba95:9d72:babc%15]) with mapi id 14.02.0247.003; Mon, 4 Mar 2013 08:47:18 -0800 From: Sreenivasa Honnur To: FreeBSD Tinderbox , "current@freebsd.org" , "i386@freebsd.org" Subject: cache sync on block device. Thread-Topic: cache sync on block device. Thread-Index: AQHOGPfuvltrNqjvQkecFV91fFvm4w== Date: Mon, 4 Mar 2013 16:47:18 +0000 Message-ID: References: <201303041621.r24GL1Dn022279@freebsd-current.sentex.ca> In-Reply-To: <201303041621.r24GL1Dn022279@freebsd-current.sentex.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.190.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Mar 2013 16:47:18.0725 (UTC) FILETIME=[EF120F50:01CE18F7] X-Mailman-Approved-At: Mon, 04 Mar 2013 17:30:06 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:27:04 -0000 Hi, I want to implementing cache sync functionality for a block device. I refe= rred to CTL code, below link says http://freebsd.1045724.n5.nabble.com/CAM-Target-Layer-and-dev-isp-td5727548= .html " If you use a block device (like a zvol) as the backing store, you'll want= =20 to disable sending cache syncs to the disk, since that will trigger a GEOM= =20 assertion.=20 ctladm realsync off" How is cache sync (flush) implemented for a block device ? bio_cmd=3DBIO_FL= USH results in ASSERT. Thanks Sreenivas From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 18:13:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ABA5E4DB; Mon, 4 Mar 2013 18:13:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 83454C1E; Mon, 4 Mar 2013 18:13:31 +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 r24IDUQ5051084; Mon, 4 Mar 2013 13:13:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r24IDUp7051074; Mon, 4 Mar 2013 18:13:30 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Mar 2013 18:13:30 GMT Message-Id: <201303041813.r24IDUp7051074@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 18:13:31 -0000 TB --- 2013-03-04 15:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 15:10:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-04 15:10:20 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-04 15:10:20 - cleaning the object tree TB --- 2013-03-04 15:10:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 15:10:23 - At svn revision 247790 TB --- 2013-03-04 15:10:24 - building world TB --- 2013-03-04 15:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 15:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 15:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 15:10:24 - SRCCONF=/dev/null TB --- 2013-03-04 15:10:24 - TARGET=pc98 TB --- 2013-03-04 15:10:24 - TARGET_ARCH=i386 TB --- 2013-03-04 15:10:24 - TZ=UTC TB --- 2013-03-04 15:10:24 - __MAKE_CONF=/dev/null TB --- 2013-03-04 15:10:24 - cd /src TB --- 2013-03-04 15:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 15:10:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Mar 4 18:02:26 UTC 2013 TB --- 2013-03-04 18:02:26 - generating LINT kernel config TB --- 2013-03-04 18:02:26 - cd /src/sys/pc98/conf TB --- 2013-03-04 18:02:26 - /usr/bin/make -B LINT TB --- 2013-03-04 18:02:26 - cd /src/sys/pc98/conf TB --- 2013-03-04 18:02:26 - /usr/sbin/config -m LINT TB --- 2013-03-04 18:02:26 - building LINT kernel TB --- 2013-03-04 18:02:26 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 18:02:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 18:02:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 18:02:26 - SRCCONF=/dev/null TB --- 2013-03-04 18:02:26 - TARGET=pc98 TB --- 2013-03-04 18:02:26 - TARGET_ARCH=i386 TB --- 2013-03-04 18:02:26 - TZ=UTC TB --- 2013-03-04 18:02:26 - __MAKE_CONF=/dev/null TB --- 2013-03-04 18:02:26 - cd /src TB --- 2013-03-04 18:02:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 18:02:26 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/kern/kern_timeout.c:659:2: error: use of undeclared identifier 'sbt1'; did you mean 'bt1'? sbt1 = sbinuptime(); ^~~~ bt1 /src/sys/kern/kern_timeout.c:604:13: note: 'bt1' declared here sbintime_t bt1, bt2; ^ 1 error generated. *** [kern_timeout.o] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 18:13:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 18:13:30 - ERROR: failed to build LINT kernel TB --- 2013-03-04 18:13:30 - 8860.64 user 1343.64 system 10990.31 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 19:38:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A7290EF7; Mon, 4 Mar 2013 19:38:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 67D31FF7; Mon, 4 Mar 2013 19:38:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r24Jcbx9008157; Mon, 4 Mar 2013 14:38:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r24Jcbsr008153; Mon, 4 Mar 2013 19:38:37 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Mar 2013 19:38:37 GMT Message-Id: <201303041938.r24Jcbsr008153@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 19:38:38 -0000 TB --- 2013-03-04 18:26:28 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 18:26:28 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-04 18:26:28 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-03-04 18:26:28 - cleaning the object tree TB --- 2013-03-04 18:26:28 - /usr/local/bin/svn stat /src TB --- 2013-03-04 18:26:31 - At svn revision 247790 TB --- 2013-03-04 18:26:32 - building world TB --- 2013-03-04 18:26:32 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 18:26:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 18:26:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 18:26:32 - SRCCONF=/dev/null TB --- 2013-03-04 18:26:32 - TARGET=sparc64 TB --- 2013-03-04 18:26:32 - TARGET_ARCH=sparc64 TB --- 2013-03-04 18:26:32 - TZ=UTC TB --- 2013-03-04 18:26:32 - __MAKE_CONF=/dev/null TB --- 2013-03-04 18:26:32 - cd /src TB --- 2013-03-04 18:26:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 18:26:37 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Mar 4 19:29:02 UTC 2013 TB --- 2013-03-04 19:29:02 - generating LINT kernel config TB --- 2013-03-04 19:29:02 - cd /src/sys/sparc64/conf TB --- 2013-03-04 19:29:02 - /usr/bin/make -B LINT TB --- 2013-03-04 19:29:03 - cd /src/sys/sparc64/conf TB --- 2013-03-04 19:29:03 - /usr/sbin/config -m LINT TB --- 2013-03-04 19:29:03 - building LINT kernel TB --- 2013-03-04 19:29:03 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 19:29:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 19:29:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 19:29:03 - SRCCONF=/dev/null TB --- 2013-03-04 19:29:03 - TARGET=sparc64 TB --- 2013-03-04 19:29:03 - TARGET_ARCH=sparc64 TB --- 2013-03-04 19:29:03 - TZ=UTC TB --- 2013-03-04 19:29:03 - __MAKE_CONF=/dev/null TB --- 2013-03-04 19:29:03 - cd /src TB --- 2013-03-04 19:29:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 19:29:03 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_thr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_thread.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_time.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_timeout.c /src/sys/kern/kern_timeout.c: In function 'softclock_call_cc': /src/sys/kern/kern_timeout.c:659: error: 'sbt1' undeclared (first use in this function) /src/sys/kern/kern_timeout.c:659: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_timeout.c:659: error: for each function it appears in.) *** [kern_timeout.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 19:38:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 19:38:37 - ERROR: failed to build LINT kernel TB --- 2013-03-04 19:38:37 - 3602.23 user 597.96 system 4329.06 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 19:38:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1CF6B79; Mon, 4 Mar 2013 19:38:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E880DFF8; Mon, 4 Mar 2013 19:38:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r24Jcndh008332; Mon, 4 Mar 2013 14:38:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r24Jcn4m008331; Mon, 4 Mar 2013 19:38:49 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Mar 2013 19:38:49 GMT Message-Id: <201303041938.r24Jcn4m008331@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 19:38:50 -0000 TB --- 2013-03-04 17:08:43 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 17:08:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-04 17:08:43 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-03-04 17:08:43 - cleaning the object tree TB --- 2013-03-04 17:08:43 - /usr/local/bin/svn stat /src TB --- 2013-03-04 17:08:46 - At svn revision 247790 TB --- 2013-03-04 17:08:47 - building world TB --- 2013-03-04 17:08:47 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 17:08:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 17:08:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 17:08:47 - SRCCONF=/dev/null TB --- 2013-03-04 17:08:47 - TARGET=powerpc TB --- 2013-03-04 17:08:47 - TARGET_ARCH=powerpc TB --- 2013-03-04 17:08:47 - TZ=UTC TB --- 2013-03-04 17:08:47 - __MAKE_CONF=/dev/null TB --- 2013-03-04 17:08:47 - cd /src TB --- 2013-03-04 17:08:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 17:08:51 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Mar 4 19:31:35 UTC 2013 TB --- 2013-03-04 19:31:35 - generating LINT kernel config TB --- 2013-03-04 19:31:35 - cd /src/sys/powerpc/conf TB --- 2013-03-04 19:31:35 - /usr/bin/make -B LINT TB --- 2013-03-04 19:31:35 - cd /src/sys/powerpc/conf TB --- 2013-03-04 19:31:35 - /usr/sbin/config -m LINT TB --- 2013-03-04 19:31:36 - building LINT kernel TB --- 2013-03-04 19:31:36 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 19:31:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 19:31:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 19:31:36 - SRCCONF=/dev/null TB --- 2013-03-04 19:31:36 - TARGET=powerpc TB --- 2013-03-04 19:31:36 - TARGET_ARCH=powerpc TB --- 2013-03-04 19:31:36 - TZ=UTC TB --- 2013-03-04 19:31:36 - __MAKE_CONF=/dev/null TB --- 2013-03-04 19:31:36 - cd /src TB --- 2013-03-04 19:31:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 19:31:36 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_thr.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_thread.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_time.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_timeout.c /src/sys/kern/kern_timeout.c: In function 'softclock_call_cc': /src/sys/kern/kern_timeout.c:659: error: 'sbt1' undeclared (first use in this function) /src/sys/kern/kern_timeout.c:659: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_timeout.c:659: error: for each function it appears in.) *** [kern_timeout.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 19:38:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 19:38:49 - ERROR: failed to build LINT kernel TB --- 2013-03-04 19:38:49 - 7682.42 user 1018.77 system 9006.30 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 20:00:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E5B1F7FA; Mon, 4 Mar 2013 20:00:51 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id AF8F9110F; Mon, 4 Mar 2013 20:00:51 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 04 Mar 2013 12:02:14 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id r24Jxg6a076231; Mon, 4 Mar 2013 11:59:42 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id r24Jxg3a076229; Mon, 4 Mar 2013 11:59:42 -0800 (PST) (envelope-from ambrisko) Date: Mon, 4 Mar 2013 11:59:42 -0800 From: Doug Ambrisko To: "Eggert, Lars" Subject: Re: serial console not accepting input? Message-ID: <20130304195942.GA56928@ambrisko.com> References: <51000A18.1020001@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-current@freebsd.org" , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 04 Mar 2013 20:00:52 -0000 On Thu, Jan 24, 2013 at 01:23:50PM +0000, Eggert, Lars wrote: | Hi, | | On Jan 23, 2013, at 17:04, Dimitry Andric wrote: | > CTS/RTS hardware flow control, maybe? E.g. add ":hw" to the default | > settings in /etc/gettytab, or make a specific entry with an added ":hw" | > setting. | | nope, I don't even get a login prompt if I do that. | | > If it is a physical serial console, you could also simply have a bad | > cable. Try swapping it with working system. :) | | Spent the last few hours fiddling with the cabling and the various BIOS | serial redirection options (it's a Dell 2950). My best guess is that | the serial port on the box is physically broken. Try to do a {Ctrl}D to see if works. We've seen that the TX on reset hangs but input works fine. I'm not sure if we ran into this with uart(4) but had a problem with sio(4). Doug A. From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 21:55:27 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE03EDC8 for ; Mon, 4 Mar 2013 21:55:27 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by mx1.freebsd.org (Postfix) with ESMTP id 791BD1789 for ; Mon, 4 Mar 2013 21:55:27 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id j1so9851044oag.21 for ; Mon, 04 Mar 2013 13:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/kfpx5oomg5t5OMQBFBydR6s7cqlA9czhIAY6m9BYnQ=; b=DpaPKUVh2FMxunVUKqmOD02EGAEVlAFitPhp58jtR5Jp+Mq8lZFz6/ivsMYQAl+Ai8 Gmai39iTYfdIRAWJnM6seeGtK11qoWYDkWeMC8KLpDC53vMHzwo442iLCXBP8ETHu6Of lrZIq3ZuWSfHzbfzMlIXs9FIvvFa5fj5sRv98= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/kfpx5oomg5t5OMQBFBydR6s7cqlA9czhIAY6m9BYnQ=; b=VC+N0ffyC8QaBRyQdEYjlaTPZb5fvB8wFkVLm2Aj47J80BrIq+LvTQaHed56MxGpyq C7SVV3KIC50qAl3DX6Bz2aD37qEwP7iIkyOMxr+TfOyYUCxDMzsN7ovjdyDr7cF2XJpc BX/EAAqtbyMITJk3HUfp3RFqJIML0Z4x/5qxW6+vvl7xxNEaNZH0EktyfMh7zWIUIgcH jR+/KuWGhjnLhE7HXWrHR+sPcTZma5WCd8htw6DrUvBKvVpoHuywb+XvdFH30FueDWw+ Yee556p5uC1Et0jfOqXgo642NSQEhiHe1K8wk594IOM5oSisXt89WfDi4dEpzYILyi4s z8lQ== MIME-Version: 1.0 X-Received: by 10.60.12.170 with SMTP id z10mr17444058oeb.122.1362434120579; Mon, 04 Mar 2013 13:55:20 -0800 (PST) Received: by 10.76.99.113 with HTTP; Mon, 4 Mar 2013 13:55:20 -0800 (PST) X-Originating-IP: [2.138.23.213] Received: by 10.76.99.113 with HTTP; Mon, 4 Mar 2013 13:55:20 -0800 (PST) In-Reply-To: <20130302165239.GB27078@ithaqua.etoilebsd.net> References: <20130302165239.GB27078@ithaqua.etoilebsd.net> Date: Mon, 4 Mar 2013 21:55:20 +0000 Message-ID: Subject: Re: Import libyaml into base From: "Simon L. B. Nielsen" To: Baptiste Daroussin X-Gm-Message-State: ALoCoQnPBt8265ztZzCuMVjOabPmwdxvogBImO6WcjcPJ/nEOsToHr2C8AhRh+HLOECxPYno1KBT Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: arch@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 21:55:27 -0000 On 2 Mar 2013 16:52, "Baptiste Daroussin" wrote: > I want to import libyaml into base as libbsdyml so that no ports will use it > like we do for expat. > > I need it for the pkg bootstrap, so it it can parse pkg.conf. > > I know that some of the bhyve people will also be glad to use it. > > libyaml is MIT licensed, it is stable: no abi/api revolution in it for a while. > > Does anyone have an objection? I don't but please add a stub manual page telling people not to use it outside base. Simon From owner-freebsd-current@FreeBSD.ORG Mon Mar 4 22:03:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C46DDFDE; Mon, 4 Mar 2013 22:03:49 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 3C10717D9; Mon, 4 Mar 2013 22:03:49 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a12so983338eaa.13 for ; Mon, 04 Mar 2013 14:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=/tdOunfV3I71bBqtEY1WuzYyif73mZjcrE0FmqUIZ4s=; b=zX4MHB4HZwOEzXMmU4ecIxCzgn7yump3dU0LYsdDCn6mPQsmmoiIX5Dy4y2z/rRz46 WMhGc6zDSqGfeZ0STeAjfD7KksQSUSioZFLGtENBhH8g7GtEel8XY3ixOQ49opMRiJ+3 i+w+httmi0t44P9uJj7MtU2F1/R9TUgPPAj4fX0QbboMcaJF7EDzphhgAeCA+Nw8/oEY Po/g6Djs1z7M1rtHBNO1U+2PG2yMSFbcwzlfG5RafRj0xIt4sW0q9/Pdy8qZuPbRiiza 9yyg7KX8sF0v6hQS3IwPboQld3kaJzu2y6nFst1vTERCVMQ/o8qn019cTDStnX6c4Wpq dM9Q== X-Received: by 10.14.193.134 with SMTP id k6mr63533221een.37.1362434628216; Mon, 04 Mar 2013 14:03:48 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id 3sm34185380eej.6.2013.03.04.14.03.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Mar 2013 14:03:46 -0800 (PST) Sender: Baptiste Daroussin Date: Mon, 4 Mar 2013 23:03:44 +0100 From: Baptiste Daroussin To: "Simon L. B. Nielsen" Subject: Re: Import libyaml into base Message-ID: <20130304220344.GN64570@ithaqua.etoilebsd.net> References: <20130302165239.GB27078@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FX+Db2fp7WJhXKrW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:03:49 -0000 --FX+Db2fp7WJhXKrW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 04, 2013 at 09:55:20PM +0000, Simon L. B. Nielsen wrote: > On 2 Mar 2013 16:52, "Baptiste Daroussin" wrote: > > I want to import libyaml into base as libbsdyml so that no ports will u= se > it > > like we do for expat. > > > > I need it for the pkg bootstrap, so it it can parse pkg.conf. > > > > I know that some of the bhyve people will also be glad to use it. > > > > libyaml is MIT licensed, it is stable: no abi/api revolution in it for a > while. > > > > Does anyone have an objection? >=20 > I don't but please add a stub manual page telling people not to use it > outside base. >=20 > Simon Sure I was planning to losely do the same as for libexpat. The only user ou= tside base will be pkgng, but it is a bit special ;) regards, Bapt --FX+Db2fp7WJhXKrW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlE1GkAACgkQ8kTtMUmk6EwXlACgvDODc6SxB9YUzFGshiqOO+Bl 8OcAn0r2HCKPUWkNj/xrbz7YyHfPcqPL =eGQp -----END PGP SIGNATURE----- --FX+Db2fp7WJhXKrW-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 05:09:49 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 20B392DF for ; Tue, 5 Mar 2013 05:09:49 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 04FC6FB9 for ; Tue, 5 Mar 2013 05:09:48 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r2559YCs012409; Mon, 4 Mar 2013 21:09:39 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303050509.r2559YCs012409@gw.catspoiler.org> Date: Mon, 4 Mar 2013 21:09:34 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: peter@rulingia.com In-Reply-To: <20130304083802.GA44865@server.rulingia.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 05:09:49 -0000 On 4 Mar, Peter Jeremy wrote: > On 2013-Mar-03 23:12:40 -0800, Don Lewis wrote: >>On 4 Mar, Konstantin Belousov wrote: >>> It could be argued that the current typical value of 16MB for the >>> hirunningbufspace is too low, but experiments with increasing it did >>> not provided any measureable change in the throughput or latency for >>> some loads. >> >>The correct value is probably proportional to the write bandwidth >>available. > > The problem is that write bandwidth varies widely depending on the > workload. For spinning rust, this will vary between maybe 64KBps > (512B random writes) and 100-150MBps (single-theaded large sequential > writes). The (low-end) SSD in my Netbook also has about 100:1 variance > due to erase blocking. How do you tune hirunningbufspace in the face > of 2 or 3 orders of magnitude variance in throughput? Especially since > SSDs don't gradually degrade - they hit a brick wall. I think a latency target would be desirable. As a first cut, maybe a limit on the number of write ops per device instead of a limit on the amount of data. That should more or less do the correct thing for small random I/O vs. large sequential writes. It could be somewhat self tuning if we kept track of the average service time, which should probably be measured with write caching off. There might still need to be a higher size limit to avoid excessive memory consumption. If you only have a single drive and it is an SSD, then there's probably not much you can do about the erase blocking problem. About the best you could do is if it supports NCQ is to turn off write caching so that you can keep track of how many writes are outstanding so that you can limit the write load to something less than the maximum number of outstanding commands that it supports, and then hope that when you run into the erase blocking situation, that *maybe* it will still process reads. If you have multiple drives, then you don't want one backlogged drive to block writes to your other drive(s), which would require something other than a global hirunningbufspace limit. From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 05:19:53 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D0824564; Tue, 5 Mar 2013 05:19:53 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id B0BB8A4; Tue, 5 Mar 2013 05:19:50 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r255JbAu012422; Mon, 4 Mar 2013 21:19:40 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303050519.r255JbAu012422@gw.catspoiler.org> Date: Mon, 4 Mar 2013 21:19:37 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: phk@phk.freebsd.dk In-Reply-To: <25327.1362404670@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: kostikbel@gmail.com, deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 05:19:53 -0000 On 4 Mar, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > -------- > In message <201303040712.r247CejP008718@gw.catspoiler.org>, Don Lewis writes: > >>Prior to 231160, the syncer thread would call sync_vnode() for the >>syncer vnode of each mountpoint every 30 seconds [...] > > I agree that the lemming syncer is better, but the fundamental mistake of > only having one syncer thread is probably the root-cause in this case: > One camera-grade flash syncing may take (a lot) more than 30 seconds. That's been my opinion for a long time as well, though I think it would be better to have one thread per device to avoid syncer threads for multiple partitions on the same drive all contending for the same actuator. One complication is that the notion of a device gets pretty hazy given that we have the geom layer in between the syncer and the hardware. I'd still have a separate worklist for each mountpoint. Multiple threads would allow us to better exploit the parallelism provided by the hardware and prevent a slow drive from impacting the performance of the other drives in the system. > One mountpoint having trouble (of whatever kind) should not affect > the rest of the mountpoints. > > I'm not sure if the syncer is untangled enough that we can have > per mount-point threads yet, but as soon as we can, we should do that. I'm not aware of any fundamental issues preventing this from being implemented, though I haven't spent much time looking at recent versions of the code. From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 05:27:14 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5A06C6D6; Tue, 5 Mar 2013 05:27:14 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 273EFD7; Tue, 5 Mar 2013 05:27:13 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r255R0Gd012437; Mon, 4 Mar 2013 21:27:04 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303050527.r255R0Gd012437@gw.catspoiler.org> Date: Mon, 4 Mar 2013 21:27:00 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: ian@FreeBSD.org In-Reply-To: <1362410177.1195.234.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 05:27:14 -0000 On 4 Mar, Ian Lepore wrote: > On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote: >> On 3 Mar, Poul-Henning Kamp wrote: >> >> > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O >> > traffic to other disks too, when these pileups gets too bad. >> >> The Lemming-syncer problem should have mostly been fixed by 231160 in >> head (231952 in stable/9 and 231967 in stable/8) a little over a year >> ago. The exceptions are atime updates, mmaped files with dirty pages, >> and quotas. Under certain workloads I still notice periodic bursts of >> seek noise. After thinking about it for a bit, I suspect that it could >> be atime updates, but I haven't tried to confirm that. >> >> When using TCQ or NCQ, perhaps we should limit the number of outstanding >> writes per device to leave some slots open for reads. We should >> probably also prioritize reads over writes unless we are under memory >> pressure. >> > > Then either those changes didn't have the intended effect, or the > problem we're seeing with lack of system responsiveness when there's a > large backlog of writes to a slow device is not the lemming-syncer > problem. It's also not a lack of TCQ/NCQ slots, given that no such > thing exists with SD card IO. > > When this is going on, the process driving the massive output spends > almost all its time in a wdrain wait, and if you try to launch an app > that isn't already in cache, a siginfo generally shows it to be in a > getblk wait. If your only drive is a single SD card, then you're pretty much hosed when I/O is blocked because the SD card is doing an erase. It can only handle one command at a time, and if a write blocks, there's nothing that we can do to get it to execute a read until it is done with the write command that it is hung up on. I'm not familiar with the lower layers, but things might be less bad if read ops can jump ahead and get sent to the drive before any queued writes. From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 05:33:37 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E6602926; Tue, 5 Mar 2013 05:33:37 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id C43D311C; Tue, 5 Mar 2013 05:33:37 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r255XQbA012452; Mon, 4 Mar 2013 21:33:30 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303050533.r255XQbA012452@gw.catspoiler.org> Date: Mon, 4 Mar 2013 21:33:26 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: ian@FreeBSD.org In-Reply-To: <1362412487.1195.257.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, killing@multiplay.co.uk, peter@rulingia.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 05:33:38 -0000 On 4 Mar, Ian Lepore wrote: > On Sun, 2013-03-03 at 20:28 +0000, Steven Hartland wrote: >> ----- Original Message ----- >> From: "Ian Lepore" >> To: "Poul-Henning Kamp" >> Cc: "deeptech71" ; ; "Peter Jeremy" >> Sent: Sunday, March 03, 2013 1:54 PM >> Subject: Re: access to hard drives is "blocked" by writes to a flash drive >> >> >> > On Sun, 2013-03-03 at 13:35 +0000, Poul-Henning Kamp wrote: >> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> -------- >> >> In message <1362317291.1195.216.camel@revolution.hippie.lan>, Ian Lepore writes >> >> : >> >> >> >> >I run into this behavior all the time too, mostly on arm systems that >> >> >have an sd card or usb thumb driver as their main/only drive. >> >> >> >> This is really a FAQ and I belive I have answered it N times already: >> >> >> >> There are, broadly speaking, two classes of flash-storage: "Camera-grade" >> >> and "the real thing". >> >> >> >> "Camera-grade" have a very limited "Flash adaptation layer" which typically >> >> only can hold one flash-block open for writing at a time, and is typically >> >> found in CF and SD cards, USB sticks etc. >> >> >> >> Some of them gets further upset if the filesystem is not the FAT they >> >> expect, because they implement "M-Systems" (patented) trick with monitoring >> >> block deletes in FAT to simulate a TRIM facility. >> >> >> >> A number of products exist with such designs, typically a CF-style, is >> >> put behind a SATA-PATA bridge and sold as 2.5" SSD SATA devices. >> >> "Transcend" have done this for instance. >> >> >> >> If you use this class of devices for anything real, gstat will show >> >> you I/O write-times of several seconds in periodic pile-ups, even >> >> 100 seconds if you are doing something heavy. >> >> >> >> For various reasons (see: Lemming-syncer) FreeBSD will block all I/O >> >> traffic to other disks too, when these pileups gets too bad. >> > >> > Hmmm, so the problem has been known and unfixed for 10 years. That's >> > not encouraging. One of the messages in the lemming-syncer mail thread >> > might explain why I've been seeing this a lot lately in hobbyist work, >> > but not so much at $work where we use sd cards heavily... we use very >> > short syncer timeouts on SD and CF storage at $work: >> > >> > kern.metadelay: 3 >> > kern.dirdelay: 4 >> > kern.filedelay: 5 >> > >> > I might play with similar settings on some of my arm boards here. >> >> Interesting, are these relevant for all filesystems e.g. ZFS? >> >> Regards >> Steve > > I'm not sure, I know almost nothing about zfs. I do know we used those > tunings for a specific reason and I sure wouldn't recommend them for > general use. There's a comment block at the top of kern/vfs_subr.c with > some information on those delay values and how they're used that you > might find useful. I think in general such small numbers on a system > doing lots of IO would be counter-productive. > > In our case we arrived at those tunings this way... We have embedded > systems with CF and SD cards as their only mass storage, and we do a > relatively small amount of writing to the cards (occasional config > changes, low-volume routine logging via syslog, not much else). > Occasionally when newsyslog kicks in there'll be a short burst of IO to > compress and rotate, then back to a trickle again. Once upon a time we > mounted the filesystem without softupdates and with the sync option. > That was fairly robust against users pulling the plug right after making > a config change, but very very slow during syslog rotation, sometimes to > the point of peturbing our apps (the CF cards run in PIO mode, and a > burst of PIO activity is hard on time-critical apps). > > So we switched using softupdates and turned off the sync option. That > was nicer to our apps, but left a long window during which updates > didn't get flushed to the card. So we lowered those 3 tuning values to > the lowest numbers supported by the code (as I vaguely remember it, this > was years ago), not to get any sort of change in performance, but to > reduce the window during which data just sat around in memory waiting > for potential further updates before being flushed. The further updates > would never happen for us, so the long delays had no benefit. This tuning could potentially increase the amount of I/O that actually occurs. The only advantage would be that large files that are sequentially written would be flushed to disk more frequently but in smaller amounts. To avoid the potential problem of lost config changes, could you put a wrapper around the editor to fsync the config file? From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 05:49:29 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D4745C1E; Tue, 5 Mar 2013 05:49:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by mx1.freebsd.org (Postfix) with ESMTP id 9DECE1A6; Tue, 5 Mar 2013 05:49:29 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id uo15so3931369pbc.33 for ; Mon, 04 Mar 2013 21:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=kzwtesqnmslR4dziGHkDwWv/ljejBKcP2E7ViIfyra4=; b=fWMcvdm/gAEkALmXnm0IZ41DJg2mt/3uYS7FjO+dudjEWJVthTU3D/W+LNvNnak5vh rc3MrN1oiGASS5nuPxCYsmPTEbPuTxMHqQizcgdhHyjDuW2x7+fI6iHx70Vcv5IwQg/b UUCu0I/57kdLYVyCfbnLEtjz6jnSK4KlMR8WdYLiyFziuswglBHFIWPVCRRoyGE2pXh/ NlD+RMjH6a2VsXvell7mbTM+JmVwaGgnejsb2Hrfi7CRfUacHd8t6T7Bf5HzALhbUQWX kLghnreiMnuxV+njwi416uhT7t7rI1Hr2YvNOVE86441VEgyjN2F/cdOGNuJoEjXHJBl WJeQ== X-Received: by 10.68.212.197 with SMTP id nm5mr33763842pbc.179.1362462568513; Mon, 04 Mar 2013 21:49:28 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id zm1sm25152382pbc.26.2013.03.04.21.49.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Mar 2013 21:49:27 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 05 Mar 2013 14:49:20 +0900 From: YongHyeon PYUN Date: Tue, 5 Mar 2013 14:49:20 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130305054920.GD1472@michelle.cdnetworks.com> References: <20130304005044.GA4589@michelle.cdnetworks.com> <20130304015344.GA62059@FreeBSD.org> <20130304021059.GC4589@michelle.cdnetworks.com> <20130304024631.GA78040@FreeBSD.org> <20130304052328.GA1445@michelle.cdnetworks.com> <20130304055948.GA76042@FreeBSD.org> <20130304062944.GB1445@michelle.cdnetworks.com> <20130304065940.GA13417@FreeBSD.org> <20130304070632.GC1445@michelle.cdnetworks.com> <20130304081858.GA23857@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130304081858.GA23857@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 05:49:29 -0000 On Mon, Mar 04, 2013 at 08:18:58AM +0000, Alexey Dokuchaev wrote: > On Mon, Mar 04, 2013 at 04:06:32PM +0900, YongHyeon PYUN wrote: > > On Mon, Mar 04, 2013 at 06:59:40AM +0000, Alexey Dokuchaev wrote: > > > Better this time, I'm having 1000baseT again! :-) > > > > Thanks a lot for testing and patience! > > Could you reboot multiple times and check whether you reliably get > > a gigabit link? > > Yes, multiple reboots was a good idea, it's not very stable: > > 1st reboot: 100baseTX (!) > 2nd reboot: 1000baseT > 3rd reboot: 1000baseT > 4th reboot: 1000baseT > 5th reboot: 100baseTX (!) > 6th reboot: 100baseTX (!) > 7th reboot: 1000baseT > 8th reboot: 100baseTX (!) > 9th reboot: 1000baseT > 10th reboot: 1000baseT > > I've tried various combinations of just reboot, shutdown -r +1m and pinging > some host while waiting for reboot. Could you disable WOL before rebooting your box? You can disable WOL like the following. #ifconfig ale0 -wol > > ./danfe From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 06:38:58 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DD1C736F; Tue, 5 Mar 2013 06:38:58 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF45306; Tue, 5 Mar 2013 06:38:58 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 23F6389EAF; Tue, 5 Mar 2013 06:38:57 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r256ct1Y028306; Tue, 5 Mar 2013 06:38:55 GMT (envelope-from phk@phk.freebsd.dk) To: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive In-reply-to: <201303050519.r255JbAu012422@gw.catspoiler.org> From: "Poul-Henning Kamp" References: <201303050519.r255JbAu012422@gw.catspoiler.org> Date: Tue, 05 Mar 2013 06:38:55 +0000 Message-ID: <28305.1362465535@critter.freebsd.dk> Cc: kostikbel@gmail.com, deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 06:38:58 -0000 Content-Type: text/plain; charset=ISO-8859-1 -------- In message <201303050519.r255JbAu012422@gw.catspoiler.org>, Don Lewis writes: >That's been my opinion for a long time as well, though I think it would >be better to have one thread per device to avoid syncer threads for >multiple partitions on the same drive all contending for the same >actuator. That would require that you move the syncer to the bottom of GEOM and initiate syncs by upcalls to the consumers above. But how does that work in the case of a mirrored drive ? Doesn't sound like a good idea to me. >Multiple threads would allow us to better exploit the parallelism >provided by the hardware and prevent a slow drive from impacting the >performance of the other drives in the system. It would also allow us to have different sync-intervals for different filesystems. >> I'm not sure if the syncer is untangled enough that we can have >> per mount-point threads yet, but as soon as we can, we should do that. > >I'm not aware of any fundamental issues preventing this from being >implemented, though I haven't spent much time looking at recent versions >of the code. It used to be impossible because of all the implicit locking based on pseudo-vnodes and whats-not... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 06:59:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 9EE87CF7; Tue, 5 Mar 2013 06:59:10 +0000 (UTC) Date: Tue, 5 Mar 2013 06:59:10 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130305065910.GA97021@FreeBSD.org> References: <20130304015344.GA62059@FreeBSD.org> <20130304021059.GC4589@michelle.cdnetworks.com> <20130304024631.GA78040@FreeBSD.org> <20130304052328.GA1445@michelle.cdnetworks.com> <20130304055948.GA76042@FreeBSD.org> <20130304062944.GB1445@michelle.cdnetworks.com> <20130304065940.GA13417@FreeBSD.org> <20130304070632.GC1445@michelle.cdnetworks.com> <20130304081858.GA23857@FreeBSD.org> <20130305054920.GD1472@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130305054920.GD1472@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 06:59:10 -0000 On Tue, Mar 05, 2013 at 02:49:20PM +0900, YongHyeon PYUN wrote: > On Mon, Mar 04, 2013 at 08:18:58AM +0000, Alexey Dokuchaev wrote: > > Yes, multiple reboots was a good idea, it's not very stable: [...] > > > > I've tried various combinations of just reboot, shutdown -r +1m and > > pinging some host while waiting for reboot. > > Could you disable WOL before rebooting your box? # ifconfig ale0 -wol # reboot It came up as 100baseTX. :( ./danfe From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 07:43:23 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B3571944; Tue, 5 Mar 2013 07:43:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by mx1.freebsd.org (Postfix) with ESMTP id 61761743; Tue, 5 Mar 2013 07:43:23 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id un15so4041098pbc.24 for ; Mon, 04 Mar 2013 23:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=65e7dzvxU6DGtzx2T4whfOf5cGGuaWwAm20mfd5RENQ=; b=b9ZJDLlfD7JiBGzeZslABDpc1WdYn4se18JlquUINsSSZzNplmwv4ix4Y1AqVRuChF 5IH4NHigY4EfG25XDVBHEjWMVovwcWIPI+KU9bZfrD6s775xmB73C/DoJK0GN09y9Fuy MiJXWfCyJSJdOI5RvTLXtPnCJdzdHcd1U0SZeEcCo2uOt5T88ypBAhkE3E8dkgVd8pNa KzOQlGgwEXkhduQ8lMxlqD9CGel5JCrMTVSz0uS4j4s8ztz5I14g1MKCDoNVN8AQsqfS eGgNuAoDPu6b/iIQWVzjQ17nqjpGWEbJ0yYulS+n/3SGKpj9R079tnJUH1eLAxNUPKAJ 1qGg== X-Received: by 10.68.143.167 with SMTP id sf7mr34860262pbb.21.1362469402538; Mon, 04 Mar 2013 23:43:22 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id rd1sm25530614pbc.19.2013.03.04.23.43.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Mar 2013 23:43:21 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 05 Mar 2013 16:43:15 +0900 From: YongHyeon PYUN Date: Tue, 5 Mar 2013 16:43:15 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130305074315.GE1472@michelle.cdnetworks.com> References: <20130304021059.GC4589@michelle.cdnetworks.com> <20130304024631.GA78040@FreeBSD.org> <20130304052328.GA1445@michelle.cdnetworks.com> <20130304055948.GA76042@FreeBSD.org> <20130304062944.GB1445@michelle.cdnetworks.com> <20130304065940.GA13417@FreeBSD.org> <20130304070632.GC1445@michelle.cdnetworks.com> <20130304081858.GA23857@FreeBSD.org> <20130305054920.GD1472@michelle.cdnetworks.com> <20130305065910.GA97021@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305065910.GA97021@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 07:43:23 -0000 On Tue, Mar 05, 2013 at 06:59:10AM +0000, Alexey Dokuchaev wrote: > On Tue, Mar 05, 2013 at 02:49:20PM +0900, YongHyeon PYUN wrote: > > On Mon, Mar 04, 2013 at 08:18:58AM +0000, Alexey Dokuchaev wrote: > > > Yes, multiple reboots was a good idea, it's not very stable: [...] > > > > > > I've tried various combinations of just reboot, shutdown -r +1m and > > > pinging some host while waiting for reboot. > > > > Could you disable WOL before rebooting your box? > > # ifconfig ale0 -wol > # reboot > > It came up as 100baseTX. :( You don't use any manual link configuration, right? When you see the controller established a 100Mbps link, how about restarting auto-negotiation? Does that also result in 100Mbps link? #ifconfig ale0 media auto > > ./danfe From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 08:06:20 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id F2BDEE76; Tue, 5 Mar 2013 08:06:20 +0000 (UTC) Date: Tue, 5 Mar 2013 08:06:20 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130305080620.GA10559@FreeBSD.org> References: <20130304024631.GA78040@FreeBSD.org> <20130304052328.GA1445@michelle.cdnetworks.com> <20130304055948.GA76042@FreeBSD.org> <20130304062944.GB1445@michelle.cdnetworks.com> <20130304065940.GA13417@FreeBSD.org> <20130304070632.GC1445@michelle.cdnetworks.com> <20130304081858.GA23857@FreeBSD.org> <20130305054920.GD1472@michelle.cdnetworks.com> <20130305065910.GA97021@FreeBSD.org> <20130305074315.GE1472@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130305074315.GE1472@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:06:21 -0000 On Tue, Mar 05, 2013 at 04:43:15PM +0900, YongHyeon PYUN wrote: > > > Could you disable WOL before rebooting your box? > > > > # ifconfig ale0 -wol > > # reboot > > > > It came up as 100baseTX. :( > > You don't use any manual link configuration, right? Right, everything is auto (that is, the defaults). > When you see the controller established a 100Mbps link, how about > restarting auto-negotiation? Does that also result in 100Mbps link? # ifconfig ale0 media auto # ifconfig ale0 | egrep -v ether\|inet ale0: flags=8843 metric 0 mtu 1500 options=c319a nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active Tried a few times, no difference. ./danfe From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 08:40:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B9BF816; Tue, 5 Mar 2013 08:40:54 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 57001973; Tue, 5 Mar 2013 08:40:53 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r258egAG012697; Tue, 5 Mar 2013 00:40:46 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303050840.r258egAG012697@gw.catspoiler.org> Date: Tue, 5 Mar 2013 00:40:42 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: phk@phk.freebsd.dk In-Reply-To: <28305.1362465535@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: kostikbel@gmail.com, deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:40:54 -0000 On 5 Mar, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > -------- > In message <201303050519.r255JbAu012422@gw.catspoiler.org>, Don Lewis writes: > >>That's been my opinion for a long time as well, though I think it would >>be better to have one thread per device to avoid syncer threads for >>multiple partitions on the same drive all contending for the same >>actuator. > > That would require that you move the syncer to the bottom of GEOM > and initiate syncs by upcalls to the consumers above. But how > does that work in the case of a mirrored drive ? ... or even worse, raid5. > Doesn't sound like a good idea to me. I wasn't advocating anything like that, but something more like this example: When we first boot, we mount /dev/ada0s1a to /. We query geom to find the underlying device name for ada0s1a and find that it is ada0. We find that we don't have a syncer thread for ada0, so we start one and attach the syncer worklist for / to the thread. Next we mount /dev/ada0s1h to /home. We query geom to find the underlying device name and find that it is also ada0. Since there is already a syncer thread for ada0, we just attach the /home worklist to this thread. Next we mount /dev/ada1s1a to /somewhere. We query geom, find that there is no syncer thread for ada1, so we start one and attach the worklist for /somewhere to this thread. For composite devices such as mirrors, using the first underlying device is probably a reasonable choice. For more complicated cases, or to override the default, the syncer thread could be specified as a mount option. Each time it woke up, each syncer thread would walk through its list of worklists, and for each worklist it would fsync all the vnodes in the current bucket. >>Multiple threads would allow us to better exploit the parallelism >>provided by the hardware and prevent a slow drive from impacting the >>performance of the other drives in the system. > > It would also allow us to have different sync-intervals for different > filesystems. Yup, you could override the system default intervals using mount options. From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 08:45:12 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3177D9FE; Tue, 5 Mar 2013 08:45:12 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id ECA499A9; Tue, 5 Mar 2013 08:45:11 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id BEB088A525; Tue, 5 Mar 2013 08:45:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r258j89k065343; Tue, 5 Mar 2013 08:45:09 GMT (envelope-from phk@phk.freebsd.dk) To: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive In-reply-to: <201303050840.r258egAG012697@gw.catspoiler.org> From: "Poul-Henning Kamp" References: <201303050840.r258egAG012697@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 05 Mar 2013 08:45:08 +0000 Message-ID: <65342.1362473108@critter.freebsd.dk> Cc: kostikbel@gmail.com, deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:45:12 -0000 In message <201303050840.r258egAG012697@gw.catspoiler.org>, Don Lewis writes: >For composite devices such as mirrors, using the first underlying device >is probably a reasonable choice. For more complicated cases, or to >override the default, the syncer thread could be specified as a mount >option. I doubt that will be any better than what we have today. I think it is a much better idea to have the syncer monitor bio write latency and adjust accordingly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 08:52:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1878C1E; Tue, 5 Mar 2013 08:52:15 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 85E559EB; Tue, 5 Mar 2013 08:52:15 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,786,1355126400"; d="scan'208";a="27999298" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 05 Mar 2013 00:52:14 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r258qEma028656; Tue, 5 Mar 2013 00:52:14 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0328.009; Tue, 5 Mar 2013 00:52:14 -0800 From: "Eggert, Lars" To: Doug Ambrisko Subject: Re: serial console not accepting input? Thread-Topic: serial console not accepting input? Thread-Index: AQHN+YBoyi5llRmNskaJJfjFwBFvjphXmc4AgAFlZICAPbmIAIAA19aA Date: Tue, 5 Mar 2013 08:52:12 +0000 Message-ID: References: <51000A18.1020001@FreeBSD.org> <20130304195942.GA56928@ambrisko.com> In-Reply-To: <20130304195942.GA56928@ambrisko.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <7309DDA140340942A1E29D350BFDFEDE@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:52:15 -0000 On Mar 4, 2013, at 20:59, Doug Ambrisko wrote: > Try to do a {Ctrl}D to see if works. We've seen that the TX on reset > hangs but input works fine. I'm not sure if we ran into this with > uart(4) but had a problem with sio(4). No change. Lars From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 08:57:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76CC1D4C; Tue, 5 Mar 2013 08:57:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by mx1.freebsd.org (Postfix) with ESMTP id 34ABFA10; Tue, 5 Mar 2013 08:57:11 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rp2so4135763pbb.6 for ; Tue, 05 Mar 2013 00:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=DUDTKhgtOdQG3ZTwJz9utUn/I758ac0vlKgM3vzJD6I=; b=Pgl7nv+OPtZTOgvpa3bF+7C9cWF2IYKIF2p0IQpqOASv8epNcRMIg0UgOu7Pee64ma wWp4Pd/B6PM/d47MfEKVQiuK/cPaj9WDEfMhvjO9V3ynkBDSTpwxAZ2IDZLN6iWyixXg 8c7yGRZp2DtzqnlDfDPYU1SbopWVwvGxXdh3VbtkqMUB8h3H4WDf+sbaTfJ0NTzDO85j Yw9qmsIMUc5zihEnZlUOBdqakADMgGR3gJhU3g9R1iQ80TZM7k4LxgXrklytx+areyj8 RKh799EQObIcZh4MGTjrdxIwpufjqhM8rPcwwJTqJsqW8cDFYjC1Sxr1uEobpfq4EooU FNlw== X-Received: by 10.68.130.1 with SMTP id oa1mr35958832pbb.134.1362473830633; Tue, 05 Mar 2013 00:57:10 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id iu10sm25778854pbc.13.2013.03.05.00.57.07 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 05 Mar 2013 00:57:09 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 05 Mar 2013 17:57:03 +0900 From: YongHyeon PYUN Date: Tue, 5 Mar 2013 17:57:03 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130305085703.GF1472@michelle.cdnetworks.com> References: <20130304052328.GA1445@michelle.cdnetworks.com> <20130304055948.GA76042@FreeBSD.org> <20130304062944.GB1445@michelle.cdnetworks.com> <20130304065940.GA13417@FreeBSD.org> <20130304070632.GC1445@michelle.cdnetworks.com> <20130304081858.GA23857@FreeBSD.org> <20130305054920.GD1472@michelle.cdnetworks.com> <20130305065910.GA97021@FreeBSD.org> <20130305074315.GE1472@michelle.cdnetworks.com> <20130305080620.GA10559@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305080620.GA10559@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:57:11 -0000 On Tue, Mar 05, 2013 at 08:06:20AM +0000, Alexey Dokuchaev wrote: > On Tue, Mar 05, 2013 at 04:43:15PM +0900, YongHyeon PYUN wrote: > > > > Could you disable WOL before rebooting your box? > > > > > > # ifconfig ale0 -wol > > > # reboot > > > > > > It came up as 100baseTX. :( > > > > You don't use any manual link configuration, right? > > Right, everything is auto (that is, the defaults). > > > When you see the controller established a 100Mbps link, how about > > restarting auto-negotiation? Does that also result in 100Mbps link? > > # ifconfig ale0 media auto > # ifconfig ale0 | egrep -v ether\|inet > ale0: flags=8843 metric 0 mtu 1500 > options=c319a > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > > Tried a few times, no difference. Hmm, Does the switch support EEE feature? If yes, would you try disabling it? > > ./danfe From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 09:14:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id E64C4825; Tue, 5 Mar 2013 09:14:11 +0000 (UTC) Date: Tue, 5 Mar 2013 09:14:11 +0000 From: Alexey Dokuchaev To: YongHyeon PYUN Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130305091411.GA26471@FreeBSD.org> References: <20130304055948.GA76042@FreeBSD.org> <20130304062944.GB1445@michelle.cdnetworks.com> <20130304065940.GA13417@FreeBSD.org> <20130304070632.GC1445@michelle.cdnetworks.com> <20130304081858.GA23857@FreeBSD.org> <20130305054920.GD1472@michelle.cdnetworks.com> <20130305065910.GA97021@FreeBSD.org> <20130305074315.GE1472@michelle.cdnetworks.com> <20130305080620.GA10559@FreeBSD.org> <20130305085703.GF1472@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130305085703.GF1472@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:14:12 -0000 On Tue, Mar 05, 2013 at 05:57:03PM +0900, YongHyeon PYUN wrote: > Hmm, Does the switch support EEE feature? If yes, would you try > disabling it? I do not think it [1] does; plus I cannot do much about this switch, as I'm pretty far away from it right now. ./danfe [1] http://netgear.com/home/products/switches-and-access-points/unmanaged-switches/GS608.aspx (got it about 4 years ago) From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 09:15:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1252B94C for ; Tue, 5 Mar 2013 09:15:23 +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 CD4DDCFB for ; Tue, 5 Mar 2013 09:15:22 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1UCnxs-000jgl-6O>; Tue, 05 Mar 2013 10:15:16 +0100 Received: from e178016006.adsl.alicedsl.de ([85.178.16.6] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1UCnxs-001Whd-46>; Tue, 05 Mar 2013 10:15:16 +0100 Message-ID: <5135B7E1.3050002@zedat.fu-berlin.de> Date: Tue, 05 Mar 2013 10:16:17 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130216 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Current Subject: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.16.6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:15:23 -0000 On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I run into a mess and can not figure out what happens. Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 is without mouse. Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. This is weird. I can not extract and rebuild ports anymore, every port I try to rebuild with portmaster fails with the very same fault: => SHA256 Checksum OK for dbus-1.4.14.tar.gz. *** [do-extract] Signal 13 Stop in /usr/ports/devel/dbus. ===>>> make failed for devel/dbus ===>>> Aborting update What is going on? Why is that? -- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 09:25:58 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F0D7DB9F; Tue, 5 Mar 2013 09:25:58 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id D4FA0D72; Tue, 5 Mar 2013 09:25:58 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r259Pm7o012790; Tue, 5 Mar 2013 01:25:51 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303050925.r259Pm7o012790@gw.catspoiler.org> Date: Tue, 5 Mar 2013 01:25:48 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: phk@phk.freebsd.dk In-Reply-To: <65342.1362473108@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: kostikbel@gmail.com, deeptech71@gmail.com, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:25:59 -0000 On 5 Mar, Poul-Henning Kamp wrote: > In message <201303050840.r258egAG012697@gw.catspoiler.org>, Don Lewis writes: > >>For composite devices such as mirrors, using the first underlying device >>is probably a reasonable choice. For more complicated cases, or to >>override the default, the syncer thread could be specified as a mount >>option. > > I doubt that will be any better than what we have today. I'm thinking of the case where ada0s1a and ada1s1a are mirrored, ada0s2b and ada1s2b are mirrored, etc. Or ada0 and ada1 are mirrored and then the mirror is partitioned. We don't want two syncer threads simultaneously trying to fsync files on the outer tracks and the inner tracks. If we just create a syncer thread for ada0, it will fsync the files on the outer tracks first and then go on to the inner tracks, avoiding lots of long seeks. > I think it is a much better idea to have the syncer monitor bio write > latency and adjust accordingly. That's a good idea as well, but that's also something that is global to each "device". From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 09:33:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAA46F86 for ; Tue, 5 Mar 2013 09:33:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 67C1ADDB for ; Tue, 5 Mar 2013 09:33:14 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a] (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BB0DE5C43; Tue, 5 Mar 2013 10:33:13 +0100 (CET) Message-ID: <5135BBD9.9090009@FreeBSD.org> Date: Tue, 05 Mar 2013 10:33:13 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Hartmann, O." , FreeBSD Current Subject: Re: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction References: <5135B7E1.3050002@zedat.fu-berlin.de> In-Reply-To: <5135B7E1.3050002@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:33:14 -0000 On 2013-03-05 10:16, Hartmann, O. wrote: > On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I > run into a mess and can not figure out what happens. > > Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 > is without mouse. > > Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. > > This is weird. I can not extract and rebuild ports anymore, every port I > try to rebuild with portmaster fails with the very same fault: > > => SHA256 Checksum OK for dbus-1.4.14.tar.gz. > *** [do-extract] Signal 13 This is SIGPIPE, so maybe your tar is broken? What happens if you manually extract that tar.gz file? From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 09:46:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C61E555D; Tue, 5 Mar 2013 09:46:16 +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 8D638E88; Tue, 5 Mar 2013 09:46:16 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UCoRr-000ukd-Nl>; Tue, 05 Mar 2013 10:46:15 +0100 Received: from e178011089.adsl.alicedsl.de ([85.178.11.89] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UCoRr-001ZWy-L9>; Tue, 05 Mar 2013 10:46:15 +0100 Message-ID: <5135BF24.8050908@zedat.fu-berlin.de> Date: Tue, 05 Mar 2013 10:47:16 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130216 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> In-Reply-To: <5135BBD9.9090009@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.11.89 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:46:16 -0000 On 03/05/13 10:33, Dimitry Andric wrote: > On 2013-03-05 10:16, Hartmann, O. wrote: >> On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I >> run into a mess and can not figure out what happens. >> >> Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 >> is without mouse. >> >> Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. >> >> This is weird. I can not extract and rebuild ports anymore, every port I >> try to rebuild with portmaster fails with the very same fault: >> >> => SHA256 Checksum OK for dbus-1.4.14.tar.gz. >> *** [do-extract] Signal 13 > > This is SIGPIPE, so maybe your tar is broken? What happens if you > manually extract that tar.gz file? I'm now with FreeBSD 10.0-CURRENT #0 r247832: Tue Mar 5 10:16:41 CET 2013/amd64. The buildworld is performed with CLANG - as it should be and for most ports, I use also CLANG. Just for the record. Now, after the buildworld and install, after the reboot the X11 server/xdm isn't even coming up again! Looking at /usr/src/UPDATING says I should recompile kernel modules or ports that provide such. With buildworld I have done so, all other rebuild is impossible due to a system failure as reported. I tried extract with tar (which tar provides /usr/bin/tar) the port devel/dbus - I can extract. I tried gtar (which gtar: /usr/local/bin/gtar). If tar is broken, then tar on CURRENT is broken. At the moment, I'm floating liek a dead man in the water. From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 10:09:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0CC76D2; Tue, 5 Mar 2013 10:09:24 +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 C75C7230; Tue, 5 Mar 2013 10:09:23 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UCooF-0014Jk-05>; Tue, 05 Mar 2013 11:09:23 +0100 Received: from e178011089.adsl.alicedsl.de ([85.178.11.89] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UCooE-001bZP-Tk>; Tue, 05 Mar 2013 11:09:22 +0100 Message-ID: <5135C48F.2050709@zedat.fu-berlin.de> Date: Tue, 05 Mar 2013 11:10:23 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130216 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> In-Reply-To: <5135BBD9.9090009@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.11.89 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:09:24 -0000 On 03/05/13 10:33, Dimitry Andric wrote: > On 2013-03-05 10:16, Hartmann, O. wrote: >> On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I >> run into a mess and can not figure out what happens. >> >> Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 >> is without mouse. >> >> Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. >> >> This is weird. I can not extract and rebuild ports anymore, every port I >> try to rebuild with portmaster fails with the very same fault: >> >> => SHA256 Checksum OK for dbus-1.4.14.tar.gz. >> *** [do-extract] Signal 13 > > This is SIGPIPE, so maybe your tar is broken? What happens if you > manually extract that tar.gz file? well, since I can't do portmaster on EVERY FreeBSD 10.0-CURRENT I have around (three boxes, different types of hardware but the same revision of sources as from today - and buildworld/kernel of course) I guess this is a major damage. Is there a way how I can "trace" the "make extract" task in the port's directory? I can manually untar each tarball, but while doing "make extract" I always get this ===> dbus-1.4.14_4 depends on file: /usr/local/sbin/pkg - found ===> Extracting for dbus-1.4.14_4 => SHA256 Checksum OK for dbus-1.4.14.tar.gz. *** [do-extract] Signal 13 (devel/dbus is an example, it happens to ALL ports). Oliver From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 10:20:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D1914A3 for ; Tue, 5 Mar 2013 10:20:00 +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 15C0A2FE for ; Tue, 5 Mar 2013 10:19:59 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1UCoyU-0018bw-UM>; Tue, 05 Mar 2013 11:19:58 +0100 Received: from e178011089.adsl.alicedsl.de ([85.178.11.89] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1UCoyU-001cbe-Rl>; Tue, 05 Mar 2013 11:19:58 +0100 Message-ID: <5135C70B.50906@zedat.fu-berlin.de> Date: Tue, 05 Mar 2013 11:20:59 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130216 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Current Subject: r247835: drm2 code breaks buildkernel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.11.89 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:20:00 -0000 On r247835 build kernel fails: cc -O2 -pipe -O3 -pipe -march=native -O3 -march=native -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GATE/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/GATE -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_ioctl.c /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_global.c:63:27: error: unused variable 'item' [-Werror,-Wunused-variable] struct drm_global_item *item = &glob[i]; ^ 1 error generated. *** [drm_global.o] Error code 1 Just for the record, oh From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 10:46:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DC178A2A for ; Tue, 5 Mar 2013 10:46:47 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id A53D064E for ; Tue, 5 Mar 2013 10:46:47 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UCpOQ-000Llu-Fx for freebsd-current@freebsd.org; Tue, 05 Mar 2013 11:46:47 +0100 Message-ID: <5135CD0E.8040801@dumbbell.fr> Date: Tue, 05 Mar 2013 11:46:38 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r247835: drm2 code breaks buildkernel References: <5135C70B.50906@zedat.fu-berlin.de> In-Reply-To: <5135C70B.50906@zedat.fu-berlin.de> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2NEQQUIAPAJIXPPFLXMGG" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:46:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2NEQQUIAPAJIXPPFLXMGG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05.03.2013 11:20, Hartmann, O. wrote: > On r247835 build kernel fails: >=20 > (...) > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_global.c:63:27: > error: unused variable 'item' [-Werror,-Wunused-variable] > struct drm_global_item *item =3D &glob[i]; Could you try the patch below? http://people.freebsd.org/~dumbbell/radeonkms/drm_global-unused-variable.= a.patch --=20 Jean-S=E9bastien P=E9dron ------enig2NEQQUIAPAJIXPPFLXMGG 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 Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE1zRUACgkQa+xGJsFYOlMwqwCeIskrn8x9Kin4M+y76v2gww96 FbAAn136NYwxPZZ/3oXWGgWiQcafz2cF =6BCK -----END PGP SIGNATURE----- ------enig2NEQQUIAPAJIXPPFLXMGG-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 11:58:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8BFB1D9 for ; Tue, 5 Mar 2013 11:58:51 +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 831E890C for ; Tue, 5 Mar 2013 11:58:51 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UCqWA-001htV-CY>; Tue, 05 Mar 2013 12:58:50 +0100 Received: from e178028174.adsl.alicedsl.de ([85.178.28.174] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UCqWA-001lXj-AE>; Tue, 05 Mar 2013 12:58:50 +0100 Message-ID: <5135DE36.9010303@zedat.fu-berlin.de> Date: Tue, 05 Mar 2013 12:59:50 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130216 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Subject: Re: r247835: drm2 code breaks buildkernel References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> In-Reply-To: <5135CD0E.8040801@dumbbell.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Originating-IP: 85.178.28.174 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 11:58:51 -0000 On 03/05/13 11:46, Jean-Sébastien Pédron wrote: > On 05.03.2013 11:20, Hartmann, O. wrote: >> On r247835 build kernel fails: >> >> (...) >> /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_global.c:63:27: >> error: unused variable 'item' [-Werror,-Wunused-variable] >> struct drm_global_item *item = &glob[i]; > > Could you try the patch below? > > http://people.freebsd.org/~dumbbell/radeonkms/drm_global-unused-variable.a.patch > Got new sources, I'm at FreeBSD 10.0-CURRENT #1 r247839: Tue Mar 5 12:28:12 CET 2013/amd64 and the kernel builds normal again. Thanks, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 12:30:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 623D0F8A; Tue, 5 Mar 2013 12:30:20 +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 099E9B09; Tue, 5 Mar 2013 12:30:20 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (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 858B623F645; Tue, 5 Mar 2013 07:30:17 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 858B623F645 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 5 Mar 2013 07:30:16 -0500 From: Glen Barber To: "Hartmann, O." Subject: Re: r247835: drm2 code breaks buildkernel Message-ID: <20130305123016.GE1483@glenbarber.us> References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IU5/I01NYhRvwH70" Content-Disposition: inline In-Reply-To: <5135DE36.9010303@zedat.fu-berlin.de> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 12:30:20 -0000 --IU5/I01NYhRvwH70 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 05, 2013 at 12:59:50PM +0100, Hartmann, O. wrote: > > Could you try the patch below? > >=20 > > http://people.freebsd.org/~dumbbell/radeonkms/drm_global-unused-variabl= e.a.patch > >=20 >=20 > Got new sources, I'm at FreeBSD 10.0-CURRENT #1 r247839: Tue Mar 5 > 12:28:12 CET 2013/amd64 and the kernel builds normal again. >=20 I still see kernel build failure with and without the above patch. Script started on Tue Mar 5 07:28:11 2013 root@nucleus:/usr/src # svnversion 247839 root@nucleus:/usr/src # time make -s -j4 KERNCONF=3DNUCLEUS buildkernel -------------------------------------------------------------- >>> Kernel build for NUCLEUS started on Tue Mar 5 07:28:20 EST 2013 -------------------------------------------------------------- =3D=3D=3D> NUCLEUS -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- Kernel build directory is /usr/obj/usr/src/sys/NUCLEUS Don't forget to do ``make cleandepend && make depend'' -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- =3D=3D=3D> drm2/drm2 (cleandir) =3D=3D=3D> drm2/i915kms (cleandir) =3D=3D=3D> opensolaris (cleandir) =3D=3D=3D> zfs (cleandir) -------------------------------------------------------------- >>> stage 2.2: rebuilding the object tree -------------------------------------------------------------- =3D=3D=3D> drm2/drm2 (obj) =3D=3D=3D> drm2/i915kms (obj) =3D=3D=3D> opensolaris (obj) =3D=3D=3D> zfs (obj) -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- -------------------------------------------------------------- >>> stage 3.1: making dependencies -------------------------------------------------------------- =3D=3D=3D> drm2/drm2 (depend) =3D=3D=3D> drm2/i915kms (depend) =3D=3D=3D> opensolaris (depend) =3D=3D=3D> zfs (depend) -------------------------------------------------------------- >>> stage 3.2: building everything -------------------------------------------------------------- =3D=3D=3D> drm2/drm2 (all) In file included from /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/= ttm_lock.c:42: @/dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of 'ttm_wri= te_unlock' [-Wredundant-decls] @/dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of 'ttm_write_= unlock' was here @/dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of 'ttm_wri= te_lock' [-Wredundant-decls] @/dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of 'ttm_write_= lock' was here /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:122: = warning: declaration does not declare anything /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:123: = warning: declaration does not declare anything /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In f= unction 'ttm_get_pool': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:280: = error: 'struct ttm_pool_manager' has no member named 'pools' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In f= unction 'ttm_pool_get_num_unused_pages': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:391: = error: 'struct ttm_pool_manager' has no member named 'pools' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In f= unction 'ttm_pool_mm_shrink': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:413: = error: 'struct ttm_pool_manager' has no member named 'pools' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In f= unction 'ttm_page_alloc_init': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:786: = error: 'struct ttm_pool_manager' has no member named 'wc_pool' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:787: = error: 'struct ttm_pool_manager' has no member named 'uc_pool' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:788: = error: 'struct ttm_pool_manager' has no member named 'wc_pool_dma32' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:790: = error: 'struct ttm_pool_manager' has no member named 'uc_pool_dma32' /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c: In f= unction 'ttm_page_alloc_fini': /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_page_alloc.c:811: = error: 'struct ttm_pool_manager' has no member named 'pools' *** [ttm_page_alloc.o] Error code 1 1 error *** [all] Error code 2 1 error *** [modules-all] Error code 2 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error 22.434u 9.092s 0:22.11 142.5% 6476+1023k 109+98423io 6pf+0w root@nucleus:/usr/src # ^D Script done on Tue Mar 5 07:28:47 2013 Glen --IU5/I01NYhRvwH70 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRNeVYAAoJEFJPDDeguUajjKkH/3cEnrmWok/NAv80vszuNxbj UFiYDgIKUrXiK7lrXzQuFOcZ+YRtpq15k+83iXwnOqVsKEzi8rfQTlQZ+L1oz8qV qLAHKdSU7NE4JqXro7pWiBmxgwOlRbD2luC7TYQ4UmR4/ukYPcV83JylnhcOnGn3 DaYVjQFz9N7OSQ7uG18O96v8AwtdFq1/9hF1vy9OPbFBO1zIDybKweD6sS+wwo9o GS116HR9aVXAi/i24iea/4i2v5Uzw+HImpgYUn9I6pskdoFem+dvUhhwJ10BeGzM DDFAbqpp2xPf6qG/JbHGxPGXyZ8Yb6PS6k8lTMjcDOVjzsgGs68/oPEl65t9aUE= =eJkV -----END PGP SIGNATURE----- --IU5/I01NYhRvwH70-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 14:13:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C72F0C3B for ; Tue, 5 Mar 2013 14:13:14 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id 8720B1C6 for ; Tue, 5 Mar 2013 14:13:14 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UCscD-000Pv6-3B; Tue, 05 Mar 2013 15:13:13 +0100 Message-ID: <5135FD78.1050608@FreeBSD.org> Date: Tue, 05 Mar 2013 15:13:12 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r247835: drm2 code breaks buildkernel References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> <20130305123016.GE1483@glenbarber.us> In-Reply-To: <20130305123016.GE1483@glenbarber.us> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2GVGBTWFPHBEOUGDKEESL" Cc: Konstantin Belousov , "J.R. Oldroyd" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 14:13:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GVGBTWFPHBEOUGDKEESL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05.03.2013 13:30, Glen Barber wrote: > dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of 'ttm_w= rite_unlock' [-Wredundant-decls] > dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of 'ttm_writ= e_unlock' was here > dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of 'ttm_w= rite_lock' [-Wredundant-decls] > dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of 'ttm_writ= e_lock' was here Those redundant declarations weren't spotted by clang. Konstantin, would you like me to commit the fix for this? And we need to upstream it too. > dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declar= e anything > dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declar= e anything These errors and the following are caused by unnamed structs and unions inside another struct: struct ttm_pool_manager { ... union { struct ttm_page_pool pools[NUM_POOLS]; struct { ... } ; }; }; With default options, clang accepts this but apparently, not gcc. I would like an opinion from the toolchain gurus, because I don't know what's the proper way to fix this one. J.R. Oldroyd CC'd, because he started to work on radeonkms backport to 9 and faced exactly those issues. --=20 Jean-S=E9bastien P=E9dron ------enig2GVGBTWFPHBEOUGDKEESL 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 Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE1/XgACgkQa+xGJsFYOlPPqwCgljpm8HOWKYCEodHzUpvhrsO9 8igAoM0eXDzZ/ad7y2+uGumDvI63LFgx =SyCJ -----END PGP SIGNATURE----- ------enig2GVGBTWFPHBEOUGDKEESL-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 14:54:31 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0853C5C9; Tue, 5 Mar 2013 14:54:31 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id B5854640; Tue, 5 Mar 2013 14:54:30 +0000 (UTC) Received: from pool-141-154-241-44.bos.east.verizon.net ([141.154.241.44] helo=homobox.opal.com) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCtG9-0005Lc-Fu; Tue, 05 Mar 2013 14:54:29 +0000 Received: from shibato (shibato.opal.com [IPv6:2001:470:8cb8:4:221:63ff:fe5a:c9a7]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id r25EsPJr098415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 5 Mar 2013 09:54:26 -0500 (EST) (envelope-from fbsd@opal.com) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 141.154.241.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/vHzpbUBo+Diki6afP8DGR Date: Tue, 5 Mar 2013 09:54:17 -0500 From: "J.R. Oldroyd" To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Subject: Re: r247835: drm2 code breaks buildkernel Message-ID: <20130305095417.3780d487@shibato> In-Reply-To: <5135FD78.1050608@FreeBSD.org> References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> <20130305123016.GE1483@glenbarber.us> <5135FD78.1050608@FreeBSD.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/LV0HoYyJMfi6yq1=m=elJd9"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (homobox.opal.com [IPv6:2001:470:8cb8:4::1]); Tue, 05 Mar 2013 09:54:26 -0500 (EST) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, RP_MATCHES_RCVD shortcircuit=no autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on homobox.opal.com Cc: Konstantin Belousov , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 14:54:31 -0000 --Sig_/LV0HoYyJMfi6yq1=m=elJd9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 05 Mar 2013 15:13:12 +0100 Jean-S=C3=A9bastien P=C3=A9dron wrote: > > On 05.03.2013 13:30, Glen Barber wrote: > > dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of 'ttm_w= rite_unlock' [-Wredundant-decls] > > dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of 'ttm_writ= e_unlock' was here > > dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of 'ttm_w= rite_lock' [-Wredundant-decls] > > dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of 'ttm_writ= e_lock' was here >=20 > Those redundant declarations weren't spotted by clang. >=20 > Konstantin, would you like me to commit the fix for this? And we need to > upstream it too. >=20 A fix for these is in my big "get it to compile" patch that I emailed you both the other day. > > dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declar= e anything > > dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declar= e anything >=20 > These errors and the following are caused by unnamed structs and unions > inside another struct: >=20 > struct ttm_pool_manager { > ... >=20 > union { > struct ttm_page_pool pools[NUM_POOLS]; > struct { > ... > } ; > }; > }; >=20 > With default options, clang accepts this but apparently, not gcc. > Experimentation shows that this warning is triggered because we use -std=3Diso9899:1999. It can be turned off again by adding --ms-extensions too. Alternatively, my big patch replaces all these anon unions with named ones. There are lots of these in this code, though. Doing this adds lots of patch bloat. > I would like an opinion from the toolchain gurus, because I don't know > what's the proper way to fix this one. >=20 > J.R. Oldroyd CC'd, because he started to work on radeonkms backport to 9 > and faced exactly those issues. >=20 There is a further problem not mentioned here. Three of the files make use of a pointer to a volatile int but later cast this to a (void *). Because we also have -Wcast-qual, this cast triggers "cast discards qualifier on pointer target type" warnings and because of -Werror, this then aborts. What's the best way to fix that? -jr --Sig_/LV0HoYyJMfi6yq1=m=elJd9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlE2ByEACgkQls33urr0k4l3fACgnznkytk2+2Omhg3BC/gvaJy2 ezUAoJdDkaA74VojMDWiE0tRknHUh8Fd =klTb -----END PGP SIGNATURE----- --Sig_/LV0HoYyJMfi6yq1=m=elJd9-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 15:07:27 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EC2DEAFD; Tue, 5 Mar 2013 15:07:27 +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 AA97677E; Tue, 5 Mar 2013 15:07:27 +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 2FB0A23F645; Tue, 5 Mar 2013 10:07:26 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 2FB0A23F645 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 5 Mar 2013 10:07:24 -0500 From: Glen Barber To: freebsd-current@FreeBSD.org Subject: drm GPU hung, resume no longer working Message-ID: <20130305150724.GB1516@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Clx92ZfkiYIKRjnr" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 15:07:28 -0000 --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am running: FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #87 r247546: Fri Mar 1 13:15:42 EST 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 Sometime very recently, resume has stopped working. I can ssh to the machine when it resumes, and I do see my background image on resume, but once the screen goes into locked mode (xscreensaver), I cannot get back to a working state without reboot. syslog reports: Mar 5 09:21:33 nucleus kernel: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 5 09:21:33 nucleus kernel: info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state dmesg says: uhub2: 2 ports with 2 removable, self powered ugen0.2: at usbus0 uhub3: on usbus0 ugen2.2: at usbus2 uhub4: on usbus2 uhub3: 6 ports with 6 removable, self powered uhub4: 6 ports with 6 removable, self powered ugen0.3: at usbus0 error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state hw.dri.0.info.i915_error_state output is at: http://people.freebsd.org/~gjb/i915.sysctl.txt Any thoughts on how to debug this further? Thanks. Glen --Clx92ZfkiYIKRjnr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRNgosAAoJEFJPDDeguUajPysH/AkxDYYv8evMjTRJJUOQnFkl 8zUlngRdBGsPbkEZaxHnfPrlvgTNL7b5aJbOKClHPpLzweaOBpV5xjV31uIhaZou A1/5/CGMXCUAo6ifnEYYHUoO32TgRrasIJOiJFnx8YvstfXFlrFozlivq3riZQaG TkiMJSU5rfUHgkigGzgzUW/ICvTagUETiTUqcitAI6xPieazUkpIcwdJ7Qq7O6O5 tDk9xz8b4RiAxiIKgzjYWiUuhiHe4X0Os0xYrINmudbu7nrfoQQmbLHsV3wo/0Wh /t4TVVENWy8AG6NDayzXHooJI6mEB2r7sJlMrHBN3Ar5fM/TPOczlEJMYRdIa1Y= =d9pB -----END PGP SIGNATURE----- --Clx92ZfkiYIKRjnr-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 15:27:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E00E02B5 for ; Tue, 5 Mar 2013 15:27:13 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id 9667686E for ; Tue, 5 Mar 2013 15:27:13 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UCtlo-0001NI-BC for freebsd-current@freebsd.org; Tue, 05 Mar 2013 16:27:12 +0100 Message-ID: <51360ECB.4000407@dumbbell.fr> Date: Tue, 05 Mar 2013 16:27:07 +0100 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r247835: drm2 code breaks buildkernel References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> <20130305123016.GE1483@glenbarber.us> <5135FD78.1050608@FreeBSD.org> <20130305095417.3780d487@shibato> In-Reply-To: <20130305095417.3780d487@shibato> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2QHTXUAOPWHLISLOMTTGH" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 15:27:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QHTXUAOPWHLISLOMTTGH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05.03.2013 15:54, J.R. Oldroyd wrote: > A fix for these is in my big "get it to compile" patch that I emailed > you both the other day. Sorry, I didn't take the time to read it yet :-/ >>> dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not decl= are anything >>> dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not decl= are anything > > Experimentation shows that this warning is triggered because we use > -std=3Diso9899:1999. It can be turned off again by adding --ms-extensi= ons > too. >=20 > Alternatively, my big patch replaces all these anon unions with > named ones. There are lots of these in this code, though. Doing > this adds lots of patch bloat. Yes, the flag is preferable. I didn't have the time to test it earlier either, until now. I confirm that it works with both clang and gcc. > There is a further problem not mentioned here. Three of the files > make use of a pointer to a volatile int but later cast this to a > (void *). Because we also have -Wcast-qual, this cast triggers > "cast discards qualifier on pointer target type" warnings and because > of -Werror, this then aborts. What's the best way to fix that? Those warnings are in the radeon driver, not ttm, aren't they? At least, the build finishes properly on my computer with gcc and clang with just -fms-extensions. --=20 Jean-S=C3=A9bastien P=C3=A9dron ------enig2QHTXUAOPWHLISLOMTTGH 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 Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE2DtAACgkQa+xGJsFYOlPvpgCglJEZ5Zb45iB5sBJUWR98QriB 1ykAn1Qj/ZYXjUT5hBGfLIJgzQZMhH+G =jWus -----END PGP SIGNATURE----- ------enig2QHTXUAOPWHLISLOMTTGH-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 15:35:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E960AA35 for ; Tue, 5 Mar 2013 15:35:44 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id 403FF8FF for ; Tue, 5 Mar 2013 15:35:44 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UCtu3-0001Wl-5p for freebsd-current@freebsd.org; Tue, 05 Mar 2013 16:35:43 +0100 Message-ID: <513610CE.30601@FreeBSD.org> Date: Tue, 05 Mar 2013 16:35:42 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: drm GPU hung, resume no longer working References: <20130305150724.GB1516@glenbarber.us> In-Reply-To: <20130305150724.GB1516@glenbarber.us> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2DGITLCEXMXAGOFQRLHUK" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 15:35:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2DGITLCEXMXAGOFQRLHUK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05.03.2013 16:07, Glen Barber wrote: > error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer ela= psed... GPU hung > info: [drm] capturing error event; look for more information in sysct= l hw.dri.0.info.i915_error_state >=20 > hw.dri.0.info.i915_error_state output is at: >=20 > http://people.freebsd.org/~gjb/i915.sysctl.txt It won't help much, but rpaulo@ posted a mail with a similar dmesg but different trigger on freebsd-x11@: http://lists.freebsd.org/pipermail/freebsd-x11/2013-March/012862.html --=20 Jean-S=E9bastien P=E9dron ------enig2DGITLCEXMXAGOFQRLHUK 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 Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE2EM4ACgkQa+xGJsFYOlMsnACcC5K0l6jFmoGffyK9BwuD/G1J LN8AoMInuyMS4rb4ukXwVnjcVIRW/nsk =tsmL -----END PGP SIGNATURE----- ------enig2DGITLCEXMXAGOFQRLHUK-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 15:37:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C769AE2B; Tue, 5 Mar 2013 15:37:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7AF936; Tue, 5 Mar 2013 15:37:45 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r25FbajN006299; Tue, 5 Mar 2013 17:37:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r25FbajN006299 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r25Fba71006298; Tue, 5 Mar 2013 17:37:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Mar 2013 17:37:36 +0200 From: Konstantin Belousov To: Jean-S?bastien P?dron Subject: Re: r247835: drm2 code breaks buildkernel Message-ID: <20130305153736.GH3794@kib.kiev.ua> References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> <20130305123016.GE1483@glenbarber.us> <5135FD78.1050608@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jaoouwwPWoQSJZYp" Content-Disposition: inline In-Reply-To: <5135FD78.1050608@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, "J.R. Oldroyd" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 15:37:45 -0000 --jaoouwwPWoQSJZYp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 05, 2013 at 03:13:12PM +0100, Jean-S?bastien P?dron wrote: > On 05.03.2013 13:30, Glen Barber wrote: > > dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of 'ttm_w= rite_unlock' [-Wredundant-decls] > > dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of 'ttm_writ= e_unlock' was here > > dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of 'ttm_w= rite_lock' [-Wredundant-decls] > > dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of 'ttm_writ= e_lock' was here >=20 > Those redundant declarations weren't spotted by clang. >=20 > Konstantin, would you like me to commit the fix for this? And we need to > upstream it too. I am somewhat sceptical about upstreaming. I reported a real bug in the ttm_lock with the trivial fix when I read the code for porting. Bug was confirmed by Linux people, but no action was taken. >=20 > > dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declar= e anything > > dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declar= e anything >=20 > These errors and the following are caused by unnamed structs and unions > inside another struct: >=20 > struct ttm_pool_manager { > ... >=20 > union { > struct ttm_page_pool pools[NUM_POOLS]; > struct { > ... > } ; > }; > }; >=20 > With default options, clang accepts this but apparently, not gcc. >=20 > I would like an opinion from the toolchain gurus, because I don't know > what's the proper way to fix this one. >=20 > J.R. Oldroyd CC'd, because he started to work on radeonkms backport to 9 > and faced exactly those issues. The patch below is supposed to fix double declaration (it is pathetic that clang silently accepts this, while issuing countless useless warnings). Also there is a usual workaround for the anonimous union/struct issue. Glen neglected to even mention that he used gcc (is it true ?), as well as to show the command line invocation of the compiler. Hopefully the patch helps. diff --git a/sys/dev/drm2/ttm/ttm_lock.h b/sys/dev/drm2/ttm/ttm_lock.h index ac8159e..6d45457 100644 --- a/sys/dev/drm2/ttm/ttm_lock.h +++ b/sys/dev/drm2/ttm/ttm_lock.h @@ -125,27 +125,6 @@ extern int ttm_read_lock(struct ttm_lock *lock, bool i= nterruptible); extern int ttm_read_trylock(struct ttm_lock *lock, bool interruptible); =20 /** - * ttm_write_unlock - * - * @lock: Pointer to a struct ttm_lock - * - * Releases a write lock. - */ -extern void ttm_write_unlock(struct ttm_lock *lock); - -/** - * ttm_write_lock - * - * @lock: Pointer to a struct ttm_lock - * @interruptible: Interruptible sleeping while waiting for a lock. - * - * Takes the lock in write mode. - * Returns: - * -ERESTARTSYS If interrupted by a signal and interruptible is true. - */ -extern int ttm_write_lock(struct ttm_lock *lock, bool interruptible); - -/** * ttm_lock_downgrade * * @lock: Pointer to a struct ttm_lock diff --git a/sys/dev/drm2/ttm/ttm_page_alloc.c b/sys/dev/drm2/ttm/ttm_page_= alloc.c index ffc8483..9a30a46 100644 --- a/sys/dev/drm2/ttm/ttm_page_alloc.c +++ b/sys/dev/drm2/ttm/ttm_page_alloc.c @@ -113,16 +113,22 @@ struct ttm_pool_manager { struct ttm_pool_opts options; =20 union { - struct ttm_page_pool pools[NUM_POOLS]; - struct { - struct ttm_page_pool wc_pool; - struct ttm_page_pool uc_pool; - struct ttm_page_pool wc_pool_dma32; - struct ttm_page_pool uc_pool_dma32; - } ; - }; + struct ttm_page_pool u_pools[NUM_POOLS]; + struct _utag { + struct ttm_page_pool u_wc_pool; + struct ttm_page_pool u_uc_pool; + struct ttm_page_pool u_wc_pool_dma32; + struct ttm_page_pool u_uc_pool_dma32; + } _ut; + } _u; }; =20 +#define pools _u.u_pools +#define wc_pool _u._ut.u_wc_pool +#define uc_pool _u._ut.u_uc_pool +#define wc_pool_dma32 _u._ut.u_wc_pool_dma32 +#define uc_pool_dma32 _u._ut.u_uc_pool_dma32 + MALLOC_DEFINE(M_TTM_POOLMGR, "ttm_poolmgr", "TTM Pool Manager"); =20 static void --jaoouwwPWoQSJZYp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIbBAEBAgAGBQJRNhFAAAoJEJDCuSvBvK1BpWQP9AgDjnFoVqBbbiQVEvSgSXpn KtZ6XfYhJL3aqAVlejKDmRNxOigU7t89bNxomYS+4BHxl8iTgX0O1KyBxi9muzKP VrwtfpD4K5Q77pM8EkQRb3PscxUUO0KuJlluk+pZlfb4w/Wh1bBXLmBcfprU645J RRTW6dm9D4Vkj/CmojqM0es2eI34hlJclqGkXAvez4a8PZIV4bzffoDF1DmehQnt 3QenI3M9fEwbg2CR1TYohsAgTZkEEJnuHlVjVB7Ll2xjr9aobrmTmRm9ZjUctTfL PHSZjgc3gDAfdHtpovW7DMrpJ37umXxqSi5INXkUvPKoML0Ejz8HW+QiSksFH7uB exwHeqKDGno4jKL625hvhLov3P3aK//50ZlWjW3E5ujqaLw0q48DEgJsACoEYu8e R2m6MlOHqxuLtIaMLW93ghJxu2ihP/nzj7GkP2Nv15/QR9H76ADTT4MnYD9S1bUr HU5S+/I+TibX2luIEtiokr4Y7Q6JC2GSl0NR/aqbXpuQOC+n8J6qifp/soXO/d+q iLT7L6mM387gaGfw4aFZP2bTHD2Rzv5D5OEKp879Kwp9CCm7VdIlg9M4KcV8KILv ZwYBoMch4T6GBnpykym0nXxXNa63J3CUf8c7Mn1zxqlAuPAg/vQuUnfSZlCQYjRM uZk44OVKTRSabmxkWkI= =hgsW -----END PGP SIGNATURE----- --jaoouwwPWoQSJZYp-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 15:48:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C9C5A23B; Tue, 5 Mar 2013 15:48:33 +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 7AC769C2; Tue, 5 Mar 2013 15:48:33 +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 7FA4123F645; Tue, 5 Mar 2013 10:48:32 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 7FA4123F645 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 5 Mar 2013 10:48:31 -0500 From: Glen Barber To: Konstantin Belousov Subject: Re: r247835: drm2 code breaks buildkernel Message-ID: <20130305154831.GD1516@glenbarber.us> References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> <20130305123016.GE1483@glenbarber.us> <5135FD78.1050608@FreeBSD.org> <20130305153736.GH3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Qz2CZ664xQdCRdPu" Content-Disposition: inline In-Reply-To: <20130305153736.GH3794@kib.kiev.ua> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, "J.R. Oldroyd" , Jean-S?bastien P?dron X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 15:48:33 -0000 --Qz2CZ664xQdCRdPu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 05, 2013 at 05:37:36PM +0200, Konstantin Belousov wrote: > Glen neglected to even mention that he used gcc (is it true ?), as well > as to show the command line invocation of the compiler. Hopefully the > patch helps. Yes, I am using gcc. I'll try your patch and report back. Glen --Qz2CZ664xQdCRdPu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRNhPOAAoJEFJPDDeguUajSdkH/27y+ZKvbIE6fcX9N6n5pvyt rx7MkeUA2lk5ybb7Ugldl4xP50b03WMbph0oxf3ahCYNrmBS7Afg333He9RQljCX /fn7gFrWZVeoBD5jrF4yAZM7UKYiYIzkBB/wJKkMGsmG0LZzjM8HnvpJFX7VgV1+ pO3RAwtzaR+qmGq43pLkN9noklCxfF/Kkydb92Ef/XMBFMZv+DLmgZvB8I6bS8tF aKRJWOQgZSyByGqpbAJTEjjAX48t/Dwm8uA4u7bldgl1VSEqjqtbaoyobROvf6OZ 7yIfPQcPgZF+nBhbjwm3BlHp+N4cJwjesZtHvT5/wuzimnS6NDNMfmXrsQkXkzY= =tMvQ -----END PGP SIGNATURE----- --Qz2CZ664xQdCRdPu-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 15:54:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC485509; Tue, 5 Mar 2013 15:54:31 +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 9283AA0D; Tue, 5 Mar 2013 15:54:31 +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 882FF23F645; Tue, 5 Mar 2013 10:54:30 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 882FF23F645 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 5 Mar 2013 10:54:29 -0500 From: Glen Barber To: Konstantin Belousov Subject: Re: r247835: drm2 code breaks buildkernel Message-ID: <20130305155428.GE1516@glenbarber.us> References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> <20130305123016.GE1483@glenbarber.us> <5135FD78.1050608@FreeBSD.org> <20130305153736.GH3794@kib.kiev.ua> <20130305154831.GD1516@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0rSojgWGcpz+ezC3" Content-Disposition: inline In-Reply-To: <20130305154831.GD1516@glenbarber.us> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, "J.R. Oldroyd" , Jean-S?bastien P?dron X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 15:54:31 -0000 --0rSojgWGcpz+ezC3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 05, 2013 at 10:48:31AM -0500, Glen Barber wrote: > On Tue, Mar 05, 2013 at 05:37:36PM +0200, Konstantin Belousov wrote: > > Glen neglected to even mention that he used gcc (is it true ?), as well > > as to show the command line invocation of the compiler. Hopefully the > > patch helps. >=20 > Yes, I am using gcc. I'll try your patch and report back. >=20 This patch does fix the build for me. Glen --0rSojgWGcpz+ezC3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRNhU0AAoJEFJPDDeguUajPhwH/13YYBFcn6/P517aFeuG3Aex +wGMzah+CQeRNb6pNnxfcL/sWcgog2hJeV+1KDNSglF6wXk0Dd86HqmNktMuFexV 2XkqhRPQnXaF2+DLbAnCwJRkaEVxiPwbhrASOIbqSH/qFQK03LzgWy/q7dEmG1SL YlZLea2M9EE+vfBNnRDZY8foF/evZXkiklyw2A62O4bJJNV+Pha53zPQaBnSprwA 9iSBnzF3dJhZIQWzEMcDK3snhhC1r1B4hiF5B6KCcJh/dWYXQYRtuR1kVlSvBJym PV1e3wudr5DVonREAwtWF1jac7FTNFnXycIG2bR6A8xoSe7Sp1WYUWTC+OdJN1A= =PDvu -----END PGP SIGNATURE----- --0rSojgWGcpz+ezC3-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 16:01:42 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B419D865; Tue, 5 Mar 2013 16:01:42 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 8E20BA83; Tue, 5 Mar 2013 16:01:42 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCuJB-00033b-98; Tue, 05 Mar 2013 16:01:41 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r25G1aWM001306; Tue, 5 Mar 2013 09:01:36 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX192UnEtHVpFaUX6sF4jkSa8 Subject: Re: access to hard drives is "blocked" by writes to a flash drive From: Ian Lepore To: Don Lewis In-Reply-To: <201303050527.r255R0Gd012437@gw.catspoiler.org> References: <201303050527.r255R0Gd012437@gw.catspoiler.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Mar 2013 09:01:36 -0700 Message-ID: <1362499296.1291.6.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 16:01:42 -0000 On Mon, 2013-03-04 at 21:27 -0800, Don Lewis wrote: > On 4 Mar, Ian Lepore wrote: > > On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote: > >> On 3 Mar, Poul-Henning Kamp wrote: > >> > >> > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > >> > traffic to other disks too, when these pileups gets too bad. > >> > >> The Lemming-syncer problem should have mostly been fixed by 231160 in > >> head (231952 in stable/9 and 231967 in stable/8) a little over a year > >> ago. The exceptions are atime updates, mmaped files with dirty pages, > >> and quotas. Under certain workloads I still notice periodic bursts of > >> seek noise. After thinking about it for a bit, I suspect that it could > >> be atime updates, but I haven't tried to confirm that. > >> > >> When using TCQ or NCQ, perhaps we should limit the number of outstanding > >> writes per device to leave some slots open for reads. We should > >> probably also prioritize reads over writes unless we are under memory > >> pressure. > >> > > > > Then either those changes didn't have the intended effect, or the > > problem we're seeing with lack of system responsiveness when there's a > > large backlog of writes to a slow device is not the lemming-syncer > > problem. It's also not a lack of TCQ/NCQ slots, given that no such > > thing exists with SD card IO. > > > > When this is going on, the process driving the massive output spends > > almost all its time in a wdrain wait, and if you try to launch an app > > that isn't already in cache, a siginfo generally shows it to be in a > > getblk wait. > > If your only drive is a single SD card, then you're pretty much hosed > when I/O is blocked because the SD card is doing an erase. It can only > handle one command at a time, and if a write blocks, there's nothing > that we can do to get it to execute a read until it is done with the > write command that it is hung up on. I'm not familiar with the lower > layers, but things might be less bad if read ops can jump ahead and get > sent to the drive before any queued writes. > Yes, but an erase-block operation on a nand flash takes on the order of 500uS, not 8-10 seconds, which is the kind of interactive non-responsiveness you experience in these situations. The very nature of SD cards is one operation at a time, so no internal operation queueing is in play to explain the long (apparent) hangs. I've debated playing with the bio work loop in mmcsd to see if moving reads ahead of writes was helpful, but that seems like a dangerous path to go down without some mitigation strategy to ensure that writes go through eventually. That seems especially important when you consider that writes may be necessary to free up memory to un-wedge other things that are waiting. (Yeah, people don't often use sd cards as swap storage, but I've done so in a pinch.) All in all, I've never pursued it because it feels like the wrong layer to address the problem at. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 16:04:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 83E72BC5; Tue, 5 Mar 2013 16:04:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id EF0C4AB0; Tue, 5 Mar 2013 16:04:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r25G4FqP010771; Tue, 5 Mar 2013 18:04:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r25G4FqP010771 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r25G4FfS010770; Tue, 5 Mar 2013 18:04:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Mar 2013 18:04:15 +0200 From: Konstantin Belousov To: Glen Barber Subject: Re: r247835: drm2 code breaks buildkernel Message-ID: <20130305160415.GI3794@kib.kiev.ua> References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> <20130305123016.GE1483@glenbarber.us> <5135FD78.1050608@FreeBSD.org> <20130305153736.GH3794@kib.kiev.ua> <20130305154831.GD1516@glenbarber.us> <20130305155428.GE1516@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tSiBuZsJmMXpnp7T" Content-Disposition: inline In-Reply-To: <20130305155428.GE1516@glenbarber.us> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, "J.R. Oldroyd" , Jean-S?bastien P?dron X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 16:04:19 -0000 --tSiBuZsJmMXpnp7T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 05, 2013 at 10:54:29AM -0500, Glen Barber wrote: > On Tue, Mar 05, 2013 at 10:48:31AM -0500, Glen Barber wrote: > > On Tue, Mar 05, 2013 at 05:37:36PM +0200, Konstantin Belousov wrote: > > > Glen neglected to even mention that he used gcc (is it true ?), as we= ll > > > as to show the command line invocation of the compiler. Hopefully the > > > patch helps. > >=20 > > Yes, I am using gcc. I'll try your patch and report back. > >=20 >=20 > This patch does fix the build for me. Thank you. --tSiBuZsJmMXpnp7T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRNhd+AAoJEJDCuSvBvK1BFMkP/2X8G7AAgeSNipG5nW2+shul B1ub6qYWfKivQtMdQB6Qg3FHo0IvO4Ggu1ISEzq2SIrq+lhIsl1u9IFA1dxxP/4k SWPk0dEwjGgWdsRl84AkvwMOSrkwGXibLkJI4A3A40wtCKkvKal7+IbKtFUGJKpL cr6wnAaInpduUwjn00S9LSP870CnSQh0Of9c3aZNaqaFNdZ4irMTB6HuxOIR0HaF /jrXPPD2909tDAn/2Zx6pl5Qt/nmQADNYre7dSu0QdTzy1Cc/r7+KoB3xS5/RT3F nktm+qxPofbfuoS8OFmWJ8ztXgtibXsYOrrTyK30Ov47eqWPHcsNoPMCCfmujiKi Itp11NAo7o/fO3A0FR2Mu8zTHucUjDrso6U2LpQQ64sqwp2ew3bQJ9A3Z17ppxJs +2sUI8wi2Y3PZfCP3it1YwXEUAKsgC+bopS+ACJJoiqWC/R6JSfFXcqhJSPdBR++ L1xYXvXmqbxe0DGI6M3S26wGjzFGO/TZ1WvS0BbanDXXBDpFptNK93/WMChYPJG2 J0u4q9b0kPk+2e2bNdB0aceg771LAemBwAxpE2wbyw+1tE2/Pp9za4Sh0xMeNeJJ px9vMPFT6X4/ES312Gu3H+XYAPQrkGsnm80R1f/YMMbnVD05vzHR15RzmiKDJU/d nejAE9Qcztl2diwH+B8D =pb+X -----END PGP SIGNATURE----- --tSiBuZsJmMXpnp7T-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 16:18:39 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 202D1515; Tue, 5 Mar 2013 16:18:39 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id EC8AABF3; Tue, 5 Mar 2013 16:18:38 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCuZZ-000EYe-Tu; Tue, 05 Mar 2013 16:18:38 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r25GIXEu001341; Tue, 5 Mar 2013 09:18:33 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18UCwMwZmqqhyrcs5WC9RW7 Subject: Re: access to hard drives is "blocked" by writes to a flash drive From: Ian Lepore To: Don Lewis In-Reply-To: <201303050533.r255XQbA012452@gw.catspoiler.org> References: <201303050533.r255XQbA012452@gw.catspoiler.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Mar 2013 09:18:33 -0700 Message-ID: <1362500313.1291.20.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, killing@multiplay.co.uk, peter@rulingia.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 16:18:39 -0000 On Mon, 2013-03-04 at 21:33 -0800, Don Lewis wrote: > On 4 Mar, Ian Lepore wrote: > > On Sun, 2013-03-03 at 20:28 +0000, Steven Hartland wrote: > >> ----- Original Message ----- > >> From: "Ian Lepore" > >> To: "Poul-Henning Kamp" > >> Cc: "deeptech71" ; ; "Peter Jeremy" > >> Sent: Sunday, March 03, 2013 1:54 PM > >> Subject: Re: access to hard drives is "blocked" by writes to a flash drive > >> > >> > >> > On Sun, 2013-03-03 at 13:35 +0000, Poul-Henning Kamp wrote: > >> >> Content-Type: text/plain; charset=ISO-8859-1 > >> >> -------- > >> >> In message <1362317291.1195.216.camel@revolution.hippie.lan>, Ian Lepore writes > >> >> : > >> >> > >> >> >I run into this behavior all the time too, mostly on arm systems that > >> >> >have an sd card or usb thumb driver as their main/only drive. > >> >> > >> >> This is really a FAQ and I belive I have answered it N times already: > >> >> > >> >> There are, broadly speaking, two classes of flash-storage: "Camera-grade" > >> >> and "the real thing". > >> >> > >> >> "Camera-grade" have a very limited "Flash adaptation layer" which typically > >> >> only can hold one flash-block open for writing at a time, and is typically > >> >> found in CF and SD cards, USB sticks etc. > >> >> > >> >> Some of them gets further upset if the filesystem is not the FAT they > >> >> expect, because they implement "M-Systems" (patented) trick with monitoring > >> >> block deletes in FAT to simulate a TRIM facility. > >> >> > >> >> A number of products exist with such designs, typically a CF-style, is > >> >> put behind a SATA-PATA bridge and sold as 2.5" SSD SATA devices. > >> >> "Transcend" have done this for instance. > >> >> > >> >> If you use this class of devices for anything real, gstat will show > >> >> you I/O write-times of several seconds in periodic pile-ups, even > >> >> 100 seconds if you are doing something heavy. > >> >> > >> >> For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > >> >> traffic to other disks too, when these pileups gets too bad. > >> > > >> > Hmmm, so the problem has been known and unfixed for 10 years. That's > >> > not encouraging. One of the messages in the lemming-syncer mail thread > >> > might explain why I've been seeing this a lot lately in hobbyist work, > >> > but not so much at $work where we use sd cards heavily... we use very > >> > short syncer timeouts on SD and CF storage at $work: > >> > > >> > kern.metadelay: 3 > >> > kern.dirdelay: 4 > >> > kern.filedelay: 5 > >> > > >> > I might play with similar settings on some of my arm boards here. > >> > >> Interesting, are these relevant for all filesystems e.g. ZFS? > >> > >> Regards > >> Steve > > > > I'm not sure, I know almost nothing about zfs. I do know we used those > > tunings for a specific reason and I sure wouldn't recommend them for > > general use. There's a comment block at the top of kern/vfs_subr.c with > > some information on those delay values and how they're used that you > > might find useful. I think in general such small numbers on a system > > doing lots of IO would be counter-productive. > > > > In our case we arrived at those tunings this way... We have embedded > > systems with CF and SD cards as their only mass storage, and we do a > > relatively small amount of writing to the cards (occasional config > > changes, low-volume routine logging via syslog, not much else). > > Occasionally when newsyslog kicks in there'll be a short burst of IO to > > compress and rotate, then back to a trickle again. Once upon a time we > > mounted the filesystem without softupdates and with the sync option. > > That was fairly robust against users pulling the plug right after making > > a config change, but very very slow during syslog rotation, sometimes to > > the point of peturbing our apps (the CF cards run in PIO mode, and a > > burst of PIO activity is hard on time-critical apps). > > > > So we switched using softupdates and turned off the sync option. That > > was nicer to our apps, but left a long window during which updates > > didn't get flushed to the card. So we lowered those 3 tuning values to > > the lowest numbers supported by the code (as I vaguely remember it, this > > was years ago), not to get any sort of change in performance, but to > > reduce the window during which data just sat around in memory waiting > > for potential further updates before being flushed. The further updates > > would never happen for us, so the long delays had no benefit. > > This tuning could potentially increase the amount of I/O that actually > occurs. The only advantage would be that large files that are > sequentially written would be flushed to disk more frequently but in > smaller amounts. > I don't think so, in our case. The mechanism that would trigger more IO would be the lack of opportunity to elide multiple rewrites of the same blocks that occur within the delay windows, and that situation just doesn't come up in any significant way in our products. We write to the card on the order of once every 10-180 seconds, usually 1 or 2 blocks updated, like appending a few lines to /var/log/messages or saving a 900 byte config file. About the biggest thing that ever gets written at once is the compressed output of rotating a log file, which means over the course of a second or two we write 20-50 kbytes, then go back to nothing for many seconds. In other words, the point I was trying to make was that these numbers are very much a special-case tuning based on carefully studying our situation and needs, and they are NOT good numbers to "just try" on any normal kind of system. I mentioned them in the first place only in conjuction with some idle speculation that maybe they accidentally cause better responsiveness on those systems (which is something I've noticed if I'm doing something unusual like untarring a file or other developer type stuff), and if so, maybe there's a clue there about the nature of the unresponsiveness. > To avoid the potential problem of lost config changes, could you put a > wrapper around the editor to fsync the config file? > It's not a "the editor" situation. Anything written to the sd card we want to get flushed out to the card "pretty quickly" regardless of what the source of the write is. We used to define "pretty quickly" as "mount with option sync" and then we decided that a couple seconds of latency was acceptable. Given that the write latency exists only as an opportunity for optimizations that generally just can't occur in our workload, long delays were all downside for us. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 16:40:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2F9C6F7E for ; Tue, 5 Mar 2013 16:40:41 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id DB2C3E75 for ; Tue, 5 Mar 2013 16:40:40 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UCuut-0002r7-L9; Tue, 05 Mar 2013 17:40:40 +0100 Message-ID: <51362002.2060906@dumbbell.fr> Date: Tue, 05 Mar 2013 17:40:34 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r247835: drm2 code breaks buildkernel References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> <20130305123016.GE1483@glenbarber.us> <5135FD78.1050608@FreeBSD.org> <20130305153736.GH3794@kib.kiev.ua> In-Reply-To: <20130305153736.GH3794@kib.kiev.ua> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2IRNEJGUCMNBQXJHTOPUP" Cc: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 16:40:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2IRNEJGUCMNBQXJHTOPUP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05.03.2013 16:37, Konstantin Belousov wrote: > The patch below is supposed to fix double declaration (it is pathetic t= hat > clang silently accepts this, while issuing countless useless warnings).= > Also there is a usual workaround for the anonimous union/struct issue. What do you think about "-fms-extensions"? It avoids modifications to the code and works with both gcc and clang. There're several unnamed structs/unions in the radeon code too. I would like to keep the diff with Linux code as small as possible. --=20 Jean-S=E9bastien P=E9dron ------enig2IRNEJGUCMNBQXJHTOPUP 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 Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE2IAcACgkQa+xGJsFYOlPwIQCcD56ZxWwmZJyP5Sy5QxMihPVy n+EAn0XeFqIgtqF1Py1wj2EVcll2jmg0 =GcDC -----END PGP SIGNATURE----- ------enig2IRNEJGUCMNBQXJHTOPUP-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 18:15:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C65F89C1 for ; Tue, 5 Mar 2013 18:15:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 104083C4 for ; Tue, 5 Mar 2013 18:15:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r25IFcCH034542; Tue, 5 Mar 2013 20:15:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r25IFcCH034542 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r25IFc0a034541; Tue, 5 Mar 2013 20:15:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Mar 2013 20:15:38 +0200 From: Konstantin Belousov To: Jean-S?bastien P?dron Subject: Re: r247835: drm2 code breaks buildkernel Message-ID: <20130305181538.GJ3794@kib.kiev.ua> References: <5135C70B.50906@zedat.fu-berlin.de> <5135CD0E.8040801@dumbbell.fr> <5135DE36.9010303@zedat.fu-berlin.de> <20130305123016.GE1483@glenbarber.us> <5135FD78.1050608@FreeBSD.org> <20130305153736.GH3794@kib.kiev.ua> <51362002.2060906@dumbbell.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oplxJGu+Ee5xywIT" Content-Disposition: inline In-Reply-To: <51362002.2060906@dumbbell.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:15:44 -0000 --oplxJGu+Ee5xywIT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 05, 2013 at 05:40:34PM +0100, Jean-S?bastien P?dron wrote: > On 05.03.2013 16:37, Konstantin Belousov wrote: > > The patch below is supposed to fix double declaration (it is pathetic t= hat > > clang silently accepts this, while issuing countless useless warnings). > > Also there is a usual workaround for the anonimous union/struct issue. >=20 > What do you think about "-fms-extensions"? It avoids modifications to > the code and works with both gcc and clang. Since TTM code needs a lot of modifications anyway, I do not mind to make one more local change. I already did it, please see r247849. This is IMO better then getting more unhandled warnings. >=20 > There're several unnamed structs/unions in the radeon code too. I would > like to keep the diff with Linux code as small as possible. It is your call. I am only looking after the TTM right now. --oplxJGu+Ee5xywIT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRNjZJAAoJEJDCuSvBvK1BAdkP/1oD5Sw0CIBghNCXOJ/JqLDk a77MCIw9ROQRKF5PyZ6/WBlH1D8Ihr1fkzsGQun8yHr+T0odem6sijEDf9lovLLw rjtec7wSpFwkxV3kCodqpAL4ArN+wJd2uDg8b8vW+MAYg4q0hgXWLUtAIhvsoXYx s6sCUqYfQiajDN4H2pP72Ga3/IrS6S1HmMMEzHYYVf1ScqiWE8bZ/xQiN2mCI6TI R4Lxmr+F8Bj4/opHXRwaLq/FunjaXM4HNLaAEipbR7eTegzNYxTrHnqWhykPggM/ jkDOG2b1ZWvERfc1gQzzGcpxbP8dlg7rajpE3jFEyb4WSb8cxn8vXSi+FOdPIksQ VYQlHaKJ3C3Ef7R2iRWzyuvOy5yYkmI8QCf8oU+bsoiYK97zgk26pmLeajfisUsI 2OHmJGw4cWc7ZuNnXYlidc5d373KFfEm6rTmJMzucEoDzLsjsvYTxitlvLKKXQWb GORb4t9rXkjahwgkA2xL1Ai5ioLNenv3CiwBw0/Lew8LiAXQ/It3omh7t/hqzpwQ Kb7A+Bi2T/1LYEvpjzVv9VoOAssDm2u9cH8iidJ9z2AR7UozFEsN1Ktza5B8XPir 9jfF+03eOb1vUMFwA/Ma9+DTlBu0WPVt3NyxzakblmtDhG60BKR9E7KT8BwemxIW 07v6IXa9bvHtC7cAODis =kiGj -----END PGP SIGNATURE----- --oplxJGu+Ee5xywIT-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 19:34:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 68289D8E; Tue, 5 Mar 2013 19:34:48 +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 0DE36916; Tue, 5 Mar 2013 19:34:47 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UCxdO-0008ws-VV>; Tue, 05 Mar 2013 20:34:47 +0100 Received: from e178002055.adsl.alicedsl.de ([85.178.2.55] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UCxdO-002KCY-Sv>; Tue, 05 Mar 2013 20:34:46 +0100 Message-ID: <51364914.2010104@zedat.fu-berlin.de> Date: Tue, 05 Mar 2013 20:35:48 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130216 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Current Subject: r247839: broken pipe - for top, sudo and ports References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> In-Reply-To: <5135BBD9.9090009@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.2.55 Cc: Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 19:34:48 -0000 On recent FreeBSD 10.0-CURRENT/amd64 (CLANG buildworld, serveral systems (3) the same symptoms)), many services drop a sporadic broken pipe This happesn to system's top (I have to type it several times to get finally a top), it happens to "sudo su -", it happens to SSH (drops connection with broken pipe) and as I reported earlier, it seems to affect the entire port system, since I can not build any port, I receive *** [do-extract] Signal 13 This is dramatic for me, because several modules (rtc, linux_adobe ...) can not be recompiled as it is required by the last /usr/src/UPDATING entry 20130304. Since dbus fails to start and even the nVidia driver (which is a kernel module, it canot be built and therefore ... ). Dimitry, I put you into CC, just in case. It seems that the last commits (not only the new DRM2 mess) broke something. I hope that others using FreeBSD 10.0CURRENT with CLANG can confirm this. Regards, Oliver On 03/05/13 10:33, Dimitry Andric wrote: > On 2013-03-05 10:16, Hartmann, O. wrote: >> On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I >> run into a mess and can not figure out what happens. >> >> Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 >> is without mouse. >> >> Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. >> >> This is weird. I can not extract and rebuild ports anymore, every port I >> try to rebuild with portmaster fails with the very same fault: >> >> => SHA256 Checksum OK for dbus-1.4.14.tar.gz. >> *** [do-extract] Signal 13 > > This is SIGPIPE, so maybe your tar is broken? What happens if you > manually extract that tar.gz file? From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 19:58:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D2957545; Tue, 5 Mar 2013 19:58:09 +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 96555A07; Tue, 5 Mar 2013 19:58:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UCy00-000EuV-Mb>; Tue, 05 Mar 2013 20:58:08 +0100 Received: from e178002055.adsl.alicedsl.de ([85.178.2.55] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UCy00-002LV9-Je>; Tue, 05 Mar 2013 20:58:08 +0100 Message-ID: <51364E8D.5020608@zedat.fu-berlin.de> Date: Tue, 05 Mar 2013 20:59:09 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130216 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Current Subject: Re: r247839: broken pipe - for top, sudo and ports References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> <51364914.2010104@zedat.fu-berlin.de> In-Reply-To: <51364914.2010104@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.2.55 Cc: Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 19:58:09 -0000 On 03/05/13 20:35, Hartmann, O. wrote: > On recent FreeBSD 10.0-CURRENT/amd64 (CLANG buildworld, serveral systems > (3) the same symptoms)), many services drop a sporadic > > broken pipe > > This happesn to system's top (I have to type it several times to get > finally a top), it happens to "sudo su -", it happens to SSH (drops > connection with broken pipe) and as I reported earlier, it seems to > affect the entire port system, since I can not build any port, I receive > > *** [do-extract] Signal 13 > > This is dramatic for me, because several modules (rtc, linux_adobe ...) > can not be recompiled as it is required by the last /usr/src/UPDATING > entry 20130304. > > Since dbus fails to start and even the nVidia driver (which is a kernel > module, it canot be built and therefore ... ). > > Dimitry, I put you into CC, just in case. It seems that the last commits > (not only the new DRM2 mess) broke something. > > I hope that others using FreeBSD 10.0CURRENT with CLANG can confirm this. > > Regards, > > Oliver > > On 03/05/13 10:33, Dimitry Andric wrote: >> On 2013-03-05 10:16, Hartmann, O. wrote: >>> On FreeBSD 10.0-CURRENT #3 r247829: Tue Mar 5 08:12:19 CET 2013/amd64 I >>> run into a mess and can not figure out what happens. >>> >>> Suddenly, after upgrading, buildworld etc., dbus fails to start so X11 >>> is without mouse. >>> >>> Trying to rebuild the port dbus fails in a SIGNAL 13 while [do-extract]. >>> >>> This is weird. I can not extract and rebuild ports anymore, every port I >>> try to rebuild with portmaster fails with the very same fault: >>> >>> => SHA256 Checksum OK for dbus-1.4.14.tar.gz. >>> *** [do-extract] Signal 13 >> >> This is SIGPIPE, so maybe your tar is broken? What happens if you >> manually extract that tar.gz file? A "truss top" reveals this, is this of help? [...] stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) connect(4,{ AF_UNIX "/var/run/nscd" },15) = 0 (0x0) fcntl(4,F_SETFL,O_NONBLOCK) = 0 (0x0) kqueue(0x80183b000,0x80122fc58,0x10,0x80062b308,0x80183b010,0x2) = 5 (0x5) kevent(5,{0x4,EVFILT_WRITE,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0) kqueue(0x5,0x7fffffffd2e0,0x1,0x0,0x0,0x0) = 6 (0x6) kevent(6,{0x4,EVFILT_READ,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0) kevent(5,{0x4,EVFILT_WRITE,EV_ADD,1,0x4,0x0},1,0x0,0,0x0) = 0 (0x0) kevent(5,0x0,0,{0x4,EVFILT_WRITE,EV_EOF,0,0x2000,0x0},1,0x0) = 1 (0x1) sendmsg(0x4,0x7fffffffd290,0x0,0x1,0x1,0x0) ERR#32 'Broken pipe' SIGNAL 13 (SIGPIPE) process exit, rval = 0 From owner-freebsd-current@FreeBSD.ORG Tue Mar 5 23:37:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5B06421 for ; Tue, 5 Mar 2013 23:37:08 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id B71EF337 for ; Tue, 5 Mar 2013 23:37:08 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id 16so3091011obc.5 for ; Tue, 05 Mar 2013 15:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=5qEpiz+56DY3JLvDm+QE6C8IbUHNH7tFbDi+Ah+kp+M=; b=Q5Zyg4kAyQREZ4BdsUk/JehsxQ7nlLu542ZQ99XaDgTWKBtelIqfosGcZQIp80/wm1 HQf46VG01efbXgtEmpYzlTJp8wfpcBkpQEdGtqs3B//UF/YdC1ilWgwi9C9Nw4NCpBU6 e4QzizoYVEeYf6KZVtKPqYladIFJGBbXSP73+xTgOQrWBWC5AGWwyKTxy203Ib85TocK PoEH6fohvPDVrrDGGo2Ia4JPsB1wnyWoDmJ1H8XCT0h9+vOUIB7c59OyWp+4CYbxf8lU Zbl0DykQw0mZGW3nRUKCgbd/d/Iji6q+iWmEBdMC5w9O+wkhyEeDG/rhcyKIsVUTPKFP rW0Q== MIME-Version: 1.0 X-Received: by 10.60.26.137 with SMTP id l9mr21002736oeg.17.1362526627632; Tue, 05 Mar 2013 15:37:07 -0800 (PST) Received: by 10.182.116.196 with HTTP; Tue, 5 Mar 2013 15:37:07 -0800 (PST) Date: Tue, 5 Mar 2013 18:37:07 -0500 Message-ID: Subject: Airport card is not recognized on i386 From: Super Bisquit To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 23:37:09 -0000 Why? From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 00:37:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5410A6D8 for ; Wed, 6 Mar 2013 00:37:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by mx1.freebsd.org (Postfix) with ESMTP id E6F13703 for ; Wed, 6 Mar 2013 00:37:54 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id 15so6540954wgd.4 for ; Tue, 05 Mar 2013 16:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MUTkasMLNQ8tJfBplv71g2jQaFdp3y7QhoBTvN2CIFc=; b=BctTwlqwnqjtOztDHx9D2S/l686jLNDiLvS4G22deAofymfE8vEovw7YOcXUHX3Wof cyzlVUgd6m+ueaGHxFfAxQEs5xvWhp4wQVHWeCeuFLRS2auX+i9ncMQCJvYJe9d2GxZa gJmw39uYLC5oflzCRPKCVfjm+PsJJtSASHN69xghbgc/zabOAiMkiarudShOHjukuA1r DEh1tfpPXB5P0jCMkzxi0uRB6umolkZrSC91ApdVLa+QSN6nzOS4ATVFlC8s7ni7zUVp HCXYBDBQPkaBj0jKkDlENiZmgoBLS7N0Pa5zbB/wLNwqPRoWHrMANklOr9IKSHUyt7/e 4Beg== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr22249093wib.33.1362530273852; Tue, 05 Mar 2013 16:37:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Tue, 5 Mar 2013 16:37:53 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Mar 2013 16:37:53 -0800 X-Google-Sender-Auth: mvPoVwzXdDJOrBq7gaGNfnzHe2A Message-ID: Subject: Re: Airport card is not recognized on i386 From: Adrian Chadd To: Super Bisquit Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 00:37:55 -0000 You need to provide much more information than that. Like, starting with what kind of airport card it is, what the PCI ID is, etc. Adrian From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 01:03:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5E14C3D1 for ; Wed, 6 Mar 2013 01:03:12 +0000 (UTC) (envelope-from adam.k.kirchhoff@gmail.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 0522F830 for ; Wed, 6 Mar 2013 01:03:11 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u54so7351610wey.30 for ; Tue, 05 Mar 2013 17:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=uR4ezKO1CcrldfiD4DDieNENR8EtEciOHULKFt2xA3s=; b=IUA4eEinafaJhaJP69+CsoDqn5/ih16f2r+A1SqRZ8li/BhHJlsJOIxoFdV9iKjUPE HKUEHtxGY+fDoVDD3kRK3p2cpmTmwkpKlgiQw5B7jk3IT1UJ6K4c0LO7FqMzwzSMOKPc SOzr5ovyFhGYOO9Iz0zW0hMgfg/Hbfgf//lKOQsDSf5ffyBBSB49mYE31tjBKBI+NBs5 TpeENQJFjTRH0S6M2/IfYXfzPYtbu5sLEsWlMXuI6I73YPB4hUeLMYEEQ4XyZMqop4wI KCZLfKBjsWjTX0PUhbnMBXzVE8q4deSiLPWCD5pIRBFGFG48C7HnrIMmIQ223xnNFvhm PRzA== MIME-Version: 1.0 X-Received: by 10.180.83.137 with SMTP id q9mr22645070wiy.4.1362531791273; Tue, 05 Mar 2013 17:03:11 -0800 (PST) Received: by 10.194.28.97 with HTTP; Tue, 5 Mar 2013 17:03:11 -0800 (PST) Date: Tue, 5 Mar 2013 20:03:11 -0500 Message-ID: Subject: Kernel panic on FreeBSD 10.0-CURRENT amd64 From: Adam Kirchhoff To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 01:03:12 -0000 I have recently installed 9.1 and attempted to upgrade to 10.0-CURRENT yesterday (largely in an effort to test the new radeon DRM code). Unfortunately, upon rebooting, I am left at kernel debugger prompt: cd0 at ata0 bus 0 scbus0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed panic: g_read_data(): invalid length 0 cpuid = 0 KDB: enter: panic [ thread pid 13 tid 100014 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> bt Tracing pid 13 tid 100014 td 0xfffffe0002957490 kdb_enter() at kdb_enter+0x3e/frame 0xffffff800026a960 vpanic() at vpanic+0x147/frame 0xffffff800026a9a0 kassert_panic() at kassert_panic+0x136/frame 0xffffff800026aa10 g_read_data() at g_read_data+0x45/frame 0xffffff800026aa50 g_label_ntfs_taste() at g_label_ntfs_taste+0xde/frame 0xffffff800026aa90 g_label_taste() at g_label_taste+0x37b/frame 0xffffff800026ab60 g_new_provider_event() at g_new_provider_event+0xda/frame 0xffffff800026ab80 g_run_events() at g_run_events+0x167/frame 0xffffff800026abb0 fork_exit() at fork_exit+0x84/frame 0xffffff800026abf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff800026abf0 --- trap 0, rip = 0, rsp = 0xffffff800026acb0, rbp = 0 --- I'm no expert, but it appears to be related to the NTFS partition I have on a separate hard drive. Any ideas what the problem might be or how to debug this further? Adam From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 02:04:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5CD65EFD for ; Wed, 6 Mar 2013 02:04:24 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 2CDFF9FD for ; Wed, 6 Mar 2013 02:04:24 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id dn14so3120562obc.4 for ; Tue, 05 Mar 2013 18:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y94XemlhWoTEyihTykS6V0CQqVFcigkG4vPI822rY+M=; b=ntqslv8pw3AIBmzxPppCCPGdeKYShVmjE59g8121Ok0uP7Usg/J01OrjknjaKLuioS DD2TszKrzCtTmXqJVoe9thEWXPoruSadZnxnRCyYbz+5e/2kS6d7/ns1fHEjQdz2Ecp8 9G/ye8X/O4NS9rz7mnCSftXqmCuTFAk8n2ZOY/1HtwPZ1Ja3+h2S1AOCPZWbi3sysXGK MwcvS2F/v7ynoIq5EgZBwBQ7COKpurddfteHQ8Fc5mbuTYC6z1D3hZEtYIa7hsomr0t3 LKBCtoj2eZJvkAh3FPVnUI85OUMBr12WnsWGs2sH7s/rXNHh4AtNXHRrhLFVExhL+tZO aChg== MIME-Version: 1.0 X-Received: by 10.182.139.37 with SMTP id qv5mr20587133obb.92.1362535463735; Tue, 05 Mar 2013 18:04:23 -0800 (PST) Received: by 10.76.109.236 with HTTP; Tue, 5 Mar 2013 18:04:23 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Mar 2013 21:04:23 -0500 Message-ID: Subject: Re: Kernel panic on FreeBSD 10.0-CURRENT amd64 From: Ryan Stone To: Adam Kirchhoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 02:04:24 -0000 On Tue, Mar 5, 2013 at 8:03 PM, Adam Kirchhoff wrote: > I have recently installed 9.1 and attempted to upgrade to 10.0-CURRENT > yesterday (largely in an effort to test the new radeon DRM code). > Unfortunately, upon rebooting, I am left at kernel debugger prompt: > > cd0 at ata0 bus 0 scbus0 target 1 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not > present - tray closed > panic: g_read_data(): invalid length 0 > cpuid = 0 > KDB: enter: panic > [ thread pid 13 tid 100014 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> bt > Tracing pid 13 tid 100014 td 0xfffffe0002957490 > kdb_enter() at kdb_enter+0x3e/frame 0xffffff800026a960 > vpanic() at vpanic+0x147/frame 0xffffff800026a9a0 > kassert_panic() at kassert_panic+0x136/frame 0xffffff800026aa10 > g_read_data() at g_read_data+0x45/frame 0xffffff800026aa50 > g_label_ntfs_taste() at g_label_ntfs_taste+0xde/frame 0xffffff800026aa90 > g_label_taste() at g_label_taste+0x37b/frame 0xffffff800026ab60 > g_new_provider_event() at g_new_provider_event+0xda/frame > 0xffffff800026ab80 > g_run_events() at g_run_events+0x167/frame 0xffffff800026abb0 > fork_exit() at fork_exit+0x84/frame 0xffffff800026abf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff800026abf0 > --- trap 0, rip = 0, rsp = 0xffffff800026acb0, rbp = 0 --- > > I'm no expert, but it appears to be related to the NTFS partition I > have on a separate hard drive. > > Any ideas what the problem might be or how to debug this further? > > Adam > _______________________________________________ > 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" > This sounds like something that was just fixed today. Do you have r247837? http://svnweb.freebsd.org/changeset/base/247837 From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 05:37:20 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 53EACB20; Wed, 6 Mar 2013 05:37:20 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 3A66E1E9; Wed, 6 Mar 2013 05:37:19 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r265b3Kv014960; Tue, 5 Mar 2013 21:37:07 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303060537.r265b3Kv014960@gw.catspoiler.org> Date: Tue, 5 Mar 2013 21:37:03 -0800 (PST) From: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive To: ian@FreeBSD.org In-Reply-To: <1362499296.1291.6.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Mar 2013 05:37:20 -0000 On 5 Mar, Ian Lepore wrote: > I've debated playing with the bio work loop in mmcsd to see if moving > reads ahead of writes was helpful, but that seems like a dangerous path > to go down without some mitigation strategy to ensure that writes go > through eventually. That seems especially important when you consider > that writes may be necessary to free up memory to un-wedge other things > that are waiting. (Yeah, people don't often use sd cards as swap > storage, but I've done so in a pinch.) All in all, I've never pursued > it because it feels like the wrong layer to address the problem at. I was initially concerned about the memory starvation problem, but I don't think it's an issue. If memory is unavailable, then the upper layer won't be able to allocate the buffer memory for the read requests and will block before sending any more read commands down to the driver. I think that large numbers of reads causing write starvation are also unlikely. A single thread can generate a large backlog of writes (unless the filesystem is mounted in sync mode), but it generally can't queue up a lot of reads because the thread is likely to block every time it issues a read request until it gets the data back from the drive. If you are still worried about this, you could maintain separate read and write queues and alternate between them if both are nonempty. From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 05:56:28 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B472EE5; Wed, 6 Mar 2013 05:56:28 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6F49D26E; Wed, 6 Mar 2013 05:56:28 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id D515A1A3C2A; Tue, 5 Mar 2013 21:56:27 -0800 (PST) Message-ID: <5136DA87.8050408@mu.org> Date: Tue, 05 Mar 2013 21:56:23 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Don Lewis Subject: Re: access to hard drives is "blocked" by writes to a flash drive References: <201303060537.r265b3Kv014960@gw.catspoiler.org> In-Reply-To: <201303060537.r265b3Kv014960@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: deeptech71@gmail.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, peter@rulingia.com, ian@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 05:56:28 -0000 On 3/5/13 9:37 PM, Don Lewis wrote: > On 5 Mar, Ian Lepore wrote: > >> I've debated playing with the bio work loop in mmcsd to see if moving >> reads ahead of writes was helpful, but that seems like a dangerous path >> to go down without some mitigation strategy to ensure that writes go >> through eventually. That seems especially important when you consider >> that writes may be necessary to free up memory to un-wedge other things >> that are waiting. (Yeah, people don't often use sd cards as swap >> storage, but I've done so in a pinch.) All in all, I've never pursued >> it because it feels like the wrong layer to address the problem at. > I was initially concerned about the memory starvation problem, but I > don't think it's an issue. If memory is unavailable, then the upper > layer won't be able to allocate the buffer memory for the read requests > and will block before sending any more read commands down to the driver. > > I think that large numbers of reads causing write starvation are also > unlikely. A single thread can generate a large backlog of writes > (unless the filesystem is mounted in sync mode), but it generally can't > queue up a lot of reads because the thread is likely to block every time > it issues a read request until it gets the data back from the drive. If > you are still worried about this, you could maintain separate read and > write queues and alternate between them if both are nonempty. > > What if we ran reads and writes over the loopback via TCP to get some kind of windowing? :) I am only half kidding... it would make sense to look to TCP to allow for some kind of window of IO based on throughput to the device. -Alfred From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 07:26:31 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 49F80C65; Wed, 6 Mar 2013 07:26:31 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0F23D765; Wed, 6 Mar 2013 07:26:30 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B410D89EAF; Wed, 6 Mar 2013 07:26:23 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id r267QLoX079226; Wed, 6 Mar 2013 07:26:21 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Lepore Subject: Re: access to hard drives is "blocked" by writes to a flash drive In-reply-to: <1362500313.1291.20.camel@revolution.hippie.lan> From: "Poul-Henning Kamp" References: <201303050533.r255XQbA012452@gw.catspoiler.org> <1362500313.1291.20.camel@revolution.hippie.lan> Date: Wed, 06 Mar 2013 07:26:21 +0000 Message-ID: <79225.1362554781@critter.freebsd.dk> Cc: deeptech71@gmail.com, Don Lewis , freebsd-current@FreeBSD.org, killing@multiplay.co.uk, peter@rulingia.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Mar 2013 07:26:31 -0000 Content-Type: text/plain; charset=ISO-8859-1 -------- In message <1362500313.1291.20.camel@revolution.hippie.lan>, Ian Lepore writes: >I don't think so, in our case. Have you seriously considered using msdosfs ? The cards flash-adaption-layer may work a LOT better if you do... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 10:05:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 46E14DB7; Wed, 6 Mar 2013 10:05:36 +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 E52EFE9D; Wed, 6 Mar 2013 10:05:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UDBE0-002tvV-WB>; Wed, 06 Mar 2013 11:05:29 +0100 Received: from e178016149.adsl.alicedsl.de ([85.178.16.149] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UDBE0-0035Jh-SV>; Wed, 06 Mar 2013 11:05:28 +0100 Message-ID: <51371525.4070408@zedat.fu-berlin.de> Date: Wed, 06 Mar 2013 11:06:29 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130216 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Current , freebsd-questions@freebsd.org Subject: CURRENT: "broken pipe" / SIGNAL 13 / no X11 / OpenLDAP/nscd weirdness Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.16.149 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Mar 2013 10:05:36 -0000 The most recent CURRENT (FreeBSD 10.0-CURRENT #0 r247865: Wed Mar 6 08:52:15 CET 2013/amd64, built with CLANG and CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 set in /etc/src.conf, for the record) does have some serious issues and I'm wondering why others do not. The problems I face affect ALL most recent FreeBSD CURRENT boxes. It doesn't matter whether I use my customized kernel config or GENERIC. The symptoms are weird. Using system commands like top(1) give me a "broken pipe" on the console. Repeating the command gives me then after a while top screen as expected. Services, like OpenLDAP (which I use throughout all systems with nscd and /etc/nsswitch.conf configured), nagios, hald, dbusd or starting X11, doesn't work properly: starting or not starting seems to be a statistical game. Since some kernel modifications needs recompiling ports which provides kernel modules, like emulators/virtual-box-ose-kmod x11/nvidia-driver fail with [...] *** [do-extract] Signal 13 This happens to all ports I try to compile/recompile, but sometimes, again the gamble, a simple make in the port's directory works and I can recompile. Also strange and possibly a sort of indication for the problem is the behaviour of sudo(1): hartmann@gate: [~] sudo su - Password: hartmann@gate: [~] sudo(1) does not switch to the superuser as it is expected, sometimes I receive a "broken pipe" error, sometimes it works as expected. In single user mode, I can cmpile ports without problems and I do not see this "broken pipe" issue. To be able to compile and install a port, I need to perform*** [do-extract] Signal 13 service ldconfig start which works, so all "suspicious" libraries should be loaded (as a naiv guess, I thought a miscompiled shared lib could casue the problem). Well, in general for the ports problem, the SINGLEUSER mode doesn't show the problem. The X11 system isn't starting up anymore. The problem why this doesn't work seems to "change": with sources/kernel prior or equal to r247839, dbusd couldn't start (obviously broken pipe ...). Sporadically non-working services, like slapd (OpenLDAP) seem to start after repeatedly issue "service slapd restart", but I can not reproduce by a number the failings. Sometimes the services start at boot time on a regular basis, sometimes not. For further informations of the settings: I use TEMPFS for /var/run and /tmp. This is common to all systems (but it doesn't affect single user mode, somehow). Things which do not work or solve the problem: a) use a GENERIC kernel b) avoid either in GENERIC or CUSTOM kernel CXXFLAGS+= in /etc/src.conf c) disable nscd d) recompile ports which cause trouble or tend to be highly inresponsive: openldap24-sasl-client/server, pam_ldap, nss_ldap, sudo, dbus and hal, xdm, xorg-server, virtualbox-ose-kmod I tried to recompile for now several times the whole sources with all standard setting (no custom /etc/src.conf or make.conf, also GENERIC kernel). No salvation. I also switched off SMP via setting #kern.smp.disabled=1 since this caused earlier some trouble - but this is more a desperate move to narrow down the problem a bit. I hope someone can reproduce this problem since I think I'm not the only one who is using CURRENT in a server-like multiuser/workstation environment (not only Vbox images, jails). Regards, oh From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 10:49:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94942ADD; Wed, 6 Mar 2013 10:49:52 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4F64EF4; Wed, 6 Mar 2013 10:49:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=tAQAYEVg02koOwrKlJnKERvuAHEpjqEJwR5tvv+9A4Y=; b=cX9zzBg965zk3HjU7EobP/ny6yH/vXnO3ZDlN14lSalE+mBVrrjjnjAcXI3sokd8xdUzeqwk7OAzoVqPuCK6FMVTAAmZHdd77ukCMNswrVyWzTp6fhGOJ2ZLwNOxHKJWe+CMdeUA+JLPTa6fn3TwbTVNdDpglGOcq7/RAFHSOnM=; Received: from localhost.lerctr.org ([127.0.0.1]:55686 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UDBuv-000HNw-R0; Wed, 06 Mar 2013 04:49:51 -0600 Received: from cpe-72-182-19-162.austin.res.rr.com ([72.182.19.162]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 06 Mar 2013 04:49:48 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 06 Mar 2013 04:49:48 -0600 From: Larry Rosenman To: , Subject: Fwd: Re: zfs send/recv invalid data Message-ID: <46d966dd574cd8097d4972213c73e9be@webmail.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.5 X-Spam-Score: -3.5 (---) X-LERCTR-Spam-Score: -3.5 (---) X-Spam-Report: SpamScore (-3.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.628 X-LERCTR-Spam-Report: SpamScore (-3.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.628 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Mar 2013 10:49:52 -0000 I forgot to add current/stable to the list TL;DR: there seems(!) to be something(!) unclean about an ssh path between an 8.3-STABLE(r247820) and 10.0-CURRENT(r247826) box such that a zfs send stream is corrupted in transit. below is the thread from -fs about it, with sshd configs from both sides. If I copy the stream it works, but piping through ssh does NOT. -------- Original Message -------- Subject: Re: zfs send/recv invalid data Date: 2013-03-06 04:46 From: Larry Rosenman To: Steven Hartland Cc: Ronald Klop , On 2013-03-06 02:38, Steven Hartland wrote: > ----- Original Message ----- From: "Larry Rosenman" >>>>>>>> I received an "invalid data" in a zfs send (from 8.3) / zfs >>>>>>>> recv (to 10.0) of a -R -I stream. >>>>>>>> What data do I need to gather to figure out what side and >>>>>>>> what's wrong? >>>>>>>> I've already started zpool scrubs on both sides. >>>>>>>> I can insert a tee to grab the stream on either/both sides if >>>>>>>> that would help. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Is the problem repeatable or is it just a network glitch? >>>>>>> Ronald. >>>>>> Repeatable....... >>>>> Here is the exact error message: >>>>> receiving incremental stream of vault/home/ctr@2013-03-05-test3 >>>>> into zroot/backups/TBH/home/ctr@2013-03-05-test3 >>>>> cannot receive incremental stream: invalid backup stream >>>>> this is the script I'm running: >>>>> #!/bin/sh >>>>> DATE=`date "+%Y-%m-%d-BUG-REPRO"` >>>>> DATE2=`date -v "-1d" "+%Y-%m-%d"` >>>>> # snap the source >>>>> ssh root@tbh.lerctr.org zfs snapshot -r vault@${DATE} >>>>> # zfs copy the source to here. >>>>> ssh root@tbh.lerctr.org "zfs send -R -D -I vault@${DATE2} >>>>> vault@${DATE} | \ >>>>> tee /tmp/backup.stream.send.${DATE} | \ >>>>> ssh home.lerctr.org \"tee /tmp/backup.stream.receive.${DATE} >>>>> | zfs recv -u -v -d zroot/backups/TBH\"" >>>>> # make sure we NEVER allow the backup stuff to automount. >>>>> /sbin/zfs list -H -t filesystem -r zroot/backups/TBH| \ >>>>> awk '{printf "/sbin/zfs set canmount=noauto %s\n",$1}' | sh >>>>> both streams are in http://www.lerctr.org/~ler/ZFS_RECV >>>> Your send and receive sides differ, which indicates your ssh >>>> shell my not be clean. >>>> Looking at the receive side its got what looks like a mail >>>> message appended. >>>> I suspect if you manually copy the receive copy to the 10 machine >>>> and >>>> the receive it will work fine. >>> we're copying mail files........ >>> and it still fails.... >>> >> I've put more example send/recv files in that directory. >> we're copying home dirs, which include lots of mail. >> (this one is my wife's) >> Ideas? >> I *CAN* give access to both sides via ssh..... > The copy of the data stream on both sides should be identical > though and its not, which leads me to believe something is > corrupting the data on the way. Try the following:- > >> From source:- > zfs send -R -D -I vault@${DATE2} vault@${DATE} > test.stream > scp test.stream home.lerctr.org:~/ >> From target: > zfs recv -u -v -d zroot/backups/TBH < test.stream > If this works then there is something unclean about your ssh > shell. > Regards > Steve > send side: # zfs send -R -D -I vault@2013-03-05 vault@2013-03-06 >/tmp/send.stream # openssl md5 /tmp/send.stream MD5(/tmp/send.stream)= 9cd1d73ea8411f1c222bc90e7bea3d33 # scp /tmp/send.stream home:/tmp/send.stream send.stream 100% 1180MB 2.5MB/s 07:44 # uname -a FreeBSD thebighonker.lerctr.org 8.3-STABLE FreeBSD 8.3-STABLE #54 r247820: Mon Mar 4 18:08:11 CST 2013 root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/THEBIGHONKER amd64 # Receive side: # uname -a FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #124 r247826: Mon Mar 4 19:59:08 CST 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 # openssl md5 /tmp/send.stream MD5(/tmp/send.stream)= 9cd1d73ea8411f1c222bc90e7bea3d33 # zfs recv -F -u -v -d zroot/backups/TBH < /tmp/send.stream # So, you are correct that something(tm) is unclean about the ssh path. adding -current and -stable for diagnosing ssh issue. sshd config on the 8.3-STABLE box: # cat /etc/ssh/sshd_config # $OpenBSD: sshd_config,v 1.87 2012/07/10 02:19:15 djm Exp $ # $FreeBSD: stable/8/crypto/openssh/sshd_config 247521 2013-03-01 02:06:04Z des $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. # Note that some of FreeBSD's defaults differ from OpenBSD's, and # FreeBSD has a few additional options. #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # Disable legacy (protocol version 1) support in the server for new # installations. In future the default will change to require explicit # activation of protocol 1 Protocol 2 # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 1024 # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #RSAAuthentication yes #PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys #AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # Change to yes to enable built-in password authentication. #PasswordAuthentication no #PermitEmptyPasswords no # Change to no to disable PAM authentication #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'no' to disable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. #UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation sandbox #PermitUserEnvironment no #Compression delayed ClientAliveInterval 120 ClientAliveCountMax 200000 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 #PermitTunnel no #ChrootDirectory none #VersionAddendum FreeBSD-20120901 # no default banner path #Banner none # override default of no subsystems Subsystem sftp /usr/libexec/sftp-server # Disable HPN tuning improvements. #HPNDisabled no # Buffer size for HPN to non-HPN connections. #HPNBufferSize 2048 # TCP receive socket buffer polling for HPN. Disable on non autotuning kernels. #TcpRcvBufPoll yes # Allow the use of the NONE cipher. #NoneEnabled no # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # ForceCommand cvs server # sshd config on the 10.0-CURRENT: # cat /etc/ssh/sshd_config # $OpenBSD: sshd_config,v 1.87 2012/07/10 02:19:15 djm Exp $ # $FreeBSD: head/crypto/openssh/sshd_config 240075 2012-09-03 16:51:41Z des $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. # Note that some of FreeBSD's defaults differ from OpenBSD's, and # FreeBSD has a few additional options. #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # The default requires explicit activation of protocol 1 #Protocol 2 # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 1024 # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #RSAAuthentication yes #PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # Change to yes to enable built-in password authentication. #PasswordAuthentication no #PermitEmptyPasswords no # Change to no to disable PAM authentication #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'no' to disable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. #UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation sandbox #PermitUserEnvironment no #Compression delayed ClientAliveInterval 120 ClientAliveCountMax 200000 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 #PermitTunnel no #ChrootDirectory none #VersionAddendum FreeBSD-20120901 # no default banner path #Banner none # override default of no subsystems Subsystem sftp /usr/libexec/sftp-server # Disable HPN tuning improvements. #HPNDisabled no # Buffer size for HPN to non-HPN connections. #HPNBufferSize 2048 # TCP receive socket buffer polling for HPN. Disable on non autotuning kernels. #TcpRcvBufPoll yes # Allow the use of the NONE cipher. #NoneEnabled no # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # ForceCommand cvs server # Ideas from the ssh folks? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 11:22:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 58289E82 for ; Wed, 6 Mar 2013 11:22:09 +0000 (UTC) (envelope-from adam.k.kirchhoff@gmail.com) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id D883C2AD for ; Wed, 6 Mar 2013 11:22:08 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id e12so7356277wge.10 for ; Wed, 06 Mar 2013 03:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R098PwyzEIr09+w/RtZ/EPOqVU7H8vmBAsU8DUR+xx8=; b=JPQ1g42Um/ZssGm7mTatuYibG936nAGY9rEKVCJWjyDVJ4CRJvGBEIs72I0WzBJgOk v5G0LsNNuFgS7pZJF/eH0jrVALD+Ir06nhS5ToP0KxvZSOk9FPwn/8o7ztnZCyXS+pV1 wZS+neKE0iEVvJN8iZDoHoPUY5OPKqlyiZ1rO0UPOsh/7sMkjqHVE9+dOTcoQzcgle+g hfU7QE1EqBUcJd7DbtDjrb5KOfLLjNWonPbrHxXkde51p0a6hBdYWlrARkICPe/TKy62 boX6GzSIOaN7N5iFgpAN9X7WiEvtJSJ+XQ/yciETp8JwD3qseHSkR4d6jh7XvxOSafqc xXkA== MIME-Version: 1.0 X-Received: by 10.194.20.72 with SMTP id l8mr45776085wje.36.1362568926710; Wed, 06 Mar 2013 03:22:06 -0800 (PST) Received: by 10.194.28.97 with HTTP; Wed, 6 Mar 2013 03:22:06 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Mar 2013 06:22:06 -0500 Message-ID: Subject: Re: Kernel panic on FreeBSD 10.0-CURRENT amd64 From: Adam Kirchhoff To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 11:22:09 -0000 On Tue, Mar 5, 2013 at 9:04 PM, Ryan Stone wrote: > On Tue, Mar 5, 2013 at 8:03 PM, Adam Kirchhoff > wrote: > >> I have recently installed 9.1 and attempted to upgrade to 10.0-CURRENT >> yesterday (largely in an effort to test the new radeon DRM code). >> Unfortunately, upon rebooting, I am left at kernel debugger prompt: >> >> cd0 at ata0 bus 0 scbus0 target 1 lun 0 >> cd0: Removable CD-ROM SCSI-0 device >> cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> cd0: Attempt to query device size failed: NOT READY, Medium not >> present - tray closed >> panic: g_read_data(): invalid length 0 >> cpuid = 0 >> KDB: enter: panic >> [ thread pid 13 tid 100014 ] >> Stopped at kdb_enter+0x3e: movq $0,kdb_why >> db> bt >> Tracing pid 13 tid 100014 td 0xfffffe0002957490 >> kdb_enter() at kdb_enter+0x3e/frame 0xffffff800026a960 >> vpanic() at vpanic+0x147/frame 0xffffff800026a9a0 >> kassert_panic() at kassert_panic+0x136/frame 0xffffff800026aa10 >> g_read_data() at g_read_data+0x45/frame 0xffffff800026aa50 >> g_label_ntfs_taste() at g_label_ntfs_taste+0xde/frame 0xffffff800026aa90 >> g_label_taste() at g_label_taste+0x37b/frame 0xffffff800026ab60 >> g_new_provider_event() at g_new_provider_event+0xda/frame >> 0xffffff800026ab80 >> g_run_events() at g_run_events+0x167/frame 0xffffff800026abb0 >> fork_exit() at fork_exit+0x84/frame 0xffffff800026abf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff800026abf0 >> --- trap 0, rip = 0, rsp = 0xffffff800026acb0, rbp = 0 --- >> >> I'm no expert, but it appears to be related to the NTFS partition I >> have on a separate hard drive. >> >> Any ideas what the problem might be or how to debug this further? >> >> Adam >> _______________________________________________ >> 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 >> " >> > > This sounds like something that was just fixed today. Do you have r247837? > > http://svnweb.freebsd.org/changeset/base/247837 > > No, I did not. I do now, and my computer is booting up. Thanks. Adam From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 12:29:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0825D00 for ; Wed, 6 Mar 2013 12:29:34 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id B62F57D8 for ; Wed, 6 Mar 2013 12:29:34 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a] (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 126C45C43; Wed, 6 Mar 2013 13:29:32 +0100 (CET) Message-ID: <513736AC.3030108@FreeBSD.org> Date: Wed, 06 Mar 2013 13:29:32 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Hartmann, O." , FreeBSD Current Subject: Re: r247839: broken pipe - for top, sudo and ports References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> <51364914.2010104@zedat.fu-berlin.de> <51364E8D.5020608@zedat.fu-berlin.de> In-Reply-To: <51364E8D.5020608@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:29:35 -0000 On 2013-03-05 20:59, Hartmann, O. wrote: ... > A "truss top" reveals this, is this of help? ... > socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) > connect(4,{ AF_UNIX "/var/run/nscd" },15) = 0 (0x0) > fcntl(4,F_SETFL,O_NONBLOCK) = 0 (0x0) ... > sendmsg(0x4,0x7fffffffd290,0x0,0x1,0x1,0x0) ERR#32 'Broken pipe' Maybe your nscd might have died? It is successfully opening and connecting to nscd's unix socket, but gets an EPIPE when it tries to send data. From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 12:39:39 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89238FB1 for ; Wed, 6 Mar 2013 12:39:39 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1B6859 for ; Wed, 6 Mar 2013 12:39:38 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=cKhiQyiN c=1 sm=0 a=0NJkuBbZY5VCdgJ+v5fl0w==:17 a=ACmFCPbeOMoA:10 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=56QU-hVGSpcA:10 a=LjTOzC1lAAAA:8 a=g3k24fdcAAAA:8 a=7X1wEsQV1qWHNVhEW5MA:9 a=CjuIK1q_8ugA:10 a=KmloqkfaIt8A:10 a=6k4BJ-aj_1UA:10 a=0NJkuBbZY5VCdgJ+v5fl0w==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.84.183 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.84.183] ([209.6.84.183:25019] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id F2/86-25623-80937315; Wed, 06 Mar 2013 07:39:37 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20791.14600.279902.573592@jerusalem.litteratus.org> Date: Wed, 6 Mar 2013 07:39:36 -0500 To: current@freebsd.org Subject: "make buildworld" breaks while compiling sendmail In-Reply-To: <201303051149.r25Bn4LZ022269@jerusalem.litteratus.org> References: <201303051149.r25Bn4LZ022269@jerusalem.litteratus.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: roberthuff@rcn.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Mar 2013 12:39:39 -0000 On a system running: FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012 amd64 with the source tree at r247826, "make buildworld" fails thus: cc -O -pipe -g -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include/ -DSASL=2 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/stats.c cc -O -pipe -g -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include/ -DSASL=2 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sysexits.c cc -O -pipe -g -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include/ -DSASL=2 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/timers.c cc -O -pipe -g -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include/ -DSASL=2 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/tls.c cc -O -pipe -g -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include/ -DSASL=2 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/trace.c cc -O -pipe -g -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include/ -DSASL=2 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/udb.c cc -O -pipe -g -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include/ -DSASL=2 -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1797:50: error: incompatible pointer types passing 'void ()' to parameter of type 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' [-Werror,-Wincompatible-pointer-types] smtpresult = reply(m, mci, e, TimeOuts.to_auth, getsasldata, NULL, ^~~~~~~~~~~ /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: passing argument to parameter here extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); ^ /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:136:21: note: expanded from macro '__P' #define __P(protos) protos /* full-blown ANSI C */ ^ /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1842:9: error: incompatible pointer types passing 'void ()' to parameter of type 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' [-Werror,-Wincompatible-pointer-types] getsasldata, NULL, XS_AUTH); ^~~~~~~~~~~ /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: passing argument to parameter here extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); ^ /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:136:21: note: expanded from macro '__P' #define __P(protos) protos /* full-blown ANSI C */ ^ /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: error: incompatible pointer types passing 'void ()' to parameter of type 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' [-Werror,-Wincompatible-pointer-types] getsasldata, NULL, XS_AUTH); ^~~~~~~~~~~ /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: passing argument to parameter here extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); ^ /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:136:21: note: expanded from macro '__P' #define __P(protos) protos /* full-blown ANSI C */ ^ 3 errors generated. *** [usersmtp.o] Error code 1 Stop in /usr/src/usr.sbin/sendmail. *** [all] Error code 1 There is no "src.conf"; "make.conf" is appended. Nothing in UPDATING appears applicable. I'm prepared to believe this is my fault - I just want to get things working again. Help, please? Respectfully, Robert Huff **** make.conf CFLAGS= -O -pipe -g STRIP= SYMVER_ENABLED= yes X_WINDOW_SYSTEM= xorg HAVE_MOTIF= yes KERNCONF=JERUSALEM # To avoid building various parts of the base system: # (copied from /usr/share/examples/etc/make.conf NO_BIND_ETC= true # Do not install files to /etc/namedb NO_BLUETOOTH= true # do not build Bluetooth related stuff NO_PROFILE= true # Avoid compiling profiled libraries # to get automatic SASL in sendmail SENDMAIL_CFLAGS+= -I/usr/local/include/ -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+= -lsasl2 # # to make CUPS magically keep working # See: http://www.csua.berkeley.edu/~ranga/notes/freebsd_cups.html # CUPS_OVERWRITE_BASE= yes NO_LPR= true # added per /usr/ports/UPDATING entry 20090401 OVERRIDE_LINUX_BASE_PORT=f10 OVERRIDE_LINUX_NONBASE_PORTS=f10 # WITH_MOZILLA= libxul WITH_GECKO= libxul # # added 2007/03/04 per advice of # in re science/gramps # WITH_BERKELEYDB=db43 WITH_BDB_VER=43 WANT_OPENLDAP_VER=24 WANT_OPENLDAP_SASL=true # # as required by ports/UPDATING of 20121012 # SAMBA_ENABLE=YES # # PORTS: use clang unless gcc is explicitly required # # # default to using clang for all port builds, with the following # exceptions # ports which will only build with the base system GNU compiler (4.2) # # the "make index" target also seems to need this, for some reason .if target(index) | \ ${.CURDIR:M*/devel/antlr*} | \ ${.CURDIR:M*/devel/google-perftools* } | \ ${.CURDIR:M*/graphics/ImageMagick* } | \ ${.CURDIR:M*/graphics/opencv*} | \ ${.CURDIR:M*/x11/kdelibs4*} | \ USE_GCC?=4.2 .endif # ports which need *some* version of the GNU compiler (won't build with # clang or have runtime issues if built with clang) # use the highest version of gcc we have installed from ports (4.6) .if ${.CURDIR:M*/accessibility/jovie*} | \ ${.CURDIR:M*/accessibility/kdeaccessibility4*} | \ ${.CURDIR:M*/audio/grip*} | \ ${.CURDIR:M*/audio/mpg123*} | \ ${.CURDIR:M*/audio/rosegarden*} | \ ${.CURDIR:M*/databases/virtuoso*} | \ ${.CURDIR:M*/deskutils/kdepimlibs4*} | \ ${.CURDIR:M*/devel/apache-ant*} | \ ${.CURDIR:M*/devel/icu*} | \ ${.CURDIR:M*/devel/kdevelop-kde4*} | \ ${.CURDIR:M*/devel/kdevplatform*} | \ ${.CURDIR:M*/devel/log4j*} | \ ${.CURDIR:M*/games/kdegames4*} | \ ${.CURDIR:M*/graphics/tonicpoint-viewer*} | \ ${.CURDIR:M*/java/* } | \ ${.CURDIR:M*/lang/gcc* } | \ ${.CURDIR:M*/math/fftw3*} | \ ${.CURDIR:M*/multimedia/avidemux2*} | \ ${.CURDIR:M*/multimedia/kdemultimedia4*} | \ ${.CURDIR:M*/multimedia/vlc*} | \ ${.CURDIR:M*/multimedia/xbmc*} | \ ${.CURDIR:M*/net/kdenetwork4*} | \ ${.CURDIR:M*/net/mpich2*} | \ ${.CURDIR:M*/net/opal3*} | \ ${.CURDIR:M*/net-p2p/ktorrent*} | \ ${.CURDIR:M*/net-p2p/vuze*} | \ ${.CURDIR:M*/sysutils/lsof*} | \ ${.CURDIR:M*/textproc/docbook-xsl*} | \ ${.CURDIR:M*/textproc/fop*} | \ ${.CURDIR:M*/www/libxul*} | \ ${.CURDIR:M*/x11/kde4-baseapps*} | \ ${.CURDIR:M*/x11/kde4-workspace*} | \ ${.CURDIR:M*/x11/lxpanel*} | \ USE_GCC?=4.6+ .endif .if ${.CURDIR:M*/usr/ports/*} .if !defined(USE_GCC) .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif .if !defined(CPP) || ${CPP} == "cpp" CPP=clang-cpp .endif .endif .endif WITH_NEW_XORG=yes WITH_BSD_SORT= WITH_PKGNG=yes # added by use.perl 2012-12-29 10:59:31 PERL_VERSION=5.16.2 From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 12:51:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3185C328; Wed, 6 Mar 2013 12:51:44 +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 D507D8F0; Wed, 6 Mar 2013 12:51:43 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UDDos-003ual-VE>; Wed, 06 Mar 2013 13:51:43 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UDDos-003JrF-Sp>; Wed, 06 Mar 2013 13:51:42 +0100 Message-ID: <51373BD8.1000104@zedat.fu-berlin.de> Date: Wed, 06 Mar 2013 13:51:36 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: r247839: broken pipe - for top, sudo and ports References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> <51364914.2010104@zedat.fu-berlin.de> <51364E8D.5020608@zedat.fu-berlin.de> <513736AC.3030108@FreeBSD.org> In-Reply-To: <513736AC.3030108@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ATEWQTXQAPQLEGJELDPA" X-Originating-IP: 130.133.86.198 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:51:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ATEWQTXQAPQLEGJELDPA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/06/13 13:29, Dimitry Andric wrote: > On 2013-03-05 20:59, Hartmann, O. wrote: > ... >> A "truss top" reveals this, is this of help? > ... >> socket(PF_LOCAL,SOCK_STREAM,0) =3D 4 (0x4) >> connect(4,{ AF_UNIX "/var/run/nscd" },15) =3D 0 (0x0) >> fcntl(4,F_SETFL,O_NONBLOCK) =3D 0 (0x0) > ... >> sendmsg(0x4,0x7fffffffd290,0x0,0x1,0x1,0x0) ERR#32 'Broken pipe' >=20 > Maybe your nscd might have died? It is successfully opening and > connecting to nscd's unix socket, but gets an EPIPE when it tries to > send data. I tried "service nscd stop", stopping nscd, but I guess I also have to change configuration /etc/nsswitch.conf then to make that effective. Even with stopped nscd, I have those weird and strange "broken pipes" as I reported (a little bit unsensible, I'm sorry). I use TEMPFS for /var/run, /tmp. I also use nscd, OpenLDAP. This works well with r247545, but with ~r247839 the strange behaviour occurs. My gateway system dies due loosing connection sporadically because of dying services. Could this "socket problem" also affect any kind of user verification, say, when a process starts up, but can not find its ID, like root, wheel or ldap (for OpenLDAP) or nagios? I reverted my sources to r247479 now and try to stick with those until the problem has been identified by more bright people and developers. I'm only an "advanced user", if ever, my abilities to debug are very limited and for that I'm sorry. I can only provide "detailed" reports of my desperate search for a solution. Thanks and regards, Oliver ------enig2ATEWQTXQAPQLEGJELDPA 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) iQEcBAEBAgAGBQJRNzveAAoJEOgBcD7A/5N82MEIAN5ny9Cd260zVXoav5ec4nZF 4LydsGCuaU72zO7Ilo/p9itiNFqRCAklOK0bIUMvm2uLbfY7SXGGf6cp2j7Rf7XV 32AVBFBn2voPdanvX7JVJnewKdCflM/TzJEKvrbmr2IAhgi5jVjEmVWD92aQALiG tL1GNfdK2DM2KBIWm0pTsQ2JiWhEMRaC3KKmSeL0FR4uXANrKftghiYNLBv+KG72 Gh1eei6PlS0HHoLGJfvN3JPbTrIfcAw44AN12hnx6oxV1x73efm9GPLHBOdGiJgd zJYL5bCNEZhk4Z/10OPi8XaYNHjgKpbANdFHv/QoruHpIkmU4uAcAqQqH2wDVwI= =TwKE -----END PGP SIGNATURE----- ------enig2ATEWQTXQAPQLEGJELDPA-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 15:38:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 05E89334; Wed, 6 Mar 2013 15:38:01 +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 D6EEA1B7; Wed, 6 Mar 2013 15:38:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 45058B917; Wed, 6 Mar 2013 10:38:00 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: r247839: broken pipe - for top, sudo and ports Date: Wed, 6 Mar 2013 08:04:57 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> <51364914.2010104@zedat.fu-berlin.de> In-Reply-To: <51364914.2010104@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201303060804.57238.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 06 Mar 2013 10:38:00 -0500 (EST) Cc: Dimitry Andric , "Hartmann, O." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Mar 2013 15:38:01 -0000 On Tuesday, March 05, 2013 2:35:48 pm Hartmann, O. wrote: > On recent FreeBSD 10.0-CURRENT/amd64 (CLANG buildworld, serveral systems > (3) the same symptoms)), many services drop a sporadic > > broken pipe > > This happesn to system's top (I have to type it several times to get > finally a top), it happens to "sudo su -", it happens to SSH (drops > connection with broken pipe) and as I reported earlier, it seems to > affect the entire port system, since I can not build any port, I receive > > *** [do-extract] Signal 13 > > This is dramatic for me, because several modules (rtc, linux_adobe ...) > can not be recompiled as it is required by the last /usr/src/UPDATING > entry 20130304. > > Since dbus fails to start and even the nVidia driver (which is a kernel > module, it canot be built and therefore ... ). > > Dimitry, I put you into CC, just in case. It seems that the last commits > (not only the new DRM2 mess) broke something. > > I hope that others using FreeBSD 10.0CURRENT with CLANG can confirm this.\ Have you tried backing up to just before all of pjd@'s file descriptor and capsicum commits? It broke some other stuff initially related to fd passing, so I don't think it is beyond imagination that it broke something with UNIX domain sockets in general. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 17:46:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 231B26AB; Wed, 6 Mar 2013 17:46:12 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) by mx1.freebsd.org (Postfix) with ESMTP id D1C3BA7B; Wed, 6 Mar 2013 17:46:11 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1UDIPi-0003aP-7u; Wed, 06 Mar 2013 20:46:03 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:Subject:Cc:To:From; bh=woKltlv2n9kQXaN98BMjPooXtVNxPoGkXa45xLpaxe4=; b=ZNkMrQRfeME39X+CFojDabrr+v8FixopTOqK7m9SlTC2AItmjN8aXCahugUTsOVdRC7XWtH5v0F3/lkV87dy/5PPjnRNdqjDMjmjW6vKz1Gqx8IVKX4WnCrRGId2KFzpd2CJnEtQ22l6VbN4LjHoabesQgKPwmw/2o6EUukmOjE=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1UDIMy-0007En-H6; Wed, 06 Mar 2013 17:43:14 +0000 From: Jan Beich To: "Hartmann\, O." Subject: Re: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction Date: Wed, 06 Mar 2013 08:32:48 -0900 References: <5135B7E1.3050002@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1UDIMy-0007En-H6@internal.tormail.org> Cc: Davide Italiano , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:46:12 -0000 "Hartmann, O." writes: > *** [do-extract] Signal 13 I have the same issue but it usually happens on `make install'. And reverting r247804 seems to be the workaround. Can you confirm? From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 17:49:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF1258C8; Wed, 6 Mar 2013 17:49:05 +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 7291EAAE; Wed, 6 Mar 2013 17:49:05 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UDISe-001h9J-Em>; Wed, 06 Mar 2013 18:49:04 +0100 Received: from e178036230.adsl.alicedsl.de ([85.178.36.230] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UDISe-003gic-Ax>; Wed, 06 Mar 2013 18:49:04 +0100 Message-ID: <5137818B.5020009@zedat.fu-berlin.de> Date: Wed, 06 Mar 2013 18:48:59 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: r247839: broken pipe - for top, sudo and ports References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> <51364914.2010104@zedat.fu-berlin.de> <201303060804.57238.jhb@freebsd.org> In-Reply-To: <201303060804.57238.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TQQENHDMCCPRQRLCMOCJ" X-Originating-IP: 85.178.36.230 Cc: freebsd-current@freebsd.org, Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Mar 2013 17:49:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TQQENHDMCCPRQRLCMOCJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 03/06/13 14:04, schrieb John Baldwin: > On Tuesday, March 05, 2013 2:35:48 pm Hartmann, O. wrote: >> On recent FreeBSD 10.0-CURRENT/amd64 (CLANG buildworld, serveral syste= ms >> (3) the same symptoms)), many services drop a sporadic >> >> broken pipe >> >> This happesn to system's top (I have to type it several times to get >> finally a top), it happens to "sudo su -", it happens to SSH (drops >> connection with broken pipe) and as I reported earlier, it seems to >> affect the entire port system, since I can not build any port, I recei= ve >> >> *** [do-extract] Signal 13 >> >> This is dramatic for me, because several modules (rtc, linux_adobe ...= ) >> can not be recompiled as it is required by the last /usr/src/UPDATING >> entry 20130304. >> >> Since dbus fails to start and even the nVidia driver (which is a kerne= l >> module, it canot be built and therefore ... ). >> >> Dimitry, I put you into CC, just in case. It seems that the last commi= ts >> (not only the new DRM2 mess) broke something. >> >> I hope that others using FreeBSD 10.0CURRENT with CLANG can confirm th= is.\ >=20 > Have you tried backing up to just before all of pjd@'s file descriptor = and > capsicum commits? It broke some other stuff initially related to fd pa= ssing, > so I don't think it is beyond imagination that it broke something with = UNIX > domain sockets in general. >=20 Yes, just this moment, the systems are "back" to r247479 and up and running as expected. I have also one box running a more recent r247539 or similar, but beyond that, things get really weird. As I reported, the problem isn't present in single user mode and seems to affect all of my systems which use nscd and OpenLDAP (this is standard (LDAP) in our environment). As pjd@ mentioned, things could be broken and I wait until the dust has seddled. With regards, Oliver ------enig2TQQENHDMCCPRQRLCMOCJ 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) iQEcBAEBAgAGBQJRN4GQAAoJEOgBcD7A/5N88TgH/1B7CObFRXf7kTJg63oL/Ms5 6rCTnrEIhkPiE7NNUndi2zJsi/9bZ0QLxqMRBevetgXvfIQW+4qvo4EPQKhmH3Ig eiL/EuVnacxNSh66sSlJmHubKrdo/nG1j30OlbkdS2OFKspCOqN2XmNXiyUGa6DV TGlIhOG55PnGe8DSsDOedXw2DM4ncXANTPXVYCnU1ScBgUCTDwCNoR5f3CKiYhiW lsiIuuCocg4xvuWN+zEVSkOwQHP525ma3g5ScUKtS0Yrp9Ahq9hBmGz8ySgsV9rU d9AKH/YzkM2Y4OGpOoFOzM2Rr8TBzDzK3yf18JYawwIWAJrJ44f+CdNlL5fH0XI= =ZQpP -----END PGP SIGNATURE----- ------enig2TQQENHDMCCPRQRLCMOCJ-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 17:57:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 853BCB2A; Wed, 6 Mar 2013 17:57:10 +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 48337B18; Wed, 6 Mar 2013 17:57:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UDIaT-001k9Z-AE>; Wed, 06 Mar 2013 18:57:09 +0100 Received: from e178036230.adsl.alicedsl.de ([85.178.36.230] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UDIaT-003hGt-6u>; Wed, 06 Mar 2013 18:57:09 +0100 Message-ID: <51378374.9010309@zedat.fu-berlin.de> Date: Wed, 06 Mar 2013 18:57:08 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jan Beich Subject: Re: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction References: <5135B7E1.3050002@zedat.fu-berlin.de> <1UDIMy-0007En-H6@internal.tormail.org> In-Reply-To: <1UDIMy-0007En-H6@internal.tormail.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2SQCXDXVNLDHPEVGBNHWL" X-Originating-IP: 85.178.36.230 Cc: Davide Italiano , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:57:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2SQCXDXVNLDHPEVGBNHWL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 03/06/13 18:32, schrieb Jan Beich: > "Hartmann, O." writes: >=20 >> *** [do-extract] Signal 13 >=20 > I have the same issue but it usually happens on `make install'. > And reverting r247804 seems to be the workaround. Can you confirm? I went back as far as r247479 and everything is perfect as it was. I my case, the whole OpenLDAP/nscd backend tends to go rogue. ------enig2SQCXDXVNLDHPEVGBNHWL 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) iQEcBAEBAgAGBQJRN4N0AAoJEOgBcD7A/5N8oZYH/Rqda2e2veKPYGXeoFwgHsVK Nhm5Sl6YNpyV1gtn8oEwp9SHwaOBVrz3dRqx1ioeje6JMy1moWWSkxqRV0XoGlPz QiILA1LDItO1HLtd/Ew9rpvLR9VyrEzG0Uf2x9nYQrAK3I+Wev/2NHZXF0/nmaz/ I9qdPX7g+Ax+qA7LqHQ2anPUxE8SVTh15ADo4gj4Frw4QDMF4ZCbvhu6DnDjmhbH VirGYT3DWK6TImemVEciZmU2rJr6f3sXAhcsrdPLJG04/HiVDyD5Q9XisCyLfL27 oSeVM4RT68dXjw979rouqcRt9wbnYMuAwOCpGEFx+ga3bqNVm658mF8zIhGw7K8= =3EfL -----END PGP SIGNATURE----- ------enig2SQCXDXVNLDHPEVGBNHWL-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 6 21:24:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2BA49D29; Wed, 6 Mar 2013 21:24:10 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id B7E08934; Wed, 6 Mar 2013 21:24:09 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 70BDB3592DB; Wed, 6 Mar 2013 22:24:08 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 537B32848C; Wed, 6 Mar 2013 22:24:08 +0100 (CET) Date: Wed, 6 Mar 2013 22:24:08 +0100 From: Jilles Tjoelker To: "Hartmann, O." Subject: Re: r247839: broken pipe - for top, sudo and ports Message-ID: <20130306212408.GA15814@stack.nl> References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> <51364914.2010104@zedat.fu-berlin.de> <51364E8D.5020608@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51364E8D.5020608@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 06 Mar 2013 21:24:10 -0000 On Tue, Mar 05, 2013 at 08:59:09PM +0100, Hartmann, O. wrote: > A "truss top" reveals this, is this of help? > [...] > stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- > ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) > stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- > ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) > stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- > ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) > stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- > ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) > stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- > ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) > socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) > connect(4,{ AF_UNIX "/var/run/nscd" },15) = 0 (0x0) > fcntl(4,F_SETFL,O_NONBLOCK) = 0 (0x0) > kqueue(0x80183b000,0x80122fc58,0x10,0x80062b308,0x80183b010,0x2) = 5 (0x5) > kevent(5,{0x4,EVFILT_WRITE,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0) > kqueue(0x5,0x7fffffffd2e0,0x1,0x0,0x0,0x0) = 6 (0x6) > kevent(6,{0x4,EVFILT_READ,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0) > kevent(5,{0x4,EVFILT_WRITE,EV_ADD,1,0x4,0x0},1,0x0,0,0x0) = 0 (0x0) > kevent(5,0x0,0,{0x4,EVFILT_WRITE,EV_EOF,0,0x2000,0x0},1,0x0) = 1 (0x1) > sendmsg(0x4,0x7fffffffd290,0x0,0x1,0x1,0x0) ERR#32 'Broken pipe' > SIGNAL 13 (SIGPIPE) > process exit, rval = 0 Apparently there is a bug that causes nscd to close the connection immediately but even then it is wrong that this terminates the calling program with SIGPIPE. The below patch prevents the SIGPIPE but cannot revive the connection to nscd. This may cause numeric UIDs in top or increase the load on the directory server. It is compile tested only. Index: lib/libc/net/nscachedcli.c =================================================================== --- lib/libc/net/nscachedcli.c (revision 247710) +++ lib/libc/net/nscachedcli.c (working copy) @@ -75,9 +75,9 @@ nevents = _kevent(connection->write_queue, NULL, 0, &eventlist, 1, &timeout); if ((nevents == 1) && (eventlist.filter == EVFILT_WRITE)) { - s_result = _write(connection->sockfd, data + result, + s_result = send(connection->sockfd, data + result, eventlist.data < data_size - result ? - eventlist.data : data_size - result); + eventlist.data : data_size - result, MSG_NOSIGNAL); if (s_result == -1) return (-1); else @@ -175,8 +175,8 @@ nevents = _kevent(connection->write_queue, NULL, 0, &eventlist, 1, NULL); if (nevents == 1 && eventlist.filter == EVFILT_WRITE) { - result = (_sendmsg(connection->sockfd, &cred_hdr, 0) == -1) ? - -1 : 0; + result = (_sendmsg(connection->sockfd, &cred_hdr, + MSG_NOSIGNAL) == -1) ? -1 : 0; EV_SET(&eventlist, connection->sockfd, EVFILT_WRITE, EV_ADD, 0, 0, NULL); _kevent(connection->write_queue, &eventlist, 1, NULL, 0, NULL); -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Thu Mar 7 06:38:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEFC9229; Thu, 7 Mar 2013 06:38:07 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) by mx1.freebsd.org (Postfix) with ESMTP id 5956D204; Thu, 7 Mar 2013 06:38:06 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1UDUSq-0005WK-D4; Thu, 07 Mar 2013 09:38:05 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:In-Reply-To:Subject:Cc:To:From; bh=Kh2cNLevTcjxA0SWiTcFPsqHC6Gkp4yyoNk04B8ZF4o=; b=ZvXNZC4LGMFNEBDmiFHJRMi4N3pXzb/khUWMIBDOFUsoeM6kj2idkRmR4+SgCSoUkUfgGnPQZEFtHcE0v2tSavvpL9FZJ/Mwb9xvO4Og8YhA6zTc8XL0odNPgR3bzOW37Gbu4LJQOVITBKhHm4j0GGN6HniRDSztt9IfGqtWCY8=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1UDUQ3-0009HU-83; Thu, 07 Mar 2013 06:35:13 +0000 From: Jan Beich To: Jilles Tjoelker Subject: Re: r247839: broken pipe - for top, sudo and ports In-Reply-To: <20130306212408.GA15814@stack.nl> (Jilles Tjoelker's message of "Wed, 6 Mar 2013 22:24:08 +0100") Date: Thu, 07 Mar 2013 04:54:01 -0100 References: <5135B7E1.3050002@zedat.fu-berlin.de> <5135BBD9.9090009@FreeBSD.org> <51364914.2010104@zedat.fu-berlin.de> <51364E8D.5020608@zedat.fu-berlin.de> <20130306212408.GA15814@stack.nl> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1UDUQ3-0009HU-83@internal.tormail.org> Cc: Davide Italiano , Dimitry Andric , FreeBSD Current , "Hartmann, O." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Mar 2013 06:38:07 -0000 Jilles Tjoelker writes: > On Tue, Mar 05, 2013 at 08:59:09PM +0100, Hartmann, O. wrote: > >> A "truss top" reveals this, is this of help? > >> [...] >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0) >> socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) >> connect(4,{ AF_UNIX "/var/run/nscd" },15) = 0 (0x0) >> fcntl(4,F_SETFL,O_NONBLOCK) = 0 (0x0) >> kqueue(0x80183b000,0x80122fc58,0x10,0x80062b308,0x80183b010,0x2) = 5 (0x5) >> kevent(5,{0x4,EVFILT_WRITE,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0) >> kqueue(0x5,0x7fffffffd2e0,0x1,0x0,0x0,0x0) = 6 (0x6) >> kevent(6,{0x4,EVFILT_READ,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0) >> kevent(5,{0x4,EVFILT_WRITE,EV_ADD,1,0x4,0x0},1,0x0,0,0x0) = 0 (0x0) >> kevent(5,0x0,0,{0x4,EVFILT_WRITE,EV_EOF,0,0x2000,0x0},1,0x0) = 1 (0x1) >> sendmsg(0x4,0x7fffffffd290,0x0,0x1,0x1,0x0) ERR#32 'Broken pipe' >> SIGNAL 13 (SIGPIPE) >> process exit, rval = 0 > > Apparently there is a bug that causes nscd to close the connection > immediately but even then it is wrong that this terminates the calling > program with SIGPIPE. > > The below patch prevents the SIGPIPE but cannot revive the connection to > nscd. This may cause numeric UIDs in top or increase the load on the > directory server. It is compile tested only. [...] The patch seems to fix the issue in a world after r247804. I don't see numeric UIDs in top but without the patch top crashes with SIGPIPE a lot less frequently than sudo or make install (in base/ports) for me. In my case shutting down nscd helped, too. Compared to stock nsswitch.conf I only have "cache" added. From owner-freebsd-current@FreeBSD.ORG Thu Mar 7 12:31:26 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C84E2DEF for ; Thu, 7 Mar 2013 12:31:26 +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 7AB38754 for ; Thu, 7 Mar 2013 12:31:26 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1UDZyh-002PiD-Hw>; Thu, 07 Mar 2013 13:31:19 +0100 Received: from e178002083.adsl.alicedsl.de ([85.178.2.83] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1UDZyh-000YL9-EQ>; Thu, 07 Mar 2013 13:31:19 +0100 Message-ID: <51388897.4080102@zedat.fu-berlin.de> Date: Thu, 07 Mar 2013 13:31:19 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Current FreeBSD Subject: IPFW in CURRENT: SMP-friendly? X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2PXQTJXQFJNRWAHLPOLDP" X-Originating-IP: 85.178.2.83 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 07 Mar 2013 12:31:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PXQTJXQFJNRWAHLPOLDP Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable There is work going on to move the OpenBSD pf(1) towards a more SMP friendly entity - this reduces CPU load and should raise throughput. Are there any plans for FreeBSD "native" packet filter IPFW2 to gain the same? Or, to ask it differently, IS ipfw(1), the freeBSD native packetfilter, already SMP friendly and so better suited for multicore architectures? I'm just cyrious. regards, Oliver ------enig2PXQTJXQFJNRWAHLPOLDP 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) iQEcBAEBAgAGBQJROIiXAAoJEOgBcD7A/5N80p0H/ApHsW6MrHEcAtUXdueR5ytq 7RsB84W/cEPYZOhQwmg/jQn99gN1/IKjDuMbXbdj0t7+ady9bSNC2nM+2U15V3di Z8l78ra1hKI8xkLlV7QdDgxAmrG2dzS32GYcfgS/+DO+fLjJ3BCIXEhsy2GR0YCg KRTykPzo2GPK5G++MDpvMzI/7Hljo8YzPQpWW1+Gn7OB17ua6qVpI5cSai9cIhHC pzpIGbtZLDUy7bgispRkYJ0YbwGkjGiwCsD4iCEzX8Qk02W9nUqF3j0VNwIXEXF7 PNDB4KhYoCWViQPzdmS2M5j6+SWi7jYcoK+b3a429/buUGvK/ym20kcsEUsotPs= =NBKB -----END PGP SIGNATURE----- ------enig2PXQTJXQFJNRWAHLPOLDP-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 7 15:48:35 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A24DF337 for ; Thu, 7 Mar 2013 15:48:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 31294202 for ; Thu, 7 Mar 2013 15:48:34 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r27FmSE6068638; Thu, 7 Mar 2013 19:48:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r27FmSNn068637; Thu, 7 Mar 2013 19:48:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 7 Mar 2013 19:48:28 +0400 From: Gleb Smirnoff To: "O. Hartmann" Subject: Re: IPFW in CURRENT: SMP-friendly? Message-ID: <20130307154828.GG48089@FreeBSD.org> References: <51388897.4080102@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <51388897.4080102@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 15:48:35 -0000 On Thu, Mar 07, 2013 at 01:31:19PM +0100, O. Hartmann wrote: O> There is work going on to move the OpenBSD pf(1) towards a more SMP O> friendly entity - this reduces CPU load and should raise throughput. O> O> Are there any plans for FreeBSD "native" packet filter IPFW2 to gain the O> same? Or, to ask it differently, IS ipfw(1), the freeBSD native O> packetfilter, already SMP friendly and so better suited for multicore O> architectures? Yes, it is already not under a single lock for a long time. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Thu Mar 7 16:48:30 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98843140; Thu, 7 Mar 2013 16:48:30 +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 310396A6; Thu, 7 Mar 2013 16:48:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UDdzZ-0003jF-4W>; Thu, 07 Mar 2013 17:48:29 +0100 Received: from e178002083.adsl.alicedsl.de ([85.178.2.83] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UDdzZ-000saw-0v>; Thu, 07 Mar 2013 17:48:29 +0100 Message-ID: <5138C4DC.9030209@zedat.fu-berlin.de> Date: Thu, 07 Mar 2013 17:48:28 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: IPFW in CURRENT: SMP-friendly? References: <51388897.4080102@zedat.fu-berlin.de> <20130307154828.GG48089@FreeBSD.org> In-Reply-To: <20130307154828.GG48089@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2XRGXFEGEIOABPLMTPDMK" X-Originating-IP: 85.178.2.83 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:48:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2XRGXFEGEIOABPLMTPDMK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 03/07/13 16:48, schrieb Gleb Smirnoff: > On Thu, Mar 07, 2013 at 01:31:19PM +0100, O. Hartmann wrote: > O> There is work going on to move the OpenBSD pf(1) towards a more SMP > O> friendly entity - this reduces CPU load and should raise throughput.= > O>=20 > O> Are there any plans for FreeBSD "native" packet filter IPFW2 to gain= the > O> same? Or, to ask it differently, IS ipfw(1), the freeBSD native > O> packetfilter, already SMP friendly and so better suited for multicor= e > O> architectures? >=20 > Yes, it is already not under a single lock for a long time. >=20 Thank you very much. Regards, Oliver ------enig2XRGXFEGEIOABPLMTPDMK 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) iQEcBAEBAgAGBQJROMTcAAoJEOgBcD7A/5N88vMIANRd3hErD612zGb5REQOBzjB zYI1gNGHEt/sE0H7KcX7wyqTZtFa9KlJ+fdVLz49roYwbYi9ERZugftEFZtIHIgH 2wik9ATWpXDCeDfnyTpIJCXF5z8t7HMXVgaKy599SiGShIdV68pCUVpm/mOSl+NR rN+HV/Xml6xBebDCLR+8nod37kAjLu4EVTdS2itpPGvbzRl7Npsq8iCpL/8Acar0 pLVdmg1wlKm/GbIc3vLsyrPBnp8FlNvrJnW134eeUWTiTtvdx32utTbi3znfnJ65 wR/YqGduJKHog+tf6bWluxejz/Mtf/VOd01y0yxJTfarJtJMWtM2LVhp+4s3emw= =4Rpm -----END PGP SIGNATURE----- ------enig2XRGXFEGEIOABPLMTPDMK-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 7 17:04:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 04189798 for ; Thu, 7 Mar 2013 17:04:03 +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 3B11B76A for ; Thu, 7 Mar 2013 17:04:01 +0000 (UTC) Received: (qmail 8033 invoked from network); 7 Mar 2013 18:17:28 -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 ; 7 Mar 2013 18:17:28 -0000 Message-ID: <5138C877.9060808@freebsd.org> Date: Thu, 07 Mar 2013 18:03:51 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Alan Cox Subject: Re: Cleanup and untangling of kernel VM initialization References: <510BC24D.2090406@freebsd.org> <510BF6E0.8070007@rice.edu> In-Reply-To: <510BF6E0.8070007@rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:04:03 -0000 On 01.02.2013 18:09, Alan Cox wrote: > On 02/01/2013 07:25, Andre Oppermann wrote: >> Rebase auto-sizing of limits on the available KVM/kmem_map instead of >> physical >> memory. Depending on the kernel and architecture configuration these >> two can >> be very different. >> >> Comments and reviews appreciated. >> > > I would really like to see the issues with the current auto-sizing code > addressed before any of the stylistic changes or en-masse conversions to > SYSINIT()s are considered. In particular, can we please start with the > patch that moves the pipe_map initialization? After that, I think that > we should revisit tunable_mbinit() and "maxmbufmem". OK. I'm trying to describe and explain the big picture for myself and other interested observers. The following text and explanations are going to be verbose and sometime redundant. If something is incorrect or incomplete please yell, I'm not an expert in all these parts and may easily have missed some subtle aspects. The kernel_map serves as the container of the entire available kernel VM address space, including the kernel text, data and bss itself, as well as other bootstrapped and pre-VM allocated structures. The kernel_map should cover a reasonable large amount of address space to be able to serve the various kernel subsystems demands in memory allocation. The cpu architecture's address range (32 or 64 bits) puts a hard ceiling on the total size of the kernel_map. Depending on the architecture the kernel_map covers a special range in the total addressable address range. * VM_MIN_KERNEL_ADDRESS * [KERNBASE] * kernel_map [actually mapped KVM range, direct allocations] * kernel text, data, bss * bootstrap and statically allocated structures [pmap] * virtual_avail [start of useable KVM] * kmem_map [submap for (most) UMA zones and kernel malloc] * exec_map [submap for temporary mapping during process exec()] * pipe_map [submap for temporary buffering of data between piped processes] * clean_map [submap for buffer_map and pager_map] * buffer_map [submap for BIO buffers] * pager_map [submap for temporary pager IO holding] * memguard_map [submap for debugging of UMA and kernel malloc] * ... [kernel_map direct allocations, free and unused space] * kernel_map [end of kernel_map] * ... * virtual_end [end of possible KVM] * VM_MAX_KERNEL_ADDRESS Some kernel_map's submaps are special by being non-pageable and by pre-allocating the necessary pmap structures to avoid page faults. The pre-allocation consumes physical memory. Thus a submap's pre-allocation should not be larger than a reasonable small fraction of available physical memory to leave enough space for other kernel and userspace memory demands. The pseudo-code for a dynamic calculation of a submap size would look like this: submap.size = min(physmem.size / pmap.prealloc_max_fraction / pmap.size_per_page * page_size, kernel_map.free_size) The pmap.prealloc_max_fraction is the largest fraction of physical memory we allow the pre-allocated pmap structures of a single submap to occupy. Separate submaps are usually used to segregate certain types of memory usage and to have individual limits applied to them: kmem_map: tries to be as large as possible. It serves the bulk of all dynamically allocated kernel memory usage. It is the memory pool used by UMA and kernel malloc. Almost all kernel structures come from here: process-, thread-, file descriptors, mbuf's and mbuf clusters, network connection control blocks, sockets, etc... It is not pageable. Calculation: is currently only partially done dynamically and the MD parts can specify particular min, max limits and scaling factors. It likely can be generalized and with only very special platforms requiring additional limits. exec_map: is used as temporary storage to set up a processes address space and related items. It is very small and by default contains only 16 pages. Calculation: (exec_map_entries * round_page(PATH_MAX + ARG_MAX)). pipe_map: is used to move piped data between processes. It is pageable memory. Calculation: min(physmem.size, kernel_map.size) / 64. clean_map: overarching submap to contain the buffer_map and pager_map. Likely no longer necessary and a leftover from earlier incarnations of the kernel VM. buffer_map: is used for BIO structures to perform IO between the kernel VM and storage media (disk). Not pageable. Calculation: min(physmem.size, kernel_map.size) / 4 up to 64MB and 1/10 thereafter. pager_map: is used for pager IO to a storage media (disk). Not pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256). memguard_map: is a special debugging submap substituting parts of kmem_map. Normally not used. There is some competition between these maps for physical memory. One has to be careful to find a total balance among them wrt. static and dynamic physical memory use. Within the submaps, especially the kmem_map, we have a number of dynamic UMA suballocators where we have to put a ceiling on their total memory usage to prevent them to consume all physical *and/or* kmem_map virtual memory. This is done with UMA zone limits. No externally exploitable single UMA zone should be able to consume all available physical memory. This applies for example to the number of processes, file descriptors, sockets, mbufs and mbuf clusters. These need to be limited to a reasonable and heavy work-load permitting amount of available physical memory. However there is going to be overcommit among them and not all them can be at their limit at the same time. Probably none of these UMA zones should be allowed to occupy more than 1/2 of all available physical memory. Often individual UMA zone limits have to be put into context and related to other concurrent UMA zones. This usually means reduced UMA zone limit for a particular zone. Balancing this takes a slight amount of voodoo magic and knowledge of common extreme work-loads to align. On the other hand for most of those zones allocations are permitted to fail rendering an attempt at connection establishment unsuccessful. It can be retried later. Generic pseudo-code: UMA zone limit = min(kmem_map.size, physmem.size) / 4 (or other appropriate fraction). It could be that some of the kernel_map submaps are no longer necessary and their purpose could simply be emulated by using an appropriately limited UMA zone. For example the exec_map is very small and only used for the exec arguments. Putting this into pageable memory isn't very useful anymore. Also the interesting construct of the clean_map containing only the buffer_map and pager_map doesn't seem necessary anymore and is probably remains of an earlier incarnation of the VM. Comments, discussion and additional input welcome. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Mar 7 22:49:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAE28BF6; Thu, 7 Mar 2013 22:49:20 +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 66B338E4; Thu, 7 Mar 2013 22:49:20 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r27MmxET030200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Mar 2013 23:49:00 +0100 (CET) (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 r27MmlJm045531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Mar 2013 23:48:47 +0100 (CET) (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 r27MmluN010374; Thu, 7 Mar 2013 23:48:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r27Mmj11010373; Thu, 7 Mar 2013 23:48:45 +0100 (CET) (envelope-from ticso) Date: Thu, 7 Mar 2013 23:48:45 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: access to hard drives is "blocked" by writes to a flash drive Message-ID: <20130307224845.GB8497@cicely7.cicely.de> References: <201303050527.r255R0Gd012437@gw.catspoiler.org> <1362499296.1291.6.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1362499296.1291.6.camel@revolution.hippie.lan> 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: deeptech71@gmail.com, Don Lewis , freebsd-current@freebsd.org, peter@rulingia.com, phk@phk.freebsd.dk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 07 Mar 2013 22:49:20 -0000 On Tue, Mar 05, 2013 at 09:01:36AM -0700, Ian Lepore wrote: > On Mon, 2013-03-04 at 21:27 -0800, Don Lewis wrote: > > On 4 Mar, Ian Lepore wrote: > > > On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote: > > >> On 3 Mar, Poul-Henning Kamp wrote: > > >> > > >> > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > > >> > traffic to other disks too, when these pileups gets too bad. > > >> > > >> The Lemming-syncer problem should have mostly been fixed by 231160 in > > >> head (231952 in stable/9 and 231967 in stable/8) a little over a year > > >> ago. The exceptions are atime updates, mmaped files with dirty pages, > > >> and quotas. Under certain workloads I still notice periodic bursts of > > >> seek noise. After thinking about it for a bit, I suspect that it could > > >> be atime updates, but I haven't tried to confirm that. > > >> > > >> When using TCQ or NCQ, perhaps we should limit the number of outstanding > > >> writes per device to leave some slots open for reads. We should > > >> probably also prioritize reads over writes unless we are under memory > > >> pressure. > > >> > > > > > > Then either those changes didn't have the intended effect, or the > > > problem we're seeing with lack of system responsiveness when there's a > > > large backlog of writes to a slow device is not the lemming-syncer > > > problem. It's also not a lack of TCQ/NCQ slots, given that no such > > > thing exists with SD card IO. > > > > > > When this is going on, the process driving the massive output spends > > > almost all its time in a wdrain wait, and if you try to launch an app > > > that isn't already in cache, a siginfo generally shows it to be in a > > > getblk wait. > > > > If your only drive is a single SD card, then you're pretty much hosed > > when I/O is blocked because the SD card is doing an erase. It can only > > handle one command at a time, and if a write blocks, there's nothing > > that we can do to get it to execute a read until it is done with the > > write command that it is hung up on. I'm not familiar with the lower > > layers, but things might be less bad if read ops can jump ahead and get > > sent to the drive before any queued writes. > > > > Yes, but an erase-block operation on a nand flash takes on the order of > 500uS, not 8-10 seconds, which is the kind of interactive > non-responsiveness you experience in these situations. The very nature > of SD cards is one operation at a time, so no internal operation > queueing is in play to explain the long (apparent) hangs. Values from datasheet I recently read (for an older 1G NAND chip) was 500uS for writing and 3ms for erasing - though erasing happens on larger granularities than writing. Of course a write request may include more than one flash write for bookkeeping. Nevertheless the long read starvation comes from writing multiple requests before reading. I often saw with gstat that a slowly decreasing L(q) was the situation when I was waiting for a read to complete. Since r/s never showed any other value than 0 and w/s showed small numbers during the starvation it is a clear sign that a bunch of write requests were queued handled before any read attempt. This usually happens in waves - L(q) pops high and decreases slowly to zero, while ms/w clims to multiple seconds then directly after another bunch of writes pop up. > I've debated playing with the bio work loop in mmcsd to see if moving > reads ahead of writes was helpful, but that seems like a dangerous path > to go down without some mitigation strategy to ensure that writes go > through eventually. That seems especially important when you consider > that writes may be necessary to free up memory to un-wedge other things > that are waiting. (Yeah, people don't often use sd cards as swap > storage, but I've done so in a pinch.) All in all, I've never pursued > it because it feels like the wrong layer to address the problem at. Sometimes there is no choice and you have to setup swap on SD, but there are other reasons to write on your SD card. But honestly - most of the time you get crazy when you are maintaining a system - e.g. install a package, which can't get faster anyway, but very often you want to edit configfiles at the same time. During production this rarely was an issue for me. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 02:13:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2B384945; Fri, 8 Mar 2013 02:13:46 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx1.freebsd.org (Postfix) with ESMTP id D402E137; Fri, 8 Mar 2013 02:13:45 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id kp1so922060pab.17 for ; Thu, 07 Mar 2013 18:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mQtgGiAoJBXKc1U4VJchsJtitzzOiFLUn30Rm6P+qYI=; b=UNo97NVUIrrckbC7EZ+0F1myjjkh4gzb56tJRZ/LkrLigoMTL80W/XhzcHS/biORWR xEdXLjlhpoE6YqPjdQYjwddly+3XixxlaYCFhGi8vRIuTpd+LcjUMaTNaW2OSKzUbj2k k8vv0LoNri2l1aZsxkWuV9SjB/LY4P7CAxSwbxwGGpCKh4/hLojnP+0w+1jMrAEBuVx8 CyktmLKA122brbZ5nZZqx5hoAP/qtcLeiiBu0CVpGxG86Or/L8YNVlSmXz+NSno7750q WSj2V7fx30jidCUghRbB/Ik7r8jvM5AwuAlo4A2zoyZKs/WFeOmPeOEg7lDynFgI00Ho Rrdg== X-Received: by 10.66.231.176 with SMTP id th16mr1484414pac.131.1362708825270; Thu, 07 Mar 2013 18:13:45 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id 1sm3643210pba.32.2013.03.07.18.13.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Mar 2013 18:13:43 -0800 (PST) Message-ID: <51394952.9030700@gmail.com> Date: Thu, 07 Mar 2013 18:13:38 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302271527.37079.jhb@freebsd.org> <512F5882.7080004@gmail.com> <201302281209.45170.jhb@freebsd.org> In-Reply-To: <201302281209.45170.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 02:13:46 -0000 On 02/28/13 09:09, John Baldwin wrote: > On Thursday, February 28, 2013 8:15:46 am matt wrote: >> On 02/27/13 12:27, John Baldwin wrote: >>> On Wednesday, February 27, 2013 1:35:43 pm matt wrote: >>>> On 02/27/13 09:00, John Baldwin wrote: >>>>> If that is true, it's because your BIOS is lying. Do you have a URL to >>>>> your ASL lying around already? >>>> Too big for pastebin :( +500k >>>> >>>> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing >>> Here is where I find _DOD and _DOS methods: >>> >>> Device (PCI0) >>> Device (VID) >>> Name (_ADR, 0x00020000) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices >>> Device (PEG) >>> Name (_ADR, 0x00010000) // _ADR: Address >>> Device (VID) >>> Name (_ADR, 0x00) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices >>> >>> PCI0.VID is a PCI device at pci0:0:2:0. >>> PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. >>> It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 >>> have a switchable GPU (e.g. it has built-in Intel graphics, but also has an >>> Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics >>> and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine >>> that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. >>> However, it may be that the acpi_video driver doesn't cope well with having multiple >>> devices. >> Only Intel graphics, there is no option for switchable graphics. >> I initially thought that PEG was for Optimus usage, and left in the bios >> by accident (i.e. Lenovo using a generic DSDT for many machines) >> >> Here is pciconf -lcf, truncated >> hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family DRAM Controller' >> class = bridge >> subclass = HOST-PCI >> cap 09[e0] = vendor (length 12) Intel cap 0 version 1 >> vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family Integrated >> Graphics Controller' >> class = display >> subclass = VGA >> cap 05[90] = MSI supports 1 message enabled with 1 message >> cap 01[d0] = powerspec 2 supports D0 D3 current D0 >> cap 13[a4] = PCI Advanced Features: FLR TP >> none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 >> rev=0x04 hdr=0x00 >> vendor = 'Intel Corporation' >> >> As you can see there is no device at pci0:0:1:0. So no dev_t with for >> acpi_video to probe or attach to. >> >> Nonetheless, only PEGs ACPI methods work, which is quite broken. This is >> true for a large number of Lenovo devices, back to x61 (non-attaching >> AGP adr) and probably including some other x series and t series. >> >> Unfortunately the ASL will not compile which makes fixing the DSDT an >> exercise in fixing broken ACPI. >> >> What I find interesting is that as far as I can tell, there's no special >> case handling for this device in Linux, yet backlight controls work out >> of the box since about 3.0. Installing Linux as the OSI via loader.conf >> is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows >> 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs >> _BCM... :( >> >> Is Linux getting this to work by doing it wrong, essentially? > Yes. I think the best way to fix this is to add a way to specify a > hint to override the ACPI path associated with a PCI device. Something > like: > > hw.pci0.0.2.0.handle="\_SB_.PCI0.PEG.VID" > > I think this patch should do the trick: > > Index: sys/dev/acpica/acpi_pci.c > =================================================================== > --- acpi_pci.c (revision 247320) > +++ acpi_pci.c (working copy) > @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le > return_ACPI_STATUS (AE_OK); > } > > +static void > +acpi_pci_override_handles(device_t dev) > +{ > + struct acpi_pci_devinfo *dinfo; > + device_t *devlist; > + int error, i, numdevs; > + char tunable_name[64], *path; > + ACPI_HANDLE handle; > + > + error = device_get_children(dev, &devlist, &numdevs); > + if (error) > + return; > + for (i = 0; i < numdevs; i++) { > + dinfo = device_get_ivars(devlist[i]); > + snprintf(tunable_name, sizeof(tunable_name), > + "hw.pci%d.%d.%d.%d.handle", dinfo->ap_dinfo.cfg.domain, > + dinfo->ap_dinfo.cfg.bus, dinfo->ap_dinfo.cfg.slot, > + dinfo->ap_dinfo.cfg.func); > + path = getenv(tunable_name); > + if (path == NULL) > + continue; > + if (ACPI_SUCCESS(AcpiGetHandle(NULL, path, &handle))) { > + device_printf(dev, > + "Forcing device at %d.%d to use path %s\n", > + dinfo->ap_dinfo.cfg.slot, > + dinfo->ap_dinfo.cfg.func, path); > + dinfo->ap_handle = handle; > + acpi_pci_update_device(handle, devlist[i]); > + } > + freeenv(path); > + } > + free(devlist, M_TEMP); > +} > + > static int > acpi_pci_probe(device_t dev) > { > @@ -306,5 +340,10 @@ acpi_pci_attach(device_t dev) > AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1, > acpi_pci_save_handle, NULL, dev, NULL); > > + /* > + * Perform another pass over child devices to allow their > + * handles to be overridden via a hint from the user. > + */ > + acpi_pci_override_handles(dev); > return (bus_generic_attach(dev)); > } > > I have been trying to get this patch to work. Basically I can't get a backslash into the appropriate variable, loader.conf seems to get them purged? I've tried singlequotes, double backslash, etc...every time the path variable is _SB.PCI0.PEG.VID instead of \_SB.PCI0.PEG.VID Is there a proper way to escape a backslash in loader.conf I'm missing? Matt From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 09:16:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CC7A572E; Fri, 8 Mar 2013 09:16:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 116FA2C6; Fri, 8 Mar 2013 09:16:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r289GYwH049203; Fri, 8 Mar 2013 11:16:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r289GYwH049203 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r289GYuW049202; Fri, 8 Mar 2013 11:16:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Mar 2013 11:16:34 +0200 From: Konstantin Belousov To: Andre Oppermann Subject: Re: Cleanup and untangling of kernel VM initialization Message-ID: <20130308091634.GM3794@kib.kiev.ua> References: <510BC24D.2090406@freebsd.org> <510BF6E0.8070007@rice.edu> <5138C877.9060808@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5TZBROn01cl7bgIF" Content-Disposition: inline In-Reply-To: <5138C877.9060808@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: alc@freebsd.org, freebsd-current@freebsd.org, Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Mar 2013 09:16:41 -0000 --5TZBROn01cl7bgIF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 07, 2013 at 06:03:51PM +0100, Andre Oppermann wrote: > On 01.02.2013 18:09, Alan Cox wrote: > > On 02/01/2013 07:25, Andre Oppermann wrote: > >> Rebase auto-sizing of limits on the available KVM/kmem_map instead of > >> physical > >> memory. Depending on the kernel and architecture configuration these > >> two can > >> be very different. > >> > >> Comments and reviews appreciated. > >> > > > > I would really like to see the issues with the current auto-sizing code > > addressed before any of the stylistic changes or en-masse conversions to > > SYSINIT()s are considered. In particular, can we please start with the > > patch that moves the pipe_map initialization? After that, I think that > > we should revisit tunable_mbinit() and "maxmbufmem". >=20 > OK. I'm trying to describe and explain the big picture for myself and > other interested observers. The following text and explanations are going > to be verbose and sometime redundant. If something is incorrect or incom= plete > please yell, I'm not an expert in all these parts and may easily have mis= sed > some subtle aspects. >=20 > The kernel_map serves as the container of the entire available kernel VM > address space, including the kernel text, data and bss itself, as well as > other bootstrapped and pre-VM allocated structures. >=20 > The kernel_map should cover a reasonable large amount of address space to= be > able to serve the various kernel subsystems demands in memory allocation. > The cpu architecture's address range (32 or 64 bits) puts a hard ceiling = on > the total size of the kernel_map. Depending on the architecture the kern= el_map > covers a special range in the total addressable address range. >=20 > * VM_MIN_KERNEL_ADDRESS > * [KERNBASE] > * kernel_map [actually mapped KVM range, direct allocations] > * kernel text, data, bss > * bootstrap and statically allocated structures [pmap] > * virtual_avail [start of useable KVM] > * kmem_map [submap for (most) UMA zones and kernel malloc] > * exec_map [submap for temporary mapping during process exec()] > * pipe_map [submap for temporary buffering of data between pipe= d processes] > * clean_map [submap for buffer_map and pager_map] > * buffer_map [submap for BIO buffers] > * pager_map [submap for temporary pager IO holding] > * memguard_map [submap for debugging of UMA and kernel malloc] > * ... [kernel_map direct allocations, free and unused spac= e] > * kernel_map [end of kernel_map] > * ... > * virtual_end [end of possible KVM] > * VM_MAX_KERNEL_ADDRESS >=20 > Some kernel_map's submaps are special by being non-pageable and > by pre-allocating the necessary pmap structures to avoid page > faults. The pre-allocation consumes physical memory. Thus a submap's > pre-allocation should not be larger than a reasonable small fraction > of available physical memory to leave enough space for other kernel > and userspace memory demands. Preallocation is done to ensure that calls to functions like pmap_qenter() always succeed and do not sleep for succession. >=20 > The pseudo-code for a dynamic calculation of a submap size would look lik= e this: >=20 > submap.size =3D min(physmem.size / pmap.prealloc_max_fraction / pmap.si= ze_per_page * > page_size, kernel_map.free_size) >=20 > The pmap.prealloc_max_fraction is the largest fraction of physical > memory we allow the pre-allocated pmap structures of a single submap > to occupy. > > Separate submaps are usually used to segregate certain types of memory > usage and to have individual limits applied to them: > > kmem_map: tries to be as large as possible. It serves the bulk of > all dynamically allocated kernel memory usage. It is the memory > pool used by UMA and kernel malloc. Almost all kernel structures > come from here: process-, thread-, file descriptors, mbuf's and > mbuf clusters, network connection control blocks, sockets, etc... > It is not pageable. Calculation: is currently only partially done > dynamically and the MD parts can specify particular min, max limits > and scaling factors. It likely can be generalized and with only very > special platforms requiring additional limits. > > exec_map: is used as temporary storage to set up a processes address > space and related items. It is very small and by default contains > only 16 pages. Calculation: (exec_map_entries * round_page(PATH_MAX > + ARG_MAX)). > > pipe_map: is used to move piped data between processes. It is > pageable memory. Calculation: min(physmem.size, kernel_map.size) / > 64. > > clean_map: overarching submap to contain the buffer_map and > pager_map. Likely no longer necessary and a leftover from earlier > incarnations of the kernel VM. > > buffer_map: is used for BIO structures to perform IO between the > kernel VM and storage media (disk). Not pageable. Calculation: > min(physmem.size, kernel_map.size) / 4 up to 64MB and 1/10 > thereafter. > > pager_map: is used for pager IO to a storage media (disk). Not > pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256). It is more versatile. The space is used for pbufs, and pbufs currently also serve for physio, for the clustering, for aio needs. > > memguard_map: is a special debugging submap substituting parts of=20 > kmem_map. Normally not used. > > There is some competition between these maps for physical memory. One > has to be careful to find a total balance among them wrt. static and > dynamic physical memory use. They mostly compete for KVA, not for the physical memory. > > Within the submaps, especially the kmem_map, we have a number of > dynamic UMA suballocators where we have to put a ceiling on their > total memory usage to prevent them to consume all physical *and/or* > kmem_map virtual memory. This is done with UMA zone limits. Note that architectures with the direct maps do not use kmem_map for the small allocations. The uma_small_alloc() utilizes the direct map for VA of the new page. kmem_map is needed when allocation is multi-page sized, to provide the continuous virtual mapping. > > No externally exploitable single UMA zone should be able to consume > all available physical memory. This applies for example to the > number of processes, file descriptors, sockets, mbufs and mbuf > clusters. These need to be limited to a reasonable and heavy work-load > permitting amount of available physical memory. However there is going > to be overcommit among them and not all them can be at their limit > at the same time. Probably none of these UMA zones should be allowed > to occupy more than 1/2 of all available physical memory. Often > individual UMA zone limits have to be put into context and related to > other concurrent UMA zones. This usually means reduced UMA zone limit > for a particular zone. Balancing this takes a slight amount of voodoo > magic and knowledge of common extreme work-loads to align. On the > other hand for most of those zones allocations are permitted to fail > rendering an attempt at connection establishment unsuccessful. It can > be retried later. > > Generic pseudo-code: UMA zone limit =3D min(kmem_map.size, physmem.size) > / 4 (or other appropriate fraction). > > It could be that some of the kernel_map submaps are no longer > necessary and their purpose could simply be emulated by using an > appropriately limited UMA zone. For example the exec_map is very small > and only used for the exec arguments. Putting this into pageable > memory isn't very useful anymore. I disagree. Having the strings copied on execve() pageable is good, the default size of around 260KB max for the strings is quite a load on the allocator. > > Also the interesting construct of the clean_map containing only > the buffer_map and pager_map doesn't seem necessary anymore and is > probably remains of an earlier incarnation of the VM. > > Comments, discussion and additional input welcome. > > -- Andre --5TZBROn01cl7bgIF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJROaxxAAoJEJDCuSvBvK1BrIQP/1tKAWRAk8oFDvVuW44tHBdm 6p6yXLnHjAmH3Et1oExh713at/oNcGIsXrj/7MoOQ0jGrZ3dF+dIWC3Rn+5mlyAc VqUIl/6YzKfZV2uDfbZDhqytt0wqYNo1gv5BlseTb/5/naRHt0SM7Rp+JKRRYeDI /2Gndmk8B/qJV5+ADJutOq0ri9cgBGsEV6+ZQYSphk0TpSQRv1WqVSWMwArGM8PI AUBoNiekPFg3cAbC4uYhq8ZMOQrZ4eetVt9f6rAexBqC5GCWVVcOsogeC2xYqMRd AXLfAo75XxtkjB21xUHKkhvbRfy+Zkxhb6LgOgnrK3QE5AnrFNcjWpzxnZ+2bv5g xlf3HjkAufWzEaH+IINKPI4kkjJCK/DyrwzGaf5yn926uRpf5lwcUxXTUcmoAOU5 yWFBjtRuzLt4DvMgsJfg4M7H0wSwSgVYazkDfqH3UJT4iCBe4nX5rtarUYYP7V3i nDf0nxvp6ejfNKk0wB7ABHFGQMD9aq40aie8wZ/55vdy8vpX1458DOX+PTVEQ9ev 5lWmQHRCnpEKd+AhEO1TExghCUTiCCbNR/ntT5Ta7FuTJSCZsmp8HGOqDvHkLO8u XQ4cvhQzjUvZQmyX7bPUnhXlwQ6Sq4vvKn8FGRSuJU+XuV70eN+MBqOsS2RuXF1D CLYlxpK4QaHRP1Z3b5u1 =EFZk -----END PGP SIGNATURE----- --5TZBROn01cl7bgIF-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 12:58:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 68C5D186 for ; Fri, 8 Mar 2013 12:58:49 +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 BBEC5F4B for ; Fri, 8 Mar 2013 12:58:48 +0000 (UTC) Received: (qmail 70224 invoked from network); 8 Mar 2013 14:12:05 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Mar 2013 14:12:05 -0000 Message-ID: <5139E07E.4040704@freebsd.org> Date: Fri, 08 Mar 2013 13:58:38 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Cleanup and untangling of kernel VM initialization References: <510BC24D.2090406@freebsd.org> <510BF6E0.8070007@rice.edu> <5138C877.9060808@freebsd.org> <20130308091634.GM3794@kib.kiev.ua> In-Reply-To: <20130308091634.GM3794@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org, Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Mar 2013 12:58:49 -0000 On 08.03.2013 10:16, Konstantin Belousov wrote: > On Thu, Mar 07, 2013 at 06:03:51PM +0100, Andre Oppermann wrote: >> pager_map: is used for pager IO to a storage media (disk). Not >> pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256). > > It is more versatile. The space is used for pbufs, and pbufs currently > also serve for physio, for the clustering, for aio needs. Good to know. Isn't the ceiling of MAXPHYS * 256 a bit tight then? >> memguard_map: is a special debugging submap substituting parts of >> kmem_map. Normally not used. >> >> There is some competition between these maps for physical memory. One >> has to be careful to find a total balance among them wrt. static and >> dynamic physical memory use. > > They mostly compete for KVA, not for the physical memory. Indeed. On 32bit architectures KVA usually is 1GB which is rather limited. >> Within the submaps, especially the kmem_map, we have a number of >> dynamic UMA suballocators where we have to put a ceiling on their >> total memory usage to prevent them to consume all physical *and/or* >> kmem_map virtual memory. This is done with UMA zone limits. > > Note that architectures with the direct maps do not use kmem_map for > the small allocations. The uma_small_alloc() utilizes the direct map > for VA of the new page. kmem_map is needed when allocation is multi-page > sized, to provide the continuous virtual mapping. Can you please explain the direct map some more? I haven't found any good documentation or comments on it. >> It could be that some of the kernel_map submaps are no longer >> necessary and their purpose could simply be emulated by using an >> appropriately limited UMA zone. For example the exec_map is very small >> and only used for the exec arguments. Putting this into pageable >> memory isn't very useful anymore. > > I disagree. Having the strings copied on execve() pageable is good, > the default size of around 260KB max for the strings is quite a > load on the allocator. Oops. You're right. I didn't notice how big ARG_MAX can be. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 17:58:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E9AFBEB9; Fri, 8 Mar 2013 17:58:20 +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 D211A9C1; Fri, 8 Mar 2013 17:58:20 +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 3214E24BCC; Fri, 8 Mar 2013 09:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1362765500; bh=Dn+jTQH/LGIATwl/B193zelYe/wvv+2od4ECzplXHeo=; h=Date:From:Reply-To:To:Subject; b=oD4e/WS+/PVdqD3fcdXxUd4MfO1JhMi2hGXkbHM0U//cZQuH+ExfX5qO6TflGggBL +Uyt97mLxgmCp7/PDZCvMFldouv3jPGUeL91rMF5QuY0MYC35ebQw/ThLUjTh3Ju6L GzSp6k/h7CndTH4opIj3wjiJqDtdMCMARtLOqaQ0= Message-ID: <513A26B9.7060305@delphij.net> Date: Fri, 08 Mar 2013 09:58:17 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: FreeBSD Current , Andriy Gapon Subject: FULL_PREEMPTION X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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: Fri, 08 Mar 2013 17:58:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I have seen a few posts from Andriy as as well as the PC-BSD default that for desktop systems, kern.sched.preempt_thresh=224 would improve responsiveness. Looking at the code, it seems that this is equivalent to compiling the kernel with FULL_PREEMPTION. The sys/conf/NOTES says, however: # FULL_PREEMPTION instructs the kernel to preempt non-realtime kernel # threads. Its sole use is to expose race conditions and other # bugs during development. Enabling this option will reduce # performance and increase the frequency of kernel panics by # design. If you aren't sure that you need it then you don't. # Relies on the PREEMPTION option. DON'T TURN THIS ON. Despite the possibility of exposing race conditions as well as potentially hurting throughput because of (possibly more) context switching, is it considered as a goal that we should support it? If so, should we enable it on -CURRENT? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJROia5AAoJEG80Jeu8UPuzv7MIAKoBNZyR28E5Wdnj2+IkHXvi Vg9TipTxAWSyCBcuywJEoZUCXZs1f/WbGOrbPQv0iS9AWFt9GZJ+arVsk23hwVdw kRredDAoF4kMR85wo0h8Zl04comNN+pdPNlftCGc4B6J63ysg1m7KlhUAHyXWLW9 lS7wleILiF1HRhggq7qBj4OChgbWUUgUBqf9ZMraLQMyFvfdnktE3OkDBOE1J0zu QgEdAtQ2RL5JkocsqGziq4zWKGjqM60WLQAR/5i8sCP+oQ5qRbIebUpc/GKWY7r8 mAQDwrvKU26pbHSWOkT0Qi9cXw+GGG2vTU6fLh1e0p2QBgzpyXO2TfpkL6kioQA= =xenl -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 18:42:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 42E18686; Fri, 8 Mar 2013 18:42:38 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) by mx1.freebsd.org (Postfix) with ESMTP id DADC7F09; Fri, 8 Mar 2013 18:42:37 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id r28CnKGi017780; Fri, 8 Mar 2013 12:42:31 -0600 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1axwtu0er1-1; Fri, 08 Mar 2013 12:42:31 -0600 Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 352265001C8; Fri, 8 Mar 2013 12:42:31 -0600 (CST) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 33E435001C4; Fri, 8 Mar 2013 12:42:31 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by mh2.mail.rice.edu (mh2.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id CVOBnZD-WOYo; Fri, 8 Mar 2013 12:42:31 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id A48445001BC; Fri, 8 Mar 2013 12:42:30 -0600 (CST) Message-ID: <513A3115.5060609@rice.edu> Date: Fri, 08 Mar 2013 12:42:29 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130127 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: Cleanup and untangling of kernel VM initialization References: <510BC24D.2090406@freebsd.org> <510BF6E0.8070007@rice.edu> <5138C877.9060808@freebsd.org> <20130308091634.GM3794@kib.kiev.ua> <5139E07E.4040704@freebsd.org> In-Reply-To: <5139E07E.4040704@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=5800 signatures=585085 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=3 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1111160001 definitions=main-1101130121 Cc: Konstantin Belousov , alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 18:42:38 -0000 On 03/08/2013 06:58, Andre Oppermann wrote: > On 08.03.2013 10:16, Konstantin Belousov wrote: >> On Thu, Mar 07, 2013 at 06:03:51PM +0100, Andre Oppermann wrote: >>> pager_map: is used for pager IO to a storage media (disk). Not >>> pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256). > > >> It is more versatile. The space is used for pbufs, and pbufs currently >> also serve for physio, for the clustering, for aio needs. > > Good to know. Isn't the ceiling of MAXPHYS * 256 a bit tight then? > >>> memguard_map: is a special debugging submap substituting parts of >>> kmem_map. Normally not used. >>> >>> There is some competition between these maps for physical memory. One >>> has to be careful to find a total balance among them wrt. static and >>> dynamic physical memory use. > > >> They mostly compete for KVA, not for the physical memory. > > Indeed. On 32bit architectures KVA usually is 1GB which is rather > limited. > >>> Within the submaps, especially the kmem_map, we have a number of >>> dynamic UMA suballocators where we have to put a ceiling on their >>> total memory usage to prevent them to consume all physical *and/or* >>> kmem_map virtual memory. This is done with UMA zone limits. > > >> Note that architectures with the direct maps do not use kmem_map for >> the small allocations. The uma_small_alloc() utilizes the direct map >> for VA of the new page. kmem_map is needed when allocation is multi-page >> sized, to provide the continuous virtual mapping. > > Can you please explain the direct map some more? I haven't found any > good documentation or comments on it. > Take a look at a MIPS architecture manual. Some architectures, such as MIPS, provide an alternate mechanism for virtual-to-physical address translation for use by the OS. Typically, a range of virtual addresses are reserved for this mechanism, and accesses to virtual addresses within this range bypass the usual translation process involving TLBs and page tables. Often, but not always, this range covers the entire physical memory of the machine, and both the forward mapping from virtual to physical and the inverse mapping from physical to virtual are trivially computed. Sometimes we implement a direct map in software when none exists in hardware, for example, amd64. On amd64 we use large pages, either 2MB or 1GB, to simulate a hardware-supported direct map. Even though it is not directly supported by hardware, it is nonetheless a useful optimization because it can be used in preference to creating and destroying mappings on as needed basis. >>> It could be that some of the kernel_map submaps are no longer >>> necessary and their purpose could simply be emulated by using an >>> appropriately limited UMA zone. For example the exec_map is very small >>> and only used for the exec arguments. Putting this into pageable >>> memory isn't very useful anymore. > > >> I disagree. Having the strings copied on execve() pageable is good, >> the default size of around 260KB max for the strings is quite a >> load on the allocator. > > Oops. You're right. I didn't notice how big ARG_MAX can be. > From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 18:57:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1904CD; Fri, 8 Mar 2013 18:57:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5F1771AD; Fri, 8 Mar 2013 18:57:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r28Ivk4T050654; Fri, 8 Mar 2013 20:57:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r28Ivk4T050654 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r28Ivkwu050653; Fri, 8 Mar 2013 20:57:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Mar 2013 20:57:45 +0200 From: Konstantin Belousov To: Andre Oppermann Subject: Re: Cleanup and untangling of kernel VM initialization Message-ID: <20130308185745.GV3794@kib.kiev.ua> References: <510BC24D.2090406@freebsd.org> <510BF6E0.8070007@rice.edu> <5138C877.9060808@freebsd.org> <20130308091634.GM3794@kib.kiev.ua> <5139E07E.4040704@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E/fydkOSwztHu2te" Content-Disposition: inline In-Reply-To: <5139E07E.4040704@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: alc@freebsd.org, freebsd-current@freebsd.org, Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 08 Mar 2013 18:57:52 -0000 --E/fydkOSwztHu2te Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 08, 2013 at 01:58:38PM +0100, Andre Oppermann wrote: > On 08.03.2013 10:16, Konstantin Belousov wrote: > > On Thu, Mar 07, 2013 at 06:03:51PM +0100, Andre Oppermann wrote: > >> pager_map: is used for pager IO to a storage media (disk). Not > >> pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256). > > > > It is more versatile. The space is used for pbufs, and pbufs currently > > also serve for physio, for the clustering, for aio needs. >=20 > Good to know. Isn't the ceiling of MAXPHYS * 256 a bit tight then? I doubt it. The ceiling on the amount of pbufs only limit the concurrency from the subsystems I enumerated. The pbuf allocations are sleepable (usually), so there is no correctness problem from having it sizes slightly lower then could be, and 256 parallel i/o's is good enough still. It might make sense to increase the pbuf KVA for arches with ample KVA, but it would only benefit special workloads which create lot of the concurrent i/o from the specific subsystems. E.g., the clustering cannot create more then 16MB of clusters for write, and with the default MAXPHYS of 128KB, this takes 64 pbufs. --E/fydkOSwztHu2te Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJROjSpAAoJEJDCuSvBvK1BH7AP/3AkItM7Vjp41hoN8RZqSbr6 +r6P7IF0OFdCypPx6XQs/15lPOXiRQNRcuxdXfo9oQwxO0SrzIIzSP30DVKxx6ex jibatgv+LHMQlkACnQOyktKk9DVNgWzR7KT9sKg6fUtSTHZZCMLvz2z28quUGu/Q T+gTx4CWzNQk81JkuInRWMcJXEzVLjcgHp3JkGIXocwKVq2XX/LT14/28PwpVmy6 uMQQHpW/qK2IY/VpDFVflQTM+onVLO7CUJYNAesXXo1j18mKtab/ATXa9M9oxl6Q 4U4xu0wYEFBaBRSKGVoFn0MNwBaB1pOMrvaPO/lLVkug76WsXBlx0Bji7qX74E5l EMrSq+CVV3NUMPcQQDJIpEJ6ndZb9oRu4fq1jcGpFPFc1qzO8mf8XcrIusKvpSfe WZrF9wnrbsEwutYYQspdgJXxFKfuhRWWKMCHUq8wrFVEhp/b/oh+qCW/v0snsMmG /iHpK/ZM2pzfX3x+5ncnhRc5FPoAolvZ1gujlxoIik5glAkkT9VE1kkl2VwjXpiD E5z+Ti9ckOia7ooMwinjNGDy51UWGAz95bdFAUf+0BGJb3dLJQXO6l9OP2K2OGz9 rGb0tdPwJtx5Wz2Nk/QHURF1bcnqx2KHFe8Tn+BTs6wH3URv84xSK/gXZEesWJ8B oexvUUWf5NDNcMy9lM/k =0QHV -----END PGP SIGNATURE----- --E/fydkOSwztHu2te-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 8 23:44:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2BD44FC7; Fri, 8 Mar 2013 23:44:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E1125FC0; Fri, 8 Mar 2013 23:44:05 +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 r28NhwhE097745; Fri, 8 Mar 2013 18:43:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r28Nhwii097741; Fri, 8 Mar 2013 23:43:58 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 8 Mar 2013 23:43:58 GMT Message-Id: <201303082343.r28Nhwii097741@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 23:44:06 -0000 TB --- 2013-03-08 22:23:05 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-08 22:23:05 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-08 22:23:05 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-03-08 22:23:05 - cleaning the object tree TB --- 2013-03-08 22:23:05 - /usr/local/bin/svn stat /src TB --- 2013-03-08 22:23:08 - At svn revision 248056 TB --- 2013-03-08 22:23:09 - building world TB --- 2013-03-08 22:23:09 - CROSS_BUILD_TESTING=YES TB --- 2013-03-08 22:23:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-08 22:23:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-08 22:23:09 - SRCCONF=/dev/null TB --- 2013-03-08 22:23:09 - TARGET=powerpc TB --- 2013-03-08 22:23:09 - TARGET_ARCH=powerpc64 TB --- 2013-03-08 22:23:09 - TZ=UTC TB --- 2013-03-08 22:23:09 - __MAKE_CONF=/dev/null TB --- 2013-03-08 22:23:09 - cd /src TB --- 2013-03-08 22:23:09 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 8 22:23:13 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis -I. -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LibCallAliasAnalysis.cpp -o LibCallAliasAnalysis.o c++ -O2 -pipe -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis -I. -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LibCallSemantics.cpp -o LibCallSemantics.o c++ -O2 -pipe -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis -I. -I/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/Lint.cpp -o Lint.o /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/Lint.cpp: In member function 'void::Lint::visitMemoryReference(llvm::Instruction&, llvm::Value*, uint64_t, unsigned int, llvm::Type*, unsigned int)': /src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/Lint.cpp:372: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** [Lint.o] Error code 1 Stop in /src/lib/clang/libllvmanalysis. *** [all] Error code 1 Stop in /src/lib/clang. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-08 23:43:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-08 23:43:58 - ERROR: failed to build world TB --- 2013-03-08 23:43:58 - 4062.46 user 504.28 system 4853.55 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 04:18:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 034F2270; Sat, 9 Mar 2013 04:18:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BB537A7D; Sat, 9 Mar 2013 04:18:06 +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 r294I5UI022707; Fri, 8 Mar 2013 23:18:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r294I5Tj022703; Sat, 9 Mar 2013 04:18:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Mar 2013 04:18:05 GMT Message-Id: <201303090418.r294I5Tj022703@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 04:18:07 -0000 TB --- 2013-03-09 01:30:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-09 01:30:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-09 01:30:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-09 01:30:17 - cleaning the object tree TB --- 2013-03-09 01:30:17 - /usr/local/bin/svn stat /src TB --- 2013-03-09 01:30:21 - At svn revision 248079 TB --- 2013-03-09 01:30:22 - building world TB --- 2013-03-09 01:30:22 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 01:30:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 01:30:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 01:30:22 - SRCCONF=/dev/null TB --- 2013-03-09 01:30:22 - TARGET=arm TB --- 2013-03-09 01:30:22 - TARGET_ARCH=arm TB --- 2013-03-09 01:30:22 - TZ=UTC TB --- 2013-03-09 01:30:22 - __MAKE_CONF=/dev/null TB --- 2013-03-09 01:30:22 - cd /src TB --- 2013-03-09 01:30:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 9 01:30:26 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 9 03:19:43 UTC 2013 TB --- 2013-03-09 03:19:43 - generating LINT kernel config TB --- 2013-03-09 03:19:43 - cd /src/sys/arm/conf TB --- 2013-03-09 03:19:43 - /usr/bin/make -B LINT TB --- 2013-03-09 03:19:44 - cd /src/sys/arm/conf TB --- 2013-03-09 03:19:44 - /usr/sbin/config -m LINT TB --- 2013-03-09 03:19:44 - building LINT kernel TB --- 2013-03-09 03:19:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:19:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:19:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:19:44 - SRCCONF=/dev/null TB --- 2013-03-09 03:19:44 - TARGET=arm TB --- 2013-03-09 03:19:44 - TARGET_ARCH=arm TB --- 2013-03-09 03:19:44 - TZ=UTC TB --- 2013-03-09 03:19:44 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:19:44 - cd /src TB --- 2013-03-09 03:19:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 9 03:19:44 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Mar 9 03:39:30 UTC 2013 TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m AC100 TB --- 2013-03-09 03:39:30 - skipping AC100 kernel TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m ARMADAXP TB --- 2013-03-09 03:39:30 - skipping ARMADAXP kernel TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m ATMEL TB --- 2013-03-09 03:39:30 - building ATMEL kernel TB --- 2013-03-09 03:39:30 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:39:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:39:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:39:30 - SRCCONF=/dev/null TB --- 2013-03-09 03:39:30 - TARGET=arm TB --- 2013-03-09 03:39:30 - TARGET_ARCH=arm TB --- 2013-03-09 03:39:30 - TZ=UTC TB --- 2013-03-09 03:39:30 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:39:30 - cd /src TB --- 2013-03-09 03:39:30 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Sat Mar 9 03:39:30 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Sat Mar 9 03:43:34 UTC 2013 TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m AVILA TB --- 2013-03-09 03:43:34 - skipping AVILA kernel TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-03-09 03:43:34 - skipping BEAGLEBONE kernel TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m BWCT TB --- 2013-03-09 03:43:34 - building BWCT kernel TB --- 2013-03-09 03:43:34 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:43:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:43:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:43:34 - SRCCONF=/dev/null TB --- 2013-03-09 03:43:34 - TARGET=arm TB --- 2013-03-09 03:43:34 - TARGET_ARCH=arm TB --- 2013-03-09 03:43:34 - TZ=UTC TB --- 2013-03-09 03:43:34 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:43:34 - cd /src TB --- 2013-03-09 03:43:34 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Mar 9 03:43:34 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sat Mar 9 03:45:54 UTC 2013 TB --- 2013-03-09 03:45:54 - cd /src/sys/arm/conf TB --- 2013-03-09 03:45:54 - /usr/sbin/config -m CAMBRIA TB --- 2013-03-09 03:45:54 - skipping CAMBRIA kernel TB --- 2013-03-09 03:45:54 - cd /src/sys/arm/conf TB --- 2013-03-09 03:45:54 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-03-09 03:45:54 - building CNS11XXNAS kernel TB --- 2013-03-09 03:45:54 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:45:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:45:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:45:54 - SRCCONF=/dev/null TB --- 2013-03-09 03:45:54 - TARGET=arm TB --- 2013-03-09 03:45:54 - TARGET_ARCH=arm TB --- 2013-03-09 03:45:54 - TZ=UTC TB --- 2013-03-09 03:45:54 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:45:54 - cd /src TB --- 2013-03-09 03:45:54 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Mar 9 03:45:54 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sat Mar 9 03:48:31 UTC 2013 TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m CRB TB --- 2013-03-09 03:48:31 - skipping CRB kernel TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-03-09 03:48:31 - skipping CUBIEBOARD kernel TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m DB-78XXX TB --- 2013-03-09 03:48:31 - building DB-78XXX kernel TB --- 2013-03-09 03:48:31 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:48:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:48:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:48:31 - SRCCONF=/dev/null TB --- 2013-03-09 03:48:31 - TARGET=arm TB --- 2013-03-09 03:48:31 - TARGET_ARCH=arm TB --- 2013-03-09 03:48:31 - TZ=UTC TB --- 2013-03-09 03:48:31 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:48:31 - cd /src TB --- 2013-03-09 03:48:31 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Mar 9 03:48:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sat Mar 9 03:51:23 UTC 2013 TB --- 2013-03-09 03:51:23 - cd /src/sys/arm/conf TB --- 2013-03-09 03:51:23 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-03-09 03:51:23 - building DB-88F5XXX kernel TB --- 2013-03-09 03:51:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:51:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:51:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:51:23 - SRCCONF=/dev/null TB --- 2013-03-09 03:51:23 - TARGET=arm TB --- 2013-03-09 03:51:23 - TARGET_ARCH=arm TB --- 2013-03-09 03:51:23 - TZ=UTC TB --- 2013-03-09 03:51:23 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:51:23 - cd /src TB --- 2013-03-09 03:51:23 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Mar 9 03:51:23 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sat Mar 9 03:54:06 UTC 2013 TB --- 2013-03-09 03:54:06 - cd /src/sys/arm/conf TB --- 2013-03-09 03:54:06 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-03-09 03:54:06 - building DB-88F6XXX kernel TB --- 2013-03-09 03:54:06 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:54:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:54:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:54:06 - SRCCONF=/dev/null TB --- 2013-03-09 03:54:06 - TARGET=arm TB --- 2013-03-09 03:54:06 - TARGET_ARCH=arm TB --- 2013-03-09 03:54:06 - TZ=UTC TB --- 2013-03-09 03:54:06 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:54:06 - cd /src TB --- 2013-03-09 03:54:06 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Mar 9 03:54:06 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sat Mar 9 03:57:03 UTC 2013 TB --- 2013-03-09 03:57:03 - cd /src/sys/arm/conf TB --- 2013-03-09 03:57:03 - /usr/sbin/config -m DOCKSTAR TB --- 2013-03-09 03:57:03 - building DOCKSTAR kernel TB --- 2013-03-09 03:57:03 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:57:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:57:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:57:03 - SRCCONF=/dev/null TB --- 2013-03-09 03:57:03 - TARGET=arm TB --- 2013-03-09 03:57:03 - TARGET_ARCH=arm TB --- 2013-03-09 03:57:03 - TZ=UTC TB --- 2013-03-09 03:57:03 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:57:03 - cd /src TB --- 2013-03-09 03:57:03 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Mar 9 03:57:03 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sat Mar 9 03:59:44 UTC 2013 TB --- 2013-03-09 03:59:44 - cd /src/sys/arm/conf TB --- 2013-03-09 03:59:44 - /usr/sbin/config -m DREAMPLUG-1001 TB --- 2013-03-09 03:59:44 - building DREAMPLUG-1001 kernel TB --- 2013-03-09 03:59:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:59:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:59:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:59:44 - SRCCONF=/dev/null TB --- 2013-03-09 03:59:44 - TARGET=arm TB --- 2013-03-09 03:59:44 - TARGET_ARCH=arm TB --- 2013-03-09 03:59:44 - TZ=UTC TB --- 2013-03-09 03:59:44 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:59:44 - cd /src TB --- 2013-03-09 03:59:44 - /usr/bin/make -B buildkernel KERNCONF=DREAMPLUG-1001 >>> Kernel build for DREAMPLUG-1001 started on Sat Mar 9 03:59:44 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DREAMPLUG-1001 completed on Sat Mar 9 04:03:34 UTC 2013 TB --- 2013-03-09 04:03:34 - cd /src/sys/arm/conf TB --- 2013-03-09 04:03:34 - /usr/sbin/config -m EA3250 TB --- 2013-03-09 04:03:34 - building EA3250 kernel TB --- 2013-03-09 04:03:34 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 04:03:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 04:03:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 04:03:34 - SRCCONF=/dev/null TB --- 2013-03-09 04:03:34 - TARGET=arm TB --- 2013-03-09 04:03:34 - TARGET_ARCH=arm TB --- 2013-03-09 04:03:34 - TZ=UTC TB --- 2013-03-09 04:03:34 - __MAKE_CONF=/dev/null TB --- 2013-03-09 04:03:34 - cd /src TB --- 2013-03-09 04:03:34 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Sat Mar 9 04:03:34 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Sat Mar 9 04:06:20 UTC 2013 TB --- 2013-03-09 04:06:20 - cd /src/sys/arm/conf TB --- 2013-03-09 04:06:20 - /usr/sbin/config -m EB9200 TB --- 2013-03-09 04:06:20 - building EB9200 kernel TB --- 2013-03-09 04:06:20 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 04:06:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 04:06:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 04:06:20 - SRCCONF=/dev/null TB --- 2013-03-09 04:06:20 - TARGET=arm TB --- 2013-03-09 04:06:20 - TARGET_ARCH=arm TB --- 2013-03-09 04:06:20 - TZ=UTC TB --- 2013-03-09 04:06:20 - __MAKE_CONF=/dev/null TB --- 2013-03-09 04:06:20 - cd /src TB --- 2013-03-09 04:06:20 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Sat Mar 9 04:06:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EB9200 completed on Sat Mar 9 04:08:52 UTC 2013 TB --- 2013-03-09 04:08:52 - cd /src/sys/arm/conf TB --- 2013-03-09 04:08:52 - /usr/sbin/config -m EP80219 TB --- 2013-03-09 04:08:52 - skipping EP80219 kernel TB --- 2013-03-09 04:08:52 - cd /src/sys/arm/conf TB --- 2013-03-09 04:08:52 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-03-09 04:08:52 - building ETHERNUT5 kernel TB --- 2013-03-09 04:08:52 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 04:08:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 04:08:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 04:08:52 - SRCCONF=/dev/null TB --- 2013-03-09 04:08:52 - TARGET=arm TB --- 2013-03-09 04:08:52 - TARGET_ARCH=arm TB --- 2013-03-09 04:08:52 - TZ=UTC TB --- 2013-03-09 04:08:52 - __MAKE_CONF=/dev/null TB --- 2013-03-09 04:08:52 - cd /src TB --- 2013-03-09 04:08:52 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sat Mar 9 04:08:52 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c cc1: warnings being treated as errors /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_recv_indiv_data_to_fwrd': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1480: warning: unused variable 'ic' [-Wunused-variable] /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_recv_indiv_data_to_me': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1539: warning: unused variable 'ic' [-Wunused-variable] /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_recv_group_data': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1606: warning: unused variable 'ic' [-Wunused-variable] *** [ieee80211_mesh.o] Error code 1 Stop in /src/sys/modules/wlan. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-09 04:18:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-09 04:18:05 - ERROR: failed to build ETHERNUT5 kernel TB --- 2013-03-09 04:18:05 - 8057.57 user 1463.77 system 10068.22 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 05:20:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A9DEA835; Sat, 9 Mar 2013 05:20:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id E8B93BE6; Sat, 9 Mar 2013 05:20:41 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id t57so1820493wey.13 for ; Fri, 08 Mar 2013 21:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0wlamhaPCHBS9s5gZptoYfVhUSkS8wpJq18CorU7jkQ=; b=scshIyB7k49iquvT04IHeNWUqFVTXY3BMhl4oEbV3hRTEzrkteHP1JqzxAL/pBky5p g/qsxo0JU3XL9E+kobPYQiRUUz+GWSI1t8NP/10+dIiGFPVsCN4PbYnOS36iy7XE9f6G D9R3KtRtHHfCIbCi545aSIjhD7PGMeOXr4+cvWs6TqJIl45FBNxL0IcNsEAktsQLCnvr JnDNhNGuBYt38+cJm0gk3Ti64iwiDFt27PJuLmP50XkqE8LpzwBGES8VMDradhGT/BgD 9pIwwS0zeNwR7RyaNfvIQtZgo88CItkaRI6R7AtwVPh2snuOND1/Un2ctkZMNYHxJZU4 CWtQ== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr8280151wjc.39.1362806439784; Fri, 08 Mar 2013 21:20:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.51.2 with HTTP; Fri, 8 Mar 2013 21:20:39 -0800 (PST) In-Reply-To: <201303090418.r294I5Tj022703@freebsd-current.sentex.ca> References: <201303090418.r294I5Tj022703@freebsd-current.sentex.ca> Date: Fri, 8 Mar 2013 21:20:39 -0800 X-Google-Sender-Auth: Q7vRNvpVcWq-Of_BJGjwD2ZGboc Message-ID: Subject: Re: [head tinderbox] failure on arm/arm From: Adrian Chadd To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 05:20:42 -0000 Fixed! Adrian On 8 March 2013 20:18, FreeBSD Tinderbox wrote: > TB --- 2013-03-09 01:30:17 - tinderbox 2.10 running on freebsd-current.se= ntex.ca > TB --- 2013-03-09 01:30:17 - FreeBSD freebsd-current.sentex.ca 8.3-PREREL= EASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebs= d-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2013-03-09 01:30:17 - starting HEAD tinderbox run for arm/arm > TB --- 2013-03-09 01:30:17 - cleaning the object tree > TB --- 2013-03-09 01:30:17 - /usr/local/bin/svn stat /src > TB --- 2013-03-09 01:30:21 - At svn revision 248079 > TB --- 2013-03-09 01:30:22 - building world > TB --- 2013-03-09 01:30:22 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 01:30:22 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 01:30:22 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 01:30:22 - SRCCONF=3D/dev/null > TB --- 2013-03-09 01:30:22 - TARGET=3Darm > TB --- 2013-03-09 01:30:22 - TARGET_ARCH=3Darm > TB --- 2013-03-09 01:30:22 - TZ=3DUTC > TB --- 2013-03-09 01:30:22 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 01:30:22 - cd /src > TB --- 2013-03-09 01:30:22 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Sat Mar 9 01:30:26 UTC 2013 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> World build completed on Sat Mar 9 03:19:43 UTC 2013 > TB --- 2013-03-09 03:19:43 - generating LINT kernel config > TB --- 2013-03-09 03:19:43 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:19:43 - /usr/bin/make -B LINT > TB --- 2013-03-09 03:19:44 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:19:44 - /usr/sbin/config -m LINT > TB --- 2013-03-09 03:19:44 - building LINT kernel > TB --- 2013-03-09 03:19:44 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:19:44 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:19:44 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:19:44 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:19:44 - TARGET=3Darm > TB --- 2013-03-09 03:19:44 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:19:44 - TZ=3DUTC > TB --- 2013-03-09 03:19:44 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:19:44 - cd /src > TB --- 2013-03-09 03:19:44 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Sat Mar 9 03:19:44 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for LINT completed on Sat Mar 9 03:39:30 UTC 2013 > TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m AC100 > TB --- 2013-03-09 03:39:30 - skipping AC100 kernel > TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m ARMADAXP > TB --- 2013-03-09 03:39:30 - skipping ARMADAXP kernel > TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m ATMEL > TB --- 2013-03-09 03:39:30 - building ATMEL kernel > TB --- 2013-03-09 03:39:30 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:39:30 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:39:30 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:39:30 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:39:30 - TARGET=3Darm > TB --- 2013-03-09 03:39:30 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:39:30 - TZ=3DUTC > TB --- 2013-03-09 03:39:30 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:39:30 - cd /src > TB --- 2013-03-09 03:39:30 - /usr/bin/make -B buildkernel KERNCONF=3DATME= L >>>> Kernel build for ATMEL started on Sat Mar 9 03:39:30 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for ATMEL completed on Sat Mar 9 03:43:34 UTC 2013 > TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m AVILA > TB --- 2013-03-09 03:43:34 - skipping AVILA kernel > TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m BEAGLEBONE > TB --- 2013-03-09 03:43:34 - skipping BEAGLEBONE kernel > TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m BWCT > TB --- 2013-03-09 03:43:34 - building BWCT kernel > TB --- 2013-03-09 03:43:34 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:43:34 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:43:34 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:43:34 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:43:34 - TARGET=3Darm > TB --- 2013-03-09 03:43:34 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:43:34 - TZ=3DUTC > TB --- 2013-03-09 03:43:34 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:43:34 - cd /src > TB --- 2013-03-09 03:43:34 - /usr/bin/make -B buildkernel KERNCONF=3DBWCT >>>> Kernel build for BWCT started on Sat Mar 9 03:43:34 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for BWCT completed on Sat Mar 9 03:45:54 UTC 2013 > TB --- 2013-03-09 03:45:54 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:45:54 - /usr/sbin/config -m CAMBRIA > TB --- 2013-03-09 03:45:54 - skipping CAMBRIA kernel > TB --- 2013-03-09 03:45:54 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:45:54 - /usr/sbin/config -m CNS11XXNAS > TB --- 2013-03-09 03:45:54 - building CNS11XXNAS kernel > TB --- 2013-03-09 03:45:54 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:45:54 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:45:54 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:45:54 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:45:54 - TARGET=3Darm > TB --- 2013-03-09 03:45:54 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:45:54 - TZ=3DUTC > TB --- 2013-03-09 03:45:54 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:45:54 - cd /src > TB --- 2013-03-09 03:45:54 - /usr/bin/make -B buildkernel KERNCONF=3DCNS1= 1XXNAS >>>> Kernel build for CNS11XXNAS started on Sat Mar 9 03:45:54 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for CNS11XXNAS completed on Sat Mar 9 03:48:31 UTC 2013 > TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m CRB > TB --- 2013-03-09 03:48:31 - skipping CRB kernel > TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m CUBIEBOARD > TB --- 2013-03-09 03:48:31 - skipping CUBIEBOARD kernel > TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m DB-78XXX > TB --- 2013-03-09 03:48:31 - building DB-78XXX kernel > TB --- 2013-03-09 03:48:31 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:48:31 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:48:31 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:48:31 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:48:31 - TARGET=3Darm > TB --- 2013-03-09 03:48:31 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:48:31 - TZ=3DUTC > TB --- 2013-03-09 03:48:31 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:48:31 - cd /src > TB --- 2013-03-09 03:48:31 - /usr/bin/make -B buildkernel KERNCONF=3DDB-7= 8XXX >>>> Kernel build for DB-78XXX started on Sat Mar 9 03:48:31 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for DB-78XXX completed on Sat Mar 9 03:51:23 UTC 2013 > TB --- 2013-03-09 03:51:23 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:51:23 - /usr/sbin/config -m DB-88F5XXX > TB --- 2013-03-09 03:51:23 - building DB-88F5XXX kernel > TB --- 2013-03-09 03:51:23 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:51:23 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:51:23 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:51:23 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:51:23 - TARGET=3Darm > TB --- 2013-03-09 03:51:23 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:51:23 - TZ=3DUTC > TB --- 2013-03-09 03:51:23 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:51:23 - cd /src > TB --- 2013-03-09 03:51:23 - /usr/bin/make -B buildkernel KERNCONF=3DDB-8= 8F5XXX >>>> Kernel build for DB-88F5XXX started on Sat Mar 9 03:51:23 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for DB-88F5XXX completed on Sat Mar 9 03:54:06 UTC 2013 > TB --- 2013-03-09 03:54:06 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:54:06 - /usr/sbin/config -m DB-88F6XXX > TB --- 2013-03-09 03:54:06 - building DB-88F6XXX kernel > TB --- 2013-03-09 03:54:06 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:54:06 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:54:06 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:54:06 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:54:06 - TARGET=3Darm > TB --- 2013-03-09 03:54:06 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:54:06 - TZ=3DUTC > TB --- 2013-03-09 03:54:06 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:54:06 - cd /src > TB --- 2013-03-09 03:54:06 - /usr/bin/make -B buildkernel KERNCONF=3DDB-8= 8F6XXX >>>> Kernel build for DB-88F6XXX started on Sat Mar 9 03:54:06 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for DB-88F6XXX completed on Sat Mar 9 03:57:03 UTC 2013 > TB --- 2013-03-09 03:57:03 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:57:03 - /usr/sbin/config -m DOCKSTAR > TB --- 2013-03-09 03:57:03 - building DOCKSTAR kernel > TB --- 2013-03-09 03:57:03 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:57:03 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:57:03 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:57:03 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:57:03 - TARGET=3Darm > TB --- 2013-03-09 03:57:03 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:57:03 - TZ=3DUTC > TB --- 2013-03-09 03:57:03 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:57:03 - cd /src > TB --- 2013-03-09 03:57:03 - /usr/bin/make -B buildkernel KERNCONF=3DDOCK= STAR >>>> Kernel build for DOCKSTAR started on Sat Mar 9 03:57:03 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for DOCKSTAR completed on Sat Mar 9 03:59:44 UTC 2013 > TB --- 2013-03-09 03:59:44 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:59:44 - /usr/sbin/config -m DREAMPLUG-1001 > TB --- 2013-03-09 03:59:44 - building DREAMPLUG-1001 kernel > TB --- 2013-03-09 03:59:44 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:59:44 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:59:44 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:59:44 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:59:44 - TARGET=3Darm > TB --- 2013-03-09 03:59:44 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:59:44 - TZ=3DUTC > TB --- 2013-03-09 03:59:44 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:59:44 - cd /src > TB --- 2013-03-09 03:59:44 - /usr/bin/make -B buildkernel KERNCONF=3DDREA= MPLUG-1001 >>>> Kernel build for DREAMPLUG-1001 started on Sat Mar 9 03:59:44 UTC 201= 3 >>>> 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 DREAMPLUG-1001 completed on Sat Mar 9 04:03:34 UTC 2= 013 > TB --- 2013-03-09 04:03:34 - cd /src/sys/arm/conf > TB --- 2013-03-09 04:03:34 - /usr/sbin/config -m EA3250 > TB --- 2013-03-09 04:03:34 - building EA3250 kernel > TB --- 2013-03-09 04:03:34 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 04:03:34 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 04:03:34 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 04:03:34 - SRCCONF=3D/dev/null > TB --- 2013-03-09 04:03:34 - TARGET=3Darm > TB --- 2013-03-09 04:03:34 - TARGET_ARCH=3Darm > TB --- 2013-03-09 04:03:34 - TZ=3DUTC > TB --- 2013-03-09 04:03:34 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 04:03:34 - cd /src > TB --- 2013-03-09 04:03:34 - /usr/bin/make -B buildkernel KERNCONF=3DEA32= 50 >>>> Kernel build for EA3250 started on Sat Mar 9 04:03:34 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for EA3250 completed on Sat Mar 9 04:06:20 UTC 2013 > TB --- 2013-03-09 04:06:20 - cd /src/sys/arm/conf > TB --- 2013-03-09 04:06:20 - /usr/sbin/config -m EB9200 > TB --- 2013-03-09 04:06:20 - building EB9200 kernel > TB --- 2013-03-09 04:06:20 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 04:06:20 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 04:06:20 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 04:06:20 - SRCCONF=3D/dev/null > TB --- 2013-03-09 04:06:20 - TARGET=3Darm > TB --- 2013-03-09 04:06:20 - TARGET_ARCH=3Darm > TB --- 2013-03-09 04:06:20 - TZ=3DUTC > TB --- 2013-03-09 04:06:20 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 04:06:20 - cd /src > TB --- 2013-03-09 04:06:20 - /usr/bin/make -B buildkernel KERNCONF=3DEB92= 00 >>>> Kernel build for EB9200 started on Sat Mar 9 04:06:20 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything >>>> Kernel build for EB9200 completed on Sat Mar 9 04:08:52 UTC 2013 > TB --- 2013-03-09 04:08:52 - cd /src/sys/arm/conf > TB --- 2013-03-09 04:08:52 - /usr/sbin/config -m EP80219 > TB --- 2013-03-09 04:08:52 - skipping EP80219 kernel > TB --- 2013-03-09 04:08:52 - cd /src/sys/arm/conf > TB --- 2013-03-09 04:08:52 - /usr/sbin/config -m ETHERNUT5 > TB --- 2013-03-09 04:08:52 - building ETHERNUT5 kernel > TB --- 2013-03-09 04:08:52 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 04:08:52 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 04:08:52 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 04:08:52 - SRCCONF=3D/dev/null > TB --- 2013-03-09 04:08:52 - TARGET=3Darm > TB --- 2013-03-09 04:08:52 - TARGET_ARCH=3Darm > TB --- 2013-03-09 04:08:52 - TZ=3DUTC > TB --- 2013-03-09 04:08:52 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 04:08:52 - cd /src > TB --- 2013-03-09 04:08:52 - /usr/bin/make -B buildkernel KERNCONF=3DETHE= RNUT5 >>>> Kernel build for ETHERNUT5 started on Sat Mar 9 04:08:52 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything > [...] > cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTI= ON_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@= /contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --para= m large-function-growth=3D1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT= 5 -mcpu=3Darm9 -ffreestanding -std=3Diso9899:1999 -Wall -Wredundant-decls -= Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissi= ng-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../= net80211/ieee80211_mesh.c > cc1: warnings being treated as errors > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_= recv_indiv_data_to_fwrd': > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1480: warning: unus= ed variable 'ic' [-Wunused-variable] > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_= recv_indiv_data_to_me': > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1539: warning: unus= ed variable 'ic' [-Wunused-variable] > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_= recv_group_data': > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1606: warning: unus= ed variable 'ic' [-Wunused-variable] > *** [ieee80211_mesh.o] Error code 1 > > Stop in /src/sys/modules/wlan. > *** [all] Error code 1 > > Stop in /src/sys/modules. > *** [modules-all] Error code 1 > > Stop in /obj/arm.arm/src/sys/ETHERNUT5. > *** [buildkernel] Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2013-03-09 04:18:05 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-03-09 04:18:05 - ERROR: failed to build ETHERNUT5 kernel > TB --- 2013-03-09 04:18:05 - 8057.57 user 1463.77 system 10068.22 real > > > http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 05:43:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 245A1AA0 for ; Sat, 9 Mar 2013 05:43:59 +0000 (UTC) (envelope-from sinkeyteck@yahoo.com) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) by mx1.freebsd.org (Postfix) with ESMTP id C25D0CB7 for ; Sat, 9 Mar 2013 05:43:58 +0000 (UTC) Received: from [98.139.212.147] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 05:43:51 -0000 Received: from [98.139.212.231] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 05:43:51 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 05:43:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 897394.48610.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 55507 invoked by uid 60001); 9 Mar 2013 05:43:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362807831; bh=qZbutJMbJttRoU/euLimn4khPuEitDUfUZX3EA63ygI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=3KWQGuBMh4nPZ+DljcMHwomb+nsBnZ9IjhBY/tWIJWjjJWqsqlcLYa+1Em1G642Z0CZLq0NWu2PbUooBY/mb91zDels5Tii7UXHwDd2ycUDf+tk2VMw7/LM8vF1O2GNyqM2xD2LYmovKwEnVcchuIZJPC8xFP43LoaA4xThm+pE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=oJcmlr8eYPgrR29iRaF29GxnT9D5qES22+250SJPf2u3DGQFi1p2khpv1oQtw9UFAa8MgMiFqRWnCaymU/UZ0TUWxKptQw9oyKRE1Z4UglTFzSWl0VF0GAXnT3IVoGavuWoNvg0msXwshA0L7BLCq2k3QAkzwaj2gTwpmZbwVBQ=; X-YMail-OSG: yT7UAVgVM1k_JTpOQipoYdcHiUeKL5TTAVDHJInJV1Rb53W 0.eoqR241s9VjN1sKPmjK1L1xEqvI5RDg1OtpGWbr1bdxyIU85PUALOiHQcw F6x5s8UyjXPPVcqNQFBngmW9Z6cY8QOVyNkb_YSjv_Z_24sKd1tovW1pjvCo cTGY.TZotiwuw_gy5xcV6DylSfYgSBeuzMuoXH9hLlli7Uohju1T8XcgWjwp g43SKu5PrgVLa_yKqikaiWpiQojCu9WGOE3jbtpdMZC5GujLKQ0nMtzw2P8q knxCcapFRqKu_pZHjEbQF588tJW4sS4H7BE.lmIO37HsNGG1JCYsfZl1acYY rIUnlCHr5u4dJnZk.3A6pk2hpOwOdSsyjb39vPsVW6AUkFtF0MSbr3lW2vF5 YZ6dpj7QmXDb48EBZVk73F22EWS2caZzdBokS5dg2oAK2FYf.i6i7j1HfvPw zojW4UdlsHHltYv06iNI2iPavUZCF4G1YyuZHm9dAks44rrq9OB3.iUiO4gp iK0vk2RL7lwcEf.xQkKWYzIGHiUhrQgS.3OQfu3dZ_lmc05N94Z1ZueGMOIh NHEnhCuF199f7E22bPOgx_NrSsxaC7OPTQG_jreAvxSVuyTlKX19sl_4VEAU Dt78wHGE- Received: from [49.125.96.162] by web31805.mail.mud.yahoo.com via HTTP; Fri, 08 Mar 2013 21:43:50 PST X-Rocket-MIMEInfo: 002.001, cHcgaXMgY3Jhc2hpbmcgd2l0aCBzZWcgZmF1bHQgZHVlIHRvIHRoaXMgY2hhbmdlPwoKaHR0cDovL3N2bndlYi5mcmVlYnNkLm9yZy9iYXNlL2hlYWQvbGliL2xpYnV0aWwvZ3JfdXRpbC5jP3IxPTI0NTM5MCZyMj0yNDc5MTkKCiMgZ2RiIC4vcHcKR05VIGdkYiA2LjEuMSBbRnJlZUJTRF0KQ29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUKd2UBMAEBAQE- X-RocketYMMF: sinkeyteck X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.137.519 Message-ID: <1362807830.29167.YahooMailClassic@web31805.mail.mud.yahoo.com> Date: Fri, 8 Mar 2013 21:43:50 -0800 (PST) From: KT Sin Subject: pw is broken? To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ktsin@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 05:43:59 -0000 pw is crashing with seg fault due to this change? http://svnweb.freebsd.org/base/head/lib/libutil/gr_util.c?r1=245390&r2=247919 # gdb ./pw 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"... (gdb) run groupadd test123 -g 12345 Starting program: /usr/src/usr.sbin/pw/pw groupadd test123 -g 12345 Program received signal SIGSEGV, Segmentation fault. 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 (gdb) bt full #0 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 No symbol table info available. #1 0x0000000080a5c00a in grcopy (gr=0x612ce0, newgr=0x81409100, name=0x0, ndx=0) at /usr/src/lib/libutil/gr_util.c:496 dst = 0x8 i = 1090277153 #2 0x0000000080a5bdc6 in gr_add (gr=0x612ce0, newmember=0x0) at /usr/src/lib/libutil/gr_util.c:451 newgr = (struct group *) 0x81409100 len = 0 num_mem = 0 #3 0x0000000080a5bd4f in gr_dup (gr=0x612ce0) at /usr/src/lib/libutil/gr_util.c:434 No locals. #4 0x000000000040bad7 in gr_update (grp=0x612ce0, group=0x0) at grupd.c:78 pfd = 0 tfd = 4244492 gr = (struct group *) 0x0 old_gr = (struct group *) 0x0 #5 0x000000000040ba8f in addgrent (grp=0x612ce0) at grupd.c:111 No locals. #6 0x000000000040a83d in pw_group (cnf=0x612bf0, mode=0, args=0x613e78) at pw_group.c:258 ---Type to continue, or q to quit--- grp = (struct group *) 0x612ce0 members = (char **) 0x81485d00 rc = 0 a_name = (struct carg *) 0x8144c0a0 a_gid = (struct carg *) 0x8144c0c0 arg = (struct carg *) 0x0 grmembers = 200 fakegroup = {gr_name = 0x7fffffffdcb9 "test123", gr_passwd = 0x40fbc9 "*", gr_gid = 12345, gr_mem = 0x81485d00} #7 0x00000000004037fb in main (argc=3, argv=0x7fffffffd9f0) at pw.c:230 which = 1 config = 0x0 cnf = (struct userconf *) 0x612bf0 ch = -1 mode = 0 opts = {{0x40e150 "V:C:qn:u:c:d:e:p:g:G:mM:k:s:oL:i:w:h:H:Db:NPy:Y", 0x40e180 "V:C:qn:u:rY", 0x40e18c "V:C:qn:u:c:d:e:p:g:G:mM:l:k:s:w:L:h:H:FNPY", 0x40e1b7 "V:C:qn:u:FPa7", 0x40e1c5 "V:C:q", 0x40e1c5 "V:C:q", 0x40e1c5 "V:C:q"}, {0x40e1cb "V:C:qn:g:h:H:M:opNPY", 0x40e1e0 "V:C:qn:g:Y", 0x40e1eb "V:C:qn:d:g:l:h:H:FM:m:NPY", 0x40e205 "V:C:qn:g:FPa", 0x40e1c5 "V:C:q", 0x0, 0x0}} funcs = {0x405270 , 0x409b60 } (gdb) From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 07:13:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 02AD85D6; Sat, 9 Mar 2013 07:13:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C6749E2E; Sat, 9 Mar 2013 07:13:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r297DBQK025474; Sat, 9 Mar 2013 02:13:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r297DBpf025470; Sat, 9 Mar 2013 07:13:11 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Mar 2013 07:13:11 GMT Message-Id: <201303090713.r297DBpf025470@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 07:13:13 -0000 TB --- 2013-03-09 03:37:57 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-09 03:37:57 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-09 03:37:57 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-09 03:37:57 - cleaning the object tree TB --- 2013-03-09 03:37:57 - /usr/local/bin/svn stat /src TB --- 2013-03-09 03:38:00 - At svn revision 248079 TB --- 2013-03-09 03:38:01 - building world TB --- 2013-03-09 03:38:01 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:38:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:38:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:38:01 - SRCCONF=/dev/null TB --- 2013-03-09 03:38:01 - TARGET=pc98 TB --- 2013-03-09 03:38:01 - TARGET_ARCH=i386 TB --- 2013-03-09 03:38:01 - TZ=UTC TB --- 2013-03-09 03:38:01 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:38:01 - cd /src TB --- 2013-03-09 03:38:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 9 03:38:06 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 9 06:30:12 UTC 2013 TB --- 2013-03-09 06:30:12 - generating LINT kernel config TB --- 2013-03-09 06:30:12 - cd /src/sys/pc98/conf TB --- 2013-03-09 06:30:12 - /usr/bin/make -B LINT TB --- 2013-03-09 06:30:12 - cd /src/sys/pc98/conf TB --- 2013-03-09 06:30:12 - /usr/sbin/config -m LINT TB --- 2013-03-09 06:30:13 - building LINT kernel TB --- 2013-03-09 06:30:13 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 06:30:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 06:30:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 06:30:13 - SRCCONF=/dev/null TB --- 2013-03-09 06:30:13 - TARGET=pc98 TB --- 2013-03-09 06:30:13 - TARGET_ARCH=i386 TB --- 2013-03-09 06:30:13 - TZ=UTC TB --- 2013-03-09 06:30:13 - __MAKE_CONF=/dev/null TB --- 2013-03-09 06:30:13 - cd /src TB --- 2013-03-09 06:30:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 9 06:30:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Mar 9 06:55:08 UTC 2013 TB --- 2013-03-09 06:55:08 - cd /src/sys/pc98/conf TB --- 2013-03-09 06:55:08 - /usr/sbin/config -m GENERIC TB --- 2013-03-09 06:55:08 - building GENERIC kernel TB --- 2013-03-09 06:55:08 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 06:55:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 06:55:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 06:55:08 - SRCCONF=/dev/null TB --- 2013-03-09 06:55:08 - TARGET=pc98 TB --- 2013-03-09 06:55:08 - TARGET_ARCH=i386 TB --- 2013-03-09 06:55:08 - TZ=UTC TB --- 2013-03-09 06:55:08 - __MAKE_CONF=/dev/null TB --- 2013-03-09 06:55:08 - cd /src TB --- 2013-03-09 06:55:08 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Mar 9 06:55:08 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1539:23: error: unused variable 'ic' [-Werror,-Wunused-variable] struct ieee80211com *ic = vap->iv_ic; ^ /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1606:23: error: unused variable 'ic' [-Werror,-Wunused-variable] struct ieee80211com *ic = vap->iv_ic; ^ 3 errors generated. *** [ieee80211_mesh.o] Error code 1 Stop in /src/sys/modules/wlan. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-09 07:13:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-09 07:13:11 - ERROR: failed to build GENERIC kernel TB --- 2013-03-09 07:13:11 - 10305.17 user 1710.76 system 12913.86 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 07:55:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7E3E123 for ; Sat, 9 Mar 2013 07:55:13 +0000 (UTC) (envelope-from kolyasir@gmail.com) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by mx1.freebsd.org (Postfix) with ESMTP id B30372AA for ; Sat, 9 Mar 2013 07:55:13 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id cr7so193800qab.10 for ; Fri, 08 Mar 2013 23:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=0V6gAgtEVNOOE0d/G58FaHRIrUoRPivYfgOvezh0w+8=; b=BVwEm+5iSzzIDW3k2a2ew2LRT7mb7SBd1RS0Ld2s9vrk37lF8fjgPD2u2YRmAXJiLZ bIVsl4e9fLfTU1667YtVKNLaJnoqcUKZmzUsRn7jGWhgfglyZMsKMfsCPLLnBo/c5Ql4 VPqI5Sp/0v+sSCrTyssORSdQzmb//DGXcbI6YPRvfH64MAjiujb9W5YMwoXoTRghTHGa K1akCgUvLXxeUIpUfERR2aGPn+UU5hggAP7crHQhsC8UJe8H4VxgZqfGqbhwe6aNJis5 /UFPVZKCOnU4GCI8QxRM3qtBRO/AxF6F5Q3BeYdNGNvoaZ5YmMURwXPkU9QrhGk1vGvl gflQ== MIME-Version: 1.0 X-Received: by 10.49.2.7 with SMTP id 7mr8260293qeq.45.1362815712791; Fri, 08 Mar 2013 23:55:12 -0800 (PST) Received: by 10.49.48.197 with HTTP; Fri, 8 Mar 2013 23:55:12 -0800 (PST) Date: Sat, 9 Mar 2013 02:55:12 -0500 Message-ID: Subject: multi-homing in freebsd From: Yasir hussan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 07:55:14 -0000 Hi, Does anyone know usage of multi-homing in freebsd, if YES kindly guid me how i can test it on my own PC. Thanks From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 07:55:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9153722A; Sat, 9 Mar 2013 07:55:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 666A12BB; Sat, 9 Mar 2013 07:55:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r297tPSe017208; Sat, 9 Mar 2013 02:55:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r297tPoR017207; Sat, 9 Mar 2013 07:55:25 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Mar 2013 07:55:25 GMT Message-Id: <201303090755.r297tPoR017207@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 07:55:26 -0000 TB --- 2013-03-09 06:48:01 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-09 06:48:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-09 06:48:01 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-09 06:48:01 - cleaning the object tree TB --- 2013-03-09 06:48:01 - /usr/local/bin/svn stat /src TB --- 2013-03-09 06:48:14 - At svn revision 248079 TB --- 2013-03-09 06:48:15 - building world TB --- 2013-03-09 06:48:15 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 06:48:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 06:48:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 06:48:15 - SRCCONF=/dev/null TB --- 2013-03-09 06:48:15 - TARGET=mips TB --- 2013-03-09 06:48:15 - TARGET_ARCH=mips TB --- 2013-03-09 06:48:15 - TZ=UTC TB --- 2013-03-09 06:48:15 - __MAKE_CONF=/dev/null TB --- 2013-03-09 06:48:15 - cd /src TB --- 2013-03-09 06:48:15 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 9 06:48:19 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 9 07:52:18 UTC 2013 TB --- 2013-03-09 07:52:18 - cd /src/sys/mips/conf TB --- 2013-03-09 07:52:18 - /usr/sbin/config -m ADM5120 TB --- 2013-03-09 07:52:18 - skipping ADM5120 kernel TB --- 2013-03-09 07:52:18 - cd /src/sys/mips/conf TB --- 2013-03-09 07:52:18 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-09 07:52:18 - skipping ALCHEMY kernel TB --- 2013-03-09 07:52:18 - cd /src/sys/mips/conf TB --- 2013-03-09 07:52:18 - /usr/sbin/config -m AP91 TB --- 2013-03-09 07:52:18 - building AP91 kernel TB --- 2013-03-09 07:52:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 07:52:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 07:52:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 07:52:18 - SRCCONF=/dev/null TB --- 2013-03-09 07:52:18 - TARGET=mips TB --- 2013-03-09 07:52:18 - TARGET_ARCH=mips TB --- 2013-03-09 07:52:18 - TZ=UTC TB --- 2013-03-09 07:52:18 - __MAKE_CONF=/dev/null TB --- 2013-03-09 07:52:18 - cd /src TB --- 2013-03-09 07:52:18 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Sat Mar 9 07:52:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c cc1: warnings being treated as errors /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_recv_indiv_data_to_fwrd': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1480: warning: unused variable 'ic' [-Wunused-variable] /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_recv_indiv_data_to_me': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1539: warning: unused variable 'ic' [-Wunused-variable] /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_recv_group_data': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1606: warning: unused variable 'ic' [-Wunused-variable] *** [ieee80211_mesh.o] Error code 1 Stop in /src/sys/modules/wlan. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/mips.mips/src/sys/AP91. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-09 07:55:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-09 07:55:25 - ERROR: failed to build AP91 kernel TB --- 2013-03-09 07:55:25 - 2805.98 user 631.93 system 4043.87 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 08:04:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4D9DD408 for ; Sat, 9 Mar 2013 08:04:01 +0000 (UTC) (envelope-from kolyasir@gmail.com) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id EDEA9300 for ; Sat, 9 Mar 2013 08:04:00 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so875720qcs.27 for ; Sat, 09 Mar 2013 00:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=LDkdIUFgWdQpidz6lRRGmNO8CAvx/hEJiJaxAmWx7Dw=; b=jIys02QWr4yu/QQFCTR7jdK2Dl+16XR2zW0Ic+nkdCfTdh9I2vAKEOt3Kqtr/v12Bo lXdKoEE6f6v2YcCoO1OA/t1g78Br+Oc1T5i1cFsNSLz57T6a7p1Bh8zpytCoJ2lrZ/0w KoeVJGt0opRxRl3a+K7fryXeiiAq+hxL3ZMpI3QNtnlcV5oITKG8mCsdtaZrF220K/Ni ZG6ClM5DCrGfsRPAWHivrlNsn2Fl0sughJOS4If7yuX28TNfE5HwVOgeKYoAwwxZqBj6 rC3mNLdjlhdyyv6mzLa598YSdwCTdYvWDXP1fw5VqGu9dYaVFcK9xG4oCeKH5Zqf6uiZ 1pHw== MIME-Version: 1.0 X-Received: by 10.49.15.198 with SMTP id z6mr8422529qec.6.1362816240208; Sat, 09 Mar 2013 00:04:00 -0800 (PST) Received: by 10.49.48.197 with HTTP; Sat, 9 Mar 2013 00:04:00 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Mar 2013 03:04:00 -0500 Message-ID: Subject: Re: multi-homing in freebsd From: Yasir hussan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 08:04:01 -0000 i just want to run multiple IPs for single network card in freebsd On Sat, Mar 9, 2013 at 2:55 AM, Yasir hussan wrote: > Hi, > > Does anyone know usage of multi-homing in freebsd, if YES kindly guid me > how i can test it on my own PC. > > Thanks > From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 08:06:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07F3351C for ; Sat, 9 Mar 2013 08:06:05 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id A035A319 for ; Sat, 9 Mar 2013 08:06:04 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id uz6so1994926obc.34 for ; Sat, 09 Mar 2013 00:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zBssBUAyYV6uyc/bi0g0IWh4jkmiXHLwxMkYgCMNCxI=; b=JV3HGHaKqeFNcKqoai9uCaTB812LWfkr37/RInDBaSy6jSVg7g0zEwwfwErSXnuUuW LMK35TONFi1GVB/uuBLIlUAnVqBZiNKqMme3bCv509JxRKOdbe+gfFD+5PEKD9jQNDJ+ 8LUJNZlGzcNjJqTa1P1gzTdNpfHUcZsac7hxnrInexpgaY99Uh0CI7CvBkLhjaNSwvf3 hPkkPYv+KV9mqGNXP64vAm4moxs0/uUPbr4pPcCszrHMbfGNZfvtnyW0FoAz8JdS1tgc LsXmbpfdw9YyjHOfaUAu1XmLds/0R/drM/5hJOzYFOj1TKx6e+4/oP7leV9EpBYVwYIu uMJw== MIME-Version: 1.0 X-Received: by 10.60.170.140 with SMTP id am12mr3930732oec.125.1362816364253; Sat, 09 Mar 2013 00:06:04 -0800 (PST) Received: by 10.76.12.5 with HTTP; Sat, 9 Mar 2013 00:06:04 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Mar 2013 03:06:04 -0500 Message-ID: Subject: Re: multi-homing in freebsd From: Zaphod Beeblebrox To: Yasir hussan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 08:06:05 -0000 On Sat, Mar 9, 2013 at 2:55 AM, Yasir hussan wrote: > > Does anyone know usage of multi-homing in freebsd, if YES kindly guid me > how i can test it on my own PC. > > This question seems almost so simple as to be a trick question. By definition, put two ethernet cards in your FreeBSD computer, give each different IP addresses and connectivity to different networks ... and congratulations: you're multi-homed. By definition, any FreeBSD router is multihomed. My BGP core router (which is FreeBSD) is multihomed and has no default route... but that's really just bragging :) Maybe you need to ask a better question. From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 08:08:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C038A645 for ; Sat, 9 Mar 2013 08:08:48 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id 7018033B for ; Sat, 9 Mar 2013 08:08:48 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id k14so2880601oag.25 for ; Sat, 09 Mar 2013 00:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fsvorRarsVNrO5s6D5Ge0QDH0zyEnnlz2+Up8SToUwQ=; b=lS2lsPljb5wQ8IMFu1ENksFHHYL7o4WptLv0NJVyuwjRvtygTIzi9fJY744ghCS6gI akxVNW/AE8G/ydOT4TFG42ycob4XZfP8dlPazcRc3OaL0HnH5V1bWnAwX1B6uPjeAO3I wbqbUrjqy05BmzpTQuRoT9ChBIeNk9KmN5Vee0eK2yaQTg2/5Cc4FFwQwUxsThEO+38C RM0bfRet8B1TwpIjIe412clNho5nlFjxERXC60Iyyqr29CU4dixjCuQsR9yKJOB4a03+ dtNmcLzPARIJq4PIkVB53HVSbG8f0sasAxJfRK4qgq+M2Qcjsl7Q5d/F0DK1305I7Zp9 S6Dw== MIME-Version: 1.0 X-Received: by 10.60.172.18 with SMTP id ay18mr3976548oec.126.1362816522757; Sat, 09 Mar 2013 00:08:42 -0800 (PST) Received: by 10.76.12.5 with HTTP; Sat, 9 Mar 2013 00:08:42 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Mar 2013 03:08:42 -0500 Message-ID: Subject: Re: multi-homing in freebsd From: Zaphod Beeblebrox To: Yasir hussan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 08:08:48 -0000 On Sat, Mar 9, 2013 at 3:04 AM, Yasir hussan wrote: > i just want to run multiple IPs for single network card in freebsd > > OK. A better question. About the only caution I can give here (assuming you don't mean something more interesting like vlans and whatnot) is that if both IP addresses are on the SAME network, use a /32 as the netmask (it works better). If they are on different networks, specify the netmask as normal. You may, at this point, need a method to choose which IP address to use for any particular connection. There's a pile of documentation waiting for you. From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 08:57:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02EB4E0C for ; Sat, 9 Mar 2013 08:57:40 +0000 (UTC) (envelope-from kolyasir@gmail.com) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by mx1.freebsd.org (Postfix) with ESMTP id A162D637 for ; Sat, 9 Mar 2013 08:57:39 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id bs12so205347qab.0 for ; Sat, 09 Mar 2013 00:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C4jN855WtoXnWNA6ZMjLj0XKbpqXYMQKoT09R/3kKrU=; b=K5hg1s4OTmVEYWVdygB8Q/q9FqfepfNuFThSvvBHCthx57p6WMk7i0ohLiSY5yGh3X 6ds2RHkkxAM2ElJfbec+z4p8gMdLZ3nCis0qoAXljFXH2L2g7XSYPMy/9HlyNLEyzTEG O+/wHk4ON1QF3yGnKuldb4/wBidlNKQ+HbBdBPwxKAPk1ecTP7/Dvf0854NkXV7ex+/E VGwgP4+/AmcOb+mMMiI8vSfJDFk9rEDUGcV9uVzqEW0bFStczVGF6lW+Vqu4WSRgqC/w e1YjN0UvyibYGF39UgoagxZwJFU86xMGZrX5x139YOFtjBTPDBo2erd0Y6V0t3eWm6OD aMSQ== MIME-Version: 1.0 X-Received: by 10.49.105.4 with SMTP id gi4mr8855602qeb.0.1362819453721; Sat, 09 Mar 2013 00:57:33 -0800 (PST) Received: by 10.49.48.197 with HTTP; Sat, 9 Mar 2013 00:57:33 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Mar 2013 03:57:33 -0500 Message-ID: Subject: Re: multi-homing in freebsd From: Yasir hussan To: Zaphod Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 08:57:40 -0000 Kindly will u give me example with cammand line, which can test on my freebsd machine, i want two ips 192.168.1.100 and 192.169.1.100 to be work on single network interface, my default interface for network is arge0 On Sat, Mar 9, 2013 at 3:08 AM, Zaphod Beeblebrox wrote: > On Sat, Mar 9, 2013 at 3:04 AM, Yasir hussan wrote: > >> i just want to run multiple IPs for single network card in freebsd >> >> > OK. A better question. About the only caution I can give here (assuming > you don't mean something more interesting like vlans and whatnot) is that > if both IP addresses are on the SAME network, use a /32 as the netmask (it > works better). If they are on different networks, specify the netmask as > normal. > > You may, at this point, need a method to choose which IP address to use > for any particular connection. There's a pile of documentation waiting for > you. > > From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 09:06:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 434BA1B7 for ; Sat, 9 Mar 2013 09:06:45 +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 E463D689 for ; Sat, 9 Mar 2013 09:06:44 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1UEFjo-000hCh-4D>; Sat, 09 Mar 2013 10:06:44 +0100 Received: from e178025158.adsl.alicedsl.de ([85.178.25.158] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1UEFjn-0033tL-W4>; Sat, 09 Mar 2013 10:06:44 +0100 Message-ID: <513AFBE3.8070506@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 10:07:47 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current Subject: CURRENT (r248061):Thunderbird SIGNAL 11 with OpenLDAP / nscd(1) broken pipe/ Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.25.158 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Mar 2013 09:06:45 -0000 For the introduction, I filed a PR for this at beginning of 2012 and suffered from the very same problem close to two years before on ALL FreeBSD versions and platforms using OpenLDAP as the user backend: ports/164239: [PATCH] mail/thunderbird: crash with nss_ldap Even with the suggested patch by the maintainer the problem stayed. With the introduction of bad code due to updates with > r247804 and the following issues of SIGNAL 13/broken pipe, the problem now is even worse in FreeBSD 10.0 r248061. >From my limited point of view I guess this long lasting unresolved problem could have been revealed itself and I hope this could be fixed along with fixing nscd(1). Again, Thunderbird in all flavours since 2010 crashes on FreeBSD 8/9 and now 10.0-CURRENT when it is used on systems with user backend in OpenLDAP or any LDAP (Thunderbird works on non-OpenLDAP backed systems of the same OS revision). I was able to "solve" the problem by starting Firefox first and only Firefox getting started prior to Thunderbird resolved the problem for a while, but closing Firefox and waiting a bit left Thunderbird unstarteable again until Firefox was closed and reopened again. I guess this strange behaviour reveals a deeper issue not necessarily bound to nscd(1) (since the problem with Thunderbird also occurs without nscd(1), BUT always bound to the use of OpenLDAP backend (with security/pam_ldap and net/nss_ldap from ports). Now, on FreeBSD 10.0-CURRENT r248061/amd64, Thunderbird dies immediately with SIGNAL 11 on those boxes with OpenLDAP backend and no "trick" makes Thunderbird starting enymore. In my desperation, I did a truss, see below and it seems to me that there is a problem getting the effective UID, since the SIGNAL 11 arises after geteuid(). At the moment, I have switched off nscd(1) by default since it is broken in CURRENT or doing very strange things (see list about broken pipe in the system, sudo(1) or even the port's system (SIGNAL 13)). I think there is a major issue covered and I hope this could be solved by the problems triggered. it is hard to believe that I'm the only one using FreeBSD for both workstation and server environment in conjuction with OpenLDAP and facing the problem with a popular software like Thunderbird. If it is a stupid configuation problem then this must be very, very special since it is now sticky with me for years. Here comes the truss ...: open("/etc/pwd.db",O_RDONLY,00) = 4 (0x4) fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) fstat(4,{ mode=-rw-r--r-- ,inode=117927,size=40960,blksize=16384 }) = 0 (0x0) read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) pread(0x4,0x801bfc000,0x1000,0x6000,0x1,0x0) = 4096 (0x1000) pread(0x4,0x813927000,0x1000,0x2000,0x1,0x0) = 4096 (0x1000) close(4) = 0 (0x0) socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) connect(4,{ AF_UNIX "/var/run/nscd" },15) ERR#2 'No such file or directory' close(4) = 0 (0x0) sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigaction(SIGPIPE,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) getpid() = 3235 (0xca3) geteuid() = 2002 (0x7d2) open("/usr/local/etc/nss_ldap.conf",O_RDONLY,0666) = 4 (0x4) fstat(4,{ mode=-rw-r--r-- ,inode=5818085,size=7997,blksize=16384 }) = 0 (0x0) fstat(4,{ mode=-rw-r--r-- ,inode=5818085,size=7997,blksize=16384 }) = 0 (0x0) read(4,"@(#)$Id: ldap.conf,v 2.47 2006/0"...,16384) = 7997 (0x1f3d) read(4,0x813928000,16384) = 0 (0x0) close(4) = 0 (0x0) __sysctl(0x7fffffffb1f8,0x2,0x7fffffffb220,0x7fffffffb200,0x0,0x0) = 0 (0x0) gettimeofday({1362819606.123684 },0x0) = 0 (0x0) getpid() = 3235 (0xca3) issetugid(0x35001c1c,0x80,0x801b1b600,0x10,0x2,0x1) = 0 (0x0) open("/etc/resolv.conf",O_RDONLY,0666) = 4 (0x4) fstat(4,{ mode=-rw-r--r-- ,inode=117845,size=101,blksize=16384 }) = 0 (0x0) read(4,"# Generated by resolvconf\nnames"...,16384) = 101 (0x65) read(4,0x813928000,16384) = 0 (0x0) close(4) = 0 (0x0) __sysctl(0x7fffffffab28,0x2,0x7fffffffad20,0x7fffffffab30,0x0,0x0) = 0 (0x0) issetugid(0x801526ae8,0x2e,0x2e,0x2e,0x101010101010101,0x8080808080808080) = 0 (0x0) stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=117790,size=991,blksize=16384 }) = 0 (0x0) open("/etc/hosts",O_RDONLY,0666) = 4 (0x4) fstat(4,{ mode=-rw-r--r-- ,inode=117862,size=2418,blksize=16384 }) = 0 (0x0) read(4,"# $FreeBSD: head/etc/hosts 10999"...,16384) = 2418 (0x972) close(4) = 0 (0x0) open("/usr/local/etc/openldap/ldap.conf",O_RDONLY,0666) = 4 (0x4) fstat(4,{ mode=-rw-r--r-- ,inode=5817420,size=410,blksize=16384 }) = 0 (0x0) read(4,"#\n# LDAP Defaults\n#\n\n# See l"...,16384) = 410 (0x19a) read(4,0x813928000,16384) = 0 (0x0) close(4) = 0 (0x0) geteuid() = 2002 (0x7d2) getuid() = 2002 (0x7d2) open("/home/ohartmann/ldaprc",O_RDONLY,0666) ERR#2 'No such file or directory' open("/home/ohartmann/.ldaprc",O_RDONLY,0666) ERR#2 'No such file or directory' open("ldaprc",O_RDONLY,0666) ERR#2 'No such file or directory' sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigaction(SIGPIPE,{ SIG_IGN SA_RESTART ss_t },{ SIG_IGN 0x0 ss_t }) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) getuid() = 2002 (0x7d2) stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inode=117790,size=991,blksize=16384 }) = 0 (0x0) geteuid() = 2002 (0x7d2) open("/etc/pwd.db",O_RDONLY,00) = 4 (0x4) fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) fstat(4,{ mode=-rw-r--r-- ,inode=117927,size=40960,blksize=16384 }) = 0 (0x0) read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) pread(0x4,0x813928000,0x1000,0x6000,0x1,0x0) = 4096 (0x1000) pread(0x4,0x813929000,0x1000,0x5000,0x1,0x0) = 4096 (0x1000) close(4) = 0 (0x0) socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) connect(4,{ AF_UNIX "/var/run/nscd" },15) ERR#2 'No such file or directory' close(4) = 0 (0x0) sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigaction(SIGPIPE,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) stat("/usr/local/etc/nss_ldap.conf",{ mode=-rw-r--r-- ,inode=5818085,size=7997,blksize=16384 }) = 0 (0x0) getpid() = 3235 (0xca3) geteuid() = 2002 (0x7d2) SIGNAL 11 (SIGSEGV) process exit, rval = 0 From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 09:24:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A0D0E592 for ; Sat, 9 Mar 2013 09:24:01 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 448D9711 for ; Sat, 9 Mar 2013 09:24:01 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1UEG0W-000jrj-EN>; Sat, 09 Mar 2013 10:24:00 +0100 Received: from e178025158.adsl.alicedsl.de ([85.178.25.158] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1UEG0W-0034oK-9o>; Sat, 09 Mar 2013 10:24:00 +0100 Message-ID: <513AFFF0.6010500@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 10:25:04 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current Subject: Re: CURRENT (r248061):Thunderbird SIGNAL 11 with OpenLDAP / nscd(1) broken pipe/ References: <513AFBE3.8070506@zedat.fu-berlin.de> In-Reply-To: <513AFBE3.8070506@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.25.158 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Mar 2013 09:24:01 -0000 Am 03/09/13 10:07, schrieb Hartmann, O.: > For the introduction, I filed a PR for this at beginning of 2012 and > suffered from the very same problem close to two years before on ALL > FreeBSD versions and platforms using OpenLDAP as the user backend: > > ports/164239: [PATCH] mail/thunderbird: crash with nss_ldap > > Even with the suggested patch by the maintainer the problem stayed. > > With the introduction of bad code due to updates with > r247804 and the > following issues of SIGNAL 13/broken pipe, the problem now is even worse > in FreeBSD 10.0 r248061. > From my limited point of view I guess this long lasting unresolved > problem could have been revealed itself and I hope this could be fixed > along with fixing nscd(1). > > Again, Thunderbird in all flavours since 2010 crashes on FreeBSD 8/9 and > now 10.0-CURRENT when it is used on systems with user backend in > OpenLDAP or any LDAP (Thunderbird works on non-OpenLDAP backed systems > of the same OS revision). > > I was able to "solve" the problem by starting Firefox first and only > Firefox getting started prior to Thunderbird resolved the problem for a > while, but closing Firefox and waiting a bit left Thunderbird > unstarteable again until Firefox was closed and reopened again. > > I guess this strange behaviour reveals a deeper issue not necessarily > bound to nscd(1) (since the problem with Thunderbird also occurs without > nscd(1), BUT always bound to the use of OpenLDAP backend (with > security/pam_ldap and net/nss_ldap from ports). > > Now, on FreeBSD 10.0-CURRENT r248061/amd64, Thunderbird dies immediately > with SIGNAL 11 on those boxes with OpenLDAP backend and no "trick" makes > Thunderbird starting enymore. > > In my desperation, I did a truss, see below and it seems to me that > there is a problem getting the effective UID, since the SIGNAL 11 arises > after geteuid(). > > At the moment, I have switched off nscd(1) by default since it is broken > in CURRENT or doing very strange things (see list about broken pipe in > the system, sudo(1) or even the port's system (SIGNAL 13)). > > I think there is a major issue covered and I hope this could be solved > by the problems triggered. > > it is hard to believe that I'm the only one using FreeBSD for both > workstation and server environment in conjuction with OpenLDAP and > facing the problem with a popular software like Thunderbird. > > If it is a stupid configuation problem then this must be very, very > special since it is now sticky with me for years. > > Here comes the truss ...: > > open("/etc/pwd.db",O_RDONLY,00) = 4 (0x4) > fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) > fstat(4,{ mode=-rw-r--r-- ,inode=117927,size=40960,blksize=16384 }) = 0 > (0x0) > read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) > pread(0x4,0x801bfc000,0x1000,0x6000,0x1,0x0) = 4096 (0x1000) > pread(0x4,0x813927000,0x1000,0x2000,0x1,0x0) = 4096 (0x1000) > close(4) = 0 (0x0) > socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) > connect(4,{ AF_UNIX "/var/run/nscd" },15) ERR#2 'No such file or > directory' > close(4) = 0 (0x0) > sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > = 0 (0x0) > sigaction(SIGPIPE,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 > (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > getpid() = 3235 (0xca3) > geteuid() = 2002 (0x7d2) > open("/usr/local/etc/nss_ldap.conf",O_RDONLY,0666) = 4 (0x4) > fstat(4,{ mode=-rw-r--r-- ,inode=5818085,size=7997,blksize=16384 }) = 0 > (0x0) > fstat(4,{ mode=-rw-r--r-- ,inode=5818085,size=7997,blksize=16384 }) = 0 > (0x0) > read(4,"@(#)$Id: ldap.conf,v 2.47 2006/0"...,16384) = 7997 (0x1f3d) > read(4,0x813928000,16384) = 0 (0x0) > close(4) = 0 (0x0) > __sysctl(0x7fffffffb1f8,0x2,0x7fffffffb220,0x7fffffffb200,0x0,0x0) = 0 (0x0) > gettimeofday({1362819606.123684 },0x0) = 0 (0x0) > getpid() = 3235 (0xca3) > issetugid(0x35001c1c,0x80,0x801b1b600,0x10,0x2,0x1) = 0 (0x0) > open("/etc/resolv.conf",O_RDONLY,0666) = 4 (0x4) > fstat(4,{ mode=-rw-r--r-- ,inode=117845,size=101,blksize=16384 }) = 0 (0x0) > read(4,"# Generated by resolvconf\nnames"...,16384) = 101 (0x65) > read(4,0x813928000,16384) = 0 (0x0) > close(4) = 0 (0x0) > __sysctl(0x7fffffffab28,0x2,0x7fffffffad20,0x7fffffffab30,0x0,0x0) = 0 (0x0) > issetugid(0x801526ae8,0x2e,0x2e,0x2e,0x101010101010101,0x8080808080808080) > = 0 (0x0) > stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- > ,inode=117790,size=991,blksize=16384 }) = 0 (0x0) > open("/etc/hosts",O_RDONLY,0666) = 4 (0x4) > fstat(4,{ mode=-rw-r--r-- ,inode=117862,size=2418,blksize=16384 }) = 0 (0x0) > read(4,"# $FreeBSD: head/etc/hosts 10999"...,16384) = 2418 (0x972) > close(4) = 0 (0x0) > open("/usr/local/etc/openldap/ldap.conf",O_RDONLY,0666) = 4 (0x4) > fstat(4,{ mode=-rw-r--r-- ,inode=5817420,size=410,blksize=16384 }) = 0 (0x0) > read(4,"#\n# LDAP Defaults\n#\n\n# See l"...,16384) = 410 (0x19a) > read(4,0x813928000,16384) = 0 (0x0) > close(4) = 0 (0x0) > geteuid() = 2002 (0x7d2) > getuid() = 2002 (0x7d2) > open("/home/ohartmann/ldaprc",O_RDONLY,0666) ERR#2 'No such file or > directory' > open("/home/ohartmann/.ldaprc",O_RDONLY,0666) ERR#2 'No such file or > directory' > open("ldaprc",O_RDONLY,0666) ERR#2 'No such file or > directory' > sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > = 0 (0x0) > sigaction(SIGPIPE,{ SIG_IGN SA_RESTART ss_t },{ SIG_IGN 0x0 ss_t }) = 0 > (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > getuid() = 2002 (0x7d2) > stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- > ,inode=117790,size=991,blksize=16384 }) = 0 (0x0) > geteuid() = 2002 (0x7d2) > open("/etc/pwd.db",O_RDONLY,00) = 4 (0x4) > fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) > fstat(4,{ mode=-rw-r--r-- ,inode=117927,size=40960,blksize=16384 }) = 0 > (0x0) > read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) > pread(0x4,0x813928000,0x1000,0x6000,0x1,0x0) = 4096 (0x1000) > pread(0x4,0x813929000,0x1000,0x5000,0x1,0x0) = 4096 (0x1000) > close(4) = 0 (0x0) > socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) > connect(4,{ AF_UNIX "/var/run/nscd" },15) ERR#2 'No such file or > directory' > close(4) = 0 (0x0) > sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) > = 0 (0x0) > sigaction(SIGPIPE,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 > (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > stat("/usr/local/etc/nss_ldap.conf",{ mode=-rw-r--r-- > ,inode=5818085,size=7997,blksize=16384 }) = 0 (0x0) > getpid() = 3235 (0xca3) > geteuid() = 2002 (0x7d2) > SIGNAL 11 (SIGSEGV) > process exit, rval = 0 Deleting /usr/local/etc/nss_ldap.conf, which is a link (hard or soft, doesn't matter the result) to /usr/local/etc/ldap.conf, makes Thunderbird start again as OpenLDAP backend wasn't configured/installed. But in that case, no OpenLDAP backed up users are available on the system. From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 09:39:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B21B0C3E for ; Sat, 9 Mar 2013 09:39:24 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 776687C4 for ; Sat, 9 Mar 2013 09:39:24 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 6DA63E3F07A for ; Sat, 9 Mar 2013 10:39:23 +0100 (CET) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEpH42o-pzSd for ; Sat, 9 Mar 2013 10:39:21 +0100 (CET) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id ED9CBE3F079 for ; Sat, 9 Mar 2013 10:39:20 +0100 (CET) Date: Sat, 9 Mar 2013 10:39:20 +0100 From: Joel Dahl To: current@freebsd.org Subject: Panic during boot with fresh CURRENT (r248090) Message-ID: <20130309093919.GJ17537@devbox.vnode.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 09:39:24 -0000 Hi, Just updated to the latest CURRENT. Got this during boot: (sorry for the large image) http://mirror.vnode.se/upload/r248090_panic.jpg -- Joel From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 10:17:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9D2FE5E1 for ; Sat, 9 Mar 2013 10:17:50 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 43C6A905 for ; Sat, 9 Mar 2013 10:17:50 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 187A0E3F07A for ; Sat, 9 Mar 2013 11:17:49 +0100 (CET) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RILAg3TTrBgs for ; Sat, 9 Mar 2013 11:17:47 +0100 (CET) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id B2D23E3F079 for ; Sat, 9 Mar 2013 11:17:46 +0100 (CET) Date: Sat, 9 Mar 2013 11:17:45 +0100 From: Joel Dahl To: current@freebsd.org Subject: Re: Panic during boot with fresh CURRENT (r248090) Message-ID: <20130309101745.GK17537@devbox.vnode.local> References: <20130309093919.GJ17537@devbox.vnode.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130309093919.GJ17537@devbox.vnode.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 10:17:50 -0000 On Sat, Mar 09, 2013 at 10:39:20AM +0100, Joel Dahl wrote: > Hi, > > Just updated to the latest CURRENT. Got this during boot: > (sorry for the large image) > > http://mirror.vnode.se/upload/r248090_panic.jpg This is fixed with r248093. -- Joel From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 10:58:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1ECC3AF8 for ; Sat, 9 Mar 2013 10:58:20 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id BBB9C9F6 for ; Sat, 9 Mar 2013 10:58:19 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1UEHTm-000yQa-H2>; Sat, 09 Mar 2013 11:58:18 +0100 Received: from e178025158.adsl.alicedsl.de ([85.178.25.158] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1UEHTm-0039ZK-EW>; Sat, 09 Mar 2013 11:58:18 +0100 Message-ID: <513B1609.3020204@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 11:59:21 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd Current Subject: r248093: Kernel build failure: /usr/src/sys/net80211/ieee80211_output.c:600:23: error: unused variable 'ic' [-Werror,-Wunused-variable] Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.25.158 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Mar 2013 10:58:20 -0000 On CURRENT, r248093, build of kernel fails due to the below shown error. [...] cc -c -O3 -O3 -Wno-error=unused-variable -fno-strict-aliasing -march=native -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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_global.h -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/net80211/ieee80211_output.c /usr/src/sys/net80211/ieee80211_output.c:600:23: error: unused variable 'ic' [-Werror,-Wunused-variable] struct ieee80211com *ic = ni->ni_ic; ^ 1 error generated. *** [ieee80211_output.o] Error code 1 Stop in /usr/obj/usr/src/sys/GATE. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. Oliver From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 08:07:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0A920632 for ; Sat, 9 Mar 2013 08:07:06 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 6F71D331 for ; Sat, 9 Mar 2013 08:07:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=ltthjTwdBp15RrFBPSURAXGikPSqP/MnvC4Fn8x+xnc=; b=TRqUF9gnxLVXDx6duByYkWXHS5vwgGuu1fz4gJ20rKQiYM/kS+kLkLbt9OKr0fRjNNt/R1q9TgivmSE3KEz2moIAEXyephgnjmkHG+aj3bY4Av5JLNxCVYZthHhh9QaJ; Received: from [122.129.203.50] (port=62858 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UEEnp-003oY9-OE; Sat, 09 Mar 2013 01:06:57 -0700 Date: Sat, 9 Mar 2013 15:06:45 +0700 From: Erich Dollansky To: Yasir hussan Subject: Re: multi-homing in freebsd Message-ID: <20130309150645.04fc5567@X220.ovitrap.com> In-Reply-To: References: Organization: ALO Green Technologies X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Sat, 09 Mar 2013 12:21:19 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 08:07:06 -0000 Hi, On Sat, 9 Mar 2013 03:04:00 -0500 Yasir hussan wrote: > i just want to run multiple IPs for single network card in freebsd it should work with alias of ifconfig Erich > > On Sat, Mar 9, 2013 at 2:55 AM, Yasir hussan > wrote: > > > Hi, > > > > Does anyone know usage of multi-homing in freebsd, if YES kindly > > guid me how i can test it on my own PC. > > > > Thanks > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 12:29:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C5DD64A for ; Sat, 9 Mar 2013 12:29:36 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mx1.freebsd.org (Postfix) with ESMTP id BEA1CDA6 for ; Sat, 9 Mar 2013 12:29:34 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id gf7so2025918lbb.32 for ; Sat, 09 Mar 2013 04:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R7+d+2RcpB+857OxBGwbC3k/cBrFhqGrB3O2PeX0hAs=; b=tAsChYZWIMSrDHDnIwrCCVTUIz3u7Nsceu2caABF8/KtzrsrApmAQfbSQzLc5cjBp2 Kp2HNCdSEDilRkjcSV5b8gZHZWnYnGRMvLjvi1m/VLKFnYHXZwKY93Pskg6JNfUxFYel mOUH3s5TBaLK1JN2IpetBM6bVvNibnqL7lrYxaudn7q7pKEoLFE6Nu5GTKz7qpeWtLeS It1p85N5cHhdaVqeZP7luj8G2TjFWxyfpO3F1cXCLQ9V1IrraIbxEzuOzAUv5QBDAfzH 7Zup67GEc/9+QgzKilQPDZali5wiBhJagl8hsVOz9yylzpbcS58VMsWYutvvPJm8gMQF PWxQ== MIME-Version: 1.0 X-Received: by 10.152.123.34 with SMTP id lx2mr4861491lab.52.1362832167929; Sat, 09 Mar 2013 04:29:27 -0800 (PST) Received: by 10.112.80.133 with HTTP; Sat, 9 Mar 2013 04:29:27 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Mar 2013 13:29:27 +0100 Message-ID: Subject: Re: multi-homing in freebsd From: Daniel Nebdal To: Yasir hussan Content-Type: text/plain; charset=ISO-8859-1 Cc: Zaphod Beeblebrox , Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 12:29:36 -0000 Going by Zaphod's recommendation of using a /32 for each IP, how about this? ifconfig arge0 inet 192.168.1.100/32 ifconfig arge0 alias 192.169.1.100/32 I wouldn't recommend 192.169, though - only 192.168.x.x is reserved for private networks, and 192.169 is a valid IP-routable prefix, assigned to some US company. To be exact: The ranges from RFC1918 are 10.0.0.0/8, 172.16.0.0 /20 and 192.168.0.0/24. On Sat, Mar 9, 2013 at 9:57 AM, Yasir hussan wrote: > Kindly will u give me example with cammand line, which can test on my > freebsd machine, i want two ips 192.168.1.100 and 192.169.1.100 to be work > on single network interface, my default interface for network is arge0 > > On Sat, Mar 9, 2013 at 3:08 AM, Zaphod Beeblebrox wrote: > >> On Sat, Mar 9, 2013 at 3:04 AM, Yasir hussan wrote: >> >>> i just want to run multiple IPs for single network card in freebsd >>> >>> >> OK. A better question. About the only caution I can give here (assuming >> you don't mean something more interesting like vlans and whatnot) is that >> if both IP addresses are on the SAME network, use a /32 as the netmask (it >> works better). If they are on different networks, specify the netmask as >> normal. >> >> You may, at this point, need a method to choose which IP address to use >> for any particular connection. There's a pile of documentation waiting for >> you. >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 14:06:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8F928100 for ; Sat, 9 Mar 2013 14:06:07 +0000 (UTC) (envelope-from kolyasir@gmail.com) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by mx1.freebsd.org (Postfix) with ESMTP id 4390A2D7 for ; Sat, 9 Mar 2013 14:06:07 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id q19so1541654qeb.6 for ; Sat, 09 Mar 2013 06:06:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=r840mK1OKzKGEEyPtZxobrnvum535Yf77Q1S9Z+9yX4=; b=ZZ7aivX95PyNmz4/pvMQR8GFvUYBA0ZeCDcaiXNTea2A4X+eYZQHqhYO6FKBNwxGUM sbnRsYiKmvDBhH32mgfffxzRB0sDmvubJ5ohdrmFn6CjBQCURcWh1baVm/n74AMgvlee loL9DKWRHL2SJ6/BM7IED2afB2BQqWNQbAx1ZojLXzyGtNzRhrwXMIOehvOjHkLEeIEi z2O62aE1FItE+ooZnO0JKGR2fBNoeT0zIAFVcjeIb1Qw4B10TSjcndCayIb9fLjhLWIq SM93Zs+yadtUYCMp98UfMMdnxf/gKwIsgQOX84dfbC1Smcg2W21uTUaroSm7Gq13u5D6 Ux9A== MIME-Version: 1.0 X-Received: by 10.224.185.148 with SMTP id co20mr8879691qab.94.1362837476461; Sat, 09 Mar 2013 05:57:56 -0800 (PST) Received: by 10.49.48.197 with HTTP; Sat, 9 Mar 2013 05:57:56 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Mar 2013 08:57:56 -0500 Message-ID: Subject: Re: multi-homing in freebsd From: Yasir hussan To: Daniel Nebdal Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Zaphod Beeblebrox , Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:06:07 -0000 i want to have differnet ips`s and each should have different interface, it could be a virtual interface. like u can made it like *ifconfig arge0.1 create* but each ip should able to access from differnet machine On Sat, Mar 9, 2013 at 7:29 AM, Daniel Nebdal wrote: > Going by Zaphod's recommendation of using a /32 for each IP, how about > this? > > ifconfig arge0 inet 192.168.1.100/32 > ifconfig arge0 alias 192.169.1.100/32 > > I wouldn't recommend 192.169, though - only 192.168.x.x is reserved > for private networks, and 192.169 is a valid IP-routable prefix, > assigned to some US company. > To be exact: The ranges from RFC1918 are 10.0.0.0/8, 172.16.0.0 /20 > and 192.168.0.0/24. > > On Sat, Mar 9, 2013 at 9:57 AM, Yasir hussan wrote: > > Kindly will u give me example with cammand line, which can test on my > > freebsd machine, i want two ips 192.168.1.100 and 192.169.1.100 to be > work > > on single network interface, my default interface for network is arge0 > > > > On Sat, Mar 9, 2013 at 3:08 AM, Zaphod Beeblebrox > wrote: > > > >> On Sat, Mar 9, 2013 at 3:04 AM, Yasir hussan > wrote: > >> > >>> i just want to run multiple IPs for single network card in freebsd > >>> > >>> > >> OK. A better question. About the only caution I can give here > (assuming > >> you don't mean something more interesting like vlans and whatnot) is > that > >> if both IP addresses are on the SAME network, use a /32 as the netmask > (it > >> works better). If they are on different networks, specify the netmask > as > >> normal. > >> > >> You may, at this point, need a method to choose which IP address to use > >> for any particular connection. There's a pile of documentation waiting > for > >> you. > >> > >> > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 14:21:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DAD35583; Sat, 9 Mar 2013 14:21:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 74F0B383; Sat, 9 Mar 2013 14:21:05 +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 r29EL4Yd080302; Sat, 9 Mar 2013 09:21:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r29EL4Jc080297; Sat, 9 Mar 2013 14:21:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Mar 2013 14:21:04 GMT Message-Id: <201303091421.r29EL4Jc080297@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:21:05 -0000 TB --- 2013-03-09 11:30:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-09 11:30:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-09 11:30:25 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-09 11:30:25 - cleaning the object tree TB --- 2013-03-09 11:31:57 - /usr/local/bin/svn stat /src TB --- 2013-03-09 11:32:00 - At svn revision 248093 TB --- 2013-03-09 11:32:01 - building world TB --- 2013-03-09 11:32:01 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 11:32:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 11:32:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 11:32:01 - SRCCONF=/dev/null TB --- 2013-03-09 11:32:01 - TARGET=arm TB --- 2013-03-09 11:32:01 - TARGET_ARCH=arm TB --- 2013-03-09 11:32:01 - TZ=UTC TB --- 2013-03-09 11:32:01 - __MAKE_CONF=/dev/null TB --- 2013-03-09 11:32:01 - cd /src TB --- 2013-03-09 11:32:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 9 11:32:05 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 9 13:22:18 UTC 2013 TB --- 2013-03-09 13:22:18 - generating LINT kernel config TB --- 2013-03-09 13:22:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:22:18 - /usr/bin/make -B LINT TB --- 2013-03-09 13:22:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:22:18 - /usr/sbin/config -m LINT TB --- 2013-03-09 13:22:18 - building LINT kernel TB --- 2013-03-09 13:22:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:22:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:22:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:22:18 - SRCCONF=/dev/null TB --- 2013-03-09 13:22:18 - TARGET=arm TB --- 2013-03-09 13:22:18 - TARGET_ARCH=arm TB --- 2013-03-09 13:22:18 - TZ=UTC TB --- 2013-03-09 13:22:18 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:22:18 - cd /src TB --- 2013-03-09 13:22:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 9 13:22:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Mar 9 13:42:15 UTC 2013 TB --- 2013-03-09 13:42:15 - cd /src/sys/arm/conf TB --- 2013-03-09 13:42:15 - /usr/sbin/config -m AC100 TB --- 2013-03-09 13:42:15 - skipping AC100 kernel TB --- 2013-03-09 13:42:15 - cd /src/sys/arm/conf TB --- 2013-03-09 13:42:15 - /usr/sbin/config -m ARMADAXP TB --- 2013-03-09 13:42:15 - skipping ARMADAXP kernel TB --- 2013-03-09 13:42:15 - cd /src/sys/arm/conf TB --- 2013-03-09 13:42:15 - /usr/sbin/config -m ATMEL TB --- 2013-03-09 13:42:15 - building ATMEL kernel TB --- 2013-03-09 13:42:15 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:42:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:42:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:42:15 - SRCCONF=/dev/null TB --- 2013-03-09 13:42:15 - TARGET=arm TB --- 2013-03-09 13:42:15 - TARGET_ARCH=arm TB --- 2013-03-09 13:42:15 - TZ=UTC TB --- 2013-03-09 13:42:15 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:42:15 - cd /src TB --- 2013-03-09 13:42:15 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Sat Mar 9 13:42:15 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Sat Mar 9 13:46:18 UTC 2013 TB --- 2013-03-09 13:46:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:46:18 - /usr/sbin/config -m AVILA TB --- 2013-03-09 13:46:18 - skipping AVILA kernel TB --- 2013-03-09 13:46:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:46:18 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-03-09 13:46:18 - skipping BEAGLEBONE kernel TB --- 2013-03-09 13:46:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:46:18 - /usr/sbin/config -m BWCT TB --- 2013-03-09 13:46:18 - building BWCT kernel TB --- 2013-03-09 13:46:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:46:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:46:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:46:18 - SRCCONF=/dev/null TB --- 2013-03-09 13:46:18 - TARGET=arm TB --- 2013-03-09 13:46:18 - TARGET_ARCH=arm TB --- 2013-03-09 13:46:18 - TZ=UTC TB --- 2013-03-09 13:46:18 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:46:18 - cd /src TB --- 2013-03-09 13:46:18 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Mar 9 13:46:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sat Mar 9 13:48:38 UTC 2013 TB --- 2013-03-09 13:48:38 - cd /src/sys/arm/conf TB --- 2013-03-09 13:48:38 - /usr/sbin/config -m CAMBRIA TB --- 2013-03-09 13:48:38 - skipping CAMBRIA kernel TB --- 2013-03-09 13:48:38 - cd /src/sys/arm/conf TB --- 2013-03-09 13:48:38 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-03-09 13:48:38 - building CNS11XXNAS kernel TB --- 2013-03-09 13:48:38 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:48:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:48:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:48:38 - SRCCONF=/dev/null TB --- 2013-03-09 13:48:38 - TARGET=arm TB --- 2013-03-09 13:48:38 - TARGET_ARCH=arm TB --- 2013-03-09 13:48:38 - TZ=UTC TB --- 2013-03-09 13:48:38 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:48:38 - cd /src TB --- 2013-03-09 13:48:38 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Mar 9 13:48:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sat Mar 9 13:51:13 UTC 2013 TB --- 2013-03-09 13:51:13 - cd /src/sys/arm/conf TB --- 2013-03-09 13:51:13 - /usr/sbin/config -m CRB TB --- 2013-03-09 13:51:13 - skipping CRB kernel TB --- 2013-03-09 13:51:13 - cd /src/sys/arm/conf TB --- 2013-03-09 13:51:13 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-03-09 13:51:13 - skipping CUBIEBOARD kernel TB --- 2013-03-09 13:51:13 - cd /src/sys/arm/conf TB --- 2013-03-09 13:51:13 - /usr/sbin/config -m DB-78XXX TB --- 2013-03-09 13:51:13 - building DB-78XXX kernel TB --- 2013-03-09 13:51:13 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:51:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:51:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:51:13 - SRCCONF=/dev/null TB --- 2013-03-09 13:51:13 - TARGET=arm TB --- 2013-03-09 13:51:13 - TARGET_ARCH=arm TB --- 2013-03-09 13:51:13 - TZ=UTC TB --- 2013-03-09 13:51:13 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:51:13 - cd /src TB --- 2013-03-09 13:51:13 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Mar 9 13:51:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sat Mar 9 13:54:02 UTC 2013 TB --- 2013-03-09 13:54:02 - cd /src/sys/arm/conf TB --- 2013-03-09 13:54:02 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-03-09 13:54:02 - building DB-88F5XXX kernel TB --- 2013-03-09 13:54:02 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:54:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:54:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:54:02 - SRCCONF=/dev/null TB --- 2013-03-09 13:54:02 - TARGET=arm TB --- 2013-03-09 13:54:02 - TARGET_ARCH=arm TB --- 2013-03-09 13:54:02 - TZ=UTC TB --- 2013-03-09 13:54:02 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:54:02 - cd /src TB --- 2013-03-09 13:54:02 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Mar 9 13:54:02 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sat Mar 9 13:56:44 UTC 2013 TB --- 2013-03-09 13:56:44 - cd /src/sys/arm/conf TB --- 2013-03-09 13:56:44 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-03-09 13:56:44 - building DB-88F6XXX kernel TB --- 2013-03-09 13:56:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:56:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:56:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:56:44 - SRCCONF=/dev/null TB --- 2013-03-09 13:56:44 - TARGET=arm TB --- 2013-03-09 13:56:44 - TARGET_ARCH=arm TB --- 2013-03-09 13:56:44 - TZ=UTC TB --- 2013-03-09 13:56:44 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:56:44 - cd /src TB --- 2013-03-09 13:56:44 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Mar 9 13:56:44 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sat Mar 9 13:59:43 UTC 2013 TB --- 2013-03-09 13:59:43 - cd /src/sys/arm/conf TB --- 2013-03-09 13:59:43 - /usr/sbin/config -m DOCKSTAR TB --- 2013-03-09 13:59:43 - building DOCKSTAR kernel TB --- 2013-03-09 13:59:43 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:59:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:59:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:59:43 - SRCCONF=/dev/null TB --- 2013-03-09 13:59:43 - TARGET=arm TB --- 2013-03-09 13:59:43 - TARGET_ARCH=arm TB --- 2013-03-09 13:59:43 - TZ=UTC TB --- 2013-03-09 13:59:43 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:59:43 - cd /src TB --- 2013-03-09 13:59:43 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Mar 9 13:59:43 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sat Mar 9 14:02:24 UTC 2013 TB --- 2013-03-09 14:02:24 - cd /src/sys/arm/conf TB --- 2013-03-09 14:02:24 - /usr/sbin/config -m DREAMPLUG-1001 TB --- 2013-03-09 14:02:24 - building DREAMPLUG-1001 kernel TB --- 2013-03-09 14:02:24 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 14:02:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 14:02:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 14:02:24 - SRCCONF=/dev/null TB --- 2013-03-09 14:02:24 - TARGET=arm TB --- 2013-03-09 14:02:24 - TARGET_ARCH=arm TB --- 2013-03-09 14:02:24 - TZ=UTC TB --- 2013-03-09 14:02:24 - __MAKE_CONF=/dev/null TB --- 2013-03-09 14:02:24 - cd /src TB --- 2013-03-09 14:02:24 - /usr/bin/make -B buildkernel KERNCONF=DREAMPLUG-1001 >>> Kernel build for DREAMPLUG-1001 started on Sat Mar 9 14:02:24 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DREAMPLUG-1001 completed on Sat Mar 9 14:06:17 UTC 2013 TB --- 2013-03-09 14:06:17 - cd /src/sys/arm/conf TB --- 2013-03-09 14:06:17 - /usr/sbin/config -m EA3250 TB --- 2013-03-09 14:06:17 - building EA3250 kernel TB --- 2013-03-09 14:06:17 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 14:06:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 14:06:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 14:06:17 - SRCCONF=/dev/null TB --- 2013-03-09 14:06:17 - TARGET=arm TB --- 2013-03-09 14:06:17 - TARGET_ARCH=arm TB --- 2013-03-09 14:06:17 - TZ=UTC TB --- 2013-03-09 14:06:17 - __MAKE_CONF=/dev/null TB --- 2013-03-09 14:06:17 - cd /src TB --- 2013-03-09 14:06:17 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Sat Mar 9 14:06:17 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Sat Mar 9 14:09:05 UTC 2013 TB --- 2013-03-09 14:09:05 - cd /src/sys/arm/conf TB --- 2013-03-09 14:09:05 - /usr/sbin/config -m EB9200 TB --- 2013-03-09 14:09:05 - building EB9200 kernel TB --- 2013-03-09 14:09:05 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 14:09:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 14:09:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 14:09:05 - SRCCONF=/dev/null TB --- 2013-03-09 14:09:05 - TARGET=arm TB --- 2013-03-09 14:09:05 - TARGET_ARCH=arm TB --- 2013-03-09 14:09:05 - TZ=UTC TB --- 2013-03-09 14:09:05 - __MAKE_CONF=/dev/null TB --- 2013-03-09 14:09:05 - cd /src TB --- 2013-03-09 14:09:05 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Sat Mar 9 14:09:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EB9200 completed on Sat Mar 9 14:11:41 UTC 2013 TB --- 2013-03-09 14:11:41 - cd /src/sys/arm/conf TB --- 2013-03-09 14:11:41 - /usr/sbin/config -m EP80219 TB --- 2013-03-09 14:11:41 - skipping EP80219 kernel TB --- 2013-03-09 14:11:41 - cd /src/sys/arm/conf TB --- 2013-03-09 14:11:41 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-03-09 14:11:41 - building ETHERNUT5 kernel TB --- 2013-03-09 14:11:41 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 14:11:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 14:11:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 14:11:41 - SRCCONF=/dev/null TB --- 2013-03-09 14:11:41 - TARGET=arm TB --- 2013-03-09 14:11:41 - TARGET_ARCH=arm TB --- 2013-03-09 14:11:41 - TZ=UTC TB --- 2013-03-09 14:11:41 - __MAKE_CONF=/dev/null TB --- 2013-03-09 14:11:41 - cd /src TB --- 2013-03-09 14:11:41 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sat Mar 9 14:11:41 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_input.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_ioctl.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_node.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_output.c cc1: warnings being treated as errors /src/sys/modules/wlan/../../net80211/ieee80211_output.c: In function 'ieee80211_send_setup': /src/sys/modules/wlan/../../net80211/ieee80211_output.c:600: warning: unused variable 'ic' [-Wunused-variable] *** [ieee80211_output.o] Error code 1 Stop in /src/sys/modules/wlan. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-09 14:21:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-09 14:21:04 - ERROR: failed to build ETHERNUT5 kernel TB --- 2013-03-09 14:21:04 - 8060.01 user 1475.91 system 10238.58 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 14:34:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C26C5E0E for ; Sat, 9 Mar 2013 14:34:25 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by mx1.freebsd.org (Postfix) with ESMTP id 5FCA0638 for ; Sat, 9 Mar 2013 14:34:24 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id c50so1549422eek.16 for ; Sat, 09 Mar 2013 06:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Eh05bxg3bva2lq0ZqgB145UYgc1TubQpYWNkPkFwq/g=; b=YbLa+KHjsW8DX6hbeaNiwB4caPFvpamrqB2RqZ7buh/yF8VQlmDxfwPH6bo96+PBHc q7T4wYJuLC7OoMMcH/GZEwF3/xzQVZMikdgku0FzF5fNW/X1sVi8vvZ8i9AQ//C70ZY1 BpMmirEFO0hPLS6JbZnobw3MeaKEm1WexGUMm4hQyFa+dAiVpGHegVSjyhHYhp11MOzl rE0XNQNgT5aBYbvh9+ilHrFTuOLr4J94VaOrYtSfoAr/H+2RTRTnE4+8i6QtjmgmU5mw pf7CDzRgkYA03IZr7upRkOuYWC9W1c/utL3P3/dMN7dszcTMhYuzoFDBLCaL0zcBtv/1 g6mg== MIME-Version: 1.0 X-Received: by 10.14.219.129 with SMTP id m1mr11394511eep.16.1362839663928; Sat, 09 Mar 2013 06:34:23 -0800 (PST) Received: by 10.14.133.204 with HTTP; Sat, 9 Mar 2013 06:34:23 -0800 (PST) Received: by 10.14.133.204 with HTTP; Sat, 9 Mar 2013 06:34:23 -0800 (PST) In-Reply-To: <1362807830.29167.YahooMailClassic@web31805.mail.mud.yahoo.com> References: <1362807830.29167.YahooMailClassic@web31805.mail.mud.yahoo.com> Date: Sat, 9 Mar 2013 06:34:23 -0800 Message-ID: Subject: Re: pw is broken? From: hiren panchasara To: ktsin@acm.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:34:25 -0000 On Mar 8, 2013 9:44 PM, "KT Sin" wrote: > > pw is crashing with seg fault due to this change? > > http://svnweb.freebsd.org/base/head/lib/libutil/gr_util.c?r1=245390&r2=247919 I think the correct fix is committed with: http://svnweb.freebsd.org/changeset/base/248102 Hiren > > # gdb ./pw > 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"... > (gdb) run groupadd test123 -g 12345 > Starting program: /usr/src/usr.sbin/pw/pw groupadd test123 -g 12345 > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 > (gdb) bt full > #0 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 > No symbol table info available. > #1 0x0000000080a5c00a in grcopy (gr=0x612ce0, newgr=0x81409100, name=0x0, > ndx=0) at /usr/src/lib/libutil/gr_util.c:496 > dst = 0x8 > i = 1090277153 > #2 0x0000000080a5bdc6 in gr_add (gr=0x612ce0, newmember=0x0) > at /usr/src/lib/libutil/gr_util.c:451 > newgr = (struct group *) 0x81409100 > len = 0 > num_mem = 0 > #3 0x0000000080a5bd4f in gr_dup (gr=0x612ce0) > at /usr/src/lib/libutil/gr_util.c:434 > No locals. > #4 0x000000000040bad7 in gr_update (grp=0x612ce0, group=0x0) at grupd.c:78 > pfd = 0 > tfd = 4244492 > gr = (struct group *) 0x0 > old_gr = (struct group *) 0x0 > #5 0x000000000040ba8f in addgrent (grp=0x612ce0) at grupd.c:111 > No locals. > #6 0x000000000040a83d in pw_group (cnf=0x612bf0, mode=0, args=0x613e78) > at pw_group.c:258 > ---Type to continue, or q to quit--- > grp = (struct group *) 0x612ce0 > members = (char **) 0x81485d00 > rc = 0 > a_name = (struct carg *) 0x8144c0a0 > a_gid = (struct carg *) 0x8144c0c0 > arg = (struct carg *) 0x0 > grmembers = 200 > fakegroup = {gr_name = 0x7fffffffdcb9 "test123", > gr_passwd = 0x40fbc9 "*", gr_gid = 12345, gr_mem = 0x81485d00} > #7 0x00000000004037fb in main (argc=3, argv=0x7fffffffd9f0) at pw.c:230 > which = 1 > config = 0x0 > cnf = (struct userconf *) 0x612bf0 > ch = -1 > mode = 0 > opts = {{0x40e150 "V:C:qn:u:c:d:e:p:g:G:mM:k:s:oL:i:w:h:H:Db:NPy:Y", > 0x40e180 "V:C:qn:u:rY", > 0x40e18c "V:C:qn:u:c:d:e:p:g:G:mM:l:k:s:w:L:h:H:FNPY", > 0x40e1b7 "V:C:qn:u:FPa7", 0x40e1c5 "V:C:q", 0x40e1c5 "V:C:q", > 0x40e1c5 "V:C:q"}, {0x40e1cb "V:C:qn:g:h:H:M:opNPY", > 0x40e1e0 "V:C:qn:g:Y", 0x40e1eb "V:C:qn:d:g:l:h:H:FM:m:NPY", > 0x40e205 "V:C:qn:g:FPa", 0x40e1c5 "V:C:q", 0x0, 0x0}} > funcs = {0x405270 , 0x409b60 } > (gdb) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 14:51:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1B7757B for ; Sat, 9 Mar 2013 14:51:07 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id B612E70B for ; Sat, 9 Mar 2013 14:51:07 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UEL74-001Vq2-Dt>; Sat, 09 Mar 2013 15:51:06 +0100 Received: from e178025158.adsl.alicedsl.de ([85.178.25.158] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UEL74-003LJ6-Ah>; Sat, 09 Mar 2013 15:51:06 +0100 Message-ID: <513B4C9A.8070602@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 15:52:10 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: hiren panchasara Subject: Re: pw is broken? References: <1362807830.29167.YahooMailClassic@web31805.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.25.158 Cc: ktsin@acm.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:51:08 -0000 Am 03/09/13 15:34, schrieb hiren panchasara: > On Mar 8, 2013 9:44 PM, "KT Sin" wrote: >> >> pw is crashing with seg fault due to this change? >> >> > http://svnweb.freebsd.org/base/head/lib/libutil/gr_util.c?r1=245390&r2=247919 > > I think the correct fix is committed with: > http://svnweb.freebsd.org/changeset/base/248102 > > Hiren >> >> # gdb ./pw >> 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"... >> (gdb) run groupadd test123 -g 12345 >> Starting program: /usr/src/usr.sbin/pw/pw groupadd test123 -g 12345 >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 >> (gdb) bt full >> #0 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 >> No symbol table info available. >> #1 0x0000000080a5c00a in grcopy (gr=0x612ce0, newgr=0x81409100, name=0x0, >> ndx=0) at /usr/src/lib/libutil/gr_util.c:496 >> dst = 0x8 >> i = 1090277153 >> #2 0x0000000080a5bdc6 in gr_add (gr=0x612ce0, newmember=0x0) >> at /usr/src/lib/libutil/gr_util.c:451 >> newgr = (struct group *) 0x81409100 >> len = 0 >> num_mem = 0 >> #3 0x0000000080a5bd4f in gr_dup (gr=0x612ce0) >> at /usr/src/lib/libutil/gr_util.c:434 >> No locals. >> #4 0x000000000040bad7 in gr_update (grp=0x612ce0, group=0x0) at > grupd.c:78 >> pfd = 0 >> tfd = 4244492 >> gr = (struct group *) 0x0 >> old_gr = (struct group *) 0x0 >> #5 0x000000000040ba8f in addgrent (grp=0x612ce0) at grupd.c:111 >> No locals. >> #6 0x000000000040a83d in pw_group (cnf=0x612bf0, mode=0, args=0x613e78) >> at pw_group.c:258 >> ---Type to continue, or q to quit--- >> grp = (struct group *) 0x612ce0 >> members = (char **) 0x81485d00 >> rc = 0 >> a_name = (struct carg *) 0x8144c0a0 >> a_gid = (struct carg *) 0x8144c0c0 >> arg = (struct carg *) 0x0 >> grmembers = 200 >> fakegroup = {gr_name = 0x7fffffffdcb9 "test123", >> gr_passwd = 0x40fbc9 "*", gr_gid = 12345, gr_mem = 0x81485d00} >> #7 0x00000000004037fb in main (argc=3, argv=0x7fffffffd9f0) at pw.c:230 >> which = 1 >> config = 0x0 >> cnf = (struct userconf *) 0x612bf0 >> ch = -1 >> mode = 0 >> opts = {{0x40e150 > "V:C:qn:u:c:d:e:p:g:G:mM:k:s:oL:i:w:h:H:Db:NPy:Y", >> 0x40e180 "V:C:qn:u:rY", >> 0x40e18c "V:C:qn:u:c:d:e:p:g:G:mM:l:k:s:w:L:h:H:FNPY", >> 0x40e1b7 "V:C:qn:u:FPa7", 0x40e1c5 "V:C:q", 0x40e1c5 "V:C:q", >> 0x40e1c5 "V:C:q"}, {0x40e1cb "V:C:qn:g:h:H:M:opNPY", >> 0x40e1e0 "V:C:qn:g:Y", 0x40e1eb "V:C:qn:d:g:l:h:H:FM:m:NPY", >> 0x40e205 "V:C:qn:g:FPa", 0x40e1c5 "V:C:q", 0x0, 0x0}} >> funcs = {0x405270 , 0x409b60 } >> (gdb) But neither r248102 nor r248103 compile! /usr/src/sys/net80211/ieee80211_output.c:600:23: error: unused variable 'ic' [-Werror,-Wunused-variable] struct ieee80211com *ic = ni->ni_ic;) ( From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 15:03:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80175A33 for ; Sat, 9 Mar 2013 15:03:05 +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 5F284795 for ; Sat, 9 Mar 2013 15:03:05 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r29F34fO067199; Sat, 9 Mar 2013 07:03:04 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r29F34UX067198; Sat, 9 Mar 2013 07:03:04 -0800 (PST) (envelope-from david) Date: Sat, 9 Mar 2013 07:03:04 -0800 From: David Wolfskill To: "Hartmann, O." Subject: Re: r248093: Kernel build failure: /usr/src/sys/net80211/ieee80211_output.c:600:23: error: unused variable 'ic' [-Werror,-Wunused-variable] Message-ID: <20130309150304.GQ13861@albert.catwhisker.org> References: <513B1609.3020204@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/2aDF+7ylDoDOrjt" Content-Disposition: inline In-Reply-To: <513B1609.3020204@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 15:03:05 -0000 --/2aDF+7ylDoDOrjt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 09, 2013 at 11:59:21AM +0100, Hartmann, O. wrote: > On CURRENT, r248093, build of kernel fails due to the below shown error. >=20 > [...] >=20 > cc -c -O3 -O3 -Wno-error=3Dunused-variable -fno-strict-aliasing > ... > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > /usr/src/sys/net80211/ieee80211_output.c > /usr/src/sys/net80211/ieee80211_output.c:600:23: error: unused variable > 'ic' [-Werror,-Wunused-variable] > struct ieee80211com *ic =3D ni->ni_ic; > ^ > 1 error generated. > *** [ieee80211_output.o] Error code 1 >=20 > Stop in /usr/obj/usr/src/sys/GATE. > *** [buildkernel] Error code 1 >=20 > Stop in /usr/src. > *** [buildkernel] Error code 1 >=20 > Stop in /usr/src. > .... I use clang, and did not encounter that: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #832 r2480= 33M/248035: Fri Mar 8 07:36:04 PST 2013 root@localhost:/usr/obj/usr/sr= c/sys/CANARY i386 Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --/2aDF+7ylDoDOrjt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlE7TycACgkQmprOCmdXAD1D+wCfSdeclQnAQ2JAvDcqOsJmkZME QqYAnRJZh3QFkKhiX/Ay+IUDHYUiQTtl =NhT4 -----END PGP SIGNATURE----- --/2aDF+7ylDoDOrjt-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 15:18:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E9731C6 for ; Sat, 9 Mar 2013 15:18:16 +0000 (UTC) (envelope-from sinkeyteck@yahoo.com) Received: from nm23.bullet.mail.bf1.yahoo.com (nm23.bullet.mail.bf1.yahoo.com [98.139.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE85F847 for ; Sat, 9 Mar 2013 15:18:15 +0000 (UTC) Received: from [98.139.212.148] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 15:16:00 -0000 Received: from [98.139.212.215] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 15:16:00 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 15:16:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 830124.48849.bm@omp1024.mail.bf1.yahoo.com Received: (qmail 24320 invoked by uid 60001); 9 Mar 2013 15:16:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362842160; bh=x+cgvhDXF1PY+Ni0KB+SEOaj151ePCSDZAviVYIhydo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LtjEkNbPSrQGWuE1IlVtlsVk/zuoKCnFu00lWlIGdZNhOW+xR3DLfgrhVj+bNw+LpHlfvk+9jQ5VbxIbZK0y9XajWnrJikx7KxCYgoatfn2yymCOfrTq1R53LCrRlqvxmwljegEmX9aZRJkad/6Lv5Uho59+/4kGj5o8M5I5PVA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iRd9L0nvgoWOAemEhZOgrOmw9mBU+PyJ14di/m/I/u2SBn9IScj3QNz13rv3Jmtgu4+cXKP3R1s51GWIfd+zd2o2blHirw0Bt2yuklXH9QK90BQtbs9s3OSQlmkvPpfeuIqNl+GAlN5Wo3lp5UOEcV64TxWRR0aKNxD1KyTrixo=; X-YMail-OSG: Uzt2ykIVM1nuEqrH5u5CxkmFsr_pcoX13DbMkgCuELxjy4C CAv4eMPAJDiLf688oqcXcKpTKIeYvzTPBw1kZaVgWq7wqXcooBOcL4PzpcGz _ii8bswpM.O6EEZYZSH0WegdZ8GU9NkWiJU3r2THMtc810hMw_8yKS161iz9 LRDS6h7fYaScEhl2HUQ9BZfjOmOJlMctDC3pktK.Q0GT2BD4SGuxqnbDVz8t qWsVbVPk2dxfMU0S.lBlHOknY6QmnoLWjhKrB3GTxV1e4Cvase3Dss2TDLlo 3v8e6d7ZnmYGZcpdv7e989XyhLGT.vJksudGAZWnAXmRXcZcV95DlWCpaQi7 rIlwOG5mow5vopcrU3vhEryV2ugn0AG.XBxAln4Qz50.qhaFH8DgDUIl1hQx IW_ewiqnzeUcgYlgl8NCHE_TLHZSL8Uc4N3VhDaD64l6pK_1.sYr3lnKzcDc Vzz1cRoOrS1Lm928IQzWnQPO83CManiUvHLYNWz3prZ.IX0p6WQbyOf8W077 fQQAnctGzVYm59INrM2A- Received: from [106.10.199.27] by web31816.mail.mud.yahoo.com via HTTP; Sat, 09 Mar 2013 07:15:59 PST X-Rocket-MIMEInfo: 002.001, c2F3IHRoZSBjb21taXQgYW4gaG91ciBhZ28uIHJlYnVpbHQgbGlidXRpbC5zby45IGFuZCB1bmZvcnR1bmF0ZWx5IGl0IHN0aWxsIGNyYXNoZXMgZm9yIG1lIDooDQoNCi0tLSBPbiBTYXQsIDMvOS8xMywgaGlyZW4gcGFuY2hhc2FyYSA8aGlyZW4ucGFuY2hhc2FyYUBnbWFpbC5jb20.IHdyb3RlOg0KDQpGcm9tOiBoaXJlbiBwYW5jaGFzYXJhIDxoaXJlbi5wYW5jaGFzYXJhQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBwdyBpcyBicm9rZW4_DQpUbzoga3RzaW5AYWNtLm9yZw0KQ2M6ICJmcmVlYnNkLWN1cnIBMAEBAQE- X-RocketYMMF: sinkeyteck X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.137.519 Message-ID: <1362842159.24304.YahooMailClassic@web31816.mail.mud.yahoo.com> Date: Sat, 9 Mar 2013 07:15:59 -0800 (PST) From: KT Sin Subject: Re: pw is broken? To: hiren panchasara , db@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ktsin@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 15:18:16 -0000 saw the commit an hour ago. rebuilt libutil.so.9 and unfortunately it still= crashes for me :( --- On Sat, 3/9/13, hiren panchasara wrote: From: hiren panchasara Subject: Re: pw is broken? To: ktsin@acm.org Cc: "freebsd-current" Date: Saturday, March 9, 2013, 10:34 PM =0AOn Mar 8, 2013 9:44 PM, "KT Sin" wrote: =0A> =0A> pw is crashing with seg fault due to this change? =0A> =0A> http://svnweb.freebsd.org/base/head/lib/libutil/gr_util.c?r1=3D245390&= r2=3D247919=0AI think the correct fix is committed with: http://svnweb.free= bsd.org/changeset/base/248102=0AHiren =0A> =0A> # gdb ./pw =0A> GNU gdb 6.1.1 [FreeBSD] =0A> Copyright 2004 Free Software Foundation, Inc. =0A> GDB is free software, covered by the GNU General Public License, and y= ou are =0A> welcome to change it and/or distribute copies of it under certain cond= itions. =0A> Type "show copying" to see the conditions. =0A> There is absolutely no warranty for GDB. =A0Type "show warranty" for d= etails. =0A> This GDB was configured as "amd64-marcel-freebsd"... =0A> (gdb) run groupadd test123 -g 12345 =0A> Starting program: /usr/src/usr.sbin/pw/pw groupadd test123 -g 12345 =0A> =0A> Program received signal SIGSEGV, Segmentation fault. =0A> 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 =0A> (gdb) bt full =0A> #0 =A00x0000000080d84a4f in stpcpy () from /lib/libc.so.7 =0A> No symbol table info available. =0A> #1 =A00x0000000080a5c00a in grcopy (gr=3D0x612ce0, newgr=3D0x81409100,= name=3D0x0, =0A> =A0 =A0 ndx=3D0) at /usr/src/lib/libutil/gr_util.c:496 =0A> =A0 =A0 =A0 =A0 dst =3D 0x8 =0A> =A0 =A0 =A0 =A0 i =3D 1090277153 =0A> #2 =A00x0000000080a5bdc6 in gr_add (gr=3D0x612ce0, newmember=3D0x0) =0A> =A0 =A0 at /usr/src/lib/libutil/gr_util.c:451 =0A> =A0 =A0 =A0 =A0 newgr =3D (struct group *) 0x81409100 =0A> =A0 =A0 =A0 =A0 len =3D 0 =0A> =A0 =A0 =A0 =A0 num_mem =3D 0 =0A> #3 =A00x0000000080a5bd4f in gr_dup (gr=3D0x612ce0) =0A> =A0 =A0 at /usr/src/lib/libutil/gr_util.c:434 =0A> No locals. =0A> #4 =A00x000000000040bad7 in gr_update (grp=3D0x612ce0, group=3D0x0) at= grupd.c:78 =0A> =A0 =A0 =A0 =A0 pfd =3D 0 =0A> =A0 =A0 =A0 =A0 tfd =3D 4244492 =0A> =A0 =A0 =A0 =A0 gr =3D (struct group *) 0x0 =0A> =A0 =A0 =A0 =A0 old_gr =3D (struct group *) 0x0 =0A> #5 =A00x000000000040ba8f in addgrent (grp=3D0x612ce0) at grupd.c:111 =0A> No locals. =0A> #6 =A00x000000000040a83d in pw_group (cnf=3D0x612bf0, mode=3D0, args= =3D0x613e78) =0A> =A0 =A0 at pw_group.c:258 =0A> ---Type to continue, or q to quit--- =0A> =A0 =A0 =A0 =A0 grp =3D (struct group *) 0x612ce0 =0A> =A0 =A0 =A0 =A0 members =3D (char **) 0x81485d00 =0A> =A0 =A0 =A0 =A0 rc =3D 0 =0A> =A0 =A0 =A0 =A0 a_name =3D (struct carg *) 0x8144c0a0 =0A> =A0 =A0 =A0 =A0 a_gid =3D (struct carg *) 0x8144c0c0 =0A> =A0 =A0 =A0 =A0 arg =3D (struct carg *) 0x0 =0A> =A0 =A0 =A0 =A0 grmembers =3D 200 =0A> =A0 =A0 =A0 =A0 fakegroup =3D {gr_name =3D 0x7fffffffdcb9 "test123", =0A> =A0 gr_passwd =3D 0x40fbc9 "*", gr_gid =3D 12345, gr_mem =3D 0x81485d0= 0} =0A> #7 =A00x00000000004037fb in main (argc=3D3, argv=3D0x7fffffffd9f0) at = pw.c:230 =0A> =A0 =A0 =A0 =A0 which =3D 1 =0A> =A0 =A0 =A0 =A0 config =3D 0x0 =0A> =A0 =A0 =A0 =A0 cnf =3D (struct userconf *) 0x612bf0 =0A> =A0 =A0 =A0 =A0 ch =3D -1 =0A> =A0 =A0 =A0 =A0 mode =3D 0 =0A> =A0 =A0 =A0 =A0 opts =3D {{0x40e150 "V:C:qn:u:c:d:e:p:g:G:mM:k:s:oL:i:= w:h:H:Db:NPy:Y", =0A> =A0 =A0 0x40e180 "V:C:qn:u:rY", =0A> =A0 =A0 0x40e18c "V:C:qn:u:c:d:e:p:g:G:mM:l:k:s:w:L:h:H:FNPY", =0A> =A0 =A0 0x40e1b7 "V:C:qn:u:FPa7", 0x40e1c5 "V:C:q", 0x40e1c5 "V:C:q", =0A> =A0 =A0 0x40e1c5 "V:C:q"}, {0x40e1cb "V:C:qn:g:h:H:M:opNPY", =0A> =A0 =A0 0x40e1e0 "V:C:qn:g:Y", 0x40e1eb "V:C:qn:d:g:l:h:H:FM:m:NPY", =0A> =A0 =A0 0x40e205 "V:C:qn:g:FPa", 0x40e1c5 "V:C:q", 0x0, 0x0}} =0A> =A0 =A0 =A0 =A0 funcs =3D {0x405270 , 0x409b60 } =0A> (gdb) =0A> =0A> _______________________________________________ =0A> freebsd-current@freebsd.org mailing list =0A> http://lists.freebsd.org/mailman/listinfo/freebsd-current =0A> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" =0A=0A From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 15:20:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8A56A47C; Sat, 9 Mar 2013 15:20:13 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 2D91F881; Sat, 9 Mar 2013 15:20:12 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id r29EwonH014637; Sat, 9 Mar 2013 15:58:50 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <513B4E2A.3020505@fgznet.ch> Date: Sat, 09 Mar 2013 15:58:50 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Hartmann, O." Subject: Re: pw is broken? References: <1362807830.29167.YahooMailClassic@web31805.mail.mud.yahoo.com> <513B4C9A.8070602@zedat.fu-berlin.de> In-Reply-To: <513B4C9A.8070602@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 15:20:13 -0000 On 09.03.13 15:52, Hartmann, O. wrote: > Am 03/09/13 15:34, schrieb hiren panchasara: >> On Mar 8, 2013 9:44 PM, "KT Sin" wrote: >>> >>> pw is crashing with seg fault due to this change? >>> >>> >> http://svnweb.freebsd.org/base/head/lib/libutil/gr_util.c?r1=245390&r2=247919 >> >> I think the correct fix is committed with: >> http://svnweb.freebsd.org/changeset/base/248102 >> >> Hiren >>> >>> # gdb ./pw >>> 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"... >>> (gdb) run groupadd test123 -g 12345 >>> Starting program: /usr/src/usr.sbin/pw/pw groupadd test123 -g 12345 >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 >>> (gdb) bt full >>> #0 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 >>> No symbol table info available. >>> #1 0x0000000080a5c00a in grcopy (gr=0x612ce0, newgr=0x81409100, name=0x0, >>> ndx=0) at /usr/src/lib/libutil/gr_util.c:496 >>> dst = 0x8 >>> i = 1090277153 >>> #2 0x0000000080a5bdc6 in gr_add (gr=0x612ce0, newmember=0x0) >>> at /usr/src/lib/libutil/gr_util.c:451 >>> newgr = (struct group *) 0x81409100 >>> len = 0 >>> num_mem = 0 >>> #3 0x0000000080a5bd4f in gr_dup (gr=0x612ce0) >>> at /usr/src/lib/libutil/gr_util.c:434 >>> No locals. >>> #4 0x000000000040bad7 in gr_update (grp=0x612ce0, group=0x0) at >> grupd.c:78 >>> pfd = 0 >>> tfd = 4244492 >>> gr = (struct group *) 0x0 >>> old_gr = (struct group *) 0x0 >>> #5 0x000000000040ba8f in addgrent (grp=0x612ce0) at grupd.c:111 >>> No locals. >>> #6 0x000000000040a83d in pw_group (cnf=0x612bf0, mode=0, args=0x613e78) >>> at pw_group.c:258 >>> ---Type to continue, or q to quit--- >>> grp = (struct group *) 0x612ce0 >>> members = (char **) 0x81485d00 >>> rc = 0 >>> a_name = (struct carg *) 0x8144c0a0 >>> a_gid = (struct carg *) 0x8144c0c0 >>> arg = (struct carg *) 0x0 >>> grmembers = 200 >>> fakegroup = {gr_name = 0x7fffffffdcb9 "test123", >>> gr_passwd = 0x40fbc9 "*", gr_gid = 12345, gr_mem = 0x81485d00} >>> #7 0x00000000004037fb in main (argc=3, argv=0x7fffffffd9f0) at pw.c:230 >>> which = 1 >>> config = 0x0 >>> cnf = (struct userconf *) 0x612bf0 >>> ch = -1 >>> mode = 0 >>> opts = {{0x40e150 >> "V:C:qn:u:c:d:e:p:g:G:mM:k:s:oL:i:w:h:H:Db:NPy:Y", >>> 0x40e180 "V:C:qn:u:rY", >>> 0x40e18c "V:C:qn:u:c:d:e:p:g:G:mM:l:k:s:w:L:h:H:FNPY", >>> 0x40e1b7 "V:C:qn:u:FPa7", 0x40e1c5 "V:C:q", 0x40e1c5 "V:C:q", >>> 0x40e1c5 "V:C:q"}, {0x40e1cb "V:C:qn:g:h:H:M:opNPY", >>> 0x40e1e0 "V:C:qn:g:Y", 0x40e1eb "V:C:qn:d:g:l:h:H:FM:m:NPY", >>> 0x40e205 "V:C:qn:g:FPa", 0x40e1c5 "V:C:q", 0x0, 0x0}} >>> funcs = {0x405270 , 0x409b60 } >>> (gdb) > > But neither r248102 nor r248103 compile! > > /usr/src/sys/net80211/ieee80211_output.c:600:23: error: unused variable > 'ic' [-Werror,-Wunused-variable] > struct ieee80211com *ic = ni->ni_ic;) > ( Try this the below. Andreas Index: sys/net80211/ieee80211_output.c =================================================================== --- sys/net80211/ieee80211_output.c (revision 248096) +++ sys/net80211/ieee80211_output.c (working copy) @@ -597,10 +597,9 @@ struct ieee80211vap *vap = ni->ni_vap; struct ieee80211_tx_ampdu *tap; struct ieee80211_frame *wh = mtod(m, struct ieee80211_frame *); - struct ieee80211com *ic = ni->ni_ic; ieee80211_seq seqno; - IEEE80211_TX_LOCK_ASSERT(ic); + IEEE80211_TX_LOCK_ASSERT(ni->ni_ic); wh->i_fc[0] = IEEE80211_FC0_VERSION_0 | type; if ((type & IEEE80211_FC0_TYPE_MASK) == IEEE80211_FC0_TYPE_DATA) { From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 15:20:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E41AD591 for ; Sat, 9 Mar 2013 15:20:51 +0000 (UTC) (envelope-from sinkeyteck@yahoo.com) Received: from nm35-vm7.bullet.mail.bf1.yahoo.com (nm35-vm7.bullet.mail.bf1.yahoo.com [72.30.238.79]) by mx1.freebsd.org (Postfix) with ESMTP id 459CF897 for ; Sat, 9 Mar 2013 15:20:51 +0000 (UTC) Received: from [98.139.212.150] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 15:18:32 -0000 Received: from [98.139.212.232] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 15:18:32 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 15:18:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 251496.52715.bm@omp1041.mail.bf1.yahoo.com Received: (qmail 35342 invoked by uid 60001); 9 Mar 2013 15:18:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362842311; bh=HBLz+wd2LRADiZZYJI7wm0v1V1K0rd8Sid6rjjHoaXg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RxAWYFw2u12ZEgh3mSxZmNLEopnEmvyxQW075HZmuv1AJnmnQu6vIC5HS7AmGkyhWU+CDmKZZB4PWZJVbxwo1T/l4sD698Bfq0NGqmoNtfwnr61j6xTx0olfCzhBwT9HAv7GYOoh37Wc7mG4ULXw9afVWDBmrbnjukMnioN+C3g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AJQqVgIgTNjYw8Wa2CFd96QKPx7LtI9PzzlL/L/mFO9L8btVcLk7mun6EMCcV3CdjkJ60rN403e0cYic2tkV37zmH4Ng2bgo3/QEF+yBb95pSF3pHt3Dle24qxojTtUfOPmCX79B7iYTnJEHYHYvZPP1yxpA07WDfQT1Hiq7rfw=; X-YMail-OSG: yRutTFcVM1lrhFp.0VDRy5ZJG_HNHtlgNSLHm9Jqiia9whw zDhLywvZCfhJPhXVdxU5cXBeE8vweUcYdlpnhA3Hm6YOL1NbPWHp8QMSBS8g VPw3rc0NUNpH2qCWFwL4LlrZk36dQ8i30S9HN3pJCD9fuh6WbH1HdYihZgs_ GUm.yuZ_QCCGWfm8vjcFa.NuncJxFjhIQ.XreVmgObHo.XTeySzt7Wn5fzhe f1PbItzO9hElzkIp2OXnSu0DxshO_q5Syoc3pF_NSTKUOYoMSL_toWqOiUpa rHG61kTsH0.i4wtjc_BcbXfO2IoGMX88I3al7NesqZcpg2wCV8PBmYV3r14T kgHiPeifL6lkP9aOF.uTDA.RsupGrxGJ2TcPgp64bDn6Ap9muGw_UmTxU0sj 1hWi54c77dV3mXoq08J6EWEqab8q3rhjK9y2TBZJb8fnlBHv9w69.O9Pm6qN _y6MIsrgGeUEiPkSEsreYWMFEunzVZYnZfS4lyPSA2eVexf4qT19ps9RZP6u wzWVXNgnxHh6FcYAhfvFEvf4- Received: from [49.125.67.170] by web31802.mail.mud.yahoo.com via HTTP; Sat, 09 Mar 2013 07:18:31 PST X-Rocket-MIMEInfo: 002.001, YWgsIHRoaXMgaXMgYSBkaWZmZXJlbnQgcHJvYmxlbS4gb25lIHF1aWNrIHdvcmthcm91bmQgaXMgdG8gY29tbWVudCBvdXQgdGhlIHVudXNlZCB2YXJpYWJsZSBpYyA6UCwgb3IgeW91IGNvdWxkIGluY2x1ZGUgSU5WQVJJQU5UUyBpbiB5b3VyIGtlcm5lbCBjb25maWcsIG9yIHlvdSBjb3VsZCBwaW5nIGFkcmlhbiA6KQ0KDQotLS0gT24gU2F0LCAzLzkvMTMsIEhhcnRtYW5uLCBPLiA8b2hhcnRtYW5AemVkYXQuZnUtYmVybGluLmRlPiB3cm90ZToNCg0KPiANCj4gQnV0IG5laXRoZXIgcjI0ODEwMiBub3IgcjIBMAEBAQE- X-RocketYMMF: sinkeyteck X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.137.519 Message-ID: <1362842311.34862.YahooMailClassic@web31802.mail.mud.yahoo.com> Date: Sat, 9 Mar 2013 07:18:31 -0800 (PST) From: KT Sin Subject: Re: pw is broken? To: hiren panchasara , " O.Hartmann" In-Reply-To: <513B4C9A.8070602@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ktsin@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 15:20:52 -0000 ah, this is a different problem. one quick workaround is to comment out the= unused variable ic :P, or you could include INVARIANTS in your kernel conf= ig, or you could ping adrian :) --- On Sat, 3/9/13, Hartmann, O. wrote: >=20 > But neither r248102 nor r248103 compile! >=20 > /usr/src/sys/net80211/ieee80211_output.c:600:23: error: > unused variable > 'ic' [-Werror,-Wunused-variable] > =A0 =A0 =A0 =A0 struct ieee80211com *ic =3D > ni->ni_ic;) > ( > From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 15:34:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8815AA9B for ; Sat, 9 Mar 2013 15:34:27 +0000 (UTC) (envelope-from sinkeyteck@yahoo.com) Received: from nm19-vm4.bullet.mail.ne1.yahoo.com (nm19-vm4.bullet.mail.ne1.yahoo.com [98.138.91.179]) by mx1.freebsd.org (Postfix) with ESMTP id 46783975 for ; Sat, 9 Mar 2013 15:34:27 +0000 (UTC) Received: from [98.138.90.49] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 09 Mar 2013 15:32:00 -0000 Received: from [98.138.87.8] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 09 Mar 2013 15:31:59 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 09 Mar 2013 15:31:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 874723.13940.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 66913 invoked by uid 60001); 9 Mar 2013 15:31:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362843119; bh=af8jU3NWcYKQXt/3PBQmRRnL3WTaL8bOM9Pm+rsfLbU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0Tv2esz4DAdqhQ+LfCqx52/9ZgNqNLFlZ7weNXdQqktfgg1QuV/wxc1kLewX5mncIbOQ8EhYuf4ykBzG+fQCFCPfwl/qOB9QB88dR8gS94TP7cQrFvEwSlf9JCh/M6f0AzwCxSYH4czEbPrGmLWBzpHV6jleI/a2k11YvJOT2m0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NVEuWUdlTc71I8YxH3I18fA0gPm9tDYIYGCKcYsld+akQJepszqVqcsXumib3b4LZj1uJyKz4HCDMmUVmh9O8SoiP4QpcD9aCTN51F9g5OFHdr+eK91vWei9yYD/9OthKb6fA2/LwVmbubsVacgFVnsdxajqveXzzeQHiNWRCo8=; X-YMail-OSG: PUSKQZYVM1mewDdwBe1Q3TvHniSyrfaxFGt_n5Q3dErgynT nZcvOgYC1i7TDDMYc6cBSW8ZTHqa0Cxp8PeMITlhpjAL2Y1N3kKAGm85QozF 7YxEIh4m9kaTiKaZfjnTPqGDEU0aYjwi7KHIck5IXGwmtbAPsR_U4lrfVPUD .RmxpxW20h6q0IeVXN0HZbdpX0CHCsWZAcpHjySQGrxOXEWJBNhRMq6n6H8T pH4CrpXUchGYwcecbOqNLRlpr6g50nJP2XfNdp2OfeQcz3gGNSrtmBZmgfRB OE1HjtczHnXKkiJBOdlcOuAn1tUNZ0oRE0qQMfJp9rpgQ5q4_XffIVLU9iP6 .rivf0lve_N_0.Bv00Jd9HRLrCtBK3faP7tFidGBC0xd8px83v7AFKsXCYVS fNxqTH8HOf65ueKF6ePi16c.ddp4JuOy6mF_RPiTeGOOo3O2ERGIGFwb650S hb3u7zWjCOaYjWY6CihIv1DBM6vec7daztIxSK88Zs.5z2HP16WuiIo6oTwU g7eC2WK.2Gy9JXkI_Fg-- Received: from [106.10.199.22] by web31808.mail.mud.yahoo.com via HTTP; Sat, 09 Mar 2013 07:31:59 PST X-Rocket-MIMEInfo: 002.001, YWguIG15IGFwb2xvZ2llcy4gcmVidWlsdCB0aGUgbmV3IGxpYnV0aWwgYWdhaW4gYW5kIGl0IHNlZW1zIHRoYXQgcjI0ODAxMiBkb2VzIGluZGVlZCByZXNvbHZlIHRoZSBwcm9ibGVtLiA6KQ0KDQotLS0gT24gU2F0LCAzLzkvMTMsIEtUIFNpbiA8a3RzaW5AYWNtLm9yZz4gd3JvdGU6DQoNCkZyb206IEtUIFNpbiA8a3RzaW5AYWNtLm9yZz4NClN1YmplY3Q6IFJlOiBwdyBpcyBicm9rZW4_DQpUbzogImhpcmVuIHBhbmNoYXNhcmEiIDxoaXJlbi5wYW5jaGFzYXJhQGdtYWlsLmNvbT4sIGRiQGZyZWVic2Qub3IBMAEBAQE- X-RocketYMMF: sinkeyteck X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.137.519 Message-ID: <1362843119.11984.YahooMailClassic@web31808.mail.mud.yahoo.com> Date: Sat, 9 Mar 2013 07:31:59 -0800 (PST) From: KT Sin Subject: Re: pw is broken? To: hiren panchasara , db@freebsd.org In-Reply-To: <1362842159.24304.YahooMailClassic@web31816.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ktsin@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 15:34:27 -0000 ah. my apologies. rebuilt the new libutil again and it seems that r248012 d= oes indeed resolve the problem. :) --- On Sat, 3/9/13, KT Sin wrote: From: KT Sin Subject: Re: pw is broken? To: "hiren panchasara" , db@freebsd.org Cc: "freebsd-current" Date: Saturday, March 9, 2013, 11:15 PM saw the commit an hour ago. rebuilt libutil.so.9 and unfortunately it still= crashes for me :( --- On Sat, 3/9/13, hiren panchasara wrote: From: hiren panchasara Subject: Re: pw is broken? To: ktsin@acm.org Cc: "freebsd-current" Date: Saturday, March 9, 2013, 10:34 PM =0AOn Mar 8, 2013 9:44 PM, "KT Sin" wrote: =0A> =0A> pw is crashing with seg fault due to this change? =0A> =0A> http://svnweb.freebsd.org/base/head/lib/libutil/gr_util.c?r1=3D245390&= r2=3D247919=0AI think the correct fix is committed with: http://svnweb.free= bsd.org/changeset/base/248102=0AHiren =0A> =0A> # gdb ./pw =0A> GNU gdb 6.1.1 [FreeBSD] =0A> Copyright 2004 Free Software Foundation, Inc. =0A> GDB is free software, covered by the GNU General Public License, and y= ou are =0A> welcome to change it and/or distribute copies of it under certain cond= itions. =0A> Type "show copying" to see the conditions. =0A> There is absolutely no warranty for GDB. =A0Type "show warranty" for d= etails. =0A> This GDB was configured as "amd64-marcel-freebsd"... =0A> (gdb) run groupadd test123 -g 12345 =0A> Starting program: /usr/src/usr.sbin/pw/pw groupadd test123 -g 12345 =0A> =0A> Program received signal SIGSEGV, Segmentation fault. =0A> 0x0000000080d84a4f in stpcpy () from /lib/libc.so.7 =0A> (gdb) bt full =0A> #0 =A00x0000000080d84a4f in stpcpy () from /lib/libc.so.7 =0A> No symbol table info available. =0A> #1 =A00x0000000080a5c00a in grcopy (gr=3D0x612ce0, newgr=3D0x81409100,= name=3D0x0, =0A> =A0 =A0 ndx=3D0) at /usr/src/lib/libutil/gr_util.c:496 =0A> =A0 =A0 =A0 =A0 dst =3D 0x8 =0A> =A0 =A0 =A0 =A0 i =3D 1090277153 =0A> #2 =A00x0000000080a5bdc6 in gr_add (gr=3D0x612ce0, newmember=3D0x0) =0A> =A0 =A0 at /usr/src/lib/libutil/gr_util.c:451 =0A> =A0 =A0 =A0 =A0 newgr =3D (struct group *) 0x81409100 =0A> =A0 =A0 =A0 =A0 len =3D 0 =0A> =A0 =A0 =A0 =A0 num_mem =3D 0 =0A> #3 =A00x0000000080a5bd4f in gr_dup (gr=3D0x612ce0) =0A> =A0 =A0 at /usr/src/lib/libutil/gr_util.c:434 =0A> No locals. =0A> #4 =A00x000000000040bad7 in gr_update (grp=3D0x612ce0, group=3D0x0) at= grupd.c:78 =0A> =A0 =A0 =A0 =A0 pfd =3D 0 =0A> =A0 =A0 =A0 =A0 tfd =3D 4244492 =0A> =A0 =A0 =A0 =A0 gr =3D (struct group *) 0x0 =0A> =A0 =A0 =A0 =A0 old_gr =3D (struct group *) 0x0 =0A> #5 =A00x000000000040ba8f in addgrent (grp=3D0x612ce0) at grupd.c:111 =0A> No locals. =0A> #6 =A00x000000000040a83d in pw_group (cnf=3D0x612bf0, mode=3D0, args= =3D0x613e78) =0A> =A0 =A0 at pw_group.c:258 =0A> ---Type to continue, or q to quit--- =0A> =A0 =A0 =A0 =A0 grp =3D (struct group *) 0x612ce0 =0A> =A0 =A0 =A0 =A0 members =3D (char **) 0x81485d00 =0A> =A0 =A0 =A0 =A0 rc =3D 0 =0A> =A0 =A0 =A0 =A0 a_name =3D (struct carg *) 0x8144c0a0 =0A> =A0 =A0 =A0 =A0 a_gid =3D (struct carg *) 0x8144c0c0 =0A> =A0 =A0 =A0 =A0 arg =3D (struct carg *) 0x0 =0A> =A0 =A0 =A0 =A0 grmembers =3D 200 =0A> =A0 =A0 =A0 =A0 fakegroup =3D {gr_name =3D 0x7fffffffdcb9 "test123", =0A> =A0 gr_passwd =3D 0x40fbc9 "*", gr_gid =3D 12345, gr_mem =3D 0x81485d0= 0} =0A> #7 =A00x00000000004037fb in main (argc=3D3, argv=3D0x7fffffffd9f0) at = pw.c:230 =0A> =A0 =A0 =A0 =A0 which =3D 1 =0A> =A0 =A0 =A0 =A0 config =3D 0x0 =0A> =A0 =A0 =A0 =A0 cnf =3D (struct userconf *) 0x612bf0 =0A> =A0 =A0 =A0 =A0 ch =3D -1 =0A> =A0 =A0 =A0 =A0 mode =3D 0 =0A> =A0 =A0 =A0 =A0 opts =3D {{0x40e150 "V:C:qn:u:c:d:e:p:g:G:mM:k:s:oL:i:= w:h:H:Db:NPy:Y", =0A> =A0 =A0 0x40e180 "V:C:qn:u:rY", =0A> =A0 =A0 0x40e18c "V:C:qn:u:c:d:e:p:g:G:mM:l:k:s:w:L:h:H:FNPY", =0A> =A0 =A0 0x40e1b7 "V:C:qn:u:FPa7", 0x40e1c5 "V:C:q", 0x40e1c5 "V:C:q", =0A> =A0 =A0 0x40e1c5 "V:C:q"}, {0x40e1cb "V:C:qn:g:h:H:M:opNPY", =0A> =A0 =A0 0x40e1e0 "V:C:qn:g:Y", 0x40e1eb "V:C:qn:d:g:l:h:H:FM:m:NPY", =0A> =A0 =A0 0x40e205 "V:C:qn:g:FPa", 0x40e1c5 "V:C:q", 0x0, 0x0}} =0A> =A0 =A0 =A0 =A0 funcs =3D {0x405270 , 0x409b60 } =0A> (gdb) =0A> =0A> _______________________________________________ =0A> freebsd-current@freebsd.org mailing list =0A> http://lists.freebsd.org/mailman/listinfo/freebsd-current =0A> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" =0A=0A From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 15:35:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E75E8C33; Sat, 9 Mar 2013 15:35:05 +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 AD03498C; Sat, 9 Mar 2013 15:35:05 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UELnc-001cbL-Bk>; Sat, 09 Mar 2013 16:35:04 +0100 Received: from e178025158.adsl.alicedsl.de ([85.178.25.158] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UELnc-003NdK-7u>; Sat, 09 Mar 2013 16:35:04 +0100 Message-ID: <513B56E8.2060702@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 16:36:08 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-ports@freebsd.org Subject: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.25.158 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Mar 2013 15:35:06 -0000 I have one specific FreeBSD 10.0-CURRENT box (FreeBSD 10.0-CURRENT #0 r248061: Fri Mar 8 19:44:30 CET 2013 amd64) which rejects to build either lang/gcc or lang/gcc46 with the very same error shown below. The box is compiled with CLANG (buildworld/kernel). It doesn't matter whether I compile those ports with cc (which referes to CLANG 3.2) or "USE_GCC=any", which should use the legacy compiler gcc or the installed lang/gcc (which seems to be outdated). Any attempt ends up with the very same error as shown below. This problem is sticky for a while now and I do not know what to do. I don't dare to delete the package in case the problem is then still present and I couldn't build the port again (I have to many scientific packages which do not compile properly with CLANG). Does anyone has an idea? Can I "rescue" the old installed lang/gcc as a package somehow to attempt a reinstallation in case deletion and recompiling the port will fail? Regards, Oliver [...] cc -O2 -pipe -O3 -march=native -I/usr/local/include -fno-strict-aliasing -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a echo timestamp > full-stamp srcdir="../.././../gcc-4.6.3/fixincludes" /bin/sh ../.././../gcc-4.6.3/fixincludes/mkfixinc.sh x86_64-portbld-freebsd10.0 sed -e 's/@gcc_version@/4.6.3/' < mkheaders.almost > mkheadersT mv -f mkheadersT mkheaders gmake[3]: Leaving directory `/usr/ports/lang/gcc/work/build/build-x86_64-portbld-freebsd10.0/fixincludes' Configuring stage 1 in ./libcpp configure: creating cache ./config.cache checking build system type... x86_64-portbld-freebsd10.0 checking host system type... x86_64-portbld-freebsd10.0 checking target system type... x86_64-portbld-freebsd10.0 checking whether gmake sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking for x86_64-portbld-freebsd10.0-gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking for x86_64-portbld-freebsd10.0-ranlib... /usr/local/bin/ranlib checking how to run the C preprocessor... cpp checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for aclocal... aclocal checking for autoconf... autoconf checking for autoheader... autoheader checking whether cc supports -W... yes checking whether cc supports -Wall... yes checking whether cc supports -Wwrite-strings... yes checking whether cc supports -Wmissing-format-attribute... yes checking whether cc supports -Wstrict-prototypes... yes checking whether cc supports -Wmissing-prototypes... yes checking whether cc supports -Wold-style-definition... yes checking whether cc supports -Wc++-compat... yes checking whether cc supports -pedantic -Wno-long-long... yes checking dependency style of cc... none configure: error: no usable dependency style found gmake[2]: *** [configure-stage1-libcpp] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc. *** [build] Error code 1 Stop in /usr/ports/lang/gcc. ===>>> make failed for lang/gcc ===>>> Aborting update From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 16:03:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A234B8CC; Sat, 9 Mar 2013 16:03:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 68344CE8; Sat, 9 Mar 2013 16:03:06 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::3859:828a:e508:def0] (unknown [IPv6:2001:7b8:3a7:0:3859:828a:e508:def0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9D8635C44; Sat, 9 Mar 2013 17:02:57 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found From: Dimitry Andric In-Reply-To: <513B56E8.2060702@zedat.fu-berlin.de> Date: Sat, 9 Mar 2013 17:02:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F5265A6-396A-426F-A3F8-EFD44D167313@FreeBSD.org> References: <513B56E8.2060702@zedat.fu-berlin.de> To: "Hartmann, O." X-Mailer: Apple Mail (2.1499) Cc: FreeBSD Current , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 16:03:06 -0000 On Mar 9, 2013, at 16:36 , "Hartmann, O." = wrote: > I have one specific FreeBSD 10.0-CURRENT box (FreeBSD 10.0-CURRENT #0 > r248061: Fri Mar 8 19:44:30 CET 2013 amd64) which rejects to build > either lang/gcc or lang/gcc46 with the very same error shown below. =85 > checking whether cc supports -pedantic -Wno-long-long... yes > checking dependency style of cc... none > configure: error: no usable dependency style found > gmake[2]: *** [configure-stage1-libcpp] Error 1 > gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build' > gmake[1]: *** [stage1-bubble] Error 2 > gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' > gmake: *** [all] Error 2 > *** [do-build] Error code 1 What is the actual error in the resulting config.log file? = Unfortunately autoconf error message are virtually information-free=85 My first guess would be that you have non-default CFLAGS in your build = environment, which confuse gcc's build stages. From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 16:30:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 863492EB; Sat, 9 Mar 2013 16:30:08 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 329A0E8E; Sat, 9 Mar 2013 16:30:07 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UEMet-001mPa-1N>; Sat, 09 Mar 2013 17:30:07 +0100 Received: from e178004056.adsl.alicedsl.de ([85.178.4.56] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UEMes-003RME-UN>; Sat, 09 Mar 2013 17:30:07 +0100 Message-ID: <513B63CF.50507@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 17:31:11 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-ports@freebsd.org Subject: CURRENT (r248103): x11/nvidia-driver fails to compile: @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.4.56 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 09 Mar 2013 16:30:08 -0000 I rebuild the kernel module for x11/nvidia-driver on a regular basis via /etc/src.conf setting of PORTS_MODULES+= x11/nvidia-driver but this time, the port gets deleted and - fails to compile (tried 310.32 and 313.26, the latter worked for me before very well). The compilation error is shown below. [...] ===> src (all) cc -O2 -pipe -O3 -march=native -fno-strict-aliasing -O3 -march=native -DNV_VERSION_STRING=\"313.26\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -mno-red-zone -mcmodel=kernel -UDEBUG -U_DEBUG -DNDEBUG -O3 -Wno-error=unused-variable -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_ctl.c In file included from nvidia_ctl.c:14: In file included from ./nv-freebsd.h:77: @/vm/vm_pager.h:127:2: error: implicit declaration of function 'rw_assert' is invalid in C99 [-Werror,-Wimplicit-function-declaration] VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:212:2: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from nvidia_ctl.c:14: In file included from ./nv-freebsd.h:77: @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:212:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from nvidia_ctl.c:14: In file included from ./nv-freebsd.h:77: @/vm/vm_pager.h:144:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:212:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from nvidia_ctl.c:14: In file included from ./nv-freebsd.h:77: @/vm/vm_pager.h:168:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:212:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ In file included from nvidia_ctl.c:14: In file included from ./nv-freebsd.h:77: @/vm/vm_pager.h:191:2: error: use of undeclared identifier 'RA_WLOCKED' VM_OBJECT_ASSERT_WLOCKED(m->object); ^ @/vm/vm_object.h:212:29: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert(&(object)->lock, RA_WLOCKED) ^ 5 errors generated. *** [nvidia_ctl.o] Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-313.26/src. *** [all] Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-313.26. *** [do-build] Error code 1 Stop in /usr/ports/x11/nvidia-driver. *** [build] Error code 1 From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 16:38:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07207A10; Sat, 9 Mar 2013 16:38:45 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward14.mail.yandex.net (forward14.mail.yandex.net [IPv6:2a02:6b8:0:801::4]) by mx1.freebsd.org (Postfix) with ESMTP id 8278CEEA; Sat, 9 Mar 2013 16:38:44 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward14.mail.yandex.net (Yandex) with ESMTP id 34FA71982133; Sat, 9 Mar 2013 20:38:43 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id E9C871B60483; Sat, 9 Mar 2013 20:38:42 +0400 (MSK) Received: from unknown (unknown [178.76.224.133]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id cgxCGgEk-cgxmWtlX; Sat, 9 Mar 2013 20:38:42 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1362847122; bh=HZy+5N5GjDI8oJTdFAuzlKOYB6ns1HzZ4ahBQe9d8Rc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hSnZyHQ96m3SLtfSeKo8La7vij+3CeR6gKB9WgTqkeSprYu/weX3F2k5flTaEEJQO w92kfie2jD4ANy+sMgwbXqldi1xrl9c2dJgt3A8Yjtp2hYSh3xbSuXRMwZ6m70beeu FD7/dXm3o0Rn2TJct1f0Ms3A5InHuqHuU2Hjde94= Message-ID: <513B6582.2080104@yandex.ru> Date: Sat, 09 Mar 2013 20:38:26 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130225 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Hartmann, O." Subject: Re: CURRENT (r248103): x11/nvidia-driver fails to compile: @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' References: <513B63CF.50507@zedat.fu-berlin.de> In-Reply-To: <513B63CF.50507@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 16:38:45 -0000 Hartmann, O. wrote on 09.03.2013 20:31: > I rebuild the kernel module for x11/nvidia-driver on a regular basis via > /etc/src.conf setting of > > PORTS_MODULES+= x11/nvidia-driver I answered to your pr. Did you tried that? """ If I understand correctly, it should be fixed in r248061 (FreeBSD source): http://svnweb.freebsd.org/base/head/sys/kern/subr_witness.c?r1=244112&r2=248093&pathrev=248093 """ -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 16:44:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6BF85C27; Sat, 9 Mar 2013 16:44:52 +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 30227F2D; Sat, 9 Mar 2013 16:44:51 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UEMt9-001oRG-6Q>; Sat, 09 Mar 2013 17:44:51 +0100 Received: from e178004056.adsl.alicedsl.de ([85.178.4.56] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UEMt9-003S3H-42>; Sat, 09 Mar 2013 17:44:51 +0100 Message-ID: <513B6743.10104@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 17:45:55 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ruslan Makhmatkhanov Subject: Re: CURRENT (r248103): x11/nvidia-driver fails to compile: @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' References: <513B63CF.50507@zedat.fu-berlin.de> <513B6582.2080104@yandex.ru> In-Reply-To: <513B6582.2080104@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.4.56 Cc: FreeBSD Current , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 16:44:52 -0000 Am 03/09/13 17:38, schrieb Ruslan Makhmatkhanov: > Hartmann, O. wrote on 09.03.2013 20:31: >> I rebuild the kernel module for x11/nvidia-driver on a regular basis via >> /etc/src.conf setting of >> >> PORTS_MODULES+= x11/nvidia-driver > > I answered to your pr. Did you tried that? > > """ > If I understand correctly, it should be fixed in r248061 (FreeBSD source): > > http://svnweb.freebsd.org/base/head/sys/kern/subr_witness.c?r1=244112&r2=248093&pathrev=248093 > > """ I'm on FreeBSD 10.0-CURRENT #0 r248061: Fri Mar 8 19:44:30 CET 2013 amd64. I just finished compiling r248108 - will reboot and see further. From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 16:46:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90FDFDD0; Sat, 9 Mar 2013 16:46:43 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward3h.mail.yandex.net (forward3h.mail.yandex.net [IPv6:2a02:6b8:0:f05::3]) by mx1.freebsd.org (Postfix) with ESMTP id 46EE6F50; Sat, 9 Mar 2013 16:46:43 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward3h.mail.yandex.net (Yandex) with ESMTP id B4E231361640; Sat, 9 Mar 2013 20:46:41 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 423751340276; Sat, 9 Mar 2013 20:46:41 +0400 (MSK) Received: from unknown (unknown [178.76.224.133]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id keDutt2S-keDu48CK; Sat, 9 Mar 2013 20:46:41 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1362847601; bh=UEUox/KWDO9ChhDKd24Oe3v2CCDo9BmlK9G7JX55LLc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dW3s9eKE0/V7esHZ0PCLGCyxE4L691xxkQYRQfv5cLDLBqc5owA+4oDbbT0Tg3qNo XXnQndH/kEi+oww0gFqcf2aA1dzqSdD7GEy3D/5zO3hpo5e0nZEpaayXa5EpHvWBF0 wk41UBm2CJvO+oeJ1jmnJNSFF6GVh338ZVqaw/ns= Message-ID: <513B6760.3070804@yandex.ru> Date: Sat, 09 Mar 2013 20:46:24 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130225 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Hartmann, O." Subject: Re: CURRENT (r248103): x11/nvidia-driver fails to compile: @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' References: <513B63CF.50507@zedat.fu-berlin.de> <513B6582.2080104@yandex.ru> <513B6743.10104@zedat.fu-berlin.de> In-Reply-To: <513B6743.10104@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 16:46:43 -0000 Hartmann, O. wrote on 09.03.2013 20:45: > Am 03/09/13 17:38, schrieb Ruslan Makhmatkhanov: >> Hartmann, O. wrote on 09.03.2013 20:31: >>> I rebuild the kernel module for x11/nvidia-driver on a regular basis via >>> /etc/src.conf setting of >>> >>> PORTS_MODULES+= x11/nvidia-driver >> >> I answered to your pr. Did you tried that? >> >> """ >> If I understand correctly, it should be fixed in r248061 (FreeBSD source): >> >> http://svnweb.freebsd.org/base/head/sys/kern/subr_witness.c?r1=244112&r2=248093&pathrev=248093 >> >> """ > > > I'm on FreeBSD 10.0-CURRENT #0 r248061: Fri Mar 8 19:44:30 CET 2013 amd64. > I just finished compiling r248108 - will reboot and see further. Err, I copypasted the yours revision, not the actual fix revision. Should read "it should be fixed in r248093". Sorry. -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 16:57:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E7B2F3D3; Sat, 9 Mar 2013 16:57:35 +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 5586FFC5; Sat, 9 Mar 2013 16:57:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UEN5S-001qH1-Jj>; Sat, 09 Mar 2013 17:57:34 +0100 Received: from e178004056.adsl.alicedsl.de ([85.178.4.56] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UEN5S-003Skc-9a>; Sat, 09 Mar 2013 17:57:34 +0100 Message-ID: <513B6A3E.1030306@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 17:58:38 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found References: <513B56E8.2060702@zedat.fu-berlin.de> <8F5265A6-396A-426F-A3F8-EFD44D167313@FreeBSD.org> In-Reply-To: <8F5265A6-396A-426F-A3F8-EFD44D167313@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------010909040709020401000602" X-Originating-IP: 85.178.4.56 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 16:57:36 -0000 This is a multi-part message in MIME format. --------------010909040709020401000602 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Am 03/09/13 17:02, schrieb Dimitry Andric: > On Mar 9, 2013, at 16:36 , "Hartmann, O." wrote: >> I have one specific FreeBSD 10.0-CURRENT box (FreeBSD 10.0-CURRENT #0 >> r248061: Fri Mar 8 19:44:30 CET 2013 amd64) which rejects to build >> either lang/gcc or lang/gcc46 with the very same error shown below. > … >> checking whether cc supports -pedantic -Wno-long-long... yes >> checking dependency style of cc... none >> configure: error: no usable dependency style found >> gmake[2]: *** [configure-stage1-libcpp] Error 1 >> gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build' >> gmake[1]: *** [stage1-bubble] Error 2 >> gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' >> gmake: *** [all] Error 2 >> *** [do-build] Error code 1 > > What is the actual error in the resulting config.log file? Unfortunately autoconf error message are virtually information-free… > > My first guess would be that you have non-default CFLAGS in your build environment, which confuse gcc's build stages. Hello. CFLAGS settings are either root@thor:/usr/ports/lang/gcc # make -VCFLAGS -O2 -pipe -march=native -I/usr/local/include -fno-strict-aliasing or root@thor:/usr/ports/lang/gcc # make -VCFLAGS -O2 -pipe -O3 -march=native -I/usr/local/include -fno-strict-aliasing There are several config.log files: ./work/build/config.log ./work/build/lto-plugin/config.log ./work/build/gcc/config.log ./work/build/intl/config.log ./work/build/libcpp/config.log ./work/build/build-x86_64-portbld-freebsd10.0/libiberty/config.log ./work/build/build-x86_64-portbld-freebsd10.0/fixincludes/config.log ./work/build/libiberty/config.log Most recent touched is ./work/build/libcpp/config.log and since libcpp occurs in the error, it is the requested log file. I can not see anything useful in that file - I'm sorry :-( It is attached to this post. If you need further material, feel free to ask. By the way, I copied my /etc/make.conf and /etc/src.conf to another CURRENT machine which has the very same revision status (as well as the /usr/src AND /usr/ports, both boxes are up to date even with "portmaster" run this morning). I do not see the problem on this other machine. --------------010909040709020401000602-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 17:05:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A93F97A4; Sat, 9 Mar 2013 17:05:02 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 6CAC29F; Sat, 9 Mar 2013 17:05:02 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UENCf-001rLO-EF>; Sat, 09 Mar 2013 18:05:01 +0100 Received: from e178004056.adsl.alicedsl.de ([85.178.4.56] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UENCf-003T7Z-Bj>; Sat, 09 Mar 2013 18:05:01 +0100 Message-ID: <513B6BFD.4060706@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 18:06:05 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ruslan Makhmatkhanov Subject: Re: CURRENT (r248103): x11/nvidia-driver fails to compile: @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' References: <513B63CF.50507@zedat.fu-berlin.de> <513B6582.2080104@yandex.ru> <513B6743.10104@zedat.fu-berlin.de> <513B6760.3070804@yandex.ru> In-Reply-To: <513B6760.3070804@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.4.56 Cc: FreeBSD Current , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 17:05:02 -0000 Am 03/09/13 17:46, schrieb Ruslan Makhmatkhanov: > Hartmann, O. wrote on 09.03.2013 20:45: >> Am 03/09/13 17:38, schrieb Ruslan Makhmatkhanov: >>> Hartmann, O. wrote on 09.03.2013 20:31: >>>> I rebuild the kernel module for x11/nvidia-driver on a regular basis >>>> via >>>> /etc/src.conf setting of >>>> >>>> PORTS_MODULES+= x11/nvidia-driver >>> >>> I answered to your pr. Did you tried that? >>> >>> """ >>> If I understand correctly, it should be fixed in r248061 (FreeBSD >>> source): >>> >>> http://svnweb.freebsd.org/base/head/sys/kern/subr_witness.c?r1=244112&r2=248093&pathrev=248093 >>> >>> >>> """ >> >> >> I'm on FreeBSD 10.0-CURRENT #0 r248061: Fri Mar 8 19:44:30 CET 2013 >> amd64. >> I just finished compiling r248108 - will reboot and see further. > > Err, I copypasted the yours revision, not the actual fix revision. > Should read "it should be fixed in r248093". Sorry. > No, it isn't. Same error, system is at revision: FreeBSD 10.0-CURRENT #1 r248106: Sat Mar 9 16:44:58 CET 2013 amd64 The error is the same. From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 17:07:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BF966957; Sat, 9 Mar 2013 17:07:32 +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 77385C8; Sat, 9 Mar 2013 17:07:32 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r29H7VIu068459; Sat, 9 Mar 2013 09:07:31 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r29H7VIl068458; Sat, 9 Mar 2013 09:07:31 -0800 (PST) (envelope-from david) Date: Sat, 9 Mar 2013 09:07:31 -0800 From: David Wolfskill To: "Hartmann, O." Subject: Re: CURRENT (r248103): x11/nvidia-driver fails to compile: @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' Message-ID: <20130309170731.GW13861@albert.catwhisker.org> References: <513B63CF.50507@zedat.fu-berlin.de> <513B6582.2080104@yandex.ru> <513B6743.10104@zedat.fu-berlin.de> <513B6760.3070804@yandex.ru> <513B6BFD.4060706@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5b1SvPrUm9of+rZU" Content-Disposition: inline In-Reply-To: <513B6BFD.4060706@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 17:07:32 -0000 --5b1SvPrUm9of+rZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 09, 2013 at 06:06:05PM +0100, Hartmann, O. wrote: > ... > No, it isn't. Same error, system is at revision: > FreeBSD 10.0-CURRENT #1 r248106: Sat Mar 9 16:44:58 CET 2013 amd64 >=20 > The error is the same. > ... Please see the message I posted to ports@, a copy of which may be found at . Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --5b1SvPrUm9of+rZU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlE7bFMACgkQmprOCmdXAD23XACbBU1AaIMGQ3PF/AbCMDbiFT8r M3sAn0QzrputcofeN/0HePM5tZCOMGWV =PhyK -----END PGP SIGNATURE----- --5b1SvPrUm9of+rZU-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 17:19:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DDF6ACF7; Sat, 9 Mar 2013 17:19:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9F61412D; Sat, 9 Mar 2013 17:19:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r29HJlNE090169; Sat, 9 Mar 2013 12:19:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r29HJlaP090165; Sat, 9 Mar 2013 17:19:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Mar 2013 17:19:47 GMT Message-Id: <201303091719.r29HJlaP090165@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 17:19:48 -0000 TB --- 2013-03-09 13:41:12 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-09 13:41:12 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-09 13:41:12 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-09 13:41:12 - cleaning the object tree TB --- 2013-03-09 13:44:03 - /usr/local/bin/svn stat /src TB --- 2013-03-09 13:44:07 - At svn revision 248093 TB --- 2013-03-09 13:44:08 - building world TB --- 2013-03-09 13:44:08 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:44:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:44:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:44:08 - SRCCONF=/dev/null TB --- 2013-03-09 13:44:08 - TARGET=pc98 TB --- 2013-03-09 13:44:08 - TARGET_ARCH=i386 TB --- 2013-03-09 13:44:08 - TZ=UTC TB --- 2013-03-09 13:44:08 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:44:08 - cd /src TB --- 2013-03-09 13:44:08 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 9 13:44:13 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 9 16:36:05 UTC 2013 TB --- 2013-03-09 16:36:05 - generating LINT kernel config TB --- 2013-03-09 16:36:05 - cd /src/sys/pc98/conf TB --- 2013-03-09 16:36:05 - /usr/bin/make -B LINT TB --- 2013-03-09 16:36:06 - cd /src/sys/pc98/conf TB --- 2013-03-09 16:36:06 - /usr/sbin/config -m LINT TB --- 2013-03-09 16:36:06 - building LINT kernel TB --- 2013-03-09 16:36:06 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 16:36:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 16:36:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 16:36:06 - SRCCONF=/dev/null TB --- 2013-03-09 16:36:06 - TARGET=pc98 TB --- 2013-03-09 16:36:06 - TARGET_ARCH=i386 TB --- 2013-03-09 16:36:06 - TZ=UTC TB --- 2013-03-09 16:36:06 - __MAKE_CONF=/dev/null TB --- 2013-03-09 16:36:06 - cd /src TB --- 2013-03-09 16:36:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 9 16:36:06 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Mar 9 17:01:13 UTC 2013 TB --- 2013-03-09 17:01:13 - cd /src/sys/pc98/conf TB --- 2013-03-09 17:01:13 - /usr/sbin/config -m GENERIC TB --- 2013-03-09 17:01:13 - building GENERIC kernel TB --- 2013-03-09 17:01:13 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 17:01:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 17:01:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 17:01:13 - SRCCONF=/dev/null TB --- 2013-03-09 17:01:13 - TARGET=pc98 TB --- 2013-03-09 17:01:13 - TARGET_ARCH=i386 TB --- 2013-03-09 17:01:13 - TZ=UTC TB --- 2013-03-09 17:01:13 - __MAKE_CONF=/dev/null TB --- 2013-03-09 17:01:13 - cd /src TB --- 2013-03-09 17:01:13 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Mar 9 17:01:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /src/sys/modules/wlan/../../net80211/ieee80211_ioctl.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /src/sys/modules/wlan/../../net80211/ieee80211_node.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -I/obj/pc98.i386/src/sys/GENERIC -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /src/sys/modules/wlan/../../net80211/ieee80211_output.c /src/sys/modules/wlan/../../net80211/ieee80211_output.c:600:23: error: unused variable 'ic' [-Werror,-Wunused-variable] struct ieee80211com *ic = ni->ni_ic; ^ 1 error generated. *** [ieee80211_output.o] Error code 1 Stop in /src/sys/modules/wlan. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-09 17:19:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-09 17:19:47 - ERROR: failed to build GENERIC kernel TB --- 2013-03-09 17:19:47 - 10275.18 user 1708.67 system 13115.02 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 17:56:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9AEAC9B1; Sat, 9 Mar 2013 17:56:32 +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 6B337241; Sat, 9 Mar 2013 17:56:32 +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 r29HuV40067195; Sat, 9 Mar 2013 12:56:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r29HuVEa067174; Sat, 9 Mar 2013 17:56:31 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Mar 2013 17:56:31 GMT Message-Id: <201303091756.r29HuVEa067174@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 17:56:32 -0000 TB --- 2013-03-09 16:50:38 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-09 16:50:38 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-09 16:50:38 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-09 16:50:38 - cleaning the object tree TB --- 2013-03-09 16:52:06 - /usr/local/bin/svn stat /src TB --- 2013-03-09 16:52:26 - At svn revision 248093 TB --- 2013-03-09 16:52:27 - building world TB --- 2013-03-09 16:52:27 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 16:52:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 16:52:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 16:52:27 - SRCCONF=/dev/null TB --- 2013-03-09 16:52:27 - TARGET=mips TB --- 2013-03-09 16:52:27 - TARGET_ARCH=mips TB --- 2013-03-09 16:52:27 - TZ=UTC TB --- 2013-03-09 16:52:27 - __MAKE_CONF=/dev/null TB --- 2013-03-09 16:52:27 - cd /src TB --- 2013-03-09 16:52:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 9 16:52:32 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 9 17:53:18 UTC 2013 TB --- 2013-03-09 17:53:18 - cd /src/sys/mips/conf TB --- 2013-03-09 17:53:18 - /usr/sbin/config -m ADM5120 TB --- 2013-03-09 17:53:18 - skipping ADM5120 kernel TB --- 2013-03-09 17:53:18 - cd /src/sys/mips/conf TB --- 2013-03-09 17:53:18 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-09 17:53:18 - skipping ALCHEMY kernel TB --- 2013-03-09 17:53:18 - cd /src/sys/mips/conf TB --- 2013-03-09 17:53:18 - /usr/sbin/config -m AP91 TB --- 2013-03-09 17:53:18 - building AP91 kernel TB --- 2013-03-09 17:53:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 17:53:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 17:53:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 17:53:18 - SRCCONF=/dev/null TB --- 2013-03-09 17:53:18 - TARGET=mips TB --- 2013-03-09 17:53:18 - TARGET_ARCH=mips TB --- 2013-03-09 17:53:18 - TZ=UTC TB --- 2013-03-09 17:53:18 - __MAKE_CONF=/dev/null TB --- 2013-03-09 17:53:18 - cd /src TB --- 2013-03-09 17:53:18 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Sat Mar 9 17:53:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_input.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_ioctl.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_node.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../net80211/ieee80211_output.c cc1: warnings being treated as errors /src/sys/modules/wlan/../../net80211/ieee80211_output.c: In function 'ieee80211_send_setup': /src/sys/modules/wlan/../../net80211/ieee80211_output.c:600: warning: unused variable 'ic' [-Wunused-variable] *** [ieee80211_output.o] Error code 1 Stop in /src/sys/modules/wlan. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/mips.mips/src/sys/AP91. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-09 17:56:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-09 17:56:31 - ERROR: failed to build AP91 kernel TB --- 2013-03-09 17:56:31 - 2805.30 user 640.05 system 3953.04 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 18:12:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B800BF02 for ; Sat, 9 Mar 2013 18:12:54 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 17135313 for ; Sat, 9 Mar 2013 18:12:53 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id fs12so2703435lab.11 for ; Sat, 09 Mar 2013 10:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mZcSrhbp+1yivprdVU546xKkZyUaNNp55lVoFH6M0TY=; b=yWhFW0SQ+ZQ/YVZGHo9Tuw0VBG0ueZ92joDeLEV9iTHZRfOkpUIqKcHvUb7e5z8b2U dBSMr3K98JdkmtXD3BM0S9ddorYZty69Sh9LD/DfPyW/Sk2eNkU65J/+yhHz38X5+K5w uZiCmXtoZ2kxKAV9BqmNx3rfcPAPasUh28IiRXb8aWoNKo5rlHhY2/EWM15gZpFuN0D/ GmjtGtXPz++4O8xoMtiFBP+ufWzaYG62lL+rOYbgmdPmmWiDduRIfSF1E1cyO8onTt/f XLUg2J0Fis4kQE7E+n1bcRlKGsgk9vs+OQTyQ2TxhkOm3i4Xrx7J3CKjeipVkwiTiiiY hemg== MIME-Version: 1.0 X-Received: by 10.112.54.6 with SMTP id f6mr2540180lbp.104.1362852772836; Sat, 09 Mar 2013 10:12:52 -0800 (PST) Received: by 10.112.80.133 with HTTP; Sat, 9 Mar 2013 10:12:52 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Mar 2013 19:12:52 +0100 Message-ID: Subject: Re: multi-homing in freebsd From: Daniel Nebdal To: Yasir hussan Content-Type: text/plain; charset=ISO-8859-1 Cc: Zaphod Beeblebrox , Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 18:12:54 -0000 Oh, you specifically need them to have different interfaces? That's a bit more complicated. I guess you could rig something with netgraph (ngctl and such), but I'm not familiar with it... -- Daniel Nebdal On Sat, Mar 9, 2013 at 2:57 PM, Yasir hussan wrote: > i want to have differnet ips`s and each should have different interface, it > could be a virtual interface. like u can made it like > > ifconfig arge0.1 create > > but each ip should able to access from differnet machine > > On Sat, Mar 9, 2013 at 7:29 AM, Daniel Nebdal wrote: >> >> Going by Zaphod's recommendation of using a /32 for each IP, how about >> this? >> >> ifconfig arge0 inet 192.168.1.100/32 >> ifconfig arge0 alias 192.169.1.100/32 >> >> I wouldn't recommend 192.169, though - only 192.168.x.x is reserved >> for private networks, and 192.169 is a valid IP-routable prefix, >> assigned to some US company. >> To be exact: The ranges from RFC1918 are 10.0.0.0/8, 172.16.0.0 /20 >> and 192.168.0.0/24. >> >> On Sat, Mar 9, 2013 at 9:57 AM, Yasir hussan wrote: >> > Kindly will u give me example with cammand line, which can test on my >> > freebsd machine, i want two ips 192.168.1.100 and 192.169.1.100 to be >> > work >> > on single network interface, my default interface for network is arge0 >> > >> > On Sat, Mar 9, 2013 at 3:08 AM, Zaphod Beeblebrox >> > wrote: >> > >> >> On Sat, Mar 9, 2013 at 3:04 AM, Yasir hussan >> >> wrote: >> >> >> >>> i just want to run multiple IPs for single network card in freebsd >> >>> >> >>> >> >> OK. A better question. About the only caution I can give here >> >> (assuming >> >> you don't mean something more interesting like vlans and whatnot) is >> >> that >> >> if both IP addresses are on the SAME network, use a /32 as the netmask >> >> (it >> >> works better). If they are on different networks, specify the netmask >> >> as >> >> normal. >> >> >> >> You may, at this point, need a method to choose which IP address to >> >> use >> >> for any particular connection. There's a pile of documentation waiting >> >> for >> >> you. >> >> >> >> >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to >> > "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 19:07:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8839BAE7; Sat, 9 Mar 2013 19:07:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id A9319688; Sat, 9 Mar 2013 19:07:50 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hi18so282703wib.15 for ; Sat, 09 Mar 2013 11:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q0XMki2A9udRdFHm2YY1Pc6/9IEcIk5waFhgULEmiL0=; b=bkuiCeEFCQu/UdsQz6lGHUa7fX7xhqL+9wYVMQtUO7H4nZcT6az/QYtTHDT2x1YYtX zvZIaG04rAWgH/o2hmCRUKGobefgAN1VMdqew+SiwF1ifuGp0zD1w///za4SCT8xy077 zHz7aF8MvW5D5KalEx4dFTCrv7F1fW0RQ6cyQsqi/fAj745jXYdC1h4HJHIm0+QTKoN7 kleN9v2VyF1rpOVXxC4xnAofBs5LHf3Umf4zrrUfPU6WAYEz/4hCT3KYpg1EVPEv/DCh L9jXODmmtOo49nEqcxbUiH/7hiihW/qXQOtQnQXQzqdnJIEwK25ESrGNv4tk3a6DkRwm zZTQ== MIME-Version: 1.0 X-Received: by 10.180.84.8 with SMTP id u8mr4760019wiy.1.1362856069751; Sat, 09 Mar 2013 11:07:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.111.201 with HTTP; Sat, 9 Mar 2013 11:07:49 -0800 (PST) In-Reply-To: <201303091756.r29HuVEa067174@freebsd-current.sentex.ca> References: <201303091756.r29HuVEa067174@freebsd-current.sentex.ca> Date: Sat, 9 Mar 2013 11:07:49 -0800 X-Google-Sender-Auth: barjyapxV5EhMuZrMo9DaOop6IY Message-ID: Subject: Re: [head tinderbox] failure on mips/mips From: Adrian Chadd To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mips@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 19:07:51 -0000 This one was fixed. Adrian On 9 March 2013 09:56, FreeBSD Tinderbox wrote: > TB --- 2013-03-09 16:50:38 - tinderbox 2.10 running on freebsd-current.se= ntex.ca > TB --- 2013-03-09 16:50:38 - FreeBSD freebsd-current.sentex.ca 8.3-PREREL= EASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebs= d-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2013-03-09 16:50:38 - starting HEAD tinderbox run for mips/mips > TB --- 2013-03-09 16:50:38 - cleaning the object tree > TB --- 2013-03-09 16:52:06 - /usr/local/bin/svn stat /src > TB --- 2013-03-09 16:52:26 - At svn revision 248093 > TB --- 2013-03-09 16:52:27 - building world > TB --- 2013-03-09 16:52:27 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 16:52:27 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 16:52:27 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 16:52:27 - SRCCONF=3D/dev/null > TB --- 2013-03-09 16:52:27 - TARGET=3Dmips > TB --- 2013-03-09 16:52:27 - TARGET_ARCH=3Dmips > TB --- 2013-03-09 16:52:27 - TZ=3DUTC > TB --- 2013-03-09 16:52:27 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 16:52:27 - cd /src > TB --- 2013-03-09 16:52:27 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Sat Mar 9 16:52:32 UTC 2013 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> World build completed on Sat Mar 9 17:53:18 UTC 2013 > TB --- 2013-03-09 17:53:18 - cd /src/sys/mips/conf > TB --- 2013-03-09 17:53:18 - /usr/sbin/config -m ADM5120 > TB --- 2013-03-09 17:53:18 - skipping ADM5120 kernel > TB --- 2013-03-09 17:53:18 - cd /src/sys/mips/conf > TB --- 2013-03-09 17:53:18 - /usr/sbin/config -m ALCHEMY > TB --- 2013-03-09 17:53:18 - skipping ALCHEMY kernel > TB --- 2013-03-09 17:53:18 - cd /src/sys/mips/conf > TB --- 2013-03-09 17:53:18 - /usr/sbin/config -m AP91 > TB --- 2013-03-09 17:53:18 - building AP91 kernel > TB --- 2013-03-09 17:53:18 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 17:53:18 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 17:53:18 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 17:53:18 - SRCCONF=3D/dev/null > TB --- 2013-03-09 17:53:18 - TARGET=3Dmips > TB --- 2013-03-09 17:53:18 - TARGET_ARCH=3Dmips > TB --- 2013-03-09 17:53:18 - TZ=3DUTC > TB --- 2013-03-09 17:53:18 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 17:53:18 - cd /src > TB --- 2013-03-09 17:53:18 - /usr/bin/make -B buildkernel KERNCONF=3DAP91 >>>> Kernel build for AP91 started on Sat Mar 9 17:53:18 UTC 2013 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything > [...] > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_= OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I= @/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --par= am large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mno-abicalls -= mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std= =3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-= pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show= -option -c /src/sys/modules/wlan/../../net80211/ieee80211_input.c > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_= OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I= @/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --par= am large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mno-abicalls -= mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std= =3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-= pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show= -option -c /src/sys/modules/wlan/../../net80211/ieee80211_ioctl.c > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_= OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I= @/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --par= am large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mno-abicalls -= mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std= =3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-= pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show= -option -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_= OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I= @/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --par= am large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mno-abicalls -= mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std= =3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-= pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show= -option -c /src/sys/modules/wlan/../../net80211/ieee80211_node.c > cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_= OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I= @/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --par= am large-function-growth=3D1000 -fno-common -g -G0 -fno-pic -mno-abicalls -= mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std= =3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-= pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show= -option -c /src/sys/modules/wlan/../../net80211/ieee80211_output.c > cc1: warnings being treated as errors > /src/sys/modules/wlan/../../net80211/ieee80211_output.c: In function 'iee= e80211_send_setup': > /src/sys/modules/wlan/../../net80211/ieee80211_output.c:600: warning: unu= sed variable 'ic' [-Wunused-variable] > *** [ieee80211_output.o] Error code 1 > > Stop in /src/sys/modules/wlan. > *** [all] Error code 1 > > Stop in /src/sys/modules. > *** [modules-all] Error code 1 > > Stop in /obj/mips.mips/src/sys/AP91. > *** [buildkernel] Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2013-03-09 17:56:31 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-03-09 17:56:31 - ERROR: failed to build AP91 kernel > TB --- 2013-03-09 17:56:31 - 2805.30 user 640.05 system 3953.04 real > > > http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 20:27:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E557177B; Sat, 9 Mar 2013 20:27:20 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id A56208DC; Sat, 9 Mar 2013 20:27:20 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UEQMR-002JcR-Bi>; Sat, 09 Mar 2013 21:27:19 +0100 Received: from e178004056.adsl.alicedsl.de ([85.178.4.56] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UEQMR-003dMl-9I>; Sat, 09 Mar 2013 21:27:19 +0100 Message-ID: <513B9B67.8070605@zedat.fu-berlin.de> Date: Sat, 09 Mar 2013 21:28:23 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: David Wolfskill Subject: Re: CURRENT (r248103): x11/nvidia-driver fails to compile: @/vm/vm_pager.h:127:2: error: use of undeclared identifier 'RA_WLOCKED' References: <513B63CF.50507@zedat.fu-berlin.de> <513B6582.2080104@yandex.ru> <513B6743.10104@zedat.fu-berlin.de> <513B6760.3070804@yandex.ru> <513B6BFD.4060706@zedat.fu-berlin.de> <20130309170731.GW13861@albert.catwhisker.org> In-Reply-To: <20130309170731.GW13861@albert.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.4.56 Cc: FreeBSD Current , Ruslan Mahmatkhanov , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 20:27:21 -0000 Am 03/09/13 18:07, schrieb David Wolfskill: > On Sat, Mar 09, 2013 at 06:06:05PM +0100, Hartmann, O. wrote: >> ... >> No, it isn't. Same error, system is at revision: >> FreeBSD 10.0-CURRENT #1 r248106: Sat Mar 9 16:44:58 CET 2013 amd64 >> >> The error is the same. >> ... > > Please see the message I posted to ports@, a copy of which may be found > at . > > Peace, > david > Your patch fixed the problem for me. Thanks, oh From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 22:21:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D18CFC04 for ; Sat, 9 Mar 2013 22:21:52 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 50B39D30 for ; Sat, 9 Mar 2013 22:21:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at BSDLabs AB Message-ID: <513BB5F7.10201@intersonic.se> Date: Sat, 09 Mar 2013 23:21:43 +0100 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Hartmann, O." Subject: Re: CURRENT (r248061):Thunderbird SIGNAL 11 with OpenLDAP / nscd(1) broken pipe/ References: <513AFBE3.8070506@zedat.fu-berlin.de> <513AFFF0.6010500@zedat.fu-berlin.de> In-Reply-To: <513AFFF0.6010500@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 22:21:52 -0000 On 2013-03-09 10:25, Hartmann, O. wrote: > Am 03/09/13 10:07, schrieb Hartmann, O.: >> For the introduction, I filed a PR for this at beginning of 2012 and >> suffered from the very same problem close to two years before on ALL >> FreeBSD versions and platforms using OpenLDAP as the user backend: >> >> ports/164239: [PATCH] mail/thunderbird: crash with nss_ldap >> >> Even with the suggested patch by the maintainer the problem stayed. >> >> With the introduction of bad code due to updates with > r247804 and the >> following issues of SIGNAL 13/broken pipe, the problem now is even worse >> in FreeBSD 10.0 r248061. >> From my limited point of view I guess this long lasting unresolved >> problem could have been revealed itself and I hope this could be fixed >> along with fixing nscd(1). >> >> Again, Thunderbird in all flavours since 2010 crashes on FreeBSD 8/9 and >> now 10.0-CURRENT when it is used on systems with user backend in >> OpenLDAP or any LDAP (Thunderbird works on non-OpenLDAP backed systems >> of the same OS revision). >> >> I was able to "solve" the problem by starting Firefox first and only >> Firefox getting started prior to Thunderbird resolved the problem for a >> while, but closing Firefox and waiting a bit left Thunderbird >> unstarteable again until Firefox was closed and reopened again. >> >> I guess this strange behaviour reveals a deeper issue not necessarily >> bound to nscd(1) (since the problem with Thunderbird also occurs without >> nscd(1), BUT always bound to the use of OpenLDAP backend (with >> security/pam_ldap and net/nss_ldap from ports). >> >> Now, on FreeBSD 10.0-CURRENT r248061/amd64, Thunderbird dies immediately >> with SIGNAL 11 on those boxes with OpenLDAP backend and no "trick" makes >> Thunderbird starting enymore. >> >> In my desperation, I did a truss, see below and it seems to me that >> there is a problem getting the effective UID, since the SIGNAL 11 arises >> after geteuid(). >> >> At the moment, I have switched off nscd(1) by default since it is broken >> in CURRENT or doing very strange things (see list about broken pipe in >> the system, sudo(1) or even the port's system (SIGNAL 13)). >> >> I think there is a major issue covered and I hope this could be solved >> by the problems triggered. >> >> it is hard to believe that I'm the only one using FreeBSD for both >> workstation and server environment in conjuction with OpenLDAP and >> facing the problem with a popular software like Thunderbird. >> >> If it is a stupid configuation problem then this must be very, very >> special since it is now sticky with me for years. >> >> Here comes the truss ...: >> >> open("/etc/pwd.db",O_RDONLY,00) = 4 (0x4) >> fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) >> fstat(4,{ mode=-rw-r--r-- ,inode=117927,size=40960,blksize=16384 }) = 0 >> (0x0) >> read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) >> pread(0x4,0x801bfc000,0x1000,0x6000,0x1,0x0) = 4096 (0x1000) >> pread(0x4,0x813927000,0x1000,0x2000,0x1,0x0) = 4096 (0x1000) >> close(4) = 0 (0x0) >> socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) >> connect(4,{ AF_UNIX "/var/run/nscd" },15) ERR#2 'No such file or >> directory' >> close(4) = 0 (0x0) >> sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) >> = 0 (0x0) >> sigaction(SIGPIPE,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 >> (0x0) >> sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) >> getpid() = 3235 (0xca3) >> geteuid() = 2002 (0x7d2) >> open("/usr/local/etc/nss_ldap.conf",O_RDONLY,0666) = 4 (0x4) >> fstat(4,{ mode=-rw-r--r-- ,inode=5818085,size=7997,blksize=16384 }) = 0 >> (0x0) >> fstat(4,{ mode=-rw-r--r-- ,inode=5818085,size=7997,blksize=16384 }) = 0 >> (0x0) >> read(4,"@(#)$Id: ldap.conf,v 2.47 2006/0"...,16384) = 7997 (0x1f3d) >> read(4,0x813928000,16384) = 0 (0x0) >> close(4) = 0 (0x0) >> __sysctl(0x7fffffffb1f8,0x2,0x7fffffffb220,0x7fffffffb200,0x0,0x0) = 0 (0x0) >> gettimeofday({1362819606.123684 },0x0) = 0 (0x0) >> getpid() = 3235 (0xca3) >> issetugid(0x35001c1c,0x80,0x801b1b600,0x10,0x2,0x1) = 0 (0x0) >> open("/etc/resolv.conf",O_RDONLY,0666) = 4 (0x4) >> fstat(4,{ mode=-rw-r--r-- ,inode=117845,size=101,blksize=16384 }) = 0 (0x0) >> read(4,"# Generated by resolvconf\nnames"...,16384) = 101 (0x65) >> read(4,0x813928000,16384) = 0 (0x0) >> close(4) = 0 (0x0) >> __sysctl(0x7fffffffab28,0x2,0x7fffffffad20,0x7fffffffab30,0x0,0x0) = 0 (0x0) >> issetugid(0x801526ae8,0x2e,0x2e,0x2e,0x101010101010101,0x8080808080808080) >> = 0 (0x0) >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- >> ,inode=117790,size=991,blksize=16384 }) = 0 (0x0) >> open("/etc/hosts",O_RDONLY,0666) = 4 (0x4) >> fstat(4,{ mode=-rw-r--r-- ,inode=117862,size=2418,blksize=16384 }) = 0 (0x0) >> read(4,"# $FreeBSD: head/etc/hosts 10999"...,16384) = 2418 (0x972) >> close(4) = 0 (0x0) >> open("/usr/local/etc/openldap/ldap.conf",O_RDONLY,0666) = 4 (0x4) >> fstat(4,{ mode=-rw-r--r-- ,inode=5817420,size=410,blksize=16384 }) = 0 (0x0) >> read(4,"#\n# LDAP Defaults\n#\n\n# See l"...,16384) = 410 (0x19a) >> read(4,0x813928000,16384) = 0 (0x0) >> close(4) = 0 (0x0) >> geteuid() = 2002 (0x7d2) >> getuid() = 2002 (0x7d2) >> open("/home/ohartmann/ldaprc",O_RDONLY,0666) ERR#2 'No such file or >> directory' >> open("/home/ohartmann/.ldaprc",O_RDONLY,0666) ERR#2 'No such file or >> directory' >> open("ldaprc",O_RDONLY,0666) ERR#2 'No such file or >> directory' >> sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) >> = 0 (0x0) >> sigaction(SIGPIPE,{ SIG_IGN SA_RESTART ss_t },{ SIG_IGN 0x0 ss_t }) = 0 >> (0x0) >> sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) >> getuid() = 2002 (0x7d2) >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- >> ,inode=117790,size=991,blksize=16384 }) = 0 (0x0) >> geteuid() = 2002 (0x7d2) >> open("/etc/pwd.db",O_RDONLY,00) = 4 (0x4) >> fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) >> fstat(4,{ mode=-rw-r--r-- ,inode=117927,size=40960,blksize=16384 }) = 0 >> (0x0) >> read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) >> pread(0x4,0x813928000,0x1000,0x6000,0x1,0x0) = 4096 (0x1000) >> pread(0x4,0x813929000,0x1000,0x5000,0x1,0x0) = 4096 (0x1000) >> close(4) = 0 (0x0) >> socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) >> connect(4,{ AF_UNIX "/var/run/nscd" },15) ERR#2 'No such file or >> directory' >> close(4) = 0 (0x0) >> sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) >> = 0 (0x0) >> sigaction(SIGPIPE,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 >> (0x0) >> sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) >> stat("/usr/local/etc/nss_ldap.conf",{ mode=-rw-r--r-- >> ,inode=5818085,size=7997,blksize=16384 }) = 0 (0x0) >> getpid() = 3235 (0xca3) >> geteuid() = 2002 (0x7d2) >> SIGNAL 11 (SIGSEGV) >> process exit, rval = 0 > > Deleting /usr/local/etc/nss_ldap.conf, which is a link (hard or soft, > doesn't matter the result) to /usr/local/etc/ldap.conf, makes > Thunderbird start again as OpenLDAP backend wasn't configured/installed. > > But in that case, no OpenLDAP backed up users are available on the system.SE556539368201 Not 100% sure but I believe I'm working right now on a system with LDAP-based user accounts ( a Samba LDAP directory ) through pam_ldap (in pam.d), nss_ldap (nsswitch.conf) and /usr/local/etc/nss_ldap.conf exactly as you describe. Never had issues similar to the above in the 7-STABLE through 9-STABLE series. The only problem I have with TB is its apetite for memory. Perhaps I'm missing something? May the difference be that my account is in /etc/passwd too? I could log in as a different user and check if you'd like. id peo uid=1001(peo) gid=0(wheel) groups=0(wheel),513(domusers),512(domadmin) Cheers, //per From owner-freebsd-current@FreeBSD.ORG Sat Mar 9 23:35:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 30A8A704 for ; Sat, 9 Mar 2013 23:35:14 +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 CD9F2F8F for ; Sat, 9 Mar 2013 23:35:13 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1UETIG-002hoO-Mv>; Sun, 10 Mar 2013 00:35:12 +0100 Received: from e178004056.adsl.alicedsl.de ([85.178.4.56] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1UETIG-003mFK-I4>; Sun, 10 Mar 2013 00:35:12 +0100 Message-ID: <513BC76F.6000609@zedat.fu-berlin.de> Date: Sun, 10 Mar 2013 00:36:15 +0100 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: Per olof Ljungmark Subject: Re: CURRENT (r248061):Thunderbird SIGNAL 11 with OpenLDAP / nscd(1) broken pipe/ References: <513AFBE3.8070506@zedat.fu-berlin.de> <513AFFF0.6010500@zedat.fu-berlin.de> <513BB5F7.10201@intersonic.se> In-Reply-To: <513BB5F7.10201@intersonic.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.4.56 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 23:35:14 -0000 Am 03/09/13 23:21, schrieb Per olof Ljungmark: > On 2013-03-09 10:25, Hartmann, O. wrote: >> Am 03/09/13 10:07, schrieb Hartmann, O.: >>> For the introduction, I filed a PR for this at beginning of 2012 and >>> suffered from the very same problem close to two years before on ALL >>> FreeBSD versions and platforms using OpenLDAP as the user backend: >>> >>> ports/164239: [PATCH] mail/thunderbird: crash with nss_ldap >>> >>> Even with the suggested patch by the maintainer the problem stayed. >>> >>> With the introduction of bad code due to updates with > r247804 and the >>> following issues of SIGNAL 13/broken pipe, the problem now is even worse >>> in FreeBSD 10.0 r248061. >>> From my limited point of view I guess this long lasting unresolved >>> problem could have been revealed itself and I hope this could be fixed >>> along with fixing nscd(1). >>> >>> Again, Thunderbird in all flavours since 2010 crashes on FreeBSD 8/9 and >>> now 10.0-CURRENT when it is used on systems with user backend in >>> OpenLDAP or any LDAP (Thunderbird works on non-OpenLDAP backed systems >>> of the same OS revision). >>> >>> I was able to "solve" the problem by starting Firefox first and only >>> Firefox getting started prior to Thunderbird resolved the problem for a >>> while, but closing Firefox and waiting a bit left Thunderbird >>> unstarteable again until Firefox was closed and reopened again. >>> >>> I guess this strange behaviour reveals a deeper issue not necessarily >>> bound to nscd(1) (since the problem with Thunderbird also occurs without >>> nscd(1), BUT always bound to the use of OpenLDAP backend (with >>> security/pam_ldap and net/nss_ldap from ports). >>> >>> Now, on FreeBSD 10.0-CURRENT r248061/amd64, Thunderbird dies immediately >>> with SIGNAL 11 on those boxes with OpenLDAP backend and no "trick" makes >>> Thunderbird starting enymore. >>> >>> In my desperation, I did a truss, see below and it seems to me that >>> there is a problem getting the effective UID, since the SIGNAL 11 arises >>> after geteuid(). >>> >>> At the moment, I have switched off nscd(1) by default since it is broken >>> in CURRENT or doing very strange things (see list about broken pipe in >>> the system, sudo(1) or even the port's system (SIGNAL 13)). >>> >>> I think there is a major issue covered and I hope this could be solved >>> by the problems triggered. >>> >>> it is hard to believe that I'm the only one using FreeBSD for both >>> workstation and server environment in conjuction with OpenLDAP and >>> facing the problem with a popular software like Thunderbird. >>> >>> If it is a stupid configuation problem then this must be very, very >>> special since it is now sticky with me for years. >>> >>> Here comes the truss ...: >>> >>> open("/etc/pwd.db",O_RDONLY,00) = 4 (0x4) >>> fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) >>> fstat(4,{ mode=-rw-r--r-- ,inode=117927,size=40960,blksize=16384 }) = 0 >>> (0x0) >>> read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) >>> pread(0x4,0x801bfc000,0x1000,0x6000,0x1,0x0) = 4096 (0x1000) >>> pread(0x4,0x813927000,0x1000,0x2000,0x1,0x0) = 4096 (0x1000) >>> close(4) = 0 (0x0) >>> socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) >>> connect(4,{ AF_UNIX "/var/run/nscd" },15) ERR#2 'No such file or >>> directory' >>> close(4) = 0 (0x0) >>> sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) >>> = 0 (0x0) >>> sigaction(SIGPIPE,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 >>> (0x0) >>> sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) >>> getpid() = 3235 (0xca3) >>> geteuid() = 2002 (0x7d2) >>> open("/usr/local/etc/nss_ldap.conf",O_RDONLY,0666) = 4 (0x4) >>> fstat(4,{ mode=-rw-r--r-- ,inode=5818085,size=7997,blksize=16384 }) = 0 >>> (0x0) >>> fstat(4,{ mode=-rw-r--r-- ,inode=5818085,size=7997,blksize=16384 }) = 0 >>> (0x0) >>> read(4,"@(#)$Id: ldap.conf,v 2.47 2006/0"...,16384) = 7997 (0x1f3d) >>> read(4,0x813928000,16384) = 0 (0x0) >>> close(4) = 0 (0x0) >>> __sysctl(0x7fffffffb1f8,0x2,0x7fffffffb220,0x7fffffffb200,0x0,0x0) = 0 (0x0) >>> gettimeofday({1362819606.123684 },0x0) = 0 (0x0) >>> getpid() = 3235 (0xca3) >>> issetugid(0x35001c1c,0x80,0x801b1b600,0x10,0x2,0x1) = 0 (0x0) >>> open("/etc/resolv.conf",O_RDONLY,0666) = 4 (0x4) >>> fstat(4,{ mode=-rw-r--r-- ,inode=117845,size=101,blksize=16384 }) = 0 (0x0) >>> read(4,"# Generated by resolvconf\nnames"...,16384) = 101 (0x65) >>> read(4,0x813928000,16384) = 0 (0x0) >>> close(4) = 0 (0x0) >>> __sysctl(0x7fffffffab28,0x2,0x7fffffffad20,0x7fffffffab30,0x0,0x0) = 0 (0x0) >>> issetugid(0x801526ae8,0x2e,0x2e,0x2e,0x101010101010101,0x8080808080808080) >>> = 0 (0x0) >>> stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- >>> ,inode=117790,size=991,blksize=16384 }) = 0 (0x0) >>> open("/etc/hosts",O_RDONLY,0666) = 4 (0x4) >>> fstat(4,{ mode=-rw-r--r-- ,inode=117862,size=2418,blksize=16384 }) = 0 (0x0) >>> read(4,"# $FreeBSD: head/etc/hosts 10999"...,16384) = 2418 (0x972) >>> close(4) = 0 (0x0) >>> open("/usr/local/etc/openldap/ldap.conf",O_RDONLY,0666) = 4 (0x4) >>> fstat(4,{ mode=-rw-r--r-- ,inode=5817420,size=410,blksize=16384 }) = 0 (0x0) >>> read(4,"#\n# LDAP Defaults\n#\n\n# See l"...,16384) = 410 (0x19a) >>> read(4,0x813928000,16384) = 0 (0x0) >>> close(4) = 0 (0x0) >>> geteuid() = 2002 (0x7d2) >>> getuid() = 2002 (0x7d2) >>> open("/home/ohartmann/ldaprc",O_RDONLY,0666) ERR#2 'No such file or >>> directory' >>> open("/home/ohartmann/.ldaprc",O_RDONLY,0666) ERR#2 'No such file or >>> directory' >>> open("ldaprc",O_RDONLY,0666) ERR#2 'No such file or >>> directory' >>> sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) >>> = 0 (0x0) >>> sigaction(SIGPIPE,{ SIG_IGN SA_RESTART ss_t },{ SIG_IGN 0x0 ss_t }) = 0 >>> (0x0) >>> sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) >>> getuid() = 2002 (0x7d2) >>> stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- >>> ,inode=117790,size=991,blksize=16384 }) = 0 (0x0) >>> geteuid() = 2002 (0x7d2) >>> open("/etc/pwd.db",O_RDONLY,00) = 4 (0x4) >>> fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) >>> fstat(4,{ mode=-rw-r--r-- ,inode=117927,size=40960,blksize=16384 }) = 0 >>> (0x0) >>> read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) >>> pread(0x4,0x813928000,0x1000,0x6000,0x1,0x0) = 4096 (0x1000) >>> pread(0x4,0x813929000,0x1000,0x5000,0x1,0x0) = 4096 (0x1000) >>> close(4) = 0 (0x0) >>> socket(PF_LOCAL,SOCK_STREAM,0) = 4 (0x4) >>> connect(4,{ AF_UNIX "/var/run/nscd" },15) ERR#2 'No such file or >>> directory' >>> close(4) = 0 (0x0) >>> sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) >>> = 0 (0x0) >>> sigaction(SIGPIPE,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 >>> (0x0) >>> sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) >>> stat("/usr/local/etc/nss_ldap.conf",{ mode=-rw-r--r-- >>> ,inode=5818085,size=7997,blksize=16384 }) = 0 (0x0) >>> getpid() = 3235 (0xca3) >>> geteuid() = 2002 (0x7d2) >>> SIGNAL 11 (SIGSEGV) >>> process exit, rval = 0 >> >> Deleting /usr/local/etc/nss_ldap.conf, which is a link (hard or soft, >> doesn't matter the result) to /usr/local/etc/ldap.conf, makes >> Thunderbird start again as OpenLDAP backend wasn't configured/installed. >> >> But in that case, no OpenLDAP backed up users are available on the system.SE556539368201 > > Not 100% sure but I believe I'm working right now on a system with > LDAP-based user accounts ( a Samba LDAP directory ) through pam_ldap (in > pam.d), nss_ldap (nsswitch.conf) and /usr/local/etc/nss_ldap.conf > exactly as you describe. > > Never had issues similar to the above in the 7-STABLE through 9-STABLE > series. The only problem I have with TB is its apetite for memory. > > Perhaps I'm missing something? May the difference be that my account is > in /etc/passwd too? I could log in as a different user and check if > you'd like. > > id peo > uid=1001(peo) gid=0(wheel) groups=0(wheel),513(domusers),512(domadmin) > > Cheers, > > //per > My account is on LDAP. Can you try with a user on LDAP? Regards, Oliver