Diskless setup with NFS_V4
Its posible use currentle FreeBSD on NFS_V4 root? Explain: pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel. In this setup kernel can use only configured (established) nfs fh. This is not allowed to switch version or some options. When pxeboot use TFTP (not NFS) kernel (in nfs/bootp_subr.c) do DHCP discover and don't allow (in nfs/nfs_diskless.c:nfs_parse_options) 'nfsv4' option. nfs/nfs_diskless.c:nfs_setup_diskless also initialy set nd3-root_args.flags = (NFSMNT_NFSV3 | NFSMNT_WSIZE | NFSMNT_RSIZE | NFSMNT_RESVPORT); and don't allow 'nfsv4' option. Where I be wrong? How I can use diskless setup with R/O root on NFS_V4 share? ___ 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: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 06:42:21PM +0800, Julian Elischer wrote: On 8/23/13 6:35 PM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fr?hlich de...@freebsd.org wrote: I don't know if you are aware that IF you really do that we will have serious problems to ship packages for 10. USE_GCC=any is the fallback in the portstree for all ports that are unable to build with clang which was introduced when HEAD switched to clang as default cc. Right now there are 150 ports in the tree that use this fallback and quite a few of them are high profile ports: the highlights: audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 security/clamav the full list: http://dpaste.com/1354075/ A possible hack could be to add a check for USE_GCC=any to behave like a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc from ports for a lot of people on HEAD I suppose. We certainly need to do that switch to remove the ancient gcc from base some time but with my portmgr hat on I can only say we don't plan to do that before 10.0 especially not if we are only talking about a few weeks time window. That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). no, I believe we have said that 10 would ship with clang by default. 10 from this winner have broken firewire code when building by clang -- cannot resume from sleep. ___ 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: Diskless setup with NFS_V4
On Fri, Aug 23, 2013 at 09:32:35AM -0400, Rick Macklem wrote: Slawa Olhovchenkov wrote: Its posible use currentle FreeBSD on NFS_V4 root? Explain: pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel. In this setup kernel can use only configured (established) nfs fh. This is not allowed to switch version or some options. When pxeboot use TFTP (not NFS) kernel (in nfs/bootp_subr.c) do DHCP discover and don't allow (in nfs/nfs_diskless.c:nfs_parse_options) 'nfsv4' option. nfs/nfs_diskless.c:nfs_setup_diskless also initialy set nd3-root_args.flags = (NFSMNT_NFSV3 | NFSMNT_WSIZE | NFSMNT_RSIZE | NFSMNT_RESVPORT); and don't allow 'nfsv4' option. Where I be wrong? How I can use diskless setup with R/O root on NFS_V4 share? No. There are a couple of problems that would need to be resolved for an NFSv4 root fs to work. 1 - An NFSv4 mount needs a unique identifier for the client machine. It currently uses the host uuid, but that is filled in by a userland utility run from the root fs (ie. not available soon enough). Linux uses the ip host address for this, which I believe is bogus and inappropriate. As I see in /etc/rc.d/hostid first try is 'kenv -q smbios.system.uuid'. This is not need userland utility. 2 - Without the nfsuserd daemon running, there is currently no uid/gid--name mappings available. This might work, but there would be a lot of file owned by nobody situations that could cause problems. This is ok for kernel loading and is same as NFSv3. I suspect this can be fixed by hardwiring a few mappings (root, bin,...), but there is currently no code to do this. The Linux solution for this is to put the number in a string on the wire and the updated draft of RFC3530 (called rfc3530bis, not yet an RFC) allows this, so eventually this will be supported by most/all servers. Until 1 and 2 are resolved, doing an NFSv4 root fs mount is not practical. To be honest, I don't see a need for it, since I'm old fashioned and still believe that the root fs should be a small volume of critical system utilities only, so an NFSv3 mount of it should be sufficient. (ie. If /var and any other subtrees where files might get byte range locked are on separate volumes, I think it should be fine with a NFSv3 root fs mount, even without running rpc.lockd.) I am try to build many diskless workers with fat software. NFSv4 targeting as more fast. And NFSv4 don't have problem with different UIDs. ___ 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: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 06:54:44AM -0700, Adrian Chadd wrote: Hi! If firewire code doesn't build on clang correctly, have you filed a bug so it gets looked at before 10.0 is released? that's pretty broken code/behaviour. How I can do it correctly? Currently in src.conf: WITHOUT_CLANG=yes WITHOUT_CLANG_IS_CC=yes Need recompile world? System build from sources Jun 8. clang -- Jan 9. ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 06:30:24AM -0400, Sam Fourman Jr. wrote: If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; Well, we write rules and we brake them. ;-) Just say that we know we brake them but it's inevitable because... And go futher. I am not a developer, just a user, so I am not versed in all of the issues but I would REALLY like to see gcc moved to ports for 10.x In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 12:11:16PM +, Sam Fourman Jr. wrote: In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Well, in this case, you would just have the mplayer maintainer configure the port to use gcc for the i386 build of mplayer... problem solved Yes, I just edit Makefile. But this is point about ports builded by clang. ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax that clang does not recognise, then please will you point me to the relevant LLVM bug report and I will investigate it. Sorry, I don't know about clang/llvm bug reports, I just try to build mplayer with Win32 codecs support on FreeBSD-10/i386. And currenly (in rev r315041) building by clang disabled in ports tree. PS: Also, if FreeBSD ship clang why ship not full set of clang? For example, when I try to build llvm-lua not found sets of files: LLVMCompiler.cpp:25:30: error: llvm/LLVMContext.h: No such file or directory LLVMCompiler.cpp:26:31: error: llvm/DerivedTypes.h: No such file or directory LLVMCompiler.cpp:27:50: error: llvm/ExecutionEngine/ExecutionEngine.h: No such file or directory LLVMCompiler.cpp:28:25: error: llvm/Module.h: No such file or directory LLVMCompiler.cpp:29:30: error: llvm/PassManager.h: No such file or directory LLVMCompiler.cpp:30:36: error: llvm/Analysis/Verifier.h: No such file or directory LLVMCompiler.cpp:31:36: error: llvm/Target/TargetData.h: No such file or directory LLVMCompiler.cpp:32:39: error: llvm/Target/TargetMachine.h: No such file or directory LLVMCompiler.cpp:33:40: error: llvm/Target/TargetOptions.h: No such file or directory LLVMCompiler.cpp:34:36: error: llvm/Transforms/Scalar.h: No such file or directory LLVMCompiler.cpp:35:33: error: llvm/Transforms/IPO.h: No such file or directory LLVMCompiler.cpp:36:43: error: llvm/Transforms/Utils/Cloning.h: No such file or directory LLVMCompiler.cpp:37:36: error: llvm/Support/IRBuilder.h: No such file or directory LLVMCompiler.cpp:38:32: error: llvm/Support/Timer.h: No such file or directory LLVMCompiler.cpp:39:38: error: llvm/Support/CommandLine.h: No such file or directory ___ 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: patch to add AES intrinsics to gcc
On Sat, Aug 24, 2013 at 01:05:13AM +0400, Slawa Olhovchenkov wrote: On Fri, Aug 23, 2013 at 06:54:44AM -0700, Adrian Chadd wrote: Hi! If firewire code doesn't build on clang correctly, have you filed a bug so it gets looked at before 10.0 is released? that's pretty broken code/behaviour. How I can do it correctly? Currently in src.conf: WITHOUT_CLANG=yes WITHOUT_CLANG_IS_CC=yes Need recompile world? System build from sources Jun 8. clang -- Jan 9. I build world w/o this options. After this I build kernel and install it. Reboot. acpiconf -s 3. power button. I got NMI. Sorry, dump don't allowed -- dump device don't ready at this moment. This is screenphoto http://zxy.spb.ru/13080005.jpg Kernel builded by GCC succeseful resuming (w/o NMI). Is it sufficient information for open PR? ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote: On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax that clang does not recognise, then please will you point me to the relevant LLVM bug report and I will investigate it. Sorry, I don't know about clang/llvm bug reports, I just try to build mplayer with Win32 codecs support on FreeBSD-10/i386. And currenly (in rev r315041) building by clang disabled in ports tree. And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. ___ 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: GCC withdraw
On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: On 24 Aug 2013, at 16:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. Irrelevant to the discussion since the base system GCC has the same problem. How about ports/180564? And llvm community known about this issue: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.html ___ 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: GCC withdraw
On Sun, Aug 25, 2013 at 02:23:54AM -0500, Scot Hetzel wrote:
On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote:
On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote:
On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
Oh, I remember. mplayer on i386 can't be builded witch clang -- clang
don't understand inlined asm.
Clang supports inline asm. If there is some specific inline asm
syntax that clang does not recognise, then please will you point me
to the relevant LLVM bug report and I will investigate it.
Sorry, I don't know about clang/llvm bug reports, I just try to build
mplayer with Win32 codecs support on FreeBSD-10/i386.
And currenly (in rev r315041) building by clang disabled in ports tree.
And i found PR about clang and mplayer: ports/176272
This PR contains log with build error log.
PR176272 is form mplayer-1.1.r20120721_2, and was closed due to the
issue was fixed by updating the port to a more recent version.
Mplayer is currently mplayer-1.1.r20130308, do you still see the same
issues with clang?
Now issues as in ports/180564. Not same, but very close ('ran out of
registers during register allocation' in other place).
___
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: GCC withdraw
On Sun, Aug 25, 2013 at 12:23:45AM -0700, Rui Paulo wrote: On 25 Aug 2013, at 00:24, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: On 24 Aug 2013, at 16:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. Irrelevant to the discussion since the base system GCC has the same problem. How about ports/180564? And llvm community known about this issue: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.html Have you tried submitting that directly to mplayer? No, I don't know about mplayer bug database and mplayer's support FreeBSD-current as target. ___ 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: GCC withdraw
On Fri, Aug 30, 2013 at 04:11:08PM +0100, David Chisnall wrote: Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) And remember about breaking firewire+clang ___ 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: New iSCSI stack.
On Thu, Sep 05, 2013 at 12:27:12PM +0200, Edward Tomasz Napiera?a wrote: Hello. At http://people.freebsd.org/~trasz/cfiscsi-20130904.diff you'll find a patch which adds the new iSCSI initiator and target, against 10-CURRENT. To use the new initiator, start with man iscsictl. For the target - man ctld. All feedback is welcome. If nothing unexpected comes up, I'll commit it in a few days from now. Note that it's still not optimized; at this point I'm focusing more on reliability and interoperability. I (as you probaly know) use cfiscsi-20130426.diff in producrion. Nice! Sorry, I don't have hardware for test cfiscsi-20130904.diff. ___ 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: New iSCSI stack.
On Sun, Sep 08, 2013 at 12:29:53PM +0200, Edward Tomasz Napiera?a wrote: We would love to quickly backport and ship this with FreeNAS as an option for our users, having the config files be the same OR having a very good converter would really make that much easier for us. Porting to 9 should be quite easy - there are Capsicum API differences; you might also want to compare CTL between 10 and 9 to see if there are any changes which need to be merged. Taking a look at the code searching for possible security issues would be also very welcome :-) As for the config files - writing a converter should be quite easy. Which configuration files you need to support, ctl.conf(5) and istgt configuration? Can you write utility for _generate_ ctl.conf from runtime configuration? Curenly configuring directly by `ctladm create` is more predictable from script, but incompatible by syntax and not persistent. ___ 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
long standing tcp bug: kern/25986
This PR contains patch. Can anybody commit it? Bug opened from 2001-Mar-22 ___ 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
ZFS txg implementation flaw
I can be wrong. As I see ZFS cretate seperate thread for earch txg writing. Also for writing to L2ARC. As result -- up to several thousands threads created and destoyed per second. And hundreds thousands page allocations, zeroing, maping unmaping and freeing per seconds. Very high overhead. In systat -vmstat I see totfr up to 60, prcfr up to 20. Estimated overhead -- 30% of system time. Can anybody implement thread and page pool for txg? ___ 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: ZFS txg implementation flaw
On Mon, Oct 28, 2013 at 10:45:02AM -0700, aurfalien wrote: On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov wrote: I can be wrong. As I see ZFS cretate seperate thread for earch txg writing. Also for writing to L2ARC. As result -- up to several thousands threads created and destoyed per second. And hundreds thousands page allocations, zeroing, maping unmaping and freeing per seconds. Very high overhead. In systat -vmstat I see totfr up to 60, prcfr up to 20. Estimated overhead -- 30% of system time. Can anybody implement thread and page pool for txg? Would lowering vfs.zfs.txg.timeout be a way to tame or mitigate this? vfs.zfs.txg.timeout: 5 Only x5 lowering (less in real case with burst writing). And more fragmentation on writing and etc. ___ 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: ZFS txg implementation flaw
On Mon, Oct 28, 2013 at 02:28:04PM -0400, Allan Jude wrote: On 2013-10-28 14:16, Slawa Olhovchenkov wrote: On Mon, Oct 28, 2013 at 10:45:02AM -0700, aurfalien wrote: On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov wrote: I can be wrong. As I see ZFS cretate seperate thread for earch txg writing. Also for writing to L2ARC. As result -- up to several thousands threads created and destoyed per second. And hundreds thousands page allocations, zeroing, maping unmaping and freeing per seconds. Very high overhead. In systat -vmstat I see totfr up to 60, prcfr up to 20. Estimated overhead -- 30% of system time. Can anybody implement thread and page pool for txg? Would lowering vfs.zfs.txg.timeout be a way to tame or mitigate this? vfs.zfs.txg.timeout: 5 Only x5 lowering (less in real case with burst writing). And more fragmentation on writing and etc. ___ 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 From my understanding, increasing the timeout so you are doing fewer transaction groups, would actually be the way to increase performance, at the cost of 'bursty' writing and the associated uneven latency. This (increasing the timeout) is dramaticaly decreasing read performance by very high IO burst. ___ 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: ZFS txg implementation flaw
On Mon, Oct 28, 2013 at 04:51:02PM -0400, Allan Jude wrote: On 2013-10-28 16:48, Slawa Olhovchenkov wrote: On Mon, Oct 28, 2013 at 02:28:04PM -0400, Allan Jude wrote: On 2013-10-28 14:16, Slawa Olhovchenkov wrote: On Mon, Oct 28, 2013 at 10:45:02AM -0700, aurfalien wrote: On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov wrote: I can be wrong. As I see ZFS cretate seperate thread for earch txg writing. Also for writing to L2ARC. As result -- up to several thousands threads created and destoyed per second. And hundreds thousands page allocations, zeroing, maping unmaping and freeing per seconds. Very high overhead. In systat -vmstat I see totfr up to 60, prcfr up to 20. Estimated overhead -- 30% of system time. Can anybody implement thread and page pool for txg? Would lowering vfs.zfs.txg.timeout be a way to tame or mitigate this? vfs.zfs.txg.timeout: 5 Only x5 lowering (less in real case with burst writing). And more fragmentation on writing and etc. ___ 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 From my understanding, increasing the timeout so you are doing fewer transaction groups, would actually be the way to increase performance, at the cost of 'bursty' writing and the associated uneven latency. This (increasing the timeout) is dramaticaly decreasing read performance by very high IO burst. It shouldn't affect read performance, except during the flush operations (every txg.timeout seconds) Yes, I talk about this time. If you watch with 'gstat' or 'gstat -f ada.$' you should see the cycle reading quickly, then every txg.timeout seconds (and for maybe longer), it flushes the entire transaction group (may be 100s of MBs) to the disk, this high write load may make reads slow until it is finished. Yes. And read may delayed for some seconds. This is unacceptable for may case. ___ 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: ZFS txg implementation flaw
On Mon, Oct 28, 2013 at 02:22:16PM -0700, Jordan Hubbard wrote:
On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
As I see ZFS cretate seperate thread for earch txg writing.
Also for writing to L2ARC.
As result -- up to several thousands threads created and destoyed per
second. And hundreds thousands page allocations, zeroing, maping
unmaping and freeing per seconds. Very high overhead.
How are you measuring the number of threads being created / destroyed? This
claim seems erroneous given how the ZFS thread pool mechanism actually works
(and yes, there are thread pools already).
It would be helpful to both see your measurement methodology and the workload
you are using in your tests.
Semi-indirect.
dtrace -n 'fbt:kernel:vm_object_terminate:entry { @traces[stack()] = count(); }'
After some (2-3) seconds
kernel`vnode_destroy_vobject+0xb9
zfs.ko`zfs_freebsd_reclaim+0x2e
kernel`VOP_RECLAIM_APV+0x78
kernel`vgonel+0x134
kernel`vnlru_free+0x362
kernel`vnlru_proc+0x61e
kernel`fork_exit+0x11f
kernel`0x80cdbfde
2490
I don't have user process created threads nor do fork/exit.
___
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: ZFS txg implementation flaw
On Mon, Oct 28, 2013 at 02:38:30PM -0700, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/28/13 14:32, Slawa Olhovchenkov wrote:
On Mon, Oct 28, 2013 at 02:22:16PM -0700, Jordan Hubbard wrote:
On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov s...@zxy.spb.ru
wrote:
As I see ZFS cretate seperate thread for earch txg writing.
Also for writing to L2ARC. As result -- up to several thousands
threads created and destoyed per second. And hundreds thousands
page allocations, zeroing, maping unmaping and freeing per
seconds. Very high overhead.
How are you measuring the number of threads being created /
destroyed? This claim seems erroneous given how the ZFS thread
pool mechanism actually works (and yes, there are thread pools
already).
It would be helpful to both see your measurement methodology and
the workload you are using in your tests.
Semi-indirect. dtrace -n 'fbt:kernel:vm_object_terminate:entry {
@traces[stack()] = count(); }'
After some (2-3) seconds
kernel`vnode_destroy_vobject+0xb9 zfs.ko`zfs_freebsd_reclaim+0x2e
kernel`VOP_RECLAIM_APV+0x78 kernel`vgonel+0x134
kernel`vnlru_free+0x362 kernel`vnlru_proc+0x61e
kernel`fork_exit+0x11f kernel`0x80cdbfde 2490
0x80cdbfd0 fork_trampoline: mov%r12,%rdi
0x80cdbfd3 fork_trampoline+3: mov%rbx,%rsi
0x80cdbfd6 fork_trampoline+6: mov%rsp,%rdx
0x80cdbfd9 fork_trampoline+9: callq 0x808db560 fork_exit
0x80cdbfde fork_trampoline+14:jmpq 0x80cdca80 doreti
0x80cdbfe3 fork_trampoline+19:nopw 0x0(%rax,%rax,1)
0x80cdbfe9 fork_trampoline+25:nopl 0x0(%rax)
I don't have user process created threads nor do fork/exit.
This has nothing to do with fork/exit but does suggest that you are
running of vnodes. What does sysctl -a | grep vnode say?
kern.maxvnodes: 1095872
kern.minvnodes: 273968
vm.stats.vm.v_vnodepgsout: 0
vm.stats.vm.v_vnodepgsin: 62399
vm.stats.vm.v_vnodeout: 0
vm.stats.vm.v_vnodein: 10680
vfs.freevnodes: 275107
vfs.wantfreevnodes: 273968
vfs.numvnodes: 316321
debug.sizeof.vnode: 504
___
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: ZFS txg implementation flaw
On Mon, Oct 28, 2013 at 02:56:17PM -0700, Xin Li wrote:
Semi-indirect. dtrace -n 'fbt:kernel:vm_object_terminate:entry
{ @traces[stack()] = count(); }'
After some (2-3) seconds
kernel`vnode_destroy_vobject+0xb9
zfs.ko`zfs_freebsd_reclaim+0x2e kernel`VOP_RECLAIM_APV+0x78
kernel`vgonel+0x134 kernel`vnlru_free+0x362
kernel`vnlru_proc+0x61e kernel`fork_exit+0x11f
kernel`0x80cdbfde 2490
0x80cdbfd0 fork_trampoline: mov%r12,%rdi
0x80cdbfd3 fork_trampoline+3: mov%rbx,%rsi
0x80cdbfd6 fork_trampoline+6: mov%rsp,%rdx
0x80cdbfd9 fork_trampoline+9: callq 0x808db560
fork_exit 0x80cdbfde fork_trampoline+14:jmpq
0x80cdca80 doreti 0x80cdbfe3
fork_trampoline+19:nopw 0x0(%rax,%rax,1)
0x80cdbfe9 fork_trampoline+25:nopl 0x0(%rax)
I don't have user process created threads nor do fork/exit.
This has nothing to do with fork/exit but does suggest that you
are running of vnodes. What does sysctl -a | grep vnode say?
kern.maxvnodes: 1095872 kern.minvnodes: 273968
vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 62399
vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodein: 10680
vfs.freevnodes: 275107 vfs.wantfreevnodes: 273968 vfs.numvnodes:
316321 debug.sizeof.vnode: 504
Try setting vfs.wantfreevnodes to 547936 (double it).
Now fork_trampoline was gone, but I still see prcfr (and zfod/totfr
too). Currently half of peeak traffic and I can't check impact to IRQ
handling.
kern.maxvnodes: 1095872
kern.minvnodes: 547936
vm.stats.vm.v_vnodepgsout: 0
vm.stats.vm.v_vnodepgsin: 63134
vm.stats.vm.v_vnodeout: 0
vm.stats.vm.v_vnodein: 10836
vfs.freevnodes: 481873
vfs.wantfreevnodes: 547936
vfs.numvnodes: 517331
debug.sizeof.vnode: 504
Now dtrace -n 'fbt:kernel:vm_object_terminate:entry { @traces[stack()] =
count(); }'
kernel`vm_object_deallocate+0x520
kernel`vm_map_entry_deallocate+0x4c
kernel`vm_map_process_deferred+0x3d
kernel`sys_munmap+0x16c
kernel`amd64_syscall+0x5ea
kernel`0x80cdbd97
56
I think this is nginx memory management (allocation|dealocation). Can
I tune malloc to disable free pages?
___
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: High Network Perfomance
On Thu, Aug 04, 2011 at 08:39:17PM -0300, Victor Detoni wrote: Hi Guys, I'm trying tunning a FreeBSD 8.2 to high perfomance network with pf. My server configuration is: Dell 1950 CPU: Intel(R) Xeon(R) CPU5130 @ 2.00GHz (1995.03-MHz K8-class CPU) 4 x CPU 2 NIC (Broadcom NetXtreme II BCM5708 1000Base-T) 1 NIC (em0: Intel(R) PRO/1000 Network Connection 7.1.9) I want to reach the high processing of packets per second and use pf as synproxy and we still processor to handle others packets or flows. I know that em drivers has MULTI_QUEUE implementation that helps high performance for Intel drivers, but I couldn't see more information about. We can reached 500k pps, but no more traffic was processed by this interface. I've already enabled net.isr.direct but with Intel Drivers does not work and the most processors are in System instead of Interrupts, why? When I enable net.isr.direct the processing is balanced for on CPU in system and another in interrupt and I reached 1M pps, but the total perfomance is down, the load grow up too fast. I've changed some parameter in sysctl for intel drivers, but it doesn't have effect. Someone know what I can do to reach more packets performance? I want to use this FreeBSD as a router/firewall only. FreeBSD (and em) need some tuning for high perfomance. Next links in russian, sorry. http://dadv.livejournal.com/138951.html http://dadv.livejournal.com/139170.html http://dadv.livejournal.com/139366.html -- Slawa Olhovchenkov ___ 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
ftpd reset restart position (REST) at any command
I try using mirror 2.9 (old, very old perl script) to mirror ftp site
in passive mode and see don't working restart transfer: server ignored
'REST pos' command.
This because in ftpcmd.y cleared restart_point:
cmd_list
: /* empty */
| cmd_list cmd
{
if (fromname)
free(fromname);
fromname = NULL;
restart_point = 0;
}
| cmd_list rcmd
;
(cmd is any command execept RNFR and REST) and mirror in passive mode
used next command sequence:
REST pos
PASV
RETR file
RFC 3659 allow this, but not recomeded:
The server-PI may react to a badly positioned REST command by
save the restart value and apply it to the next data transfer command
...
Why this case (save the restart value) is bad choice?
___
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: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 03:45:48PM +0400, Lev Serebryakov wrote: Hello, Lev. You wrote 21 августа 2012 г., 15:40:35: GC Try reverting r239356 -- if that works, then please let jhb@ know. LS I'm confused by this commit, because it seems (from comment alone), LS that dhclient will not work without devd anymore (with synchronous LS dhcp option in rc.conf). LS Am I right? Also, I don't like idea of removing IP address from interface when cable is unplugged. It was very disturbing behavior of Windows machines for years. I've unplug cable to change switch port for only a second and all connections are broken, even if one second later dhcpclient receive SAME lease! I don't like this. FreeBSD was very tolerant to unplugging cable for eons, and I (and not only me) like it. If I understand this change properly, it is no more the case :( Not only cable. Turn on microwave, lost WiFi connection and lost all open ssh session (and other network connection). ___ 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: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 09:40:27PM +0400, Lev Serebryakov wrote: Hello, Ian. You wrote 21 августа 2012 г., 21:36:30: IL Perhaps the right solution is to add a dhclient command line option to IL operate in the historical buggy mode: it doesn't exit on link status IL changes, and fails to work properly if those link status changes are IL happening because the physical connection has moved to another network. Right solution was spoken by jhb@ already: dhclient should re-request lease on interface down/up cycle. There is no need to exit and be started again in any case. It will work ``as expected'' without any options for everybody. Not re-request lease, simple renew. ___ 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: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 10:18:15PM +0400, Lev Serebryakov wrote: SO Not re-request lease, simple renew. Sorry, I'm not very strong in exact terms here. dhcp client can sent different requests: DHCPDISCOVER from 0.0.0.0 to 255.255.255.255 DHCPREQUEST from 0.0.0.0 to SERVER_IP (from DHCPOFFER) or DHCPRELEASE DHCPDISCOVER from 0.0.0.0 to 255.255.255.255 DHCPREQUEST from 0.0.0.0 to SERVER_IP or DHCPREQUEST from 0.0.0.0 to 255.255.255.255 or DHCPREQUEST from IP to SERVER_IP and DHCPINFORM for quering additional parametrs after boot, w/o change IP (for example IE request information about proxy auto config) renew address at lease_time/2 usually DHCPREQUEST from IP to SERVER_IP. ___ 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: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 01:56:11PM -0600, Warner Losh wrote: On Aug 21, 2012, at 6:46 AM, Slawa Olhovchenkov wrote: On Tue, Aug 21, 2012 at 03:45:48PM +0400, Lev Serebryakov wrote: Hello, Lev. You wrote 21 августа 2012 г., 15:40:35: GC Try reverting r239356 -- if that works, then please let jhb@ know. LS I'm confused by this commit, because it seems (from comment alone), LS that dhclient will not work without devd anymore (with synchronous LS dhcp option in rc.conf). LS Am I right? Also, I don't like idea of removing IP address from interface when cable is unplugged. It was very disturbing behavior of Windows machines for years. I've unplug cable to change switch port for only a second and all connections are broken, even if one second later dhcpclient receive SAME lease! I don't like this. FreeBSD was very tolerant to unplugging cable for eons, and I (and not only me) like it. If I understand this change properly, it is no more the case :( Not only cable. Turn on microwave, lost WiFi connection and lost all open ssh session (and other network connection). mosh helps. No. Not all remote host allow to install mosh. Cisco routers, for example, don't allow to install mosh. ___ 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: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Wed, Aug 22, 2012 at 02:36:23AM +0400, Lev Serebryakov wrote: Hello, Ian. You wrote 22 августа 2012 г., 1:38:04: IL For example, this script can replace devd as a daemon that restarts IL dhclient when any link comes back up... IL Of course the right thing to do is invoke the proper rc scripts rather IL than dhclient directly... this is just to illustrate how easy it is to IL replace devd if your needs are specialized. [sigh] Everything worked with 8.x without problems. It worked with 9.x and -CURRENT with adding of ``synchronous_dhclient=YES'' into /etc/rc.conf (And it cost me about 2 hours of investigation, why dhclient stops to start after upgrade). Next I'll need to write some script. Is it Ok to you? Yes, I understand problem with laptops, which change wire and wireless networks and need to re-acquire new address. But it should be soleved other way. And jhb@ already posted proper solution, BTW! And, as side note, ``man rc.cof'' says NOTHING about relation of devd and ``synchronous_dhclient'' setting! It says about ``start dhclient(8) synchronously at startup'' without explaining, that without this option and with devd disabled, dhclient WILL NOT START AT ALL! And relations between devd and dhclient are not documented at all in: rc.conf(5), dhclient(8), devd.conf(5) and devd(8). Time ago synchronous_dhclient is waiting for obtain IP by dhcpclient. w/o synchronous_dhclient and ifconfig_bge0=DHCP dhcpclient run in background and don't paused boot while obtaining IP address. On perinterface basis: ifconfig_bge0=SYNCDHCP or ifconfig_bge0=NOSYNCDHCP Background start of dhcpclient currently by devd, on UP event on ethernet interface. This introduction in 6.2. 2006-08-22. ___ 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: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tue, Aug 21, 2012 at 05:25:23PM -0400, John Baldwin wrote:
On Tuesday, August 21, 2012 9:34:31 am John Baldwin wrote:
On Tuesday, August 21, 2012 7:53:08 am Lev Serebryakov wrote:
Hello, Garrett.
You wrote 21 августа 2012 г., 15:40:35:
GC Try reverting r239356 -- if that works, then please let jhb@ know.
LS I'm confused by this commit, because it seems (from comment alone),
LS that dhclient will not work without devd anymore (with synchronous
LS dhcp option in rc.conf).
LS Am I right?
And if I'm right about understanding what this change does, it is
POLA violation for sure. Both consequences: unable to use dhcclient
without devd (user will need to restart it by hands after each cable
unplugging event) and removing IP address from interface on cable
unplugging or other interface down event but before lease is expired.
If I'm right in understanding this commit, I vote to back it out and
find better solution, may be, two new options: one to remove IP and
one to exit on interface down. And default behavior should be OLD
ONE about IP address in any case and OLD ONE about exit in case when
dhclient isn't started by devd, but by rc scripts directly.
Humm. devd is the more common case, and we explicitly don't use devd to
start
dhclient on boot even when devd is enabled (so out of the box dhcp would
first
be started by rc, but would be restarted by devd).
Another option is to rework dhclient to work like it does on OpenBSD where
it
renews its lease if the link bounces, but to not exit when the link goes
down.
That case would fix the currently broken case that you unplug your cable,
take
your laptop over to another network (e.g. take it home if suspend/resume
works), then plug it back in and are still stuck with your old IP.
Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient.
I tested that it survives the following:
- Unplugging/replugging does not kill an existing ssh session
- Using ifconfig down/up does not kill an existing ssh session
- Plugging into a different network does cause dhclient to negotiate
a new lease on the new network
Assign address on interface manualy cause exiting dhcpclient?
I've removed the bits to clear the old configuration if dhclient exits due to
'ifconfig down', and dhclient no longer exits on link down, but instead tracks
the link state and enters the 'reboot' state when the link goes up.
Index: dhcpd.h
===
--- dhcpd.h (revision 239498)
+++ dhcpd.h (working copy)
@@ -208,6 +208,7 @@
int errors;
int dead;
u_int16_tindex;
+ int linkstat;
};
struct timeout {
Index: dhclient.c
===
--- dhclient.c(revision 239498)
+++ dhclient.c(working copy)
@@ -218,6 +218,7 @@
struct sockaddr *sa;
struct iaddr a;
ssize_t n;
+ int linkstat;
n = read(routefd, msg, sizeof(msg));
rtm = (struct rt_msghdr *)msg;
@@ -278,10 +279,14 @@
ifi-name);
goto die;
}
- if (!interface_link_status(ifi-name)) {
- warning(Interface %s is down, dhclient exiting,
- ifi-name);
- goto die;
+ linkstat = interface_link_status(ifi-name);
+ if (linkstat != ifi-linkstat) {
+ debug(%s link state %s - %s, ifi-name,
+ ifi-linkstat ? up : down,
+ linkstat ? up : down);
+ ifi-linkstat = linkstat;
+ if (linkstat)
+ state_reboot(ifi);
}
break;
case RTM_IFANNOUNCE:
@@ -321,8 +326,6 @@
die:
script_init(FAIL, NULL);
- if (ifi-client-active)
- script_write_params(old_, ifi-client-active);
if (ifi-client-alias)
script_write_params(alias_, ifi-client-alias);
script_go();
@@ -437,6 +440,7 @@
}
fprintf(stderr, got link\n);
}
+ ifi-linkstat = 1;
if ((nullfd = open(_PATH_DEVNULL, O_RDWR, 0)) == -1)
error(cannot open %s: %m, _PATH_DEVNULL);
--
John Baldwin
___
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
___
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: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Wed, Aug 22, 2012 at 08:43:52AM -0400, John Baldwin wrote: On Tuesday, August 21, 2012 7:16:30 pm Slawa Olhovchenkov wrote: On Tue, Aug 21, 2012 at 05:25:23PM -0400, John Baldwin wrote: On Tuesday, August 21, 2012 9:34:31 am John Baldwin wrote: On Tuesday, August 21, 2012 7:53:08 am Lev Serebryakov wrote: Hello, Garrett. You wrote 21 августа 2012 г., 15:40:35: GC Try reverting r239356 -- if that works, then please let jhb@ know. LS I'm confused by this commit, because it seems (from comment alone), LS that dhclient will not work without devd anymore (with synchronous LS dhcp option in rc.conf). LS Am I right? And if I'm right about understanding what this change does, it is POLA violation for sure. Both consequences: unable to use dhcclient without devd (user will need to restart it by hands after each cable unplugging event) and removing IP address from interface on cable unplugging or other interface down event but before lease is expired. If I'm right in understanding this commit, I vote to back it out and find better solution, may be, two new options: one to remove IP and one to exit on interface down. And default behavior should be OLD ONE about IP address in any case and OLD ONE about exit in case when dhclient isn't started by devd, but by rc scripts directly. Humm. devd is the more common case, and we explicitly don't use devd to start dhclient on boot even when devd is enabled (so out of the box dhcp would first be started by rc, but would be restarted by devd). Another option is to rework dhclient to work like it does on OpenBSD where it renews its lease if the link bounces, but to not exit when the link goes down. That case would fix the currently broken case that you unplug your cable, take your laptop over to another network (e.g. take it home if suspend/resume works), then plug it back in and are still stuck with your old IP. Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient. I tested that it survives the following: - Unplugging/replugging does not kill an existing ssh session - Using ifconfig down/up does not kill an existing ssh session - Plugging into a different network does cause dhclient to negotiate a new lease on the new network Assign address on interface manualy cause exiting dhcpclient? Hmm, it does. Is that by design? That seems to be the old behavior of the client from my reading of the code as well. I am don't know, but this is comfortable. It is not desirable lost this behavior. ___ 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: datapoints on 10G throughput with TCP ?
On Mon, Dec 05, 2011 at 08:27:03PM +0100, Luigi Rizzo wrote: Hi, I am trying to establish the baseline performance for 10G throughput over TCP, and would like to collect some data points. As a testing program i am using nuttcp from ports (as good as anything, i guess -- it is reasonably flexible, and if you use it in TCP with relatively large writes, the overhead for syscalls and gettimeofday() shouldn't kill you). I'd be very grateful if you could do the following test: - have two machines connected by a 10G link - on one run nuttcp -S - on the other one run nuttcp -t -T 5 -w 128 -v the.other.ip and send me a dump of the output, such as the one(s) at the end of the message. I am mostly interested in two configurations: - one over loopback, which should tell how fast is the CPU+memory As an example, one of my machines does about 15 Gbit/s, and one of the faster ones does about 44 Gbit/s - one over the wire using 1500 byte mss. Here it really matters how good is the handling of small MTUs. As a data point, on my machines i get 2..3.5 Gbit/s on the slow machine with a 1500 byte mtu and default card setting. Clearing the interrupt mitigation register (so no mitigation) brings the rate to 5-6 Gbit/s. Same hardware with linux does about 8 Gbit/s. HEAD seems 10-20% slower than RELENG_8 though i am not sure who is at fault. The receive side is particularly critical - on FreeBSD the receiver is woken up every two packets (do the math below, between the number of rx calls and throughput and mss), resulting in almost 200K activations per second, and despite the fact that interrupt mitigation is set to a much lower value (so incoming packets should be batched). On linux, i see much fewer reads, presumably the process is woken up only at the end of a burst. About relative performance FreeBSD and Linux I wrote in -performance@ at Jan'11 (Interrupt performance) EXAMPLES OF OUTPUT -- nuttcp -t -T 5 -w 128 -v 10.0.1.2 nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - 10.0.1.2 nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 10.0.1.2 with mss=1460, RTT=0.103 ms nuttcp-t: send window size = 131400, receive window size = 65700 nuttcp-t: 3095.0982 MB in 5.00 real seconds = 633785.85 KB/sec = 5191.9737 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 49522 I/O calls, msec/call = 0.10, calls/sec = 9902.99 nuttcp-t: 0.0user 2.7sys 0:05real 54% 100i+2639d 752maxrss 0+3pf 258876+6csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 10.0.1.4 nuttcp-r: send window size = 33580, receive window size = 131400 nuttcp-r: 3095.0982 MB in 5.17 real seconds = 613526.42 KB/sec = 5026.0084 Mbps nuttcp-r: 1114794 I/O calls, msec/call = 0.00, calls/sec = 215801.03 nuttcp-r: 0.1user 3.5sys 0:05real 69% 112i+1104d 626maxrss 0+15pf 507653+188csw nuttcp -t -T 5 -w 128 -v localhost nuttcp-t: v6.1.2: socket nuttcp-t: buflen=65536, nstream=1, port=5001 tcp - localhost nuttcp-t: time limit = 5.00 seconds nuttcp-t: connect to 127.0.0.1 with mss=14336, RTT=0.051 ms nuttcp-t: send window size = 143360, receive window size = 71680 nuttcp-t: 26963.4375 MB in 5.00 real seconds = 5521440.59 KB/sec = 45231.6413 Mbps nuttcp-t: host-retrans = 0 nuttcp-t: 431415 I/O calls, msec/call = 0.01, calls/sec = 86272.51 nuttcp-t: 0.0user 4.6sys 0:05real 93% 102i+2681d 774maxrss 0+3pf 2510+1csw nuttcp-r: v6.1.2: socket nuttcp-r: buflen=65536, nstream=1, port=5001 tcp nuttcp-r: accept from 127.0.0.1 nuttcp-r: send window size = 43008, receive window size = 143360 nuttcp-r: 26963.4375 MB in 5.20 real seconds = 5313135.74 KB/sec = 43525.2080 Mbps nuttcp-r: 767807 I/O calls, msec/call = 0.01, calls/sec = 147750.09 nuttcp-r: 0.1user 3.9sys 0:05real 79% 98i+2570d 772maxrss 0+16pf 311014+8csw on the server, run ___ 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 ___ 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: [RFT] Major snd_hda rewrite
On Wed, Jan 11, 2012 at 09:33:17PM +0200, Alexander Motin wrote: I would like request for testing of my work on further HDA sound driver improvement. Can you add (or document, if exist) functionality of recording audio playing? ___ 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: [CFT] modular kernel config
On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf Where SCSI disk/etc? ___ 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: [CFT] modular kernel config
On Fri, Mar 02, 2012 at 10:09:24AM +0100, Alexander Leidinger wrote: Quoting Slawa Olhovchenkov s...@zxy.spb.ru (from Thu, 1 Mar 2012 18:58:34 +0400): On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf Where SCSI disk/etc? CAM and ATA are loaded as modules in the loader.conf (except for two SCSI controllers, which are not available as modules). I may have missed to load a module, or I may not load in the correct order (which would be a bug of missing/wrong dependencies in some modules). I'm investigating a corresponding report with error messages. Not controllers, peripherals: disk/tape/etc device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) device ses # SCSI Environmental Services (and SAF-TE) ___ 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: [patch] iwi(4) suspend/resume broken
On Wed, Mar 14, 2012 at 09:46:56AM +0900, Mitsuru IWASAKI wrote: Hi, I've noticed that iwi(4) doesn't have ieee80211_new_state(IEEE80211_S_INIT) in iwi_stop_locked() since 8.0-RELEASE (comparing with RELENG_7's). It seems that this prevent if_iwi from working properly after resuming, no data frames were sent. The patches is available at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120314.diff Now that iwi(4) is working well for me :) I'll commit this coming weekend if there are no objections. ath(4) also don't work witch suspend/resume. and ath(4) dpn't work after resume even if kldunload before suspend (kldload don't work). ___ 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: rctl limit cpu
On Wed, Jul 27, 2011 at 09:32:49PM +0200, Edward Tomasz Napiera?a wrote: Wiadomo?? napisana przez Alexander Pyhalov w dniu 26 lip 2011, o godz. 15:32: Hello. I see in rctl man page, that I can limit cpu time in milliseconds, e.g., for jail. But I can't deny allocation of the resource (according to man page). In Solaris I can assign different amount of cpu shares to different projects. How can I achieve this with rctl? For example, I'd like to give jail:www 40% CPU, jail:db - 50% CPU and leave 10% to the base system... The cputime resource (it got renamed shortly before the code freeze to match resource names in login.conf(5)) defines amount of CPU time used, not the percentage. That's why you cannot deny it - if you could, it would just make the offending process (jail, login class, user) hang indefinitely. The %CPU limit is not implemented yet. I plan to do this before sometime after 9.0 is out. Any progress yet? ___ 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: Some performance measurements on the FreeBSD network stack
On Thu, Apr 19, 2012 at 03:30:18PM +0200, Luigi Rizzo wrote: I have been running some performance tests on UDP sockets, using the netsend program in tools/tools/netrate/netsend and instrumenting the source code and the kernel do return in various points of the path. Here are some results which I hope you find interesting. I do some test in 2011. May be this test is not actual now. May be actual. Initial message http://lists.freebsd.org/pipermail/freebsd-performance/2011-January/004156.html UDP socket in FreeBSD http://lists.freebsd.org/pipermail/freebsd-performance/2011-February/004176.html About 4BSD/ULE http://lists.freebsd.org/pipermail/freebsd-performance/2011-February/004181.html ___ 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
pmap and mtx scalability problem
I treid make -j 30 build{world,kernel} (latest -CURRENT) on 24-core machine and
see poor
scalability of pmap/mtx -- more then 50% cpu spend on system time.
pmcstat:
@ CPU_CLK_UNHALTED_CORE [194841 samples]
42.65% [83102]_mtx_lock_sleep @ /boot/kernel/kernel
40.97% [34051] pmap_enter
100.0% [34051] vm_fault_hold
100.0% [34051] trap_pfault
30.40% [25262] vm_page_activate
100.0% [25262] vm_fault_hold
100.0% [25262] trap_pfault
18.41% [15300] vm_pageq_remove
73.63% [11266] vm_page_free_toq
70.69% [7964]vm_object_terminate
29.31% [3302]vm_object_page_remove
26.37% [4034] vm_fault_hold
100.0% [4034]trap_pfault
make -j 8:
15.44% [10740]_mtx_lock_sleep @ /boot/kernel/kernel
38.77% [4164] pmap_enter
99.93% [4161] vm_fault_hold
100.0% [4161]trap_pfault
00.07% [3] kmem_back
100.0% [3] kmem_malloc
27.98% [3005] vm_page_activate
100.0% [3005] vm_fault_hold
100.0% [3005]trap_pfault
20.64% [2217] vm_pageq_remove
64.73% [1435] vm_page_free_toq
63.41% [910] vm_object_terminate
make -j 4
06.86% [4222] pagezero @ /boot/kernel/kernel
98.39% [4154] trap_pfault
100.0% [4154] trap
01.11% [47]vm_fault_hold
___
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: pmap and mtx scalability problem
On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote: Known problem. There is an open disagreement about how to improve the granularity of locking in pmap. split locking to process-specific information and global information? use lock-free lists (i see TAILQ_INSERT_TAIL in pmap_enter)? sorry for stupidity, if any. ___ 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: pmap and mtx scalability problem
On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote: No. I developed a patch from Jeffr that pushed the vm_page_lock array down in to the machine dependent code, replacing most of the uses of the single vm_page_queue_lock. However, alc doesn't like the design and has not proposed an alternative. can i test this? -Kip On Tue, Apr 24, 2012 at 10:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote: Known problem. There is an open disagreement about how to improve the granularity of locking in pmap. split locking to process-specific information and global information? use lock-free lists (i see TAILQ_INSERT_TAIL in pmap_enter)? sorry for stupidity, if any. -- ?The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don?t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won?t take measure of their own strength, for fear of antagonizing their own weakness. Those who don?t like to make waves?or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It?s the reductionist approach to life: if you keep it small, you?ll keep it under control. If you don?t make any noise, the bogeyman won?t find you. But it?s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.? Sophie Scholl ___ 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: Some performance measurements on the FreeBSD network stack
On Wed, Apr 25, 2012 at 01:22:06PM +0400, Maxim Konovalov wrote: Hi, On Tue, 24 Apr 2012, 17:40-, Li, Qing wrote: Yup, all good points. In fact we have considered all of these while doing the work. In case you haven't seen it already, we did write about these issues in our paper and how we tried to address those, flow-table was one of the solutions. http://dl.acm.org/citation.cfm?id=1592641 Is this article available for those without ACM subscription? Tip: get citation from abstract to google. 3'th link: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf ___ 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: [PATCH] Add rusage reporting to procstat
On Mon, Jan 14, 2013 at 04:39:17PM -0500, John Baldwin wrote: This patch adds a new -r flag to dump the resource usage information (what you would get from getrusage() or wait()) for a given process. Sample output: % procstat -r $$ PID COMM TYPE VALUE 1428 tcsh user time 00:00:00.050182 1428 tcsh system time 00:00:00.040145 1428 tcsh maximum RSS 3328 B maximum RSS -- 3328 _bytes_? You kidding. 1428 tcsh integral shared memory 2844 B 1428 tcsh integral unshared data 6372 B 1428 tcsh integral unshared stack 1152 B 1428 tcsh page reclaims1306 1428 tcsh page faults12 1428 tcsh swaps 0 1428 tcsh block reads50 1428 tcsh block writes0 1428 tcsh messages sent 172 1428 tcsh messages received 0 1428 tcsh signals received 33 1428 tcsh voluntary context switches 1167 1428 tcsh involuntary context switches1 http://www.FreeBSD.org/~jhb/patches/procstat_rusage.patch Any thoughts, etc.? -- John Baldwin ___ 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 ___ 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: [PATCH] Add rusage reporting to procstat
On Tue, Jan 15, 2013 at 01:49:01PM +, David Chisnall wrote: On 15 Jan 2013, at 13:47, Slawa Olhovchenkov wrote: maximum RSS -- 3328 _bytes_? You kidding. I think this is a bug in our getrusage. I've seen similar (4KB) things in a program that mmap()s 12KB of input, allocates a load of heap memory for metadata, uses a bunch of stack, and then exits. I find it is quite odd that the figure isn't a multiple of the page size, because the resident set can't be anything other than an integer number of pages.. man getrusage ru_maxrssthe maximum resident set size utilized (in kilobytes). Dimensions of the other fields may be also wrong. ___ 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
FreeBSD-10.0-CURRENT-i386-20130108-r245175-release.iso trapped at rm -r
Fresh install FreeBSD-10.0-CURRENT-i386-20130108-r245175-release.iso in virtualbox 4.2 (Host -- FreeBSD-9 amd64). After install run in headless mode, login by ssh. mount -u -o async / rm -r /usr/port Got trap http://zxy.spb.ru/trap.png ___ 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: acpi resume related patch
On Fri, Jan 25, 2013 at 10:43:33AM +0200, Andriy Gapon wrote: If you have ACPI suspend/resume working, if it used to work but stopped working at some time, if it never worked, but you are still hoping, could you please test the following patch and report back? http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch I have ACPI suspend/resume working but AR9220 never resume from sleep. ___ 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: ipfilter(4) needs maintainer
On Fri, Apr 12, 2013 at 11:33:30PM -0700, Rui Paulo wrote: It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Realy? pf do FTP nat translation w/o contexst switching? Multiple GRE nat translation? I am use from ipfilter only ipnat. ___ 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: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote: Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! You disallow anonymization? NAT do anonymisation also. ___ 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: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 02:50:23PM +0400, Lev Serebryakov wrote: KP I'm however talking about an ftp client behind a very restrictive KP firewall making an IPv6 connection an ftp server that uses passive KP mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). Not heavy. But error-prone, yes. ___ 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
GEOM (GPART) filtered device tree
I am try to build SAN with iSCSI access based on FreeBSD+ZFS. LUN emulated by ZFS volume. Because partitioned not contrlled and can be dangerous (even threat host OS) I needed to filtered some /dev subtree from GPART (temporary or permanently). How do i do this? ___ 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: [HEADSUP] New pkg-devel 1.1.0 beta1
On Thu, May 30, 2013 at 05:20:54PM +0200, Baptiste Daroussin wrote: The pkg developement team is proud to announce the new 1.1.0 beta1 release of pkg. - new experimental pkg convert (can convert from and to legacy pkg database) pkg2ng now uses pkg convert (still recommanded to use pkg2ng) Converting packages from /var/db/pkg Converting pkg-1.1.0.b3_1... pkg: unknown keyword display, ignoring @display Installing pkg-1.1.0.b3_1...Segmentation fault (core dumped) ___ 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: [HEADSUP] New pkg-devel 1.1.0 beta1
On Mon, Jun 03, 2013 at 05:34:19PM +0200, Baptiste Daroussin wrote: On Mon, Jun 03, 2013 at 07:17:24PM +0400, Slawa Olhovchenkov wrote: On Thu, May 30, 2013 at 05:20:54PM +0200, Baptiste Daroussin wrote: The pkg developement team is proud to announce the new 1.1.0 beta1 release of pkg. - new experimental pkg convert (can convert from and to legacy pkg database) pkg2ng now uses pkg convert (still recommanded to use pkg2ng) Converting packages from /var/db/pkg Converting pkg-1.1.0.b3_1... pkg: unknown keyword display, ignoring @display Installing pkg-1.1.0.b3_1...Segmentation fault (core dumped) ___ 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 Have you run pkg2ng? Yes, this is run pkg2ng. ___ 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: [HEADSUP] New pkg-devel 1.1.0 beta1
On Mon, Jun 03, 2013 at 08:40:31PM +0200, Baptiste Daroussin wrote: On Mon, Jun 03, 2013 at 07:39:03PM +0400, Slawa Olhovchenkov wrote: On Mon, Jun 03, 2013 at 05:34:19PM +0200, Baptiste Daroussin wrote: On Mon, Jun 03, 2013 at 07:17:24PM +0400, Slawa Olhovchenkov wrote: On Thu, May 30, 2013 at 05:20:54PM +0200, Baptiste Daroussin wrote: The pkg developement team is proud to announce the new 1.1.0 beta1 release of pkg. - new experimental pkg convert (can convert from and to legacy pkg database) pkg2ng now uses pkg convert (still recommanded to use pkg2ng) Converting packages from /var/db/pkg Converting pkg-1.1.0.b3_1... pkg: unknown keyword display, ignoring @display Installing pkg-1.1.0.b3_1...Segmentation fault (core dumped) ___ 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 Have you run pkg2ng? Yes, this is run pkg2ng. Ok I'll have a look and fix asap. And for graphics/evince don't recorded dependencies from archivers/unzip (as RUN_DEPENDS in Makefile). ___ 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: [HEADSUP] New pkg-devel 1.1.0 beta1
On Tue, Jun 11, 2013 at 11:52:59AM -0500, Bryan Drewery wrote:
On 6/11/2013 11:51 AM, Slawa Olhovchenkov wrote:
On Mon, Jun 03, 2013 at 08:40:31PM +0200, Baptiste Daroussin wrote:
On Mon, Jun 03, 2013 at 07:39:03PM +0400, Slawa Olhovchenkov wrote:
On Mon, Jun 03, 2013 at 05:34:19PM +0200, Baptiste Daroussin wrote:
On Mon, Jun 03, 2013 at 07:17:24PM +0400, Slawa Olhovchenkov wrote:
On Thu, May 30, 2013 at 05:20:54PM +0200, Baptiste Daroussin wrote:
The pkg developement team is proud to announce the new 1.1.0 beta1
release of
pkg.
- new experimental pkg convert (can convert from and to legacy pkg
database)
pkg2ng now uses pkg convert (still recommanded to use pkg2ng)
Converting packages from /var/db/pkg
Converting pkg-1.1.0.b3_1...
pkg: unknown keyword display, ignoring @display
Installing pkg-1.1.0.b3_1...Segmentation fault (core dumped)
___
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
Have you run pkg2ng?
Yes, this is run pkg2ng.
Ok I'll have a look and fix asap.
And for graphics/evince don't recorded dependencies from
archivers/unzip (as RUN_DEPENDS in Makefile).
This is possibly expected because unzip is in base. The archivers/unzip
package is not installed. The port is not depending on
LOCALBAES/bin/unzip so it doesn't pull in the archivers/unzip port, it
just uses the base version.
It's not a pkg problem.
Whose problem is it? Where addressed PR?
In ports Makefile for graphics/evince
.if ${PORT_OPTIONS:MCOMICS}
RUN_DEPENDS+= unzip:${PORTSDIR}/archivers/unzip
CONFIGURE_ARGS+=--enable-comics
GCONF_SCHEMAS+= evince-thumbnailer-comics.schemas
PLIST_SUB+= COMICS=
.else
CONFIGURE_ARGS+=--disable-comics
PLIST_SUB+= COMICS=@comment
.endif
poudriere check dependencies changing by comparing 'make
run-depends-list' and recorded dependices from existing package. In
run-depends-list archivers/unzip prsent, in package -- absent.
As result on every run 'poudriere bulk' package graphics/evince
removed (new dependency: archivers/unzip) and rebuilding. And
depended from evince packages too.
This is problem of evince port or port infrastructure?
Or may be we need 'soft' (optional) dependencies -- installed if some
files missing? (for example -- system build w/o bzip2, package
installed bzip2, for usual system -- do nothing).
___
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: [rfc] bind per-cpu timeout threads to each CPU
On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: On 19.02.2014 22:04, Adrian Chadd wrote: On 19 February 2014 11:59, Alexander Motin m...@freebsd.org wrote: So if we're moving towards supporting (among others) a pcbgroup / RSS hash style work load distribution across CPUs to minimise per-connection lock contention, we really don't want the scheduler to decide it can schedule things on other CPUs under enough pressure. That'll just make things worse. True, though it is also not obvious that putting second thread on CPU run queue is better then executing it right now on another core. Well, it depends if you're trying to optimise for run all runnable tasks as quickly as possible or run all runnable tasks in contexts that minimise lock contention. The former sounds great as long as there's no real lock contention going on. But as you add more chances for contention (something like 100,000 concurrent TCP flows) then you may end up having your TCP timer firing stuff interfere with more TXing or RXing on the same connection. 100K TCP flows probably means 100K locks. That means that chance of lock collision on each of them is effectively zero. More realistic it could What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP timeouts callbacks? ___ 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: [rfc] bind per-cpu timeout threads to each CPU
On Thu, Feb 20, 2014 at 12:09:04AM +0200, Alexander Motin wrote: On 19.02.2014 23:44, Slawa Olhovchenkov wrote: On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: On 19.02.2014 22:04, Adrian Chadd wrote: On 19 February 2014 11:59, Alexander Motin m...@freebsd.org wrote: So if we're moving towards supporting (among others) a pcbgroup / RSS hash style work load distribution across CPUs to minimise per-connection lock contention, we really don't want the scheduler to decide it can schedule things on other CPUs under enough pressure. That'll just make things worse. True, though it is also not obvious that putting second thread on CPU run queue is better then executing it right now on another core. Well, it depends if you're trying to optimise for run all runnable tasks as quickly as possible or run all runnable tasks in contexts that minimise lock contention. The former sounds great as long as there's no real lock contention going on. But as you add more chances for contention (something like 100,000 concurrent TCP flows) then you may end up having your TCP timer firing stuff interfere with more TXing or RXing on the same connection. 100K TCP flows probably means 100K locks. That means that chance of lock collision on each of them is effectively zero. More realistic it could What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP timeouts callbacks? I am not sure what this formula means, but yes, per-CPU callout locks can much more likely be congested. They are only per-CPU, not per-flow. 100K TCP flows distributed between CPU (100K/N_cpu). every TCP flow several times per seconds touch his callout (*PPS) ___ 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: Import of DragonFly Mail Agent
On Sun, Feb 23, 2014 at 10:11:56PM +0100, Baptiste Daroussin wrote: As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. What's about suid, security separations etc? ___ 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: Import of DragonFly Mail Agent
On Mon, Feb 24, 2014 at 03:30:14PM +0100, Baptiste Daroussin wrote: On Mon, Feb 24, 2014 at 06:17:37PM +0400, Slawa Olhovchenkov wrote: On Sun, Feb 23, 2014 at 10:11:56PM +0100, Baptiste Daroussin wrote: As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. What's about suid, security separations etc? What do you mean? dma is changing user as soon as possible, dma will be capsicumized, what else do you want as informations? sendmail (in the past) have same behaviour (run as root and chage user). This is some security risk. For many scenario change user is not simple (for example -- send file from local user A to local user B, file with permsion 0400). sendmail will be forced to change behaviour -- mailnull suid program for place mail into queue and root daemon for deliver to user. This is more complex. Can be dma avoid this way? ___ 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: libinit idea
On Mon, Feb 24, 2014 at 10:00:57AM -0800, Don Lewis wrote: I forgot to mention that the command line tools are feel cumbersome. To restart a service: FreeBSD: /etc/rc.d/foo restart service foo restart Old Linux: /etc/init.d/foo restart service foo restart Systemd: systemctl restart foo.service seems worse that that when I'm actually typing it ... Would it take seemingly forever? I would like to try systemd in Linux, can't say at this stage whether I'll like it, hate it, or somewhere in between. There's no substitute for firsthand experience. ___ 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 ___ 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: FreeBSD iscsi target
On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: Does freebsd iscsi target supports: 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) 3. Multiple connections per session No; see above. I think this is help for 40G links. ___ 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: FreeBSD iscsi target
On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: Does freebsd iscsi target supports: 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) 3. Multiple connections per session No; see above. I think this is help for 40G links. I assume that you are looking at transfer of large amounts of data over 40G links. Assuming that tis is the case, yes, multiple connections per session Yes, this case. As I know, single transfer over 40G link limited by 10G. ___ 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: FreeBSD iscsi target
On Wed, Jul 02, 2014 at 12:51:59PM -0700, Kevin Oberman wrote: On Wed, Jul 2, 2014 at 4:26 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: Does freebsd iscsi target supports: 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) 3. Multiple connections per session No; see above. I think this is help for 40G links. I assume that you are looking at transfer of large amounts of data over 40G links. Assuming that tis is the case, yes, multiple connections per session Yes, this case. As I know, single transfer over 40G link limited by 10G. ??? No, not at all. Getting 40G performance over TCP is not easy, but there is no 10G limitation. As I know (may be wrong) 40G is bundled 4x10G link. For prevent packet reordering (when run over diferrent link) all packets from one sessoin must be routed to same link. Same issuse for Etherchannel. ___ 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: FreeBSD iscsi target
On Thu, Jul 03, 2014 at 09:31:45AM +0100, Nikolay Denev wrote: On Thu, Jul 3, 2014 at 12:06 AM, Kevin Oberman rkober...@gmail.com wrote: On Wed, Jul 2, 2014 at 1:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Wed, Jul 02, 2014 at 12:51:59PM -0700, Kevin Oberman wrote: On Wed, Jul 2, 2014 at 4:26 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: Does freebsd iscsi target supports: 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) 3. Multiple connections per session No; see above. I think this is help for 40G links. I assume that you are looking at transfer of large amounts of data over 40G links. Assuming that tis is the case, yes, multiple connections per session Yes, this case. As I know, single transfer over 40G link limited by 10G. ??? No, not at all. Getting 40G performance over TCP is not easy, but there is no 10G limitation. As I know (may be wrong) 40G is bundled 4x10G link. For prevent packet reordering (when run over diferrent link) all packets from one sessoin must be routed to same link. Same issuse for Etherchannel. No, 40G Ethernet is single channel from the interface perspective.. What my be confusing you is that they may use lanes which, for 40G, are 10.3125G. But, unlike the case with Etherchannel, these lanes are hidden from the MAC. The interface deals with a single stream and parcels it out over the 10G (or 25G) lanes. All 100G optical links use multiple lanes (4x25G or 10x10G), but 40G my use either a single 40G lane for distances of up to 2km or 4x10G for longer runs. Since, in most cases, 40G is used within a data center or to connect to wave gear for DWDM transmission over very long distances, most runs are under 2km, so a single 40G lane may be used. When 4 lanes are used, a ribbon cable is required to assure that all optical or copper paths are exactly the same length. Since the PMD is designed to know about and use these lanes for a single channel, the issue of packet re-ordering is not present and the protocol layers above the physical are unaware of how many lanes are used. Wikipedia has a fairly good discussion under the unfortunate title of 100 Gigabit Ethernet https://en.wikipedia.org/wiki/100_Gigabit_Ethernet. Regardless of the title, the article covers both 40 and 100 Gigabit specifications as both were specified on the same standard, 802.3ba. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@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 I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. ___ 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: FreeBSD iscsi target
On Thu, Jul 03, 2014 at 10:35:55AM +0100, Nikolay Denev wrote: I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. Interesting, however this seems like implementation specific detail, and not limitation of native 40Gbit ethernet. I see some perfomance tests on solaris and 40G link. In this test perfomance limited about 10Gbit per flow. May be I found links to this test. May be some NIC's implementation specific detail also limited performance per flow. Still, it's something that one must be aware of (esp when dealing with Cisco gear :) ) I wonder why they are not doing something like this : http://blog.ipspace.net/2011/04/brocade-vcs-fabric-has-almost-perfect.html --Nikolay ___ 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: FreeBSD iscsi target
On Thu, Jul 03, 2014 at 10:28:19AM -0700, Adrian Chadd wrote: Which NIC? I am can't find again this forum posts (last time I find -- year ago). May be this http://hardforum.com/showthread.php?t=1662769 In this case -- Mellanox QDR ConnectX2 Infiniband. On 3 July 2014 03:29, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Jul 03, 2014 at 10:35:55AM +0100, Nikolay Denev wrote: I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. Interesting, however this seems like implementation specific detail, and not limitation of native 40Gbit ethernet. I see some perfomance tests on solaris and 40G link. In this test perfomance limited about 10Gbit per flow. May be I found links to this test. May be some NIC's implementation specific detail also limited performance per flow. Still, it's something that one must be aware of (esp when dealing with Cisco gear :) ) I wonder why they are not doing something like this : http://blog.ipspace.net/2011/04/brocade-vcs-fabric-has-almost-perfect.html --Nikolay ___ 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 ___ 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: FreeBSD iscsi target
On Thu, Jul 03, 2014 at 08:39:42PM -0700, Kevin Oberman wrote: In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. Yep. It is really crappy LAGG (fixed three-tupple hash... yuck!) and is really nothing but 4 10G Ethernet ports using a 40G PHY in yhe 4x10G form. Note that they don't make any claim of 802.3ba compliance. It only states that 40 Gigabit Ethernet is now part of the IEEE 802.3ba standard. So it is, but this device almost certainly predates the completion of the standard to get a product for which there was great demand. It's a data center product and for typical cases of large numbers of small flow, it should do the trick. Probably does not interoperate with true 80-2.3ba hardware, either. My boss at the time I retired last November was on the committee that wrote 802.3ba. He would be a good authority on whether the standard has any vague wording that would allow this, but he retired 5 month after I did and I have no contact information for him. But I'm pretty sure that there is no way that this is legitimate 40G Ethernet. 802.3ba describe only end point of ethernet. ASIC, internal details of implemetations NICs, switches, fabrics -- out of standart scope. Bottleneck can be in any point of packet flow. In first pappers of netmap test demonstarated NIC can't do saturation of 10G in one stream 64 bytes packet -- need use multiple rings for transmit. I think need use general rule: one flow transfer can hit performance limitation. ___ 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: FreeBSD iscsi target
On Fri, Jul 04, 2014 at 12:25:35PM +0200, Luigi Rizzo wrote: On Fri, Jul 4, 2014 at 12:16 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Jul 03, 2014 at 08:39:42PM -0700, Kevin Oberman wrote: In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. Yep. It is really crappy LAGG (fixed three-tupple hash... yuck!) and is really nothing but 4 10G Ethernet ports using a 40G PHY in yhe 4x10G form. Note that they don't make any claim of 802.3ba compliance. It only states that 40 Gigabit Ethernet is now part of the IEEE 802.3ba standard. So it is, but this device almost certainly predates the completion of the standard to get a product for which there was great demand. It's a data center product and for typical cases of large numbers of small flow, it should do the trick. Probably does not interoperate with true 80-2.3ba hardware, either. My boss at the time I retired last November was on the committee that wrote 802.3ba. He would be a good authority on whether the standard has any vague wording that would allow this, but he retired 5 month after I did and I have no contact information for him. But I'm pretty sure that there is no way that this is legitimate 40G Ethernet. 802.3ba describe only end point of ethernet. ASIC, internal details of implemetations NICs, switches, fabrics -- out of standart scope. Bottleneck can be in any point of packet flow. In first pappers of netmap test demonstarated NIC can't do saturation of 10G in one stream 64 bytes packet -- need use multiple rings for transmit. ?that was actually just a configuration issue which since then has been ?resolved. The 82599 can do 14.88 Mpps on a single ring (and is the only 10G nic i have encountered who can do so). Thanks for clarification. Besides, performance with short packets has nothing to do with the case you were discussing, namely throughput for a single large flow. This is only illustration about hardware limitation. Perforamnce may be not only bandwidth limited, but interrupt/pps (per flow) limited. I think need use general rule: one flow transfer can hit performance limitation. ?This is neither a useful nor it is restricted to a single flow. Everything can underperform depending on the hw/sw configuration, but not necessarily has to. Yes. And estimate to ideal hw/sw configuration and enviroment -- bad think. ___ 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: RFC: Remove pty(4)
On Wed, Aug 20, 2014 at 11:00:14AM -0700, Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened with other drivers. This is mainly because we always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and userspace loops over ptyXX and after it successfully opens it tries to open the other one with the same suffix. So, having a single device is not really enough. My option, instead, is that of removing pty(4), which is nothing more than a compatibility driver, and move pmtx(4) code somewhere else. The main drawback of the removal of this is that it makes impossible to run FreeBSD = 7 jails and SSH into them. I personally don't consider this a huge issue, in light of the fact that FreeBSD-7 has been EOL for a long time, but I would like to hear other people comments. FreeBSD EOL, but still working. # uname -a FreeBSD XXX 5.4-STABLE FreeBSD 5.4-STABLE #3: Fri Mar 29 13:52:44 MSK 2013 slw@:/usr/obj/usr/src/sys/RADIUS i386 And may be exist software for this version, don't exist for modern OS. The code review for the proposed change can be found here: https://reviews.freebsd.org/D659 If I won't get any objection I'll commit this in one week time, i.e. August 27th. Waht about porting software, relaying on /dev/ptyXX and /dev/ttyXX? ___ 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
LOR kernel trap
I am build freebsd-current w/ cvs snap on 2003.11.11
and have some problem:
1. LOR
lock order reversal
1st 0xc1b05690 rtentry (rtentry) @ /usr/src/sys/net/rtsock.c:388
2nd 0xc15e187c radix node head (radix node head) @ /usr/src/sys/net/route.c:1114
Stack backtrace:
backtrace(c06126bc,c15e187c,c061775a,c061775a,c06177b0) at backtrace+0x17
witness_lock(c15e187c,8,c06177b0,45a,1) at witness_lock+0x672
_mtx_lock_flags(c15e187c,0,c06177b0,45a,c1b05690) at _mtx_lock_flags+0xba
rt_setgate(c1b05600,c1ad6440,c1b05b78,185,0) at rt_setgate+0x3b8
route_output(c0e11500,c16fc550,b0,c0e11500,1f50) at route_output+0x6aa
raw_usend(c16fc550,0,c0e11500,0,0) at raw_usend+0x73
rts_send(c16fc550,0,c0e11500,0,0) at rts_send+0x35
sosend(c16fc550,0,c6a8bc7c,c0e11500,0) at sosend+0x44d
soo_write(c1a01c38,c6a8bc7c,c1b74780,0,c1afd000) at soo_write+0x70
dofilewrite(c1afd000,c1a01c38,8,bfbfe870,b0) at dofilewrite+0xf8
write(c1afd000,c6a8bd10,c062c0e1,3ee,3) at write+0x6e
syscall(2f,2f,2f,8,3) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4), eip = 0x28283c2f, esp = 0xbfbfe65c, ebp = 0xbfbfe688 ---
2. kernel trap
cpuid = 0 acic id = 00
ip 0x8:0xc04955ed
sp 0x10:0xc6a8babc
fp 0x10:0xc6a8bac0
code segment base 0 limit f type 0x1b DPL 0 pres 1 def32 1 gran 1
eflags interrupt enabled IOPL = 0
current process 562 (ppp)
kernel: type 30 trap, code = 0
stopet at critical_exit+0x2d: jmp critical_exit+0x36
gdb -k /.1/obj/usr/src/sys/SLW/kernel.debug
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
(kgdb) l *0xc04955ed
0xc04955ed is in critical_exit (machine/cpufunc.h:358).
353 }
354
355 static __inline void
356 write_eflags(u_int ef)
357 {
358 __asm __volatile(pushl %0; popfl : : r (ef));
359 }
360
361 static __inline void
362 wrmsr(u_int msr, u_int64_t newval)
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR kernel trap
I am build freebsd-current w/ cvs snap on 2003.11.11 and have some problem: 2. kernel trap cpuid = 0 acic id = 00 This has been fixed in later snaps. Thanks, I now try 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Fri Nov 21 23:12:09 MSK 2003. This trap seems fixed. And I now see 'kernel: stray irq7' -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
If you want access to fetch early on in this way, you could make a local branch and maintain the change for your own site, or you could boot from a FreeBSD live CD, or use sysinstall from the installation CD to install a package. I don't see fetch as a requirement for diskless clients. Wrong. Not diskless. Simple w/o CD, DVD, FDC. Only HDD. -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
psmintr not attached w/ acpi
If acpi enabled PS/2 mouse failed to work and irq12 cold't attach
to psmintr.
Is this problem reporting PS/2 mouse resource before atkbdc?
psmcpnp0 irq 12 on acpi0
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0047
atkbd: keyboard ID 0x41ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d
psm0: current command byte:0047
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3-00, 3 buttons
psm0: config:, flags:, packet size:4
psm0: syncmask:08, syncbits:08
vmstat -i
interrupt total rate
irq0: clk 64245 99
irq1: atkbd0 1 0
irq8: rtc 82235127
irq11: xl0 uhci0+737 1
irq13: npx01 0
irq14: ata0 2411 3
irq15: ata1 52 0
Total 149682232
Device (PS2M)
{
Name (_HID, EisaId (PNP0F13))
Method (_STA, 0, NotSerialized)
{
If (LEqual (PS2F, 0x00))
{
Return (0x0F)
}
Else
{
Return (0x00)
}
}
Method (_CRS, 0, NotSerialized)
{
Name (BUF1, Buffer (0x05)
{
0x22, 0x00, 0x10, 0x79, 0x00
})
Name (BUF2, Buffer (0x15)
{
0x47, 0x01, 0x60, 0x00, 0x60, 0x00, 0x01, 0x01,
0x47, 0x01, 0x64, 0x00, 0x64, 0x00, 0x01, 0x01,
0x22, 0x00, 0x10, 0x79, 0x00
})
If (LEqual (KBDI, 0x01))
{
Return (BUF2)
}
Else
{
Return (BUF1)
}
}
}
Device (PS2K)
{
Name (_HID, EisaId (PNP0303))
Method (_STA, 0, NotSerialized)
{
If (LEqual (KBDI, 0x01))
{
Return (0x00)
}
Else
{
Return (0x0F)
}
}
Name (_CRS, Buffer (0x15)
{
0x47, 0x01, 0x60, 0x00, 0x60, 0x00, 0x01, 0x01,
0x47, 0x01, 0x64, 0x00, 0x64, 0x00, 0x01, 0x01,
0x22, 0x02, 0x00, 0x79, 0x00
})
}
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: psmintr not attached w/ acpi
On Mon, Dec 01, 2003 at 09:48:40AM -0800, Nate Lawson wrote: Your ASL indicates that it returns different values for present (based on PS2F) and current resources (based on KBDI). Please send me the URL to the full ASL so I can see what sets those two variables. http://zxy.spb.ru/acpi.dump Do you need additional information? -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: psmintr not attached w/ acpi
On Mon, Dec 01, 2003 at 10:59:49AM -0800, Nate Lawson wrote:
On Mon, Dec 01, 2003 at 09:48:40AM -0800, Nate Lawson wrote:
Your ASL indicates that it returns different values for present (based on
PS2F) and current resources (based on KBDI). Please send me the URL to
the full ASL so I can see what sets those two variables.
http://zxy.spb.ru/acpi.dump
Do you need additional information?
Try this workaround, recompile your asl, set dsdt_load in loader.conf.
See acpi(4) if you need info on this process. I think your BIOS needs a
workaround. I wonder if the MS interpreter ignores _STA for some devices.
I try recompile asl and got some errors:
===
iasl acpi.dump
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030619 [Nov 25 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
acpi.dump84: And (SUSF, 0x02, STAT)
Error1037 -^ syntax error
ASL Input: acpi.dump - 3574 lines, 113232 bytes, 12 keywords
Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 9 Optimizations
===
I commented out this line and try again.
===
iasl acpi.dump
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030619 [Nov 25 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
acpi.dump 352: Method (\_WAK, 1, NotSerialized)
Warning 2026 - ^ Reserved method must return a value (_WAK)
acpi.dump 382: Store (Local0, Local0)
Error1013 - ^ Method local variable is not initialized
(Local0)
acpi.dump 387: Store (Local0, Local0)
Error1013 - ^ Method local variable is not initialized
(Local0)
acpi.dump 1609: ICF0, 2,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1610: ICF1, 2,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1612: WPPE, 1,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1614: FAS0, 2,
Error1051 - ^ Access width of Field Unit extends beyond
region limit
acpi.dump 1615: FAS1, 2
Error1051 - ^ Access width of Field Unit extends beyond
region limit
ASL Input: acpi.dump - 3850 lines, 119353 bytes, 1690 keywords
Compilation complete. 7 Errors, 1 Warnings, 0 Remarks, 345 Optimizations
===
What is wrong?
--- slawa-IntelLaptop.asl.origMon Dec 1 10:54:18 2003
+++ slawa-IntelLaptop.asl Mon Dec 1 10:57:39 2003
@@ -3353,14 +3353,7 @@
Name (_HID, EisaId (PNP0F13))
Method (_STA, 0, NotSerialized)
{
-If (LEqual (PS2F, 0x00))
-{
Return (0x0F)
-}
-Else
-{
-Return (0x00)
-}
}
Method (_CRS, 0, NotSerialized)
-Nate
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A page fault in subr_turnstile.c:propogate_priority()
On Wed, Dec 03, 2003 at 05:43:13PM +0300, Igor Sysoev wrote:
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0xe5
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc053f197
stack pointer = 0x10:0xe3c21c80
frame pointer = 0x10:0xe3c21ca0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 42 (irq29: ahd0)
trap number = 12
panic: page fault
cpuid = 2;
boot() called on cpu#2
syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue
cpuid = 2;
boot() called on cpu#2
Uptime: 1d2h4m15s
Dumping 2047 MB
jmp0xc053f2b2 propagate_priority+578
0xc053f187 propagate_priority+279:cmp(%edi),%ebx
0xc053f189 propagate_priority+281:
je 0xc053f290 propagate_priority+544
0xc053f18f propagate_priority+287:mov0x24(%ebx),%eax
0xc053f192 propagate_priority+290:mov0x4(%eax),%eax
0xc053f195 propagate_priority+293:mov(%eax),%edx
[ FAULT ]
/usr/src/sys/kern/subr_turnstile.c:256
td1 = TAILQ_PREV(td, threadqueue, td_lockq);
if (td1-td_priority = pri) {
mtx_unlock_spin(tc-tc_lock);
continue;
}
0xc053f197 propagate_priority+295:movzbl 0xe5(%edx),%eax
0xc053f19e propagate_priority+302:cmp0xfff0(%ebp),%eax
0xc053f1a1 propagate_priority+305:
jle0xc053f290 propagate_priority+544
0xc053f1a7 propagate_priority+311:call 0xc051e650 critical_enter
0xc053f1ac propagate_priority+316:mov%fs:0x0,%edx
0xc053f1b3 propagate_priority+323:mov$0x4,%eax
0xc053f1b8 propagate_priority+328:lock cmpxchg %edx,0xc06ac7fc
0xc053f1c0 propagate_priority+336:sete %al
0xc053f1c3 propagate_priority+339:movzbl %al,%eax
0xc053f1c6 propagate_priority+342:test %eax,%eax
0xc053f1c8 propagate_priority+344:
jne0xc053f210 propagate_priority+416
0xc053f1ca propagate_priority+346:mov%fs:0x0,%edx
--
Slawa Olhovchenkov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
On Fri, Sep 12, 2014 at 04:38:25PM -0500, Bryan Drewery wrote: No (as portmgr). Ports should not be touching the base system like this. Let's NOT go backwards and add a /bin/bash. In fact the /usr/bin/perl one will be removed soon as well. This is (for perl) may break many 3rd party scripts. ___ 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: [CURRENT] hostapd: WPA w/ EAP-TTLS or EAP-PEAP or EAP-TLS ?
On Fri, Oct 03, 2014 at 03:14:53PM +0200, O. Hartmann wrote: Where is the support on WPA with EAP-TTLS or EAP-PEAP or EAP-TLS in hostapd? Trying to circumvent FreeBSD's very poor documentation on the options of hostapd, I found lots of howtos for Linuxes of different flavours utilizing obviously the same hostapd basis. But whenever I try to configure one of the above mentioned auth methods for a gateway I try to configure (CURRENT, 10.1-PRE), I get an error. What is up here? You need to recompile source. And patching some Makefiles, AFAIR. ___ 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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote: Hi all, We are starting the release process of pkg 1.4, we want to have a better release process than with every single previous version of pkg. For that we will need you help! I have issuse, but I am not test on 1.4. I upgrade php (5.5.15 - 5.5.17), pecl-memcache don't change version. pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-memcache). pkg-devel has been updated to the latest version of pkg as of alpha2. Changes you can expect in pkg 1.4 are the following: - Loads of bug fixes - Stricter checking of the path passed via the plist - Removal of the bundled libyaml - new --raw-format to chose the output format for info -R and search -R - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10:amd64) the old ABI is available as a fallback in ALTABI linux packages still freebsd:10:x86:32 ? - pkg check now support a quiet mode - new 3 way merge code (stolen from the fossil-scm) to allow automerging configuration files - new @config keyword to mark a file as a config file (during upgrade/reinstallation it will try to merge the configuration with the one the user may have modified) an option AUTOMERGE is available to prevent automerging if automerge fails a .pkgnew file will be created along with the untouched user version of the configuration - The update procedure has been improved and speed up a lot (in particular for machine with low resources) - The unique identifier has been modified to be pkgname meaning now ports can be moved in new categories without having to be considered a different package - Only libraries starting by lib* are added to the provided libraries - General speed up of all operations We need help in testing, but we also need help in writing regression tests ! The more we have tests the more stable the releases will be. The release will also allow to be able to package base! regards, Bapt ___ 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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 01:24:52PM +0100, Baptiste Daroussin wrote:
On Wed, Oct 29, 2014 at 04:13:26PM +0400, Slawa Olhovchenkov wrote:
On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote:
Hi all,
We are starting the release process of pkg 1.4, we want to have a better
release
process than with every single previous version of pkg. For that we will
need
you help!
I have issuse, but I am not test on 1.4.
I upgrade php (5.5.15 - 5.5.17), pecl-memcache don't change version.
pkg uprgade don't reinstall pecl-memcache (pourdure rebuild pecl-memcache).
This is a problem with the port infrastructure for pecl
What problem?
deps: {
php55-session: {
origin: www/php55-session,
version: 5.5.17_1
},
php55: {
origin: lang/php55,
version: 5.5.17_1
},
php55-zlib: {
origin: archivers/php55-zlib,
version: 5.5.17_1
}
}
pkg-devel has been updated to the latest version of pkg as of alpha2.
Changes you can expect in pkg 1.4 are the following:
- Loads of bug fixes
- Stricter checking of the path passed via the plist
- Removal of the bundled libyaml
- new --raw-format to chose the output format for info -R and search -R
- ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become
FreeBSD:10:amd64)
the old ABI is available as a fallback in ALTABI
linux packages still freebsd:10:x86:32 ?
Yes for now, we plan to change that later.
regards,
Bapt
___
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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 01:40:25PM +0100, Baptiste Daroussin wrote:
On Wed, Oct 29, 2014 at 04:31:57PM +0400, Slawa Olhovchenkov wrote:
On Wed, Oct 29, 2014 at 01:24:52PM +0100, Baptiste Daroussin wrote:
On Wed, Oct 29, 2014 at 04:13:26PM +0400, Slawa Olhovchenkov wrote:
On Wed, Oct 29, 2014 at 12:19:33AM +0100, Baptiste Daroussin wrote:
Hi all,
We are starting the release process of pkg 1.4, we want to have a
better release
process than with every single previous version of pkg. For that we
will need
you help!
I have issuse, but I am not test on 1.4.
I upgrade php (5.5.15 - 5.5.17), pecl-memcache don't change version.
pkg uprgade don't reinstall pecl-memcache (pourdure rebuild
pecl-memcache).
This is a problem with the port infrastructure for pecl
What problem?
deps: {
php55-session: {
origin: www/php55-session,
version: 5.5.17_1
},
php55: {
origin: lang/php55,
version: 5.5.17_1
},
php55-zlib: {
origin: archivers/php55-zlib,
version: 5.5.17_1
}
}
How can we know pecl-memcache has to be reinstalled?
We won't reinstall each time a version of a dep changes :)
And what is solution?
May be some flag on package (php) for reinstall all deps?
___
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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 01:53:04PM +0100, Baptiste Daroussin wrote: How can we know pecl-memcache has to be reinstalled? We won't reinstall each time a version of a dep changes :) And what is solution? May be some flag on package (php) for reinstall all deps? I do have no idea, I'm open for suggestions :) Either on the package side with triggers but that means implementing trigger in package Or in package side with provide/requires saying that this packages requires an exact version of php meaning in case of upgrade of php the version would have changed May be (as workaround) some database witch this packages? List, or regexp. This is need for some binary modules and don't need for text modules. But for some cases -- and for text modules too. Or someone has to be clever and find a ports only solution. On ports side pecl-memcache rebuild on php version changed. Why the help does a minor version has an inpact on the pecl? isn't the abi stable over minor versions? I am don't know -- I am not php guru. As result -- memcache module don't loaded and class Memcache not found. May be just strict version check. ___ 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: pkg 1.4 freeze please test test test!
On Wed, Oct 29, 2014 at 03:07:14PM +0100, Baptiste Daroussin wrote: Why the help does a minor version has an inpact on the pecl? isn't the abi stable over minor versions? I am don't know -- I am not php guru. As result -- memcache module don't loaded and class Memcache not found. May be just strict version check. From what I do read from here: https://wiki.php.net/rfc/releaseprocess#releases_cycle only going from X.Y to X.Y+1 needs to rebuild the extensions. and going from X.Y.Z to X.Y.Z+1 should be compatible I don't know. May be this is specific only for pecl-memcache. May be reinstalling php lost information about installed extensions. ___ 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
systat -ifstat on high-speed links
I am try to use 'systat -ifstat 1' when traffic over network intrface about 35Gbit. systat show about 2.5Gbit. Where is problem? ___ 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: systat -ifstat on high-speed links
On Mon, Nov 03, 2014 at 11:58:56AM -0500, Ryan Stone wrote: http://svnweb.freebsd.org/changeset/base/272284 Date: Mon Sep 29 17:38:50 2014 UTC (4 weeks, 6 days ago) MFC after: 1 week MFC stoped? ___ 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: netmap: extension to store user data per packet/slot?
On Tue, Nov 11, 2014 at 10:13:54PM +0100, Franco Fichtner wrote:
Hi Luigi,
hi all,
so I was running into logistics issues with netmap(4)
with regard to zero-copy and redirection through pipes:
working on a load-balancing framework revealed that it
is very hard to track a packet's origins to later move
it onward to the respective outgoing interface, be it
another device or the host stack.
Long story short: user data needs to be stored for the
packet buffer or slot.
I think need configurable (by sysctl) space recerved before packet.
This is may be used as user data. Or for insert VLAN/MPLS/QinQ/etc
headers.
More general: tilera have good api for this.
There are three ways that I can see so far:
(1) Allocate a netmap pipe pair for each interface,
in case of transparent mode also a pipe for the
host stack each. That's a lot of pipes and
most likely insane, but it won't extend the ABI.
(2) Store the additional data in the actual buffer.
That is sort of ok, but seems sluggish WRT cache
behaviour -- maybe the buffer won't be read but
it needs to be written. Sure, we can store it at
the end, but there already resides the packet
timestamp if enabled (if I recall correctly).
Wouldn't extend the ABI per se, but might collide
with the timestamping
(3) Make room in struct netmap_slot itself like this:
diff --git a/sys/net/netmap.h b/sys/net/netmap.h
index 15ebf73..d0a9c0e 100644
--- a/sys/net/netmap.h
+++ b/sys/net/netmap.h
@@ -147,6 +147,7 @@ struct netmap_slot {
uint16_t len; /* length for this slot */
uint16_t flags; /* buf changed, etc. */
uint64_t ptr; /* pointer for indirect buffers */
+ uint64_t userdata; /* reserved storage for caller */
};
It could also be broken down in two fields with uint32_t
each; not sure what would be more sensible. This of course
requires an API bump, although it should be backwards
compatible.
Any feedback on this is highly appreciated.
Cheers,
Franco
___
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
___
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: simple task to speed up booting
On Sun, Dec 14, 2014 at 07:52:11AM -0700, Ian Lepore wrote:
On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
large part of our boot time on systems with slow-ish serial consoles.
I think right now it takes a step for each 512 byte read, reducing that
to once every 64kB or even 1MB would be an improvement with the kind of
kernel sizes we have today.
I experimented with that a while ago using the attached patch and was
disappointed with the results. As I vaguely remember it, a divisor of 8
looked fine, but had no significant speedup. With a divisor of 32 the
difference was measureable (only like 1.5 seconds or so faster), but it
gave the impression that something was wrong, and the overall perception
was that it was slower rather than faster, despite what a stopwatch
said.
I was testing at 115kbps, maybe at 9600 it would be significant. I
don't understand why anything these days is still defaulting to 9600.
It's the 21st century, but we never got the George Jetson flying cars we
were promised, and apparently we're never going to break loose from the
standards set by accoustic-coupled modems.
You not always working with self-owned servers.
Default is 9600,8n1
___
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: any primer on running bhyve guests sharing disk with host ?
On Sat, Jan 03, 2015 at 05:15:11PM +0100, Luigi Rizzo wrote: Hi, in order to do some kernel testing, I would like to run bhyve guests using (through NFS, probably) the host's file system. diskless(8) is probably one way to go, i was wondering if someone has instructions for that. Specifically: - how to bhyveload a kernel (rather than the full disk image); as an alternative, given a kernel, something to build an image that can be passed to bhyveload - how to pass the necessary config (rootpath) to the client without having to rely on a specialized dhcp server I used to be familiar with diskless configs, so i can probably sort out the server side myself. May be I missunderstand you, but diskless client-specific config relay on client IP address (ex: /conf/ip/1.2.3.4/...). Also, diskless boot relay on BIOS network support (by PXE, for example), with working NIC, assigned IP address and etc. ___ 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: tzsetup - UTC user question
On Tue, Feb 03, 2015 at 03:08:38PM +1000, Paul Koch wrote: Since the default option for Select local or UTC clock changed from No to Yes, we are seeing many customers who incorrectly answer this question! This screws up things in our app because we store all data in UTC. A few observations... Most people don't know what CMOS clock is. Maybe change the wording to BIOS clock or Hardware Clock ?? The person doing the install may not know what the clock is currently set to, especially when installing in a VM. Perhaps the screen should display the current machine time so they can correctly answer the question. Why was the default changed from No to Yes ? or change ntpd_sync_on_start=YES to force correct time. in most case for hardware platform CMOS time contains garbage. ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: On 01/14/15 15:31, Hans Petter Selasky wrote: On 01/11/15 19:08, Jason Wolfe wrote: Hans, We've had 50 machines running 10.1-STABLE with this patch for the better part of a week without issue. Prior we would have seen a panic every few days at the least, so things are looking very promising on our front. Jason Hi, I've updated D1438 including the manual page changes needed for timeout.9 aswell in addition to a minor fix for those using timeout() and untimeout() and KTR(). https://reviews.freebsd.org/D1438 --HPS FYI: Now in -current: https://svnweb.freebsd.org/changeset/base/277213 Thanks for all good comments and reviews. Only stability impovement? Or performance too? ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Thu, Jan 15, 2015 at 05:42:36PM +0100, Hans Petter Selasky wrote: On 01/15/15 16:58, Slawa Olhovchenkov wrote: On Thu, Jan 15, 2015 at 04:51:00PM +0100, Hans Petter Selasky wrote: On 01/15/15 16:46, Slawa Olhovchenkov wrote: On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: Only stability impovement? Or performance too? Hi, Stability improvement mostly. Should not affect performance from what I know. Some changes are made about when and how we can select a different callback CPU for a callout callback. Try reading the updated timeout(9) I am not kernel guru and can't be draw a conclusion from manual page. man manual page first. Maybe it answers your question. Else feel free to ask here. As I understand performance for massive TCP connections (tens of thousands connections) will be same, no improvement, no degraded? (very high lock congestion on TCP timers working). Hi, There is no difference in memory footprint per TCP connection. There is no significant different in the amount of code executed when a callout is started/stopped or reset. There might be a reduction in the number of times the spinlocks inside the callout subsystem are locked/unlocked, due to some simplifications made and checks for redundant locking. The changes are mainly about closing some races in the callout subsystem and cornercases towards the TCP/IP stack which use callouts. There is a patch for the TCP/IP stack coming possibly next week to take advantage of the new callout_drain_async() function. It is not ready yet, and I'm waiting for the current callout patch to settle first. Thanks. I am going to try this patch in 10-STABLE branch. ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Thu, Jan 15, 2015 at 04:51:00PM +0100, Hans Petter Selasky wrote: On 01/15/15 16:46, Slawa Olhovchenkov wrote: On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: Only stability impovement? Or performance too? Hi, Stability improvement mostly. Should not affect performance from what I know. Some changes are made about when and how we can select a different callback CPU for a callout callback. Try reading the updated timeout(9) I am not kernel guru and can't be draw a conclusion from manual page. man manual page first. Maybe it answers your question. Else feel free to ask here. As I understand performance for massive TCP connections (tens of thousands connections) will be same, no improvement, no degraded? (very high lock congestion on TCP timers working). ___ 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: DigitalOcean offers VMs with FreeBSD!
On Thu, Jan 15, 2015 at 06:28:23PM +0300, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15.01.2015 14:29, Lev Serebryakov wrote: https://www.digitalocean.com/company/blog/presenting-freebsd-how-we-made-it-happen/ I didn't see this news on mailing lists :) But here are some thread about FreeBSD is way slower than Linux in these virtual installations https://news.ycombinator.com/item?id=487 May be IOPS quotation? Can you test with dd and custom kernel with MAXPHYS=1048576 ? ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: On 01/17/15 23:18, Hans Petter Selasky wrote: On 01/17/15 20:11, Jason Wolfe wrote: HPS, Just to give a quick status update, this patch has most certainly resolved our spin lock held too long panics on stable/10. Thank you to JHB for spending some time digging into the issue and leading us to td_slpcallout as the culprit, and HPS for your rewrite. I had heard rumors of other being affected by similar issues, so this seems like a fine candidate for an MFC if possible. Jason Hi Jason, I'm glad to hear that my patch has resolved your issue and I'm happy we now have a more stable system. It was actually a co-worker at work which wrote some bad code which I started debugging which then lead me to look at the callout subsystem. One bug kills the other ;-) I'm planning a MFC to 10-stable - yes, and will possibly add the _callout_stop_safe() function to not break binary compatibility with existing drivers as part of the MFC. --HPS Hi, Here is a followup patch for the TCP stack like I mentioned in the beginning of the work done on the callout subsystem: https://reviews.freebsd.org/D1563 If someone has a setup for massive TCP testing please give it a spin. I have on 10.1 (with applied r261906). ___ 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: help with sandybridge/ivybridge hwpmc NUMA DRAM counters
On Thu, Apr 23, 2015 at 12:24:06AM -0700, Adrian Chadd wrote: On 23 April 2015 at 00:22, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: Yeah, on stable/10. But on -HEAD it's different. There's two entries - one for d3_01 and one for d3_03. What CPU model? CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.06-MHz K8-class CPU) Origin=GenuineIntel Id=0x306e4 Family=0x6 Model=0x3e Stepping=4 Same with me? ___ 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: help with sandybridge/ivybridge hwpmc NUMA DRAM counters
On Wed, Apr 22, 2015 at 11:38:22PM -0700, Adrian Chadd wrote: hi all, I'm having a spot of problem trying to get the local/remote dram counters working on the NUMA sandybridge and ivybridge systems here. Things work fine using intel-pcm, but those same counters don't work with hwpmc. Sandybridge - there's apparently an MSR that needs to be fiddled if the counters are active. Ivybridge - the v1 and v2 chips have different local/remote dram counters, and on my v2 setup there's actually /two/ LOCAL_DRAM: # pmccontrol -L | grep DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.REMOTE_DRAM CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.05-MHz K8-class CPU) adrian@testbox1:~/git/github/erikarn/freebsd/sys/dev/hwpmc % pmccontrol -L | grep DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.REMOTE_DRAM Now, i may be able to get to figuring this out at some point in the distant future, but I'd really appreciate any help I can get now. I'm now at the point with the NUMA affinity API stuff where I'm now chasing down when things are correctly working with local/remote RAM, and I'd really like to use hwpmc in sampling mode to work on it. Thanks for any help! -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 ___ 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: help with sandybridge/ivybridge hwpmc NUMA DRAM counters
On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: Yeah, on stable/10. But on -HEAD it's different. There's two entries - one for d3_01 and one for d3_03. What CPU model? ___ 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: help with sandybridge/ivybridge hwpmc NUMA DRAM counters
On Thu, Apr 23, 2015 at 10:24:55AM +0300, Slawa Olhovchenkov wrote: On Thu, Apr 23, 2015 at 12:24:06AM -0700, Adrian Chadd wrote: On 23 April 2015 at 00:22, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: Yeah, on stable/10. But on -HEAD it's different. There's two entries - one for d3_01 and one for d3_03. What CPU model? CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.06-MHz K8-class CPU) Origin=GenuineIntel Id=0x306e4 Family=0x6 Model=0x3e Stepping=4 Same with me? May be in you case E5-269x? ___ 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: pkg 1.5.0 is out
On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: Hi all, Final pkg 1.5.0 has been released. pkg 1.5.1 at 'pkg upgrade' propose === New packages to be INSTALLED: nvidia-driver: 346.47 linux-c6-libGLU: 10.1 === I am use nvidia-driver-340: # pkg info nvidia-driver-340-340.76 nvidia-driver-340-340.76 Name : nvidia-driver-340 Version: 340.76 Installed on : Tue Mar 10 16:15:59 MSK 2015 Origin : x11/nvidia-driver-340 Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : x11 kld Licenses : NVIDIA Maintainer : da...@freebsd.org WWW: http://www.nvidia.com/object/unix.html Comment: NVidia graphics card binary drivers for hardware OpenGL rendering Options: ACPI_PM: on DOCS : on LINUX : on WBINVD : off Shared Libs required: libXext.so.6 libX11.so.6 Shared Libs provided: libvdpau_nvidia.so.1 libnvidia-glsi.so.1 libnvidia-glcore.so.1 libnvidia-eglcore.so.1 libnvidia-cfg.so.1 libglx.so.1 libGLESv2.so.2 libGLESv1_CM.so.1 libGL.so.1 libEGL.so.1 Annotations: repo_type : binary repository : ivs Flat size : 209MiB ___ 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: Increase BUFSIZ to 8192
On Thu, May 14, 2015 at 08:53:05AM -0600, Ian Lepore wrote: At least I'm inclined to ponder it. Apparently nobody else is. People running servers with more GB of ram than grains of sand on the beach won't care about things like 64k buffers used by /bin/sh to read a line of text, and all the world is big servers now, right? I have setups with servering tens of gigabits pers second from one server. Default send_lowat (SO_SNDLOWAT) is 2048. Settnig to 128K increase load. Setting to 16k slightly reduce. Not so simple. ___ 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
