On Mon, Jan 2, 2017 at 7:57 AM, Mateusz Guzik <mjguzik at 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 <mjguzik at
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 at
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