Dziekuje bardzo. Jutro postaramy się 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ąd Rejonowy Gdańsk-Północ VII Gospodarczy KRS: 0000006693 Kapitał zakładowy: 10.000.000,00- PLN -----Original Message----- From: owner-freebsd-current_at_freebsd.org [mailto:owner-freebsd-current_at_freebsd.org] On Behalf Of freebsd-current-request_at_freebsd.org Sent: Thursday, September 16, 2010 2:00 PM To: freebsd-current_at_freebsd.org Subject: freebsd-current Digest, Vol 361, Issue 4 Send freebsd-current mailing list submissions to freebsd-current_at_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_at_freebsd.org You can reach the person managing the list at freebsd-current-owner_at_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=true 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 <tinderbox_at_freebsd.org> Subject: [head tinderbox] failure on powerpc64/powerpc To: FreeBSD Tinderbox <tinderbox_at_freebsd.org>, <current_at_freebsd.org>, <powerpc64_at_freebsd.org> Message-ID: <201009151254.o8FCsOd1063007_at_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=/obj TB --- 2010-09-15 12:09:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-15 12:09:10 - TARGET=powerpc TB --- 2010-09-15 12:09:10 - TARGET_ARCH=powerpc64 TB --- 2010-09-15 12:09:10 - TZ=UTC TB --- 2010-09-15 12:09:10 - __MAKE_CONF=/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=telnet_net_write -std=gnu99 -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 ===> libexec/tftpd (all) cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=gnu99 -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=gnu99 -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 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 <tinderbox_at_freebsd.org> Subject: [head tinderbox] failure on powerpc/powerpc To: FreeBSD Tinderbox <tinderbox_at_freebsd.org>, <current_at_freebsd.org>, <powerpc_at_freebsd.org> Message-ID: <201009151303.o8FD3QDP026756_at_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=/obj TB --- 2010-09-15 11:48:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-15 11:48:34 - TARGET=powerpc TB --- 2010-09-15 11:48:34 - TARGET_ARCH=powerpc TB --- 2010-09-15 11:48:34 - TZ=UTC TB --- 2010-09-15 11:48:34 - __MAKE_CONF=/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=telnet_net_write -std=gnu99 -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 ===> libexec/tftpd (all) cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=gnu99 -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=gnu99 -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 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 <krivenok.dmitry_at_gmail.com> Subject: buildworld + ccache trouble To: freebsd-current_at_freebsd.org Message-ID: <AANLkTimF79ZPE3MJeHQ=O1ismQCj916Q9kL23SBZOTL9_at_mail.gmail.com> Content-Type: text/plain; charset=ISO-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=/usr/local/libexec/ccache/world-cc CXX=/usr/local/libexec/ccache/world-c++ .endif Then I set WITHOUT_BOOT = 'YES' DEBUG_FLAGS = '-g -O0' and run make buildworld buildkernel installkernel However, I got build error: ===> lib/csu/i386-elf (obj,depend,all,install) rm -f .depend CC='/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=gnu99 -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=gnu99 -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=gnu99 -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=gnu99 -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. -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry_at_gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry_at_jabber.ru icq: 242-526-443 ------------------------------ Message: 4 Date: Wed, 15 Sep 2010 08:25:13 -0600 (MDT) From: "M. Warner Losh" <imp_at_bsdimp.com> Subject: Re: DHCP server in base To: demelier.david_at_gmail.com Cc: kimelto_at_gmail.com, ray_at_ddteam.net, dougb_at_freebsd.org, mj_at_feral.com, freebsd-current_at_freebsd.org Message-ID: <20100915.082513.802140508206832836.imp_at_bsdimp.com> Content-Type: Text/Plain; charset=us-ascii In message: <AANLkTinkJ182=GFTdWW_0OAT6rfoRJPBxnzMyukCeYnR_at_mail.gmail.com> David DEMELIER <demelier.david_at_gmail.com> writes: : 2010/9/11 Doug Barton <dougb_at_freebsd.org>: : > 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. : > : : 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 <max_at_mxcrypt.com> Subject: Re: buildworld + ccache trouble To: Dmitry Krivenok <krivenok.dmitry_at_gmail.com> Cc: freebsd-current_at_freebsd.org Message-ID: <AANLkTikdnu_WK4XTCksm=A=upNtobCHtsujAtUwW6akC_at_mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok <krivenok.dmitry_at_gmail.com> wrote: > Hello All! > I recently updated to r212634 and tried to build CURRENT tree with ccache. > > However, I got build error: > > <snip> > > 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" <bzeeb-lists_at_lists.zabbadoz.net> Subject: Re: TCP loopback socket fusing To: Andre Oppermann <oppermann_at_networx.ch> Cc: freebsd-net_at_freebsd.org, freebsd-current_at_freebsd.org Message-ID: <20100915151632.E31898_at_maildrop.int.zabbadoz.net> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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? 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 -- Bjoern A. Zeeb Welcome a new stage of life. ------------------------------ Message: 7 Date: Wed, 15 Sep 2010 16:23:53 +0100 From: Anton Shterenlikht <mexas_at_bristol.ac.uk> Subject: multiple problems between r212316 and r212643 on ia64 To: freebsd-current_at_freebsd.org, freebsd-ia64_at_freebsd.org Message-ID: <20100915152353.GA45611_at_mech-anton240.men.bris.ac.uk> Content-Type: text/plain; charset=us-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 . # 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 # 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 -- 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 <gljennjohn_at_googlemail.com> Subject: Re: TCP loopback socket fusing To: Andre Oppermann <oppermann_at_networx.ch> Cc: freebsd-net_at_freebsd.org, freebsd-current_at_freebsd.org Message-ID: <20100915181431.30677523_at_ernst.jennejohn.org> Content-Type: text/plain; charset=US-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 > properly defuse the sockets in all situations. > 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=1) -> OK d) I then set net.inet.tcp.loopfuse=0 before starting firefox -> OK e) set net.inet.tcp.loopfuse=1 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=0 in /etc/sysctl.conf. -- Gary Jennejohn ------------------------------ Message: 9 Date: Wed, 15 Sep 2010 17:48:07 +0200 From: Andre Oppermann <oppermann_at_networx.ch> Subject: Re: TCP loopback socket fusing To: "Bjoern A. Zeeb" <bzeeb-lists_at_lists.zabbadoz.net> Cc: freebsd-net_at_freebsd.org, freebsd-current_at_freebsd.org Message-ID: <4C90EAB7.2000902_at_networx.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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. -- Andre ------------------------------ Message: 10 Date: Wed, 15 Sep 2010 11:40:28 -0600 From: "Jason J. W. Williams" <jasonjwwilliams_at_gmail.com> Subject: ZFS Test Suite To: freebsd-current_at_freebsd.org Message-ID: <AANLkTim01vyns2LrzRWmH0+EhkTNUkcvaW14GkSgYCAj_at_mail.gmail.com> Content-Type: text/plain; charset=ISO-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 <dougb_at_FreeBSD.org> Subject: Re: DHCP server in base To: "M. Warner Losh" <imp_at_bsdimp.com> Cc: freebsd-current_at_freebsd.org Message-ID: <4C91100C.5060502_at_FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 only is it disingenuous for you to indicate that it was, I don't 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 it. FWIW, part of the reason that I don't agree with it is that at some point, hopefully in the near future, we will want to include the DHCPv6 client in the mix somewhere; and when we do the code base is not going 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 there was so much critical mass in favor of it that there was no point 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 I can certainly see how you would be supportive of this change. My intent was to make the argument in a general way that this is the wrong direction to go, and that users would benefit *more* from a robust modularized system. The fact that the v4 DHCPd might accidentally be a good candidate for including in the base today doesn't mean that doing so is the right strategy for the long term. Doug -- ... 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 <mav_at_FreeBSD.org> Subject: Re: Multiple hpet messages during boot To: FreeBSD-Current <freebsd-current_at_freebsd.org> Message-ID: <4C911214.7060406_at_FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Joel Dahl wrote: > I noticed this during boot (HEAD from yesterday): > > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > > 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. -- Alexander Motin ------------------------------ Message: 13 Date: Wed, 15 Sep 2010 13:36:55 -0500 From: Tom Judge <tom_at_tomjudge.com> Subject: Re: buildworld + ccache trouble To: Maxim Khitrov <max_at_mxcrypt.com> Cc: freebsd-current_at_freebsd.org, Dmitry Krivenok <krivenok.dmitry_at_gmail.com> Message-ID: <4C911247.7010309_at_tomjudge.com> Content-Type: text/plain; charset=UTF-8 On 09/15/2010 09:53 AM, Maxim Khitrov wrote: > On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok > <krivenok.dmitry_at_gmail.com> wrote: > >> Hello All! >> I recently updated to r212634 and tried to build CURRENT tree with ccache. >> >> However, I got build error: >> >> <snip> >> >> 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. > In the past I have used the solution outlined here: http://www.tomjudge.com/index.php/FreeBSD/Creating_a_%28i386/ia32%29_build_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 -- TJU13-ARIN ------------------------------ Message: 14 Date: Wed, 15 Sep 2010 22:47:00 +0300 From: Andriy Gapon <avg_at_icyb.net.ua> Subject: Re: regarding pciids To: Alexander Best <arundel_at_freebsd.org>, freebsd-current_at_freebsd.org Message-ID: <4C9122B4.2040202_at_icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 on 14/09/2010 03:59 Alexander Best said the following: > hi there, > > 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) -- Andriy Gapon ------------------------------ Message: 15 Date: Wed, 15 Sep 2010 22:14:30 +0200 From: Dimitry Andric <dim_at_FreeBSD.org> Subject: Re: buildworld + ccache trouble To: Dmitry Krivenok <krivenok.dmitry_at_gmail.com> Cc: freebsd-current_at_freebsd.org Message-ID: <4C912926.6070409_at_FreeBSD.org> Content-Type: text/plain; charset="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 _at__at_ -299,15 +299,15 _at__at_ LIB32WMAKEENV+= MAKEOBJDIRPREFIX=${OBJTREE}/lib32 \ VERSION="${VERSION}" \ INSTALL="sh ${.CURDIR}/tools/install.sh" \ PATH=${TMPPATH} \ - CC="${CC} ${LIB32FLAGS}" \ - CXX="${CXX} ${LIB32FLAGS}" \ - OBJC="${OBJC} ${LIB32FLAGS}" \ LIBDIR=/usr/lib32 \ SHLIBDIR=/usr/lib32 LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ - -DWITHOUT_HTML -DNO_CTF DESTDIR=${LIB32TMP} + -DWITHOUT_HTML -DNO_CTF DESTDIR=${LIB32TMP} \ + CC="${CC} ${LIB32FLAGS}" \ + CXX="${CXX} ${LIB32FLAGS}" \ + OBJC="${OBJC} ${LIB32FLAGS}" LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*} -DNO_INCS .endif ------------------------------ Message: 16 Date: Wed, 15 Sep 2010 17:49:44 -0400 From: John Baldwin <jhb_at_freebsd.org> Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch To: freebsd-current_at_freebsd.org Cc: Marcin Cieslak <saper_at_saper.info> Message-ID: <201009151749.45038.jhb_at_freebsd.org> Content-Type: Text/Plain; charset="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. > > Looks like it's a race condition (same in tun(4) and tap(4)), > the following patch seems to address the issue: This is a good find. I actually went through these drivers a bit further and have a bit of a larger patch to extend the locking some. Would you care to test it? Index: if_tap.c =================================================================== --- if_tap.c (revision 212557) +++ if_tap.c (working copy) _at__at_ -209,7 +209,6 _at__at_ tap_destroy(struct tap_softc *tp) { struct ifnet *ifp = tp->tap_ifp; - int s; /* Unlocked read. */ KASSERT(!(tp->tap_flags & TAP_OPEN), _at__at_ -217,10 +216,8 _at__at_ knlist_destroy(&tp->tap_rsel.si_note); destroy_dev(tp->tap_dev); - s = splimp(); ether_ifdetach(ifp); if_free_type(ifp, IFT_ETHER); - splx(s); mtx_destroy(&tp->tap_mtx); free(tp, M_TAP); _at__at_ -398,7 +395,7 _at__at_ struct tap_softc *tp = NULL; unsigned short macaddr_hi; uint32_t macaddr_mid; - int unit, s; + int unit; char *name = NULL; u_char eaddr[6]; _at__at_ -449,15 +446,13 _at__at_ dev->si_drv1 = tp; tp->tap_dev = dev; - s = splimp(); ether_ifattach(ifp, eaddr); - splx(s); mtx_lock(&tp->tap_mtx); tp->tap_flags |= TAP_INITED; mtx_unlock(&tp->tap_mtx); - knlist_init_mtx(&tp->tap_rsel.si_note, NULL); + knlist_init_mtx(&tp->tap_rsel.si_note, &tp->tap_mtx); TAPDEBUG("interface %s is created. minor = %#x\n", ifp->if_xname, dev2unit(dev)); _at__at_ -474,7 +469,7 _at__at_ { struct tap_softc *tp = NULL; struct ifnet *ifp = NULL; - int error, s; + int error; if (tapuopen == 0) { error = priv_check(td, PRIV_NET_TAP); _at__at_ -497,15 +492,13 _at__at_ tp->tap_pid = td->td_proc->p_pid; tp->tap_flags |= TAP_OPEN; ifp = tp->tap_ifp; - mtx_unlock(&tp->tap_mtx); - s = splimp(); ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; if (tapuponopen) ifp->if_flags |= IFF_UP; + mtx_unlock(&tp->tap_mtx); if_link_state_change(ifp, LINK_STATE_UP); - splx(s); TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, dev2unit(dev)); _at__at_ -524,7 +517,6 _at__at_ struct ifaddr *ifa; struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; - int s; /* junk all pending output */ IF_DRAIN(&ifp->if_snd); _at__at_ -537,25 +529,24 _at__at_ mtx_lock(&tp->tap_mtx); if (((tp->tap_flags & TAP_VMNET) == 0) && (ifp->if_flags & IFF_UP)) { mtx_unlock(&tp->tap_mtx); - s = splimp(); if_down(ifp); + mtx_lock(&tp->tap_mtx); if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + ifp->if_drv_flags &= ~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 &= ~IFF_DRV_RUNNING; + mtx_lock(&tp->tap_mtx); } - splx(s); - } else - mtx_unlock(&tp->tap_mtx); + } 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); - mtx_lock(&tp->tap_mtx); tp->tap_flags &= ~TAP_OPEN; tp->tap_pid = 0; mtx_unlock(&tp->tap_mtx); _at__at_ -580,8 +571,10 _at__at_ TAPDEBUG("initializing %s\n", ifp->if_xname); + mtx_lock(&tp->tap_mtx); ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + mtx_unlock(&tp->tap_mtx); /* attempt to start output */ tapifstart(ifp); _at__at_ -599,7 +592,7 _at__at_ struct tap_softc *tp = ifp->if_softc; struct ifreq *ifr = (struct ifreq *)data; struct ifstat *ifs = NULL; - int s, dummy; + int dummy; switch (cmd) { case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ _at__at_ -612,7 +605,6 _at__at_ break; case SIOCGIFSTATUS: - s = splimp(); ifs = (struct ifstat *)data; dummy = strlen(ifs->ascii); mtx_lock(&tp->tap_mtx); _at__at_ -621,14 +613,10 _at__at_ sizeof(ifs->ascii) - dummy, "\tOpened by PID %d\n", tp->tap_pid); mtx_unlock(&tp->tap_mtx); - splx(s); break; default: - s = splimp(); - dummy = ether_ioctl(ifp, cmd, data); - splx(s); - return (dummy); + return (ether_ioctl(ifp, cmd, data)); /* NOT REACHED */ } _at__at_ -645,7 +633,6 _at__at_ tapifstart(struct ifnet *ifp) { struct tap_softc *tp = ifp->if_softc; - int s; TAPDEBUG("%s starting\n", ifp->if_xname); _at__at_ -665,24 +652,19 _at__at_ TAPDEBUG("%s not ready, tap_flags = 0x%x\n", ifp->if_xname, tp->tap_flags); - s = splimp(); do { IF_DEQUEUE(&ifp->if_snd, m); if (m != NULL) m_freem(m); ifp->if_oerrors ++; } while (m != NULL); - splx(s); return; } - mtx_unlock(&tp->tap_mtx); - s = splimp(); ifp->if_drv_flags |= IFF_DRV_OACTIVE; - if (ifp->if_snd.ifq_len != 0) { - mtx_lock(&tp->tap_mtx); + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { if (tp->tap_flags & TAP_RWAIT) { tp->tap_flags &= ~TAP_RWAIT; wakeup(tp); _at__at_ -691,16 +673,16 _at__at_ if ((tp->tap_flags & TAP_ASYNC) && (tp->tap_sigio != NULL)) { mtx_unlock(&tp->tap_mtx); pgsigio(&tp->tap_sigio, SIGIO, 0); - } else - mtx_unlock(&tp->tap_mtx); + mtx_lock(&tp->tap_mtx); + } 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 */ } ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; - splx(s); + mtx_unlock(&tp->tap_mtx); } /* tapifstart */ _at__at_ -715,7 +697,6 _at__at_ struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; struct tapinfo *tapp = NULL; - int s; int f; #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD4) _at__at_ -724,12 +705,10 _at__at_ switch (cmd) { case TAPSIFINFO: - s = splimp(); tapp = (struct tapinfo *)data; ifp->if_mtu = tapp->mtu; ifp->if_type = tapp->type; ifp->if_baudrate = tapp->baudrate; - splx(s); break; case TAPGIFINFO: _at__at_ -757,26 +736,26 _at__at_ break; case FIOASYNC: - s = splimp(); mtx_lock(&tp->tap_mtx); if (*(int *)data) tp->tap_flags |= TAP_ASYNC; else tp->tap_flags &= ~TAP_ASYNC; mtx_unlock(&tp->tap_mtx); - splx(s); break; case FIONREAD: - s = splimp(); - if (ifp->if_snd.ifq_head) { - struct mbuf *mb = ifp->if_snd.ifq_head; + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { + struct mbuf *mb; - for(*(int *)data = 0;mb != NULL;mb = mb->m_next) + IFQ_LOCK(&ifp->if_snd); + IFQ_POLL_NOLOCK(&ifp->if_snd, mb); + for (*(int *)data = 0; mb != NULL; + mb = mb->m_next) *(int *)data += mb->m_len; + IFQ_UNLOCK(&ifp->if_snd); } else *(int *)data = 0; - splx(s); break; case FIOSETOWN: _at__at_ -797,10 +776,6 _at__at_ /* VMware/VMnet port ioctl's */ - 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): _at__at_ -814,9 +789,9 _at__at_ f &= ~IFF_CANTCHANGE; f |= IFF_UP; - s = splimp(); + mtx_lock(&tp->tap_mtx); ifp->if_flags = f | (ifp->if_flags & IFF_CANTCHANGE); - splx(s); + mtx_unlock(&tp->tap_mtx); break; case OSIOCGIFADDR: /* get MAC address of the remote side */ _at__at_ -851,7 +826,7 _at__at_ struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; struct mbuf *m = NULL; - int error = 0, len, s; + int error = 0, len; TAPDEBUG("%s reading, minor = %#x\n", ifp->if_xname, dev2unit(dev)); _at__at_ -867,26 +842,27 _at__at_ } tp->tap_flags &= ~TAP_RWAIT; - mtx_unlock(&tp->tap_mtx); /* sleep until we get a packet */ do { - s = splimp(); IF_DEQUEUE(&ifp->if_snd, m); - splx(s); if (m == NULL) { - if (flag & O_NONBLOCK) + if (flag & O_NONBLOCK) { + mtx_unlock(&tp->tap_mtx); return (EWOULDBLOCK); + } - mtx_lock(&tp->tap_mtx); tp->tap_flags |= TAP_RWAIT; - mtx_unlock(&tp->tap_mtx); - error = tsleep(tp,PCATCH|(PZERO+1),"taprd",0); - if (error) + error = mtx_sleep(tp, &tp->tap_mtx, PCATCH | (PZERO + 1), + "taprd", 0); + if (error) { + mtx_unlock(&tp->tap_mtx); return (error); + } } } while (m == NULL); + mtx_unlock(&tp->tap_mtx); /* feed packet to bpf */ BPF_MTAP(ifp, m); _at__at_ -982,14 +958,14 _at__at_ { struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; - int s, revents = 0; + int revents = 0; TAPDEBUG("%s polling, minor = %#x\n", ifp->if_xname, dev2unit(dev)); - s = 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 = %d, " \ "minor = %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); _at__at_ -1001,12 +977,12 _at__at_ selrecord(td, &tp->tap_rsel); } + IFQ_UNLOCK(&ifp->if_snd); } if (events & (POLLOUT | POLLWRNORM)) revents |= (events & (POLLOUT | POLLWRNORM)); - splx(s); return (revents); } /* tappoll */ _at__at_ -1019,11 +995,9 _at__at_ static int tapkqfilter(struct cdev *dev, struct knote *kn) { - int s; struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; - s = splimp(); switch (kn->kn_filter) { case EVFILT_READ: TAPDEBUG("%s kqfilter: EVFILT_READ, minor = %#x\n", _at__at_ -1040,11 +1014,9 _at__at_ default: TAPDEBUG("%s kqfilter: invalid filter, minor = %#x\n", ifp->if_xname, dev2unit(dev)); - splx(s); return (EINVAL); /* NOT REACHED */ } - splx(s); kn->kn_hook = (caddr_t) dev; knlist_add(&tp->tap_rsel.si_note, kn, 0); _at__at_ -1061,12 +1033,11 _at__at_ static int tapkqread(struct knote *kn, long hint) { - int ret, s; + int ret; struct cdev *dev = (struct cdev *)(kn->kn_hook); struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; - s = splimp(); if ((kn->kn_data = ifp->if_snd.ifq_len) > 0) { TAPDEBUG("%s have data in queue. len = %d, minor = %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); _at__at_ -1076,7 +1047,6 _at__at_ ifp->if_xname, dev2unit(dev)); ret = 0; } - splx(s); return (ret); } /* tapkqread */ _at__at_ -1090,13 +1060,10 _at__at_ static int tapkqwrite(struct knote *kn, long hint) { - int s; struct tap_softc *tp = ((struct cdev *) kn->kn_hook)->si_drv1; struct ifnet *ifp = tp->tap_ifp; - s = splimp(); kn->kn_data = ifp->if_mtu; - splx(s); return (1); } /* tapkqwrite */ Index: if_tun.c =================================================================== --- if_tun.c (revision 212557) +++ if_tun.c (working copy) _at__at_ -344,13 +344,13 _at__at_ tp->tun_flags &= ~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); } /* XXX: should return an error code so it can fail. */ _at__at_ -385,7 +385,7 _at__at_ IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); ifp->if_snd.ifq_drv_maxlen = 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 |= IFCAP_LINKSTATE; ifp->if_capenable |= IFCAP_LINKSTATE; _at__at_ -443,7 +443,6 _at__at_ { struct tun_softc *tp; struct ifnet *ifp; - int s; tp = dev->si_drv1; ifp = TUN2IFP(tp); _at__at_ -451,27 +450,25 _at__at_ mtx_lock(&tp->tun_mtx); tp->tun_flags &= ~TUN_OPEN; tp->tun_pid = 0; - mtx_unlock(&tp->tun_mtx); /* * junk all pending output */ CURVNET_SET(ifp->if_vnet); - s = splimp(); IFQ_PURGE(&ifp->if_snd); - splx(s); if (ifp->if_flags & IFF_UP) { - s = splimp(); + mtx_unlock(&tp->tun_mtx); if_down(ifp); - splx(s); + mtx_lock(&tp->tun_mtx); } /* Delete all addresses and routes which reference this interface. */ if (ifp->if_drv_flags & IFF_DRV_RUNNING) { struct ifaddr *ifa; - s = splimp(); + ifp->if_drv_flags &= ~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 == AF_INET) { _at__at_ -482,16 +479,14 _at__at_ } } if_purgeaddrs(ifp); - ifp->if_drv_flags &= ~IFF_DRV_RUNNING; - splx(s); + mtx_lock(&tp->tun_mtx); } if_link_state_change(ifp, LINK_STATE_DOWN); CURVNET_RESTORE(); - 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"); cv_broadcast(&tp->tun_cv); _at__at_ -510,9 +505,11 _at__at_ TUNDEBUG(ifp, "tuninit\n"); + mtx_lock(&tp->tun_mtx); ifp->if_flags |= IFF_UP; ifp->if_drv_flags |= IFF_DRV_RUNNING; getmicrotime(&ifp->if_lastchange); + mtx_unlock(&tp->tun_mtx); #ifdef INET if_addr_rlock(ifp); _at__at_ -545,9 +542,8 _at__at_ struct ifreq *ifr = (struct ifreq *)data; struct tun_softc *tp = ifp->if_softc; struct ifstat *ifs; - int error = 0, s; + int error = 0; - s = splimp(); switch(cmd) { case SIOCGIFSTATUS: ifs = (struct ifstat *)data; _at__at_ -576,7 +572,6 _at__at_ default: error = EINVAL; } - splx(s); return (error); } _at__at_ -682,7 +677,6 _at__at_ static int tunioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread *td) { - int s; int error; struct tun_softc *tp = dev->si_drv1; struct tuninfo *tunp; _at__at_ -745,9 +739,11 _at__at_ switch (*(int *)data & ~IFF_MULTICAST) { case IFF_POINTOPOINT: case IFF_BROADCAST: + mtx_lock(&tp->tun_mtx); TUN2IFP(tp)->if_flags &= ~(IFF_BROADCAST|IFF_POINTOPOINT|IFF_MULTICAST); TUN2IFP(tp)->if_flags |= *(int *)data; + mtx_unlock(&tp->tun_mtx); break; default: return(EINVAL); _at__at_ -769,17 +765,15 _at__at_ mtx_unlock(&tp->tun_mtx); break; case FIONREAD: - s = 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 = 0; mb != 0; mb = mb->m_next) + for (*(int *)data = 0; mb != NULL; mb = mb->m_next) *(int *)data += mb->m_len; IFQ_UNLOCK(&TUN2IFP(tp)->if_snd); } else *(int *)data = 0; - splx(s); break; case FIOSETOWN: return (fsetown(*(int *)data, &tp->tun_sigio)); _at__at_ -813,7 +807,7 _at__at_ struct tun_softc *tp = dev->si_drv1; struct ifnet *ifp = TUN2IFP(tp); struct mbuf *m; - int error=0, len, s; + int error=0, len; TUNDEBUG (ifp, "read\n"); mtx_lock(&tp->tun_mtx); _at__at_ -824,27 +818,24 _at__at_ } tp->tun_flags &= ~TUN_RWAIT; - mtx_unlock(&tp->tun_mtx); - s = splimp(); do { IFQ_DEQUEUE(&ifp->if_snd, m); if (m == NULL) { if (flag & O_NONBLOCK) { - splx(s); + mtx_unlock(&tp->tun_mtx); return (EWOULDBLOCK); } - mtx_lock(&tp->tun_mtx); tp->tun_flags |= TUN_RWAIT; - mtx_unlock(&tp->tun_mtx); - if ((error = tsleep(tp, PCATCH | (PZERO + 1), - "tunread", 0)) != 0) { - splx(s); + error = mtx_sleep(tp, &tp->tun_mtx, PCATCH | (PZERO + 1), + "tunread", 0); + if (error != 0) { + mtx_unlock(&tp->tun_mtx); return (error); } } } while (m == NULL); - splx(s); + mtx_unlock(&tp->tun_mtx); while (m && uio->uio_resid > 0 && error == 0) { len = min(uio->uio_resid, m->m_len); _at__at_ -957,13 +948,11 _at__at_ static int tunpoll(struct cdev *dev, int events, struct thread *td) { - int s; struct tun_softc *tp = dev->si_drv1; struct ifnet *ifp = TUN2IFP(tp); int revents = 0; struct mbuf *m; - s = splimp(); TUNDEBUG(ifp, "tunpoll\n"); if (events & (POLLIN | POLLRDNORM)) { _at__at_ -981,7 +970,6 _at__at_ if (events & (POLLOUT | POLLWRNORM)) revents |= events & (POLLOUT | POLLWRNORM); - splx(s); return (revents); } _at__at_ -991,11 +979,9 _at__at_ static int tunkqfilter(struct cdev *dev, struct knote *kn) { - int s; struct tun_softc *tp = dev->si_drv1; struct ifnet *ifp = TUN2IFP(tp); - s = splimp(); switch(kn->kn_filter) { case EVFILT_READ: TUNDEBUG(ifp, "%s kqfilter: EVFILT_READ, minor = %#x\n", _at__at_ -1012,10 +998,8 _at__at_ default: TUNDEBUG(ifp, "%s kqfilter: invalid filter, minor = %#x\n", ifp->if_xname, dev2unit(dev)); - splx(s); return(EINVAL); } - splx(s); kn->kn_hook = (caddr_t) dev; knlist_add(&tp->tun_rsel.si_note, kn, 0); _at__at_ -1029,12 +1013,11 _at__at_ static int tunkqread(struct knote *kn, long hint) { - int ret, s; + int ret; struct cdev *dev = (struct cdev *)(kn->kn_hook); struct tun_softc *tp = dev->si_drv1; struct ifnet *ifp = TUN2IFP(tp); - s = splimp(); if ((kn->kn_data = ifp->if_snd.ifq_len) > 0) { TUNDEBUG(ifp, "%s have data in the queue. Len = %d, minor = %#x\n", _at__at_ -1046,7 +1029,6 _at__at_ dev2unit(dev)); ret = 0; } - splx(s); return (ret); } _at__at_ -1057,13 +1039,10 _at__at_ static int tunkqwrite(struct knote *kn, long hint) { - int s; struct tun_softc *tp = ((struct cdev *)kn->kn_hook)->si_drv1; struct ifnet *ifp = TUN2IFP(tp); - s = splimp(); kn->kn_data = ifp->if_mtu; - splx(s); return (1); } -- John Baldwin ------------------------------ Message: 17 Date: Wed, 15 Sep 2010 21:57:34 +0000 (UTC) From: Marcin Cieslak <saper_at_saper.info> Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch To: freebsd-current_at_freebsd.org Message-ID: <slrni92gae.177v.saper_at_saper.info> Content-Type: text/plain; charset=UTF-8 Dnia 15.09.2010 John Baldwin <jhb_at_freebsd.org> napisaE/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. >> >> Looks like it's a race condition (same in tun(4) and tap(4)), >> the following patch seems to address the issue: > > This is a good find. I actually went through these drivers a bit further and > have a bit of a larger patch to extend the locking some. Would you care to > 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) _at_ /usr/src/sys/net/route.c:370 2nd 0xc2472a04 if_afdata (if_afdata) _at_ /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 = 0x28128acf, esp = 0xbfbfed80, ebp = 0xbfbfed8c --- ^Ctun0: link state changed to DOWN -------8<------------------------------------------------------------------- ------- lock order reversal: 1st 0xc24db8c8 rtentrystray irq7 (rtentry) _at_ /usr/src/sys/net/route.c:370 2nd 0xc2482604 if_afdata (if_afdata) _at_ /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 = 0x28128acf, esp = 0xbfbfed80, ebp = 0xbfbfed8c --- tun0: link state changed to DOWN -------8<------------------------------------------------------------------- ------- --Marcin ------------------------------ Message: 18 Date: Wed, 15 Sep 2010 22:08:32 +0000 From: Alexander Best <arundel_at_freebsd.org> Subject: WITHOUT_BIND=true and `make delete-old` To: freebsd-current_at_freebsd.org Message-ID: <20100915220832.GA24698_at_freebsd.org> Content-Type: text/plain; charset=us-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=true? cheers. alex -- a13x ------------------------------ Message: 19 Date: Wed, 15 Sep 2010 14:23:26 -0700 From: Marcel Moolenaar <xcllnt_at_mac.com> Subject: Re: multiple problems between r212316 and r212643 on ia64 To: Anton Shterenlikht <mexas_at_bristol.ac.uk> Cc: freebsd-current_at_freebsd.org, freebsd-ia64_at_freebsd.org Message-ID: <5667FD77-8DBC-4638-80B6-67BCF9D4FB29_at_mac.com> Content-Type: text/plain; charset=us-ascii On Sep 15, 2010, at 8:23 AM, Anton Shterenlikht wrote: > > % 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 > > > # cd /etc/mail > # make start > Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf > sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf > . > # > > # cd /usr/src > # svn up > svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence > # > I think your file system is borked. Nonetheless, let me upgrade myself and see if I run onto it too. -- Marcel Moolenaar xcllnt_at_mac.com ------------------------------ Message: 20 Date: Wed, 15 Sep 2010 20:47:22 -0400 From: jhell <jhell_at_DataIX.net> Subject: Re: ZFS Test Suite To: "Jason J. W. Williams" <jasonjwwilliams_at_gmail.com> Cc: freebsd-current_at_freebsd.org Message-ID: <4C91691A.9040207_at_DataIX.net> Content-Type: text/plain; charset=ISO-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. > Got a download link. Seems from this point on hub.opensolaris.org is down. -- jhell,v ------------------------------ Message: 21 Date: Wed, 15 Sep 2010 19:45:14 -0600 From: "Jason J. W. Williams" <jasonjwwilliams_at_gmail.com> Subject: Re: ZFS Test Suite To: jhell <jhell_at_dataix.net> Cc: "freebsd-current_at_freebsd.org" <freebsd-current_at_freebsd.org> Message-ID: <AANLkTin-pKQyvYujMAjECcy9F2hkXHU0ELiPrR1Lt5O9_at_mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Yeah...Oracle closed the gate. Illumos.org probably has a copy in their fork though. -J On Wednesday, September 15, 2010, jhell <jhell_at_dataix.net> 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 <gpalmer_at_freebsd.org> Subject: Re: ZFS Test Suite To: jhell <jhell_at_DataIX.net> Cc: "Jason J. W. Williams" <jasonjwwilliams_at_gmail.com>, freebsd-current_at_freebsd.org Message-ID: <20100916021417.GB381_at_in-addr.com> Content-Type: text/plain; charset=us-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. > > > > 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/ 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 <ehrmann_at_gmail.com> Subject: Re: NFS lockups with VMware esxi client To: Rick Macklem <rmacklem_at_uoguelph.ca> Cc: freebsd-current_at_freebsd.org Message-ID: <4C918B3E.1070107_at_gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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. >> > I believe it is patched in head/current. A compatible patch is at: > http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch > > rick > It worked! I grabbed the latest from STABLE, checked, saw that patch was already in, compiled, and it's working. Thank you. ------------------------------ Message: 24 Date: Wed, 15 Sep 2010 19:07:03 -0700 From: joe mcguckin <joe_at_via.net> Subject: Can't build PERL under 8.1 Release To: freebsd-current_at_freebsd.org Message-ID: <1C9F72B8-26BC-4A03-AD81-3616A8AA8CA3_at_via.net> Content-Type: text/plain; charset=us-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=perl INSTALLMAN1DIR=none INSTALLMAN3DIR=none PERL_CORE=1 LIBPERL_A=libperl.so LINKTYPE=static 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=perl" "INSTALLMAN1DIR=none" "INSTALLMAN3DIR=none" "PERL_CORE=1" "LIBPERL_A=libperl.so" "LINKTYPE=static" Writing Makefile for DynaLoader ==> Your Makefile has been rebuilt. <== ==> Please rerun the make command. <== 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 <mexas_at_bristol.ac.uk> Subject: Re: multiple problems between r212316 and r212643 on ia64 To: Marcel Moolenaar <xcllnt_at_mac.com> Cc: freebsd-current_at_freebsd.org, Anton Shterenlikht <mexas_at_bristol.ac.uk>, freebsd-ia64_at_freebsd.org Message-ID: <20100916105704.GB51787_at_mech-anton240.men.bris.ac.uk> Content-Type: text/plain; charset=us-ascii On Wed, Sep 15, 2010 at 02:23:26PM -0700, Marcel Moolenaar wrote: > > On Sep 15, 2010, at 8:23 AM, Anton Shterenlikht wrote: > > > > > % 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 > > > > > > # cd /etc/mail > > # make start > > Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf > > sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf > > . > > # > > > > # cd /usr/src > > # svn up > > svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence > > # > > > > 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 ***** # -- 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_at_freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" End of freebsd-current Digest, Vol 361, Issue 4 ***********************************************Received on Thu Sep 16 2010 - 10:38:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC