Re: Voxer using FreeBSD, BSDNow.tv interview
On Mon, Oct 20, 2014 at 07:18:45PM -0400, Philip M. Gollucci wrote: > Not true, you can roll your own omnibus chef builds with this fixed. Can we get this off advocacy@ please? pgp6sj87TQSAd.pgp Description: PGP signature
Re: Jenkins, Kyua, and Bhyve used for FreeBSD OS testing
Hi, Thanks for those kind words, Alfred! I would like to point out a few things. (1) Jenkins team are really easy to work with, and I've been pushing fixes upstream to them, such as: https://github.com/jenkinsci/jenkins/pull/1387 which fixes shared library support on FreeBSD, Windows, Linux/ARM, Linux/PPC. Jenkins has something called the Jenkins Pull Request builder, so that when you submit a patch to them via a Github Pull Request, it checks out the Jenkins source, patches it, builds it, and runs automated tests. This helps the Jenkins team to decide whether to pull in a patch or not. It's quick, easy, works welland honestly, makes working with an open source project fun! Unfortunately, working with FreeBSD can seem to be antiquated and a drudgery in comparison, but things are improving with things like Phabricator and Bugzilla. (2) By fixing up the unit tests and paying attention to failures, I've found real problems that need to be fixed. The yacc unit tests started failing after recent imports of byacc. I traced down the problem, and reported it upstream to Thomas Dickey who maintains byacc. He fixed the problem (see http://invisible-island.net/byacc/CHANGES 2014-10-05 and 2014-10-06) and I confirmed that fixed the unit tests. We have the fixed byacc in HEAD and stable/10 branches. Although I've got the ball rolling, hopefully more people in the FreeBSD community can help out by writing tests, paying attention to test failures, helping out with devops issues related to Jenkins, etc. For folks interested, hop on freebsd-test...@freebsd.org and help pitch in! -- Craig On Mon, Oct 20, 2014 at 9:56 PM, Alfred Perlstein wrote: > Craig this is really great. Thanks for doing this and thanks for the > Jenkins guys on giving a shout out! > > On Oct 20, 2014, at 9:42 AM, Craig Rodrigues wrote: > > > Hi, > > > > FYI, Kohsuke Kawaguchi, the lead developer of Jenkins, > > accepted my posting on the Jenkins blog, which describes > > how the FreeBSD project is using Jenkins, Kyua, and Bhyve > > for FreeBSD OS testing: > > > > http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testing > > > > -- > > Craig > > ___ 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: Jenkins, Kyua, and Bhyve used for FreeBSD OS testing
Craig this is really great. Thanks for doing this and thanks for the Jenkins guys on giving a shout out! On Oct 20, 2014, at 9:42 AM, Craig Rodrigues wrote: > Hi, > > FYI, Kohsuke Kawaguchi, the lead developer of Jenkins, > accepted my posting on the Jenkins blog, which describes > how the FreeBSD project is using Jenkins, Kyua, and Bhyve > for FreeBSD OS testing: > > http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testing > > -- > Craig > ___ > 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: kernel page fault with nfs
Hello Tibias, Any news? Best Regards, 2014-10-20 20:55 GMT+08:00 Rick Macklem : > Tobias C. Berner wrote: > > Now that I posted it, 32767 should of course be 2^15=32768. Let me > > recheck if it still > > hangs with the correct value. > > > > On Monday 20 October 2014 09.15:39 Tobias C. Berner wrote: > > > Hi Marcelo > > > > > > Yes, I'm using readahead: > > > The mountoptions are > > > "readahead=4,soft,intr,rw,tcp,wsize=32767,rsize=32767,late" > > > > If you type "nfsstat -m", you will see what is actually getting used. > (I suspect the above rsize/wsize got clipped to 32256 or something like > that. I think it clips it to a multiple of 512.) > > If rsize/wsize are not a power of 2, there are issues, although I've never > been able to see why it is broken. Maybe it should clip it to the power of > 2 below the value, since it causes unexplained problems otherwise. > > rick > > > > > > > mfg Tobias > > > > > > On Monday 20 October 2014 10.41:30 Marcelo Araujo wrote: > > > > Hello Tobias, > > > > > > > > Could you show how you are mount the NFS share? > > > > Are you using 'readahead' option? > > > > > > > > Best Regards, > > > > > > > > 2014-10-19 17:40 GMT+08:00 Tobias C. Berner : > > > > > both are at 1100038. > > > > > > > > > > On Sunday 19 October 2014 11.12:36 Marcelo Araujo wrote: > > > > > > It is still strange, could you do what Allan said and send us > > > > > > the > > > > > > result > > > > > > > > > > in > > > > > > > > > > > case you are not sure you have world and kernel in the same > > > > > > revision! > > > > > > > > > > > > On Oct 19, 2014 6:48 AM, "Tobias C. Berner" > > > > > > wrote: > > > > > > > Hi > > > > > > > > > > > > > > World ist from october 16, installed world and kernel then. > > > > > > > > > > > > > > Kernel was later rebuilt with debug-options. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is the following more sensible? > > > > > > > > > > > > > > > > ## > > > > > > > > > > > > > > # kgdb NOXON/kernel.debug vmcore.1 > > > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > > > > > > > > > cpuid = 5; apic id = 05 > > > > > > > > > > > > > > fault virtual address = 0xfe07d1744000 > > > > > > > > > > > > > > fault code = supervisor write data, page not present > > > > > > > > > > > > > > instruction pointer = 0x20:0x80d4d58a > > > > > > > > > > > > > > stack pointer = 0x28:0xfe086057f240 > > > > > > > > > > > > > > frame pointer = 0x28:0xfe086057f2f0 > > > > > > > > > > > > > > code segment = base 0x0, limit 0xf, type 0x1b > > > > > > > > > > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > > > > > > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > > > > > > > > > > current process = 6524 (python2.7) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (kgdb) bt > > > > > > > > > > > > > > #0 doadump (textdump=1) at pcpu.h:219 > > > > > > > > > > > > > > #1 0x80926b6d in kern_reboot (howto=260) at > > > > > > > /usr/src/sys/kern/kern_shutdown.c:447 > > > > > > > > > > > > > > #2 0x809270c0 in panic (fmt=) > > > > > > > at > > > > > > > /usr/src/sys/kern/kern_shutdown.c:746 > > > > > > > > > > > > > > #3 0x8035f167 in db_panic (addr= > > > > > > out>, > > > > > > > have_addr=2, count=0, modif=0x0) at > > > > > > > /usr/src/sys/ddb/db_command.c:473 > > > > > > > > > > > > > > #4 0x8035ed7d in db_command (cmd_table=0x0) at > > > > > > > /usr/src/sys/ddb/db_command.c:440 > > > > > > > > > > > > > > #5 0x8035eaf4 in db_command_loop () at > > > > > > > /usr/src/sys/ddb/db_command.c:493 > > > > > > > > > > > > > > #6 0x80361600 in db_trap (type= > > > > > > out>, > > > > > > > code=0) > > > > > > > > > > at > > > > > > > > > > > > /usr/src/sys/ddb/db_main.c:251 > > > > > > > > > > > > > > #7 0x80966f01 in kdb_trap (type=12, code=0, > > > > > > > tf= > > > > > > optimized > > > > > > > out>) at /usr/src/sys/kern/subr_kdb.c:654 > > > > > > > > > > > > > > #8 0x80d4fa7c in trap_fatal > > > > > > > (frame=0xfe086057f190, > > > > > > > > > > eva= > > > > > > > > > > > optimized out>) at /usr/src/sys/amd64/amd64/trap.c:861 > > > > > > > > > > > > > > #9 0x80d4fe0c in trap_pfault > > > > > > > (frame=0xfe086057f190, > > > > > > > usermode=) at > > > > > > > /usr/src/sys/amd64/amd64/trap.c:677 > > > > > > > > > > > > > > #10 0x80d4f42e in trap (frame=0xfe086057f190) > > > > > > > at > > > > > > > /usr/src/sys/amd64/amd64/trap.c:426 > > > > > > > > > > > > > > #11 0x80d33972 in calltrap () at > > > > > > > /usr/src/sys/amd64/amd64/exception.S:231 > > > > > > > > > > > > > > #12 0x80d4d58a in bzero () at > > > > > > > /usr/src/sys/amd64/amd64/support.S:53 > > > > > > > > > > > > > > #13 0x80830463 in ncl_doio (vp=0xf801e7f99938, > > > > > > > bp=0xfe07c5a168e8,
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Mon, Oct 20, 2014 at 08:04:14PM -0400, Allan Jude wrote: > > For instance, the page that talks about running buildworld and buildkernel > > have some instructions that are evidently vestigal for root-on-ZFS people. > > Which parts? Nothing about buildworld is really any different when using > ZFS except maybe the way you mount /usr/obj with noatime etc. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html In this case, after "shutdown now" it suggests turning off a readonly flag that's not on, mounting everything despite nothing being unmounted, and setting the kernel time zone despite that never seeming to be an issue. > Can you be more specific? The documentation team likes to add 'quick start' > sections to the often more complex sections, so that users looking to just > get started can do so, and dig into the more advanced options once they > have it working. Sure. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-poudriere.html So, coming at it from scratch, the section has a quick description and notes where to find a sample config file. Then it says "It may be convenient to put poudriere datasets in an isolated tree mounted at /poudriere. Defaults for the other configuration values are adequate." However, that's the first appearance of the word "dataset" so I don't know what it is or why I want a root-level mount for it. Section 5.6.1 has an example invocation: poudriere jail -c -j 10amd64 -v 10.0-RELEASE This might not catch everyone, but the formality of the jail name and the version made me think that the jail name has to be of a certain strict form to work. Maybe it doesn't? It's not entirely clear. Then there's another example invocation: poudriere ports -c -p local It's not altogether clear (to me at least) what this is doing as compared with the -c -i -v invocataion. Again, I suspect I can spend enough time reading docs to figure it out, but that completely negates the value of the Handbook as a primary source for information. After these two somewhat opaque examples, we're told "poudriere can build ports with multiple configurations, in multiple jails, and from different port trees" and "The basic configuration shown here puts a single jail-, port-, and set-specific make.conf in /usr/local/etc/poudriere.d." This one definitely got me, as it seems to suggest that things should live in /usr/local/etc/poudriere.d, but it doesn't specify exactly where. I see something now that I think I missed before, which is that the long string "10amd64-local-workstation-pkglist" references bits of text from the first two invocations, but the description of how the string is formulated is somewhat opaque, depending to some extent on the still-undefined "set" which I presume to mean the same thing as "dataset". But, where do I go to find the built packages? I'm guessing at the moment that I'd find them somewhere in /poudriere, but I'm not entirely clear on how different architectures and sets and such are kept distinct... (I spun up a large virtual machine to do a test build and try to observe where things went afterwards, and at that I was still unclear on where, for instance, config options were stored... Anyway, the build exhausted its eight gigs of RAM and the OOM killer made a mess of things, and I haven't had a chance to revisit the process.) It's entirely possible that I'm just old and slow and that this stuff isn't as unclear to me as it seems, but at the very least it's introducing new concepts without defining them and then using them in combinations that don't help the reader to understand how the combinations work. Part of this is inconsistency in formatting - are all the italic bits freeform text that doesn't matter, in the examples? It seems like some of them (FreeBSD version, for example) can't be. Again, a dig through more docs would clarify it, but if that's necessary then this Handbook section seems somewhat inadequate. > One goal is to actually have the version of the ports tree that the most > recent binary packages were built with available, so that users who use > that would have 0 complications from mixing. That would be useful. > Also, there have been some proposed features for pkg to make it aware of > which packages were installed from ports, and when 'pkg upgrade' runs, to > rebuild those packages from ports with the same options, instead of > installing the 'wrong' version from the binary packages, requiring the user > to 'pkg lock' or 'pkg annotate' to avoid that. Hm, I'm as yet unfamiliar with those two commands, but again, that sounds pretty useful. > Binary packages of libdvdcss are not built for legal reasons I figured as much - Debian doesn't ship it at all, for comparison, leaving the user in an even worse position. It was a cause of stress when I also had "don't mix pkgs and ports" emblazoned across my vision. Worth noting is that my world hasn't ended mixing the two, to the point where I'm doing so
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On 2014-10-20 19:15, Mason Loring Bliss wrote: > On Mon, Oct 20, 2014 at 06:21:58PM -0400, Allan Jude wrote: > >> This thread is supposed to be about how to make it easier for people to >> migrate to FreeBSD from Linux. Not a discussion about forums vs mailing >> lists vs newsgroups. > > I'm going to transition from being an avid Debian user who hates web fora to > an avid FreeBSD who hates web fora. > > Anyway, my experience here is useful as I've got to be representative of a > number of people making the transition lately. It's been a relatively smooth > transition so far, with only a couple bugs and quirks in the way of my doing > everything I did with Debian. > > Two things would be principally useful for people coming from Linux. Thank you very much for sharing this > > First, the handbook should be updated and corrected, as it's a good enough > resource that I've come to depend upon it, but I've hit snags that seem to > not reflect the current state of FreeBSD. > > For instance, the page that talks about running buildworld and buildkernel > have some instructions that are evidently vestigal for root-on-ZFS people. > Which parts? Nothing about buildworld is really any different when using ZFS except maybe the way you mount /usr/obj with noatime etc. > Another example, the documentation of Poudriere is hard to follow, presenting > a complex and idealized set-up rather than explaining to a new user what the > moving parts are and how it all works. I strongly suspect in that case that > people who need the Handbook won't easily follow that, and people who can > follow it don't need the Handbook per se, or that level of instruction. > Can you be more specific? The documentation team likes to add 'quick start' sections to the often more complex sections, so that users looking to just get started can do so, and dig into the more advanced options once they have it working. > Joe Armstrong talks about this process of picking an audience in his forward > to the second edition of his Erlang book: > > https://joearms.github.io/2014/06/26/Background-to-programming-erlang.html > > The second thing that would be useful would be a series of cheat sheets for > various things. This can either be equivalent commands or equivalent systems. > Let new folks know that LUKS is GELI and that md-raid1 is gmirror and so > forth. Show common package handling commands for various Linux flavours and > map them to pkgng and ports. For instance, what's the equivalent of "yum > provides"? Or what do I do in place of "apt-cache search" or "zypper up" or > similar. > This is what this thread was originally about, creating such cheat sheets. > Other things in the grab bag... It's generally said that ports and pkgs > shouldn't mix, but there are at least a couple instances where it's > unavoidable: > This was true with the old package system, since those packages were built work a ports tree snapshot from the date of the release. With the new binary packages being rebuild weekly, it is much less of an issues. One goal is to actually have the version of the ports tree that the most recent binary packages were built with available, so that users who use that would have 0 complications from mixing. Also, there have been some proposed features for pkg to make it aware of which packages were installed from ports, and when 'pkg upgrade' runs, to rebuild those packages from ports with the same options, instead of installing the 'wrong' version from the binary packages, requiring the user to 'pkg lock' or 'pkg annotate' to avoid that. > I bet roughly no one who installs Subversion wants the FreeBSD bug report > headers baked in by default, but there they are unless you rebuild from ports > with a non-default configuration. > > If you want to watch DVDs on your FreeBSD workstation, it's necessary to > install libdvdcss, but you can't get it from pkgng because it's not there. > Again, you must build from ports. > Binary packages of libdvdcss are not built for legal reasons > I have nothing against ports, but people are warned off of mixing packages > and ports when clearly it's necessary sometimes. > It may be time to revisit this warning, as it may no longer be required. > Oh, here's one. I *was* horrified by ports at first, until someone told me > about "make config-recursive". It really makes me wonder why this isn't the > default. I remember giving up on FreeBSD when 9.x was new because I had to > build X from ports after the FreeBSD breach, and it seemed like the process > was going to take a couple days of stuttering stops and starts as random > packages I didn't want in some cases popped up between compiles. I learned > some mechanism for saying "just take the defaults" but what I know now is > that what I really wanted was "make config-recursive". Why, out of curiosity, > is it not the default? That would seem better than documenting it harder. > Making config-recursive the default is infact a good ide
Re: Voxer using FreeBSD, BSDNow.tv interview
Not true, you can roll your own omnibus chef builds with this fixed. On Mon, Oct 20, 2014 at 1:36 PM, Rainer Duffner wrote: > > > Am 20.10.2014 um 10:19 schrieb David Chisnall : > > > > > > I presume that most of the relevant differences are for users / > developers and not sysadmins? It's worth noting that GNU coreutils, tar, > bash, and a load of other things are in the ports repository. I wonder if > it's worth having a gnu-userland metaport, perhaps with something like the > Solaris approach of sticking them all in a different tree so that you can > just add that to the start of your PATH and have all of the GNU tools work > by default. > > > > > They use chef. > The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD > version of it. Well, it least it did the last time I looked. Maybe this got > fixed in the meantime. > Which means that to „bootstrap“ a node, you’ve first got to install pkg on > it, install bash, symlink it to /bin/bash and then bootstrap the node. > Which kind of runs against the concept of doing everything via chef. > > > > > > > ___ > freebsd-advoc...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-advocacy > To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org > " -- - TaxiMagic Mobile App $10 Promo Code - 'p6magic' any 1st time rider can use it $ 5 Promo Code - 'cabbie' - thanks New Castle! 4096R/D1EAB94D 2081 E230 3001 6508 8847 1BBF A0A8 DB0F D1EA B94D Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. Director IT Operations, RideCharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ 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: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Mon, Oct 20, 2014 at 06:21:58PM -0400, Allan Jude wrote: > This thread is supposed to be about how to make it easier for people to > migrate to FreeBSD from Linux. Not a discussion about forums vs mailing > lists vs newsgroups. I'm going to transition from being an avid Debian user who hates web fora to an avid FreeBSD who hates web fora. Anyway, my experience here is useful as I've got to be representative of a number of people making the transition lately. It's been a relatively smooth transition so far, with only a couple bugs and quirks in the way of my doing everything I did with Debian. Two things would be principally useful for people coming from Linux. First, the handbook should be updated and corrected, as it's a good enough resource that I've come to depend upon it, but I've hit snags that seem to not reflect the current state of FreeBSD. For instance, the page that talks about running buildworld and buildkernel have some instructions that are evidently vestigal for root-on-ZFS people. Another example, the documentation of Poudriere is hard to follow, presenting a complex and idealized set-up rather than explaining to a new user what the moving parts are and how it all works. I strongly suspect in that case that people who need the Handbook won't easily follow that, and people who can follow it don't need the Handbook per se, or that level of instruction. Joe Armstrong talks about this process of picking an audience in his forward to the second edition of his Erlang book: https://joearms.github.io/2014/06/26/Background-to-programming-erlang.html The second thing that would be useful would be a series of cheat sheets for various things. This can either be equivalent commands or equivalent systems. Let new folks know that LUKS is GELI and that md-raid1 is gmirror and so forth. Show common package handling commands for various Linux flavours and map them to pkgng and ports. For instance, what's the equivalent of "yum provides"? Or what do I do in place of "apt-cache search" or "zypper up" or similar. Other things in the grab bag... It's generally said that ports and pkgs shouldn't mix, but there are at least a couple instances where it's unavoidable: I bet roughly no one who installs Subversion wants the FreeBSD bug report headers baked in by default, but there they are unless you rebuild from ports with a non-default configuration. If you want to watch DVDs on your FreeBSD workstation, it's necessary to install libdvdcss, but you can't get it from pkgng because it's not there. Again, you must build from ports. I have nothing against ports, but people are warned off of mixing packages and ports when clearly it's necessary sometimes. Oh, here's one. I *was* horrified by ports at first, until someone told me about "make config-recursive". It really makes me wonder why this isn't the default. I remember giving up on FreeBSD when 9.x was new because I had to build X from ports after the FreeBSD breach, and it seemed like the process was going to take a couple days of stuttering stops and starts as random packages I didn't want in some cases popped up between compiles. I learned some mechanism for saying "just take the defaults" but what I know now is that what I really wanted was "make config-recursive". Why, out of curiosity, is it not the default? That would seem better than documenting it harder. Ah, and one more for the grab bag. I strongly suspect that many folks coming from Linux are going to bristle at the notion of using Sendmail. I used to run it so I wasn't terribly bothered by it, but maybe pre-populating rc.conf with obvious bits that people can see and turn off would be nice. OpenBSD has a nice model of populating rc.conf and sysctl.conf fully, and it ends up being a pleasant tool. Those awash in wonder, coming from Linux, can say, "Look, it's all right here!" -- Mason Loring Bliss ma...@blisses.orgEwige Blumenkraft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I ___ 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: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On 20 October 2014 15:21, Allan Jude wrote: > This thread is supposed to be about how to make it easier for people to > migrate to FreeBSD from Linux. Not a discussion about forums vs mailing > lists vs newsgroups. > It turns out those things are intertwined. It turns out that making it easier for people to do 'X' just isn't a handbook and a printed book - it's community building, communication and inclusiveness. All the ease of use in the world doesn't matter if people don't know about it and don't feel a part of of something. If you want to avoid the community building, then it's just a tool - and you should market it as such. :) -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"
Re: ssh None cipher
On 2014-10-20 14:33, Brooks Davis wrote: > On Sat, Oct 18, 2014 at 12:10:28AM -0400, Allan Jude wrote: >> On 2014-10-17 22:43, Benjamin Kaduk wrote: >>> On Fri, 17 Oct 2014, Ben Woods wrote: >>> Whilst trying to replicate data from my FreeNAS to my FreeBSD home theater PC on my local LAN, I came across this bug preventing use of the None cipher: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163127 I think I could enable the None cipher by recompiling base with a flag in /etc/src.conf. >>> >>> I agree. >>> Is there any harm in enabling this by default, but having the None cipher remain disabled in /etc/ssh/sshd_config? That way people wouldn't have it on my default, but wouldn't have to recompile to enable it. >>> >>> I do not see any immediate and concrete harm that doing so would cause, >>> yet that is insufficient for me to think that doing so would be a good >>> idea. >> >> I've been using openssh-portable from ports with the none cipher patch >> to get around this. >> >> IIRC, upstream openssh refuses to merge the none cipher patches "because >> you shouldn't do that". But I'd vote for having it compiled in and just >> disabled by default. >> >> It will refuse to let you have a shell without encryption, and prints a >> big fat hairy warning when encryption is disabled. > > When Bjoern and I did the merge of the HPN patches we left None disable > by default out of a desire to be conservative with a change we knew some > people didn't like. I think turning it on by default would be fine given > the seatbelts in place to prevent accidental inappropriate use. > > -- Brooks > +1 to this. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On 2014-10-20 17:15, Chris H wrote: > On Mon, 20 Oct 2014 14:32:53 -0400 Mason Loring Bliss > wrote > >> On Sat, Oct 18, 2014 at 02:58:57PM +0900, Tomoaki AOKI wrote: >> >>> I think the advantages of the forum are... >>> >>> *Well moderated by moderators and anministrators. >>> *Registering email address is needed, but not disclosed by default. >> >> The disadvantages of web fora include: >> >> * I can't read things in my very efficient email client. Related: >> * I have to compose my replies in a web browser edit window. >> * I need to visit periodically and hope that the site makes it possible for >> me to attend to unread messages without struggling. >> >> I think wikis are useful. I think web fora exist because folks haven't had >> sufficient exposure to email to make the advantages clear. Not discussed here >> are newsgroups, which are perhaps ideal for the sorts of topics commonly >> found on mailing lists, except perhaps that they're not at all centralized. > > This thread reeks of bikeshed. > There isn't anything wrong with all of the opinions shared in this thread > except there will surely be no final consensus. :) > > --Chris >> >> -- >> Mason Loring Bliss (( "In the drowsy dark cave of the mind dreams >> ma...@blisses.org )) build their nest with fragments dropped >> http://blisses.org/ (( from day's caravan." - Rabindranath Tagore >> ___ >> 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" > This thread is supposed to be about how to make it easier for people to migrate to FreeBSD from Linux. Not a discussion about forums vs mailing lists vs newsgroups. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: FreeBSD && TCP stealth
I am not aware of any work but adding -net to get more "networking" eyeballs. On Mon, Oct 20, 2014 at 1:23 AM, Matthias Apitz wrote: > El día Monday, October 20, 2014 a las 09:25:28AM +0200, Matthias Apitz > escribió: > >> >> Hello, >> >> Is there any work started or in progress to implement TCP stealth in our >> kernel as proposed to IETF in >> >> https://datatracker.ietf.org/doc/draft-kirsch-ietf-tcp-stealth/ >> >> The idea is that the client put some magic value in the ISN of the first >> SYN pkg which is derived from a secret the client and the server share. >> The server can check the ISN and decide if it will answer the SYN pkg or >> do a RST, for example. > > For Linux wip see also: https://gnunet.org/knock > > matthias > -- > Matthias Apitz | /"\ ASCII Ribbon Campaign: > E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail > WWW: http://www.unixarea.de/ | X- No proprietary attachments > phone: +49-170-4527211 | / \ - Respect for open standards > | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign > ___ > 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: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Mon, 20 Oct 2014 14:32:53 -0400 Mason Loring Bliss wrote > On Sat, Oct 18, 2014 at 02:58:57PM +0900, Tomoaki AOKI wrote: > > > I think the advantages of the forum are... > > > > *Well moderated by moderators and anministrators. > > *Registering email address is needed, but not disclosed by default. > > The disadvantages of web fora include: > > * I can't read things in my very efficient email client. Related: > * I have to compose my replies in a web browser edit window. > * I need to visit periodically and hope that the site makes it possible for > me to attend to unread messages without struggling. > > I think wikis are useful. I think web fora exist because folks haven't had > sufficient exposure to email to make the advantages clear. Not discussed here > are newsgroups, which are perhaps ideal for the sorts of topics commonly > found on mailing lists, except perhaps that they're not at all centralized. This thread reeks of bikeshed. There isn't anything wrong with all of the opinions shared in this thread except there will surely be no final consensus. :) --Chris > > -- > Mason Loring Bliss (( "In the drowsy dark cave of the mind dreams > ma...@blisses.org )) build their nest with fragments dropped > http://blisses.org/ (( from day's caravan." - Rabindranath Tagore > ___ > 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: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support
On 10/8/14, Yonghyeon PYUN wrote: > On Thu, Oct 02, 2014 at 02:07:30PM +0900, Yonghyeon PYUN wrote: >> On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote: >> > On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote: >> > > Hi, >> > > I've added support for QAC AR816x/AR817x ethernet controllers. It >> > > passed my limited testing and I need more testers. You can find >> > > patches from the following URLs. >> > > >> > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff >> > > and >> > > http://people.freebsd.org/~yongari/alc/alc.diff.20140930 >> > > >> > > pci.qurik.diff is to workaround silicon bug of AR816x. Without it >> > > MSI/MSIX interrupt wouldn't work. If you just want to use >> > > legacy INTx interrupt you don't have to apply it but you have to >> > > tell alc(4) not to use MSI/MSIX interrupt with tunables( >> > > hw.alc.msi.disable and hw.alc.msix_disable). >> > > >> > > alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172 >> > > and E2200 controllers. It supports all hardware features except >> > > RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x >> > > controllers please test and report how the diff works for you. >> > > Thanks. >> > >> > http://people.freebsd.org/~yongari/alc/pci.quirk.diff >> > http://people.freebsd.org/~yongari/alc/alc.diff.20141001 >> > >> > Patch updated to address link establishment issue. >> >> http://people.freebsd.org/~yongari/alc/alc.diff.20141002 >> Patch updated again to correct wrong lock assertion. > > FYI: I've committed all the changes required to support > AR816x/AR817x. Cool! Working fine with AR8161 on Gigabyte H87N-Wifi Mobo! Thanks! > ___ > 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: Voxer using FreeBSD, BSDNow.tv interview
On Mon, Oct 20, 2014 at 09:13:35PM +0200, Rainer Duffner wrote: > >> > > Yes that is the job of the maintainer, so bugging the chef maintainer is the > > right thing to do. > > > > Maintaining a port meaning making sure it workds properly the FreeBSD way. > > > The omnibus installer is not a port. > AFAIK. > It’s the installer provided by Chef (the company, formerly known as > „Opscode“). > > It’s basically a shell-script with an archive attached that dumps stuff into > /opt/chef and creates a couple of symlinks. > > > Well that is the problem, I know a couple of people using chef from ports on freebsd just fine on some large deployments, that explains why I got surprised by this feedback Bapt pgpP1FRXJdX8W.pgp Description: PGP signature
Re: Voxer using FreeBSD, BSDNow.tv interview
>> > Yes that is the job of the maintainer, so bugging the chef maintainer is the > right thing to do. > > Maintaining a port meaning making sure it workds properly the FreeBSD way. The omnibus installer is not a port. AFAIK. It’s the installer provided by Chef (the company, formerly known as „Opscode“). It’s basically a shell-script with an archive attached that dumps stuff into /opt/chef and creates a couple of symlinks. ___ 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: Voxer using FreeBSD, BSDNow.tv interview
On Mon, Oct 20, 2014 at 02:49:31PM -0400, Nikolai Lifanov wrote: > On 10/20/14 14:43, Baptiste Daroussin wrote: > > On Mon, Oct 20, 2014 at 02:33:20PM -0400, Nikolai Lifanov wrote: > >> On 10/20/14 13:36, Rainer Duffner wrote: > >>> > Am 20.10.2014 um 10:19 schrieb David Chisnall : > > > I presume that most of the relevant differences are for users / > developers and not sysadmins? It's worth noting that GNU coreutils, > tar, bash, and a load of other things are in the ports repository. I > wonder if it's worth having a gnu-userland metaport, perhaps with > something like the Solaris approach of sticking them all in a different > tree so that you can just add that to the start of your PATH and have > all of the GNU tools work by default. > > >>> > >>> > >>> They use chef. > >>> The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD > >>> version of it. Well, it least it did the last time I looked. Maybe this > >>> got fixed in the meantime. > >>> Which means that to „bootstrap“ a node, you’ve first got to install pkg > >>> on it, install bash, symlink it to /bin/bash and then bootstrap the node. > >>> Which kind of runs against the concept of doing everything via chef. > >>> > >>> > >>> > >> > >> Hi from sysutils/ansible maintainer! > >> > >> The ansible port REINPLACE_CMDs away hardcoded paths at build time. This > >> way managing FreeBSD "just works". Maybe chef can benefit from the same > >> approach? > >> > > USES=shebangfix is there exactly for that. > > > > I USES=shebangfix, but it only fixes ~40% of path problems (although in > a very neat and easy to use way). Hardcoded etcdir, module directory, > man pages, etc. also need to be changed. > Yes that is the job of the maintainer, so bugging the chef maintainer is the right thing to do. Maintaining a port meaning making sure it workds properly the FreeBSD way. regards, Bapt pgpxbmoHXW7px.pgp Description: PGP signature
Re: Voxer using FreeBSD, BSDNow.tv interview
On 10/20/14 14:43, Baptiste Daroussin wrote: > On Mon, Oct 20, 2014 at 02:33:20PM -0400, Nikolai Lifanov wrote: >> On 10/20/14 13:36, Rainer Duffner wrote: >>> Am 20.10.2014 um 10:19 schrieb David Chisnall : I presume that most of the relevant differences are for users / developers and not sysadmins? It's worth noting that GNU coreutils, tar, bash, and a load of other things are in the ports repository. I wonder if it's worth having a gnu-userland metaport, perhaps with something like the Solaris approach of sticking them all in a different tree so that you can just add that to the start of your PATH and have all of the GNU tools work by default. >>> >>> >>> They use chef. >>> The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD >>> version of it. Well, it least it did the last time I looked. Maybe this got >>> fixed in the meantime. >>> Which means that to „bootstrap“ a node, you’ve first got to install pkg on >>> it, install bash, symlink it to /bin/bash and then bootstrap the node. >>> Which kind of runs against the concept of doing everything via chef. >>> >>> >>> >> >> Hi from sysutils/ansible maintainer! >> >> The ansible port REINPLACE_CMDs away hardcoded paths at build time. This >> way managing FreeBSD "just works". Maybe chef can benefit from the same >> approach? >> > USES=shebangfix is there exactly for that. > I USES=shebangfix, but it only fixes ~40% of path problems (although in a very neat and easy to use way). Hardcoded etcdir, module directory, man pages, etc. also need to be changed. > 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: Voxer using FreeBSD, BSDNow.tv interview
On Mon, Oct 20, 2014 at 02:33:20PM -0400, Nikolai Lifanov wrote: > On 10/20/14 13:36, Rainer Duffner wrote: > > > >> Am 20.10.2014 um 10:19 schrieb David Chisnall : > >> > >> > >> I presume that most of the relevant differences are for users / developers > >> and not sysadmins? It's worth noting that GNU coreutils, tar, bash, and a > >> load of other things are in the ports repository. I wonder if it's worth > >> having a gnu-userland metaport, perhaps with something like the Solaris > >> approach of sticking them all in a different tree so that you can just add > >> that to the start of your PATH and have all of the GNU tools work by > >> default. > >> > > > > > > They use chef. > > The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD > > version of it. Well, it least it did the last time I looked. Maybe this got > > fixed in the meantime. > > Which means that to „bootstrap“ a node, you’ve first got to install pkg on > > it, install bash, symlink it to /bin/bash and then bootstrap the node. > > Which kind of runs against the concept of doing everything via chef. > > > > > > > > Hi from sysutils/ansible maintainer! > > The ansible port REINPLACE_CMDs away hardcoded paths at build time. This > way managing FreeBSD "just works". Maybe chef can benefit from the same > approach? > USES=shebangfix is there exactly for that. regards, Bapt pgp1hYCQHvSHs.pgp Description: PGP signature
Re: Voxer using FreeBSD, BSDNow.tv interview
On 10/20/14 13:36, Rainer Duffner wrote: > >> Am 20.10.2014 um 10:19 schrieb David Chisnall : >> >> >> I presume that most of the relevant differences are for users / developers >> and not sysadmins? It's worth noting that GNU coreutils, tar, bash, and a >> load of other things are in the ports repository. I wonder if it's worth >> having a gnu-userland metaport, perhaps with something like the Solaris >> approach of sticking them all in a different tree so that you can just add >> that to the start of your PATH and have all of the GNU tools work by >> default. >> > > > They use chef. > The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD > version of it. Well, it least it did the last time I looked. Maybe this got > fixed in the meantime. > Which means that to „bootstrap“ a node, you’ve first got to install pkg on > it, install bash, symlink it to /bin/bash and then bootstrap the node. > Which kind of runs against the concept of doing everything via chef. > > > Hi from sysutils/ansible maintainer! The ansible port REINPLACE_CMDs away hardcoded paths at build time. This way managing FreeBSD "just works". Maybe chef can benefit from the same approach? - Nikolai Lifanov ___ 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: ssh None cipher
On Sat, Oct 18, 2014 at 12:10:28AM -0400, Allan Jude wrote: > On 2014-10-17 22:43, Benjamin Kaduk wrote: > > On Fri, 17 Oct 2014, Ben Woods wrote: > > > >> Whilst trying to replicate data from my FreeNAS to my FreeBSD home theater > >> PC on my local LAN, I came across this bug preventing use of the None > >> cipher: > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163127 > >> > >> I think I could enable the None cipher by recompiling base with a flag in > >> /etc/src.conf. > > > > I agree. > > > >> Is there any harm in enabling this by default, but having the None cipher > >> remain disabled in /etc/ssh/sshd_config? That way people wouldn't have it > >> on my default, but wouldn't have to recompile to enable it. > > > > I do not see any immediate and concrete harm that doing so would cause, > > yet that is insufficient for me to think that doing so would be a good > > idea. > > I've been using openssh-portable from ports with the none cipher patch > to get around this. > > IIRC, upstream openssh refuses to merge the none cipher patches "because > you shouldn't do that". But I'd vote for having it compiled in and just > disabled by default. > > It will refuse to let you have a shell without encryption, and prints a > big fat hairy warning when encryption is disabled. When Bjoern and I did the merge of the HPN patches we left None disable by default out of a desire to be conservative with a change we knew some people didn't like. I think turning it on by default would be fine given the seatbelts in place to prevent accidental inappropriate use. -- Brooks pgphyLtTmkQdL.pgp Description: PGP signature
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Sat, Oct 18, 2014 at 02:58:57PM +0900, Tomoaki AOKI wrote: > I think the advantages of the forum are... > > *Well moderated by moderators and anministrators. > *Registering email address is needed, but not disclosed by default. The disadvantages of web fora include: * I can't read things in my very efficient email client. Related: * I have to compose my replies in a web browser edit window. * I need to visit periodically and hope that the site makes it possible for me to attend to unread messages without struggling. I think wikis are useful. I think web fora exist because folks haven't had sufficient exposure to email to make the advantages clear. Not discussed here are newsgroups, which are perhaps ideal for the sorts of topics commonly found on mailing lists, except perhaps that they're not at all centralized. -- Mason Loring Bliss (( "In the drowsy dark cave of the mind dreams ma...@blisses.org )) build their nest with fragments dropped http://blisses.org/ (( from day's caravan." - Rabindranath Tagore ___ 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: Voxer using FreeBSD, BSDNow.tv interview
> Am 20.10.2014 um 10:19 schrieb David Chisnall : > > > I presume that most of the relevant differences are for users / developers > and not sysadmins? It's worth noting that GNU coreutils, tar, bash, and a > load of other things are in the ports repository. I wonder if it's worth > having a gnu-userland metaport, perhaps with something like the Solaris > approach of sticking them all in a different tree so that you can just add > that to the start of your PATH and have all of the GNU tools work by default. > > They use chef. The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD version of it. Well, it least it did the last time I looked. Maybe this got fixed in the meantime. Which means that to „bootstrap“ a node, you’ve first got to install pkg on it, install bash, symlink it to /bin/bash and then bootstrap the node. Which kind of runs against the concept of doing everything via chef. ___ 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: Voxer using FreeBSD, BSDNow.tv interview
On 19 October 2014 18:09, Craig Rodrigues wrote: > Hi, > > If you don't watch BSDNow.tv ( http://bsdnow.tv ), I encourage you to do so. > Allan Jude and Kris Moore do a great job of doing a weekly video podcast > of news in the BSD world. It is great stuff. > > In episode 58 ( http://www.bsdnow.tv/episodes/2014_10_08-behind_the_masq ) > BSDNow interviewed the CTO of Voxer ( http://voxer.com ), > a mobile messaging startup based in San Francisco. Thanks for linking to this Craig - it's a good interview. As always the whole BSDNow.tv episode is interesting, but if anyone wants to jump right to this interview it starts at 14:44. ___ 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"
Jenkins, Kyua, and Bhyve used for FreeBSD OS testing
Hi, FYI, Kohsuke Kawaguchi, the lead developer of Jenkins, accepted my posting on the Jenkins blog, which describes how the FreeBSD project is using Jenkins, Kyua, and Bhyve for FreeBSD OS testing: http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testing -- Craig ___ 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: kernel page fault with nfs
Tobias C. Berner wrote: > Now that I posted it, 32767 should of course be 2^15=32768. Let me > recheck if it still > hangs with the correct value. > > On Monday 20 October 2014 09.15:39 Tobias C. Berner wrote: > > Hi Marcelo > > > > Yes, I'm using readahead: > > The mountoptions are > > "readahead=4,soft,intr,rw,tcp,wsize=32767,rsize=32767,late" > > If you type "nfsstat -m", you will see what is actually getting used. (I suspect the above rsize/wsize got clipped to 32256 or something like that. I think it clips it to a multiple of 512.) If rsize/wsize are not a power of 2, there are issues, although I've never been able to see why it is broken. Maybe it should clip it to the power of 2 below the value, since it causes unexplained problems otherwise. rick > > > > mfg Tobias > > > > On Monday 20 October 2014 10.41:30 Marcelo Araujo wrote: > > > Hello Tobias, > > > > > > Could you show how you are mount the NFS share? > > > Are you using 'readahead' option? > > > > > > Best Regards, > > > > > > 2014-10-19 17:40 GMT+08:00 Tobias C. Berner : > > > > both are at 1100038. > > > > > > > > On Sunday 19 October 2014 11.12:36 Marcelo Araujo wrote: > > > > > It is still strange, could you do what Allan said and send us > > > > > the > > > > > result > > > > > > > > in > > > > > > > > > case you are not sure you have world and kernel in the same > > > > > revision! > > > > > > > > > > On Oct 19, 2014 6:48 AM, "Tobias C. Berner" > > > > > wrote: > > > > > > Hi > > > > > > > > > > > > World ist from october 16, installed world and kernel then. > > > > > > > > > > > > Kernel was later rebuilt with debug-options. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is the following more sensible? > > > > > > > > > > > > > ## > > > > > > > > > > > > # kgdb NOXON/kernel.debug vmcore.1 > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > > > > > > > cpuid = 5; apic id = 05 > > > > > > > > > > > > fault virtual address = 0xfe07d1744000 > > > > > > > > > > > > fault code = supervisor write data, page not present > > > > > > > > > > > > instruction pointer = 0x20:0x80d4d58a > > > > > > > > > > > > stack pointer = 0x28:0xfe086057f240 > > > > > > > > > > > > frame pointer = 0x28:0xfe086057f2f0 > > > > > > > > > > > > code segment = base 0x0, limit 0xf, type 0x1b > > > > > > > > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > > > > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > > > > > > > > current process = 6524 (python2.7) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (kgdb) bt > > > > > > > > > > > > #0 doadump (textdump=1) at pcpu.h:219 > > > > > > > > > > > > #1 0x80926b6d in kern_reboot (howto=260) at > > > > > > /usr/src/sys/kern/kern_shutdown.c:447 > > > > > > > > > > > > #2 0x809270c0 in panic (fmt=) > > > > > > at > > > > > > /usr/src/sys/kern/kern_shutdown.c:746 > > > > > > > > > > > > #3 0x8035f167 in db_panic (addr= > > > > > out>, > > > > > > have_addr=2, count=0, modif=0x0) at > > > > > > /usr/src/sys/ddb/db_command.c:473 > > > > > > > > > > > > #4 0x8035ed7d in db_command (cmd_table=0x0) at > > > > > > /usr/src/sys/ddb/db_command.c:440 > > > > > > > > > > > > #5 0x8035eaf4 in db_command_loop () at > > > > > > /usr/src/sys/ddb/db_command.c:493 > > > > > > > > > > > > #6 0x80361600 in db_trap (type= > > > > > out>, > > > > > > code=0) > > > > > > > > at > > > > > > > > > > /usr/src/sys/ddb/db_main.c:251 > > > > > > > > > > > > #7 0x80966f01 in kdb_trap (type=12, code=0, > > > > > > tf= > > > > > optimized > > > > > > out>) at /usr/src/sys/kern/subr_kdb.c:654 > > > > > > > > > > > > #8 0x80d4fa7c in trap_fatal > > > > > > (frame=0xfe086057f190, > > > > > > > > eva= > > > > > > > > > optimized out>) at /usr/src/sys/amd64/amd64/trap.c:861 > > > > > > > > > > > > #9 0x80d4fe0c in trap_pfault > > > > > > (frame=0xfe086057f190, > > > > > > usermode=) at > > > > > > /usr/src/sys/amd64/amd64/trap.c:677 > > > > > > > > > > > > #10 0x80d4f42e in trap (frame=0xfe086057f190) > > > > > > at > > > > > > /usr/src/sys/amd64/amd64/trap.c:426 > > > > > > > > > > > > #11 0x80d33972 in calltrap () at > > > > > > /usr/src/sys/amd64/amd64/exception.S:231 > > > > > > > > > > > > #12 0x80d4d58a in bzero () at > > > > > > /usr/src/sys/amd64/amd64/support.S:53 > > > > > > > > > > > > #13 0x80830463 in ncl_doio (vp=0xf801e7f99938, > > > > > > bp=0xfe07c5a168e8, cr=, td= > > > > > optimized > > > > > > > > out>, > > > > > > > > > > called_from_strategy=) > > > > > > > > > > > > at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1648 > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To
Re: vt_suspend / vt_resume
On 09.10.2014 17:09, Andriy Gapon wrote: > I looked at the vt code and I was not able to figure out what would be the > proper place there. > Initially I thought that vt_allocate() would be it, but then it seems that > vt_allocate() might not be called. So, perhaps vtterm_cnprobe() ? Something > else? What about vt_upgrade()? It's called later in the boot process: /* Delay until all devices attached, to not waste time. */ SYSINIT(vt_early_cons, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_ANY, vt_upgrade, &vt_consdev); However, it's called from vt_allocate() too, so you would need a flag in struct vd_device->vd_flags to record the fact the handlers are registered. The core handlers would then call backend-specific handlers, if the backend provides them. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: at - atrun utility bug on 10.0
On Sun, Oct 19, 2014 at 10:53:35AM -0700, Jim Pazarena wrote: > I find that while a job is running via the at facility, that is, > atrun has executed it, every subsequent execution of atrun (via > cron) STAYS running while the original program (executed by atrun) > is still active. > > Generally, according to the docs, atrun is executed every 5 minutes > */5 * * * * within /etc/crontab > I always modify this to * * * * * for more prompt at execution. > > I have jobs submitted via 'at' which tend to run for several hours > sometimes even all day. > If I do a 'ps wwax' I could see dozens, hundreds, even thousands > of "atrun" running. > When the original job completes all the "atrun"s disappear. > I noticed this on 10.0, where on 9.1 it simply does not happen. > > It is my feeling that the atrun on 10.0 is either being held up by > a lock fyl, an flock, or something else which is blocking its > normal termination when there is an empty queue, or rather when > there is an item in the queue which is already being tended to > by another process. > > I would think that the general */5 granularity of atrun, along with > most jobs NOT running for multiple hours tends to obfuscate this > (what I think is a) bug. And most people looking at an wwax would > skip past it without giving it any thought. > > If anyone could confirm that I am not going insane, I would file a > bug report thru normal channels. Of course, I may be going insane > regardless of THIS email :-) I doubt that port people can help you. What version of FreeBSD do you run, exactly ? It is 10.0 or stable/10 ? It seems that your observations are sound, and your trouble is caused by HEAD r251625. OTOH, it seems that HEAD r264617, merged to stable/10 as r265368, fixed something which is described very similar to the bug you hit. ___ 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 && TCP stealth
El día Monday, October 20, 2014 a las 09:25:28AM +0200, Matthias Apitz escribió: > > Hello, > > Is there any work started or in progress to implement TCP stealth in our > kernel as proposed to IETF in > > https://datatracker.ietf.org/doc/draft-kirsch-ietf-tcp-stealth/ > > The idea is that the client put some magic value in the ISN of the first > SYN pkg which is derived from a secret the client and the server share. > The server can check the ISN and decide if it will answer the SYN pkg or > do a RST, for example. For Linux wip see also: https://gnunet.org/knock matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: Voxer using FreeBSD, BSDNow.tv interview
On 19 Oct 2014, at 23:09, Craig Rodrigues wrote: > (2) Most devops engineers in web/mobile companies are familiar with >Linux. Any differences between Linux and FreeBSD in > command-line >utilities are not show-stoppers, but they are annoyances. >Anything FreeBSD could do to help people used to Linux would be > a big >help. Allan Jude even brought up my request to symlink > /bin/bash ( > https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095483.html > ) :) I presume that most of the relevant differences are for users / developers and not sysadmins? It's worth noting that GNU coreutils, tar, bash, and a load of other things are in the ports repository. I wonder if it's worth having a gnu-userland metaport, perhaps with something like the Solaris approach of sticking them all in a different tree so that you can just add that to the start of your PATH and have all of the GNU tools work by default. David ___ 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: kernel page fault with nfs
Now that I posted it, 32767 should of course be 2^15=32768. Let me recheck if it still hangs with the correct value. On Monday 20 October 2014 09.15:39 Tobias C. Berner wrote: > Hi Marcelo > > Yes, I'm using readahead: > The mountoptions are > "readahead=4,soft,intr,rw,tcp,wsize=32767,rsize=32767,late" > > > mfg Tobias > > On Monday 20 October 2014 10.41:30 Marcelo Araujo wrote: > > Hello Tobias, > > > > Could you show how you are mount the NFS share? > > Are you using 'readahead' option? > > > > Best Regards, > > > > 2014-10-19 17:40 GMT+08:00 Tobias C. Berner : > > > both are at 1100038. > > > > > > On Sunday 19 October 2014 11.12:36 Marcelo Araujo wrote: > > > > It is still strange, could you do what Allan said and send us the > > > > result > > > > > > in > > > > > > > case you are not sure you have world and kernel in the same revision! > > > > > > > > On Oct 19, 2014 6:48 AM, "Tobias C. Berner" wrote: > > > > > Hi > > > > > > > > > > World ist from october 16, installed world and kernel then. > > > > > > > > > > Kernel was later rebuilt with debug-options. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is the following more sensible? > > > > > > > > > > ## > > > > > > > > > > # kgdb NOXON/kernel.debug vmcore.1 > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > > > > > cpuid = 5; apic id = 05 > > > > > > > > > > fault virtual address = 0xfe07d1744000 > > > > > > > > > > fault code = supervisor write data, page not present > > > > > > > > > > instruction pointer = 0x20:0x80d4d58a > > > > > > > > > > stack pointer = 0x28:0xfe086057f240 > > > > > > > > > > frame pointer = 0x28:0xfe086057f2f0 > > > > > > > > > > code segment = base 0x0, limit 0xf, type 0x1b > > > > > > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > > > > > > current process = 6524 (python2.7) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (kgdb) bt > > > > > > > > > > #0 doadump (textdump=1) at pcpu.h:219 > > > > > > > > > > #1 0x80926b6d in kern_reboot (howto=260) at > > > > > /usr/src/sys/kern/kern_shutdown.c:447 > > > > > > > > > > #2 0x809270c0 in panic (fmt=) at > > > > > /usr/src/sys/kern/kern_shutdown.c:746 > > > > > > > > > > #3 0x8035f167 in db_panic (addr=, > > > > > have_addr=2, count=0, modif=0x0) at > > > > > /usr/src/sys/ddb/db_command.c:473 > > > > > > > > > > #4 0x8035ed7d in db_command (cmd_table=0x0) at > > > > > /usr/src/sys/ddb/db_command.c:440 > > > > > > > > > > #5 0x8035eaf4 in db_command_loop () at > > > > > /usr/src/sys/ddb/db_command.c:493 > > > > > > > > > > #6 0x80361600 in db_trap (type=, > > > > > code=0) > > > > > > at > > > > > > > > /usr/src/sys/ddb/db_main.c:251 > > > > > > > > > > #7 0x80966f01 in kdb_trap (type=12, code=0, tf= > > > > optimized > > > > > out>) at /usr/src/sys/kern/subr_kdb.c:654 > > > > > > > > > > #8 0x80d4fa7c in trap_fatal (frame=0xfe086057f190, > > > > > > eva= > > > > > > > optimized out>) at /usr/src/sys/amd64/amd64/trap.c:861 > > > > > > > > > > #9 0x80d4fe0c in trap_pfault (frame=0xfe086057f190, > > > > > usermode=) at > > > > > /usr/src/sys/amd64/amd64/trap.c:677 > > > > > > > > > > #10 0x80d4f42e in trap (frame=0xfe086057f190) at > > > > > /usr/src/sys/amd64/amd64/trap.c:426 > > > > > > > > > > #11 0x80d33972 in calltrap () at > > > > > /usr/src/sys/amd64/amd64/exception.S:231 > > > > > > > > > > #12 0x80d4d58a in bzero () at > > > > > /usr/src/sys/amd64/amd64/support.S:53 > > > > > > > > > > #13 0x80830463 in ncl_doio (vp=0xf801e7f99938, > > > > > bp=0xfe07c5a168e8, cr=, td= > > > > > out>, > > > > > > > > called_from_strategy=) > > > > > > > > > > at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1648 ___ 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 && TCP stealth
Hello, Is there any work started or in progress to implement TCP stealth in our kernel as proposed to IETF in https://datatracker.ietf.org/doc/draft-kirsch-ietf-tcp-stealth/ The idea is that the client put some magic value in the ISN of the first SYN pkg which is derived from a secret the client and the server share. The server can check the ISN and decide if it will answer the SYN pkg or do a RST, for example. Vy 73 matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: kernel page fault with nfs
Hi Marcelo Yes, I'm using readahead: The mountoptions are "readahead=4,soft,intr,rw,tcp,wsize=32767,rsize=32767,late" mfg Tobias On Monday 20 October 2014 10.41:30 Marcelo Araujo wrote: > Hello Tobias, > > Could you show how you are mount the NFS share? > Are you using 'readahead' option? > > Best Regards, > > 2014-10-19 17:40 GMT+08:00 Tobias C. Berner : > > both are at 1100038. > > > > On Sunday 19 October 2014 11.12:36 Marcelo Araujo wrote: > > > It is still strange, could you do what Allan said and send us the result > > > > in > > > > > case you are not sure you have world and kernel in the same revision! > > > > > > On Oct 19, 2014 6:48 AM, "Tobias C. Berner" wrote: > > > > Hi > > > > > > > > World ist from october 16, installed world and kernel then. > > > > > > > > Kernel was later rebuilt with debug-options. > > > > > > > > > > > > > > > > > > > > > > > > Is the following more sensible? > > > > > > > > ## > > > > > > > > # kgdb NOXON/kernel.debug vmcore.1 > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > > > cpuid = 5; apic id = 05 > > > > > > > > fault virtual address = 0xfe07d1744000 > > > > > > > > fault code = supervisor write data, page not present > > > > > > > > instruction pointer = 0x20:0x80d4d58a > > > > > > > > stack pointer = 0x28:0xfe086057f240 > > > > > > > > frame pointer = 0x28:0xfe086057f2f0 > > > > > > > > code segment = base 0x0, limit 0xf, type 0x1b > > > > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > > > > current process = 6524 (python2.7) > > > > > > > > > > > > > > > > > > > > > > > > (kgdb) bt > > > > > > > > #0 doadump (textdump=1) at pcpu.h:219 > > > > > > > > #1 0x80926b6d in kern_reboot (howto=260) at > > > > /usr/src/sys/kern/kern_shutdown.c:447 > > > > > > > > #2 0x809270c0 in panic (fmt=) at > > > > /usr/src/sys/kern/kern_shutdown.c:746 > > > > > > > > #3 0x8035f167 in db_panic (addr=, > > > > have_addr=2, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:473 > > > > > > > > #4 0x8035ed7d in db_command (cmd_table=0x0) at > > > > /usr/src/sys/ddb/db_command.c:440 > > > > > > > > #5 0x8035eaf4 in db_command_loop () at > > > > /usr/src/sys/ddb/db_command.c:493 > > > > > > > > #6 0x80361600 in db_trap (type=, code=0) > > > > at > > > > > > /usr/src/sys/ddb/db_main.c:251 > > > > > > > > #7 0x80966f01 in kdb_trap (type=12, code=0, tf= > > > optimized > > > > out>) at /usr/src/sys/kern/subr_kdb.c:654 > > > > > > > > #8 0x80d4fa7c in trap_fatal (frame=0xfe086057f190, > > > > eva= > > > > > optimized out>) at /usr/src/sys/amd64/amd64/trap.c:861 > > > > > > > > #9 0x80d4fe0c in trap_pfault (frame=0xfe086057f190, > > > > usermode=) at /usr/src/sys/amd64/amd64/trap.c:677 > > > > > > > > #10 0x80d4f42e in trap (frame=0xfe086057f190) at > > > > /usr/src/sys/amd64/amd64/trap.c:426 > > > > > > > > #11 0x80d33972 in calltrap () at > > > > /usr/src/sys/amd64/amd64/exception.S:231 > > > > > > > > #12 0x80d4d58a in bzero () at > > > > /usr/src/sys/amd64/amd64/support.S:53 > > > > > > > > #13 0x80830463 in ncl_doio (vp=0xf801e7f99938, > > > > bp=0xfe07c5a168e8, cr=, td= > > > out>, > > > > > > called_from_strategy=) > > > > > > > > at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1648 > > > > > > > > #14 0x80831acf in ncl_write (ap=) at > > > > /usr/src/sys/fs/nfsclient/nfs_clbio.c:1124 > > > > > > > > #15 0x80e646a5 in VOP_WRITE_APV (vop=, > > > > a=) at vnode_if.c:997 > > > > > > > > #16 0x809f52f9 in vn_write (fp=0xf80101c62780, > > > > uio=0xfe086057f970, active_cred=, flags=320, > > > > td=0x0) at vnode_if.h:413 > > > > > > > > #17 0x809f5602 in vn_io_fault_doio (args= > > > out>, > > > > uio=0xa00, td=0x0) at /usr/src/sys/kern/vfs_vnops.c:991 > > > > > > > > #18 0x809f2aec in vn_io_fault1 () at > > > > /usr/src/sys/kern/vfs_vnops.c:1047 > > > > > > > > #19 0x809f0e3b in vn_io_fault (fp=0xf80101c62780, > > > > uio=0xfe086057f970, active_cred=, flags=0, > > > > td=0xf80171d79920) > > > > > > > > at /usr/src/sys/kern/vfs_vnops.c:1152 > > > > > > > > #20 0x80982357 in dofilewrite (td=0xf80171d79920, fd=19, > > > > fp=0xf80101c62780, auio=0xfe086057f970, offset= > > > optimized > > > > out>, flags=0) at file.h:306 > > > > > > > > #21 0x80982088 in kern_writev (td=0xf80171d79920, fd=19, > > > > auio=0xfe086057f970) at /usr/src/sys/kern/sys_generic.c:467 > > > > > > > > #22 0x80982013 in sys_write (td=, > > > > uap= > > > > > optimized out>) at /usr/src/sys/kern/sys_generic.c:382 > > > > > > > > #23 0x80d5051b in amd64_syscall (td=0xf80171d79920, > > > > traced=0) > > > > > > at subr_syscall.
