Kernel Panic sys/netinet/tcp_subr.c 2386
Hi, I just got a kernel panic on my 15.0-CURRENT machine, with an Assertion in sys/netinet/tcp_subr.c 2386 full log: https://people.freebsd.org/~wosch/tmp/kernel-panic-tcp_subr-line-2386.png OS: 15.0-CURRENT main-3e9515846f (10-Feb-2024, github.com/freebsd/freebsd-src) Should I worry? -Wolfram -- Wolfram Schneider https://wolfram.schneider.org
Re: Move the Handbook into source tree
We have 3 main repos: src, ports and doc. There are good reasons why we are doing this, and it will not change in the near future. For further questions and details, please ask on the freebsd-docs mailing list. You are right that the documentation on our web site is mostly for -current, the state of the art of the code base. If you need the documentation for our supported releases please check our Documentation Archive at https://docs.freebsd.org/doc/ and select your favourite release, e.g. the handbook for FreeBSD 13.0 https://docs.freebsd.org/doc/13.0-RELEASE/usr/local/share/doc/freebsd/en/books/handbook/ the handbook for FreeBSD 12.0 https://docs.freebsd.org/doc/12.0-RELEASE/usr/local/share/doc/freebsd/en/books/handbook/ -Wolfram On Tue, 7 Sept 2021 at 09:03, Mehmet Erol Sanliturk wrote: > > Dear All , > > in many of my messages to FreeBSD mailing lists I am mentioning the > following view : > > "Please move the Handbook into source tree , and >Maintain it with respect to current release without mixing sliding > releases : If you do this , >maintenance of a correct Handbook is IMPOSSIBLE because maintenance of >associated IF statements about releases . > " > > When we look at the following web pages , we see the following : > > https://www.freebsd.org/cgi/man.cgi > FreeBSD Manual Pages > > In the second box of "All sections" line , there are lines about all of > the FreeBSD releases > with many more other systems . > > In spite of this , in the following page : > > https://docs.freebsd.org/en/books/handbook/ > FreeBSD Handbook > The FreeBSD Documentation Project > > > " > Abstract > > Welcome to FreeBSD! This handbook covers the installation and day to day > use of > FreeBSD 13.0-RELEASE, FreeBSD 12.2-RELEASE and FreeBSD 11.4-RELEASE. ... > " > > A Handbook which ( for me , exactly , for the others , perhaps ) with many > errors ... > > > I think that , it is NOT extraordinarily a difficult process to move the > Handbook into source > tree and maintaining it with respect to per release and insert into the > above web page a part > similar to the manual pages to display the requested Handbook with respect > to releases . > In the present case , previous handbooks are lost , because of the > difficulty of finding them . > > Thank you very much and my best wishes for you and humanity in these > pandemic days ... > > > Mehmet Erol Sanliturk -- Wolfram Schneider https://wolfram.schneider.org
Re: -CURRENT compilation time
On Mon, 6 Sept 2021 at 11:44, David Chisnall wrote: > > On 06/09/2021 09:08, Jeremie Le Hen wrote: > > Compiling C++ seems > > extremely CPU heavy and this is made worse by the fact LLVM is built > > twice (once for build/cross tools, once for the actual world). > > Note that you need to build LLVM twice only if you are actively > debugging LLVM reproduceable deployment images. You actually don't need > to build it at all, you can use an external toolchain to skip the first > build and you can compile WITHOUT_TOOLCHAIN to avoid building the > version that's installed and then install a toolchain from packages: > > https://wiki.freebsd.org/ExternalToolchain I did a test on a 16 core (32 VCPU) machine (Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz). With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5 times faster (real or user+sys), down from 48 min to 19.5 min real time. time make -j16 buildworld -- >>> World build completed on Mon Sep 6 12:00:45 UTC 2021 >>> World built in 2862 seconds, ncpu: 32, make -j16 -- 2862.04 real 41234.87 user 1582.66 sys time make -j16 WITHOUT_TOOLCHAIN=yes buildworld -- >>> World build completed on Mon Sep 6 11:32:41 UTC 2021 >>> World built in 1181 seconds, ncpu: 32, make -j16 ---------- 1180.73 real 16076.27 user 988.73 sys -Wolfram -- Wolfram Schneider https://wolfram.schneider.org
Re: -CURRENT compilation time
On Mon, 6 Sept 2021 at 10:10, Jeremie Le Hen wrote: > > Hey, > > I want to build -CURRENT again from sources. It's been a long time > since I hadn't done that. I'm shocked by the compilation time. > > I started the whole thing on Friday night and Monday morning it's > still in stage 4.2 (building libraries). Through occasional glancing > at the screen over the weekend, it seems obvious to me that the > compilation time is utterly dominated by LLVM. Compiling C++ seems > extremely CPU heavy and this is made worse by the fact LLVM is built > twice (once for build/cross tools, once for the actual world). > > So OK, my CPU is not the most powerful out there but it's still decent [1]. > > So I have a couple of questions coming to my mind: > 1. Is there any optimization I could benefit from? (I'm sure there's a > knob to use the existing compiler instead of building a > cross-compiler.) > 2. More generally, isn't this compilation time not considered as a > problem for developers? This seems to terribly slow down the iteration > time for people working on the build system. I wouldn't be surprised > if this drove people away from working on/improving that area. > > [1] > https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6260U+%40+1.80GHz=2671 Hi, I ran buildworld yesterday on a 3 CPU VM (AMD EPYC 2.4GHz) and the runtime was 2h. We spent most of the time in "stage 4.2: building libraries", in my case 62% of the CPU time and 75% of the real time. I guess the build time on your laptop should be around 6 hours if everything is ok. time make -j $(sysctl -n hw.ncpu) buildworld > log.buildworld 2>&1 tail -n 5 log.buildworld -- >>> World build completed on Sat Sep 4 20:58:00 UTC 2021 >>> World built in 7235 seconds, ncpu: 3, make -j3 -- 7235.61 real 20527.30 user 915.88 sys egrep '>>> stage| real ' log.buildworld >>> stage 1.1: legacy release compatibility shims 0.28 real 0.18 user 0.10 sys >>> stage 1.2: bootstrap tools 165.99 real 472.58 user11.56 sys >>> stage 2.1: cleaning up the object tree 21.47 real36.96 user14.14 sys 15.87 real29.14 user11.87 sys >>> stage 2.3: build tools 2.42 real 3.79 user 0.62 sys >>> stage 3: cross tools 9.92 real18.49 user 1.75 sys >>> stage 3.1: recording build metadata 0.07 real 0.01 user 0.06 sys >>> stage 4.1: building includes 16.62 real36.46 user 9.48 sys >>> stage 4.2: building libraries 5440.89 real 15724.60 user 482.58 sys >>> stage 4.3: building lib32 shim libraries 615.91 real 1654.77 user 164.58 sys >>> stage 4.4: building everything 937.23 real 2540.06 user 205.47 sys -Wolfram -- Wolfram Schneider https://wolfram.schneider.org
Re: git: 99feb137f5f6 - main - `make buildworld' with time logging for each stage
Hi David,
Thanks for the investigation. I will prepare a fix soon.
BTW, should we care about the error message
"sh: pkg: not found" ?
-Wolfram
On Sun, 1 Aug 2021 at 14:26, David Wolfskill wrote:
>
> I believe that src/Makefile.inc1 needs a tweak to add "time" to the list
> of "Required install tools to be saved in a scratch dir for safety" --
> something like:
>
> diff --git a/Makefile.inc1 b/Makefile.inc1
> index 3d54a088d070..213b32a97ed3 100644
> --- a/Makefile.inc1
> +++ b/Makefile.inc1
> @@ -1300,7 +1300,7 @@ _sysctl=sysctl
> ITOOLS=[ awk cap_mkdb cat chflags chmod chown cmp cp \
> date echo egrep find grep id install ${_install-info} \
> ln make mkdir mtree mv pwd_mkdb \
> - rm sed services_mkdb sh sort strip ${_sysctl} test true uname wc \
> + rm sed services_mkdb sh sort strip ${_sysctl} test time true uname wc
> \
> ${_zoneinfo} ${LOCAL_ITOOLS}
>
> # Needed for share/man
>
>
> Because when I tried to update from main-n248391-f7f76c200a8c to
> main-n248404-60fb9e10c74c, I saw:
>
> ...
> ===> etc (install)
> ===> etc/sendmail (install)
> cd /usr/src/share/man; make makedb
> makewhatis /usr/share/man
> makewhatis /usr/share/openssl/man
> cd /usr/src; make -f Makefile.inc1 install32
> sh: pkg: not found
> cd /usr/src/lib; time env MACHINE_CPU="i686 mmx sse sse2" MACHINE=i386
> MACHINE_ARCH=i386
> PATH=/common/S4/obj/usr/src/amd64.amd64/tmp/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/usr/sbin:/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/common/S4/obj/usr/src/amd64.amd64/tmp/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/usr/sbin:/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/bin:/common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/tmp/install.Z8rMzNyp
> SYSROOT=/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp LIBDIR=/usr/lib32
> SHLIBDIR=/usr/lib32 DTRACE="dtrace" make AS="as --32" LD="ld -m
> elf_i386_fbsd" NM="nm" OBJCOPY="objcopy" -DCOMPAT_32BIT CC="cc -target
> x86_64-unknown-freebsd14.0 --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp
> -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -DCOMPAT_32BIT -march=i686
> -mmmx -msse -msse2 -target x86_64-unknown-freebsd14.0 -m32
> --sysroot=/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp
> -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin
> -B/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32" CXX="c++
> -target x86_64-unknown-freebsd14.0
> --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp
> -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -DCOMPAT_32BIT -march=i686
> -mmmx -msse -msse2 -target x86_64-unknown-freebsd14.0 -m32
> --sysroot=/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp
> -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin
> -B/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32" CPP="cpp
> -target x86_64-unknown-freebsd14.0
> --sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp
> -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin -DCOMPAT_32BIT -march=i686
> -mmmx -msse -msse2 -target x86_64-unknown-freebsd14.0 -m32
> --sysroot=/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp
> -B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin
> -B/common/S4/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/lib32" -DNO_CPU_CFLAGS
> MK_CTF=no -DNO_LINT MK_TESTS=no
> OBJTOP=/common/S4/obj/usr/src/amd64.amd64/obj-lib32 OBJROOT='${OBJTOP}/'
> MAKEOBJDIRPREFIX= MK_MAN=no MK_HTML=no-DLIBRARIES_ONLY install
> /tmp/install.Z8rMzNyp/sh: time: not found
> *** Error code 127
>
> Stop.
> make[3]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/src
> 149.85 real65.62 user35.05 sys
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
> Command exit status: 1
> Script done on Sun Aug 1 05:17:29 2021
>
>
> Making the above change, then re-running the "make installworld" has worked.
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> Life is not intended to be a zero-sum game.
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
--
Wolfram Schneider https://wolfram.schneider.org
partitioning schemes: GPT <-> MBR
Hi guys, I have 2 small virtual machines running in data center, on similar hardware. Both are running FreeBSD 12-current. The first one is based on a 10.3 image, upgraded to current. The second one is based on 11.1, upgraded to current. I notice a difference in disk partitioning. 10.3 is using GPT, and 11.1 MBR. [FreeBSD 10.3] $ gpart show => 34 83886013 vtbd0 GPT (40G) 34 1024 1 freebsd-boot (512K) 1058 2097152 2 freebsd-swap (1.0G) 2098210 81787836 3 freebsd-ufs (39G) 83886046 1 - free - (512B) [FreeBSD 11.1] $ gpart show => 63 83886017 vtbd0 MBR (40G) 63 1 - free - (512B) 64 79691776 1 freebsd [active] (38G) 79691840 4194240 - free - (2.0G) I thought that MBR is outdated. But the hosting company told me that FreeBSD 11.1 is using MBR by default. Is that correct? My problem with the MBR machine is that I cannot add a swap device. There are 2GB free space, and I want add a 1GB swap device: $ gpart add -s 1G -t freebsd-swap vtbd0 gpart: Invalid argument is this an MBR issue? thanks, Wolfram -- Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.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: /usr/obj is 11GB huge on FreeBSD 12-current
On 15 December 2017 at 20:20, Wolfram Schneider <wo...@freebsd.org> wrote: > On 15 December 2017 at 19:39, Konstantin Belousov <kostik...@gmail.com> wrote: >> On Fri, Dec 15, 2017 at 06:38:48PM +0100, Wolfram Schneider wrote: >>> On 15 December 2017 at 17:51, Wolfram Schneider <wo...@freebsd.org> wrote: >>> > On 15 December 2017 at 13:02, David Wolfskill <da...@catwhisker.org> >>> > wrote: >>> >> On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >>> >>> Hi, >>> >>> >>> >>> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >>> >>> is now 11GB huge: >>> >>> >>> >>> FreeBSD 12-current >>> >>> $ du -hs /usr/obj >>> >>> 11G /usr/obj >>> >>> >>> >>> on FreeBSD 11-stable it was less the size: >>> >>> $ du -hs /usr/obj >>> >>> 5.6G /usr/obj >>> >>> >>> >>> this is a problem when you have a small VM with 20GB disk space or less. >>> >>> >>> >>> Is there a way to use less /usr/obj disk space during build? I know >>> >>> that we have to do some bootstrapping for newer compiler tools, but >>> >>> does we need to keep all temp files during the build? >>> >> >>> >> There was a change near the beginning of November; please see UPDATING >>> >> entry 20171101 -- you probably have several no-longer-used >>> >> subdirectories under /usr/obj/usr/src/. >>> >> >>> >> Once those are cleared out, my experience (tracking stable/11 & head in >>> >> different slices on the same machines) is that stbale/11 is using about >>> >> 5.0G, while head uses about 6.1G. >>> > >>> > I think the suspect directories are "tmp" and "obj-lib32", together >>> > they are 4.1GB huge. >>> > >>> > I will run a build of current again with a clean obj tree (-current on >>> > a recent -current). Let's see. >>> >>> I run a test on universe12b (FreeBSD 12.0-CURRENT #0 r325426: Sun Nov >>> 5) with an empty obj directory. >>> >>> `make buildworld' creates 9.7GB of obj data. After running `make >>> buildkernel' it will grow to 12GB. This is on a ZFS filesystem (my >>> original report was on UFS) >> >> Most likely reason of the bump is generation of debugging data, turned on >> for 12. Another not usable thing to disable are tests and profile libraries. >> Put the following into /etc/src.conf: >> WITHOUT_PROFILE=yes >> WITHOUT_DEBUG_FILES=yes >> WITHOUT_TESTS=yes > > Hi Konstantin, > > I tried these 3 variables and the results looks much better, down to > 5.1GB from 12GB. Many thanks! > > $ du -hs obj* > 12G obj-debug > 5.1G obj-nodebug I did another test which of the WITHOUT_* variables saves most of the space 5.5G obj-WITHOUT_DEBUG_FILES (6.5GB less) 10G obj-WITHOUT_LIB32 (2GB less) 11G obj-WITHOUT_PROFILE (1GB less) 12G obj-WITHOUT_TESTS if you are short on disk space (e.g. a small VM with SSD drive), you should compile with $ export WITHOUT_DEBUG_FILES=YES; make buildworld -Wolfram -- Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.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: /usr/obj is 11GB huge on FreeBSD 12-current
On 15 December 2017 at 20:41, Larry Rosenman <l...@lerctr.org> wrote: > On 12/15/17, 1:28 PM, "owner-freebsd-curr...@freebsd.org" > <owner-freebsd-curr...@freebsd.org> wrote: > > > Wolfram Schneider writes: > > > I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > > is now 11GB huge: > > > > FreeBSD 12-current > > $ du -hs /usr/obj > > 11G /usr/obj > > > > on FreeBSD 11-stable it was less the size: > > $ du -hs /usr/obj > > 5.6G /usr/obj > > Mine - also 12-current - reports 7.6G. > May we see your kernel config file, src.conf, and make.conf? I'm running a fresh installed FreeBSD without modifications. There is no src.conf or make.conf on the machine. -Wolfram -- Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.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: /usr/obj is 11GB huge on FreeBSD 12-current
On 15 December 2017 at 19:39, Konstantin Belousov <kostik...@gmail.com> wrote: > On Fri, Dec 15, 2017 at 06:38:48PM +0100, Wolfram Schneider wrote: >> On 15 December 2017 at 17:51, Wolfram Schneider <wo...@freebsd.org> wrote: >> > On 15 December 2017 at 13:02, David Wolfskill <da...@catwhisker.org> wrote: >> >> On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >> >>> Hi, >> >>> >> >>> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >> >>> is now 11GB huge: >> >>> >> >>> FreeBSD 12-current >> >>> $ du -hs /usr/obj >> >>> 11G /usr/obj >> >>> >> >>> on FreeBSD 11-stable it was less the size: >> >>> $ du -hs /usr/obj >> >>> 5.6G /usr/obj >> >>> >> >>> this is a problem when you have a small VM with 20GB disk space or less. >> >>> >> >>> Is there a way to use less /usr/obj disk space during build? I know >> >>> that we have to do some bootstrapping for newer compiler tools, but >> >>> does we need to keep all temp files during the build? >> >> >> >> There was a change near the beginning of November; please see UPDATING >> >> entry 20171101 -- you probably have several no-longer-used >> >> subdirectories under /usr/obj/usr/src/. >> >> >> >> Once those are cleared out, my experience (tracking stable/11 & head in >> >> different slices on the same machines) is that stbale/11 is using about >> >> 5.0G, while head uses about 6.1G. >> > >> > I think the suspect directories are "tmp" and "obj-lib32", together >> > they are 4.1GB huge. >> > >> > I will run a build of current again with a clean obj tree (-current on >> > a recent -current). Let's see. >> >> I run a test on universe12b (FreeBSD 12.0-CURRENT #0 r325426: Sun Nov >> 5) with an empty obj directory. >> >> `make buildworld' creates 9.7GB of obj data. After running `make >> buildkernel' it will grow to 12GB. This is on a ZFS filesystem (my >> original report was on UFS) > > Most likely reason of the bump is generation of debugging data, turned on > for 12. Another not usable thing to disable are tests and profile libraries. > Put the following into /etc/src.conf: > WITHOUT_PROFILE=yes > WITHOUT_DEBUG_FILES=yes > WITHOUT_TESTS=yes Hi Konstantin, I tried these 3 variables and the results looks much better, down to 5.1GB from 12GB. Many thanks! $ du -hs obj* 12G obj-debug 5.1G obj-nodebug -Wolfram -- Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.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: /usr/obj is 11GB huge on FreeBSD 12-current
On 15 December 2017 at 17:51, Wolfram Schneider <wo...@freebsd.org> wrote: > On 15 December 2017 at 13:02, David Wolfskill <da...@catwhisker.org> wrote: >> On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >>> Hi, >>> >>> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >>> is now 11GB huge: >>> >>> FreeBSD 12-current >>> $ du -hs /usr/obj >>> 11G /usr/obj >>> >>> on FreeBSD 11-stable it was less the size: >>> $ du -hs /usr/obj >>> 5.6G /usr/obj >>> >>> this is a problem when you have a small VM with 20GB disk space or less. >>> >>> Is there a way to use less /usr/obj disk space during build? I know >>> that we have to do some bootstrapping for newer compiler tools, but >>> does we need to keep all temp files during the build? >> >> There was a change near the beginning of November; please see UPDATING >> entry 20171101 -- you probably have several no-longer-used >> subdirectories under /usr/obj/usr/src/. >> >> Once those are cleared out, my experience (tracking stable/11 & head in >> different slices on the same machines) is that stbale/11 is using about >> 5.0G, while head uses about 6.1G. > > I think the suspect directories are "tmp" and "obj-lib32", together > they are 4.1GB huge. > > I will run a build of current again with a clean obj tree (-current on > a recent -current). Let's see. I run a test on universe12b (FreeBSD 12.0-CURRENT #0 r325426: Sun Nov 5) with an empty obj directory. `make buildworld' creates 9.7GB of obj data. After running `make buildkernel' it will grow to 12GB. This is on a ZFS filesystem (my original report was on UFS) -Wolfram > Can we agree that the obj tree should not grow from 5GB to 10GB for > the next release? > > -Wolfram > > -- > Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.org -- Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.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: /usr/obj is 11GB huge on FreeBSD 12-current
On 15 December 2017 at 13:02, David Wolfskill <da...@catwhisker.org> wrote: > On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >> Hi, >> >> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >> is now 11GB huge: >> >> FreeBSD 12-current >> $ du -hs /usr/obj >> 11G /usr/obj >> >> on FreeBSD 11-stable it was less the size: >> $ du -hs /usr/obj >> 5.6G /usr/obj >> >> this is a problem when you have a small VM with 20GB disk space or less. >> >> Is there a way to use less /usr/obj disk space during build? I know >> that we have to do some bootstrapping for newer compiler tools, but >> does we need to keep all temp files during the build? > > There was a change near the beginning of November; please see UPDATING > entry 20171101 -- you probably have several no-longer-used > subdirectories under /usr/obj/usr/src/. > > Once those are cleared out, my experience (tracking stable/11 & head in > different slices on the same machines) is that stbale/11 is using about > 5.0G, while head uses about 6.1G. I think the suspect directories are "tmp" and "obj-lib32", together they are 4.1GB huge. I will run a build of current again with a clean obj tree (-current on a recent -current). Let's see. Can we agree that the obj tree should not grow from 5GB to 10GB for the next release? -Wolfram -- Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.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"
/usr/obj is 11GB huge on FreeBSD 12-current
Hi, I upgraded a machine from 11-stable to 12-current. The /usr/obj tree is now 11GB huge: FreeBSD 12-current $ du -hs /usr/obj 11G /usr/obj on FreeBSD 11-stable it was less the size: $ du -hs /usr/obj 5.6G /usr/obj this is a problem when you have a small VM with 20GB disk space or less. Is there a way to use less /usr/obj disk space during build? I know that we have to do some bootstrapping for newer compiler tools, but does we need to keep all temp files during the build? # FreeBSD 12-current $ du -ks * | sort -n 4 compiler-metadata.mk 4 host-osreldate.h 112 etc 216 include 9972 tests 15324 libexec 17188 bin 34964 stand 57424 rescue 65280 share 80312 sbin 118616 cddl 146792 kerberos5 175244 secure 192340 gnu 251784 usr.sbin 1269916 obj-lib32 1737908 usr.bin 1863716 sys 2528160 lib 2892776 tmp # FreeBSD 11-stable $ du -ks * |sort -n 4 compiler-metadata.mk 116 etc 216 include 8860 tests 14212 libexec 16260 bin 36276 rescue 63300 sbin 67224 share 85268 cddl 86868 kerberos5 107672 gnu 110360 secure 172352 lib32 00 usr.sbin 518908 world32 668756 tmp 979040 lib 989640 usr.bin 1721096 sys -Wolfram -- Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.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: kernel panic: make_dev_alias_v bad si_name (error=22) si_name=vtcon/ org.qemu.guest_agent.0)
On 15 November 2017 at 10:58, Conrad Meyer <c...@freebsd.org> wrote: > Hi Wolfram, > > Looks like the same issue as > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223531 . Hi Conrad, thanks for the hint. Do you know which commit may broke the driver? Is there any patch or workaround? I do not have access to the physical machine, only full root access to the guest. I don't want to bother with the cloud provider, I'm happy that they offer FreeBSD at all as a default installation. -Wolfram > Best, > Conrad > > On Wed, Nov 15, 2017 at 1:31 AM, Wolfram Schneider <wo...@freebsd.org> wrote: >> Hi, >> >> I have a virtual machine running with FreeBSD 11-stable at a cloud >> provider. It runs fine. I tried to upgrade to FreeBSD 12-current and >> the kernel panics at boot time with: >> >> make_dev_alias_v bad si_name (error=22) si_name=vtcon/ >> org.qemu.guest_agent.0) >> >> and hangs. Lucky, I still can boot from kernel.old and bring the machine up. >> >> any idea whats wrong here? >> >> -Wolfram -- Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.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"
kernel panic: make_dev_alias_v bad si_name (error=22) si_name=vtcon/ org.qemu.guest_agent.0)
Hi, I have a virtual machine running with FreeBSD 11-stable at a cloud provider. It runs fine. I tried to upgrade to FreeBSD 12-current and the kernel panics at boot time with: make_dev_alias_v bad si_name (error=22) si_name=vtcon/ org.qemu.guest_agent.0) and hangs. Lucky, I still can boot from kernel.old and bring the machine up. any idea whats wrong here? -Wolfram -- Wolfram Schneider <wo...@freebsd.org> https://wolfram.schneider.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"
[FreeBSD manual pages for mlockall(2)]
Hi Jukka, I forwarded your mail to freebsd-current. It looks like someone forgot to add the mlockall(2) manpages. The prototype is defined in /usr/include/sys/mman.h (http://cvsweb.freebsd.org/src/sys/sys/mman.h ) -Wolfram - Forwarded message from Jukka A. Ukkonen [EMAIL PROTECTED] - Date: Wed, 24 Jul 2002 17:36:09 +0300 From: Jukka A. Ukkonen [EMAIL PROTECTED] Organization: Mawit Ltd. X-Accept-Language: en To: [EMAIL PROTECTED] Subject: FreeBSD manual pages X-OriginalArrivalTime: 24 Jul 2002 14:36:09.0527 (UTC) FILETIME=[738ABC70:01C2331F] Hi! I was just browsing the FreeBSD HTML manual pages looking for information about mlockall(2) munlockall(2) system calls. The manual pages were not there. This makes me wonder whether the pages are simply missing even though actual functions are there or whether these POSIX real-time extensions are really still missing from FreeBSD-5.0 while OpenBSD has had them since release 2.9. I have not really looked into the actual version 5.0 libraries yet, nor have I checked the source code. -- Cheers, // jau A computer, to print out a fact, will divide, multiply, and subtract. But this output can be no more than debris, if the input was short of exact. -- Gigo - End forwarded message - -- Wolfram Schneider [EMAIL PROTECTED] http://wolfram.schneider.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
no current snapshots available
Hi, there are no up to date current snapshots available. At ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/ the last snapshot is from 21-Mar-2002 and at ftp://snapshots.jp.freebsd.org/pub/FreeBSD/snapshots/i386/ the last snapshot is from 23-Mar-2002 (apparently disk full). -Wolfram -- Wolfram Schneider [EMAIL PROTECTED] http://wolfram.schneider.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: no new snapshot onftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/
Hi Makoto, the 5.0-current snapshots on current.jp.freebsd.org are not updated since 3-Aug-2001. What happens? -Wolfram wosch What happens? Is -current now so unstable that we cannot make a wosch snapshot anymore? current.jp.FreeBSD.org is for you until current.freebsd.org is back again; it's not a *mirror*, but has almost same features. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: no new snapshot onftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/
On 2001-08-19 00:48:19 +0900, Makoto MATSUSHITA wrote:
wosch the 5.0-current snapshots on current.jp.freebsd.org are not updated
wosch since 3-Aug-2001. What happens?
Really?
Sorry, my fault.
lrwxr-xr-x 1 root ftp 27 Aug 10 17:19 5-LATEST - 5.0-CURRENT-20010810-JPSNAP
The last successfully finished release should be Aug/10/2001.
Right.
Current 5-current release is broken, since KerberosIV-enabled
src/gnu/usr.bin/cvs is broken as follows:
Nevertheless, current sucks. No successfully builds since 9 days ;-{{
-Wolfram
cc -O -pipe -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib
-DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src
-I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib
-I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/diff -DHAVE_KERBEROS
-DHAVE_KRB_GET_ERR_TEXT -DENCRYPTION-c
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c: In function
`start_tcp_server':
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: `client_sai'
undeclared (first use in this function)
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: (Each
undeclared identifier is reported only once
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: for each
function it appears in.)
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4151: warning:
passing arg 6 of `krb_sendauth' discards qualifiers from pointer target type
*** Error code 1
Sorry I don't know how to fix.
-- -
Makoto `MAR' MATSUSHITA
--
Wolfram Schneider [EMAIL PROTECTED] http://wolfram.schneider.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: no new snapshot on ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/
On 2001-08-03 10:27:26 +0900, Makoto MATSUSHITA wrote: wosch What happens? Is -current now so unstable that we cannot make a wosch snapshot anymore? current.jp.FreeBSD.org is for you until current.freebsd.org is back again; it's not a *mirror*, but has almost same features. Great! I will use this server for the automatically update of the -current manpages at http://www.FreeBSD.org/cgi/man.cgi?manpath=FreeBSD+5.0-current Thanks, Wolfram -- Wolfram Schneider [EMAIL PROTECTED] http://wolfram.schneider.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
no new snapshot on ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/
Hi, the last -current snapshot is 6 weeks old. ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/5.0-20010618-CURRENT/, What happens? Is -current now so unstable that we cannot make a snapshot anymore? -Wolfram -- Wolfram Schneider [EMAIL PROTECTED] http://wolfram.schneider.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
swapper.core
I'm running -current from July 1999. Now I getting a core dump of the swapper daemon (sic!!!) after booting. This is really strange ... a dying swapper and 100MB free memory. I guess it is a interupt conflict with the 3com ethernet card. $ ls -l /swapper.core -rw--- 1 root wheel 8192 Jan 12 12:32 /swapper.core 1 3C5x9 board(s) on ISA found at 0x280 ep0 at port 0x280-0x28f irq 10 on isa0 ep0: aui/utp/bnc[*UTP*] address 00:20:af:05:37:0d ep0 XXX: driver didn't set ifq_maxlen kernel trap 9 with interrupts disabled pid 193 (swapper), uid 0: exited on signal 10 (core dumped) ps -xuawww | grep swap root 0 0.0 0.0 00 ?? DLs 28Jan36 0:00.00 (swapper) root 193 0.0 0.0 00 ?? Z- 0:00.00 (swapper) -- Wolfram Schneider [EMAIL PROTECTED] http://wolfram.schneider.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: optional 'make release' speed-up patch
On 1999-09-08 23:35:04 -0700, Rodney W. Grimes wrote:
Hi,
The following patch to /usr/src/release/Makefile allows the
specification of the variable FASTCLEAN, which instead of doing
a recursive rm on CHROOTDIR, simply umounts/newfs/mounts. Of
course, this is only useful if your CHROOTDIR location is a
separate mount point (which mine is: /snap).
Comments and critiques welcome.
And how about a similiar patch to /usr/src/Makefile that is
FASTCLEANDIR that brings back a patched up version of
my original CLEANDIR. Something like
-rm -rf /usr/obj/${.CURDIR}/tmp
chflags -R noschg /usr/obj/${.CURDIR}/tmp
rm -rf /usr/obj/${.CURDIR}
You could also rename the old obj directory and then
run the remove command as background process:
mv /usr/obj/${.CURDIR} /usr/obj/${.CURDIR}.foobar
( rm -rf /usr/obj/${.CURDIR}.foobar; \
chflags -R noschg /usr/obj/${.CURDIR}.foobar; \
rm -rf /usr/obj/${.CURDIR}.foobar )
--
Wolfram Schneider [EMAIL PROTECTED] http://wolfram.schneider.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make aout-to-elf on -current?
On 1999-04-16 00:54:32 -0600, Warner Losh wrote: Does make aout-to-elf still purport to work from a 2.2.8R system to a recent (like today's) current? I updated my laptop 4 weeks ago from 2.2.6R to 4.0-current. There where only minor problems, see PR bin/10784 and bin/10785 -- Wolfram Schneider wo...@freebsd.org http://wolfram.schneider.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Mail archive question
On 1999-01-21 12:10:38 -0700, Warner Losh wrote: Given a message id and a mailing list, is there some way construct a URL that will fetch that mail message. This will make doing the UPDATING file a little easier when long messages are sent to -current. I can say blah blah blah changed, see gross url for details. http://www.freebsd.org/cgi/mid.cgi?id=199901211910.maa79...@harmony.village.org or shorter http://www.freebsd.org/cgi/mid.cgi?199901211910.MAA79228 -- Wolfram Schneider wo...@freebsd.org http://freebsd.org/~w/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
make aout-to-elf died in src/gnu/usr.bin/texinfo/doc
I tried `make aout-to-elf' last sunday (17th Jan). Make died in src/gnu/usr.bin/texinfo/doc The Makefile started the elf binary `../makeinfo/makeinfo' But the elf linker was not yet ready ... -- Wolfram Schneider wo...@freebsd.org http://freebsd.org/~w/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
