Re: rsh commands to 5.1-CURRENT being rejected
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: Sep 14 17:46:52 local7.notice target logger: TCP_Wrappers ALLOW: source/tar get,rshd,974,[EMAIL PROTECTED] Sep 14 17:46:52 auth.info target inetd[974]: connection from source, servic e rshd (tcp) Sep 14 17:46:52 auth.info target rshd[974]: [EMAIL PROTECTED] as root: permission denied (authentication error). cmd='date' /root/.rhosts (600): source root /etc/pam.d/rsh: not changed /etc/inetd.conf: shell stream tcp nowait root /usr/libexec/rshd rshd -L /etc/hosts: both source and target are defined /etc/named/s/: both source and target are defined 5.1-CURRENT: Wednesday, 20 August 2003 20:36:05 Under FBSD-4.8, this is not a problem. Under FBSD-5.1, nothing I do seems to allow rsh from another LAN host. A TCPDUMP of the rsh session shows root.root.command coming from source and then permission denied coming from target, where the TCPDUMP is running. The source host displays: rshd: Login incorrect.. RSH from target to source works just fine?!? A picture is worth a thousand words. (No worries folks, this is in my internal network here at home. Professionally I use SSH and Kerberos rsh.) --- /usr/src/etc/pam.d/rsh Sun Feb 9 16:50:03 2003 +++ /etc/pam.d/rsh Mon Jun 16 15:20:00 2003 @@ -6,7 +6,7 @@ # auth auth requiredpam_nologin.so no_warn -auth requiredpam_rhosts.so no_warn +auth requiredpam_rhosts.so no_warn allow_root # account accountrequiredpam_unix.so Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seeing system-lockups on recent current
I'm seeing similar lockups, however they started shortly after the new ATA code was committed. The lockups usually occur when there's a lot of ATA activity, e.g. filesystem or fsck. At the moment I can only guess as to what the problem might be (missing interrupt is my most educated guesss) but keeping the amount of ATA I/O to a minimum does help the situation. Both machines which have suffered the problem have intel chipsets. One is a 12 year old P120 (I cannot recall the exact chipset) and the other is a PIII with an 815E chipset. On a couple of occasions I had systat running and noticed that buffers in use climbed until the system just froze, responding only to pings. In all cases all filesystems were generally clean just with the dirty bit set, except for filesystem on an ATA drive (/var or /export) which required considerable cleanup. Filesystems that reside on SCSI devices have yet to exhibit any symptoms, e.g. requiring anything more than resetting the dirty bit. Due to this problem I've yet to complete a portupgrade, something I've been trying to complete over the last four weeks, as it usually hangs the system within 12 hours. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ In message [EMAIL PROTECTED], Garance A Drosihn writes: For the past week or so, I have been having a frustrating time with my freebsd-current/i386 system. It is a dual Athlon system. It has been running -current just fine since December, with me updating the OS every week or two. I did not update it for most of September, and then went to update it to pick up the recent round of security-related fixes. My first update run picked up a change which caused system panics. Other people were also seeing that panic, and it wasn't long before updates were committed to current to fix that problem. However, ever since then my -current system has very frequently locked up. Totally locked. The only way to get it back is a hardware reset. I have rebuilt the system at least a dozen times since then. I have built it with snapshots of /usr/src from Sept 12th to Oct 8th (which is what it's running at the moment). I have dropped back to a single-CPU kernel. I turned off X (in /etc/ttys) so that doesn't start up at all. All those attempts to get a reliable 5.x-system have not worked. Sometimes the system will crash in the middle of a buildworld, other times it will crash while it's basically idle and the monitor is turned off. One time it crashed in the middle of an installworld -- right when it was replacing /lib files. Boy was that a headache to recover from! On the same PC, in a different DOS partition, is a 4.x-stable system. If I boot into 4.x, I have no problems. I fire up all the servers that I run, start buildworlds, run cvsup's, and even had all the 5.x partitions mounted and was running a infinite-loop that MD5'd every file in the 5.x system. I had all of that going on at the same time, and the system is fine. While in the 4.x system, I've removed /usr/src on the 5.x system and recreated it, just in case there were some files corrupted in there. And once the problems started, I made a point of always removing all of /usr/obj/usr/src before starting the buildworld, in case there were corrupted files in there. I still have a few things I want to try. And I know it could still be a hardware problem (although it bugs me that it fails so consistently on 5.x and never fails on 4.x). Perhaps it is just some disk-corruption problem that occurred during the first few panics. But I thought I'd at least mention it, and see if anyone else has been having similar problems. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/libexec/talkd notification broken on pty's when user is using misc/screen ports in -CURRENT
Mine configures as follows: /* * define PTYMODE if you do not like the default of 0622, which allows * public write to your pty. * define PTYGROUP to some numerical group-id if you do not want the * tty to be in your group. * Note, screen is unable to change mode or group of the pty if it * is not installed with sufficient privilege. (e.g. set-uid-root) * define PTYROFS if the /dev/pty devices are mounted on a read-only * filesystem so screen should not even attempt to set mode or group * even if running as root (e.g. on TiVo). */ #define PTYMODE 0620 #define PTYGROUP 4 /* #undef PTYROFS */ What does your /etc/group look like? Could send me a copy of /etc/devfs.conf. I'd like to see an ls -l of /dev too. I'm preparing to host a Canada Day barbecue at my house, so I may not have a chance to check for email later on today. Please bear with me. Thanks. I'm cc'ing this to current@ just in the chance that someone there might solve this before I do. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ In message [EMAIL PROTECTED], Vincent Poy writes : On Tue, 1 Jul 2003, Cy Schubert wrote: In message [EMAIL PROTECTED], Vincent Poy writes : [a bunch of lines edited out for brevity, see archives] Hi Cy: I found the problem. In 5.1-CURRENT and I think 5.1-RELEASE, /dev uses the devfs for the devices so it no longer has to be manually generated. I login to the system using /dev/ttyp0 which shows up as: crw--w 1 vince tty- 5, 0 Jul 1 08:28 /dev/ttyp0 However, the 10 tty's that screen uses is ttyp1-pa which has the group as users or the same as my login: crw--w 1 vince users- 5, 1 Jul 1 08:28 /dev/ttyp1 crw--- 1 vince users - 5, 2 Jul 1 08:26 /dev/ttyp2 crw--w 1 vince users - 5, 3 Jun 30 16:18 /dev/ttyp3 crw--w 1 vince users - 5, 4 Jun 29 00:35 /dev/ttyp4 crw--w 1 vince users - 5, 5 Jun 29 00:35 /dev/ttyp5 crw--w 1 vince users - 5, 6 Jun 29 00:35 /dev/ttyp6 crw--w 1 vince users - 5, 7 Jun 29 00:35 /dev/ttyp7 crw--w 1 vince users - 5, 8 Jun 29 00:35 /dev/ttyp8 crw--w 1 vince users - 5, 9 Jul 1 08:18 /dev/ttyp9 crw--w 1 vince users - 5, 10 Jul 1 08:28 /dev/ttypa As soon as I changed the ttyp1 to the group tty, everything started working correctly. So it seems that the /dev has the incorrect group whe n the tty is from screen. No problems here. cwsys$ ll ttyp? crw-rw-rw- 1 root wheel5, 0 Jun 26 13:19 ttyp0 crw--w 1 cytty 5, 1 Jul 1 10:05 ttyp1 crw--w 1 cytty 5, 2 Jul 1 10:05 ttyp2 crw--w 1 cytty 5, 3 Jul 1 10:05 ttyp3 crw--w 1 cytty 5, 4 Jul 1 10:05 ttyp4 crw--w 1 cytty 5, 5 Jul 1 10:05 ttyp5 crw--w 1 cytty 5, 6 Jul 1 10:05 ttyp6 crw--w 1 cytty 5, 7 Jul 1 10:05 ttyp7 crw--w 1 cytty 5, 8 Jul 1 10:05 ttyp8 crw--w 1 cytty 5, 9 Jul 1 10:05 ttyp9 crw--w 1 cytty 5, 10 Jul 1 10:05 ttypa crw--w 1 cytty 5, 11 Jul 1 10:05 ttypb crw--w 1 cytty 5, 12 Jul 1 10:05 ttypc crw--w 1 cytty 5, 13 Jul 1 10:05 ttypd crw--w 1 cytty 5, 14 Jul 1 10:05 ttype crw--w 1 cytty 5, 15 Jul 1 10:05 ttypf cwsys$ I have a locally built package here at http://komquats.com/pkg/screen-3. 9.15_1.tbz/. It's built from the stock 3.9.15_1. See if it makes a difference. Other than that it could be a myriad of configuration things on your system. Anyhow give it a try and let us know your results. I tried your package with the extracted bin/screen binary and yours work correctly. [EMAIL PROTECTED] [11:20am][~] tty /dev/ttypb [EMAIL PROTECTED] [11:20am][~] dir /dev/ttypb crw--w 1 vince tty - 5, 11 Jul 1 11:20 /dev/ttypb [EMAIL PROTECTED] [11:20am][~] Message from [EMAIL PROTECTED] at 11:20 on 2003/07/01 ... talk: connection requested by [EMAIL PROTECTED] talk: respond with: talk [EMAIL PROTECTED] [EMAIL PROTECTED] [11:20am][~] So this means that the configure script might have something configured incorrectly. I just tried to rebuild the port and it's the configure script which generates the config.h with the wrong PTYGROUP. /* * define PTYMODE if you do not like the default of 0622, which allows * public write to your pty. * define PTYGROUP to some numerical group-id if you do not want the * tty to be in your group. * Note, screen is unable to change mode or group of the pty if it * is not installed with sufficient privilege
Re: Corroupted CVS File (fwd)
John, It appears I may not be going insane after all. The file is received OK from cvsup7 and from cvsup10. When I check out (using cvs co) from my local repo or rsync the repo to another machine on my network here at home, the file is corrupted. Looks like I've found some kind of issue with -CURRENT. I'm running 5.1-REL. The rsync process is still running. It hasn't even copied the file over yet it appears to have made it's first pass through my CVS tree and suddenly the file is corrupt. I've run the following against my CVS tree: find . -type f | file -f - | grep ':.*data$' It's managed to flag quite a few files however only the file in question appears to be damaged so far. I'm cc'ing this to current@ as I'm fearing the worst at the moment. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ --- Forwarded Message Date:Wed, 02 Jul 2003 09:55:38 -0700 From:Cy Schubert [EMAIL PROTECTED] To: John Polstra [EMAIL PROTECTED] Subject: Re: Corroupted CVS File In message [EMAIL PROTECTED], John Polstra writes: Hi Cy, I'd like to report a corrupted RCS file on cvsup10: cwsys% cvs co cryptcat cvs checkout: Updating cryptcat U cryptcat/Makefile cvs [checkout aborted]: EOF in value in RCS file /home/fcvs/ports/net/cr yptcat/distinfo,v cwsys% I checked the file on cvsup10 and on cvsup-master, and they're identical. The one I have here is also identical to those, and I can check it out OK. Are you sure the corruption isn't on your local system? Here's what I get from md5: thin$ md5 distinfo,v MD5 (distinfo,v) = 2e7bbef5226dfd02efe1ec51d2bea8fa John Strange. I could have sworn that I removed the file and cvsupped again. Anyhow I did and it fixed the problem. Hope this doesn't portend how the rest of my day will go. Cheers, - -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ --- End of Forwarded Message ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Corroupted CVS File (fwd)
The fsck discovered an unexpectd softupdate inconsistency, listing the file in question. Case closed. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ --- Forwarded Message Date:Thu, 03 Jul 2003 09:22:25 -0700 From:Cy Schubert [EMAIL PROTECTED] To: John Polstra [EMAIL PROTECTED] Subject: Re: Corroupted CVS File (fwd) In message [EMAIL PROTECTED], John Polstra writes: In article [EMAIL PROTECTED], Cy Schubert [EMAIL PROTECTED] wrote: It appears I may not be going insane after all. I never suspected you of insanity. :-) I know you didn't. It's just my way of putting it. :) The file is received OK from cvsup7 and from cvsup10. When I check out (using cvs co) from my local repo or rsync the repo to another machine on my network here at home, the file is corrupted. Looks like I've found some kind of issue with -CURRENT. I'm running 5.1-REL. Next time you find a corrupted RCS file, save it somewhere. Not a problem. I can reproduce this problem at will. Take a look at it in an editor and see if you can spot what's going on. The typical kinds of corruption I've seen over the years when people have reported these things to me have been: - Single-bit errors in the RCS file. These are always caused by HW problems, and they always go away if ECC RAM is installed. I doubt this - Either a region of zeroes or a portion of an unrelated file splatted somewhere into the middle of the corrupted RCS file. Possible. I'll have to look more closely This kind of corruption is always page-aligned or filesystem block aligned. It is probably caused by kernel software bugs. I used to see a lot of these back around FreeBSD-3.x, but I haven't heard of any for a long time now. Interestingly, my repo exists on my /opt2 filesystem and /opt2 appears somewhere in the middle of the file. It's the only intelligible string in the file. Could I have some kind of single bit error (h/w) or storage overlay (h/w or s/w)? I guess I'm stating the obvious. I suspect what I'm seeing is either random data on disk because when the inode is rewritten to update the access time it's corrupted hmmm could I have some filesystem corruption?? I think I'll shut down and force an fsck. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Two buttocks cannot avoid friction. -- Malawi saying Cheers, - -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ --- End of Forwarded Message ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on head (r255759) [_callout_stop_safe()- panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140]
In message 523d8c39.4050...@freebsd.org, Bryan Drewery writes: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bTOWMsw68o4sI8l0qJIHm7QU0StCi2OQm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 9/21/2013 7:06 AM, Bjoern A. Zeeb wrote: On Sat, 21 Sep 2013, Bryan Drewery wrote: =20 Unread portion of the kernel message buffer: panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140 cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe118aeef820 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe118aeef8d0 vpanic() at vpanic+0x126/frame 0xfe118aeef910 panic() at panic+0x43/frame 0xfe118aeef970 __rw_assert() at __rw_assert+0xa3/frame 0xfe118aeef980 _callout_stop_safe() at _callout_stop_safe+0x54/frame 0xfe118aeef= 9f0 arptimer() at arptimer+0x14e/frame 0xfe118aeefa30 softclock_call_cc() at softclock_call_cc+0x188/frame 0xfe118aeefb= 10 softclock() at softclock+0x47/frame 0xfe118aeefb30 intr_event_execute_handlers() at intr_event_execute_handlers+0x93/frame 0xfe118aeefb70 ithread_loop() at ithread_loop+0xa6/frame 0xfe118aeefbb0 fork_exit() at fork_exit+0x84/frame 0xfe118aeefbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe118aeefbf0 --- trap 0, rip =3D 0, rsp =3D 0xfe118aeefcb0, rbp =3D 0 --- =20 =20 +1 from me; I guess introduced somwhere between 255569 and 255758, as these are my edges of kernel.old and kernel. =20 r255726 was stable for me. r255759 is not. r255755 converted ipfilter to callout, but I am unsure if that is the problem. I've been running the r255755 code locally on a couple of r255665 systems for about a week with no problems but I'll check it again. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: [Heads Up] RCS removed from base
In message 52538562.6030...@freebsd.org, Julian Elischer writes: On 10/8/13 10:03 AM, Steve Rikli wrote: On Mon, Oct 07, 2013 at 06:32:21PM -0700, Alfred Perlstein wrote: On 10/7/13 6:30 PM, Steve Kargl wrote: ... PS: As noted, the code is GPL. There has been an effort to remove GPL code from FreeBSD (whether prudent or not). That plus the age of the code is good enough reason to ditch it! huzzah! Plus we can make RCSBSD along with it. Is such a project underway? I.e. an RCS of some kind from FreeBSD? OpenBSD went through this a while ago and use OpenRCS -- is that even remotely appropriate for use in FreeBSD? From reading most of both thread(s), it seems there's at least some interest in keeping an RCS in base; whether it's the status quo RCS (w/GPL) doesn't seem to be strictly required, as long as whichever RCS is available in base is (mostly?) compatible with status quo RCS. the prudent path is to put the original back before 10 and arange to replace it by 11 I'm officially asking core to allow this to stop what I consider a bad POLA problem. it can not be said that there was no pushback against this change. and it was sprung on us with no real warning. Probably a good idea. Though I've put a rcs57 port in place, ports need to be updated and probably a little more warning would have been nice. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: [Heads Up] RCS removed from base
In message 52538d19.8000...@freebsd.org, Julian Elischer writes:
On 10/8/13 12:34 PM, Mehmet Erol Sanliturk wrote:
On Mon, Oct 7, 2013 at 9:49 PM, Julian Elischer jul...@freebsd.org
mailto:jul...@freebsd.org wrote:
On 10/8/13 9:33 AM, Steve Kargl wrote:
On Mon, Oct 07, 2013 at 08:41:38PM -0400, George Mitchell wrote:
On 10/07/13 20:28, John-Mark Gurney wrote:
Julian Elischer wrote this message on Tue, Oct 08,
2013 at 08:01 +0800:
not a big thing but I believe that a lot of
poeple use ci/co on /etc
becasue it is just there
+1
Folks, this is just plain a major violation of the
Principle of Least
Amazement. RCS is ideal for keeping track of my
configuration files
in /etc. What do we gain by removing it?
Less GPL code in FreeBSD?
not a problem unless you plan in shipping a changed version of
it on your product??
Most new versions of GPL licensed code are converted to Version 3 GPL .
This is blocking FreeBSD if they keep GPL licensed code in base ,
because commercial companies usingFreeBSD are not able to use
FreeBSD any more if the FreeBSD switches to Version 3 GPL .
This obstacle is in the base system GCC : It stayed in an older
version , and necessitated to switch to Clang/LLVM .
Difficulty of such a switch is apparenly known .
Therefore cleaning base from GPL licensed code is a vital
requirement for further progress WITH RESPECT TO FreeBSD Project
structure .
Thank you very much .
sure but lets keep the one one in the the tree untill there is a
replacement ready to commit. ro 10 will have NO RCS which is a POLA.
We do now have an rcs57 port which is the same as what was in base. The
port could be made to _optionally_ install into /usr instead of
${LOCALBASE}.
--
Cheers,
Cy Schubert cy.schub...@komquats.com
FreeBSD UNIX: c...@freebsd.org Web: http://www.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: rcs
In message 525422b6.9040...@mu.org, Alfred Perlstein writes: On 10/8/13 8:04 AM, sth...@nethelp.no wrote: I think the fact is that most direct users of RCS use it in a very simple way, and it works just fine for that. with no real need for any updates or any change. With all due respect Julian, The more we discuss this more this really points to the problem that FreeBSD appears to be a challenge to install packages into such that a package moving out of base is such a big deal. Can we fix that instead? I mean, this change should really not be a big deal, but yet it is and this speaks to the core of FreeBSD utility. Not commenting on RCS here, but on the concept of moving packages out of the base: - For some of us, the attraction of FreeBSD is that it is a tightly integrated system, and the base contains enough useful functionality that we don't *have* to add a lot of packages. - Each package that is moved out of the base system means less useful functionality in the base system - and for me: Less reason to use FreeBSD instead of Linux. I absolutely see the problem of maintaining out-of-date packages in the base system, and the desirability of making the base system less reliant on GPL. I'm mostly troubled by the fact that there seems to be a rather strong tendency the last few years of having steadily less functionality in the base system - and I'm not at all convinced that the right balance has been found here. This discussion is not new, and I don't expect to convince any new persons... I'm sure other devs will disagree, but with ~15 years of FreeBSD experience and ~13 years as a dev, my very strong opinion is that this tightly coupled system is actually a boat anchor sinking us. Just because no one else does it a certain way, does not mean that a unique way of doing something is correct and/or sustainable. Maybe in 1995, 1999, or 2005 even, but not today. Especially in the context of add-on tools like rcs. What we need to discuss is lowering the bar to making custom installs. I personally find that installing FreeBSD is useless until I install screen, zsh, vim-lite, git why is that so manual for me? Why can't I just register a package set somewhere so that all I have to type in is alfred.perlstein.devel into a box during the installer and I get all my packages by default? A Red Hat-like kickstart or Solaris jumpstart possibly? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: [Heads Up] RCS removed from base
In message 52542687.7000...@pix.net, Kurt Lidl writes: On 10/8/13, Julian Elischer wrote: On 10/7/13 11:06 PM, Steve Kargl wrote: On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote: Hey all, RCS was removed from the base system in r256095. If you still want to use RCS please install either devel/rcs or devel/rcs57. If not, be sure to check out the alternatives (pun stolen and intended). Perhaps, a note in src/UPDATING is appropriate? ok so what is this, the secret cabal to make FreeBSD useless? I'm ccing core as I believe this was not discussed enough in public (in fact not discussed AT ALL in any forum I am watching) and I officially request a backout of the removal of what I consider to be core functionality. My usual way of doing things is on install to ci EVERYTHING in /etc to get a snapsot right the way back to install. now I have to change things in /etc (and other places) BEFORE I can check them in. (i.e. get networking up and ports installed) not a big thing but I believe that a lot of poeple use ci/co on /etc becasue it is just there +1 for keeping a RCS in base. I too use to maintain a bunch of files in /etc - I have for years and years. I don't particularly want the GPL'd version - I'd be happiest with the OpenRCS version (BSD-licensed) from OpenBSD. I've started work on a port (not that this was my highest priority but received a private email that I may want to do this instead of rcs57). Would the majority here rather have it in base? Just finished schlepping the OpenBSD source to my laptop (the link to the OpenRCS site returns a TCP RST). I don't mind either way. It's the groups's and the Project's call. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: rcs
In message CAETOPp0imH3LCM2gwe1a_TJD+q5YoWhuJbR0YhHpux0qe8irtA@mail.gmail.c om , Jos Backus writes: On Oct 7, 2013 7:31 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: Okay folks, can we make a call about keeping the RCS tools in the base? The proponents wanting to remove RCS need to speak up and make their technical case. Perhaps slightly off-topic, but how about we move into the 21st century and import the 2-clause BSD-licensed Fossil? http://www.fossil-scm.org/ Not RCS, I know, but vastly more useful. Bikeshed alert. Let's not let this discussion go sideways. Seriously, it's not the same. To import something different doesn't replace what was removed. We have two options. Put it back, or something like it, e.g. OpenRCS, back, or put it in ports. Personally I don't think it matters where it lives as long as the same functionality is there. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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
tcl tk ports on FreeBSD 10 amd64
Hi, Sorry for cross posting but this concerns both lists. Over the last month or so I've been upgrading my prod infrastructure from 9 to 10. It's mostly complete except for a number of issues. One issue, just solved today (circumvented is a better word), is exmh crashing 10.0 on amd64 while on i386 there are no issues with exmh. It appears that the tcl and tk ports (all three of them, 8.4, 8.5, and 8.6) will panic 10.0 on amd64 (but not i386) when the ports are built with threading support. I haven't had a chance to look at the dump yet but I had a hunch to test the ports without threading support enabled, making the panic go away. If I don't get to it in time, here is what I haveFatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0x80957aeb stack pointer = 0x28:0xfe00f17f9980 frame pointer = 0x28:0xfe00f17f99a0 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 = 11 (idle: cpu2) trap number = 9 timeout stopping cpus panic: general protection fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00f17f9510 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00f17f95c0 panic() at panic+0x153/frame 0xfe00f17f9640 trap_fatal() at trap_fatal+0x3a2/frame 0xfe00f17f96a0 trap() at trap+0x7bf/frame 0xfe00f17f98c0 calltrap() at calltrap+0x8/frame 0xfe00f17f98c0 --- trap 0x9, rip = 0x80957aeb, rsp = 0xfe00f17f9980, rbp = 0xfe 00f17f99a0 --- cpu_idle_hlt() at cpu_idle_hlt+0x2b/frame 0xfe00f17f99a0 cpu_idle() at cpu_idle+0x93/frame 0xfe00f17f99c0 sched_idletd() at sched_idletd+0x1ee/frame 0xfe00f17f9a70 fork_exit() at fork_exit+0x9a/frame 0xfe00f17f9ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00f17f9ab0 --- trap 0, rip = 0, rsp = 0xfe00f17f9b70, rbp = 0 --- Uptime: 4m42s Dumping 522 out of 5932 MB:..4%..13%..22%..31%..43%..53%..62%..71%..83%..92% so far, Tcl/tk are tickling some bug somewhere. Before anyone suggests memory, I've been able to reproduce this on an Intel Core i3 machine with 6 GB and an AMD X2 5000+, also with 6 GB, both in amd64 mode. Both systems are dual (or multi) boot. The bug does not exhibit itself in i386 mode. It also doesn't exhibit itself when tcl/tk are built without thread support. The only application I know of which tickles the bug is mail/exmh2 (I'm the maintainer) when using a threaded tcl/tk. My 11-CURRENT partition on my laptop is still i386 so I haven't been able to reproduce it under 11 with amd64. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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
ifconfig alias
Sometime between Nov 9 and yesterday (Nov 23 at approximately noon PST) ifconfig alias has stopped working. Here's uname -a FreeBSD bob 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r227907M: Thu Nov 24 13:04:39 PST 2011 root@bob:/usr/obj/dsk03/src/svn-current/sys/BREAK i386 Here's the problem (interface doesn't matter -- on this machine vr0 and sk0 are affected). bob# ifconfig vr0 vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=82808VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE ether 00:16:17:8e:65:fe inet6 fe80::216:17ff:fe8e:65fe%vr0 prefixlen 64 scopeid 0x6 inet 10.1.2.7 netmask 0xff00 broadcast 10.1.2.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active bob# ifconfig vr0 10.1.2.2 netmask 0x alias bob# ifconfig vr0 vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=82808VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE ether 00:16:17:8e:65:fe inet6 fe80::216:17ff:fe8e:65fe%vr0 prefixlen 64 scopeid 0x6 inet 10.1.2.2 netmask 0x broadcast 10.1.2.2 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active bob# A sample 8.2 system, showing how it should work: FreeBSD cwsys 8.2-STABLE FreeBSD 8.2-STABLE #0: Wed Nov 23 20:29:36 PST 2011 root@cwsys:/export/obj/opt/src/svn-stable8/sys/KQLARGE i386 cwsys# ifconfig nfe0 nfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MA GIC,VLAN_HWTSO,LINKSTATE ether 00:1e:8c:3e:1b:da inet 10.1.2.1 netmask 0xff00 broadcast 10.1.2.255 media: Ethernet autoselect (100baseTX full-duplex,flowcontrol,rxpause,txpa use) status: active cwsys# ifconfig nfe0 inet 10.1.2.99 netmask 0x alias cwsys# ifconfig nfe0 nfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MA GIC,VLAN_HWTSO,LINKSTATE ether 00:1e:8c:3e:1b:da inet 10.1.2.1 netmask 0xff00 broadcast 10.1.2.255 inet 10.1.2.99 netmask 0x broadcast 10.1.2.99 media: Ethernet autoselect (100baseTX full-duplex,flowcontrol,rxpause,txpa use) status: active cwsys# -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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
Amd(8) Hangs at Boot
Just udated to the latest current and amd hangs at boot. Ideas? NFS access cache time=0 Starting amd. [halt - sent] KDB: enter: Break to debugger [ thread pid 762 tid 100072 ] Stopped at kdb_break+0x4e: movl$0,kdb_why db bt Tracing pid 762 tid 100072 td 0x8a1675e0 kdb_break(87641200,c7c8617c,807a9208,81ac6b54,81ac6b50,...) at kdb_break+0x4e/frame 0xc7c86130 uart_intr(87641200,0,8a1675e0,4,875f30d0,...) at uart_intr+0x8e/frame 0xc7c8615c intr_event_handle(8757fa80,c7c861c0,1,8a1675e0,8a22d6e4,...) at intr_event_handle+0x85/frame 0xc7c8617c intr_execute_handlers(875f30d0,c7c861c0,0) at intr_execute_handlers+0x42/fra me 0xc7c8619c lapic_handle_intr(42,c7c861c0) at lapic_handle_intr+0x3d/frame 0xc7c861b0 Xapic_isr2() at Xapic_isr2+0x35/frame 0xc7c861b0 --- interrupt, eip = 0x80929af4, esp = 0xc7c86200, ebp = 0xc7c86220 --- udp_bind(8a4b71a0,8a125380,8a1675e0,8a1675e0,8758b400,...) at udp_bind+0x104/frame 0xc7c86220 bindresvport(8a4b71a0,0,c7c86380,89fa8300,c7c86408,...) at bindresvport+0x14a/frame 0xc7c86284 clnt_reconnect_call(876e82e0,c7c86358,1,89fa8300,c7c86408,...) at clnt_reconnect_call+0x2a0/frame 0xc7c862e8 newnfs_request(c7c86408,8a229200,0,8a229310,0,...) at newnfs_request+0x82a/frame 0xc7c863b0 nfsrpc_getattrnovp(8a229200,8a22928c,20,1,8758be80,...) at nfsrpc_getattrnovp+0xfa/frame 0xc7c864b0 mountnfs(8a125b40,c7c86870,c7c8678c,0,c7c86728,...) at mountnfs+0x883/frame 0xc7c865a0 nfs_mount(8a11c2a0,80d1e8e8,8a0fc400,8758be80,0,...) at nfs_mount+0x169f/frame 0xc7c86960 vfs_donmount(8a1675e0,80,0,c7c86b58,8a10b000,...) at vfs_donmount+0xc94/frame 0xc7c86b40 kernel_mount(87557a80,80,0,58,3,...) at kernel_mount+0x52/frame 0xc7c86b80 nfs_cmount(87557a80,7fbfd170,80,0,80b46c55,...) at nfs_cmount+0x63/frame 0xc7c86c08 sys_mount(8a1675e0,c7c86cc8,8a1675e0,88bb82f0,80d94a80,...) at sys_mount+0x20b/frame 0xc7c86c40 syscall(c7c86d08) at syscall+0x479/frame 0xc7c86cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc7c86cfc --- syscall (21, FreeBSD ELF32, sys_mount), eip = 0x280ebef7, esp = 0x7fbfd09c, ebp = 0x7fbfd0c0 --- db -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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
Smartmontools
Other than nooptions ATA_CAM, is there a fix or circumvention to allow smartmontools to work correctly under 9.0 and -CURRENT? slippy# smartctl -a /dev/ad0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ad0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary slippy# -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: Smartmontools
In message e5fba775-b6b6-4086-ba2b-d74a19cf4...@samsco.org, Scott Long writes : On Feb 1, 2012, at 9:49 PM, Cy Schubert wrote: Other than nooptions ATA_CAM, is there a fix or circumvention to allow smartmontools to work correctly under 9.0 and -CURRENT? slippy# smartctl -a /dev/ad0 smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-STABLE i386] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device Unable to get CAM device list /dev/ad0: Unable to detect device type Smartctl: please specify device type with the -d option. Use smartctl -h to get a usage summary slippy# I can't say for certain, but my guess is that you've been victimized by recen t changes to CAM headers. Have you tried recompiling to get everything in sy nc? Everything (kernel and userland) but smaartmontools (and other ports) has been rebuilt (two days ago). Rebuilding the port did the trick. Thanks. :) -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
In message 4f91c8fe.4070...@freebsd.org, Dimitry Andric writes: This is a multi-part message in MIME format. --030506060901050002030508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-04-20 22:21, Jason Evans wrote: On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: I think the best solution would be for jemalloc to avoid using obvious names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just this reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for so lving this problem in the short run. I take it back. There's spotty mangling coverage for variables. I'll try to add full coverage. I'm now using the attached. It seems to work... It didn't work for me. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: /usr/bin/as: out of memory allocating 4194304 bytes after a total of 524288000 bytes
In message 4f92f020.1000...@protected-networks.net, Michael Butler writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/12 13:21, Cy Schubert wrote: In message 4f91c8fe.4070...@freebsd.org, Dimitry Andric writes: This is a multi-part message in MIME format. --030506060901050002030508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-04-20 22:21, Jason Evans wrote: On Apr 20, 2012, at 1:14 PM, Jason Evans wrote: On Apr 20, 2012, at 1:10 PM, Dimitry Andric wrote: On 2012-04-20 21:54, Jason Evans wrote: On Apr 20, 2012, at 12:49 PM, Dimitry Andric wrote: I think the best solution would be for jemalloc to avoid using obviou s names like chunksize for its globals, because it is basically a library that could be linked to any sort of program out there. For example, it could prefix all its internal-use only globals with jemalloc_ or some other mangling scheme. Jason, any thoughts? jemalloc has optional namespace mangling support built in for just thi s reason. I'll turn it on, hopefully today. Indeed, I had just found jemalloc/internal/private_namespace.h. :) It does seem to list only functions, not variables, is that right? Ah right, functions only. Well then, I don't have any bright ideas for so lving this problem in the short run. I take it back. There's spotty mangling coverage for variables. I'll tr y to add full coverage. I'm now using the attached. It seems to work... It didn't work for me. The problem is that /usr/bin/as is statically linked .. rebuild that and you'll be fine, I did. I restored from backup made a month ago and rebuilt world again. That worked. I then rebuilt world again. That's when it failed. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: Chrome crashing system (amd64-10.0-CURRENT)
In message 20120517071141.gl2...@thinkbsd.divinix.org, John Hixson writes: On Thu, May 17, 2012 at 01:15:54AM -0500, Conrad J. Sabatier wrote: For the last week or so, I've been unable to run chrome. Any attempt to start it up will cause the system either to freeze up or reboot. To make matters worse, no trace of what's happening is anywhere to be found. Nothing in any log files. The system doesn't drop into the kernel debugger, either. It's either a hard freeze or sudden reboot. I've tried rebuilding the chromium port, with both clang and gcc 4.6, to no avail. I've also updated the system sources several times this week and remade world/kernel. Nothing seems to help. I'm totally stumped as to how to determine what's going on here. Any suggestions as to how to obtain some useful info? To add to this, I've had the same problem on 10-CURRENT for several months now. I think we're dealing with two issues here. First, the application is passing out of bound data or corrupt data to the O/S. Secondly, FreeBSD should be able to withstand this (DoS). -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: ipfilter(4) needs maintainer
In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: ipfilter(4) needs maintainer
I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org In message 8adc8f0961dd8f7972300837db7403ce.squir...@ma.sdf.org, c...@sdf.org writes: Ok, seems someone has taken the job. In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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
Re: ipfilter(4) needs maintainer
In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8(B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: ipfilter(4) needs maintainer
In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: ipfilter(4) needs maintainer
In message 20130415195544.gy76...@freebsd.org, Gleb Smirnoff writes: Cy, good news that you volunteered to work on this! On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote: C The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't C done much with IPF while employed with Sun. Since then there has been some C development that is long overdue for HEAD. The problem is that v5.1.2 is under GPL. I'm afraid we should update to v4.1.34 only, and then stick to it. So the nearest TODO list is smth like: - update to v4.1.34 - cleanse old kernel APIs (timeout(9) at least) - fix VIMAGE - review open PRs (some might should be closed) - since we do not expect more imports, may be cleanse non-FreeBSD stuff from there? - maybe move it into sys/netpfil? Need to consult imp@ on that. License is very closed to BSD, but has some additions. A small step in the right direction is a good thing. I'll run the patches by you first. The existing license isn't that BSD-friendly either, which is why it lives in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. A person can always load it anyway. C I'm not sure if I'd MFC it into 9 or not. This is up to you, but be adviced that head already differs from stable/9, for example network stack is entirely in network byte order. So merging would require a lot of attention and testing. C I did consider a port but given it would has to touch bits and pieces of C the source tree (/usr/src), a port would be messy and the decision was mad e C to work on importing it into base. Port isn't an option. IPFilter is too close to many kernel APIs, that can change quickly. Agreed. I looked at it a few months ago and determined that src is where it should be. (I put it aside, getting ACER WMI/ACPI working on my new Acer laptop was my priority at the time.) -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: ipfilter(4) needs maintainer
It was pointed out to me that Darren Reed has changed licenses from his IP Filter license that's been in IPF since 2005 or so, when he joined Sun, to GPLv2 (probably when Darren left when Oracle took over Sun). Given that IPF already lives in src/contrib and src/sys/contrib due to the 2005 license change, would that be a problem? If it's OK then I'll maintain it in src. If not then a port is in order. Having said that, a port would be messy as IPF's own install scripts update src/sys/netinet, among other locations. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org In message d6ade9c6-868a-4524-a6d7-4eb88f9d6...@yahoo.com, Scott Long writes: The desire to remove it stems from the inability to give it adequate engineer ing service as the network stack evolves. Simply taking it out of a kernel confi g file doesn't address that problem at all. If it's going to stay in FreeBSD at all , it needs to be maintained. This could be set about a fair amount of stuff in Fr eeBSD, but IPFilter stands out since there's a high rate of needed change happening in the network stack, and it shouldn't be left to rot nor to be a stumbling bloc k for those changes. Scott On Apr 15, 2013, at 12:49 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert cy.schub...@komquats.comwrot e: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55ãCy Schubert cy.schub...@komquats.com ã®ã¡ãã»ã¼ã¸: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was mad e to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longes t of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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 -- Sam Fourman Jr. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-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: ipfilter(4) needs maintainer
In message 516c58ed.40...@freebsd.org, Jung-uk Kim writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-15 15:27:55 -0400, Cy Schubert wrote: In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). FYI, NetBSD has PF from OpenBSD: http://www.netbsd.org/docs/network/pf.html Also, they upgraded it to the latest GPL'ed sources recently (and moved to a different directory): http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_wi th_tag=MAIN Now they have their own packet filter, called NPF: http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html They have more choices now. :-) I'm always (or usually) one for more than fewer choices. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: ipfilter(4) needs maintainer
In message 20130415212826.ga76...@freebsd.org, Gleb Smirnoff writes: On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote: c However it would of been better if said person asked me as I already c offered to take it on but whatever. Sorry, I didn't see your posting. I had a permissions issue on my gateway which caused the loss of a few emails (still sorting through the list of bounces). More manpower - the better. Why can't you work together? I don't mind working with others. I know there's more than enough to keep everyone busy. My main goal is to make sure IPF doesn't disappear nor go into disrepair and to make sure it's well maintained. Let's work together. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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
Stack Overflow in GEOM
Has anyone see this before? Just updated my CURRENT partitions on my testbed and laptop. The laptop just boots but I've managed to capture this on my testbed (attached to a serial port on another system). This is HEAD from yesterday (Apr 15) morning (PDT). The partition being booted is ada0s1d. On my laptop it's ada0s3a. KSTACK_PAGES is 4. Is there a way to quickly display that kern.kstack_pages from DDB? ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: SAMSUNG SP0802N TK100-24 ATA-7 device ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 76351MB (156368016 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: Maxtor 6Y120P0 YAR41BW0 ATA-7 device ada1: 133.000MB/s transfers (UDMA6, PIO 8192bytes) ada1: 117246MB (240121728 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 ada2 at ata2 bus 0 scbus2 target 0 lun 0 ada2: WDC WD5000AAKS-00D2B0 12.01C02 ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad4 ada3 at ata3 bus 0 scbus3 target 0 lun 0 ada3: WDC WD3200KS-00PFB0 21.00M21 ATA-7 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada3: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad6 SMP: AP CPU #1 Launched! panic: stack overflow detected; backtrace may be corrupted cpuid = 1 KDB: enter: panic [ thread pid 13 tid 19 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db bt Tracing pid 13 tid 19 td 0x872d6000 kdb_enter(80ca7886,80ca7886,80ca9523,86edcae0,1,...) at kdb_enter+0x3d/frame 0x86edca98 panic(80ca9523,86edcb70,80713dd2,86edcbd8,86edcafc,...) at panic+0x141/frame 0x86edcad4 __stack_chk_init(86edcbd8,86edcafc,86edcaf8,86edcafc,64,...) at __stack_chk_init/frame 0x86edcae0 g_label_disk_ident_taste(87b7dc80,86edcbd8,80,0,0,...) at g_label_disk_ident_taste+0x102/frame 0x86edcb70 g_label_taste(80d26b88,872ff500,0,872ff480,872d6000,...) at g_label_taste+0x3ca/frame 0x86edcc6c g_new_provider_event(872ff500,0,25c,80c9798e,0,...) at g_new_provider_event+0xb1/frame 0x86edcc88 g_run_events(0,86edcd08,222db60d,83725616,b10094f2,...) at g_run_events+0x19f/frame 0x86edccc4 fork_exit(8070d140,0,86edcd08) at fork_exit+0xa3/frame 0x86edccf4 fork_trampoline() at fork_trampoline+0x8/frame 0x86edccf4 --- trap 0, eip = 0, esp = 0x86edcd40, ebp = 0 --- db I've been poking at this off and on last night. Any ideas? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: Stack Overflow in GEOM
In message 1257671366135...@web6f.yandex.ru, Ilya A. Arkhipov writes: 16.04.2013, 21:56, Cy Schubert cy.schub...@komquats.com: Has anyone see this before? Just updated my CURRENT partitions on my testbed and laptop. The laptop just boots but I've managed to capture this on my testbed (attached to a serial port on another system). This is HEAD from yesterday (Apr 15) morning (PDT). The partition being booted is ada0s1d. On my laptop it's ada0s3a. KSTACK_PAGES is 4. Is there a way to quickly display that kern.kstack_pages from DDB? ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: SAMSUNG SP0802N TK100-24 ATA-7 device ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 76351MB (156368016 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: Maxtor 6Y120P0 YAR41BW0 ATA-7 device ada1: 133.000MB/s transfers (UDMA6, PIO 8192bytes) ada1: 117246MB (240121728 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 ada2 at ata2 bus 0 scbus2 target 0 lun 0 ada2: WDC WD5000AAKS-00D2B0 12.01C02 ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad4 ada3 at ata3 bus 0 scbus3 target 0 lun 0 ada3: WDC WD3200KS-00PFB0 21.00M21 ATA-7 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada3: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad6 SMP: AP CPU #1 Launched! panic: stack overflow detected; backtrace may be corrupted cpuid = 1 KDB: enter: panic [ thread pid 13 tid 19 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db bt Tracing pid 13 tid 19 td 0x872d6000 kdb_enter(80ca7886,80ca7886,80ca9523,86edcae0,1,...) at kdb_enter+0x3d/frame 0x86edca98 panic(80ca9523,86edcb70,80713dd2,86edcbd8,86edcafc,...) at panic+0x141/frame 0x86edcad4 __stack_chk_init(86edcbd8,86edcafc,86edcaf8,86edcafc,64,...) at __stack_chk_init/frame 0x86edcae0 g_label_disk_ident_taste(87b7dc80,86edcbd8,80,0,0,...) at g_label_disk_ident_taste+0x102/frame 0x86edcb70 g_label_taste(80d26b88,872ff500,0,872ff480,872d6000,...) at g_label_taste+0x3ca/frame 0x86edcc6c g_new_provider_event(872ff500,0,25c,80c9798e,0,...) at g_new_provider_event+0xb1/frame 0x86edcc88 g_run_events(0,86edcd08,222db60d,83725616,b10094f2,...) at g_run_events+0x19f/frame 0x86edccc4 fork_exit(8070d140,0,86edcd08) at fork_exit+0xa3/frame 0x86edccf4 fork_trampoline() at fork_trampoline+0x8/frame 0x86edccf4 --- trap 0, eip = 0, esp = 0x86edcd40, ebp = 0 --- db I've been poking at this off and on last night. Any ideas? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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 Hi, It should be related with: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=30160 3+0+current/svn-src-head Author: ivoras Date: Mon Apr 15 16:09:24 2013 New Revision: 249508 URL: http://svnweb.freebsd.org/changeset/base/249508 Log: Introduce glabel labels based on GEOM ident attributes. In this initial implementation, error on the side of conservatism and only create labels for GEOMs of classes DISK and MULTIPATH. Discussed with: trasz Approved by: silence from freebsd-geom@ You were correct. Backing out r249508 in my tree resolves the panic on both hosts. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: Stack Overflow in GEOM
In message CAF-QHFVPZUOSZr-xhOjNgLSgw0aJm8BazEwig-meaP1xZPvwXA@mail.gmail.c om , Ivan Voras writes: On 17 April 2013 00:44, Cy Schubert cy.schub...@komquats.com wrote: You were correct. Backing out r249508 in my tree resolves the panic on both hosts. Hi, Sorry about that - should be fixed by http://svnweb.freebsd.org/base?view=revisionrevision=249564 . hey, no prob. Fetching it now. Thanks. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: ipfilter(4) needs maintainer
In message CAPyFy2BaoF-7t-skTUPt97hkRgdjO-KbB2-vhjOus-nutNO5Fw@mail.gmail.c om , Ed Maste writes: On 15 April 2013 16:12, Cy Schubert cy.schub...@komquats.com wrote: The existing license isn't that BSD-friendly either, which is why it lives in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. A person can always load it anyway. There's a plan[1] to remove the remaining GPL components from base over time. Updating to the last ipfilter that's under the current license is probably the path forward, unless it moves out to ports. [1] https://wiki.freebsd.org/GPLinBase That's been pointed out to me. IPF's build/install scripts place header files in /usr/include, IMO unacceptable for a port. Going forward we go to 4.1.34 (still under the old license) then look at options. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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
Ipfilter pre-Vendor Import Issue
Hi, Originally this email was a here is how I'm planning on doing it kind of email but now that svn 1.8 broke the third step I need some help. I've been getting the flattening of the ipfilter vendor branch right and working on the importation of ipfilter 5.1.2 into my own test SVN repo. (Now that we have Darren Reed's permission to use the previous license, I will import 5.1.2). I've prepared the tree by flattening the layout as discussed in 5.3.1 of the developers handbook. It worked until I upgraded my SVN port from 1.7.2 to 1.8. Here are the steps I took and the results of the last failing step. I will also discuss what I believe should be the solution. Given I'm not an SVN expert I need some advice and help. To flatten the ipfilter vendor branch I did the following. This worked before using svn 1.7.2 and continues to work using 1.8. cd $MY_WORK_DIR/vendor/ipfilter for I in */contrib/ipfilter; do ( cd $I svn mv $(svn list) ../.. cd ../.. svn rm contrib svn propdel -R svn:mergeinfo ) done cd $MY_WORK_DIR/vendor-sys/ipfilter for I in */sys/contrib/ipfilter; do ( cd $I svn mv $(svn list) ../../.. cd ../../.. svn rm sys svn propdel -R svn:mergeinfo ) done cd $MY_WORK_DIR svn ci vendor/ipfilter vendor-sys/ipfilter The second step is to turn off keyword expansion as recommended by the developers guide. This worked before under 1.7.2 and continues to work under svn 1.8. cd $MY_WORK_DIR/vendor/ipfilter svn propdel svn:keywords -R . cd $MY_WORK_DIR/vendor-sys/ipfilter svn propdel svn:keywords -R . cd $MY_WORK_DIR svn ci vendor/ipfilter vendor-sys/ipfilter It's the last step of the flattening process discussed in the developers guide that worked under svn 1.7.2 but does not work under svn 1.8. What I planned on doing was this: cd $MY_WORK_DIR/current/contrib/ipfilter svn merge --record-only \ svn+ssh://svn.FreeBSD.org/base/vendor/ipfilter/dist@NNN cd $MY_WORK_DIR/current/sys/contrib/ipfilter svn merge --record-only \ svn+ssh://svn.FreeBSD.org/base/vendor-sys/ipfilter/dist@NNN (Don't worry about the NNN, I will fill that in with the appropriate rev.) Unfortunately it doesn't work any more. Here is what svn spit out at me. slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfilte r/dist@252548 svn: E205000: Try 'svn help merge' for more information svn: E205000: Source and target must be different but related branches svn: E205000: Source and target have no common ancestor: 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist@252548' and '.@unspecified' slippy$ My solution is, for I in `find . -type f`; do svn merge --record-only -r 1:HEAD file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist/$I@252548; done (r252548 is the revision where I turned off keyword expansion for the flattened ipfilter vendor trees.) I'm not a subversion expert so my question is, am I going down the right path here? Or, is there a better way to address the error above? Once I address this I will be able to import the new ipfilter into the vendor and vendor-sys branches (which I managed to get to under svn 1.7.2). To answer the obvious question, I've done svn upgrade and when that didn't help I subsequently used a fresh checkout from my local test SVN repo, so this is not an issue. Any and all help would be appreciated. Thanks for your help. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
In message 20130705084649.gc67...@freebsd.org, Gleb Smirnoff writes: Cy, On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote: C Unfortunately it doesn't work any more. Here is what svn spit out at me. C C slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter C slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfil te C r/dist@252548 C svn: E205000: Try 'svn help merge' for more information C svn: E205000: Source and target must be different but related branches C svn: E205000: Source and target have no common ancestor: C 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist@252548' and C '.@unspecified' C slippy$ AFAIU, the problem is that current contrib/ipfilter was never merged from vendor/ipfilter. So, actually we are dealing with a first import (from subversion viewpoint), not n-th. That's unfortunate. What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter Having ipfilter in one place instead of two (vendor and vendor-sys) makes a lot more sense. I suppose we could put ipfilter's kernel components in sys/netpfil but what about the userland sources? Also see my reply below regarding keeping it in contrib. In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? The reason to keep ipftilter in contrib is to maintain consistency with other contributed software such as bind, nvi, sendmail, pf, and a host of other notable software we don't maintain ourselves. Maintaining consistency with other contributed software should probably be maintained. I'm open to moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as long as consistency is maintained across the board. Do you think we should put the userland sources also in the same location or should we maintain a similar separation we do today? I'm open to both however I'd prefer keeping all vendor software (kernel and userland) in one location. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
In message 51da85cf.3000...@freebsd.org, Andre Oppermann writes: On 05.07.2013 20:38, Cy Schubert wrote: In message 20130705084649.gc67...@freebsd.org, Gleb Smirnoff writes: What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter Having ipfilter in one place instead of two (vendor and vendor-sys) makes a lot more sense. I suppose we could put ipfilter's kernel components in sys/netpfil but what about the userland sources? Also see my reply below regarding keeping it in contrib. In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? The reason to keep ipftilter in contrib is to maintain consistency with other contributed software such as bind, nvi, sendmail, pf, and a host of other notable software we don't maintain ourselves. Maintaining consistency with other contributed software should probably be maintained. I'm open to moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as long as consistency is maintained across the board. Do you think we should put the userland sources also in the same location or should we maintain a similar separation we do today? I'm open to both however I'd prefer keeping all vendor software (kernel and userland) in one location. I think the main distinction here is whether the adaptions to FreeBSD are kept local (resulting in almost a fork) or are fed upstream so that successive updates require less or no local changes. I see no problem feeding update upstream. The email I just received from Darren (cc'd Gleb and yourself) is likely to lead to this kind of relationship. Having the kernel part in sys/netpfil certainly makes it easier for kernel people to adjust it to changed realities. True. I'm thinking we should do the same with the userland side of ipfilter, keeping everything consistent. Also, I think putting all of the vendor bits regardless of whether they're destined for kernel or userlan into vendor/ or vendor-sys/ should make it simpler as well. What are your thoughts? IIRC ipfilter also has very messy ifdef's all over the place for every possible ancient version of FreeBSD. This probably should be cleaned up (and upstreamed) as well. Yes. There's a lot of cruft in there for operating systems that are no longer relevant as well. At least we can push some of the FreeBSD cleanup upstream. Initially I'd like to import v5-1-2 into our vendor branch (either vendor/ or vendor-sys/ for the complete tarball) then svn merge into sys/netpfil/ (for kernel) and netpfil/ (for userland). Do you have any additional thoughts on any of this? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ipfilter pre-Vendor Import Issue
In message 20130708134400.gh67...@glebius.int.ru, Gleb Smirnoff writes: Cy, On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote: C What I'd prefer to see is the following: C C - commit new ipfilter untouched to vendor-sys/ipfilter C - nuke sys/contrib/ipfilter C - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter C C Having ipfilter in one place instead of two (vendor and vendor-sys) makes a C lot more sense. C C I suppose we could put ipfilter's kernel components in sys/netpfil but wha t C about the userland sources? Also see my reply below regarding keeping it i n C contrib. IMO, it is possible to keep a bulk checkout of ipfilter in vendor/ipfilter, but merge kernel files separately to sys/netpfil/ipfilter, and separately merge userland files to appropriate place. C In future imports do: C C - commit newer ipfilter to vendor-sys/ipfilter C - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter C C What's the reason to keep code in contrib? C C The reason to keep ipftilter in contrib is to maintain consistency with C other contributed software such as bind, nvi, sendmail, pf, and a host of C other notable software we don't maintain ourselves. Maintaining consistenc y C with other contributed software should probably be maintained. I'm open to C moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as C long as consistency is maintained across the board. C C Do you think we should put the userland sources also in the same location C or should we maintain a similar separation we do today? I'm open to both C however I'd prefer keeping all vendor software (kernel and userland) in on e C location. The BSD license allows us to put the code into FreeBSD w/o any separation. So the question is: what is more handy to us? What do we actually gain having contrib/ipf, assuming we got vendor branch already? What we lose is: - more complex Makefiles - more complex hacking: edit files in one place, run make in other How is this for a plan? Instead of importing the kernel bits into vendor-sys/ipfilter and the userland bits into vendor/ipfilter, the base tarball should be imported into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We keep the complete tarball imported into one place in the tree. Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and netpfil/ipfilter (for userland bits). We should probably think of moving pf and ipfw into the new subdirectory as well, but that's for a future discussion. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: [head tinderbox] failure on i386/i386
!PPCSubTarget.hasFPCVT()) return false; Value *Src = I-getOperand(0); -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 ?
In message CAJ-Vmo=_vLkMZn02EPUmpvqugcT8ga1_Kqs=XU49SGUNGEO0Pw@mail.gmail.c om , Adrian Chadd writes: On 18 July 2014 07:34, krad kra...@gmail.com wrote: that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. Then do the port and maintain it. The problem isn't the desire to keep things up to date, it's a lack of people who want that _and_ are willing/able to do it _and_ are funded somehow. Funding is the issue. Sure, some of us maintain software because a personal need however without funding one has to fit maintaining software into whatever time is left. For those of us who do this without funding you manage to squeeze in an hour here or there. So, please step up! We'll all love you for it. Many hands make light work. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 ?
In message 20381608.hhy3qfh...@overcee.wemm.org, Peter Wemm writes: On Saturday 19 July 2014 13:06:52 Baptiste Daroussin wrote: On Fri, Jul 18, 2014 at 03:22:18PM -0400, Allan Jude wrote: On 2014-07-18 15:07, Adrian Chadd wrote: On 18 July 2014 07:34, krad kra...@gmail.com wrote: that is true and I have not problem using man pages, however tha= ts not the way most of the world work and search engines arent exactly new = either. We should be trying to engage more people not less, and part of tha= t is reaching out. =20 Then do the port and maintain it. =20 The problem isn't the desire to keep things up to date, it's a la= ck of people who want that _and_ are willing/able to do it _and_ are fu= nded somehow. =20 So, please step up! We'll all love you for it. =20 =20 =20 -a ___ 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 =20 At vBSDCon Bapt@ volunteered to port the newer pf back to FreeBSD, = after spending some hours driving with Henning. =20 I tried and broke pf for month and my changes have been reverted, thi= s is not as simple as it looks like, our code as diverge a lot in some par= t and we do support things that openbsd does not (vimage). Sync features re= quires us to be very careful, my priorities went elsewhere since that time, = so now I will probably only focus on bringing features I care about, and not= the entirely new pf. =20 So no do not count me as volunteer to maintain pf, I ll probably do s= ome work but not a full sync. If anyone is looking for a really useful chunk to work on, please go ba= ck over=20 the pf history in openbsd and find where they added ipv6 fragment suppo= rt. It=20 was fairly well contained and didn't appear to be a big deal to port. = They=20 did do something with mbuf tags that I'm suspicious of though. IPv6 fragments are the biggest pain point we have on the freebsd.org cl= uster -=20 yes, we use pf and IPv6 extensively, but dns with ipv6 involved is real= ly=20 painful without fragment support. We sort-of work around it by using dedicated IPv6 address that has noth= ing but=20 the dns resolver clients and allow ipv6 fragments to it. Its not idea= l but=20 it gets over the worst problems. The other thing we had to do for usability is stop state tracking for u= dp dns=20 =2D the sheer update rate was causing collisions and state drops / resets= of=20 other connections to the point of being really hard to use. Those two tweaks - stopping heavy dns use from thrashing the state tabl= es, and=20 having a safe place to send fragments makes it quite usable for freebsd= .org. But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 ?
In message 53ccf596.1070...@yandex.ru, Andrey V. Elsukov writes: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20.07.2014 18:15, Maxim Khitrov wrote: In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. Even if you just drop current PF from FreeBSD, there is nobody, who want to port new PF from OpenBSD. And this is not easy task, as you may think. Gleb has worked on rewriting PF more than half year. So, return back all improvements after import will be hard enough and, again, nobody want to do it. :) One way or another something needs to be done and agreed it would be a lot of work. Our options are, a) Import OpenBSD pf thereby throwing away our current investment in pf. All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would be all for naught. We do get a new pf though. Won't be a quality port though. Personally, not my #1 option. b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we do save the work we put into our pf. Once again a lot of work. We'd be introducing incompatibility. c) Do nothing. It goes without saying that pf would suffer rot and eventually we would need to do something. d) Yank pf from tree. An option but probably not a great one. We do have two other packet filters in the kernel (ipfw and ipfilter) however they are different beasts with different capabilities. I think the reason we have the packet filters we do have is for the capabilities they bring to the table. I for one have run more than one in the same kernel because each has different capabilities. e) We could add capability to pf on a piecemeal basis. Option (b) but as time permits. Remember, people have jobs and commitments. Funding would help address this. f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more compatible with our IP stack? Could this be an option? Anything we do should work with VIMAGE and be able to handle nat66 as well. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 ?
In message alpine.lrh.2.11.1407201430030.2...@nber7.nber.org, Daniel Feenberg writes: On Sun, 20 Jul 2014, Lars Engels wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supporte d linux thing as well, so the world could be rid of iptables. However i gues s thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. No one with authority has yet said that If an updated pf were available, would be welcomed. Rather they have said An updated pf would not be suitable, as it would be incompatible with existing configuration files. If the latter is indeed the case, there is little incentive for anyone to go to the effort of porting the newer pf. After all, the reward for the work is chiefly in glory, and if there is to be no glory, the work is unlikely to be done. I disagree. One does not do this for the glory. One does this because the nail hurts enough to do something about it. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 ?
Sorry for the late reply. It's a busy time right now. In message 53d0239d.1050...@a1poweruser.com, Fbsd8 writes: Cy Schubert wrote: On 20.07.2014 18:15, Maxim Khitrov wrote: In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. Even if you just drop current PF from FreeBSD, there is nobody, who want to port new PF from OpenBSD. And this is not easy task, as you may think. Gleb has worked on rewriting PF more than half year. So, return back all improvements after import will be hard enough and, again, nobody want to do it. :) One way or another something needs to be done and agreed it would be a lot of work. Our options are, a) Import OpenBSD pf thereby throwing away our current investment in pf. All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would be all for naught. We do get a new pf though. Won't be a quality port though. Personally, not my #1 option. b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we do save the work we put into our pf. Once again a lot of work. We'd be introducing incompatibility. c) Do nothing. It goes without saying that pf would suffer rot and eventually we would need to do something. d) Yank pf from tree. An option but probably not a great one. We do have two other packet filters in the kernel (ipfw and ipfilter) however they are different beasts with different capabilities. I think the reason we have the packet filters we do have is for the capabilities they bring to the table. I for one have run more than one in the same kernel because each has different capabilities. e) We could add capability to pf on a piecemeal basis. Option (b) but as time permits. Remember, people have jobs and commitments. Funding would help address this. f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more compatible with our IP stack? Could this be an option? Anything we do should work with VIMAGE and be able to handle nat66 as well. Hello Cy; Finally a voice I recognize. If I remember correctly you stepped up to the plate earlier this year and did for ipfilter the same kind of things Last autumn. this thread is talking about for pf. IE; apply upstream maintenance and convert to FreeBSD standards. I think your work was a BSD fork of Darrow's ipfilter which from this point on all upstream maintenance must be hand merged into the BSD fork. I am a long time ipfilter user and Actually we did not fork ipfilter. It's simply included into our tree, with a few modifications. thank you for your dedication and work ethics getting the updated ipfilter into 10.0 and 9.3 so quickly. You're welcome. I too am a long time ipfilter user (Solaris and FreeBSD). So as someone who has been there and done that already you have unique experience to really know the size of the task in hours to accomplish a pf upgrade. Could you list the tasks and hours it took you to perform the ipfilter upgrade so readers can have a real insight into what they are asking for? The experience is not unique. Every developer pretty much follows the same process when importing code into the tree. As for tasks, the ipfilter import was relatively simple compared to some others. Remember, ipfilter was designed to be run on any of the BSDs, SunOS, Solaris, and HP/UX, IRIX, and Tru64 UNIX. That made upgrading from 4.1.28 to 5.1.2 simpler than pf which is written only for OpenBSD and its stack. I agree with your option e above, but I would re-word it this way. Using the pf fork we already have in place, hand merge upstream differences in piecemeal chunks as time permits. The openbsd new syntax being the first chunk, closely followed by VIMAGE awareness. Personally I would choose option e because of $JOB and $FAMILY commitments. Adding the new OpenBSD syntax may be more difficult than we might think. The new syntax may be related to a new internal structure of pf. If the new pf is a rewrite (ipfilter 5.1.2 was a rewrite of large chunks of code), then you have no option but to do a wholesale import and retrofit our mods back into it, if they would even fit at all. I think the first task for anyone taking this on would be to familiarize oneself with the current pf code in FreeBSD and what was done to make it fit and to enhance it, then familiarize oneself with the new pf to get a feel for what work would
Re: FreeBSD Quarterly Status Report - Second Quarter 2014
In message 20140724183353.gl1...@hub.freebsd.org, Glen Barber writes: New Automounter Contact: Edward Tomasz Napieral/a tr...@freebsd.org Deficiencies in the current automounter, amd(8), are a recurring problem reported by many FreeBSD users. A new automounter is being developed to address these concerns. The automounter is a cleanroom implementation of functionality available in most other Unix systems, using proper kernel support implemented via an autofs filesystem. The automounter supports a standard map format, and will integrate with the Lightweight Directory Access Protocol (LDAP) service. Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd currently integrates with NIS as well. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 Quarterly Status Report - Second Quarter 2014
In message 20140725211249.ga3...@brick.home, Edward Tomasz =?utf-8?Q?Napiera= C5=82a?= writes: On 0725T1019, Cy Schubert wrote: In message 20140724183353.gl1...@hub.freebsd.org, Glen Barber writes: New Automounter Contact: Edward Tomasz Napieral/a tr...@freebsd.org Deficiencies in the current automounter, amd(8), are a recurring problem reported by many FreeBSD users. A new automounter is being developed to address these concerns. The automounter is a cleanroom implementation of functionality available in most other Unix systems, using proper kernel support implemented via an autofs filesystem. The automounter supports a standard map format, and will integrate with the Lightweight Directory Access Protocol (LDAP) service. Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd currently integrates with NIS as well. It's just a matter of testing, apart from a trivial shell script. Would you be able to help me with this? Sure! Just point me in the direction of the patches. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 ?
In message 53d395e4.1070...@fastmail.net, Darren Reed writes: On 24/07/2014 1:42 AM, Cy Schubert wrote: But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. ipfiler 5 handles fragments for ipv6. Switching gears and leaving the discussion of ipv6 fragments to mention nat66. A lot of people have been talking about nat66. I could be wrong but I don't think it can handle nat66. I need to do some testing to verify this. I remember reading on sourceforge that it was on your todo list. It doesn't look like it was checked off as being completed. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 ?
In message CAN6yY1uHJn4xA-5zFr4fZez3FyXi7tT0LmhyR8yWkqG7k1A+=A@mail.gmail.c om , Kevin Oberman writes: On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed darr...@freebsd.org wrote: On 27/07/2014 4:43 AM, Cy Schubert wrote: In message 53d395e4.1070...@fastmail.net, Darren Reed writes: On 24/07/2014 1:42 AM, Cy Schubert wrote: But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. ipfiler 5 handles fragments for ipv6. Switching gears and leaving the discussion of ipv6 fragments to mention nat66. A lot of people have been talking about nat66. I could be wrong but I don't think it can handle nat66. I need to do some testing to verify this. I remember reading on sourceforge that it was on your todo list. It doesn't look like it was checked off as being completed. IPFilter 5 does IPv6 NAT. With the import of 5.1.2, map, rdr and rewrite rules will all work with IPv6 addresses. NAT66 is a specific implementation of IPv6 NAT behaviour. Cheers, Darren And all IPv6 NAT is evil and should be cast into (demonic residence of your choosing) on sight! That I don't disagree with, IPv6 NAT makes no logical sense. Having said that I've received emails asking about NAT66 specifically. It is on people's minds. NAT on IPv6 serves no useful purpose at all. It only serves to complicate things and make clueless security officers happy. It adds zero security. It is a great example of people who assume that NAT is a security feature in IPv4 (it's not) so it should also be in IPv6. Agreed. People think NAT is a security feature (and those same people tout the security of reverse proxies too). It's a checkbox item. The problem is that this meme is so pervasive that even when people understand that it is bad, they still insist on it because there will be an unchecked box on the security checklist for All systems not pubic servers are in RFC1918 space? -- YES NO. The checklist item should be (usually) All systems behind a stateful firewall with an appropriate rule set? -- YES NO as it is a stateful firewall (which is mandatory for NAT that provides all of the security. Exactly! That's pretty much what people who know better are saying. I say usually because the major research lab where I worked ran without a firewall (and probably still does) and little, if any, NAT. It was tested regularly by red teams hired by the feds and they never were able to penetrate anything due to a very aggressive IDS/IPS system, but most people and companies should NOT go this route. I have IPv6 at home (Comcast) and my router runs a stateful firewall with a rule set functionally the same as that used for IPv4 and that provides the protection needed. Not part of this discussion: I think you need both. Firewalls and IPS with IDS. OTOH using NAT as a means of securing a network is illogical. I worked at one place where they would NAT already NATted packets, themselves having previously been processed by previous NAT, all for the sake of security only terribly broke the network to the point there were issues to numerous to discuss in a quick reply here. So putting support for NAT66 or any IPv6 NAT into a firewall is just making things worse. Please don't do it! -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: [PATCHES] Two fixes for lpd/lpc for review and test
In message v04210102b472f8589876@[128.113.24.47], Garance A Drosihn writes: I've been using the patch from PR 13549 on 4 -stable stable machines for about 3 weeks with no ill effects -- and it fixes the problem. In my next installment, I'm going to try a subject of "Make Money Fast via Sex With Green Card Lawyers" You can get screwed by a lawyer without sex. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX GroupInternet: [EMAIL PROTECTED] ITSD [EMAIL PROTECTED] Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Upgrading to 4.0
In message [EMAIL PROTECTED], Ruslan Ermilov writes: [Redirected to -current] On Wed, Feb 09, 2000 at 11:49:30AM -0800, Cy Schubert wrote: Can FreeBSD be upgraded from 3.4-stable to 4.0-current from source. When I installed -current on my testbed I got a number of sig 12's (SIGSYS), e.g. fix one, reiterate, fix the next one, etc., that I finally gave up and installed 4.0-current from snapshot. The reason for asking is that I'm installing a console server in Vancouver, a 30 minute flight by helijet from Victoria. My options are to install -stable and subsequently install 4.1 from source, negating the requirement to travel to Vancouver to perform the installation, or install from CDROM or FTP requiring console access. Any thoughts? Without providing any in-depth details: 0. `uname -r' returns 3.x 1. make buildworld 2. make buildkernel 3. make installkernel 4. reboot with new kernel in signle-user mode 5. make -DNOINFO installworld 6. make buildkernel installkernel (again) 7. make installworld (again, without -DNOINFO) Excellent. I'll try it on my testbed and let you know how it goes. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX GroupInternet: [EMAIL PROTECTED] ITSD Province of BC "COBOL IS A WASTE OF CARDS." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Tripwire Fails to build under 5.x
In message [EMAIL PROTECTED], Kris Kennaway writes: On Wed, Oct 01, 2003 at 03:49:30PM +0300, J8keR wrote: Does this mean wait until its fixed or am I missing some update ? It means wait until it's fixed, or fix it yourself and submit the patch. There are a lot of C++ issues with it, notably STLport issues. STLport that comes with tripwire does not build under -CURRENT. The STLport in the port collection is too new because tripwire depends on some unique quirks within the old STLport (as documented in their documentation -- STLport was too new and fluid so they chose to code for a specific version). I'm slowly but surely progressing. If people wish to expedite the process, I would welcome a patch. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
In message [EMAIL PROTECTED], boyd, rounin write s: From: Bruce M Simpson [EMAIL PROTECTED] During my time in an investment bank, installations were usually hosed in this way by human error (systems administrators removing a file by accident, etc) ... yup, it's rare i've seen flakey h/w. but i do remember one sysadmin (when i was a contract sysadmin) who on day 2 chown'd the whole source tree to himself on a development m/c. ugly. there were backups but 'that would be too costly [in time]' to do a clean restore. I've seen that too. An end user got permission from management to the root account, e.g. management ordered us to give her the root pw on a Tru64 box. She chowned every file on the system to herself. Very ugly indeed. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message [EMAIL PROTECTED], Jacques A. Vidrine wri tes: So can we just have a statically linked /bin/sh and get on with life? I was thinking the same thing myself a few days ago. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with reboot
In message v2yda48cf211004280807r7e6089i3e0b9fef0e494...@mail.gmail.com, Dmit ry Krivenok writes: Hello! I have a trouble with my FreeBSD-CURRENT virtual machine running on VmWare ESX server. uname -a prints: FreeBSD host 9.0-CURRENT FreeBSD 9.0-CURRENT #16 r207299: Wed Apr 28 04:15:07 UTC 2010 r...@host:/usr/obj/usr/src/sys/GENERIC amd64 The problem lies in that FreeBSD hangs after reboot command. I see the following on console: http://www.freeimagehosting.net/image.php?8885b3c6ea.png Is it a known problem? Are there any solutions? Thanks in advance! I'm experiencing the same on real hardware with AMD Sempron on an MCI board. On my system this occurs in i386 mode. As it's my testbed I have no such problems under 7.X or 8.X. I also have the same problem on my Acer 3623NWXMi laptop (with 1.6 GHz Pentium M CPU, 1.5 GB memory, and 120 GB hard disk upgrades, and the latest Acer 1.6 BIOS upgrade for this computer). -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org e**(i*pi)+1=0 ___ 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: Move banner to games
In message 4cadc453.7010...@googlemail.com, army.of.root writes: On 10\10\02 18:48, Paul B Mahol wrote: On 10/2/10, Brandon Goochjamesbrandongo...@gmail.com wrote: On Sat, Oct 2, 2010 at 7:36 AM, Paul B Maholone...@gmail.com wrote: Hi, I see no point to have it in usr/bin. Cool! This is the first time I've heard of this program! How come the folks at my university who manage the line printers have never let me on to this?! Ahh -- wait a sec -- I'm beginning to see your point about the whole move it to games thing... -Brandon aka The Green Bar Bandit NetBSD and OpenBSD have this version in games and horizontal version of banner in usr/bin. I see no point to have this program(s) in base at all. I will just stop here. Hi, A horizontal version of banner could be nice for motd etc. I like banner. It makes me smile and think that FreeBSD is a cosy place to be. It's been in the base for decades. People used it to print banners on reports, before laser and ink jet printers were around, when tractor feed printers ruled. Banner was more than just a game. People used it for production work. I suppose you could still use it for its intended purpose today however with the graphical tools we have today it's a little archaic. Having said that, it doesn't take up a lot of space and should probably remain where it is. BTW, I'm of the age where I did use it and tools like it (on the IBM mainframe) for real work. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org e**(i*pi)+1=0 ___ 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: Move banner to games
In message 20101007154058.e68d71c...@ptavv.es.net, Kevin Oberman writes: Date: Thu, 07 Oct 2010 16:49:43 +0200 From: Daniel Braniss da...@cs.huji.ac.il Sender: owner-freebsd-curr...@freebsd.org In message 4cadc453.7010...@googlemail.com, army.of.root writes: On 10\10\02 18:48, Paul B Mahol wrote: On 10/2/10, Brandon Goochjamesbrandongo...@gmail.com wrote: On Sat, Oct 2, 2010 at 7:36 AM, Paul B Maholone...@gmail.com wrot e: Hi, I see no point to have it in usr/bin. Cool! This is the first time I've heard of this program! How come th e folks at my university who manage the line printers have never let m e on to this?! Ahh -- wait a sec -- I'm beginning to see your point about the whole move it to games thing... -Brandon aka The Green Bar Bandit NetBSD and OpenBSD have this version in games and horizontal version of banner in usr/bin. I see no point to have this program(s) in base at all. I will just stop here. Hi, A horizontal version of banner could be nice for motd etc. I like banner. It makes me smile and think that FreeBSD is a cosy place to be. It's been in the base for decades. People used it to print banners on reports, before laser and ink jet printers were around, when tractor fee d printers ruled. Banner was more than just a game. People used it for production work. I suppose you could still use it for its intended purpos e today however with the graphical tools we have today it's a little archai c. Having said that, it doesn't take up a lot of space and should probably remain where it is. BTW, I'm of the age where I did use it and tools like it (on the IBM mainframe) for real work. ah memories, I had the walls of my office covered with pi with some very lo ng precision :-) I'm so sorry. I'm more prone to remember the ASCII rendering of the artwork of rather long images from a popular magazine which would certainly (and properly) be unacceptble in the workplace today. :-) I can recall my first exposure to ASCII art. I was 17 in Computing Science class in high school. A friend had brought in some artwork his brother had printed on the mainframe at the University of Alberta. The source was a Fortran program with a huge number of punched cards as input. It certainly wouldn't be accepted anywhere here either. What I found quite intriguing was the ASCII art produced by arcane single line APL programs. You could pack a lot of function into a very few bytes of code. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org e**(i*pi)+1=0 ___ 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: ntpd errors after upgrade on current amd64
In message 551da257.6060...@freebsd.org, Jung-uk Kim writes: This is a multi-part message in MIME format. --090800070300040107060309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/01/2015 11:32, Manfred Antar wrote: After build install world on current ntpd doesn't work. Here is error: FreeBSD/amd64 (pozo.com) (ttyu0) login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax error ntp_crypto.c was not properly merged. Basically, the fix for SA-14:31.ntp was applied twice. Please try the attached patch. Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%2 fails: Can't assign requested address A separate issue, I think. Jung-uk Kim * Note: ntp_parser.y is redundant and it was the root cause of inconsistent builds and build failures, i.e., ntp_parser.c and ntp_parser.h may be regenerated on the *source* directory depending on phase of the moon. Although we can re-gen them after r280915, upstream does not support BSD yacc. Ntp_parser.y is not redundant. It is referenced by ntp_parser.c. I put that fix in two days ago. I'll re-merge based on your second patch/the posted fix. I'll try it first in the port though. -- Cheers, Cy Schubert cy.schub...@komquats.com or cy.schub...@cschubert.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: ntpd errors after upgrade on current amd64
In message 20150403080118.ga2...@roberto-aw.eurocontrol.fr, Ollivier Robert w rites: According to Cy Schubert on Thu, Apr 02, 2015 at 06:26:42PM -0700: Ntp_parser.y is not redundant. It is referenced by ntp_parser.c. I put that fix in two days ago. No, it is the source of ntp_parser.c/h through yacc (or bison) as jkim said. In theory, you have only the .y and during build you generate the .c/.h. In practice, you always use the ntp_parser.c/.h that come pre-built and build wi th that. As jkim shows, the generated file can be quite different. The fix has just been committed. 4.2.8p2 should be released shortly to resolve the other issues. I've added an ntp-rc port to track the release candidates. -- Cheers, Cy Schubert cy.schub...@komquats.com or cy.schub...@cschubert.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: Build failed in Jenkins: FreeBSD_HEAD #2725
In message 861766483.4.1430730824975.javamail.jenk...@jenkins-9.freebsd.org , jenkins-ad...@freebsd.org writes: See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2725/changes Changes: [cy] MFV ntp 4.2.8p2 (r281348) Reviewed by:delphij (suggested MFC) Approved by: roberto Security: CVE-2015-1798, CVE-2015-1799 Security: VuXML ebd84c96-dd7e-11e4-854e-3c970e169bc2 MFC after:1 month [neel] Emulate the 'CMP r/m8, imm8' instruction encountered when booting a Wi ndows Vista guest. Reported by: Leon Dang (ld...@nahannisys.com) MFC after:1 week -- [...truncated 125654 lines...] === usr.bin/uudecode/tests (depend) --- usr.sbin.depend__D --- --- depend_subdir_ntp --- mkdep: compile failed *** [.depend] Error code 1 make[5]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin /ntp/ntpd 1 error make[5]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin /ntp/ntpd *** [_sub.depend] Error code 2 make[4]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin /ntp 1 error make[4]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin /ntp *** [depend_subdir_ntp] Error code 2 make[3]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin --- usr.bin.depend__D --- A failure has been detected in another branch of the parallel make make[5]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/ uudecode/tests *** [_sub.depend] Error code 2 make[4]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/ uudecode 1 error make[4]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/ uudecode *** [depend_subdir_uudecode] Error code 2 make[3]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin --- depend_subdir_svn --- A failure has been detected in another branch of the parallel make make[6]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/ svn/lib/libsvn_client *** [_sub.depend] Error code 2 make[5]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/ svn/lib 1 error make[5]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/ svn/lib *** [_sub.depend] Error code 2 make[4]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/ svn 1 error make[4]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/ svn *** [depend_subdir_svn] Error code 2 make[3]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin 2 errors make[3]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin *** [usr.bin.depend__D] Error code 2 make[2]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/ --- usr.sbin.depend__D --- --- depend_subdir_sendmail --- echo sendmail: https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/Fr eeBSD_HEAD/tmp/usr/lib/libc.a https://jenkins.freebsd.org/job/FreeBSD_HEAD /ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libutil.a https://jenkins.freebsd.o rg/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libwrap.a https: //jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/lib/libsm/l ibsm.a https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_H EAD/lib/libsmdb/libsmutil.a https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws /obj/builds/FreeBSD_HEAD/tmp/usr/lib/libssl.a https://jenkins.freebsd.org/j ob/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libcrypto.a .depen d A failure has been detected in another branch of the parallel make make[4]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin /sendmail *** [depend_subdir_sendmail] Error code 2 make[3]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin 2 errors make[3]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin *** [usr.sbin.depend__D] Error code 2 make[2]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/ 2 errors make[2]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/ *** [_depend] Error code 2 make[1]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/ 1 error make[1]: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/ *** [buildworld] Error code 2 make: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/ 1 error make: stopped in https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/ Build step 'Execute shell' marked build as failure I cannot see where the problem is. All local tests, including universe, have built cleanly. -- Cheers, Cy Schubert cy.schub...@komquats.com or cy.schub...@cschubert.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd
Re: Build failed in Jenkins: FreeBSD_HEAD #2725
I think jenkins copy of head still contains ntp_parser.y. I see no issue here. Cy Schubert cy.schub...@cschubert.com You need to do a better job at figuring out why you broke things. This is not the first time you've broken things with an ntp import. -- Craig On May 4, 2015 8:45 AM, Cy Schubert cy.schub...@komquats.com wrote: That file was deleted long ago. Cy Schubert cy.schub...@cschubert.com On May 4, 2015 7:49 AM, Craig Rodrigues rodr...@freebsd.org wrote: On Monday, May 4, 2015, Cy Schubert cy.schub...@komquats.com wrote: I cannot see where the problem is. All local tests, including universe, have built cleanly. In this log: https://jenkins.freebsd.org/job/FreeBSD_HEAD/2725/console search for: error: version control conflict marker in file -- 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: Build failed in Jenkins: FreeBSD_HEAD #2725
Thanks. That fixed the jenkins build. Cy Schubert cy.schub...@cschubert.com On May 4, 2015 10:52 AM, Li-Wen Hsu lw...@freebsd.org wrote: On Mon, May 04, 2015 at 10:46:10 -0700, Garrett Cooper wrote: On May 4, 2015, at 10:38, Cy Schubert cy.schub...@komquats.com wrote: I think jenkins copy of head still contains ntp_parser.y. I see no issue here. Cy Schubert cy.schub...@cschubert.com You need to do a better job at figuring out why you broke things. This is not the first time you've broken things with an ntp import. I don’t see that file either… $ ls contrib/ntp/ntpd/ntp_parser.y ls: contrib/ntp/ntpd/ntp_parser.y: No such file or directory $ svnversion 282423M $ svn status | grep -v \? M Makefile I wiped out the workspace, it will do a fresh checkout on next build. Let's see if this helps. Li-Wen -- Li-Wen Hsu lw...@freebsd.org http://lwhsu.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: Panic from vesa_configure()
In message <CAJ-VmonGOs2f+rzciEcV=VuaNrZt0hqNePQx4LZDWu6BxuR9NQ@mail.gmail.c
om>
, Adrian Chadd writes:
> Ok,
>
> So try adding this check:
>
> vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> if (vmbuf == NULL) {
> printf("%s: x86bios_alloc failed!\n", __func__);
> goto fail;
> }
>
> ... that call shouldn't be failing, but if it's truely failing on the
> bcopy(), the only reason is because vmbuf is NULL.
Thanks. I'll try this.
vesa.c hasn't changed for a while so I suspect the root cuase may be
somewhere else (we're probably treating the symptom here). Nice thing about
using the same mobo and cpu combination on all my machines (except
laptops), failures are completely reproducible. Might be a good idea to put
in a dtrace probe too.
--
Cheers,
Cy Schubert <cy.schub...@komquats.com> or <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic from vesa_configure()
In message <CAGSa5y0QiKV9SgJYJ_mz3SnJGNjieHSvYP8nLjt9eWXo4RU6ww@mail.gmail.c om> , Jeremie Le Hen writes: > On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd <adrian.ch...@gmail.com> wrote > : > > can you copy/paste the file:line that each of those stackframes represents? > > > > I may have an idea or two.. > > Sure here we go: > > (kgdb) list *vesa_configure+0x270 > 0x80b25cd0 is in vesa_configure (/usr/src-svn/sys/dev/fb/vesa.c:827). > > (kgdb) list *vga_init+0x65 > 0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402). > > (kgdb) list *isavga_attach+0x92 > 0x80b9afd2 is in isavga_attach (/usr/src-svn/sys/isa/vga_isa.c:224). Here is what I see. Only happens on real hardware (not VirtualBox VMs). uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) acpi_alloc_wakeup_handler: can't alloc wake memory orm0: at iomem 0xc-0xcc7ff on isa0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0x80bb7284 stack pointer = 0x28:0x81e4f960 frame pointer = 0x28:0x81e4f970 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 = 0 (swapper) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x81e4f4f0 vpanic() at vpanic+0x182/frame 0x81e4f570 panic() at panic+0x43/frame 0x81e4f5d0 trap_fatal() at trap_fatal+0x351/frame 0x81e4f630 trap_pfault() at trap_pfault+0x1e4/frame 0x81e4f690 trap() at trap+0x46e/frame 0x81e4f8a0 calltrap() at calltrap+0x8/frame 0x81e4f8a0 --- trap 0xc, rip = 0x80bb7284, rsp = 0x81e4f970, rbp = 0x81e4f970 --- bcopy() at bcopy+0x24/frame 0x81e4f970 vesa_configure() at vesa_configure+0x270/frame 0x81e4fb60 vga_init() at vga_init+0x65/frame 0x81e4fb80 isavga_attach() at isavga_attach+0x92/frame 0x81e4fbc0 device_attach() at device_attach+0x420/frame 0x81e4fc20 isa_probe_children() at isa_probe_children+0x211/frame 0x81e4fc90 mi_startup() at mi_startup+0x108/frame 0x81e4fcb0 btext() at btext+0x2c Uptime: 1s acpi0: reset failed - timeout Automatic reboot in 15 seconds - press a key on the console to abort It's getting late here. I'll try digging around tomorrow. -- Cheers, Cy Schubert <cy.schub...@komquats.com> or <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic from vesa_configure()
In message <56917d49.1000...@rice.edu>, Alan Cox writes:
> This is a multi-part message in MIME format.
> --080104010900060709060805
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 7bit
>
> On 01/09/2016 14:05, Alan Cox wrote:
> > On 01/09/2016 13:48, Adrian Chadd wrote:
> >> On 9 January 2016 at 11:30, John Baldwin <j...@freebsd.org> wrote:
> >>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
> >>>> In message <cagsa5y0qikv9sgjyj_mz3snjgnjiehsvyp8nljt9ewxo4ru...@mail.gma
> il.c
> >>>> om>
> >>>> , Jeremie Le Hen writes:
> >>>>> On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd <adrian.ch...@gmail.com>
> wrote
> >>>>> :
> >>>>>> can you copy/paste the file:line that each of those stackframes repres
> ents?
> >>>>>>
> >>>>>> I may have an idea or two..
> >>>>> Sure here we go:
> >>>>>
> >>>>> (kgdb) list *vesa_configure+0x270
> >>>>> 0x80b25cd0 is in vesa_configure (/usr/src-svn/sys/dev/fb/vesa.c
> :827).
> >>>>>
> >>>>> (kgdb) list *vga_init+0x65
> >>>>> 0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402).
> >>>>>
> >>>>> (kgdb) list *isavga_attach+0x92
> >>>>> 0x80b9afd2 is in isavga_attach (/usr/src-svn/sys/isa/vga_isa.c:
> 224).
> >>>> Here is what I see. Only happens on real hardware (not VirtualBox VMs).
> >>>>
> >>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> >>>> uart0: console (9600,n,8,1)
> >>>> acpi_alloc_wakeup_handler: can't alloc wake memory
> >>> This is probably related to the same cause. Both this and the x86 BIOS s
> tuff
> >>> need "low" memory (memory below 1MB).
> >>>
> >>> x86bios_alloc() uses contigmalloc() as does acpi_alloc_wakeup_handler().
> >>> Perhaps the recent changes to contigmalloc() affect this? In particular,
> >>> try reverting r292469 to see if that fixes the issue.
> >> Can't we just keep a pool of those pages around and not give them out
> >> unless someone specifically asks for low memory?
> > vm_phys.c already implements a "soft segregation" under which these
> > pages are only allocated as a last resort, unless
> > kmem_alloc_{attr,contig}() or contigmalloc() is called.
> >
> > What happened is that r292469 changed the order in which we pull from
> > the free lists for kmem_alloc_{attr,contig}() and contigmalloc() so that
> > a bunch of, for example, contigmalloc(low=0, high=4GB) calls, could
> > potentially exhaust physical memory in the range [0, 1MB). In other
> > words, we're no longer getting the soft segregation among contigmalloc()
> > calls.
> >
>
> This patch should suffice to restore the soft segregation among
> contigmalloc() calls.
This fixes it.
pcib2: at device 15.0 on pci0
pci2: on pcib2
vgapci0: mem 0xe800-0xefff,0xfddfe000-0xfdd
f irq 16 at device 0.0 on pci2
vgapci0: Boot video device
amdtemp0: on hostb3
acpi_tz0: on acpi0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (9600,n,8,1)
orm0: at iomem 0xc-0xcc7ff on isa0
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
powernow0: <PowerNow! K8> on cpu0
powernow1: <PowerNow! K8> on cpu1
--
Cheers,
Cy Schubert <cy.schub...@komquats.com> or <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic from vesa_configure()
In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert
writes:
> In message <CAJ-VmonGOs2f+rzciEcV=VuaNrZt0hqNePQx4LZDWu6BxuR9NQ@mail.gmail.c
> om>
> , Adrian Chadd writes:
> > Ok,
> >
> > So try adding this check:
> >
> > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> > if (vmbuf == NULL) {
> > printf("%s: x86bios_alloc failed!\n", __func__);
> > goto fail;
> > }
> >
> > ... that call shouldn't be failing, but if it's truely failing on the
> > bcopy(), the only reason is because vmbuf is NULL.
>
> Thanks. I'll try this.
>
> vesa.c hasn't changed for a while so I suspect the root cuase may be
> somewhere else (we're probably treating the symptom here). Nice thing about
> using the same mobo and cpu combination on all my machines (except
> laptops), failures are completely reproducible. Might be a good idea to put
> in a dtrace probe too.
Hi Adrian,
Your patch fixed the issue. I've included a dtrace probe. I suspect the
error may be BIOS specific and the dtrace probe should help in tracking it
down. Does this look good to commit?
--
Cheers,
Cy Schubert <cy.schub...@komquats.com> or <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic from vesa_configure()
Cy Schubert writes:
> In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert
> writes:
> > In message <CAJ-VmonGOs2f+rzciEcV=VuaNrZt0hqNePQx4LZDWu6BxuR9NQ@mail.gmail.
> c
> > om>
> > , Adrian Chadd writes:
> > > Ok,
> > >
> > > So try adding this check:
> > >
> > > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> > > if (vmbuf == NULL) {
> > > printf("%s: x86bios_alloc failed!\n", __func__);
> > > goto fail;
> > > }
> > >
> > > ... that call shouldn't be failing, but if it's truely failing on the
> > > bcopy(), the only reason is because vmbuf is NULL.
> >
> > Thanks. I'll try this.
> >
> > vesa.c hasn't changed for a while so I suspect the root cuase may be
> > somewhere else (we're probably treating the symptom here). Nice thing about
>
> > using the same mobo and cpu combination on all my machines (except
> > laptops), failures are completely reproducible. Might be a good idea to put
>
> > in a dtrace probe too.
>
> Hi Adrian,
>
> Your patch fixed the issue. I've included a dtrace probe. I suspect the
> error may be BIOS specific and the dtrace probe should help in tracking it
> down. Does this look good to commit?
A bit of multitasking going on here. I should have included the patch. :~
Index: vesa.c
===
--- vesa.c (revision 293386)
+++ vesa.c (working copy)
@@ -819,6 +819,11 @@
regs.R_AX = 0x4f00;
vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
+ if (vmbuf == NULL) {
+ printf("%s: x86bios_alloc failed!\n", __func__);
+ DTRACE_PROBE1(x86bios_alloc_failed, int, vmbuf);
+ goto fail;
+ }
regs.R_ES = X86BIOS_PHYSTOSEG(offs);
regs.R_DI = X86BIOS_PHYSTOOFF(offs);
Cheers,
Cy Schubert <cy.schub...@komquats.com> or <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Cross-build Brokenness
It appears that the i386 cross-build is broken as follows. Builds on native
amd64 are OK.
--- main.o ---
cc -target i386-unknown-freebsd11.0 --sysroot=/usr/obj/i386.i386/opt/src/svn
-current/tmp -B/usr/obj/i386.i386/opt/src/svn-current/tmp/usr/bin -O2 -pipe
-pipe -DRDUMP -g -MD -MF.depend.main.o -MTmain.o -std=gnu99
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
-Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter -Qunused-arguments -c
/opt/src/svn-current/sbin/dump/main.c -o main.o
--- all_subdir_lib ---
/usr/obj/i386.i386/opt/src/svn-current/tmp/usr/bin/ld:
/usr/bin/../lib/clang/3.8.0/lib/freebsd/libclang_rt.ubsan_standalone-i386.a:
No such file: No such file or directory
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [h_raw.full] Error code 1
make[7]: stopped in /opt/src/svn-current/lib/libc/tests/ssp
1 error
make[7]: stopped in /opt/src/svn-current/lib/libc/tests/ssp
*** [h_raw] Error code 2
make[6]: stopped in /opt/src/svn-current/lib/libc/tests/ssp
1 error
make[6]: stopped in /opt/src/svn-current/lib/libc/tests/ssp
--- all_subdir_kerberos5 ---
A failure has been detected in another branch of the parallel make
make[5]: stopped in /opt/src/svn-current/kerberos5/lib/libheimbase
--- all_subdir_lib ---
*** [all_subdir_lib/libc/tests/ssp] Error code 2
make[5]: stopped in /opt/src/svn-current/lib/libc/tests
1 error
make[5]: stopped in /opt/src/svn-current/lib/libc/tests
--- all_subdir_kerberos5 ---
*** [all] Error code 2
make[4]: stopped in /opt/src/svn-current/kerberos5/lib
1 error
make[4]: stopped in /opt/src/svn-current/kerberos5/lib
--- all_subdir_lib ---
*** [all] Error code 2
make[4]: stopped in /opt/src/svn-current/lib/libc
1 error
make[4]: stopped in /opt/src/svn-current/lib/libc
--- all_subdir_kerberos5 ---
*** [all_subdir_kerberos5/lib] Error code 2
make[3]: stopped in /opt/src/svn-current/kerberos5
1 error
make[3]: stopped in /opt/src/svn-current/kerberos5
*** [all_subdir_kerberos5] Error code 2
make[2]: stopped in /opt/src/svn-current
--- all_subdir_lib ---
*** [all_subdir_lib/libc] Error code 2
make[3]: stopped in /opt/src/svn-current/lib
1 error
make[3]: stopped in /opt/src/svn-current/lib
*** [all_subdir_lib] Error code 2
make[2]: stopped in /opt/src/svn-current
--- all_subdir_rescue ---
A failure has been detected in another branch of the parallel make
make[6]: stopped in /opt/src/svn-current/bin/csh
*** [csh_make] Error code 2
make[5]: stopped in /export/obj/i386.i386/opt/src/svn-current/rescue/rescue
1 error
make[5]: stopped in /export/obj/i386.i386/opt/src/svn-current/rescue/rescue
*** [objs] Error code 2
make[4]: stopped in /opt/src/svn-current/rescue/rescue
1 error
make[4]: stopped in /opt/src/svn-current/rescue/rescue
*** [all] Error code 2
make[3]: stopped in /opt/src/svn-current/rescue
1 error
make[3]: stopped in /opt/src/svn-current/rescue
*** [all_subdir_rescue] Error code 2
make[2]: stopped in /opt/src/svn-current
--- all_subdir_sbin ---
A failure has been detected in another branch of the parallel make
make[4]: stopped in /opt/src/svn-current/sbin/dump
*** [all_subdir_sbin/dump] Error code 2
make[3]: stopped in /opt/src/svn-current/sbin
1 error
make[3]: stopped in /opt/src/svn-current/sbin
*** [all_subdir_sbin] Error code 2
make[2]: stopped in /opt/src/svn-current
4 errors
make[2]: stopped in /opt/src/svn-current
*** [everything] Error code 2
make[1]: stopped in /opt/src/svn-current
1 error
make[1]: stopped in /opt/src/svn-current
*** [buildworld] Error code 2
make: stopped in /opt/src/svn-current
1 error
make: stopped in /opt/src/svn-current
slippy#
The following patch fixes my i386 cross-builds on amd64 native architecture.
Index: lib/libc/tests/ssp/Makefile
===
--- lib/libc/tests/ssp/Makefile (revision 302191)
+++ lib/libc/tests/ssp/Makefile (working copy)
@@ -1,5 +1,6 @@
# $FreeBSD$
+.include
.include
NO_WERROR=
@@ -34,10 +35,12 @@
.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
.if ${COMPILER_TYPE} == "clang" && ${MK_TOOLCHAIN} == "yes"
.if ${COMPILER_VERSION} < 30500 || 30700 <= ${COMPILER_VERSION}
+.if ${MACHINE_CPUARCH} == ${_HOST_ARCH}
PROGS+=h_raw
.endif
.endif
.endif
+.endif
PROGS+=h_read
PROGS+=h_readlink
PROGS+=h_snprintf
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org maili
Re: CURRENT slow and shaky network stability
In message <20160409105444.7020f2f1.ohart...@zedat.fu-berlin.de>, "O. Hartmann" writes: > --Sig_/SqWr.x1C_BgJVIYh7m_9T5y > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > Am Mon, 04 Apr 2016 23:46:08 -0700 > Cy Schubert <cy.schub...@komquats.com> schrieb: > > > In message <20160405082047.670d7...@freyja.zeit4.iv.bundesimmobilien.de>,= > =20 > > "O. H > > artmann" writes: > > > On Sat, 02 Apr 2016 16:14:57 -0700 > > > Cy Schubert <cy.schub...@komquats.com> wrote: > > > =20 > > > > In message <20160402231955.41b05526.ohart...@zedat.fu-berlin.de>, "O.= > =20 > > > > Hartmann" > > > > writes: =20 > > > > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > > > > Content-Type: text/plain; charset=3DUS-ASCII > > > > > Content-Transfer-Encoding: quoted-printable > > > > >=20 > > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > > > > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > > >=20 > > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > > > > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > > > >=3D20 =20 > > > > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > > > > Cy Schubert <cy.schub...@komquats.com> schrieb: > > > > > > > =3D20 =20 > > > > > > > > In message <56f6c6b0.6010...@protected-networks.net>, Michael= > Butle =20 > > > r =20 > > > > > > > > =3D =20 > > > > > writes: =3D20 =20 > > > > > > > > > -current is not great for interactive use at all. The strat= > egy of > > > > > > > > > pre-emptively dropping idle processes to swap is hurting ..= > big > > > > > > > > > tim=3D =20 > > > > > e. =3D20 =20 > > > > > > > >=3D20 > > > > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out = > to > > > > > > > > disk.=3D =20 > > > > > LRU=3D20 =20 > > > > > > > > doesn't do this. > > > > > > > >=3D20 =20 > > > > > > > > >=3D20 > > > > > > > > > Compare inactive memory to swap in this example .. > > > > > > > > >=3D20 > > > > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt,= > 94.5% > > > > > > > > > i=3D =20 > > > > > dle =20 > > > > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M F= > ree > > > > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =3D= > 20 =20 > > > > > > > >=3D20 > > > > > > > > To analyze this you need to capture vmstat output. You'll see= > the > > > > > > > > fre=3D =20 > > > > > e pool=3D20 =20 > > > > > > > > dip below a threshold and pages go out to disk in response. I= > f you > > > > > > > > ha=3D =20 > > > > > ve=3D20 =20 > > > > > > > > daemons with small working sets, pages that are not part of t= > he > > > > > > > > worki=3D =20 > > > > > ng=3D20 =20 > > > > > > > > sets for daemons or applications will eventually be paged out= > . This > > > > > > > > i=3D =20 > > > > > s not=3D20 =20 > > > > > > > > a bad thing. In your example above, the 281 MB of UFS buffers= > are > > > > > > > > mor=3D =20 > > > > > e=3D20 =20 > > > > > > > > active than the 917 MB paged out. If it's paged out and never= > used > > > > > > > > ag=3D =20 > > > > > ain,=3D20 =20 > > > > > > > > then it doesn't hurt. However the 281 MB of buffers saves you= > I/O. > > > > > > > > Th=3D =20 > > > > > e=3D20 =20 > > > > > > > > inactive pages are part of your free pool that were active at= > one > > > > > > > > tim=3D =20 > > > >
Re: CURRENT slow and shaky network stability
In message <20160402231955.41b05526.ohart...@zedat.fu-berlin.de>, "O. Hartmann" writes: > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > Am Sat, 2 Apr 2016 11:39:10 +0200 > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > >=20 > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > Cy Schubert <cy.schub...@komquats.com> schrieb: > > > =20 > > > > In message <56f6c6b0.6010...@protected-networks.net>, Michael Butler = > writes: =20 > > > > > -current is not great for interactive use at all. The strategy of > > > > > pre-emptively dropping idle processes to swap is hurting .. big tim= > e. =20 > > > >=20 > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to disk.= > LRU=20 > > > > doesn't do this. > > > >=20 > > > > >=20 > > > > > Compare inactive memory to swap in this example .. > > > > >=20 > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% i= > dle > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > > >=20 > > > > To analyze this you need to capture vmstat output. You'll see the fre= > e pool=20 > > > > dip below a threshold and pages go out to disk in response. If you ha= > ve=20 > > > > daemons with small working sets, pages that are not part of the worki= > ng=20 > > > > sets for daemons or applications will eventually be paged out. This i= > s not=20 > > > > a bad thing. In your example above, the 281 MB of UFS buffers are mor= > e=20 > > > > active than the 917 MB paged out. If it's paged out and never used ag= > ain,=20 > > > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. Th= > e=20 > > > > inactive pages are part of your free pool that were active at one tim= > e but=20 > > > > now are not. They may be reclaimed and if they are, you've just saved= > more=20 > > > > I/O. > > > >=20 > > > > Top is a poor tool to analyze memory use. Vmstat is the better tool t= > o help=20 > > > > understand memory use. Inactive memory isn't a bad thing per se. Moni= > tor=20 > > > > page outs, scan rate and page reclaims. > > > >=20 > > > >=20 > > >=20 > > > I give up! Tried to check via ssh/vmstat what is going on. Last lines b= > efore broken > > > pipe: > > >=20 > > > [...] > > > procs memory pagedisks faults cpu > > > r b w avm fre flt re pi pofr sr ad0 ad1 insycs = > us sy id > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 540= > 0 95 5 0 > > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40869 345= > 9 93 7 0 > > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52192 436= > 6 91 9 0 > > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86209 436= > 8 88 12 0 > > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 779569 704= > 359 87 13 0 > > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 507337 484= > 861 93 7 0 > > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68131 4440= > 7 95 5 0 > > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99366 3806= > 0 89 11 0 > > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 99371 49= > 99 85 15 0 > > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29142 443= > 1 95 5 0 > > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken pipe > > >=20 > > >=20 > > > This makes this crap system completely unusable. The server (FreeBSD 11= > .0-CURRENT #20 > > > r297503: Sat Apr 2 09:02:41 CEST 2016 amd64) in question did poudriere= > bulk job. I > > > can not even determine what terminal goes down first - another one, muc= > h more time > > > idle than the one shwoing the "vmstat 5" output, is still alive!=20 > > >=20 > > > i consider this a serious bug and it is no be
Re: CURRENT slow and shaky network stability
In message <CAN6yY1tioVfhnEu0eEyE4wROJ5bJ3an2rOYM95cj1d44CTiJew@mail.gmail.c om> , Kevin Oberman writes: > --089e01176a5d71db0d052f8803c7 > Content-Type: text/plain; charset=UTF-8 > > On Sat, Apr 2, 2016 at 2:19 PM, O. Hartmann <ohart...@zedat.fu-berlin.de> > wrote: > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > Cy Schubert <cy.schub...@komquats.com> schrieb: > > > > > > > > > In message <56f6c6b0.6010...@protected-networks.net>, Michael > > Butler writes: > > > > > > -current is not great for interactive use at all. The strategy of > > > > > > pre-emptively dropping idle processes to swap is hurting .. big > > time. > > > > > > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to > > disk. LRU > > > > > doesn't do this. > > > > > > > > > > > > > > > > > Compare inactive memory to swap in this example .. > > > > > > > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% > > idle > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse > > > > > > > > > > To analyze this you need to capture vmstat output. You'll see the > > free pool > > > > > dip below a threshold and pages go out to disk in response. If you > > have > > > > > daemons with small working sets, pages that are not part of the > > working > > > > > sets for daemons or applications will eventually be paged out. This > > is not > > > > > a bad thing. In your example above, the 281 MB of UFS buffers are > > more > > > > > active than the 917 MB paged out. If it's paged out and never used > > again, > > > > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. > > The > > > > > inactive pages are part of your free pool that were active at one > > time but > > > > > now are not. They may be reclaimed and if they are, you've just > > saved more > > > > > I/O. > > > > > > > > > > Top is a poor tool to analyze memory use. Vmstat is the better tool > > to help > > > > > understand memory use. Inactive memory isn't a bad thing per se. > > Monitor > > > > > page outs, scan rate and page reclaims. > > > > > > > > > > > > > > > > > > I give up! Tried to check via ssh/vmstat what is going on. Last lines > > before broken > > > > pipe: > > > > > > > > [...] > > > > procs memory pagedisks faults > > cpu > > > > r b w avm fre flt re pi pofr sr ad0 ad1 insycs > > us sy id > > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 > > 5400 95 5 0 > > > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40869 > > 3459 93 7 0 > > > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52192 > > 4366 91 9 0 > > > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86209 > > 4368 88 12 0 > > > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 779569 > > 704359 87 13 0 > > > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 507337 > > 484861 93 7 0 > > > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68131 > > 44407 95 5 0 > > > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99366 > > 38060 89 11 0 > > > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 99371 > > 4999 85 15 0 > > > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29142 > > 4431 95 5 0 > > > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken pipe > > > > > > > > > > > > This makes this crap system completely unusable. The server (FreeBSD > > 11.0-CURRENT #20 > > > > r297503: Sat Apr 2 09:02:41 C
Re: CURRENT slow and shaky network stability
In message <20160402105503.7ede5be1.ohart...@zedat.fu-berlin.de>, "O. Hartmann" writes: > --Sig_/VIBPN0rbNwuyJuk=dxEGA+U > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > Am Sat, 02 Apr 2016 01:07:55 -0700 > Cy Schubert <cy.schub...@komquats.com> schrieb: > > > In message <56f6c6b0.6010...@protected-networks.net>, Michael Butler writ= > es: > > > -current is not great for interactive use at all. The strategy of > > > pre-emptively dropping idle processes to swap is hurting .. big time. = > =20 > >=20 > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to disk. LRU= > =20 > > doesn't do this. > >=20 > > >=20 > > > Compare inactive memory to swap in this example .. > > >=20 > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% idle > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > >=20 > > To analyze this you need to capture vmstat output. You'll see the free po= > ol=20 > > dip below a threshold and pages go out to disk in response. If you have=20 > > daemons with small working sets, pages that are not part of the working=20 > > sets for daemons or applications will eventually be paged out. This is no= > t=20 > > a bad thing. In your example above, the 281 MB of UFS buffers are more=20 > > active than the 917 MB paged out. If it's paged out and never used again,= > =20 > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. The=20 > > inactive pages are part of your free pool that were active at one time bu= > t=20 > > now are not. They may be reclaimed and if they are, you've just saved mor= > e=20 > > I/O. > >=20 > > Top is a poor tool to analyze memory use. Vmstat is the better tool to he= > lp=20 > > understand memory use. Inactive memory isn't a bad thing per se. Monitor= > =20 > > page outs, scan rate and page reclaims. > >=20 > >=20 > > I give up! Tried to check via ssh/vmstat what is going on. Last lines befor= > e broken pipe: > > [...] > procs memory pagedisks faults cpu > r b w avm fre flt re pi pofr sr ad0 ad1 insycs us s= > y id > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 5400 95= > 5 0 > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40869 3459 93= > 7 0 > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52192 4366 91= > 9 0 > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86209 4368 88= > 12 0 > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 779569 704359 = > 87 13 0 > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 507337 484861 = > 93 7 0 > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68131 44407 95= > 5 0 > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99366 38060 89= > 11 0 > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 99371 4999 8= > 5 15 0 > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29142 4431 95= > 5 0 > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken pipe How many CPUs does FreeBSD see? (CPUs being the number of cores and threads, i.e. my dual core intel has two threads so FreeBSD sees four CPUs.) The load on the box shouldn't exceed more than two processes per CPU or you will notice performance issues. Ideally we look at load average first. If it's high then we check CPU%. If that looks good we look at memory and I/O. With the scant information at hand right now I see a possible CPU issue. Scan rate looks high but there's no paging so I'd consider it borderline. -- Cheers, Cy Schubert <cy.schub...@komquats.com> or <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT slow and shaky network stability
In message <20160402113910.14de7eaf.ohart...@zedat.fu-berlin.de>, "O. Hartmann" writes: > --Sig_/cnPyYwlIcD24/.m6dd2EX7j > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > Am Sat, 2 Apr 2016 10:55:03 +0200 > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > Cy Schubert <cy.schub...@komquats.com> schrieb: > >=20 > > > In message <56f6c6b0.6010...@protected-networks.net>, Michael Butler wr= > ites: =20 > > > > -current is not great for interactive use at all. The strategy of > > > > pre-emptively dropping idle processes to swap is hurting .. big time.= >=20 > > >=20 > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to disk. L= > RU=20 > > > doesn't do this. > > > =20 > > > >=20 > > > > Compare inactive memory to swap in this example .. > > > >=20 > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% idle > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > >=20 > > > To analyze this you need to capture vmstat output. You'll see the free = > pool=20 > > > dip below a threshold and pages go out to disk in response. If you have= > =20 > > > daemons with small working sets, pages that are not part of the working= > =20 > > > sets for daemons or applications will eventually be paged out. This is = > not=20 > > > a bad thing. In your example above, the 281 MB of UFS buffers are more= > =20 > > > active than the 917 MB paged out. If it's paged out and never used agai= > n,=20 > > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. The= > =20 > > > inactive pages are part of your free pool that were active at one time = > but=20 > > > now are not. They may be reclaimed and if they are, you've just saved m= > ore=20 > > > I/O. > > >=20 > > > Top is a poor tool to analyze memory use. Vmstat is the better tool to = > help=20 > > > understand memory use. Inactive memory isn't a bad thing per se. Monito= > r=20 > > > page outs, scan rate and page reclaims. > > >=20 > > > =20 > >=20 > > I give up! Tried to check via ssh/vmstat what is going on. Last lines bef= > ore broken > > pipe: > >=20 > > [...] > > procs memory pagedisks faults cpu > > r b w avm fre flt re pi pofr sr ad0 ad1 insycs us= > sy id > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 5400 = > 95 5 0 > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40869 3459 = > 93 7 0 > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52192 4366 = > 91 9 0 > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86209 4368 = > 88 12 0 > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 779569 70435= > 9 87 13 0 > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 507337 48486= > 1 93 7 0 > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68131 44407 = > 95 5 0 > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99366 38060 = > 89 11 0 > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 99371 4999= > 85 15 0 > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29142 4431 = > 95 5 0 > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken pipe > >=20 > >=20 > > This makes this crap system completely unusable. The server (FreeBSD 11.0= > -CURRENT #20 > > r297503: Sat Apr 2 09:02:41 CEST 2016 amd64) in question did poudriere b= > ulk job. I can > > not even determine what terminal goes down first - another one, much more= > time idle than > > the one shwoing the "vmstat 5" output, is still alive!=20 > >=20 > > i consider this a serious bug and it is no benefit what happened since th= > is "fancy" > > update. :-( > > By the way - it might be of interest and some hint. > > One of my boxes is acting as server and gateway. It utilises NAT, IPFW, whe= > n it is under > high load, as it was today, sometimes passing the network flow from ISP int= > o the network > for clients is extremely slow. I do not consider this the reason for collap= > sing ssh > sessions,
Re: CURRENT slow and shaky network stability
In message <20160405092712.131ee...@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > On Mon, 04 Apr 2016 23:46:08 -0700 > Cy Schubert <cy.schub...@komquats.com> wrote: > > > In message <20160405082047.670d7...@freyja.zeit4.iv.bundesimmobilien.de>, > > "O. H > > artmann" writes: > > > On Sat, 02 Apr 2016 16:14:57 -0700 > > > Cy Schubert <cy.schub...@komquats.com> wrote: > > > > > > > In message <20160402231955.41b05526.ohart...@zedat.fu-berlin.de>, "O. > > > > Hartmann" > > > > writes: > > > > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > > > > Content-Type: text/plain; charset=US-ASCII > > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > > > > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > > > > > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > > > > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > > > >=20 > > > > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > > > > Cy Schubert <cy.schub...@komquats.com> schrieb: > > > > > > > =20 > > > > > > > > In message <56f6c6b0.6010...@protected-networks.net>, Michael > > > > > > > > Butle > > > r > > > > > > > > = > > > > > writes: =20 > > > > > > > > > -current is not great for interactive use at all. The strateg > y > > > > > > > > > of pre-emptively dropping idle processes to swap is hurting . > . > > > > > > > > > big tim= > > > > > e. =20 > > > > > > > >=20 > > > > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to > > > > > > > > disk.= > > > > > LRU=20 > > > > > > > > doesn't do this. > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Compare inactive memory to swap in this example .. > > > > > > > > >=20 > > > > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, > > > > > > > > > 94.5% i= > > > > > dle > > > > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Fre > e > > > > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > > > > > > > >=20 > > > > > > > > To analyze this you need to capture vmstat output. You'll see t > he > > > > > > > > fre= > > > > > e pool=20 > > > > > > > > dip below a threshold and pages go out to disk in response. If > you > > > > > > > > ha= > > > > > ve=20 > > > > > > > > daemons with small working sets, pages that are not part of the > > > > > > > > worki= > > > > > ng=20 > > > > > > > > sets for daemons or applications will eventually be paged out. > > > > > > > > This i= > > > > > s not=20 > > > > > > > > a bad thing. In your example above, the 281 MB of UFS buffers a > re > > > > > > > > mor= > > > > > e=20 > > > > > > > > active than the 917 MB paged out. If it's paged out and never u > sed > > > > > > > > ag= > > > > > ain,=20 > > > > > > > > then it doesn't hurt. However the 281 MB of buffers saves you I > /O. > > > > > > > > Th= > > > > > e=20 > > > > > > > > inactive pages are part of your free pool that were active at o > ne > > > > > > > > tim= > > > > > e but=20 > > > > > > > > now are not. They may be reclaimed and if they are, you've just > > > > > > > > saved= > > > > > more=20 > > > > > > > > I/O. > > &
Re: CURRENT slow and shaky network stability
In message <20160405082047.670d7...@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > On Sat, 02 Apr 2016 16:14:57 -0700 > Cy Schubert <cy.schub...@komquats.com> wrote: > > > In message <20160402231955.41b05526.ohart...@zedat.fu-berlin.de>, "O. > > Hartmann" > > writes: > > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > > Content-Type: text/plain; charset=US-ASCII > > > Content-Transfer-Encoding: quoted-printable > > > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > > "O. Hartmann" <ohart...@zedat.fu-berlin.de> schrieb: > > > >=20 > > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > > Cy Schubert <cy.schub...@komquats.com> schrieb: > > > > > =20 > > > > > > In message <56f6c6b0.6010...@protected-networks.net>, Michael Butle > r > > > > > > = > > > writes: =20 > > > > > > > -current is not great for interactive use at all. The strategy of > > > > > > > pre-emptively dropping idle processes to swap is hurting .. big > > > > > > > tim= > > > e. =20 > > > > > >=20 > > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to > > > > > > disk.= > > > LRU=20 > > > > > > doesn't do this. > > > > > >=20 > > > > > > >=20 > > > > > > > Compare inactive memory to swap in this example .. > > > > > > >=20 > > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% > > > > > > > i= > > > dle > > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > > > > >=20 > > > > > > To analyze this you need to capture vmstat output. You'll see the > > > > > > fre= > > > e pool=20 > > > > > > dip below a threshold and pages go out to disk in response. If you > > > > > > ha= > > > ve=20 > > > > > > daemons with small working sets, pages that are not part of the > > > > > > worki= > > > ng=20 > > > > > > sets for daemons or applications will eventually be paged out. This > > > > > > i= > > > s not=20 > > > > > > a bad thing. In your example above, the 281 MB of UFS buffers are > > > > > > mor= > > > e=20 > > > > > > active than the 917 MB paged out. If it's paged out and never used > > > > > > ag= > > > ain,=20 > > > > > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. > > > > > > Th= > > > e=20 > > > > > > inactive pages are part of your free pool that were active at one > > > > > > tim= > > > e but=20 > > > > > > now are not. They may be reclaimed and if they are, you've just > > > > > > saved= > > > more=20 > > > > > > I/O. > > > > > >=20 > > > > > > Top is a poor tool to analyze memory use. Vmstat is the better tool > > > > > > t= > > > o help=20 > > > > > > understand memory use. Inactive memory isn't a bad thing per se. > > > > > > Moni= > > > tor=20 > > > > > > page outs, scan rate and page reclaims. > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > > I give up! Tried to check via ssh/vmstat what is going on. Last lines > > > > > b= > > > efore broken > > > > > pipe: > > > > >=20 > > > > > [...] > > > > > procs memory pagedisks faults > cpu > > > > > r b w avm fre flt re pi pofr sr ad0 ad1 insyc > s > > > > > = > > > us sy id > > > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 > > > > > 540=
Re: CURRENT slow and shaky network stability
In message <56f6c6b0.6010...@protected-networks.net>, Michael Butler writes: > -current is not great for interactive use at all. The strategy of > pre-emptively dropping idle processes to swap is hurting .. big time. FreeBSD doesn't "preemptively" or arbitrarily push pages out to disk. LRU doesn't do this. > > Compare inactive memory to swap in this example .. > > 110 processes: 1 running, 108 sleeping, 1 zombie > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% idle > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse To analyze this you need to capture vmstat output. You'll see the free pool dip below a threshold and pages go out to disk in response. If you have daemons with small working sets, pages that are not part of the working sets for daemons or applications will eventually be paged out. This is not a bad thing. In your example above, the 281 MB of UFS buffers are more active than the 917 MB paged out. If it's paged out and never used again, then it doesn't hurt. However the 281 MB of buffers saves you I/O. The inactive pages are part of your free pool that were active at one time but now are not. They may be reclaimed and if they are, you've just saved more I/O. Top is a poor tool to analyze memory use. Vmstat is the better tool to help understand memory use. Inactive memory isn't a bad thing per se. Monitor page outs, scan rate and page reclaims. -- Cheers, Cy Schubert <cy.schub...@komquats.com> or <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT slow and shaky network stability
In message <201603300728.u2u7sdwc092...@gw.catspoiler.org>, Don Lewis writes: > On 29 Mar, To: ohart...@zedat.fu-berlin.de wrote: > > On 28 Mar, Don Lewis wrote: > >> On 28 Mar, O. Hartmann wrote: > > > >> If I get a chance, I try booting my FreeBSD 11 machine with less RAM to > >> see if that is a trigger. > > > > I just tried cranking hw.physmen down to 8 GB on 11.0-CURRENT r297204, > > GENERIC kernel. /boot/loader.conf contains: > > geom_mirror_load="YES" > > kern.geom.label.disk_ident.enable="0" > > kern.geom.label.gptid.enable="0" > > zfs_load="YES" > > vboxdrv_load="YES" > > hw.physmem="8G" > > > > /etc/sysctl.conf contains: > > kern.ipc.shm_allow_removed=1 > > > > No /etc/src.conf and nothing of that should matter in /etc/make.conf. > > > > > > This is what I see after running > > poudriere ports -p whatever -u > > > > last pid: 2102; load averages: 0.24, 0.52, 0.36up 0+00:06:54 14:1 > 3:51 > > 52 processes: 1 running, 51 sleeping > > CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > > Mem: 95M Active, 20M Inact, 1145M Wired, 39K Buf, 5580M Free > > ARC: 595M Total, 256M MFU, 248M MRU, 16K Anon, 14M Header, 78M Other > > Swap: 40G Total, 40G Free > > > > No swap used, inactive memory low, no interactivity problems. Next I'll > > try r297267, which is what I believe you are running. I scanned the > > commit logs between r297204 and r297267 and didn't see anything terribly > > suspicious looking. > > No problems here with r297267 either. I did a bunch of small poudriere > runs since the system was first booted. Usable RAM is still dialed back > to 8 GB. A bit of swap is in use, mostly because nginx, which has been > unused since the system was booted, got swapped out. Inactive memory is > low now that poudriere is done. > > last pid: 75471; load averages: 0.21, 0.15, 0.19up 0+07:36:07 00:24: > 00 > 50 processes: 1 running, 49 sleeping > CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > Mem: 5988K Active, 14M Inact, 2641M Wired, 41K Buf, 4179M Free > ARC: 790M Total, 575M MFU, 169M MRU, 16K Anon, 9618K Header, 36M Other > Swap: 40G Total, 50M Used, 40G Free > > Do you use tmpfs? Anything stored in there will get stashed in inactive > memory and/or swap. Tmpfs objects are treated as any other in memory. If the pages are recent enough they will be active. -- Cheers, Cy Schubert <cy.schub...@komquats.com> or <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT slow and shaky network stability
In message <56f6c6b0.6010...@protected-networks.net>, Michael Butler writes: > -current is not great for interactive use at all. The strategy of > pre-emptively dropping idle processes to swap is hurting .. big time. > > Compare inactive memory to swap in this example .. > > 110 processes: 1 running, 108 sleeping, 1 zombie > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% idle > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse > > PID USERNAME THR PRI NICE SIZERES STATE C TIMEWCPU > COMMAND > 1819 imb 1 280 213M 11284K select 1 147:44 5.97% > gkrellm > 59238 imb 43 200 980M 424M select 0 10:07 1.92% > firefox > > .. it shouldn't start randomly swapping out processes because they're > used infrequently when there's more than enough RAM to spare .. Inactive memory will after time be used to "top up" the free memory pool. > > It also shows up when trying to reboot .. on all of my gear, 90 seconds > of "fail-safe" time-out is no longer enough when a good proportion of > daemons have been dropped onto swap and must be brought back in to flush > their data segments :-( What does vmstat 5 display? A high scan rate is indicative of memory in short supply. My laptop has 6 GB RAM of which I've allocated 2.5 GB for ARC. Top shows that 3.6 GB are wired (not pagable) leaving 2.4 GB available for apps. The laptop is in the middle of a four thread buildworld. It's using 1.8 MB swap so far. ARC is 2560 MB. UFS cache is only 49 MB at the moment but will balloon to 603 MB during installworld. When it does my swap grows to 100-150 MB. (The reason is the large 2.5 GB ARC *and* a large 603 MB UFS cache.) Notice vmstat output below. On line 8 of my vmstat output you scan rate jump to 10K. Two pages per second are paged out. This is due to the free memory pool (in line 7) dropping to 49 MB, so it freed up a few pages by paging out. Notice that page reclaims (re) is high at times. These pages were scheduled to be paged out but were used before they were. This indicates that my laptop is is running pretty close to the line between paging a lot and not paging at all. slippy$ vmstat 5 procs memory pagedisks faults cpu r b w avmfre flt re pi pofr sr ad0 da0 in sy cs us sy id 4 0 0 3413M 208M 12039 11 9 0 12804 170 0 0 533 7865 2722 59 3 38 4 0 0 3260M 376M 18550 0 0 0 27436 386 9 8 576 23029 30705 94 6 0 4 1 0 3432M 171M 25345 0 6 0 15340 360 10 12 530 2524 1362 97 3 0 4 0 0 3395M 208M 20904 0 0 0 22995 395 12 11 517 5427 1142 97 3 0 4 0 0 3695M53M 20102 0 0 0 12482 473 17 10 517 1383 1244 98 2 0 4 0 0 3404M 371M 22996 14 10 0 39691 4557 14 8 503 8540 1813 96 3 1 4 1 0 3673M49M 22398 441 22 0 6778 429 10 13 543 3034 1609 97 3 0 4 0 0 3396M 439M 19522 26 3 2 33901 10137 11 15 545 5617 1686 97 3 0 4 0 0 3489M 412M 26636 0 0 0 25710 393 10 12 531 5287 1450 95 3 2 4 0 0 3558M 337M 23364 329 13 0 20051 410 11 15 561 6052 1702 96 3 0 4 0 0 3492M 335M 18244 0 3 0 18550 444 14 7 512 5140 2087 98 2 0 4 0 0 3412M 404M 21765 0 0 0 25611 388 7 12 533 7873 1394 97 3 0 5 0 0 3604M 189M 19044 0 0 0 8404 505 7 10 644 63940 90591 93 6 1 4 0 0 3533M 363M 13079 423 17 0 22327 464 11 8 501 7960 4194 94 3 3 4 0 0 3222M 616M 20822 218 17 0 34180 294 11 13 550 5602 1850 95 4 1 4 0 0 3307M 542M 19639 32 3 0 15940 345 13 10 516 2589 1505 96 3 1 4 0 0 3320M 527M 19656 0 1 0 19191 397 14 8 514 1886 1257 97 3 0 4 0 0 3295M 605M 21676 910 35 0 25978 356 14 12 533 3039 1490 95 4 0 Page outs is the first place to look. If no page outs, page reclaims will tell you your system may be borderline. A high scan rate says that your working set size is large enough to put some pressure on VM. Ideally in this case I should add memory but since I'm running this close to the line (I chose my ARC maximum well) I'll just save my money instead. Also, FreeBSD is doing exactly what it should in this scenario. Top is a good tool but it doesn't tell the whole picture. Run vmstat to get a better picture of your memory use. Following this thread throughout the day (on my cellphone), I'm not convinced this is a FreeBSD O/S problem. Check your apps. What are their working set sizes. Do your apps have a small or large locality of reference? Remember, O/S tuning is a matter of robbing Peter to pay Paul. Reducing the resources used by applications will pay back bigger dividends. Hope this helps. -- Cheers, Cy Schubert <cy
Re: crossbuild buildworld on amd64 for arm fails to find KERNCONF GENERIC after r302865
In message <CAC67Hz-ZqcYR3p4fR+cBiBcju3JrOxtU+wTr6hwMn_eoo=Wedw@mail.gmail.c om> , Guy Yur writes: > Hi, > > I am trying to crossbuild arm on an amd64 machine and buildworld > is checking for KERNCONF and fails to find GENERIC kernel. > I only set KERNCONF when I am doing buildkernel/installkernel > so KERNCONF is the default set in Makefile.inc1. > > # make buildworld TARGET=arm TARGET_ARCH=armv6 > make[1]: "/usr/src/Makefile.inc1" line 122: SYSTEM_COMPILER: > Determined that CC=cc matches the source tree. Not bootstrapping a > cross-compiler. > make[1]: "/usr/src/Makefile.inc1" line 1144: Missing KERNCONF > /usr/src/sys/arm/conf/GENERIC > *** Error code 1 > > Stop. > make: stopped in /usr/src > > > # uname -a > FreeBSD vm4.localdomain 12.0-CURRENT FreeBSD 12.0-CURRENT #13 > r302895M: Fri Jul 15 16:06:24 IDT 2016 > root@vm4.localdomain:/usr/obj/usr/src/sys/VIRTUALBOX amd64 Thanks for the report. I've reverted it now until I get the time to look at it more closely. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: crossbuild buildworld on amd64 for arm fails to find KERNCONF GENERIC after r302865
In message <CAC67Hz_UAWvATr1x4QPX2OrA8_JC+9A_eoG8RMffXG5aZuWV7A@mail.gmail.c
om>
, Guy Yur writes:
> On Fri, Jul 15, 2016 at 6:11 PM, Cy Schubert <cy.schub...@komquats.com> wrote
> :
> > In message <CAC67Hz-ZqcYR3p4fR+cBiBcju3JrOxtU+wTr6hwMn_eoo=Wedw@mail.gmail.
> c
> > om>
> > , Guy Yur writes:
> >> Hi,
> >>
> >> I am trying to crossbuild arm on an amd64 machine and buildworld
> >> is checking for KERNCONF and fails to find GENERIC kernel.
> >> I only set KERNCONF when I am doing buildkernel/installkernel
> >> so KERNCONF is the default set in Makefile.inc1.
> >>
> >> # make buildworld TARGET=arm TARGET_ARCH=armv6
> >> make[1]: "/usr/src/Makefile.inc1" line 122: SYSTEM_COMPILER:
> >> Determined that CC=cc matches the source tree. Not bootstrapping a
> >> cross-compiler.
> >> make[1]: "/usr/src/Makefile.inc1" line 1144: Missing KERNCONF
> >> /usr/src/sys/arm/conf/GENERIC
> >> *** Error code 1
> >>
> >> Stop.
> >> make: stopped in /usr/src
> >>
> >>
> >> # uname -a
> >> FreeBSD vm4.localdomain 12.0-CURRENT FreeBSD 12.0-CURRENT #13
> >> r302895M: Fri Jul 15 16:06:24 IDT 2016
> >> root@vm4.localdomain:/usr/obj/usr/src/sys/VIRTUALBOX amd64
> >
> > Thanks for the report. I've reverted it now until I get the time to look at
> > it more closely.
> >
> >
> > --
> > Cheers,
> > Cy Schubert <cy.schub...@cschubert.com>
> > FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
> >
> > The need of the many outweighs the greed of the few.
> >
>
> Doing the missing check only for the kernel targets works for me.
>
> .if make(buildkernel) || \
> make(installkernel) || make(installkernel.debug) || \
> make(reinstallkernel) || make(reinstallkernel.debug) || \
> make(distributekernel) || make(distributekernel.debug) || \
> make(packagekernel) || make(create-kernel-packages)
> .error Missing KERNCONF ${KERNCONFDIR}/${_kernel}
> .endif
Yes, this is one solution. The plan is to use this:
.if make(*kernel) || make(*kernel.debug) || make(*kernel-packages)
>
>
> It might be possible cover more of the section with the .if make.
> I think these are all the targets that use BUILDKERNELS, INSTALLKERNEL.
>
> .if make(buildkernel) || \
> make(installkernel) || make(installkernel.debug) || \
> make(reinstallkernel) || make(reinstallkernel.debug) || \
> make(distributekernel) || make(distributekernel.debug) || \
> make(packagekernel) || make(create-kernel-packages)
> BUILDKERNELS=
> ...
> .error Missing KERNCONF ${KERNCONFDIR}/${_kernel}
> .endif
> .endfor
> .endif
That causes other breakage.
I believe I have a solution. I just need to make sure to thoroughly test it
first.
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange issue after early AP startup
In message <1922021.4hjeqfj...@ralph.baldwin.cx>, John Baldwin writes: > On Tuesday, January 17, 2017 05:08:58 PM Cy Schubert wrote: > > In message <1492450.xzfnz8z...@ralph.baldwin.cx>, John Baldwin writes: > > > On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote: > > > > In message <b9c53237-4b1a-a140-f692-bf5837060...@selasky.org>, Hans Pet > ter > > > > Sela > > > > sky writes: > > > > > Hi, > > > > > > > > > > When booting I observe an additional 30-second delay after this print > : > > > > > > > > > > > Timecounters tick every 1.000 msec > > > > > > > > > > ~30 second delay and boot continues like normal. > > > > > > > > > > Checking "vmstat -i" reveals that some timers have been running loose > . > > > > > > > > > > > cpu0:timer 44300442 > > > > > > cpu1:timer 40561404 > > > > > > cpu3:timer 48462822 483058 > > > > > > cpu2:timer 48477898 483209 > > > > > > > > > > Trying to add delays and/or prints around the Timecounters printout > > > > > makes the issue go away. Any ideas for debugging? > > > > > > > > > > Looks like a startup race to me. > > > > > > > > just picking a random email to reply to, I'm seeing a different issue w > ith > > > > early AP startup. It affects one of my four machines, my laptop. My thr > ee > > > > server systems downstairs have no problem however my laptop will reboot > > > > > repeatedly at: > > > > > > > > Jan 17 11:55:16 slippy kernel: cd0: Attempt to query device size failed > : > > > > NOT READY, Medium not present - tray closed > > > > > > So it panics and reboots after this? > > > > Yes, it goes into a panic/reboot loop for a few iterations until it > > successfully boots. Disabling early AP startup allows it to boot up without > > > the assumed race. > > Can you add DDB to the kernel config (and remove DDB_UNATTENDED) to get it > to break into DDB when it panics to get the panic message (and a stack trace > as well)? I found and fixed the problem. It was in some code I had added a long time ago but not committed yet to the bge driver to implement WOL. It was a lock assertion. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange issue after early AP startup
In message <b9c53237-4b1a-a140-f692-bf5837060...@selasky.org>, Hans Petter Sela sky writes: > Hi, > > When booting I observe an additional 30-second delay after this print: > > > Timecounters tick every 1.000 msec > > ~30 second delay and boot continues like normal. > > Checking "vmstat -i" reveals that some timers have been running loose. > > > cpu0:timer 44300442 > > cpu1:timer 40561404 > > cpu3:timer 48462822 483058 > > cpu2:timer 48477898 483209 > > Trying to add delays and/or prints around the Timecounters printout > makes the issue go away. Any ideas for debugging? > > Looks like a startup race to me. just picking a random email to reply to, I'm seeing a different issue with early AP startup. It affects one of my four machines, my laptop. My three server systems downstairs have no problem however my laptop will reboot repeatedly at: Jan 17 11:55:16 slippy kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Then finally boot after a number of reboots (0-N), it finally boots. Disabling early AP start allows it to boot past that point first time. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange issue after early AP startup
In message <1492450.xzfnz8z...@ralph.baldwin.cx>, John Baldwin writes: > On Tuesday, January 17, 2017 12:53:19 PM Cy Schubert wrote: > > In message <b9c53237-4b1a-a140-f692-bf5837060...@selasky.org>, Hans Petter > > Sela > > sky writes: > > > Hi, > > > > > > When booting I observe an additional 30-second delay after this print: > > > > > > > Timecounters tick every 1.000 msec > > > > > > ~30 second delay and boot continues like normal. > > > > > > Checking "vmstat -i" reveals that some timers have been running loose. > > > > > > > cpu0:timer 44300442 > > > > cpu1:timer 40561404 > > > > cpu3:timer 48462822 483058 > > > > cpu2:timer 48477898 483209 > > > > > > Trying to add delays and/or prints around the Timecounters printout > > > makes the issue go away. Any ideas for debugging? > > > > > > Looks like a startup race to me. > > > > just picking a random email to reply to, I'm seeing a different issue with > > early AP startup. It affects one of my four machines, my laptop. My three > > server systems downstairs have no problem however my laptop will reboot > > repeatedly at: > > > > Jan 17 11:55:16 slippy kernel: cd0: Attempt to query device size failed: > > NOT READY, Medium not present - tray closed > > So it panics and reboots after this? Yes, it goes into a panic/reboot loop for a few iterations until it successfully boots. Disabling early AP startup allows it to boot up without the assumed race. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d/ntpdate broken since r311103 - /head/etc/ntp.conf - Update ntp.conf to use the ntpd pool feature
In message <1484093380.96230.94.ca...@freebsd.org>, Ian Lepore writes:
> On Wed, 2017-01-11 at 00:48 +0100, Ronald Klop wrote:
> > Hello,
> >
> > Since the commit in the subject /etc/rc.d/ntpdate does not work
> > anymore.
> > # /etc/rc.d/ntpdate restart
> > Setting date via ntp.
> > 11 Jan 00:35:46 ntpdate[56020]: no servers can be used, exiting
> >
> > This diff fixes it for me:
> > # diff -u /tmp/ntpdate /etc/rc.d/ntpdate
> > --- /tmp/ntpdate2017-01-11 00:41:58.736138000 +0100
> > +++ /etc/rc.d/ntpdate 2017-01-11 00:42:15.522986000 +0100
> > @@ -20,7 +20,7 @@
> > Â Â if [ -z "$ntpdate_hosts" -a -f "$ntpdate_config" ]; then
> > Â Â ntpdate_hosts=`awk '
> > Â Â /^server[ \t]*127.127/Â Â Â Â Â Â {next}
> > - /^(server|peer)/Â Â Â Â Â Â Â Â Â Â Â Â {
> > + /^(server|peer|pool)/Â Â Â Â Â Â Â Â Â Â Â Â {
> > Â Â Â Â Â Â if ($2 ~/^-/)Â Â Â Â Â Â Â Â Â Â Â
> > {print $3}
> >       else                 Â
> > Â Â {print $2}}
> > Â Â ' < "$ntpdate_config"`
> >
> >
> > Regards,
> >
> > Ronald.
>
> Ooops, my bad, I'll get it fixed asap.
Not all your bad. Those of us reviewing the change should picked up on that
too.
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd dies nightly on a server with jails
In message <1489782793.40576.185.ca...@freebsd.org>, Ian Lepore writes: > On Fri, 2017-03-17 at 13:26 -0700, Don Lewis wrote: > > On 17 Mar, O. Hartmann wrote: > > > > > > > > Just some strange news: > > > > > > I left the server the whole day with ntpd disabled and I didn't > > > watch > > > a gain of the RTC by one second, even stressing the machine. > > > > > > But soon after restarting ntpd, I realised immediately a 30 minutes > > > off! This morning, the discrapancy was almost 5 hours - it looked > > > more > > > like a weird ajustment to another time base than UTC. > > > > > > Over the weekend I'll leave the server with ntpd disabled and only > > > RTC > > > running. I've the strange feeling that something is intentionally > > > readjusting the ntpd time due to a misconfiguration or a rogue ntp > > > server in the X.CC.pool.ntp.org > > A ntp should recognize a single bad server and ignore it in favor of > > the other servers that are sane. > > > > It sounds like something is going off the rails once ntpd starts > > calling > > adjtime().  What is the output of: > > sysctl kern.clockrate > > > > I'd suggest starting ntpd and running "ntpq -c pe" a few times a > > minute > > and capturing its output to monitor the status of ntpd as it starts > > up > > and try to capture things going wrong.   You should probably disable > > iburst in ntp.conf to give more visibility in the early startup. > > > > For the first few minutes ntpd should just be getting reliable > > timestamp > > info and won't start trying to adjust the clock until it has captured > > endough samples and figured out which servers are best.  Then the > > behaviour of the offset is the thing to watch.  If the iniital offset > > is > > large enough, ntpd will step the clock once to get it close to zero, > > otherwise it will just use adjtime to slowy push the offset towards > > zero.  I think though that you will see the offset start gyrating > > madly. > > > > You might want to set /var/db/ntpd.drift to zero beforehand if there > > is > > an insane value in there.  If the initial drift value is bogus, will > > try > > to use it which will push the time offset away from zero so fast that > > it > > will decide to keep stepping the clock back to zero before it can > > capture enough samples from the external servers to determine the > > true > > local clock drift rate. > > Do not set ntpd.drift contents to zero.  Delete the file.  There's a > huge difference between a file that says the clock is perfect and a > missing file which triggers ntpd to do a 15-minute frequency > measurement to come up with the initial drift correction. Yes. And, without debugging output and/or a dump, I don't think we'll be any closer to the truth. Until then the best we can do is make educated guesses. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd dies nightly on a server with jails
Hi O.Hartmann, I'll try to answer as much as I can in the noon hour I have left. In message <20170315071724.78bb0...@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > Running a host with several jails on recent CURRENT (12.0-CURRENT #8 r315187: > Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily basis. > > The box is an older two-socket Fujitsu server equipted with two four-core > Intel(R) Xeon(R) CPU L5420 @ 2.50GHz. > > The box has several jails, each jail does NOT run service ntpd. Each jail has > its dedicated loopback, lo1 throughout lo5 (for the moment) with dedicated IP > : > 127.0.1.1 - 127.0.5.1 (if this matter, I believe not). > > The host itself has two main NICs, broadcom based. bcm0 is dedicated to the > host, bcm1 is shared amongst the jails: each jail has an IP bound to bcm1 via > whihc the jails communicate with the network. > > I try to capture log informations via syslog, but FreeBSD's ntpd seems to be > very, very sparse with such informations, coverging to null - I can't see > anything suiatble in the logs why NTPD dies almost every night leaving the > system with a wild reset of time. Sometimes it is a gain of 6 hours, sometime > s > it is only half an hour. I leave the box at 16:00 local time usually and take > care again at ~ 7 o'clock in the morning local time. We will need to turn on debugging. Unfortunately debug code is not compiled into the binary. We have two options. You can either update src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's the exact same ntp) with the DEBUG option -- this is probably simpler. Then enable debug with -d and -D. -D increases verbosity. I just committed a debug option to both ntp ports to assist here. Next question: Do you see any indication of a core dump? I'd be interested in looking at it if possible. > > When the clock is floating that wild, in all cases ntpd isn't running any mor > e. > I try to restart with options -g and -G to adjust the time quickly at the > beginning, which works fine. This is disconcerting. If your clock is floating wildly without ntpd running there are other issues that might be at play here. At most the clock might drift a little, maybe a minute or two a day but not by a lot. Does the drift cause your clocks to run fast or slow? > > Apart from possible misconfigurations of the jails (I'm quite new to jails an > d > their pitfalls), I was wondering what causes ntpd to die. i can't determine > exactly the time of its death, so it might be related to diurnal/periodic > processes (I use only the most vanilla configurations on periodic, except for > checking ZFS's scrubbing enabled). As I'm a little rushed for time, I didn't catch whether the jails themselves were also running ntpd... just thought I'd ask. I don't see how zfs scrubbing or any other periodic scripts could cause this. > > I'ven't had the chance to check whether the hardware is completely all right, > but from a superficial point of view there is no issue with high gain of the > internal clock or other hardware issues. It's probably a good idea to check. I don't think that would cause ntpd any gas. I've seen RTC battery messages on my gear which haven't caused ntpd any problem. I have two machines which complain about RTC battery being dead, where in fact I have replaced the batteries and the messages still are displayed at boot. I'm not sure if it's possible for a kernel to damage the RTC. In my case that doesn't cause ntpd any problems. It's probably good to check anyway. > > If there are known issues with jails (the problem occurs since I use those), > advice is appreciated. Not that I know of. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is ipfilter firewall with ippool working?
In message <58e50379.6090...@gmail.com>, Ernie Luzar writes: > I have been a ipfilter user since Freebsd 3.0 without any complaints. > Now I'm trying to get ippool to function. I have been able to add a > pool, but now I want to refresh it's contents. From what I read in "man > 8 ippool", I have to remove the pool from core and then re-add it with > the complete new content. When I issue this command to remove the named > ippool from core, I get message saying "Segmentation fault (core > dumped)" and the system continues as normal. > > ippool -R -m unsolicited > > I know that in 2016 ipfilter was forked and updated to be freebsd > friendly. Thinking maybe something in the kernel code was changed that > now is causing this problem. I'm running release 11.0. > > Is there anyone out there who has ipfilter/ippool working? Hi, I use ipfilter (and have for a couple of decades on Solaris and FreeBSD). We haven't forked it but we are fixing bugs and pushing them upstream. Looking at the ippool source, this is another case of the source or man page being incorrect. Looking at earlier versions of the source and man pages, it appears to have been broken for almost forever. This is not the first command line parsing issue or man page discrepancy in ipfilter. Can you please file a PR and assign it to me? The todos will be to: 1. Determine whether the man page or the code is correct. 2. Verify that all arguments are parsed (and subsequently processes). 3. Verify that correct error messages are produced as appropriate. For now you can issue ippool -R -m unsolicited POOL_TYPE, where pool type is documented in the man page with -t (though that will also need to be verified). The ippool parser thinks the pool type is a positional argument not an option. I'd like to verify Darren Reed's (original author's) intention before blindly "fixing" anything. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'
The reason it's supposed to link in rpcsvc. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. In message <24642190-36ea-45e7-f392-de2b6e224...@protected-networks.net>, Micha el Butler writes: > Seems that SVN r314659 broke this :-( > > Michael > > On 03/04/17 11:11, O. Hartmann wrote: > > At revision 314670, buildworld fails on all CURRENT machines with the error > shown below. > > > > > > Regards, > > > > oh > > > > > > [...] > > ===> usr.sbin/amd/hlfsd (all) > > Building /usr/obj/usr/src/usr.sbin/amd/hlfsd/hlfsd > > --- hlfsd --- > > nfs_prot_svc.o: In function `nfs_program_2': > > /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x5f): undefined reference > to > > `xdr_attrstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x7d): unde > fined > > reference to `xdr_attrstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.tex > t+0x82): > > undefined reference to > > `xdr_sattrargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xa2): und > efined > > reference to `xdr_diropres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.tex > t+0xa7): > > undefined reference to > > `xdr_diropargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xb8): und > efined > > reference to `xdr_readlinkres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(. > text+0xc9): > > undefined reference to > > `xdr_readres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xce): undef > ined reference > > to `xdr_readargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xf5): u > ndefined > > reference to `xdr_attrstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.tex > t+0xfa): > > undefined reference to > > `xdr_writeargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x11b): un > defined > > reference to `xdr_nfsstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text > +0x120): > > undefined reference to > > `xdr_renameargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x12e): u > ndefined > > reference to `xdr_nfsstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text > +0x133): > > undefined reference to > > `xdr_linkargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x141): und > efined > > reference to `xdr_nfsstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text > +0x146): > > undefined reference to > > `xdr_symlinkargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x154): > undefined > > reference to `xdr_diropres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.tex > t+0x159): > > undefined reference to > > `xdr_createargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x167): u > ndefined > > reference to `xdr_nfsstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text > +0x16c): > > undefined reference to > > `xdr_diropargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x17a): un > defined > > reference to `xdr_readdirres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.t > ext+0x17f): > > undefined reference to > > `xdr_readdirargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x18d): > undefined > > reference to `xdr_statfsres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.te > xt+0x192): > > undefined reference to `xdr_nfs_fh' stubs.o: In function > > `nfsproc_readlink_2_svc': /usr/src/contrib/amd/hlfsd/stubs.c:(.text+0x6f7): > undefined > > reference to `xdr_readlinkres' cc: error: linker command failed with exit c > ode 1 (use -v > > to see invocation) *** [hlfsd] Error code 1 > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld error
rc/lib/libc > *** [all_subdir_lib/libc] Error code 2 > > make[3]: stopped in /usr/src/lib > 1 error > > make[3]: stopped in /usr/src/lib > *** [all_subdir_lib] Error code 2 > > make[2]: stopped in /usr/src > --- all_subdir_secure --- > A failure has been detected in another branch of the parallel make > > make[5]: stopped in /usr/src/secure/lib/libcrypto > *** [all_subdir_secure/lib/libcrypto] Error code 2 > > make[4]: stopped in /usr/src/secure/lib > 1 error > > make[4]: stopped in /usr/src/secure/lib > *** [all_subdir_secure/lib] Error code 2 > > make[3]: stopped in /usr/src/secure > 1 error > > make[3]: stopped in /usr/src/secure > *** [all_subdir_secure] Error code 2 > > make[2]: stopped in /usr/src > 4 errors > > make[2]: stopped in /usr/src > *** [everything] Error code 2 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [buildworld] Error code 2 > > make: stopped in /usr/src > 1 error > > make: stopped in /usr/src > 1551.754u 434.064s 17:54.86 184.7%12598+328k 113045+55926io 25455pf+14w That's from a r314812 five days ago. I rebuilt world in one of my development trees since then with no problem. Consider running make delete-old. There might be an old header in /usr/include that's getting in the way. Having said that, world should be self contained so, the assumed scenario above shouldn't happen (except in ports), meaning if make delete-old fixes the problem there may be a buglet in a makefile somewhere. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld error
In message <5cb065b0-5a7d-4a50-a722-8ea579a67...@freebsd.org>, Dimitry Andric w rites: > > > --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > On 12 Mar 2017, at 01:55, Roberto Rodriguez Jr <rob.rodz@gmail.com> = > wrote: > >=20 > > Now... > > make buildworld > ... > > In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15: > > In file included from = > /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20: > > In file included from > > /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19: > > In file included from /usr/include/c++/v1/algorithm:634: > > In file included from /usr/include/c++/v1/memory:604: > > /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' = > file not > > found > > #include <__undef___deallocate> > > ^ > > Yes, this is because of the bad advice to run "make delete-old" before > you had run "make installworld". You had an older version of libc++ in > /usr/include/c++, but that still required the __undef___deallocate > header, which has now been deleted by "make delete-old". > > Your best chance is to build and install libc++ first, if possible, by > doing: > > cd /usr/src/lib/libc++ > make obj > make depend > make > make install > > Then retry building world. If this actually fixes it, it (the build) is wrong. You shouldn't have to build and install src in order to build another part of src. The procedure has always been documented as make installworld first then make delete-old. Failing to do so will on rare occasions bite you when building a port. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld error
In message <CACnPvjJ6j_8arj7nS2uugCu1SnC2+Qxoy5rixiO_+Xe1H1cVnQ@mail.gmail.c om> , Roberto Rodriguez Jr writes: > Hey, > > Even with a fresh checkout of sources ( today 935am EST). Buildworld/kernel > fail 10 seconds into build. Can you post output, please? -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld error
In message <1c4e6a09-86ad-4dc7-aa65-336a1643e...@freebsd.org>, Dimitry Andric w rites: > > > --Apple-Mail=_41B95E0F-96E1-4E0A-A996-DE3C34E4B13B > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=us-ascii > > On 12 Mar 2017, at 02:46, Cy Schubert <cy.schub...@komquats.com> wrote: > > > > In message <5cb065b0-5a7d-4a50-a722-8ea579a67...@freebsd.org>, Dimitry > > Andric w > > rites: > >> > >> > >> --Apple-Mail=_A0AD1F4B-1279-4DA7-85F9-FB9846A878D7 > >> Content-Transfer-Encoding: quoted-printable > >> Content-Type: text/plain; > >>charset=us-ascii > >> > >> On 12 Mar 2017, at 01:55, Roberto Rodriguez Jr <rob.rodz@gmail.com> = > >> wrote: > >>> =20 > >>> Now... > >>> make buildworld > >> ... > >>> In file included from /usr/src/contrib/llvm/lib/Support/APInt.cpp:15: > >>> In file included from = > >> /usr/src/contrib/llvm/include/llvm/ADT/APInt.h:20: > >>> In file included from > >>> /usr/src/contrib/llvm/include/llvm/Support/MathExtras.h:19: > >>> In file included from /usr/include/c++/v1/algorithm:634: > >>> In file included from /usr/include/c++/v1/memory:604: > >>> /usr/include/c++/v1/new:73:10: fatal error: '__undef___deallocate' = > >> file not > >>> found > >>> #include <__undef___deallocate> > >>>^ > >> > >> Yes, this is because of the bad advice to run "make delete-old" before > >> you had run "make installworld". You had an older version of libc++ in > >> /usr/include/c++, but that still required the __undef___deallocate > >> header, which has now been deleted by "make delete-old". > >> > >> Your best chance is to build and install libc++ first, if possible, by > >> doing: > >> > >> cd /usr/src/lib/libc++ > >> make obj > >> make depend > >> make > >> make install > >> > >> Then retry building world. > > > > If this actually fixes it, it (the build) is wrong. You shouldn't have to > > build and install src in order to build another part of src. > > > > The procedure has always been documented as make installworld first then > > make delete-old. Failing to do so will on rare occasions bite you when > > building a port. > > Yes, but in this case Roberto ran "make delete-old" *before* installing > world, on your advice. That is definitely something that should be > avoided. That's not what I was talking about. I should have worded that better, as in for next time. People should run make delete-old after the previous installworld and prior to the next buildworld. Even so, the contents of the current /usr/include should not affect the current buildworld. In practice this is still the case. r307800 is a good example of this. I wouldn't be surprised there's more of this in src. > > E.g., "make delete-old" should only ever be run with exactly the same > source tree that your current world was installed from. And preferably > right after "make installworld" and updating /etc. Exactly! -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AMD CPU/APU temperature driver
In message <20170306090406.GA1869@c720-r292778-amd64>, Matthias Apitz writes: > El dÃa Monday, March 06, 2017 a las 05:04:31AM +0300, Rozhuk Ivan escribió: > > > Hi! > > > > > > New amdtemp driver needs more testers! > > > > > > https://reviews.freebsd.org/D9759 > > > > Fast buld/install: > > ...download and apply patch... > > kldunload amdtemp > > cd /usr/src/sys/modules/amdtemp/ > > make > > make install > > make cleandir > > kldload amdtemp > > > > > > rus/eng: http://netlab.dhis.org/wiki/ru:software:freebsd:amdtemp > > Hi, > > The English version of the Wiki gives only: This topic does not exist > yet. Is there an English version? I get the following: This topic does not exist yet You've followed a link to a topic that doesn't exist yet. If permissions allow, you may create it by clicking on \u201cCreate this page\u201d. I have three older AMD X2 boxes in my basement. I could give it a spin when I get a chance. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is ipfilter firewall with ippool working?
In message <58e656c6.8000...@gmail.com>, Ernie Luzar writes:
> Cy Schubert wrote:
> > In message <58e50379.6090...@gmail.com>, Ernie Luzar writes:
> >> I have been a ipfilter user since Freebsd 3.0 without any complaints.
> >> Now I'm trying to get ippool to function. I have been able to add a
> >> pool, but now I want to refresh it's contents. From what I read in "man
> >> 8 ippool", I have to remove the pool from core and then re-add it with
> >> the complete new content. When I issue this command to remove the named
> >> ippool from core, I get message saying "Segmentation fault (core
> >> dumped)" and the system continues as normal.
> >>
> >> ippool -R -m unsolicited
> >>
> >> I know that in 2016 ipfilter was forked and updated to be freebsd
> >> friendly. Thinking maybe something in the kernel code was changed that
> >> now is causing this problem. I'm running release 11.0.
> >>
> >> Is there anyone out there who has ipfilter/ippool working?
> >
> > Hi,
> >
> > I use ipfilter (and have for a couple of decades on Solaris and FreeBSD).
> > We haven't forked it but we are fixing bugs and pushing them upstream.
> >
> > Looking at the ippool source, this is another case of the source or man
> > page being incorrect. Looking at earlier versions of the source and man
> > pages, it appears to have been broken for almost forever. This is not the
> > first command line parsing issue or man page discrepancy in ipfilter.
> >
> > Can you please file a PR and assign it to me? The todos will be to:
> >
> > 1. Determine whether the man page or the code is correct.
> > 2. Verify that all arguments are parsed (and subsequently processes).
> > 3. Verify that correct error messages are produced as appropriate.
> >
> > For now you can issue ippool -R -m unsolicited POOL_TYPE, where pool type
> > is documented in the man page with -t (though that will also need to be
> > verified). The ippool parser thinks the pool type is a positional argument
> > not an option.
> >
> > I'd like to verify Darren Reed's (original author's) intention before
> > blindly "fixing" anything.
> >
> >
>
> Thank you for taking on this project to fix ippool. I have stumbled
> across many items that don't work as documented or the documentation
> doesn't provide enough information about the required syntax.
The parser is definitely broken. I discovered another broken parser last
year.
>
> Yes I can submit a pr. I will add to your to-do list pointing out things
> that need addressing.
>
> I have already tried "ippool -R -m unsolicited -t tree" and it gives
> error ilegal option --t
That is because -t isn't parsed (via getopt()). Just put in the table name
but without the "-t" characters.
>
> The usage of this command is to remove the named pool from running in
> core so it can be re-added in mass with updated content.
>
> I can all most do the same thing using this command sequence
> ippool -f /etc/ippool.conf -u
> this unloads all the entries but leaves the pool name in place
> then this command reloads in mass
> ippool -f /etc/ippool.conf
>
> Can you suggest some other way the get ippool -R command working?
Attached is a patch. Except for basic functionality, I haven't tested it
but it should get you going for now. I'll add this to my list of things to
completely fix. There are other parser issues in ippool. I'm going out of
town in a couple of days. I'll work on a more comprehensive patch when I
get back in 12 days.
The patch has also been attached to the PR. Let's continue talking there.
Index: contrib/ipfilter/tools/ippool.c
===
--- contrib/ipfilter/tools/ippool.c (revision 316573)
+++ contrib/ipfilter/tools/ippool.c (working copy)
@@ -262,7 +262,7 @@
char *argv[];
{
int type, role, c, err;
- char *poolname;
+ char *poolname, *typearg = NULL;
iphtable_t iph;
ip_pool_t pool;
@@ -274,7 +274,9 @@
bzero((char *), sizeof(iph));
bzero((char *), sizeof(pool));
- while ((c = getopt(argc, argv, "dm:no:RSv")) != -1)
+ optreset = optind = 1;
+
+ while ((c = getopt(argc, argv, "dm:no:RSvt:")) != -1)
switch (c)
{
case 'd' :
@@ -303,8 +305,18 @@
case 'v' :
opts |= OPT_VERBOSE;
break;
+ case 't' :
+ type = gettype(optarg, _type);
+ typearg = optar
Re: small patch for /etc/rc.d/nfsd, bugfix or POLA violation?
In message <ytxpr01mb0189f5614497d4fa96a7579add...@ytxpr01mb0189.canprd01.pr OD. OUTLOOK.COM>, Rick Macklem writes: > --_002_YTXPR01MB0189F5614497D4FA96A7579ADDA80YTXPR01MB0189CANP_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi, > > The attached one line patch to /etc/rc.d/nfsd modifies the script so that i= > t > does not force the nfsuserd to be run when nfsv4_server_enable is set. > (nfsuserd can still be enabled via nfsuserd_enable=3D"YES" is /etc/rc.conf.= > ) > > Here's why I think this patch might be appropriate... > (a) - The original RFC for NFSv4 (RFC3530) essentially required Owners and >Owner_groups to be specified as @ and this required >the nfsuserd daemon to be running. > (b) - RFC7530, which replace RFC3530, allows a Owner/Owner_group string to = > be > the uid/gid number in a string when using AUTH_SYS. This simplifies confi= > guration > for an all AUTH_SYS/POSIX environment (most NFS uses, I suspect?). > > To make the server do (b), two things need to be done: > 1 - set vfs.nfsd.enable_stringtouid=3D1 > 2 - set vfs.nfsd.enable_uidtostring=3D1 (for head, I don't know if it will = > be MFC'd?) > OR > - never run nfsuserd after booting (killing it off after it has been runn= > ing is not > sufficient) > =20 > Given the above, it would seem that /etc/rc.d/nfsd should not force running= > of > the nfsuserd daemon, due to changes in the protocol. > > However, this will result in a POLA violation, in that after the patch, nfs= > userd won't > start when booting, unless nfsuserd_enable=3D"YES" is added to /etc/rc.conf= > . > > So, what do people think about this patch? rick= How about a warning message + an UPDATING entry + no MFC? And, relnotes = yes to say we now support RFC7530 in 12.0? -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory
In message <201706271956.v5rjujqp065...@slippy.cwsent.com>, Cy Schubert
writes:
> In message <83207990-cd7c-90ea-6893-c0b3b1321...@passap.ru>, Boris
> Samorodov wr
> ites:
> > 27.06.2017 20:06, Trond Endrestøl пиÑеÑ:
> >
> > > Try running make installworld without -j N.
> > > Serial installworld was successful at my end.
> >
> > Thank you, that helped.
>
> For users doing poudriere jail -c or poudriere jail -u, use -J 1, though
> poudriere should only perform parallel builds only, not parallel installs.
> Parallel installs is simply asking for trouble regardless.
The patch I'm about to post here isn't quite correct. Either base or the
port's upstream should be patched to resolve this but this should help
someone somewhere.
Index: Makefile
===
--- Makefile(revision 444518)
+++ Makefile(working copy)
@@ -2,7 +2,7 @@
PORTNAME= poudriere
DISTVERSION= 3.1.19
-PORTREVISION= 0
+PORTREVISION= 1
CATEGORIES=ports-mgmt
MASTER_SITES= LOCAL/bdrewery/${PORTNAME}/ \
http://mirror.shatow.net/freebsd/${PORTNAME}/ \
Index: files/patch-src__share__poudriere__jail.sh
===
--- files/patch-src__share__poudriere__jail.sh (nonexistent)
+++ files/patch-src__share__poudriere__jail.sh (working copy)
@@ -0,0 +1,27 @@
+--- src/share/poudriere/jail.sh.orig 2017-06-01 10:21:58.0 -0700
src/share/poudriere/jail.sh2017-06-27 13:06:20.548694000 -0700
+@@ -272,21 +272,16 @@
+ }
+
+ installworld() {
+- local make_jobs
+ local destdir="${JAILMNT}"
+
+- if [ ${JAIL_OSVERSION} -gt 1100086 ]; then
+- make_jobs="${MAKE_JOBS}"
+- fi
+-
+ msg "Starting make installworld"
+- ${MAKE_CMD} -C "${SRC_BASE}" ${make_jobs} installworld \
++ ${MAKE_CMD} -C "${SRC_BASE}" installworld \
+ DESTDIR=${destdir} DB_FROM_SRC=1 || \
+ err 1 "Failed to 'make installworld'"
+- ${MAKE_CMD} -C "${SRC_BASE}" ${make_jobs} DESTDIR=${destdir} \
++ ${MAKE_CMD} -C "${SRC_BASE}" DESTDIR=${destdir} \
+ DB_FROM_SRC=1 distrib-dirs || \
+ err 1 "Failed to 'make distrib-dirs'"
+- ${MAKE_CMD} -C "${SRC_BASE}" ${make_jobs} DESTDIR=${destdir} \
++ ${MAKE_CMD} -C "${SRC_BASE}" DESTDIR=${destdir} \
+ distribution || err 1 "Failed to 'make distribution'"
+
+ return 0
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory
In message <83207990-cd7c-90ea-6893-c0b3b1321...@passap.ru>, Boris Samorodov wr ites: > 27.06.2017 20:06, Trond Endrestøl пиÑеÑ: > > > Try running make installworld without -j N. > > Serial installworld was successful at my end. > > Thank you, that helped. For users doing poudriere jail -c or poudriere jail -u, use -J 1, though poudriere should only perform parallel builds only, not parallel installs. Parallel installs is simply asking for trouble regardless. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory
In message <291c901c-7b78-7f4f-dd8d-d808406fb...@freebsd.org>, Bryan Drewery wr ites: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --UMVEimIc8tkOmRSqA1n5pHiCvanl0O7sJ > Content-Type: multipart/mixed; boundary="lqMESdlFVuAvpHCbkFDFe9mUliTQ2oLlW"; > protected-headers="v1" > From: Bryan Drewery <bdrew...@freebsd.org> > To: Cy Schubert <cy.schub...@komquats.com> > Cc: Boris Samorodov <b...@passap.ru>, freebsd-current@freebsd.org, > b...@freebsd.org > Message-ID: <291c901c-7b78-7f4f-dd8d-d808406fb...@freebsd.org> > Subject: Re: [base package build] [fail] r320347 -> r320392: install: > builddir/Africa/Abidjan: No such file or directory > References: <201706272014.v5rkej8l042...@slippy.cwsent.com> > In-Reply-To: <201706272014.v5rkej8l042...@slippy.cwsent.com> > > --lqMESdlFVuAvpHCbkFDFe9mUliTQ2oLlW > Content-Type: text/plain; charset=utf-8 > Content-Language: en-US > Content-Transfer-Encoding: quoted-printable > > On 6/27/17 1:14 PM, Cy Schubert wrote: > > In message <201706271956.v5rjujqp065...@slippy.cwsent.com>, Cy Schubert= > =20 > > writes: > >> In message <83207990-cd7c-90ea-6893-c0b3b1321...@passap.ru>, Boris=20 > >> Samorodov wr > >> ites: > >>> 27.06.2017 20:06, Trond Endrest=C3=83=C2=B8l =C3=90=C2=BF=C3=90=C2=B8= > =C3=91=CB=86=C3=90=C2=B5=C3=91=E2=80=9A: > >>> > >>>> Try running make installworld without -j N. > >>>> Serial installworld was successful at my end. > >>> > >>> Thank you, that helped. > >> > >> For users doing poudriere jail -c or poudriere jail -u, use -J 1, thou= > gh=20 > >> poudriere should only perform parallel builds only, not parallel insta= > lls.=20 > >> Parallel installs is simply asking for trouble regardless. > >=20 > > Parallel install should be working just fine. It is a supported feature > of installworld. What was the issue exactly? I had some problems a few moths ago, maybe a year ago, I can't recall exactly. After a recent email exchange I decided to try again. It works now. I must have hit a rough spot at one point. I've updated my scripts to use parallel install again. I'll raise a red flag next time rather than quietly adjusting what I do. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [autofs] problems with "dirty" UFS2 partitions
In message <20170808071758.6a815...@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > Hello, > > we're running a NanoBSD based appliance which resides on a small SoC and > utilises a mSATA SSD for logging, database storage and mail folder. The > operating system is recent CURRENT as it is still under development. > > The problem ist, that from time to time, without knowing or seeing the reason > , > the automounted partitions become "dirty (UFS2 partitions, no ZFS dur to > memory and performance limitations). Journaling is enbaled. > > When the partitions on the SSD become "dirty", logging or accessing them isn' > t > possible anymore and for some reason I do not see any log entries reporting > this (maybe due to the fact all logs are going also to that disk since the lo > gs > would pollute the serial console/console and the console is used for > maintenance purposes/ssh terminal). > > Is it possible to - automated! - check the filesystem on bootup? As on ordina > ry > FreeBSD systems with fstab-based filesystems, this happens due to the > rc-init-infrastructure but autofs filesystems seem to be somehow standing asi > de > from this procedure. I'd be interested in finding out if your system either panicked or simply failed to unmount the filesystems in question during a boot or shutdown. Is the SSD being removed prior to FreeBSD having the chance to unmount it? I think if we answer These questions we're more than half way there. Warner has a good suggestion worth considering. Another option might be to use amd program maps. The program map being a program or script that would run fsck prior to issuing a mount. Having said that, this treats the symptom rather than addressing the cause. It's preferred to discover the cause so that autofs (or amd) can mount a clean filesystem. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [autofs] problems with "dirty" UFS2 partitions
In message <20170808132621.1f14c...@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > On Mon, 07 Aug 2017 23:48:15 -0700 > Cy Schubert <cy.schub...@komquats.com> wrote: > > > Just for convenience, I 'glued" Warner Losh's messages below and reply inline > as usual. > > > In message <20170808071758.6a815...@freyja.zeit4.iv.bundesimmobilien.de>, > > "O. H > > artmann" writes: > > > Hello, > > > > > > we're running a NanoBSD based appliance which resides on a small SoC and > > > utilises a mSATA SSD for logging, database storage and mail folder. The > > > operating system is recent CURRENT as it is still under development. > > > > > > The problem ist, that from time to time, without knowing or seeing the > > > reason , > > > the automounted partitions become "dirty (UFS2 partitions, no ZFS dur to > > > memory and performance limitations). Journaling is enbaled. > > > > > > When the partitions on the SSD become "dirty", logging or accessing them > > > isn' t > > > possible anymore and for some reason I do not see any log entries reporti > ng > > > this (maybe due to the fact all logs are going also to that disk since th > e > > > lo gs > > > would pollute the serial console/console and the console is used for > > > maintenance purposes/ssh terminal). > > > > > > Is it possible to - automated! - check the filesystem on bootup? As on > > > ordina ry > > > FreeBSD systems with fstab-based filesystems, this happens due to the > > > rc-init-infrastructure but autofs filesystems seem to be somehow standing > > > asi de > > > from this procedure. > > > > I'd be interested in finding out if your system either panicked or simply > > failed to unmount the filesystems in question during a boot or shutdown. Is > > > the SSD being removed prior to FreeBSD having the chance to unmount it? I > > think if we answer These questions we're more than half way there. > > The system in question is logging onto this mSATA SSD and the filesystem is > mounted/unmounted via autofs. I do not see any syystem/core faults when doing > a > reboot and the cases, where the filesystem is unclean after a reboot are rare > . > But it is even deadly if the system is required to log (it is a > routing/PBX/DNS/firewalling system with FAX and answering machine/recording > facilities). > > The only clue I have is that due to the unmount attempt of autounmountd while > still writing logging data the filesystem remains in an unclean condition. Bu > t > the question is then what is causing this condition. It's not unmounting for this very reason. It can't. (Try umount of a filesystem which has files still open.) > > > > > Warner has a good suggestion worth considering. > > > > Another option might be to use amd program maps. The program map being a > > program or script that would run fsck prior to issuing a mount. Having said > > > that, this treats the symptom rather than addressing the cause. It's > > preferred to discover the cause so that autofs (or amd) can mount a clean > > filesystem. > > Is this also possible with the in-kernel autofs facility? I replaced the amd > daemon by the more modern autofs feature and - sorry - I didn't look into the > man page while writing the mail. I'll check that out. > > The main question is, if the above described condition of writing log data an > d > unmount at the same time results in an unresolvable race condition, to simply > mount the SSD filesystem via /etc/fstab. The box is booting off a SD card, th > e > mSATA SSD is for loggin/data only and I wanted it to make it as robust as > possible with the main on having the firewall/router online to let traffic > traverse instead of being blocked when the system fails mounting a filesystem > , > which is not necessary for survival. To have log or to have traffic passing i > s > the essential question to answere here ... You could mount late or issue an fsck in rc.local. In rc.local, if it fails simply spit out an error message (or email). > > > > > > > > [from Warner Losh] > > Can't you just list them in /etc/fstab with the noauto option, but with a > > non-zero number listed in the 'pass' number column? I know nanobsd doesn't > > generate things this way, but maybe it should > > > > Warner > > I haven't though of this ever - will it force a check of a dirty filesystem > even when it is mounted via autofs? I considered /etc/fstab and autofs as > mutual exclusive - in my naive view ... > > Thank you very much, > > Oliver -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: swapfile query
In message <bad32602-c6a9-4a82-b0cb-148d313b9...@freebsd.org>, David Chisnall w rites: > On 19 Aug 2017, at 17:54, Cy Schubert <cy.schub...@komquats.com> wrote: > > > >> 3. should total swap be 1x 2x or some other multiple of RAM these days? > > > > Depends. If you're running some kind of database server or OLTP > > application. Some vendors recommend no swap whatsoever while others > > recommend some. What does your application vendor recommend? > > The main advantage of swap these days (on machines with that sort of amount o > f RAM) is to allow you to keep some file-backed memory objects in memory in p > reference to leaked (or very cold) heap memory. Memory overcommitment and the working set of each address space determines how much and what is paged out. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: swapfile query
In message <b357df9a-e38f-c635-a44a-11f6085bc...@zyxst.net>, tech-lists writes: > On 19/08/2017 17:54, Cy Schubert wrote: > > Then it doesn't matter if you use one or many swapfiles and deleting the 4 > > GB won't make a difference. Just add the desired swap as required. > > > > With 128 GB RAM you shouldn't be swapping anyway. If your system is you > > have more serious problems than the lack of swap. > > The system is a bhyve host. There are 9 guests, two of them are > freebsd-11-stable, the rest are ubuntu-14.04-LTS. Restarting some (but > not all) of the guests has the effect of decreasing swap usage. The > system also runs ZFS. The guests live on the ZFS filesystem. > > The OS & swap on the host are SSD and are not part of the ZFS system. > > What I'm seeing is, the host system won't touch swap for days. I guess > when the guests get busier than an as yet unknown amount, the host > starts using swap. The issue I'm having isn't so much it using swap, > it's that the used swap seemingly is not liberated after it has been > used, and I don't know exactly how to narrow it down. An easy way to find out is to run top, type in "w", then "o" and "swap" to see which processes are using swap. You'll notice that the numbers won't add up. I haven't looked at this but my guess is that there may be swap leak. You can verify this by replacing the swapfile (add a new and remove the old). Run vmstat. If the system is actively paging you will see page outs and page ins, some page reclaims, and a scan rate in the hundreds. (On my -CURRENT laptop I see a scan rate in the hundreds on a totally idle laptop and in the teens of my idle firewall. IMO this doesn't seem right, at least not compared to previous releases of FreeBSD or from the days when I worked on Solaris. You shouldn't see a scan rate on an idle system.) My rule of thumb [was] scan rate less than 200 is good or to put it another way if you're using more than 5% of your system resources ( > 5% CPU or > 5% disk I/O) paging or swapping you need more RAM. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: swapfile query
In message <201708192100.v7jl0vfk003...@slippy.cwsent.com>, Cy Schubert writes: > (On my -CURRENT laptop I see a scan rate in the hundreds on a totally idle > laptop and in the teens of my idle firewall. IMO this doesn't seem right, > at least not compared to previous releases of FreeBSD or from the days when > I worked on Solaris. You shouldn't see a scan rate on an idle system.) It appears that on an idle system with many pages in use, i.e. a laptop running X and not really doing anything else, pages are scanned though the system is idle. This is likely an artifact of r308474. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: swapfile query
In message <20170819213149.GA34140@raichu>, Mark Johnston writes: > On Sat, Aug 19, 2017 at 02:24:19PM -0700, Cy Schubert wrote: > > In message <201708192100.v7jl0vfk003...@slippy.cwsent.com>, Cy Schubert > > writes: > > > > > (On my -CURRENT laptop I see a scan rate in the hundreds on a totally idl > e > > > laptop and in the teens of my idle firewall. IMO this doesn't seem right, > > > > at least not compared to previous releases of FreeBSD or from the days wh > en > > > I worked on Solaris. You shouldn't see a scan rate on an idle system.) > > > > It appears that on an idle system with many pages in use, i.e. a laptop > > running X and not really doing anything else, pages are scanned though the > > system is idle. This is likely an artifact of r308474. > > It's an intentional consequence of r254304. The page daemon performs a > slow and steady scan of the queue of active pages and will gradually > move unreferenced pages to the inactive queue. This is certainly better. It's probably good idea to remove scan rate from vmstat output as it's not meaningful in the traditional sense any more. For example on a traditionally scanning VM system (Solaris or z/OS) the number of pages scanned per second (or unreferenced interval count -- the inverse of the scan rate) is the first indication that you need to look at your vm subsystem. As of r254304 rate cannot be used used as a metric any more except when one sees it deviate wildly from previous observations. (Not that I'm complaining.) See below: procs memory pagedisks faults cpu r b w avm fre flt re pi pofr sr ad0 da0 insycs us sy id 0 0 0 3.9G 292M 4 0 0 0 193 125 0 0 434 773 588 0 0 100 1 0 0 3.9G 292M55 0 0 0 181 123 22 0 460 2467 1402 0 1 99 0 0 0 3.9G 290M 969 0 0 1 316 124 1 0 490 12571 4004 3 1 95 0 0 0 3.9G 289M 261 0 0 0 160 124 21 0 505 20426 7751 2 2 97 0 0 0 1.5G 755M 3481 0 1 1 60951 74 18 0 463 19918 6576 13 4 82 At this point I closed firefox. Pages are freed and scan rate decreases. We now have a new normal. 0 0 0 1.5G 752M10 0 0 0 0 24 1 0 409 595 365 0 0 100 0 0 0 1.5G 754M 1 0 0 0 403 23 49 0 478 609 1321 0 1 99 0 0 0 1.5G 754M19 0 0 0 171 24 0 0 402 655 382 0 0 100 0 0 0 1.5G 754M 0 0 0 0 170 24 0 0 423 568 463 0 0 100 0 0 0 1.5G 754M 0 0 0 0 174 12 0 0 403 627 359 0 0 100 0 0 0 1.5G 754M 0 0 0 0 172 35 4 0 425 625 474 0 0 100 0 0 0 1.5G 754M 1 0 0 0 170 24 4 0 416 651 398 0 0 100 0 0 0 1.5G 754M 0 0 0 0 163 23 1 0 426 655 490 0 0 100 0 0 0 1.5G 754M 0 0 0 0 176 23 0 0 429 663 384 0 0 100 0 0 0 1.5G 754M 0 0 0 0 163 23 0 0 445 661 482 0 0 100 Should we consider removing scan rate from vmstat output? It doesn't really mean anything in relation to tuning any more. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
