Re: Several minor annoyances on Current
> hm, I have similar experience with 10-stable see > http://lists.freebsd.org/pipermail/freebsd-questions/2014-July/259067.html Thankfully, my boot time is not so severe. I have no ideas to help however. * preventing coredump files: setting in ~/.cshrc below does not work. What is the correct syntax? ulimit -c 0 setenv ulimit -c 0 * What is the error below? Could this output hold clues to finding deeper errors? This occurred during an install requiring opengl, but could Radeon-KMS be a contributing cause? Not running in a graphics capable console, and unable to find one. svgalib: ark: Unknown chiptype 29. Not running in a graphics capable console, and unable to find one. Not running in a graphics capable console, and unable to find one. *** Error code 1 - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5933755.html Sent from the freebsd-current mailing list archive at Nabble.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"
MFC of NFSv4.1 server code?
Hi, There has been little comment w.r.t. the NFSv4.1 server code I dropped into head a month ago. It changes the internal interfaces between the NFS related kernel modules, but I do not believe that these would be considered KPIs. I`d like to MFC it to stable10 for 10.1. Does anyone have a strong opinion on this. Thanks in advance for any comments, 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"
[Video] Upcoming RSS enhancements to the FreeBSD Network Stack
Hi, On July 10, at the Bay Area FreeBSD Users Group ( http://bafug.org ), Adrian Chadd gave a very nice talk: "Upcoming RSS enhancements to the FreeBSD Network Stack" https://www.youtube.com/watch?v=7CvIztTz-RQ Thanks to Adrian for doing the work and giving the talk! Thanks to Cao Pham for recording the video and posting it online! -- 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: BAFUG July 10: libvirt virtualization API for controlling bhyve virtual machines
Hi, Thanks to Cao Pham at iXsystems, video for this presentation has been posted online: https://www.youtube.com/watch?v=LRLV_SZo6Sw -- Craig On Mon, Jun 30, 2014 at 5:30 PM, Craig Rodrigues wrote: > Hi, > > On July 10, 2014, in Mountain View, California, I will be giving a brief > tech talk on: > > "libvirt virtualization API for controlling bhyve virtual machines" > > I have been testing the extensions that Roman Bogorodskiy < > no...@freebsd.org> > has made to the lbivirt library for supporting bhyve. I will talk about > my experiences with libvirt and bhyve. > > Here are more details about the talk plus directions to the location: > > http://www.meetup.com/BAFUG-Bay-Area-FreeBSD-User-Group/events/191061222/ > > Feel free to sign up on the meetup site and attend if you are in the area! > -- > 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: [CFT] Autofs.
On Wed, Jul 30, 2014 at 6:51 PM, Craig Rodrigues wrote: > On Wed, Jul 30, 2014 at 12:19 AM, Edward Tomasz Napierała < > tr...@freebsd.org> wrote: > >> At the link below you will find a patch that adds the new automounter. >> The patch is against yesterdays 11.0-CURRENT. >> >> http://people.freebsd.org/~trasz/autofs-head-20140729.diff >> >> > Hi, > > Nice stuff! I updated a current system, and tried the patch. > I put autofs_enable="YES" in /etc/rc.conf > > In my network, I have a system, testhost with some NFS exports. > > /dir1/export1 > /dir1/export2 > /dir1/export3 > > I did: > > cd /net/testhost > > This operation seemed to timeout. > In dmesg, I saw these errors: > > WARNING: autofs_callout: request 0 for /net/ timed out after 30 seconds > WARNING: autofs_trigger_one: request for /net/ completed with error 60 > autofs_trigger: trigger failed with error 60; will retry in 1 seconds, 2 > attempts left > WARNING: autofs_callout: request 1 for /net/ timed out after 30 seconds > WARNING: autofs_trigger_one: request for /net/ completed with error 60 > autofs_trigger: trigger failed with error 60; will retry in 1 seconds, 1 > attempts left > WARNING: autofs_callout: request 2 for /net/ timed out after 30 seconds > WARNING: autofs_trigger_one: request for /net/ completed with error 60 > autofs_trigger: trigger failed 3 times; returning error 60 > > I used my Mac laptop in the same network, and did: > > cd /net/testhost > > and the command did not timeout, and I could do an ls and see that > /net/testhost/dir1/ was visible. > > Any ideas? > > This is cool stuff, and I hope you can get it into the 10.1 RELEASE. > > -- > Craig > > Hi, I cannot reproduce this problem at all. Now, when I do: cd /net/testhost it "just works", and I can access all the NFS exports. My previous problem might have been due to a temporary networking problem on my side. Yay! The only additional comment that I have for you is that the rc.conf variable is "autofs_enable", but the /etc/rc.d/ scripts are /etc/rc.d/automount and /etc/rc.d/automountd. It's not a big deal, but it would be nice if there was a single /etc/rc.d/autofs script to consolidate all this stuff, that would make it easier for admins to figure out where all the rc.d stuff related to autofs lives. Also, if your rc script introduced an autofs_flags (or automount_flags) variable, so that people could put the "-d" flag in there to enable more automount debugging, that would be nice. Other than that, I would say: Great work! I hope you can get this into 10.1-RELEASE! -- 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: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Jan, On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokemüller wrote: > On 31.07.2014 16:21, Anton Berezin wrote: > >At the console, depressing and holding a key does not lead to auto-repeat. > > > >At the console, sometimes a key only appears on the terminal after another > >key is pressed. > > Maybe this is a problem caused by a misdetected clock source? I've had this > problem as well. > > Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other > settings that are listed in kern.timecounter.choice and > kern.eventtimer.choice, such as HPET which works great for me. Setting both to HPET certainly helped the LA. I cannot check the keyboard input until tomorrow, but chances are that it is indeed the fix. Thanks a bunch! \Anton. -- Our society can survive even a large amount of irrational regulation. -- John McCarthy ___ 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: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi, On 31.07.2014 16:21, Anton Berezin wrote: At the console, depressing and holding a key does not lead to auto-repeat. At the console, sometimes a key only appears on the terminal after another key is pressed. Maybe this is a problem caused by a misdetected clock source? I've had this problem as well. Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other settings that are listed in kern.timecounter.choice and kern.eventtimer.choice, such as HPET which works great for me. Cheers, Jan ___ 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"
Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi, Previously I ran CURRENT from some time in April without any problems. Symptoms: Consistently high LA (2.6 to 8.0) with all CPUs idle. At the console, depressing and holding a key does not lead to auto-repeat. At the console, sometimes a key only appears on the terminal after another key is pressed. In xorg, key auto-repeat sorta works, but visibly slower than active xset settings, and jerky as well. Moving mouse around helps. During reboot, when the kernel prints the number of dirty buffers periodically before shutting down, it "freezes" and does not print the next number until I press a key. So it takes multiple presses of "Shift" or "Control" before it actually boots. Nothing suspicious according to vmstat, vmstat -i, pcmstat, top, top -SH, top -m io. What I tried, by myself and because of various advices on IRC: - replacing sc with vt & disabling sc - removing atkbdc from kernel configuration - removing uart from kernel configuration - putting "off" for ttyu0 in /etc/ttys (it had "onifconsole") No luck. Verbose dmesg can be obtained from: http://www.tobez.org/download/dmesg.verbose.2014-07-31.txt Any thought? Thanks in advance, \Anton. -- Our society can survive even a large amount of irrational regulation. -- John McCarthy ___ 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: Future of pf / firewall in FreeBSD ? - does it have one ?
On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: D> Without diminishing your efforts so far, what do you think about D> pitching all efforts into IPFW to combine effort and reduce overhead of D> maintaining separate firewalls in the core? Is there an advantage to D> having our own pf? Is there any disadvantage keeping it? It is a plugin. It is optional and loadable. I removed most additions to the network stack that live outside netpfil/pf. Some people like it and use it. It is also the only tool to configure ALTQ now. -- Totus tuus, Glebius. ___ 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: Future of pf / firewall in FreeBSD ? - does it have one ?
On 07/29/14 20:35, Gleb Smirnoff wrote: On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote: M> |> imho, the root problem here is that an effort to implement a M> single M> |> feature improvement (multi-threading) has caused the FreeBSD M> version M> |> of pf to apparently reach a near-unmaintainable position in the M> |> FreeBSD community because improvements from OpenBSD can no longer M> be M> |> ported over easily. FreeBSD's pf has been put in a virtual M> |> isolation chamber due to the multi-threaded enhancement. M> |> M> |> Was it worth it? M> | M> |Yes. This happened *three times* in BSD land now. How much more M> |proof does it take to make that clear? M> |[snip] M> M> In this instance, more proof would consist of pf development not M> wallowing in inactivity. M> M> imo, tactical changes were implemented in pf without the strategic M> negative consequences affecting the decision process guiding the M> implementation of those tactical features.And that's backwards. M> Strategies direct tactics, not vice versa. I would strongly disagree with you. I would claim that directions I've put in pf in 2012 are strategically correct, while previous life of pf in FreeBSD was not. History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already outdated. It isn't possible otherwise. While Max spent time on porting some stable version, the OpenBSD moved forward. It was later updated again by Max, and again right after update it was outdated. I mean that people who a) believe that OpenBSD pf is the one true b) eager for bleeding edge version, these people simply cannot be satisfied. A porter needs to take latest stable version from OpenBSD and spend some time working on it. So, pf in FreeBSD was always "outdated", even before my SMP work on it. Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped. In 2004 we've got 10 years of diverging developement between FreeBSD and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in 9.x is again outdated and introduces a number of bugs that were not present in 8.x (regressions). Most regressions didn't came from OpenBSD, but were artifacts of porting. Also, the number of #ifdefs in code became so unbearable that no one would want to go through code fixing bugs. In 2012 for me it was obvious that following this route is strategically incorrect. You are never "up to date". You need more efforts to port pf, and you yield in a port of worse and worse quality over time. So, in 2012 I put a lot of efforts to not only bring pf out of a single mutex, but also make it more native to FreeBSD. You can read this through commit logs. The net result is that we got our own pf, that can be maintained further. Unfortunately, still no person is seen on horizon who can take maintainership. That explains it rather well. Thank you for the enlightenment on this. Without diminishing your efforts so far, what do you think about pitching all efforts into IPFW to combine effort and reduce overhead of maintaining separate firewalls in the core? Is there an advantage to having our own pf? ___ 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: Future of pf / firewall in FreeBSD ? - does it have one ?
On 30/07/2014 2:54 AM, Kevin Oberman wrote: > ... > I would hope that is not the case. While NAT66 is "well known" and has been > a topic of discussion for years, NPT66 is relatively new. It does share > many concepts with NAT66 (and, most likely implementations also share > code), but does not require any state, making it vastly less complex and no > longer breaks point to point networking. The names look similar, which may > result in unfortunate confusion, but NPT66 may be the bast solution to a > real problem and it does not create the issues of NAT66. NPT66 is a subset of NAT66. Cheers, Darren ___ 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"
m4 still broken on gcc platforms
Hi, I am still seeing this with arm/power/sparc/mips. Can somene please fix it? ===> usr.bin/m4/tests (all) cc1: warnings being treated as errors /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c: In function 'm4errx': /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c:268: warning: declaration of 'eval' shadows a global declaration /scratch/tmp/bz/head.svn/usr.bin/m4/extern.h:40: warning: shadowed declaration is here --- misc.o --- *** [misc.o] Error code 1 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4 cc1: warnings being treated as errors /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_remove': /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:123: warning: cast discards qualifiers from pointer target type /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_find': /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:144: warning: cast discards qualifiers from pointer target type /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_next': /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:183: warning: cast discards qualifiers from pointer target type --- ohash.o --- *** [ohash.o] Error code 1 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4 --- all_subdir_m4 --- *** [all_subdir_m4] Error code 1 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin ===> usr.bin/mail (all) — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 ___ 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: Future of pf / firewall in FreeBSD ? - does it have one ?
On 7/29/2014 3:18 AM, Gleb Smirnoff wrote: Darren, On Sat, Jul 19, 2014 at 09:36:06PM -0700, Darren Pilgrim wrote: D> Never mistake silence for consent. D> D> The vast majority of people don't know pf is outdated and broken on D> FreeBSD because they don't know what they're missing and likely aren't D> using IPv6 yet. The moment you turn on IPv6 and restart a validating D> unbound, you run full-speed into pf's broken behaviour. Make an D> EDNS0-enabled query for a signed zone and you'll get a fragmented UDP D> packet that will never make it through unless you tell pf to allow all D> fragments unconditionally. They'll simply think something is wrong with D> unbound, turn off EDNS0 and/or validation, hurt peformance and/or D> security in the process, and never realize their firewall is doing D> literally the worst possible thing it could do. D> D> All because over half a decade ago some folks got all butthurt over a D> config file format change. Do I understand you right, that you propose a tens thousands lines of untrivial code bulk update in order to fix a particular bug, that can be nailed down separately? No. I believe pf should be removed from FreeBSD and efforts refocused on keeping ipfw up to date and feature complete. It makes more sense to look at what pf, ipf, nbtables, etc. are all doing as a source of ideas for what we can do with ipfw. A decade ago, there was justification for adding pf: at the time, ipfw lacked some major features. Ipfw has since caught up. I see no remaining value in having more than one packet filter in the base. Ipfw is more mature and less broken, so we should keep it and ditch the rest in the name of survival efficiency. Do you also say that breaking configuration files for a large number of people is okay if the update is expected to fix a bug unrelated to configuration? Yes. Loss of configuration file backward compatibility is a fact of progress. Here are some examples of places where FreeBSD broke backward compatibility of a configuration file: - rc.conf (with every major version change) - resolv.conf - kernels - make.conf vs. src.conf - the ports collection - pkg vs. pkgng - pkgng changes within pkgng 1.x On top of that, we also have whole chunks of the OS where compatibility was broken (e.g., the toolchain, switch to unbound, etc.). For me sounds like hunting a sparrow with a cannon. The whole thing, to me, was an example of lobbyist politics: a vocal minority had the resources and access to stop progress. Now we are all suffering for their ignorance and arrogance. If anything, we should rename pf to tppf (short for "Tea Party Packet Filter"). ___ 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"
