Re: Bug in make setting wrong MAKESYSPATH
>From Simon J. Gerraty: >> Bug occurs when building or configuring ports, syntax error in >> /BETA1/usr/share/mk/bsd.compiler.mk line 52 >This is of course specific to your particular arrangement >if you'd mounted /BETA1/usr/ports on /usr/ports, it would function as >you wish, or if /BETA1/usr/share/mk happend to match /usr/share/mk >it would work fine. >So, anoying in this case, but not a bug. >> I don't know about other situations such as building doc. >> I could avoid this error either by setting (setenv or export, depending on >> shell) MAKESYSPATH or >> by null-mounting /BETA1/usr/ports at /usr/ports . >Yes. Just because I found a workaround does not mean it is not a bug. If I were setting up a computer or hard disk from the beginning, I would put ports tree, src tree(s) and doc trees on a separate partition with no FreeBSD installation. NetBSD pkgsrc and src trees could be installed on same or another partition. That would facilitate backing up the entire installation (FreeBSD or NetBSD) without backing up the src and other trees, which could be redownloaded by cvs, svn or git, as the case might be. I guess then I would need to set MAKESYSPATH in FreeBSD ports, or null-mount PORTSDIR at /usr/ports. If you look at github.com/FreeBSD, you see some modified ports trees that might be installed at, for instance /freebsd-ports-graphics Tom ___ 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"
Another INO64 Disaster
I did not following the upgrade instructions to the letter and 'blew up' my FreeBSD laptop. Having made a recent backup of all of my important files, I decided that performing a reinstall would be easier than repairing my system. I downloaded the r318945 snapshot and performed a clean install on a Compaq Presario F500 laptop. After the first boot, I tried to install the pkg system. The first fault said that the libarchive.so.6 was missing. I symlinked it to the installed libarchive.so.7 and installed the necessary files for pkg. I tried a pkg install of bash and the files installed in /usr/local/bin had "REAL" strange permissions and dates. The dates were all December 1969 and before the Unix epoch date of January 1970. Something is wrong with INO64 on a recent snapshot! Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: Another INO64 Disaster
On 27 May 2017 at 12:25, Thomas Laus wrote: > After the > first boot, I tried to install the pkg system. The first fault said > that the libarchive.so.6 was missing. Yes, the most recent package set available is built against a pre-ino64 world and depends on older versions of libraries (like libarchive) than those provided in an ino64 image. In-place upgrades will work because existing binaries still use the old, not-deleted libraries, but existing packages won't work against a fresh ino64 install. You can wait until the next package build (against ino64 world) is complete, or build your own packages from the ports tree or via Poudriere. ___ 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: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)
I wrote: >To briefly summarize the previous post related to perf. degradation when >running a >recent kernel... >- kernel build running 1yr old kernel took 100minutes >- same kernel build running recent kernel 148minutes >(ie. Almost a 50% degradation.) >As noted in the last post, I got rid of most of the degradation by disabling >SMP. > >- same kernel build running recent kernel with SCHED_4BSD 104minutes > After poking at this some more, it appears that r312426 is the main cause of this degradation. Doing SMP enabled test runs using SCHED_ULE running the recent kernel, I got: - recent kernel (as above)148minutes - with r312426 reverted122minutes - with the "obvious change" mentioned in r312426's commit message, using (flags & SW_TYPE_MASK) == SWT_RELINQUISH instead of (flag & SWT_RELINQUISH) 121minutes So, I'd say either reverting the patch or replacing it with the "obvious change" mentioned in the commit message will at least mostly fix the problem. I actually suspect that setting "preempt" for SWT_IDLE and/or SWT_IWAIT is what is needed to be the pre-r312426 performance, since those are the ones that SWT_RELINQUISH doesn't match. (There is also SWT_PREEMPT, but that was handled by the r312426 patch.) I also tested: ((flags & SW_PREEMPT) != 0 || (flags & SW_TYPE_MASK) == SWT_IDLE || (flags & SW_TYPE_MASK) == SWT_IWAIT) and it also resulted in121minutes I still get better perf. from SCHED_4BSD of 104minutes, but I usually see better performance for SCHED_4BSD, so I think this is expected. I know nothing about SCHED_ULE, so I don't think I can do more, unless someone wants me to try a different patch? rick ___ 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"
