Completely cleaning out /usr/src and /usr/obj fixed it (both current and past revisions)
On Mon, Jan 2, 2017 at 8:33 AM, Aryeh Friedman <aryeh.fried...@gmail.com> wrote: > > > On Mon, Jan 2, 2017 at 7:57 AM, Mateusz Guzik <mjgu...@gmail.com> wrote: > >> On Mon, Jan 02, 2017 at 07:48:22AM -0500, Aryeh Friedman wrote: >> > On Mon, Jan 2, 2017 at 7:36 AM, Mateusz Guzik <mjgu...@gmail.com> >> wrote: >> > >> > > On Mon, Jan 02, 2017 at 06:57:48AM -0500, Aryeh Friedman wrote: >> > > > FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan >> 1 >> > > > 02:45:34 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC >> amd64 >> > > > >> > > > >> > > > -------------------------------------------------------------- >> > > > >>> stage 3.1: building everything >> > > > -------------------------------------------------------------- >> > > > cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=30901 >> > > > COMPILER_TYPE=clang COMPILER_FREEBSD_VERSION=1100503 >> > > > MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 >> CPUTYPE= >> > > > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >> > > > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >> > > > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc >> > > -target >> > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp >> > > > -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -target >> > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp >> > > > -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -target >> > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp >> > > > -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" NM=nm >> > > > OBJDUMP=objdump OBJCOPY="objcopy" RANLIB=ranlib STRINGS= >> SIZE="size" >> > > > INSTALL="sh /usr/src/tools/install.sh" >> > > > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/ >> > > src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/ >> > > usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/ >> > > sbin:/bin:/usr/sbin:/usr/bin >> > > > make -m /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ >> > > > linking kernel.full >> > > > ctfmerge -L VERSION -g -o kernel.full ... >> > > > <freezes> >> > > >> > > How reproducible is the crash? What previous kernel was known to work? >> > > Can you narrow it down to a particular revision, preferably with >> kernel >> > > debugging enabled? (see the end of the mail) >> > > >> > >> > It first appeared a few days ago (forget what revision) then disappeared >> > the day after and reappeared yesterday. It is 100% reproducible (i.e. >> > clearing out /usr/obj and doing a make kernel in either single or >> multiuser >> > mode both cause it). Turing on debugging would be hard but perhaps I >> > should slightly qualify "freeze": make freezes but the rest of the >> system >> > is responsive and killing make leaves a zombie ctfmerge. If I still >> need >> > kernel debugging based on the above I will do it but looking for an >> easier >> > explanation first. >> > >> >> I definitely don't run into anything of the sort and the problem >> statement is quote vague. >> >> However, if the problem is indeed reproducible, the minimum you can do >> is find the first revision where it started appearing and that would >> definitely help with an investigation. >> >> > Any advice on how to do that since I update daily I can tell you when it > started (the day) but not the actual revision ID. > > > > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
