deprecation policy (Was: sysctl kern.ipc.somaxconn limit 65535 why?)
Hi Jeremie Le Hen! On Mon, 8 Oct 2012 12:49:34 +0200; Jeremie Le Hen wrote about 'Re: sysctl kern.ipc.somaxconn limit 65535 why?': On 03.10.2012 22:03, Adrian Chadd wrote: somaxconn is the connection queue depth. If it's sitting at a couple hundred thousand then something else is going crazily wrong. I understand your frustration, but there's a lot of instances where the application just isn't doing things right and the OS tries to hide it as much as psosible. Blowing out somaxconn to chew up a whole lot of resources seems a bit silly. I'd rather investigate why the userland application is not servicing the connect queue often enough. I've written network services that supported tens of thousands of new TCP connections a second on a LAN and I never once had to bump somaxconn past 32767. I'm not saying that it won't apply to your scenario, I'm just trying to explain that there's likely more going on. I guess the problem is rather kern.ipc.maxsockets which is only 25600. The name somaxconn is confusing as it specifies the listen queue limit instead of the maximum number of connections as the it suggests. If we want to change that name to something more sensible and less error-prone like somaxbacklog, does the project has a policy to change sysctl names? I'm thinking of something like renaming the sysctl to somaxbacklog and make somaxconn compatibility shim during RELENG_10 which still works but prints a warning in the dmesg. AFAIR, the policy was to keep for two major releases, not one, though it was the policy for binaries, not sysctl (e.g. if /sbin/natd would be officially made deprecated in 10.0 RELNOTES, then it must be kept in 10.* and 11.* with complete removal in 12.0). Possibly the policy for sysctl's is the same, because 3rd-party software may use such knobs, while not sure this applies to kern.*, though. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: (was: Announcing the end of port CVS) no IPv6 mirrors for portsnap.FreeBSD.org
For those reasons by February 28th 2013 the FreeBSD ports tree will no longer be exported to CVS. Therefore ports tree updates via CVS or CVSup will no longer available after that date. All users who use CVS or CVSup to update the ports tree are encouraged to switch to portsnap(8) [1] or for users which need more control over their ports collection checkout use Subversion directly: On an IPv6-only host (9.1-RC1) : # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... none found. Fetching snapshot tag from portsnap.FreeBSD.org... failed. No mirrors remaining, giving up. csup works fine: # csup /etc/cvsup/ports Connected to 2001:15c0::f::9 Updating collection ports-all/cvs Edit ports/MOVED Cleaning up ... If portsnap wants to become a mainstream ports update channel, it should be accessible over IPv6 too. Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2012-10-09 12:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-10-09 12:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-09 12:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-10-09 12:40:00 - cleaning the object tree TB --- 2012-10-09 12:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-10-09 12:40:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-10-09 12:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-10-09 12:43:26 - /usr/local/bin/svn update /src TB --- 2012-10-09 12:44:12 - At svn revision 241371 TB --- 2012-10-09 12:44:13 - building world TB --- 2012-10-09 12:44:13 - CROSS_BUILD_TESTING=YES TB --- 2012-10-09 12:44:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-09 12:44:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-09 12:44:13 - SRCCONF=/dev/null TB --- 2012-10-09 12:44:13 - TARGET=i386 TB --- 2012-10-09 12:44:13 - TARGET_ARCH=i386 TB --- 2012-10-09 12:44:13 - TZ=UTC TB --- 2012-10-09 12:44:13 - __MAKE_CONF=/dev/null TB --- 2012-10-09 12:44:13 - cd /src TB --- 2012-10-09 12:44:13 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Oct 9 12:44:23 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Oct 9 15:12:32 UTC 2012 TB --- 2012-10-09 15:12:32 - generating LINT kernel config TB --- 2012-10-09 15:12:32 - cd /src/sys/i386/conf TB --- 2012-10-09 15:12:32 - /usr/bin/make -B LINT TB --- 2012-10-09 15:12:33 - cd /src/sys/i386/conf TB --- 2012-10-09 15:12:33 - /usr/sbin/config -m LINT TB --- 2012-10-09 15:12:33 - building LINT kernel TB --- 2012-10-09 15:12:33 - CROSS_BUILD_TESTING=YES TB --- 2012-10-09 15:12:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-09 15:12:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-09 15:12:33 - SRCCONF=/dev/null TB --- 2012-10-09 15:12:33 - TARGET=i386 TB --- 2012-10-09 15:12:33 - TARGET_ARCH=i386 TB --- 2012-10-09 15:12:33 - TZ=UTC TB --- 2012-10-09 15:12:33 - __MAKE_CONF=/dev/null TB --- 2012-10-09 15:12:33 - cd /src TB --- 2012-10-09 15:12:33 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Oct 9 15:12:33 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Tue Oct 9 15:47:06 UTC 2012 TB --- 2012-10-09 15:47:06 - cd /src/sys/i386/conf TB --- 2012-10-09 15:47:06 - /usr/sbin/config -m LINT-NOINET TB --- 2012-10-09 15:47:06 - building LINT-NOINET kernel TB --- 2012-10-09 15:47:06 - CROSS_BUILD_TESTING=YES TB --- 2012-10-09 15:47:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-09 15:47:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-09 15:47:06 - SRCCONF=/dev/null TB --- 2012-10-09 15:47:06 - TARGET=i386 TB --- 2012-10-09 15:47:06 - TARGET_ARCH=i386 TB --- 2012-10-09 15:47:06 - TZ=UTC TB --- 2012-10-09 15:47:06 - __MAKE_CONF=/dev/null TB --- 2012-10-09 15:47:06 - cd /src TB --- 2012-10-09 15:47:06 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Oct 9 15:47:06 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Tue Oct 9 16:19:26 UTC 2012 TB --- 2012-10-09 16:19:26 - cd /src/sys/i386/conf TB --- 2012-10-09 16:19:26 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-10-09 16:19:26 - building LINT-NOINET6 kernel TB --- 2012-10-09 16:19:26 - CROSS_BUILD_TESTING=YES TB --- 2012-10-09 16:19:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-09 16:19:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-09 16:19:26 - SRCCONF=/dev/null TB --- 2012-10-09 16:19:26 - TARGET=i386 TB --- 2012-10-09 16:19:26 - TARGET_ARCH=i386 TB --- 2012-10-09 16:19:26 - TZ=UTC TB --- 2012-10-09 16:19:26 - __MAKE_CONF=/dev/null TB --- 2012-10-09 16:19:26 - cd /src TB --- 2012-10-09 16:19:26 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Tue Oct 9 16:19:26 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -g -DDEFAULT_JUMBO -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
Re: deprecation policy (Was: sysctl kern.ipc.somaxconn limit 65535 why?)
.. let's like, create some better sysctl descriptions? :-) Then encourage those to be used in documentation somewhere? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
perl 5.16 on current
Has anyone upgraded to Perl 5.16.0? Are there any outstanding issues or problems? Any packages that don't build? Thanks in advance for any feedback. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: perl 5.16 on current
AN wrote on 09.10.2012 22:16: Has anyone upgraded to Perl 5.16.0? Are there any outstanding issues or problems? Any packages that don't build? Thanks in advance for any feedback. Using it since August, had no problems with it. But I don't use it for programming, only for usual system/desktop stuff. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: perl 5.16 on current
On Tue, 9 Oct 2012, AN wrote: Has anyone upgraded to Perl 5.16.0? Are there any outstanding issues or problems? Any packages that don't build? Thanks in advance for any feedback. I'm using under RELENG_9 without issue though I did rebuild all dependencies. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[HEADSUP] FYI: patch to ports that do not build with clang has been committed
The commit mail hasn't gone through yet, so I guess I need to post this first and reference the commit mail later. Sometime in the near future, the default CC on -current will be switched to clang. The patch I have committed is a workaround -- an interim measure -- to get ready for this transition. I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of USE_GCC=any to a port's Makefile, and then committed that change to various ports. In most (but not all!) cases this will tell the port build with gcc instead of clang (*) . For those users with CC installed as gcc (including -stable), this patch should have no effect. Variations of combinations have been heavily tested on pointyhat-west. If there are any regressions, please contact me. You can see the difference in the errorlogs here: With USE_GCC=any: http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121007231359.pointyhat-west/index-category.html Without USE_GCC=any: http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121005165436.pointyhat-west/index-category.html While the absolute number of errors is not that much different, that is a false indication: over 2500 more packages are built with than without. For those who wish to build *only* with clang, and thus defeat the workaround, simply set FORCE_BASE_CC_FOR_TESTING=anything, either in the Makefile line, or, if you are adventurous, in your /etc/make.conf. We appreciate all the testing that we can get (it is too much for any small group of people, much less one person.) In the long run, I would like to see as many ports built natively with clang as possible, and I appreciate the work that people have been doing to move us towards that goal. However, once the switch is made, it would have been a burden to everyone tracking -current to have suddenly found themselves enlisted in that effort :-) So, for the medium-term, this workaround should reduce the POLA violation. *Note* that due to the high number (over a thousand!) ports that do not build with clang, I arbitrarily decided to apply the workaround only to ports that block 2 or more other ports from building union important ports. This does not mean that the workaround shouldn't be applied to other ports that are too hard to fix. This is part 1 of a set of patches that are being proposed to deal with the switchover. As I merge and test them some more, I will put them out for further review. Thanks. mcl * several ports are very, very, clever, and detect clang anyways; others build with gcc if CC is unset, but don't with CC=gcc. These ports are broken, and need to be fixed as we continue the process of switching over. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MPSAFE VFS -- List of upcoming actions
On Mon, Oct 8, 2012 at 7:57 AM, Attilio Rao atti...@freebsd.org wrote: On Fri, Sep 28, 2012 at 4:47 PM, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: schrieb Attilio Rao am 28.09.2012 16:18 (localtime): On Wed, Sep 26, 2012 at 12:02 PM, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: ... After many people willing to test fuse on STABLE_9, I made this patch that at least compiles there: http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch Thanks a lot! In the meantime I made the original patch compiling. I simply looked at the changes which were made around july in the fuse project to follow changes in head (checkpath(), vrecycle() and vtruncbuf()) and reverted them. Since I have no idea about the code I modified, I'm happy that you did a more qualified patch set :-) Of course, I didn't have a chance to test it because I'm also out for vacation right now but please do and report. Happy holiday!!! If you're by chance arround the Oktoberfest, drop me a note, I'll pay you a Maß (or any other drink if you don't like „Wiesnbier“) :-) I really hoped to make this year, but no luck :/ ... Some questions: Is this planned to be mfc'd and if so, how can one know? In which sense how can one know?. We usually specify MFC timeouts in the commit message (not sure if this answers your concerns). Yep, that's what I wanted to know. So if there's no MFC timeout in the log, it's not intended to be MFCd ever I guess. Thanks a lot! World/Kernel compiled fine in the meantime, I'll do some sshfs tests. Did you do any test in the end? Thanks, Attilio i have done same testing and it clearly is more stable than the old kmod. At least operations that crashed my system now work. I did see one weird anomaly, though. I had several NTFS file system mounted, one a Windows OS. I also had a GELI encrypted UFS file system mounted. They were both mounted and working. I finished with the data disk and tried to unmount it. I got no error, but it remained mounted. I did not actually try to access it. Figured it would umount when I shut down or end up dirty and I'd have to fsck it. The unmount attempt was using nautilus/gnome-mount. This is not the odd part, though. After the attempt to unmount the UFS device, I could no longer access the Window_OS file system. an ls showed the mount point to be d- and an attempt to list files in the directory reported that the socket was not found. So it looks like the attempt to unmount one NTFS FS deleted the socket for the other. This make absolutely no sense to me, but you understand the underlying opertations better than I do. Repeated efforts have failed to re-create the problem. I'm baffled. It is possible that there is no relationship between the two odd things happening at about the same time (NTFS volume lost socket and UFS disk won;t unmount, but reports no errors), but neither has happened since. FWIW, I also see that no device numbers are listed for the fuse devices: /dev/fuse 184319948 165594236 1872571290%/media/Media /dev/fuse 110636028 82934424 2770160475%/media/Windows7_OS How does the system distinguish between them? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
