From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 12:38:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E5AE106576E for ; Thu, 16 Sep 2010 12:38:15 +0000 (UTC) (envelope-from pguzikos@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9918FC19 for ; Thu, 16 Sep 2010 12:38:13 +0000 (UTC) Received: by wyb33 with SMTP id 33so1693242wyb.13 for ; Thu, 16 Sep 2010 05:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:x-mimeole; bh=oM78gzQfSbASepdhVY4R1pVYZZz9Zp61KmiAnVzUGKg=; b=o2Y6RJvfrClp6q57JWJDbZ5RNAI4AVdgE6PzZiXu6Vq9pS0Vxx0eKcvnK7S33SFznG Cz8/Uu7CDGLkKHXfG6cpf4trxOSUwazkvOF/NwPEM2nN/ok6MdtcflEok4Kcc1eJR6ii 5Lu0/wUSnIN95hfEfvpcQS0N8rGaFcKQQIF0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :x-mimeole; b=g5wqP9RhLFaVU1xodgMrIXZo1dxpLekwwGu8q/YHNHLVe3N2tmtDPgUIY9lltawFzj ws5wY8ewvjD/6hq/2GBoUl6LfkVZTXrZcgFkrwWJoktYtWluiFF+dFzYyId3pTd4eNlY V4Wg1mM4eyOxMkeu88d/g+aWkndLhxr+xLXNc= Received: by 10.216.47.196 with SMTP id t46mr6558376web.13.1284639059325; Thu, 16 Sep 2010 05:10:59 -0700 (PDT) Received: from r61PC (bud82.internetdsl.tpnet.pl [83.18.159.82]) by mx.google.com with ESMTPS id p45sm1774205weq.45.2010.09.16.05.10.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Sep 2010 05:10:57 -0700 (PDT) From: "Piotr Guzik" To: References: <20100916120025.D573910656D7@hub.freebsd.org> In-Reply-To: <20100916120025.D573910656D7@hub.freebsd.org> Date: Thu, 16 Sep 2010 14:10:54 +0200 Message-ID: <5541058CFB0F4E7FAAD0BD4D053C4437@MetrixMetal.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActVlvXzC9IaxgemSYuJlAYFGJnnXAAATPrg X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18416 Subject: RE: freebsd-current Digest, Vol 361, Issue 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 12:38:15 -0000 Dziekuje bardzo. Jutro postaramy si=EA odebrac tusze oraz monitor. Pozdrawiam, Piotr Guzik -------------------------------------------------------------- Metrix Metal Sp. z o.o. ul. Piaskowa 3 83-100 Tczew NIP 586-00-23-871 S=B1d Rejonowy Gda=F1sk-P=F3=B3noc VII Gospodarczy KRS: 0000006693 Kapita=B3 zak=B3adowy: 10.000.000,00- PLN =20 -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of freebsd-current-request@freebsd.org Sent: Thursday, September 16, 2010 2:00 PM To: freebsd-current@freebsd.org Subject: freebsd-current Digest, Vol 361, Issue 4 Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-request@freebsd.org You can reach the person managing the list at freebsd-current-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-current digest..." Today's Topics: 1. [head tinderbox] failure on powerpc64/powerpc (FreeBSD Tinderbox) 2. [head tinderbox] failure on powerpc/powerpc (FreeBSD Tinderbox) 3. buildworld + ccache trouble (Dmitry Krivenok) 4. Re: DHCP server in base (M. Warner Losh) 5. Re: buildworld + ccache trouble (Maxim Khitrov) 6. Re: TCP loopback socket fusing (Bjoern A. Zeeb) 7. multiple problems between r212316 and r212643 on ia64 (Anton Shterenlikht) 8. Re: TCP loopback socket fusing (Gary Jennejohn) 9. Re: TCP loopback socket fusing (Andre Oppermann) 10. ZFS Test Suite (Jason J. W. Williams) 11. Re: DHCP server in base (Doug Barton) 12. Re: Multiple hpet messages during boot (Alexander Motin) 13. Re: buildworld + ccache trouble (Tom Judge) 14. Re: regarding pciids (Andriy Gapon) 15. Re: buildworld + ccache trouble (Dimitry Andric) 16. Re: tun(4) in -CURRENT: No buffer space available - race condition patch (John Baldwin) 17. Re: tun(4) in -CURRENT: No buffer space available - race condition patch (Marcin Cieslak) 18. WITHOUT_BIND=3Dtrue and `make delete-old` (Alexander Best) 19. Re: multiple problems between r212316 and r212643 on ia64 (Marcel Moolenaar) 20. Re: ZFS Test Suite (jhell) 21. Re: ZFS Test Suite (Jason J. W. Williams) 22. Re: ZFS Test Suite (Gary Palmer) 23. Re: NFS lockups with VMware esxi client (David Ehrmann) 24. Can't build PERL under 8.1 Release (joe mcguckin) 25. Re: multiple problems between r212316 and r212643 on ia64 (Anton Shterenlikht) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Sep 2010 12:54:24 GMT From: FreeBSD Tinderbox Subject: [head tinderbox] failure on powerpc64/powerpc To: FreeBSD Tinderbox , , Message-ID: <201009151254.o8FCsOd1063007@freebsd-current.sentex.ca> TB --- 2010-09-15 12:07:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-15 12:07:44 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-09-15 12:07:44 - cleaning the object tree TB --- 2010-09-15 12:08:39 - cvsupping the source tree TB --- 2010-09-15 12:08:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-09-15 12:09:10 - building world TB --- 2010-09-15 12:09:10 - MAKEOBJDIRPREFIX=3D/obj TB --- 2010-09-15 12:09:10 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-15 12:09:10 - TARGET=3Dpowerpc TB --- 2010-09-15 12:09:10 - TARGET_ARCH=3Dpowerpc64 TB --- 2010-09-15 12:09:10 - TZ=3DUTC TB --- 2010-09-15 12:09:10 - __MAKE_CONF=3D/dev/null TB --- 2010-09-15 12:09:10 - cd /src TB --- 2010-09-15 12:09:10 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 15 12:09:12 UTC 2010 >>> 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 -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DSTREAMSPTY -DINET6 = -I/src/libexec/telnetd/../../contrib/telnet -DAUTHENTICATION -DENCRYPTION -DKRB5 -DFORWARD = -Dnet_write=3Dtelnet_net_write -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall = -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /obj/powerpc.powerpc64/src/libexec/telnetd/../../lib/libtelnet/libtelnet.= a -lmp -lcrypto -lcrypt -lpam -lkrb5 -lhx509 -lasn1 -lroken -lcom_err gzip -cn /src/libexec/telnetd/../../contrib/telnet/telnetd/telnetd.8 > telnetd.8.gz =3D=3D=3D> libexec/tftpd (all) cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftpd.c cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftp-io.c cc1: warnings being treated as errors /src/libexec/tftpd/tftp-io.c: In function 'receive_packet': /src/libexec/tftpd/tftp-io.c:396: warning: variable 'pfrom' might be clobbered by 'longjmp' or 'vfork' *** Error code 1 Stop in /src/libexec/tftpd. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-15 12:54:24 - WARNING: /usr/bin/make returned exit code = 1=20 TB --- 2010-09-15 12:54:24 - ERROR: failed to build world TB --- 2010-09-15 12:54:24 - 1768.60 user 658.62 system 2799.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ------------------------------ Message: 2 Date: Wed, 15 Sep 2010 13:03:26 GMT From: FreeBSD Tinderbox Subject: [head tinderbox] failure on powerpc/powerpc To: FreeBSD Tinderbox , , Message-ID: <201009151303.o8FD3QDP026756@freebsd-current.sentex.ca> TB --- 2010-09-15 11:47:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-15 11:47:01 - starting HEAD tinderbox run for = powerpc/powerpc TB --- 2010-09-15 11:47:01 - cleaning the object tree TB --- 2010-09-15 11:47:51 - cvsupping the source tree TB --- 2010-09-15 11:47:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-15 11:48:34 - building world TB --- 2010-09-15 11:48:34 - MAKEOBJDIRPREFIX=3D/obj TB --- 2010-09-15 11:48:34 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-15 11:48:34 - TARGET=3Dpowerpc TB --- 2010-09-15 11:48:34 - TARGET_ARCH=3Dpowerpc TB --- 2010-09-15 11:48:34 - TZ=3DUTC TB --- 2010-09-15 11:48:34 - __MAKE_CONF=3D/dev/null TB --- 2010-09-15 11:48:34 - cd /src TB --- 2010-09-15 11:48:34 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 15 11:48:34 UTC 2010 >>> 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 -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DSTREAMSPTY -DINET6 = -I/src/libexec/telnetd/../../contrib/telnet -DAUTHENTICATION -DENCRYPTION -DKRB5 -DFORWARD = -Dnet_write=3Dtelnet_net_write -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall = -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /obj/powerpc.powerpc/src/libexec/telnetd/../../lib/libtelnet/libtelnet.a -lmp -lcrypto -lcrypt -lpam -lkrb5 -lhx509 -lasn1 -lroken -lcom_err gzip -cn /src/libexec/telnetd/../../contrib/telnet/telnetd/telnetd.8 > telnetd.8.gz =3D=3D=3D> libexec/tftpd (all) cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftpd.c cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftp-io.c cc1: warnings being treated as errors /src/libexec/tftpd/tftp-io.c: In function 'receive_packet': /src/libexec/tftpd/tftp-io.c:396: warning: variable 'pfrom' might be clobbered by 'longjmp' or 'vfork' *** Error code 1 Stop in /src/libexec/tftpd. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-15 13:03:26 - WARNING: /usr/bin/make returned exit code = 1=20 TB --- 2010-09-15 13:03:26 - ERROR: failed to build world TB --- 2010-09-15 13:03:26 - 3257.18 user 858.55 system 4584.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ------------------------------ Message: 3 Date: Wed, 15 Sep 2010 16:44:45 +0400 From: Dmitry Krivenok Subject: buildworld + ccache trouble To: freebsd-current@freebsd.org Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 Hello All! I recently updated to r212634 and tried to build CURRENT tree with = ccache. I added /usr/local/libexec/ccache in my $PATH and added the following in /etc/make.conf: .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE) CC=3D/usr/local/libexec/ccache/world-cc CXX=3D/usr/local/libexec/ccache/world-c++ .endif Then I set WITHOUT_BOOT =3D 'YES' DEBUG_FLAGS =3D '-g -O0' and run make buildworld buildkernel installkernel However, I got build error: =3D=3D=3D> lib/csu/i386-elf (obj,depend,all,install) rm -f .depend CC=3D'/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crti.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crtn.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -DGCRT -c -o gcrt1_c.o /usr/src/lib/csu/i386-elf/crt1_c.c /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1_s.S /usr/src/lib/csu/i386-elf/crt1_s.S: Assembler messages: /usr/src/lib/csu/i386-elf/crt1_s.S:36: Error: suffix or operands invalid for `push' /usr/src/lib/csu/i386-elf/crt1_s.S:39: Error: bad register expression /usr/src/lib/csu/i386-elf/crt1_s.S:40: Error: bad register expression /usr/src/lib/csu/i386-elf/crt1_s.S:42: Error: `8(%ebp)' is not a valid 64 bit base/index expression /usr/src/lib/csu/i386-elf/crt1_s.S:43: Error: suffix or operands invalid for `push' /usr/src/lib/csu/i386-elf/crt1_s.S:44: Error: `4(%ebp)' is not a valid 64 bit base/index expression /usr/src/lib/csu/i386-elf/crt1_s.S:45: Error: suffix or operands invalid for `push' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Is it a know issue? Any solutions? Thanks in advance! P.S. Build works fine if I don't use ccache. --=20 Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 ------------------------------ Message: 4 Date: Wed, 15 Sep 2010 08:25:13 -0600 (MDT) From: "M. Warner Losh" Subject: Re: DHCP server in base To: demelier.david@gmail.com Cc: kimelto@gmail.com, ray@ddteam.net, dougb@freebsd.org, mj@feral.com, freebsd-current@freebsd.org Message-ID: <20100915.082513.802140508206832836.imp@bsdimp.com> Content-Type: Text/Plain; charset=3Dus-ascii In message: = David DEMELIER writes: : 2010/9/11 Doug Barton : : > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: : >> : >> Hi, : >> : >> another argument about hostapd :) if have access point we must have : >> way to assign IP for AP clients. : > : > To start with, your assumption is wrong. DHCPd is not *actually* a : > requirement, although I admit that practically it is. : > : >> Last spring I made firmware based on FreeBSD for router with only = 4MB : >> NOR flash (D-Link DIR-320). : > : > In this category (micro-miniaturization) you're already in the "significant : > customization needed" area, which means that general arguments about "the : > base" don't apply. : > : >> Since this device is router I must be : >> able to serve DHCP. And current implementation of dhcpclient, that = we : >> have, is same isc-dhcp, and I replace system dhcpclient with ports : >> one+dhcpd but with small patch that put basic dhcp utils onto : >> libdhcp.so. : > : > Your argument is creative and well thought out, but I personally = don't find : > it persuasive. Counter arguments that come immediately to mind are: : > 1. The DHCP server is not going to benefit any but a small minority = of : > FreeBSD users. : > 2. The software is already available in the ports tree, and adding a : > port/package of it really is not an overwhelming burden. : > : > More generally, the main reason I want to keep more stuff out of the base, : > and remove some of the stuff that's in there now, is that it makes : > maintenance difficult across FreeBSD branches. We have a general = policy that : > if we have a major version N of something in a release branch that = we don't : > upgrade that major version without a really good reason to avoid = POLA : > surprises for our users. Once again using BIND as an example, this = has led : > to a really old and past-EOL version of BIND in FreeBSD 6 which I've only : > gotten away with because anyone doing serious DNS work nowadays has = to : > upgrade to at least 9.6 anyway. But it's an ugly situation, and I = don't want : > to repeat it. : > :=20 : I agree but like Aleksandr said, almost 70% of dhcp code is already in : base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea : to keep some parts in the ports tree and move out from the base. Yea. I agree too. Just because BIND was EOLd in 6 isn't a great argument against dhcp server. Most of the code is there anyway, and it isn't evolving as fast as BIND. It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. After all, we just added more compression utilities to the base, and nobody said a peep. This is analogous: we have good opportunity to integrate into the system, and users benefit from that integration. Warner ------------------------------ Message: 5 Date: Wed, 15 Sep 2010 10:53:00 -0400 From: Maxim Khitrov Subject: Re: buildworld + ccache trouble To: Dmitry Krivenok Cc: freebsd-current@freebsd.org Message-ID: Content-Type: text/plain; charset=3DUTF-8 On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok wrote: > Hello All! > I recently updated to r212634 and tried to build CURRENT tree with = ccache. > > However, I got build error: > > > > Stop in /usr/src/lib/csu/i386-elf. > *** Error code 1 > > Is it a know issue? > Any solutions? If I remember correctly, this happens when you try to build 32-bit library set on amd64 (you do not have WITHOUT_LIB32 set in /etc/src.conf). My solution was to disable 32-bit support by setting that option. If you're still using ccache version 2.4, try upgrading to 3.0.1, though I'm not sure if this problem has been fix. The only other alternative that I know of is to not use ccache to buildworld on amd64. - Max ------------------------------ Message: 6 Date: Wed, 15 Sep 2010 15:19:50 +0000 (UTC) From: "Bjoern A. Zeeb" Subject: Re: TCP loopback socket fusing To: Andre Oppermann Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100915151632.E31898@maildrop.int.zabbadoz.net> Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed On Mon, 13 Sep 2010, Andre Oppermann wrote: Hey, > When a TCP connection via loopback back to localhost is made the whole > send, segmentation and receive path (with larger packets though) is = still > executed. This has some considerable overhead. > > To short-circuit the send and receive sockets on localhost TCP = connections > I've made a proof-of-concept patch that directly places the data in = the > other side's socket buffer without doing any packetization and other protocol > overhead (like UNIX domain sockets). The connections setup (SYN, = SYN-ACK, > ACK) and shutdown are still handled by normal TCP segments via = loopback so > that firewalling stills works. The actual payload data during the = session > won't be seen and the sequence numbers don't move other than for SYN = and FIN. > The sequence are remain valid though. Obviously tcpdump won't see any data > transfers either if the connection has fused sockets. > > Preliminary testing (with WITNESS and INVARIANTS enabled) has shown = stable > operation and a rough doubling of the throughput on loopback = connections. > I've tested most socket teardown cases and it behaves fine. I'm not entirely > sure I've got all possible path's but the way it is integrated should=20 > properly > defuse the sockets in all situations. Three comments in reverse order: 1 If S/S+A/A and shutdown aren't shortcut, can you always rely on proper payload order, especially in the shutdown case? 2 Given my experience with epairs, which are basically a loop with two interfaces and even interface queues, any significant delay you are seeing is _not_ due to longer code paths through the stack but simply because of the netisr. 3 If properly doing this for TCP, we should probably also do it for other protocols. /bz --=20 Bjoern A. Zeeb Welcome a new stage of life. ------------------------------ Message: 7 Date: Wed, 15 Sep 2010 16:23:53 +0100 From: Anton Shterenlikht Subject: multiple problems between r212316 and r212643 on ia64 To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> Content-Type: text/plain; charset=3Dus-ascii I just rebuilt world and kernel from r212316 to r212643 on ia64. man(1) doesn't work, I get: % man ls zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged % man man zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged and so on for any command. sendmail doesn't work: # cd /etc/mail # make start Starting: sendmail-submitmailwrapper: no mapping in = /etc/mail/mailer.conf sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf . #=20 Rebooting with 212316 kernel doesn't change anything. I cannot roll back to another revision because svn doesn't work: # cd /usr/src # svn up svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence #=20 I can build svn, but trying to install it, I get: *skip* /usr/bin/install -c -o root -g wheel -d /usr/local/share/locale/zh_TW/LC_MESSAGES cd subversion/po ; /usr/bin/install -c -o root -g wheel -m 644 zh_TW.mo /usr/local/share/locale/zh_TW/LC_MESSAGES/subversion.mo subversion/svnversion/svnversion . /repos/svn/trunk > /usr/local/include/subversion-1/svn-revision.txt svn: Can't open file '.svn/entries': Illegal byte sequence *** Error code 1 Stop in /usr/ports/devel/subversion-freebsd/work/subversion-1.6.12. *** Error code 1 In addition I get this in /var/log/messages: init: getty repeating too quickly on port /dev/ttyv8, sleeping 30 secs ntpd[976]: select() error: Resource temporarily unavailable last message repeated 29 times Please advise many thanks anton --=20 Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ------------------------------ Message: 8 Date: Wed, 15 Sep 2010 18:14:31 +0200 From: Gary Jennejohn Subject: Re: TCP loopback socket fusing To: Andre Oppermann Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100915181431.30677523@ernst.jennejohn.org> Content-Type: text/plain; charset=3DUS-ASCII On Mon, 13 Sep 2010, Andre Oppermann wrote: > Preliminary testing (with WITNESS and INVARIANTS enabled) has shown = stable > operation and a rough doubling of the throughput on loopback = connections. > I've tested most socket teardown cases and it behaves fine. I'm not entirely > sure I've got all possible path's but the way it is integrated should=20 > properly defuse the sockets in all situations. >=20 I tried this out with the following results: a) booted the new kernel, started X, started firefox -> hard hang, had = to reset the box to recover. Note that firefox uses wwwoffle as a local, caching proxy and wwwwoffle is accessed through localhost:8080 b) tried (a) again to make sure it wasn't a fluke -> same result c) booted anew but started opera instead, which does _not_ use wwwoffle as its proxy (net.inet.tcp.loopfuse=3D1) -> OK d) I then set net.inet.tcp.loopfuse=3D0 before starting firefox -> OK e) set net.inet.tcp.loopfuse=3D1 and ran cvsup to update my CVS tree followed by checking out the changed sources, which uses loopback to talk to cvsupd -> OK So, somewhow trying to access wwwoffle through localhost:8080 causes a hard hang of the box. Whether this has something to do with the port number or just strange behavior on the part of wwwoffle I can't say, because the hard hang makes debugging impossible. By hard hang I mean that there is no visible activity, gkrellm isn't updating, mouse and keyboard are ignored and ping from a different machine shows no reaction, so I'd say the kernel is pretty much wedged. For now I'm setting net.inet.tcp.loopfuse=3D0 in /etc/sysctl.conf. -- Gary Jennejohn ------------------------------ Message: 9 Date: Wed, 15 Sep 2010 17:48:07 +0200 From: Andre Oppermann Subject: Re: TCP loopback socket fusing To: "Bjoern A. Zeeb" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <4C90EAB7.2000902@networx.ch> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed On 15.09.2010 17:19, Bjoern A. Zeeb wrote: > On Mon, 13 Sep 2010, Andre Oppermann wrote: > > Hey, > >> When a TCP connection via loopback back to localhost is made the = whole >> send, segmentation and receive path (with larger packets though) is = still >> executed. This has some considerable overhead. >> >> To short-circuit the send and receive sockets on localhost TCP connections >> I've made a proof-of-concept patch that directly places the data in = the >> other side's socket buffer without doing any packetization and other protocol >> overhead (like UNIX domain sockets). The connections setup (SYN, = SYN-ACK, >> ACK) and shutdown are still handled by normal TCP segments via = loopback so >> that firewalling stills works. The actual payload data during the = session >> won't be seen and the sequence numbers don't move other than for SYN = and FIN. >> The sequence are remain valid though. Obviously tcpdump won't see any data >> transfers either if the connection has fused sockets. >> >> Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable >> operation and a rough doubling of the throughput on loopback = connections. >> I've tested most socket teardown cases and it behaves fine. I'm not entirely >> sure I've got all possible path's but the way it is integrated should properly >> defuse the sockets in all situations. > > Three comments in reverse order: > > 1 If S/S+A/A and shutdown aren't shortcut, can you always rely on = proper > payload order, especially in the shutdown case? Yes. The payload is always directly placed in the receive socket buffer of the other socket, never in the send buffer. There is never any = unsent data left in the send buffer that could become reordered. > 2 Given my experience with epairs, which are basically a loop with two > interfaces and even interface queues, any significant delay you are > seeing is _not_ due to longer code paths through the stack but > simply because of the netisr. I haven't measured delay, only bandwidth. And that's with WITNESS and INVARIANTS enabled. You are probably right, the netisr is taking its toll. Especially the TCP_INFO lock may have some contention in the loopback case on SMP. Though a lot of mbuf allocations, packet manipulations and instructions (instruction cache) are avoided by fusing the sockets together. > 3 If properly doing this for TCP, we should probably also do it for > other protocols. UNIX domain sockets already do this. This implementation is particular for TCP and only touches the protocol specific parts. It's not done at the socket layer. For UDP it's not that easy to do as most UDP = connections are one-off packets and no permanent binding between two sockets exists. For SCTP I don't know. From glancing over the code it seems they have, at least partially, their own socket buffer code. How difficult a fused socket there would be I can't say. --=20 Andre ------------------------------ Message: 10 Date: Wed, 15 Sep 2010 11:40:28 -0600 From: "Jason J. W. Williams" Subject: ZFS Test Suite To: freebsd-current@freebsd.org Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 Does the FreeBSD ZFS port get tested against the ZFS test suite created by Sun? It's a fairly comprehensive suite and has delivered a very reliable set of ZFS beta code for a long time. Trying to gauge the stability and compatibility of the FreeBSD port. Thank you in advance. -J ------------------------------ Message: 11 Date: Wed, 15 Sep 2010 11:27:24 -0700 From: Doug Barton Subject: Re: DHCP server in base To: "M. Warner Losh" Cc: freebsd-current@freebsd.org Message-ID: <4C91100C.5060502@FreeBSD.org> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed On 9/15/2010 7:25 AM, M. Warner Losh wrote: > Yea. I agree too. Just because BIND was EOLd in 6 isn't a great > argument against dhcp server. That rather clearly was not the only element of my argument, and not=20 only is it disingenuous for you to indicate that it was, I don't=20 appreciate you doing so. > Most of the code is there anyway, and it isn't evolving as fast as = BIND. That is actually a more rational argument, even if I don't agree with=20 it. FWIW, part of the reason that I don't agree with it is that at some=20 point, hopefully in the near future, we will want to include the DHCPv6=20 client in the mix somewhere; and when we do the code base is not going=20 to be as stable as we have enjoyed so far with the v4 dhclient. > It would be very convenient to have this particular thing in the base, > and we shouldn't be too dogmatic about never having any new 3rd party > things in the base. After all, we just added more compression > utilities to the base, and nobody said a peep. I actually thought that change was rather silly, but it was clear that=20 there was so much critical mass in favor of it that there was no point=20 in stating a dissenting opinion. As part of the project's leadership you = should be careful not to mistake silence for agreement, or worse, = support. > This is analogous: we > have good opportunity to integrate into the system, and users benefit > from that integration. Given your perspective of wanting more of a complete system in the base=20 I can certainly see how you would be supportive of this change. My=20 intent was to make the argument in a general way that this is the wrong=20 direction to go, and that users would benefit *more* from a robust=20 modularized system. The fact that the v4 DHCPd might accidentally be a=20 good candidate for including in the base today doesn't mean that doing=20 so is the right strategy for the long term. Doug --=20 ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ ------------------------------ Message: 12 Date: Wed, 15 Sep 2010 21:36:04 +0300 From: Alexander Motin Subject: Re: Multiple hpet messages during boot To: FreeBSD-Current Message-ID: <4C911214.7060406@FreeBSD.org> Content-Type: text/plain; charset=3DISO-8859-1 Joel Dahl wrote: > I noticed this during boot (HEAD from yesterday): >=20 > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] >=20 > Is it really necessary to print this 8 times? HPET at present chipsets may use up to 8 IRQs. Driver registers filter interrupt handlers for them. Interrupt handling code prints this. If you boot with verbose, you may see that some network cards prints alike things for the number of supported MSI/MSI-X interrupts. --=20 Alexander Motin ------------------------------ Message: 13 Date: Wed, 15 Sep 2010 13:36:55 -0500 From: Tom Judge Subject: Re: buildworld + ccache trouble To: Maxim Khitrov Cc: freebsd-current@freebsd.org, Dmitry Krivenok Message-ID: <4C911247.7010309@tomjudge.com> Content-Type: text/plain; charset=3DUTF-8 On 09/15/2010 09:53 AM, Maxim Khitrov wrote: > On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok > wrote: > =20 >> Hello All! >> I recently updated to r212634 and tried to build CURRENT tree with ccache. >> >> However, I got build error: >> >> >> >> Stop in /usr/src/lib/csu/i386-elf. >> *** Error code 1 >> >> Is it a know issue? >> Any solutions? >> =20 > If I remember correctly, this happens when you try to build 32-bit > library set on amd64 (you do not have WITHOUT_LIB32 set in > /etc/src.conf). > > My solution was to disable 32-bit support by setting that option. If > you're still using ccache version 2.4, try upgrading to 3.0.1, though > I'm not sure if this problem has been fix. The only other alternative > that I know of is to not use ccache to buildworld on amd64. > =20 In the past I have used the solution outlined here: http://www.tomjudge.com/index.php/FreeBSD/Creating_a_%28i386/ia32%29_buil= d_c luster_using_amd64_and_i386_hosts This used to (in the 6.2 days) allow us to build i386 objects on amd64 hosts. It may work for you. Tom --=20 TJU13-ARIN ------------------------------ Message: 14 Date: Wed, 15 Sep 2010 22:47:00 +0300 From: Andriy Gapon Subject: Re: regarding pciids To: Alexander Best , freebsd-current@freebsd.org Message-ID: <4C9122B4.2040202@icyb.net.ua> Content-Type: text/plain; charset=3DISO-8859-1 on 14/09/2010 03:59 Alexander Best said the following: > hi there, >=20 > any thoughts on using http://pciids.sourceforge.net/ for pciids = instead of the > Hart and Boemler lists. the SF site seems to be updated more regularly = and > would get rid of the need to decide for each entry, whether to take = the Hart or > Boemler one. +1 FWIW Especially given that the format is what we use too (modulo subvendor, sub-etc) --=20 Andriy Gapon ------------------------------ Message: 15 Date: Wed, 15 Sep 2010 22:14:30 +0200 From: Dimitry Andric Subject: Re: buildworld + ccache trouble To: Dmitry Krivenok Cc: freebsd-current@freebsd.org Message-ID: <4C912926.6070409@FreeBSD.org> Content-Type: text/plain; charset=3D"iso-8859-1" On 2010-09-15 14:44, Dmitry Krivenok wrote: > I recently updated to r212634 and tried to build CURRENT tree with = ccache. ... > /usr/src/lib/csu/i386-elf/crt1_s.S:42: Error: `8(%ebp)' is not a valid > 64 bit base/index expression I assume this error occurs when building the 32-bit components on amd64. If so, can you please try the attached patch? It should fix the build32 stage with a non-default ${CC} setting. This also applies to building with clang, for instance. -------------- next part -------------- diff --git a/Makefile.inc1 b/Makefile.inc1 index a08e4ca..66d074f 100644 --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -299,15 +299,15 @@ LIB32WMAKEENV+=3D = MAKEOBJDIRPREFIX=3D${OBJTREE}/lib32 \ VERSION=3D"${VERSION}" \ INSTALL=3D"sh ${.CURDIR}/tools/install.sh" \ PATH=3D${TMPPATH} \ - CC=3D"${CC} ${LIB32FLAGS}" \ - CXX=3D"${CXX} ${LIB32FLAGS}" \ - OBJC=3D"${OBJC} ${LIB32FLAGS}" \ LIBDIR=3D/usr/lib32 \ SHLIBDIR=3D/usr/lib32 =20 LIB32WMAKE=3D ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ - -DWITHOUT_HTML -DNO_CTF DESTDIR=3D${LIB32TMP} + -DWITHOUT_HTML -DNO_CTF DESTDIR=3D${LIB32TMP} \ + CC=3D"${CC} ${LIB32FLAGS}" \ + CXX=3D"${CXX} ${LIB32FLAGS}" \ + OBJC=3D"${OBJC} ${LIB32FLAGS}" LIB32IMAKE=3D ${LIB32WMAKE:NINSTALL=3D*:NDESTDIR=3D*} -DNO_INCS .endif =20 ------------------------------ Message: 16 Date: Wed, 15 Sep 2010 17:49:44 -0400 From: John Baldwin Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch To: freebsd-current@freebsd.org Cc: Marcin Cieslak Message-ID: <201009151749.45038.jhb@freebsd.org> Content-Type: Text/Plain; charset=3D"iso-8859-1" On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: > Output queue of tun(4) gets full after some time when sending lots of data. > I have been observing this on -CURRENT at least since March this year. >=20 > Looks like it's a race condition (same in tun(4) and tap(4)),=20 > the following patch seems to address the issue: This is a good find. I actually went through these drivers a bit = further and=20 have a bit of a larger patch to extend the locking some. Would you care = to=20 test it? Index: if_tap.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_tap.c (revision 212557) +++ if_tap.c (working copy) @@ -209,7 +209,6 @@ tap_destroy(struct tap_softc *tp) { struct ifnet *ifp =3D tp->tap_ifp; - int s; =20 /* Unlocked read. */ KASSERT(!(tp->tap_flags & TAP_OPEN), @@ -217,10 +216,8 @@ =20 knlist_destroy(&tp->tap_rsel.si_note); destroy_dev(tp->tap_dev); - s =3D splimp(); ether_ifdetach(ifp); if_free_type(ifp, IFT_ETHER); - splx(s); =20 mtx_destroy(&tp->tap_mtx); free(tp, M_TAP); @@ -398,7 +395,7 @@ struct tap_softc *tp =3D NULL; unsigned short macaddr_hi; uint32_t macaddr_mid; - int unit, s; + int unit; char *name =3D NULL; u_char eaddr[6]; =20 @@ -449,15 +446,13 @@ dev->si_drv1 =3D tp; tp->tap_dev =3D dev; =20 - s =3D splimp(); ether_ifattach(ifp, eaddr); - splx(s); =20 mtx_lock(&tp->tap_mtx); tp->tap_flags |=3D TAP_INITED; mtx_unlock(&tp->tap_mtx); =20 - knlist_init_mtx(&tp->tap_rsel.si_note, NULL); + knlist_init_mtx(&tp->tap_rsel.si_note, &tp->tap_mtx); =20 TAPDEBUG("interface %s is created. minor =3D %#x\n",=20 ifp->if_xname, dev2unit(dev)); @@ -474,7 +469,7 @@ { struct tap_softc *tp =3D NULL; struct ifnet *ifp =3D NULL; - int error, s; + int error; =20 if (tapuopen =3D=3D 0) { error =3D priv_check(td, PRIV_NET_TAP); @@ -497,15 +492,13 @@ tp->tap_pid =3D td->td_proc->p_pid; tp->tap_flags |=3D TAP_OPEN; ifp =3D tp->tap_ifp; - mtx_unlock(&tp->tap_mtx); =20 - s =3D splimp(); ifp->if_drv_flags |=3D IFF_DRV_RUNNING; ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; if (tapuponopen) ifp->if_flags |=3D IFF_UP; + mtx_unlock(&tp->tap_mtx); if_link_state_change(ifp, LINK_STATE_UP); - splx(s); =20 TAPDEBUG("%s is open. minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); =20 @@ -524,7 +517,6 @@ struct ifaddr *ifa; struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; - int s; =20 /* junk all pending output */ IF_DRAIN(&ifp->if_snd); @@ -537,25 +529,24 @@ mtx_lock(&tp->tap_mtx); if (((tp->tap_flags & TAP_VMNET) =3D=3D 0) && (ifp->if_flags & = IFF_UP)) { mtx_unlock(&tp->tap_mtx); - s =3D splimp(); if_down(ifp); + mtx_lock(&tp->tap_mtx); if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; + mtx_unlock(&tp->tap_mtx); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { rtinit(ifa, (int)RTM_DELETE, 0); } if_purgeaddrs(ifp); - ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; + mtx_lock(&tp->tap_mtx); } - splx(s); - } else - mtx_unlock(&tp->tap_mtx); + } =20 if_link_state_change(ifp, LINK_STATE_DOWN); funsetown(&tp->tap_sigio); selwakeuppri(&tp->tap_rsel, PZERO+1); - KNOTE_UNLOCKED(&tp->tap_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tap_rsel.si_note, 0); =20 - mtx_lock(&tp->tap_mtx); tp->tap_flags &=3D ~TAP_OPEN; tp->tap_pid =3D 0; mtx_unlock(&tp->tap_mtx); @@ -580,8 +571,10 @@ =20 TAPDEBUG("initializing %s\n", ifp->if_xname); =20 + mtx_lock(&tp->tap_mtx); ifp->if_drv_flags |=3D IFF_DRV_RUNNING; ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; + mtx_unlock(&tp->tap_mtx); =20 /* attempt to start output */ tapifstart(ifp); @@ -599,7 +592,7 @@ struct tap_softc *tp =3D ifp->if_softc; struct ifreq *ifr =3D (struct ifreq *)data; struct ifstat *ifs =3D NULL; - int s, dummy; + int dummy; =20 switch (cmd) { case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ @@ -612,7 +605,6 @@ break; =20 case SIOCGIFSTATUS: - s =3D splimp(); ifs =3D (struct ifstat *)data; dummy =3D strlen(ifs->ascii); mtx_lock(&tp->tap_mtx); @@ -621,14 +613,10 @@ sizeof(ifs->ascii) - dummy, "\tOpened by PID %d\n", tp->tap_pid); mtx_unlock(&tp->tap_mtx); - splx(s); break; =20 default: - s =3D splimp(); - dummy =3D ether_ioctl(ifp, cmd, data); - splx(s); - return (dummy); + return (ether_ioctl(ifp, cmd, data)); /* NOT REACHED */ } =20 @@ -645,7 +633,6 @@ tapifstart(struct ifnet *ifp) { struct tap_softc *tp =3D ifp->if_softc; - int s; =20 TAPDEBUG("%s starting\n", ifp->if_xname); =20 @@ -665,24 +652,19 @@ TAPDEBUG("%s not ready, tap_flags =3D 0x%x\n", ifp->if_xname,=20 tp->tap_flags); =20 - s =3D splimp(); do { IF_DEQUEUE(&ifp->if_snd, m); if (m !=3D NULL) m_freem(m); ifp->if_oerrors ++; } while (m !=3D NULL); - splx(s); =20 return; } - mtx_unlock(&tp->tap_mtx); =20 - s =3D splimp(); ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; =20 - if (ifp->if_snd.ifq_len !=3D 0) { - mtx_lock(&tp->tap_mtx); + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { if (tp->tap_flags & TAP_RWAIT) { tp->tap_flags &=3D ~TAP_RWAIT; wakeup(tp); @@ -691,16 +673,16 @@ if ((tp->tap_flags & TAP_ASYNC) && (tp->tap_sigio !=3D NULL)) { mtx_unlock(&tp->tap_mtx); pgsigio(&tp->tap_sigio, SIGIO, 0); - } else - mtx_unlock(&tp->tap_mtx); + mtx_lock(&tp->tap_mtx); + } =20 selwakeuppri(&tp->tap_rsel, PZERO+1); - KNOTE_UNLOCKED(&tp->tap_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tap_rsel.si_note, 0); ifp->if_opackets ++; /* obytes are counted in ether_output */ } =20 ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; - splx(s); + mtx_unlock(&tp->tap_mtx); } /* tapifstart */ =20 =20 @@ -715,7 +697,6 @@ struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; struct tapinfo *tapp =3D NULL; - int s; int f; #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD4) @@ -724,12 +705,10 @@ =20 switch (cmd) { case TAPSIFINFO: - s =3D splimp(); tapp =3D (struct tapinfo *)data; ifp->if_mtu =3D tapp->mtu; ifp->if_type =3D tapp->type; ifp->if_baudrate =3D tapp->baudrate; - splx(s); break; =20 case TAPGIFINFO: @@ -757,26 +736,26 @@ break; =20 case FIOASYNC: - s =3D splimp(); mtx_lock(&tp->tap_mtx); if (*(int *)data) tp->tap_flags |=3D TAP_ASYNC; else tp->tap_flags &=3D ~TAP_ASYNC; mtx_unlock(&tp->tap_mtx); - splx(s); break; =20 case FIONREAD: - s =3D splimp(); - if (ifp->if_snd.ifq_head) { - struct mbuf *mb =3D ifp->if_snd.ifq_head; + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { + struct mbuf *mb; =20 - for(*(int *)data =3D 0;mb !=3D NULL;mb =3D mb->m_next) + IFQ_LOCK(&ifp->if_snd); + IFQ_POLL_NOLOCK(&ifp->if_snd, mb); + for (*(int *)data =3D 0; mb !=3D NULL; + mb =3D mb->m_next) *(int *)data +=3D mb->m_len; + IFQ_UNLOCK(&ifp->if_snd); } else *(int *)data =3D 0; - splx(s); break; =20 case FIOSETOWN: @@ -797,10 +776,6 @@ =20 /* VMware/VMnet port ioctl's */ =20 - case SIOCGIFFLAGS: /* get ifnet flags */ - bcopy(&ifp->if_flags, data, sizeof(ifp->if_flags)); - break; - #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD4) case _IO('V', 0): @@ -814,9 +789,9 @@ f &=3D ~IFF_CANTCHANGE; f |=3D IFF_UP; =20 - s =3D splimp(); + mtx_lock(&tp->tap_mtx); ifp->if_flags =3D f | (ifp->if_flags & IFF_CANTCHANGE); - splx(s); + mtx_unlock(&tp->tap_mtx); break; =20 case OSIOCGIFADDR: /* get MAC address of the remote side */ @@ -851,7 +826,7 @@ struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; struct mbuf *m =3D NULL; - int error =3D 0, len, s; + int error =3D 0, len; =20 TAPDEBUG("%s reading, minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); =20 @@ -867,26 +842,27 @@ } =20 tp->tap_flags &=3D ~TAP_RWAIT; - mtx_unlock(&tp->tap_mtx); =20 /* sleep until we get a packet */ do { - s =3D splimp(); IF_DEQUEUE(&ifp->if_snd, m); - splx(s); =20 if (m =3D=3D NULL) { - if (flag & O_NONBLOCK) + if (flag & O_NONBLOCK) { + mtx_unlock(&tp->tap_mtx); return (EWOULDBLOCK); + } =20 - mtx_lock(&tp->tap_mtx); tp->tap_flags |=3D TAP_RWAIT; - mtx_unlock(&tp->tap_mtx); - error =3D tsleep(tp,PCATCH|(PZERO+1),"taprd",0); - if (error) + error =3D mtx_sleep(tp, &tp->tap_mtx, PCATCH | (PZERO + 1), + "taprd", 0); + if (error) { + mtx_unlock(&tp->tap_mtx); return (error); + } } } while (m =3D=3D NULL); + mtx_unlock(&tp->tap_mtx); =20 /* feed packet to bpf */ BPF_MTAP(ifp, m); @@ -982,14 +958,14 @@ { struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; - int s, revents =3D 0; + int revents =3D 0; =20 TAPDEBUG("%s polling, minor =3D %#x\n",=20 ifp->if_xname, dev2unit(dev)); =20 - s =3D splimp(); if (events & (POLLIN | POLLRDNORM)) { - if (ifp->if_snd.ifq_len > 0) { + IFQ_LOCK(&ifp->if_snd); + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { TAPDEBUG("%s have data in queue. len =3D %d, " \ "minor =3D %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); @@ -1001,12 +977,12 @@ =20 selrecord(td, &tp->tap_rsel); } + IFQ_UNLOCK(&ifp->if_snd); } =20 if (events & (POLLOUT | POLLWRNORM)) revents |=3D (events & (POLLOUT | POLLWRNORM)); =20 - splx(s); return (revents); } /* tappoll */ =20 @@ -1019,11 +995,9 @@ static int tapkqfilter(struct cdev *dev, struct knote *kn) { - int s; struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; =20 - s =3D splimp(); switch (kn->kn_filter) { case EVFILT_READ: TAPDEBUG("%s kqfilter: EVFILT_READ, minor =3D %#x\n", @@ -1040,11 +1014,9 @@ default: TAPDEBUG("%s kqfilter: invalid filter, minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); - splx(s); return (EINVAL); /* NOT REACHED */ } - splx(s); =20 kn->kn_hook =3D (caddr_t) dev; knlist_add(&tp->tap_rsel.si_note, kn, 0); @@ -1061,12 +1033,11 @@ static int tapkqread(struct knote *kn, long hint) { - int ret, s; + int ret; struct cdev *dev =3D (struct cdev *)(kn->kn_hook); struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; =20 - s =3D splimp(); if ((kn->kn_data =3D ifp->if_snd.ifq_len) > 0) { TAPDEBUG("%s have data in queue. len =3D %d, minor =3D %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); @@ -1076,7 +1047,6 @@ ifp->if_xname, dev2unit(dev)); ret =3D 0; } - splx(s); =20 return (ret); } /* tapkqread */ @@ -1090,13 +1060,10 @@ static int tapkqwrite(struct knote *kn, long hint) { - int s; struct tap_softc *tp =3D ((struct cdev *) kn->kn_hook)->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; =20 - s =3D splimp(); kn->kn_data =3D ifp->if_mtu; - splx(s); =20 return (1); } /* tapkqwrite */ Index: if_tun.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_tun.c (revision 212557) +++ if_tun.c (working copy) @@ -344,13 +344,13 @@ tp->tun_flags &=3D ~TUN_RWAIT; wakeup(tp); } + selwakeuppri(&tp->tun_rsel, PZERO + 1); + KNOTE_LOCKED(&tp->tun_rsel.si_note, 0); if (tp->tun_flags & TUN_ASYNC && tp->tun_sigio) { mtx_unlock(&tp->tun_mtx); pgsigio(&tp->tun_sigio, SIGIO, 0); } else mtx_unlock(&tp->tun_mtx); - selwakeuppri(&tp->tun_rsel, PZERO + 1); - KNOTE_UNLOCKED(&tp->tun_rsel.si_note, 0); } =20 /* XXX: should return an error code so it can fail. */ @@ -385,7 +385,7 @@ IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); ifp->if_snd.ifq_drv_maxlen =3D 0; IFQ_SET_READY(&ifp->if_snd); - knlist_init_mtx(&sc->tun_rsel.si_note, NULL); + knlist_init_mtx(&sc->tun_rsel.si_note, &sc->tun_mtx); ifp->if_capabilities |=3D IFCAP_LINKSTATE; ifp->if_capenable |=3D IFCAP_LINKSTATE; =20 @@ -443,7 +443,6 @@ { struct tun_softc *tp; struct ifnet *ifp; - int s; =20 tp =3D dev->si_drv1; ifp =3D TUN2IFP(tp); @@ -451,27 +450,25 @@ mtx_lock(&tp->tun_mtx); tp->tun_flags &=3D ~TUN_OPEN; tp->tun_pid =3D 0; - mtx_unlock(&tp->tun_mtx); =20 /* * junk all pending output */ CURVNET_SET(ifp->if_vnet); - s =3D splimp(); IFQ_PURGE(&ifp->if_snd); - splx(s); =20 if (ifp->if_flags & IFF_UP) { - s =3D splimp(); + mtx_unlock(&tp->tun_mtx); if_down(ifp); - splx(s); + mtx_lock(&tp->tun_mtx); } =20 /* Delete all addresses and routes which reference this interface. */ if (ifp->if_drv_flags & IFF_DRV_RUNNING) { struct ifaddr *ifa; =20 - s =3D splimp(); + ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; + mtx_unlock(&tp->tun_mtx); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { /* deal w/IPv4 PtP destination; unlocked read */ if (ifa->ifa_addr->sa_family =3D=3D AF_INET) { @@ -482,16 +479,14 @@ } } if_purgeaddrs(ifp); - ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; - splx(s); + mtx_lock(&tp->tun_mtx); } if_link_state_change(ifp, LINK_STATE_DOWN); CURVNET_RESTORE(); =20 - mtx_lock(&tp->tun_mtx); funsetown(&tp->tun_sigio); selwakeuppri(&tp->tun_rsel, PZERO + 1); - KNOTE_UNLOCKED(&tp->tun_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tun_rsel.si_note, 0); TUNDEBUG (ifp, "closed\n"); =20 cv_broadcast(&tp->tun_cv); @@ -510,9 +505,11 @@ =20 TUNDEBUG(ifp, "tuninit\n"); =20 + mtx_lock(&tp->tun_mtx); ifp->if_flags |=3D IFF_UP; ifp->if_drv_flags |=3D IFF_DRV_RUNNING; getmicrotime(&ifp->if_lastchange); + mtx_unlock(&tp->tun_mtx); =20 #ifdef INET if_addr_rlock(ifp); @@ -545,9 +542,8 @@ struct ifreq *ifr =3D (struct ifreq *)data; struct tun_softc *tp =3D ifp->if_softc; struct ifstat *ifs; - int error =3D 0, s; + int error =3D 0; =20 - s =3D splimp(); switch(cmd) { case SIOCGIFSTATUS: ifs =3D (struct ifstat *)data; @@ -576,7 +572,6 @@ default: error =3D EINVAL; } - splx(s); return (error); } =20 @@ -682,7 +677,6 @@ static int tunioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread=20 *td) { - int s; int error; struct tun_softc *tp =3D dev->si_drv1; struct tuninfo *tunp; @@ -745,9 +739,11 @@ switch (*(int *)data & ~IFF_MULTICAST) { case IFF_POINTOPOINT: case IFF_BROADCAST: + mtx_lock(&tp->tun_mtx); TUN2IFP(tp)->if_flags &=3D ~(IFF_BROADCAST|IFF_POINTOPOINT|IFF_MULTICAST); TUN2IFP(tp)->if_flags |=3D *(int *)data; + mtx_unlock(&tp->tun_mtx); break; default: return(EINVAL); @@ -769,17 +765,15 @@ mtx_unlock(&tp->tun_mtx); break; case FIONREAD: - s =3D splimp(); if (!IFQ_IS_EMPTY(&TUN2IFP(tp)->if_snd)) { struct mbuf *mb; IFQ_LOCK(&TUN2IFP(tp)->if_snd); IFQ_POLL_NOLOCK(&TUN2IFP(tp)->if_snd, mb); - for( *(int *)data =3D 0; mb !=3D 0; mb =3D mb->m_next) + for (*(int *)data =3D 0; mb !=3D NULL; mb =3D mb->m_next) *(int *)data +=3D mb->m_len; IFQ_UNLOCK(&TUN2IFP(tp)->if_snd); } else *(int *)data =3D 0; - splx(s); break; case FIOSETOWN: return (fsetown(*(int *)data, &tp->tun_sigio)); @@ -813,7 +807,7 @@ struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); struct mbuf *m; - int error=3D0, len, s; + int error=3D0, len; =20 TUNDEBUG (ifp, "read\n"); mtx_lock(&tp->tun_mtx); @@ -824,27 +818,24 @@ } =20 tp->tun_flags &=3D ~TUN_RWAIT; - mtx_unlock(&tp->tun_mtx); =20 - s =3D splimp(); do { IFQ_DEQUEUE(&ifp->if_snd, m); if (m =3D=3D NULL) { if (flag & O_NONBLOCK) { - splx(s); + mtx_unlock(&tp->tun_mtx); return (EWOULDBLOCK); } - mtx_lock(&tp->tun_mtx); tp->tun_flags |=3D TUN_RWAIT; - mtx_unlock(&tp->tun_mtx); - if ((error =3D tsleep(tp, PCATCH | (PZERO + 1), - "tunread", 0)) !=3D 0) { - splx(s); + error =3D mtx_sleep(tp, &tp->tun_mtx, PCATCH | (PZERO + 1), + "tunread", 0); + if (error !=3D 0) { + mtx_unlock(&tp->tun_mtx); return (error); } } } while (m =3D=3D NULL); - splx(s); + mtx_unlock(&tp->tun_mtx); =20 while (m && uio->uio_resid > 0 && error =3D=3D 0) { len =3D min(uio->uio_resid, m->m_len); @@ -957,13 +948,11 @@ static int tunpoll(struct cdev *dev, int events, struct thread *td) { - int s; struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); int revents =3D 0; struct mbuf *m; =20 - s =3D splimp(); TUNDEBUG(ifp, "tunpoll\n"); =20 if (events & (POLLIN | POLLRDNORM)) { @@ -981,7 +970,6 @@ if (events & (POLLOUT | POLLWRNORM)) revents |=3D events & (POLLOUT | POLLWRNORM); =20 - splx(s); return (revents); } =20 @@ -991,11 +979,9 @@ static int tunkqfilter(struct cdev *dev, struct knote *kn) { - int s; struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); =20 - s =3D splimp(); switch(kn->kn_filter) { case EVFILT_READ: TUNDEBUG(ifp, "%s kqfilter: EVFILT_READ, minor =3D %#x\n", @@ -1012,10 +998,8 @@ default: TUNDEBUG(ifp, "%s kqfilter: invalid filter, minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); - splx(s); return(EINVAL); } - splx(s); =20 kn->kn_hook =3D (caddr_t) dev; knlist_add(&tp->tun_rsel.si_note, kn, 0); @@ -1029,12 +1013,11 @@ static int tunkqread(struct knote *kn, long hint) { - int ret, s; + int ret; struct cdev *dev =3D (struct cdev *)(kn->kn_hook); struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); =20 - s =3D splimp(); if ((kn->kn_data =3D ifp->if_snd.ifq_len) > 0) { TUNDEBUG(ifp, "%s have data in the queue. Len =3D %d, minor =3D %#x\n", @@ -1046,7 +1029,6 @@ dev2unit(dev)); ret =3D 0; } - splx(s); =20 return (ret); } @@ -1057,13 +1039,10 @@ static int tunkqwrite(struct knote *kn, long hint) { - int s; struct tun_softc *tp =3D ((struct cdev *)kn->kn_hook)->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); =20 - s =3D splimp(); kn->kn_data =3D ifp->if_mtu; - splx(s); =20 return (1); } --=20 John Baldwin ------------------------------ Message: 17 Date: Wed, 15 Sep 2010 21:57:34 +0000 (UTC) From: Marcin Cieslak Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch To: freebsd-current@freebsd.org Message-ID: Content-Type: text/plain; charset=3DUTF-8 Dnia 15.09.2010 John Baldwin napisaE=02/a: > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: >> Output queue of tun(4) gets full after some time when sending lots of data. >> I have been observing this on -CURRENT at least since March this = year. >>=20 >> Looks like it's a race condition (same in tun(4) and tap(4)),=20 >> the following patch seems to address the issue: > > This is a good find. I actually went through these drivers a bit = further and=20 > have a bit of a larger patch to extend the locking some. Would you = care to=20 > test it? Sure, I am installing it right now (for if_tun right now). There are also a LORs during tunclose (I always get one of them when = closing the tunnel): -------8<----------------------------------------------------------------= --- ------- lock order reversal: 1st 0xc24db8c8 rtentry (rtentry) @ /usr/src/sys/net/route.c:370 2nd 0xc2472a04 if_afdata (if_afdata) @ = /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(c0a4b284,cce14714,c0723185,c0715b2b,c0a4d1f8,...) = at db_trace_self_wrapper+0x26 kdb_backtrace(c0715b2b,c0a4d1f8,c0c4f308,c21186e8,cce1476c,...) at kdb_backtrace+0x29 _witness_debugger(c0a4d1f8,c2472a04,c0a539ec,c211dfe0,c0a63771,...) at _witness_debugger+0x25 witness_checkorder(c2472a04,9,c0a63771,1a1,0,...) at witness_checkorder+0x6aa _rw_wlock(c2472a04,c0a63771,1a1,0,c2472a04,...) at _rw_wlock+0x38 in6_setscope(cce148c4,c2472800,0,cce147fc,cce147e0,...) at = in6_setscope+0x30 in6_purgeaddr(c2539600,0,0,c211e048,c2362364,...) at in6_purgeaddr+0x4af if_purgeaddrs(c2472800,2,0,1cd,c24ab4c0,...) at if_purgeaddrs+0xb0 tunclose(c24d1000,3,2000,c23622c0,1,...) at tunclose+0x197 giant_close(c24d1000,3,2000,c23622c0,c23622c0,...) at giant_close+0x6e devfs_close(cce14a78,cce14a9c,c07785fb,c0aae500,cce14a78,...) at devfs_close+0x2a9 VOP_CLOSE_APV(c0aae500,cce14a78,c0a532d0,12d,c0af0160,...) at VOP_CLOSE_APV+0x42 vn_close(c24ccaa0,3,c2160c80,c23622c0,c23622c0,...) at vn_close+0xdb vn_closefile(c24bc0e0,c23622c0,c24bc0e0,0,cce14b28,...) at = vn_closefile+0xe4 devfs_close_f(c24bc0e0,c23622c0,3,0,c24bc0e0,...) at devfs_close_f+0x2b _fdrop(c24bc0e0,c23622c0,cce14b5c,c072327c,0,...) at _fdrop+0x43 closef(c24bc0e0,c23622c0,721,71e,c2362364,...) at closef+0x277 fdfree(c23622c0,0,c0a4549c,107,80000000,...) at fdfree+0x3ba exit1(c23622c0,0,cce14c7c,c071da4a,c23622c0,...) at exit1+0x465 sys_exit(c23622c0,cce14cec,stray irq7 c06a7bac,1,0,...) at sys_exit+0x1d syscallenter(c23622c0,cce14ce4,c06d6stray irq7 d5d,c0cae934,8,...) at syscallenter+0x25a syscall(cce14d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (1, FreeBSD ELF32, sys_exit), eipstray irq7 =3D 0x28128acf, esp =3D 0xbfbfed80, ebp =3D 0xbfbfed8c --- ^Ctun0: link state changed to DOWN -------8<----------------------------------------------------------------= --- ------- lock order reversal: 1st 0xc24db8c8 rtentrystray irq7 (rtentry) @ /usr/src/sys/net/route.c:370 2nd 0xc2482604 if_afdata (if_afdata) @ = /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(c0a4912e,cce16714,c0723105,c0715aab,c0a4b0a2,...) = at db_trace_self_wrapper+0x26 kdb_backtrace(c0715aab,c0a4b0a2,c0c4cb58,c21176e8,cce1676c,...) at kdb_backtrace+0x29 _witness_debugger(c0a4b0a2,c2482604,c0a51896,c211cfe0,c0a6137e,...) at _witness_debugger+0x25 witness_checkorder(c2482604,9,c0a6137e,1a1,0,...) at witness_checkorder+0x6aa _rw_wlock(c2482604,c0a613stray irq7 7e,1a1,c0793997,c2482604,...) at _rw_wlock+0x38 in6_setscope(cce168c4,c2482400,0,cce167fc,cce167e0,...) at = in6_setscope+0x30 in6_purgeaddr(c253e000,0,0,c211d048,c2361364,...) at in6_purgeaddr+0x4af if_purgeaddrs(c2482400,2,0,1cd,c24aa5c0,...) at if_purgeaddrs+0xb0 tunclose(c2539a00,3,2000,c23612c0,1,...) at tunclose+0x136 giant_close(c2539a00,3,2000,c23612c0,c23612c0,...) at giant_close+0x6e devfs_close(cce16a78,cce16a9c,c077857b,c0aac0e0,cce16a78,...) at devfs_close+0x2a9 VOP_CLOSE_APV(c0aac0e0,cce16a78,c0a5117a,12d,c0aedac0,...) at VOP_CLOSE_APV+0x42 vn_close(c25d2770,3,c215fc80,c23612c0,c0b10180,...) at vn_close+0xdb vn_closefile(c24bba10,c23612c0,c24bba10,0,cce16b28,...) at = vn_closefile+0xe4 devfs_close_f(c24bba10,c23612c0,3,0,c24bba10,...) at devfs_close_f+0x2b _fdrop(c24bba10,c23612c0,cce16b5c,c07231fc,0,...) at _fdrop+0x43 closef(c24bba10,c23612c0,721,71e,c2361364,...) at closef+0x277 fdfree(c23612c0,0,c0a43346,107,c2361364,...) at fdfree+0x3ba exit1(c23612c0,0,cce16c7c,c071d9ca,c23612c0,...) at exit1+0x465 sys_exit(c23612c0,cce16cec,28087460,1,0,...) at sys_exit+0x1d syscallenter(c23612c0,cce16ce4,c09a564e,c23612c0,cce16d28,...) at syscallenter+0x25a syscall(cce16d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (1, FreeBSD ELF32, sys_exit), eip =3D 0x28128acf, esp =3D 0xbfbfed80, ebp =3D 0xbfbfed8c --- tun0: link state changed to DOWN -------8<----------------------------------------------------------------= --- ------- --Marcin ------------------------------ Message: 18 Date: Wed, 15 Sep 2010 22:08:32 +0000 From: Alexander Best Subject: WITHOUT_BIND=3Dtrue and `make delete-old` To: freebsd-current@freebsd.org Message-ID: <20100915220832.GA24698@freebsd.org> Content-Type: text/plain; charset=3Dus-ascii hi there, just wanted to ask if the following entries from BSD.include.dist: "lwres" and BSD.usr.dist: "bind9" (including arm and misc) could be moved to BIND.chroot.dist so `make delete-old` doesn't have to remove those directories after every installworld and WITHOUT_BIND=3Dtrue? cheers. alex --=20 a13x ------------------------------ Message: 19 Date: Wed, 15 Sep 2010 14:23:26 -0700 From: Marcel Moolenaar Subject: Re: multiple problems between r212316 and r212643 on ia64 To: Anton Shterenlikht Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> Content-Type: text/plain; charset=3Dus-ascii On Sep 15, 2010, at 8:23 AM, Anton Shterenlikht wrote: >=20 > % man ls > zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged > % man man > zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged >=20 >=20 > # cd /etc/mail > # make start > Starting: sendmail-submitmailwrapper: no mapping in = /etc/mail/mailer.conf > sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf > . > #=20 >=20 > # cd /usr/src > # svn up > svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence > #=20 >=20 I think your file system is borked. Nonetheless, let me upgrade myself and see if I run onto it too. --=20 Marcel Moolenaar xcllnt@mac.com ------------------------------ Message: 20 Date: Wed, 15 Sep 2010 20:47:22 -0400 From: jhell Subject: Re: ZFS Test Suite To: "Jason J. W. Williams" Cc: freebsd-current@freebsd.org Message-ID: <4C91691A.9040207@DataIX.net> Content-Type: text/plain; charset=3DISO-8859-1 On 09/15/2010 13:40, Jason J. W. Williams wrote: > Does the FreeBSD ZFS port get tested against the ZFS test suite > created by Sun? It's a fairly comprehensive suite and has delivered a > very reliable set of ZFS beta code for a long time. Trying to gauge > the stability and compatibility of the FreeBSD port. Thank you in > advance. >=20 Got a download link. Seems from this point on hub.opensolaris.org is = down. --=20 jhell,v ------------------------------ Message: 21 Date: Wed, 15 Sep 2010 19:45:14 -0600 From: "Jason J. W. Williams" Subject: Re: ZFS Test Suite To: jhell Cc: "freebsd-current@freebsd.org" Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 Yeah...Oracle closed the gate. Illumos.org probably has a copy in their fork though. -J On Wednesday, September 15, 2010, jhell wrote: > On 09/15/2010 13:40, Jason J. W. Williams wrote: >> Does the FreeBSD ZFS port get tested against the ZFS test suite >> created by Sun? It's a fairly comprehensive suite and has delivered a >> very reliable set of ZFS beta code for a long time. Trying to gauge >> the stability and compatibility of the FreeBSD port. Thank you in >> advance. >> > > Got a download link. Seems from this point on hub.opensolaris.org is = down. > > -- > > jhell,v > ------------------------------ Message: 22 Date: Wed, 15 Sep 2010 22:14:17 -0400 From: Gary Palmer Subject: Re: ZFS Test Suite To: jhell Cc: "Jason J. W. Williams" , freebsd-current@freebsd.org Message-ID: <20100916021417.GB381@in-addr.com> Content-Type: text/plain; charset=3Dus-ascii On Wed, Sep 15, 2010 at 08:47:22PM -0400, jhell wrote: > On 09/15/2010 13:40, Jason J. W. Williams wrote: > > Does the FreeBSD ZFS port get tested against the ZFS test suite > > created by Sun? It's a fairly comprehensive suite and has delivered = a > > very reliable set of ZFS beta code for a long time. Trying to gauge > > the stability and compatibility of the FreeBSD port. Thank you in > > advance. > >=20 >=20 > Got a download link. Seems from this point on hub.opensolaris.org is = down. http://hub.opensolaris.org/bin/view/Community+Group+zfs/zfstestsuite = pointed me at http://dlc.sun.com/osol/test/downloads/current/=20 The stcnv-zfs-src-20090909.tar.bz2 file was able to be downloaded from the 2nd link and produced a 4.1MB file with about 1565 entries in it according to tar -ztf. Note that I don't run ZFS here so I can't try = the test suite. Regards, Gary ------------------------------ Message: 23 Date: Wed, 15 Sep 2010 20:13:02 -0700 From: David Ehrmann Subject: Re: NFS lockups with VMware esxi client To: Rick Macklem Cc: freebsd-current@freebsd.org Message-ID: <4C918B3E.1070107@gmail.com> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed Rick Macklem wrote: >> I have NFS sharing a ZFS pool that VMware esxi stores files on. When >> put under stress (an OS installation, but not Linux compilation), the >> NFS server locks, spiking to 100% CPU usage. Not even kill -KILL can >> stop the process, so rebooting is required. >> =20 > I believe it is patched in head/current. A compatible patch is at: > http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch > > rick > =20 It worked! I grabbed the latest from STABLE, checked, saw that patch=20 was already in, compiled, and it's working. Thank you. ------------------------------ Message: 24 Date: Wed, 15 Sep 2010 19:07:03 -0700 From: joe mcguckin Subject: Can't build PERL under 8.1 Release To: freebsd-current@freebsd.org Message-ID: <1C9F72B8-26BC-4A03-AD81-3616A8AA8CA3@via.net> Content-Type: text/plain; charset=3Dus-ascii I just installed 8.1 Release. Trying to build Perl, it dies at: Running Makefile.PL in ext/DynaLoader ../../miniperl -I../../lib Makefile.PL INSTALLDIRS=3Dperl = INSTALLMAN1DIR=3Dnone INSTALLMAN3DIR=3Dnone PERL_CORE=3D1 LIBPERL_A=3Dlibperl.so = LINKTYPE=3Dstatic Writing Makefile for DynaLoader Makefile out-of-date with respect to Makefile.PL Cleaning current config before rebuilding Makefile... make -f Makefile.old clean > /dev/null 2>&1 ../../miniperl "-I../../lib" "-I../../lib" Makefile.PL = "INSTALLDIRS=3Dperl" "INSTALLMAN1DIR=3Dnone" "INSTALLMAN3DIR=3Dnone" "PERL_CORE=3D1" "LIBPERL_A=3Dlibperl.so" "LINKTYPE=3Dstatic" Writing Makefile for DynaLoader =3D=3D> Your Makefile has been rebuilt. <=3D=3D =3D=3D> Please rerun the make command. <=3D=3D false *** Error code 1 Rerunning make just make it die again in the same location. Any ideas? -joe ------------------------------ Message: 25 Date: Thu, 16 Sep 2010 11:57:04 +0100 From: Anton Shterenlikht Subject: Re: multiple problems between r212316 and r212643 on ia64 To: Marcel Moolenaar Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Message-ID: <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> Content-Type: text/plain; charset=3Dus-ascii On Wed, Sep 15, 2010 at 02:23:26PM -0700, Marcel Moolenaar wrote: >=20 > On Sep 15, 2010, at 8:23 AM, Anton Shterenlikht wrote: >=20 > >=20 > > % man ls > > zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- = unchanged > > % man man > > zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- = unchanged > >=20 > >=20 > > # cd /etc/mail > > # make start > > Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf > > sendmail-clientmqueuemailwrapper: no mapping in = /etc/mail/mailer.conf > > . > > #=20 > >=20 > > # cd /usr/src > > # svn up > > svn: Can't open file '/usr/local/etc/subversion/servers': Illegal = byte sequence > > #=20 > >=20 >=20 > I think your file system is borked. Nonetheless, let me > upgrade myself and see if I run onto it too. I did "fsck -f" in single user mode - all seems fine: # fsck -f ** /dev/da0p2 ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 723993 files, 7874130 used, 20052947 free (87043 frags, 2495738 blocks, = 0.3% fra gmentation) ***** FILE SYSTEM IS CLEAN ***** # --=20 Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ------------------------------ _______________________________________________ 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" End of freebsd-current Digest, Vol 361, Issue 4 ***********************************************