Re: misc/mc, diff and compare two files
On Sun, May 14, 2017 at 7:53 AM, Boris Samorodov wrote: > Hi All, > > FYI: For those who use FreeBSD-HEAD, misc/mc and it's awesome "compare > two files" feature: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219277 > > HTH > -- > WBR, bsam Or use the "compare [two|three] [buffers|files]" tool in emacs. Being able to deal with three files can be surprisingly handy. emacs is a great tool for many things and I even find it has a pretty good editor, though most vim? users seem to disagree. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: UC Berkeley 4-clause copyright
In looking at NetBSD/OpenBSD's math_private.h, it seems the content of mathimpl.h have been tacked onto it. -- steve On Tue, May 16, 2017 at 05:55:24PM -0700, Steve Kargl wrote: > I don't have a commit bit. I just checked OpenBSD/NetBSD. > They use a 3-clause license. > > -- > steve > > On Tue, May 16, 2017 at 06:51:30PM -0600, Warner Losh wrote: > > If it says that it's copyright those people, that's an issue. If it > > doesn't then there's no issue. Doesn't look like it does. If you'd > > like, I can look at it an DTRT if you're unsure. > > > > Warner > > > > On Tue, May 16, 2017 at 6:48 PM, Steve Kargl > > wrote: > > > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: > > >> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl > > >> wrote: > > >> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > > >> > Copyright. Supposedly UCB no longer enforces clause 3. Can > > >> > clause 3 be removed? > > >> > > > >> Yes. Remove it. It's convention these days to also renumber. It was > > >> likely missed. > > >> > > >> Are there other copyright holders? If so, that would be why I didn't > > >> remove it at the time years ago But I may have missed them too. > > >> > > > > > > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have > > > onlu UCB in file (other than bde and das in the RCS string). > > > > > > lib/msun/b_tgamma.c has a standard 4-clause BSD license with > > > the years 1992 and 1993 listed. But, later in the file there > > > is the comment > > > > > > /* > > > * This code by P. McIlroy, Oct 1992; > > > * > > > * The financial support of UUNET Communications Services is greatfully > > > * acknowledged. > > > */ > > > > > > IANAL, so I don't know if this triggers the "and its contributors." > > > portion of clause 3. > > > > > > lib/msun/b_exp.c has a standard 4-clause BSD license with the > > > years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog > > > like annotation > > > > > > /* EXP(X) > > > * RETURN THE EXPONENTIAL OF X > > > * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) > > > * CODED IN C BY K.C. NG, 1/19/85; > > > * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, > > > 6/14/86. > > > > > > Again, IANAL. > > > > > > -- > > > Steve > > > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > > > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > > ___ > > 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" > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ 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: UC Berkeley 4-clause copyright
I don't have a commit bit. I just checked OpenBSD/NetBSD. They use a 3-clause license. -- steve On Tue, May 16, 2017 at 06:51:30PM -0600, Warner Losh wrote: > If it says that it's copyright those people, that's an issue. If it > doesn't then there's no issue. Doesn't look like it does. If you'd > like, I can look at it an DTRT if you're unsure. > > Warner > > On Tue, May 16, 2017 at 6:48 PM, Steve Kargl > wrote: > > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: > >> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl > >> wrote: > >> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > >> > Copyright. Supposedly UCB no longer enforces clause 3. Can > >> > clause 3 be removed? > >> > > >> Yes. Remove it. It's convention these days to also renumber. It was > >> likely missed. > >> > >> Are there other copyright holders? If so, that would be why I didn't > >> remove it at the time years ago But I may have missed them too. > >> > > > > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have > > onlu UCB in file (other than bde and das in the RCS string). > > > > lib/msun/b_tgamma.c has a standard 4-clause BSD license with > > the years 1992 and 1993 listed. But, later in the file there > > is the comment > > > > /* > > * This code by P. McIlroy, Oct 1992; > > * > > * The financial support of UUNET Communications Services is greatfully > > * acknowledged. > > */ > > > > IANAL, so I don't know if this triggers the "and its contributors." > > portion of clause 3. > > > > lib/msun/b_exp.c has a standard 4-clause BSD license with the > > years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog > > like annotation > > > > /* EXP(X) > > * RETURN THE EXPONENTIAL OF X > > * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) > > * CODED IN C BY K.C. NG, 1/19/85; > > * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. > > > > Again, IANAL. > > > > -- > > Steve > > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > ___ > 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" -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ 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: UC Berkeley 4-clause copyright
If it says that it's copyright those people, that's an issue. If it doesn't then there's no issue. Doesn't look like it does. If you'd like, I can look at it an DTRT if you're unsure. Warner On Tue, May 16, 2017 at 6:48 PM, Steve Kargl wrote: > On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: >> On Tue, May 16, 2017 at 6:23 PM, Steve Kargl >> wrote: >> > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley >> > Copyright. Supposedly UCB no longer enforces clause 3. Can >> > clause 3 be removed? >> > >> Yes. Remove it. It's convention these days to also renumber. It was >> likely missed. >> >> Are there other copyright holders? If so, that would be why I didn't >> remove it at the time years ago But I may have missed them too. >> > > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have > onlu UCB in file (other than bde and das in the RCS string). > > lib/msun/b_tgamma.c has a standard 4-clause BSD license with > the years 1992 and 1993 listed. But, later in the file there > is the comment > > /* > * This code by P. McIlroy, Oct 1992; > * > * The financial support of UUNET Communications Services is greatfully > * acknowledged. > */ > > IANAL, so I don't know if this triggers the "and its contributors." > portion of clause 3. > > lib/msun/b_exp.c has a standard 4-clause BSD license with the > years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog > like annotation > > /* EXP(X) > * RETURN THE EXPONENTIAL OF X > * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) > * CODED IN C BY K.C. NG, 1/19/85; > * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. > > Again, IANAL. > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ 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: UC Berkeley 4-clause copyright
On Tue, May 16, 2017 at 06:37:56PM -0600, Warner Losh wrote: > On Tue, May 16, 2017 at 6:23 PM, Steve Kargl > wrote: > > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > > Copyright. Supposedly UCB no longer enforces clause 3. Can > > clause 3 be removed? > > > Yes. Remove it. It's convention these days to also renumber. It was > likely missed. > > Are there other copyright holders? If so, that would be why I didn't > remove it at the time years ago But I may have missed them too. > lib/msun/b_log.c and lib/msun/mathimpl.h have appear to have onlu UCB in file (other than bde and das in the RCS string). lib/msun/b_tgamma.c has a standard 4-clause BSD license with the years 1992 and 1993 listed. But, later in the file there is the comment /* * This code by P. McIlroy, Oct 1992; * * The financial support of UUNET Communications Services is greatfully * acknowledged. */ IANAL, so I don't know if this triggers the "and its contributors." portion of clause 3. lib/msun/b_exp.c has a standard 4-clause BSD license with the years 1985 and 1993 listed. Later in the file is KC Ng's ChangeLog like annotation /* EXP(X) * RETURN THE EXPONENTIAL OF X * DOUBLE PRECISION (IEEE 53 bits, VAX D FORMAT 56 BITS) * CODED IN C BY K.C. NG, 1/19/85; * REVISED BY K.C. NG on 2/6/85, 2/15/85, 3/7/85, 3/24/85, 4/16/85, 6/14/86. Again, IANAL. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ 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: UC Berkeley 4-clause copyright
Yes. Remove it. It's convention these days to also renumber. It was likely missed. Are there other copyright holders? If so, that would be why I didn't remove it at the time years ago But I may have missed them too. Warner On Tue, May 16, 2017 at 6:23 PM, Steve Kargl wrote: > The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley > Copyright. Supposedly UCB no longer enforces clause 3. Can > clause 3 be removed? > > -- > Steve > 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > ___ > 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"
UC Berkeley 4-clause copyright
The files in lib/msun/bsdsrc contain the 4-clause UC Berkeley Copyright. Supposedly UCB no longer enforces clause 3. Can clause 3 be removed? -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ 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: build src with colored output?
David Chisnall wrote: > Ideally, we’d solve this by fixing bmake to behave more like a modern > build tool and: It's called meta mode ;-) and makes the OP's real issue much easier - when build fails, the failing .meta file is saved in src/../error/ providing no doubt and no need to search. ___ 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 not working with MAKEOBJDIRPREFIX
Roger Pau Monné wrote: > $ cd /home/royger/buildjob/freebsd > $ make -j30 buildworld MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ That will not work as desired. When you set VAR=val as an argument to make, it overrides anything the makefiles want to do and there are a number of points where the top level makefiles want to play with MAKEOBJDIRPREFIX By contrast; MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ make -j30 buildworld or for csh users; env MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ make -j30 buildworld provides the same value via the environment, this leaves the makefiles able to do as they will. ___ 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: IFLIB: em0/igb0 broken: No buffer space available/TX(0) desc avail = 1024, pidx = 0
On Tue, May 16, 2017 at 06:56:23AM +0200, O. Hartmann wrote: > Since the introduction of IFLIB, I have big trouble with especially a certain > type of NIC, namely formerly known igb and em. > > The worst device is an Intel NIC known as i217-LM > > em0@pci0:0:25:0:class=0x02 card=0x11ed1734 chip=0x153a8086 > rev=0x05 > hdr=0x00 vendor = 'Intel Corporation' > device = 'Ethernet Connection I217-LM' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xfb30, size 131072, enabled > bar [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled > bar [18] = type I/O Port, range 32, base 0xf020, size 32, enabled > > This NIC is widely used by Fujitsu's workstations CELSIUS M740 and the fate > would have it, that I have to use one of these. > > When syncing data over the network from the workstation to an older C2D/bce > based server via NFSv4, since introduction of IFLIB the connection to the NFS > get stuck and I receive on the console messages like > > em0: TX(0) desc avail = 1024, pidx = 0 > em0: TX(0) desc avail = 42, pidx = 985 > > Hitting "Ctrl-T" on the terminal doing the sync via "rsync", I see then this > message: > > load: 0.01 cmd: rsync 68868 [nfsaio] 395.68r 4.68u 4.64s 0% 3288k (just for > the record) > > Server and client(s) are on 12-CURRENT: ~ FreeBSD 12.0-CURRENT #38 r318285: > Mon > May 15 12:27:29 CEST 2017 amd64, customised kernels and "netmap" enabled (just > for the record if that matters). > > In the past, I was able to revive the connection by simply putting the NIC > down > and then up again and while I had running a ping as a trace indication of the > state of the NIC, I got very often > > ping: sendto: No buffer space available > > Well, today I checked via dmesg the output to gather again those messages and > realised that the dmesg is garbled: > > [...] > nfs nfs servnnfs servefs r server19 2.19162n.fs snerver fs1 s9nfs s2er.nfs > server er192.168.0.31:/pool/packages: not responding v > er 192.168.0.31ver :/po1ol/packages9: 2.168.0.31:/pool/packagesn: noot > responding t > <6>n fs serverespondinngf > s > server 192.168.1rn nfs server 192.168.0.31:/pool/packages: not1 responding > 9 > 2.168.1f7s 0.31:/pool/packagenfs sesrver 19serv2er .168.0.31:/poo: not > respolnding / > packages: not responding > nfs server 19192.168.0.31:/pool/pa2c.k168.0.31:a/gpserver > ne1s92.168.0.31:/pool/pac: knot respaof1s68 gs.e17rve8r.2 > 3192.168.0.31:/pool/packa1:/pool/packages: not responding o goes: nl/packages: > not responding o > t responding > nfs server 192.168.0.31:/poes: ol/packages: nfns server > 192.168.0.31:/pool/paot responding c > kages: not respondinnfs server n192.1f68.0.31:/pool/packagess: ndi server > 192.168.0.31:/pool/packages: not responding > [...] > > Earlier this year after introduction of IFLIB, I checked out servers equipted > with Intels very popular i350T2v2 NIC and I had similar problems when dd'ing > large files over NFSv4 (ZFS backed) from a client (em0, a client/consumer > grade > older NIC from 2010, forgot its ID, towards server with i350, but the server > side got stuck with the messages seen similar to those reported with the > i217-LM). Since my department uses lots of those server grade NICs, I will > swap > the i217 with a i350T2 and check again. > > Nevertheless, the situation is very uncomfortable! I'm able to reproduce this (watchdog timeouts followed by a link bounce, garbled dmesg) on my workstation by dd'ing to a file on an NFSv3 mount of a local file server. This is with: em0@pci0:0:25:0:class=0x02 card=0x102717aa chip=0x15028086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82579LM Gigabit Network Connection' class = network subclass = ethernet ___ 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: zfs recv panic
On 16 May 2017, at 19:58, Andriy Gapon wrote: On 16/05/2017 16:49, Kristof Provost wrote: On 16 May 2017, at 15:41, Andriy Gapon wrote: On 10/05/2017 12:37, Kristof Provost wrote: I have a reproducible panic on CURRENT (r318136) doing (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var For clarity, the receiving machine is CURRENT r318136, the sending machine is running a somewhat older CURRENT version. The receiving machine panics a few seconds in: receiving full stream of zroot/var@before-kernel-2017-04-03 into tank/jupiter/var@before-kernel-2017-04-03 panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) (0x0 == 0x1), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, line: 2007 could you please try to revert commits related to the compressed send and see if that helps? I assume that the sending machine does not have (does not use) the feature while the target machine is capable of the feature. The commits are: r317648 and r317414. Mot that I really suspect that change, but just to eliminate the possibility. Those commits appear to be the trigger. I’ve not changed the sender, but with those reverted I don’t see the panic any more. Thank you for testing. Do you still have the old kernel / module and the crash dump? It would interesting to poke around in frame 14. This contains the kernel and crash files: https://www.sigsegv.be/files/zfs_recv_kernel_crash.tar.bz2 I was running r318356 at the time of this panic. Regards, Kristof ___ 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 not working with MAKEOBJDIRPREFIX
On Tue, May 16, 2017 at 02:18:36PM +0200, O. Hartmann wrote: > On Tue, 16 May 2017 09:39:11 +0100 > Roger Pau Monné wrote: > > > Hello, > > > > I'm trying to build world as a regular user, using sources fetched into my > > home directory and a different object directory. The rune I'm using to build > > is: > > > > $ cd /home/royger/buildjob/freebsd > > $ make -j30 buildworld MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ > > As far as I know, in this construct, MAKEOBJDIRPREFIX is an argument to make, > but MAKEOBJDIRPREFIX is strictly required to be set in the environment! > > Have you tried the following setting: > > env MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ make -j30 buildworld > > I do this kind of task as root this way (as it doesn't work as you showed, > either). Hello, Yes, that's right, MAKEOBJDIRPREFIX is strictly required to be set in the environment, setting it fixes the issue. It always confuses me how some of those (like DESTDIR) can be passed as an arguments while others don't. Thanks, Roger. ___ 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: [Bug 218849] Remove rc.conf jail configuration via jail_* variables
Just commenting on past ideas of mine. *spend no time replying* . Thanks! ... inline comments below... sort of like 'overhear my typing into my bsd wish list nano-file.' and as such, scribble a not to thyself, not the list nor I, as I am out of time this [year] and # commenting not # coding an email ... On Tue, 16 May 2017 10:43:47 +, bugzilla-nore...@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 > > --- Comment #28 from Miroslav Lachman <000.f...@quip.cz> --- > (In reply to Jonathan Anderson from comment #27) > I think the opposite way. Or we end up with the same problems as with ezjail, > portupgrade, portmaster etc. now. I applaud each of those tools, as well as the extinct portmanager, and wish they be fully pkg compliant and/or the fallback for a resurrected /var/db/pkg plain-text version of .sqlite (s) for those urgent times [ once yearly for instance ] here where a newbie failure by inexperience and/or unresolved bug eclipses my day with a few hours of backup-worked-but-not-as-smoothly-as-I-thought successes... Some features in base are stalled or very > complicated just to not break 3rd party tools with no active maintainer. > "because they are in Handbook" I welcome a fully salaried handbook full time 'synchronizer', too advanced in years on my part, but yes I could pay yearly a share. > It would be better to document jails with base tools and just some list of 3rd > party tools with brief info about them and link to homepage of those projects. . off topic, snuck in: Some .htm,.php,.aspx, I save in .htm .txt manner a .htm[ or... ] for read-later, many of which .htm[etc] I save, vs xclip > disk , appear once loaded on disk as a jumble of text within interspersed /tags/ and /css/ stuff making it transcrible yes, but readable, no, so I give up and re-google the page I saved. If anyone has any best practice to educate me on a better save-to-disk-htm[php][aspx] method that is foolproof. comparatively, to reload from disk later [ for presentations, etc...] I may, if can, also paypal/snail mail a 'finders fee', if, say after a few months of usage I could frame it on the wall, actually, so I do not continue as I presently do, and feel of more use to others in pulling up saved files vs [ oh, I thought I could read that, it is 2/3 mime-glyphs... ] 'stuff that happens' to me and my sometimes guests. cc: the handbook guy, above, but that is in the distant future... so to speak. Or, add filler to an email. Sorry, or, continue as/until I de-procrastinate and 'send' to my understanding fellow list-readers [ tl/dr : see header, unfortunately top posted... we are looking over the shoulder at my nano file, that 'just this once, I promise' is publicly posted to the list so others can treat it as the off-topic it purports to be, comprises, asserts, mitigates itself as, and ... ] Have a very pleasant day, and I do not mean that with any insincerity. Thanks! . > > -- > You are receiving this mail because: > You are on the CC list for the bug. > ___ > 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: zfs recv panic
On 16/05/2017 16:49, Kristof Provost wrote: > On 16 May 2017, at 15:41, Andriy Gapon wrote: >> On 10/05/2017 12:37, Kristof Provost wrote: >>> I have a reproducible panic on CURRENT (r318136) doing >>> (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 >>> (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var >>> >>> For clarity, the receiving machine is CURRENT r318136, the sending machine >>> is >>> running a somewhat older CURRENT version. >>> >>> The receiving machine panics a few seconds in: >>> >>> receiving full stream of zroot/var@before-kernel-2017-04-03 into >>> tank/jupiter/var@before-kernel-2017-04-03 >>> panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) (0x0 == >>> 0x1), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, >>> line: 2007 >> >> could you please try to revert commits related to the compressed send and >> see if >> that helps? I assume that the sending machine does not have (does not use) >> the >> feature while the target machine is capable of the feature. >> >> The commits are: r317648 and r317414. Mot that I really suspect that change, >> but just to eliminate the possibility. > > Those commits appear to be the trigger. > I’ve not changed the sender, but with those reverted I don’t see the panic any > more. Thank you for testing. Do you still have the old kernel / module and the crash dump? It would interesting to poke around in frame 14. -- Andriy Gapon ___ 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: zfs recv panic
On 16 May 2017, at 15:41, Andriy Gapon wrote: On 10/05/2017 12:37, Kristof Provost wrote: I have a reproducible panic on CURRENT (r318136) doing (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var For clarity, the receiving machine is CURRENT r318136, the sending machine is running a somewhat older CURRENT version. The receiving machine panics a few seconds in: receiving full stream of zroot/var@before-kernel-2017-04-03 into tank/jupiter/var@before-kernel-2017-04-03 panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) (0x0 == 0x1), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, line: 2007 could you please try to revert commits related to the compressed send and see if that helps? I assume that the sending machine does not have (does not use) the feature while the target machine is capable of the feature. The commits are: r317648 and r317414. Mot that I really suspect that change, but just to eliminate the possibility. Those commits appear to be the trigger. I’ve not changed the sender, but with those reverted I don’t see the panic any more. Regards, Kristof ___ 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 not working with MAKEOBJDIRPREFIX
El día Tuesday, May 16, 2017 a las 02:18:36PM +0200, O. Hartmann escribió: > On Tue, 16 May 2017 09:39:11 +0100 > Roger Pau Monné wrote: > > > Hello, > > > > I'm trying to build world as a regular user, using sources fetched into my > > home directory and a different object directory. The rune I'm using to build > > is: > > > > $ cd /home/royger/buildjob/freebsd > > $ make -j30 buildworld MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ > > As far as I know, in this construct, MAKEOBJDIRPREFIX is an argument to make, > but MAKEOBJDIRPREFIX is strictly required to be set in the environment! I used it many times that way, as well # make installworld DESTDIR=/mnt This should work. Can you try with a smaller -j value? matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/ccid--export-key-guru.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdió la Guerra. May 8, 1945: Who does not celebrate lost the War. ___ 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 not working with MAKEOBJDIRPREFIX
On Tue, 16 May 2017 09:39:11 +0100 Roger Pau Monné wrote: > Hello, > > I'm trying to build world as a regular user, using sources fetched into my > home directory and a different object directory. The rune I'm using to build > is: > > $ cd /home/royger/buildjob/freebsd > $ make -j30 buildworld MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ As far as I know, in this construct, MAKEOBJDIRPREFIX is an argument to make, but MAKEOBJDIRPREFIX is strictly required to be set in the environment! Have you tried the following setting: env MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ make -j30 buildworld I do this kind of task as root this way (as it doesn't work as you showed, either). Kind regards, Oliver > > And this leads to the following build error: > > --- all_subdir_rescue --- > --- cat.lo --- > cc -target x86_64-unknown-freebsd12.0 > --sysroot=/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/tmp > -B/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/tmp/usr/bin -O2 > -pipe -std=gnu99-Qunused-arguments -nostdlib -Wl,-dc -r -o cat.lo > cat_stub.o > /home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/rescue/rescue//usr/home/royger/buildjob/freebsd/bin/cat/cat.o > cc: error: no such file or directory: > '/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/rescue/rescue//usr/home/royger/buildjob/freebsd/bin/cat/cat.o' > *** [cat.lo] Error code 1 > > AFAIK this should work fine, does anyone has any clues about what causes this > failure? > > Thanks, Roger. > > ___ > 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #28 from Miroslav Lachman <000.f...@quip.cz> --- (In reply to Jonathan Anderson from comment #27) I think the opposite way. Or we end up with the same problems as with ezjail, portupgrade, portmaster etc. now. Some features in base are stalled or very complicated just to not break 3rd party tools with no active maintainer. "because they are in Handbook" It would be better to document jails with base tools and just some list of 3rd party tools with brief info about them and link to homepage of those projects. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: build src with colored output?
On 16 May 2017, at 07:42, Johannes Lundberg wrote: > > Gonna answer myself here. Think I found a way. > > Add CFLAGS=-fcolor-diagnostics to env or /etc/src.conf > Do clean build, that is no -DNO_CLEAN,KERNFAST, etc. > > Makes it a lot easier to find the errors in a 16 threads build output... > > The mystery still remains though, why is color disabled for parallel > builds? It’s disabled for two reasons. The first is aesthetic - some people don’t like coloured output. I’m not going to debate that one. The other is technical. Unlike modern build tools, such as Ninja, bmake’s handling of multithreaded output is very bad. It simply allows each task the same output device, whereas ninja gives each parallel job a pipe back to the build process and then merges the output itself. This means that you periodically encounter the case where one child process has sent a colour escape sequence to the output and then another process sends the next line, giving weird visual effects and reducing the utility of colour outputs. Ideally, we’d solve this by fixing bmake to behave more like a modern build tool and: - Giving each sub-process its own pipe. - Emitting the full compile command for all failed tasks. - Displaying only a summary for successful commands Or we could find someone with the time to spend giving FreeBSD a modern build system, which would probably save us 1-2 man years of developer time each year overall. David ___ 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: zfs recv panic
On 10/05/2017 12:37, Kristof Provost wrote: > Hi, > > I have a reproducible panic on CURRENT (r318136) doing > (jupiter) # zfs send -R -v zroot/var@before-kernel-2017-04-26 | nc dual 1234 > (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var > > For clarity, the receiving machine is CURRENT r318136, the sending machine is > running a somewhat older CURRENT version. > > The receiving machine panics a few seconds in: > > receiving full stream of zroot/var@before-kernel-2017-04-03 into > tank/jupiter/var@before-kernel-2017-04-03 > panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) (0x0 == > 0x1), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c, > line: 2007 Kristof, could you please try to revert commits related to the compressed send and see if that helps? I assume that the sending machine does not have (does not use) the feature while the target machine is capable of the feature. The commits are: r317648 and r317414. Mot that I really suspect that change, but just to eliminate the possibility. Thank you. > cpuid = 0 > time = 1494408122 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120cad930 > vpanic() at vpanic+0x19c/frame 0xfe0120cad9b0 > panic() at panic+0x43/frame 0xfe0120cada10 > assfail3() at assfail3+0x2c/frame 0xfe0120cada30 > dbuf_assign_arcbuf() at dbuf_assign_arcbuf+0xf2/frame 0xfe0120cada80 > dmu_assign_arcbuf() at dmu_assign_arcbuf+0x170/frame 0xfe0120cadad0 > receive_writer_thread() at receive_writer_thread+0x6ac/frame > 0xfe0120cadb70 > fork_exit() at fork_exit+0x84/frame 0xfe0120cadbb0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0120cadbb0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 7 tid 100672 ] > Stopped at kdb_enter+0x3b: movq$0,kdb_why > db> > > > kgdb backtrace: > #0 doadump (textdump=0) at pcpu.h:232 > #1 0x803a208b in db_dump (dummy=, dummy2= optimized out>, dummy3=, dummy4=) at > /usr/src/sys/ddb/db_command.c:546 > #2 0x803a1e7f in db_command (cmd_table=) at > /usr/src/sys/ddb/db_command.c:453 > #3 0x803a1bb4 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:506 > #4 0x803a4c7f in db_trap (type=, code= optimized out>) at /usr/src/sys/ddb/db_main.c:248 > #5 0x80a93cb3 in kdb_trap (type=3, code=-61456, tf= out>) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0x80ed3de6 in trap (frame=0xfe0120cad860) at > /usr/src/sys/amd64/amd64/trap.c:537 > #7 0x80eb62f1 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #8 0x80a933eb in kdb_enter (why=0x8143d8f5 "panic", > msg= optimized out>) at cpufunc.h:63 > #9 0x80a51cf9 in vpanic (fmt=, > ap=0xfe0120cad9f0) at /usr/src/sys/kern/kern_shutdown.c:772 > #10 0x80a51d63 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:710 > #11 0x8262b26c in assfail3 (a=, lv= optimized > out>, op=, rv=, f= out>, l=) > at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 > #12 0x822ad892 in dbuf_assign_arcbuf (db=0xf8008f23e560, > buf=0xf8008f09fcc0, tx=0xf8008a8d5200) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:2007 > #13 0x822b87f0 in dmu_assign_arcbuf (handle=, > offset=0, buf=0xf8008f09fcc0, tx=0xf8008a8d5200) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:1542 > #14 0x822bf7fc in receive_writer_thread (arg=0xfe0120a1d168) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:2284 > #15 0x80a13704 in fork_exit (callout=0x822bf150 > , arg=0xfe0120a1d168, frame=0xfe0120cadbc0) at > /usr/src/sys/kern/kern_fork.c:1038 > #16 0x80eb682e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:611 > #17 0x in ?? () > > Let me know if there’s any other information I can provide, or things I can > test. > Fortunately the target machine is not a production machine, so I can panic it > as > often as required. -- Andriy Gapon ___ 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"
buildworld not working with MAKEOBJDIRPREFIX
Hello, I'm trying to build world as a regular user, using sources fetched into my home directory and a different object directory. The rune I'm using to build is: $ cd /home/royger/buildjob/freebsd $ make -j30 buildworld MAKEOBJDIRPREFIX=/home/royger/buildjob/obj/ And this leads to the following build error: --- all_subdir_rescue --- --- cat.lo --- cc -target x86_64-unknown-freebsd12.0 --sysroot=/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/tmp -B/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/tmp/usr/bin -O2 -pipe -std=gnu99-Qunused-arguments -nostdlib -Wl,-dc -r -o cat.lo cat_stub.o /home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/rescue/rescue//usr/home/royger/buildjob/freebsd/bin/cat/cat.o cc: error: no such file or directory: '/home/royger/buildjob/obj//usr/home/royger/buildjob/freebsd/rescue/rescue//usr/home/royger/buildjob/freebsd/bin/cat/cat.o' *** [cat.lo] Error code 1 AFAIK this should work fine, does anyone has any clues about what causes this failure? Thanks, Roger. ___ 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"
