Jenkins build is back to normal : FreeBSD_HEAD #2755
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2755/ ___ 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: What to do about RCS/OpenRCS
On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: Maybe off-topic, but functionality-wise it might make much more sense to import Fossil. RCS has too many limitations this day and age when better tools are available. Of course, this would require people to learn something new, which I know can be a challenge. I really like fossil. But it's still under development, so it would soon be outdated. It's better installed from ports/packages. pgpdrB812fhDT.pgp Description: PGP signature
Jenkins build became unstable: FreeBSD_HEAD-tests2 #1025
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/1025/ ___ 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: What to do about RCS/OpenRCS
On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote: On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: Maybe off-topic, but functionality-wise it might make much more sense to import Fossil. RCS has too many limitations this day and age when better tools are available. Of course, this would require people to learn something new, which I know can be a challenge. I really like fossil. But it's still under development, so it would soon be outdated. It's better installed from ports/packages. It seems OpenRCS is still under development ;-p It's better installed from ports/packages, too. It would give Fossil a recognition boost as a BSD-licensed DVCS. Jos ___ 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: nmount, mountd drops high order MNT_xx flags during a mount update
On Sun, 2015-05-10 at 09:07 -0400, Rick Macklem wrote: Oops, I did my usual and forgot to attach the patch. Here it is, rick - Original Message - Doug Rabson wrote: You could add a single integer-valued vfsopt which holds the high-order bits of f_flags? I have created a patch that does this. It is on https://reviews.freebsd.org/D2506 (I have also attached it here, for those who don't use Phabricator.) Please review/comment on this. (Feel free to add yourself as a reviewer, etc.) Also, David, if you can test this patch, it would be appreciated. Thanks for the suggestion Doug, rick On 7 May 2015 at 02:10, Rick Macklem rmack...@uoguelph.ca wrote: David Boyd reported a problem to freebsd-current@ w.r.t. the MNT_AUTOMOUNTED flag getting cleared by mountd. http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel I just took a look at this and it's kinda ugly... mountd acquires a list of mounts via getmntinfo() and then does an nmount() for each of them to get rid of any exports. It uses f_flags from the statfs returned by getmntinfo() as the 3rd argument to nmount(). -- Since nmount()s 3rd argument is a int, it silently drops any MNT_xx flag in the high order 32bits of f_flags. At this time, it happens that MNT_AUTOMOUNTED is the only one, but... I can think of a couple of ways to fix this, but I don't like any of them;-) 1) I suppose mountd could check for each flag set in f_flags and generate a vfsopts string for it, but that means that every time a new flag that can be updated is added to MNT_xx, this mountd.c code would have to updated. -- Ugly!! 2) Require that all flags in MNT_UPDATEMASK be in the low order 32bits. I wouldn`t mind this except in means that the MNT_xx flags must be redefined and I don`t think that could get MFC`d. 3) Add a new newernmount(2) which has a 64bit flags argument instead of int. Hopefully someone can think of a nice way to fix this, rick ___ 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 ___ 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 Rick, Edward, et al, I have applied your patches to several (four) servers and have not noticed any more instances of the errant behavior. I think (hope) that this is the correct fix and wonder if this fix might make it's way into an errata. Thanks for the quick responses. David Boyd. ___ 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 build is still unstable: FreeBSD_HEAD-tests2 #1026
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/1026/ ___ 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: What to do about RCS/OpenRCS
On Mon, May 11, 2015 at 09:12:57AM -0700, Jos Backus wrote: On May 11, 2015 9:10 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote: On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote: On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: Maybe off-topic, but functionality-wise it might make much more sense to import Fossil. RCS has too many limitations this day and age when better tools are available. Of course, this would require people to learn something new, which I know can be a challenge. I really like fossil. But it's still under development, so it would soon be outdated. It's better installed from ports/packages. It seems OpenRCS is still under development ;-p It's better installed from ports/packages, too. It would give Fossil a recognition boost as a BSD-licensed DVCS. Please, just stop. Thanks. Like I said, a challenge. You've completely missed the point. OpenRCS is intended to replace ancient GNU RCS, which is already included in the base system and used by a few scripts. Fossil is not a drop-in replacement for the rcs utilities. So, please just stop. PS: Please reply to the list not directly to me. CC stored. -- Steve ___ 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 build is back to stable : FreeBSD_HEAD-tests2 #1027
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/1027/ ___ 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: Race VT+X11 on -current
On 10 May 2015 at 13:14, Hans Petter Selasky h...@selasky.org wrote: Your patch is correct from what I can see. Signed modulus can be creepy sometimes! Better if VT_MAXWINDOWS was power of two and we used a bitwise AND. The patch is correct, although signedness doesn't come into play. The unsigned vw_number just wraps to 2^32-1, which is 3 modulo 12. ___ 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
Increase BUFSIZ to 8192
Hi, I would like to change the default value of BUFSIZ to 8192. After testing various applications that uses BUFSIZ like changing it in libmd I can often see performance improvements: For example with md5(1): Current BUFSIZ (1024) 0.13 real 0.04 user 0.09 sys New BUFSIZ (8192) 0.08 real 0.04 user 0.03 sys sha256(1): Before: 0.44 real 0.39 user 0.04 sys After: 0.37 real 0.35 user 0.01 sys This is done on a small amd64 Lenovo S20 laptop Review available here: https://reviews.freebsd.org/D2515 Any opinion? Best regards, Bapt pgp13koZsDgjw.pgp Description: PGP signature
Re: Increase BUFSIZ to 8192
So I'm curious - why's it faster? -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: Increase BUFSIZ to 8192
Baptiste Daroussin wrote this message on Tue, May 12, 2015 at 01:06 +0200: I would like to change the default value of BUFSIZ to 8192. After testing various applications that uses BUFSIZ like changing it in libmd I can often see performance improvements: For example with md5(1): Current BUFSIZ (1024) 0.13 real 0.04 user 0.09 sys New BUFSIZ (8192) 0.08 real 0.04 user 0.03 sys sha256(1): Before: 0.44 real 0.39 user 0.04 sys After: 0.37 real 0.35 user 0.01 sys This is done on a small amd64 Lenovo S20 laptop Review available here: https://reviews.freebsd.org/D2515 personally, I think the applications that are abusing BUFSIZ should be fixed to use a properly sized buffer for their applications... BUFSIZ is defined for the default stdio buffer sizes... I got significant perf improvement many years ago by fixed lpd to use a sane BUFSIZ... And did the same recently w/ nc (bumping from 2k to 16k, though I'd'f liked to go larger)... Also, you'd probably see even better performance by increasing the size to 64k, though as with all things, this means more memory use on smaller systems (though on smaller/slower systems, this may be an even bigger win)... This mostly just reduces number of context switches... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: Turbulence in head @r282676.
On Mon, May 11, 2015 at 11:17:03AM -0500, Mark Felder wrote: On Sun, May 10, 2015, at 12:39, Alan Cox wrote: This is fixed in r282706. The r282694 snapshots (amd64 at least) are useless because of this bug and was causing me constant crashing. ... On a positive note, my update this morning from r282719 to r282766 for amd64 was sufficiently uneventful to qualify as fairly boring -- which I consider A Good Thing. :-} On a less-positive note, the most recent head/i386 that I have been able to boot was r282623 -- r282676, r282719, and r282766 all panic in the HDA device attach code with: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex hdac1 (HDA driver mutex) r = 0 (0xcfef... src/sys/dev/sound/pci/hda/hdaa.c:1571 as cited in http://docs.FreeBSD.org/cgi/mid.cgi?20150509142751.GV1158. Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp99fHgG93DW.pgp Description: PGP signature
Re: What to do about RCS/OpenRCS
On Mon, 2015-05-11 at 09:27 -0700, Jos Backus wrote: On May 11, 2015 9:21 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 11, 2015 at 09:12:57AM -0700, Jos Backus wrote: On May 11, 2015 9:10 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote: On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote: On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: Maybe off-topic, but functionality-wise it might make much more sense to import Fossil. RCS has too many limitations this day and age when better tools are available. Of course, this would require people to learn something new, which I know can be a challenge. I really like fossil. But it's still under development, so it would soon be outdated. It's better installed from ports/packages. It seems OpenRCS is still under development ;-p It's better installed from ports/packages, too. It would give Fossil a recognition boost as a BSD-licensed DVCS. Please, just stop. Thanks. Like I said, a challenge. You've completely missed the point. OpenRCS is intended to replace ancient GNU RCS, which is already included in the base system and used by a few scripts. Fossil is not a drop-in replacement for the rcs utilities. I didn't miss anything. My point is that debating to update one piece of obsolete software with another is silly, and that FreeBSD should try to move forward in this area. But that's hard, as your response indicates. This is the last I'll say about this, because it appears the community isn't ready. Have fun with your ancient version control while Linux continues to grow in market share. :-( So you're saying that it's not that you're missing the point, it's just that you're trolling the list. That will be remembered. (Of course, it's clear to those who've actually read the thread that you are in fact completely missing the point.) -- Ian ___ 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: What to do about RCS/OpenRCS
On May 11, 2015 9:21 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 11, 2015 at 09:12:57AM -0700, Jos Backus wrote: On May 11, 2015 9:10 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote: On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote: On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: Maybe off-topic, but functionality-wise it might make much more sense to import Fossil. RCS has too many limitations this day and age when better tools are available. Of course, this would require people to learn something new, which I know can be a challenge. I really like fossil. But it's still under development, so it would soon be outdated. It's better installed from ports/packages. It seems OpenRCS is still under development ;-p It's better installed from ports/packages, too. It would give Fossil a recognition boost as a BSD-licensed DVCS. Please, just stop. Thanks. Like I said, a challenge. You've completely missed the point. OpenRCS is intended to replace ancient GNU RCS, which is already included in the base system and used by a few scripts. Fossil is not a drop-in replacement for the rcs utilities. I didn't miss anything. My point is that debating to update one piece of obsolete software with another is silly, and that FreeBSD should try to move forward in this area. But that's hard, as your response indicates. This is the last I'll say about this, because it appears the community isn't ready. Have fun with your ancient version control while Linux continues to grow in market share. :-( Jos So, please just stop. PS: Please reply to the list not directly to me. CC stored. -- Steve ___ 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: What to do about RCS/OpenRCS
On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote: On May 11, 2015 2:31 AM, Lars Engels lars.eng...@0x20.net wrote: On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: Maybe off-topic, but functionality-wise it might make much more sense to import Fossil. RCS has too many limitations this day and age when better tools are available. Of course, this would require people to learn something new, which I know can be a challenge. I really like fossil. But it's still under development, so it would soon be outdated. It's better installed from ports/packages. It seems OpenRCS is still under development ;-p It's better installed from ports/packages, too. It would give Fossil a recognition boost as a BSD-licensed DVCS. Please, just stop. Thanks. -- Steve ___ 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: Turbulence in head @r282676.
On Sun, May 10, 2015, at 12:39, Alan Cox wrote: This is fixed in r282706. The r282694 snapshots (amd64 at least) are useless because of this bug and was causing me constant crashing. ___ 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: What to do about RCS/OpenRCS
On May 11, 2015 9:33 AM, David Chisnall thera...@freebsd.org wrote: [snip] And now you’re moving beyond missing the point and just trolling. Thanks for the ad hominen, David. You continue to make my point. Over and out, Jos 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
Weird problem with rand_harvestq
Hi, I am using FreeBSD 10.0-RELEASE #0 r260789. the following lines are a section of ps command out put on my server. as you see in second line rand_harvestq made completely busy one core my four cores CPU . The OS got very slow and top output doesn't show cpu usage . top output last pid: 40488; load averages: 2.57, 0.69, 0.34 up 6+22:29:24 11:38:01 74 processes: 2 running, 72 sleeping CPU: % user, % nice, % system, % interrupt, % idle Mem: 50M Active, 1128M Inact, 718M Wired, 1780K Cache, 622M Buf, 4040M Free Swap: 4096M Total, 4096M Free ps output = USER PID %CPU %MEM VSZ RSS TT STAT STARTEDTIME COMMAND root 11 300.0 0.0 064 - RL Sun01PM 47620:20.47 [idle] root 14 100.0 0.0 016 - DNL Sun01PM 1:29.31 [rand_harvestq] any help would be appreciated. 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
Re: What to do about RCS/OpenRCS
On 11 May 2015, at 17:27, Jos Backus j...@catnook.com wrote: I didn't miss anything. My point is that debating to update one piece of obsolete software with another is silly, and that FreeBSD should try to move forward in this area. But that's hard, as your response indicates. Steve is correct, and you are missing the point. Fossil, Git, Mercurial, and so on are all available as packages. No one is suggesting using RCS in preference to any of them. Deleting RCS from the base system would be nice, but unfortunately we can’t because of scripts that depend on some components of RCS. Replacing these with the OpenRCS equivalents (if they work) would allow us to remove a GPL’d piece of code from the base system. As long as this doesn’t come with a functionality regression, this would be a nice thing to do. Replacing RCS in the base system with Fossil solves no problems that actually exist. It does not allow the scripts that rely on RCS to continue to work and it does not make Fossil easier to use (would you really want to stick with the one in the base system for the entire lifetime of a major release, rather than use the packaged one?). It would only make sense if we were to move FreeBSD development to Fossil and currently there are a few showstoppers in Fossil that prevent this. This is the last I'll say about this, because it appears the community isn't ready. Have fun with your ancient version control while Linux continues to grow in market share. :-( And now you’re moving beyond missing the point and just trolling. 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
