Re: Head build unsafe for /etc today

[Mark Millard]

On 2017-Nov-2, at 8:50 PM, Steve Kargl  
wrote:

> On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote:
>> 
>> Are you accusing me of lying?
>> 
> 
> Nope.  I'm stating the obvious.  If you are using
> META_MODE and you do "make buildwould" that is 
> equivalent to "make -DNO_CLEAN buildworld", which
> means you did not rebuild the *world*. 

Also from a prior message of this sequence:

> If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> in whatever jail you use, then you're not properly testing 
> your changes to the build infrastructure.

With or without META_MODE, a rm -fr /usr/obj/*
before the build attempt forces a rebuild as far
as I know. It may be more that cleaning was
effectively not tested then rebuilding was
not tested. But always doing rm -fr /usr/obj/*
first establishes a very limited context for
testing cleaning.

WITH_META_MODE and WITHOUT_META_MODE still
might not be strictly equivalent after the
rm -fr /usr/obj/* for some other properties
in such an "empty" context. So testing those
combinations makes sense but would be
insufficient.

> When I see a commit message of the form (and I've
> haven't seen one like this in 25+ years of using
> FreeBSD (aka 386BSD+patchkit))
> 
> Author: bdrewery
> Date: Thu Nov  2 22:23:00 2017
> New Revision: 325347
> URL: https://svnweb.freebsd.org/changeset/base/325347
> 
> Log:
>  Something is very wrong
> 
> Modified:
>  head/Makefile
> 
> Modified: head/Makefile
> ==
> --- head/Makefile Thu Nov  2 21:58:18 2017(r325346)
> +++ head/Makefile Thu Nov  2 22:23:00 2017(r325347)
> @@ -1,3 +1,4 @@
> +.error Bad revision, please wait for a fix in head
> 
> It suggests that whomever did the commit did not properly test
> the patch.  The use of META_MODE (or any other shortcut) when
> testing simply isn't proper testing.

I think I understand the intended point but the
actual wording for "the use of . . ." and
"[i]f your first step isn't . . ." is wrong from
what I can tell.

The testing of WITH_META_MODE is a proper form of test
but is not a sufficient category of test overall. But
omitting all tests of WITH_META_MODE would be poor
procedure in my view.

Some testing needs to be done without rm -fr /usr/obj/*
after a prior build as well. Some testing of
WITH_META_MODE after a prior build needs to be done.
Some testing of WITHOUT_META_MODE after a prior build
needs to be done. And so on. At least that would be
my view.

Any and all mistakes checked-in are examples of
insufficient testing --but always doing sufficient
testing requires establishing a much simpler, more
limited, context. To my knowledge FreeBSD is not
trying to scale back like that. (It is not under
the direction of an Edsger W. Dijkstra.)

I do not know if something might be able to be done
to make such a specific type of "clean test" mistake
less likely to happen again. Could a test context
be established where attempts to delete outside the
build tree would be rejected, with notifications of
the attempts? Could running such a test be automatic
(part of something that is run systematically) and
fast enough to not want to skip it? (Just being
illustrative. The details involved are well outside
my background knowledge. There may be nothing
easy or reasonable.)

===
Mark Millard
markmi at dsl-only.net

___
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: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools

[Mark Millard]

[The rebuilding is not your problem. . . Its a
file system time problem.]

On 2017-Nov-2, at 8:16 PM, Mark Millard  wrote:

> On 2017-Nov-2, at 8:08 PM, Bryan Drewery  wrote:
> 
>> On 11/2/2017 7:47 PM, Mark Millard wrote:
>>> [Top post as it does not flow with the prior material.]
>>> 
>>> Back-to-back repeats of the same buildworld buildkernel
>>> command are rebuilding lots of obj-lib32 *.o files and
>>> the like each time under WITH_META_MODE=yes for -r325351.
>>> 
>> 
>> I think it is expected since I had to change the objdirs for build/cross
>> tools again to fix your report.
> 
> FYI: that was after several prior builds with -r325351. It is
> not just a first-repeat example.
> 
>> I am very confused how I never hit the issue you and Matt ran into. I
>> had this commit sitting in my test branch for days.  It may just be due
>> to SYSTEM_COMPILER getting triggered.  There's so many combinations of
>> options in the early build that it's impossible to test all of them.
> 
> I had WITH_META_MODE=yes as I normally do but had done
> the rm -fr of the tree content as well (because of
> directory tree structure mismatches that would be in
> the new build).
> 
>> Anyway if it continues to happen please also pass -dM to your make as it
>> will tell us why it is rebuilding.
> 
> I'm about to try that.

It reported a more up-to-date file.

But looking the timestamp was in the future (tomorrow,
almost 24 hours away):

# ls -lT 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/runetype.h
-rwxr-xr-x  1 root  wheel  3906 Nov  3 20:13:14 2017 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/runetype.h

Apparently one or more of the times when I booted the
virtual machine recently it ended up with a bad time
and part of at least /usr/include has the problem with
timestamps:

# ls -lT /usr/include/runetype.h
-r--r--r--  1 root  wheel  3906 Nov  3 22:48:30 2017 /usr/include/runetype.h

(The time for the active boot is fine.)

Sorry for the noise.

>>> Script started on Thu Nov  2 18:34:57 2017
>>> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null 
>>> SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host 
>>> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make 
>>> -j4 buildworld buildkernel
>>> 
>>> vs.
>>> 
>>> Script started on Thu Nov  2 18:34:57 2017
>>> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null 
>>> SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host 
>>> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make 
>>> -j4 buildworld buildkernel
>>> 
>>> 
>>> # svnlite status -u -r325351 /usr/src | sort
>>>   *   320623   /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h
>>> ?/usr/src/sys/amd64/conf/GENERIC-DBG
>>> ?/usr/src/sys/amd64/conf/GENERIC-NODBG
>>> ?/usr/src/sys/arm/conf/GENERIC-DBG
>>> ?/usr/src/sys/arm/conf/GENERIC-NODBG
>>> ?/usr/src/sys/arm64/conf/GENERIC-DBG
>>> ?/usr/src/sys/arm64/conf/GENERIC-NODBG
>>> ?/usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
>>> ?/usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
>>> ?/usr/src/sys/powerpc/conf/GENERICvtsc-DBG
>>> ?/usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
>>> M   325351   
>>> /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
>>> M   325351   /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
>>> M   325351   /usr/src/crypto/openssl/crypto/armcap.c
>>> M   325351   /usr/src/lib/libkvm/kvm_powerpc.c
>>> M   325351   /usr/src/lib/libkvm/kvm_private.c
>>> M   325351   /usr/src/sys/arm/allwinner/aw_usbphy.c
>>> M   325351   /usr/src/sys/arm64/arm64/identcpu.c
>>> M   325351   /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi
>>> M   325351   /usr/src/sys/boot/ofw/Makefile.inc
>>> M   325351   /usr/src/sys/boot/powerpc/Makefile.inc
>>> M   325351   /usr/src/sys/boot/powerpc/boot1.chrp/Makefile
>>> M   325351   /usr/src/sys/boot/powerpc/kboot/Makefile
>>> M   325351   /usr/src/sys/boot/uboot/Makefile.inc
>>> M   325351   /usr/src/sys/conf/kmod.mk
>>> M   325351   /usr/src/sys/conf/ldscript.powerpc
>>> M   325351   /usr/src/sys/kern/subr_pcpu.c
>>> M   325351   /usr/src/sys/powerpc/aim/mmu_oea64.c
>>> M   325351   /usr/src/sys/powerpc/ofw/ofw_machdep.c
>>> M   325351   /usr/src/sys/powerpc/powerpc/interrupt.c
>>> M   325351   /usr/src/sys/powerpc/powerpc/mp_machdep.c
>>> M   325351   /usr/src/sys/powerpc/powerpc/trap.c
>>> 
>>> 
>>> --
>> stage 5.1: building lib32 shim libraries
>>> 

Re: Head build unsafe for /etc today

[Warner Losh]

On Thu, Nov 2, 2017 at 9:50 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote:
> >
> > Are you accusing me of lying?
> >
>
> Nope.  I'm stating the obvious.  If you are using
> META_MODE and you do "make buildwould" that is
> equivalent to "make -DNO_CLEAN buildworld", which
> means you did not rebuild the *world*.
>
> When I see a commit message of the form (and I've
> haven't seen one like this in 25+ years of using
> FreeBSD (aka 386BSD+patchkit))
>
> Author: bdrewery
> Date: Thu Nov  2 22:23:00 2017
> New Revision: 325347
> URL: https://svnweb.freebsd.org/changeset/base/325347
>
> Log:
>   Something is very wrong
>
> Modified:
>   head/Makefile
>
> Modified: head/Makefile
> 
> ==
> --- head/Makefile   Thu Nov  2 21:58:18 2017(r325346)
> +++ head/Makefile   Thu Nov  2 22:23:00 2017(r325347)
> @@ -1,3 +1,4 @@
> +.error Bad revision, please wait for a fix in head
>
> It suggests that whomever did the commit did not properly test
> the patch.  The use of META_MODE (or any other shortcut) when
> testing simply isn't proper testing.


FreeBSD has grown too big to test every possible thing before you commit.
Lord knows the number of make universes I've done is maybe 1/100th the
number of commits (or less) I've made. We all take short cuts, or fail to
exhaustively test every single possible thing, or have some environmental
contamination that normally isn't a problem but masks an issue, or forget
to add a file / directory, or a hundred other things that can and do go
wrong. It happens. It will happen again. I just hope to never again be the
last person to break the tree before BSDcan again, but I live in fear that
I'll miss something because I know I'm human.

Personally, I think that this commit was the responsible thing to do: He'd
just committed several changes. It wasn't clear which one needed to be
backed out. While he tracked down the root cause, he put in counter
measures to make sure that nobody else got bitten by the bug he himself
encountered when he was further testing the system. He then resolved it by
fixing the root cause, but I know that had he not been able to do so, he'd
have backed things out.

Part of being in this project is recognizing that and allowing the
occasional oops to happen w/o making an unduly large case out of it...

Warner

Warner
___
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: Head build unsafe for /etc today

[Steve Kargl]

On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote:
> 
> Are you accusing me of lying?
> 

Nope.  I'm stating the obvious.  If you are using
META_MODE and you do "make buildwould" that is 
equivalent to "make -DNO_CLEAN buildworld", which
means you did not rebuild the *world*. 

When I see a commit message of the form (and I've
haven't seen one like this in 25+ years of using
FreeBSD (aka 386BSD+patchkit))

Author: bdrewery
Date: Thu Nov  2 22:23:00 2017
New Revision: 325347
URL: https://svnweb.freebsd.org/changeset/base/325347

Log:
  Something is very wrong

Modified:
  head/Makefile

Modified: head/Makefile
==
--- head/Makefile   Thu Nov  2 21:58:18 2017(r325346)
+++ head/Makefile   Thu Nov  2 22:23:00 2017(r325347)
@@ -1,3 +1,4 @@
+.error Bad revision, please wait for a fix in head

It suggests that whomever did the commit did not properly test
the patch.  The use of META_MODE (or any other shortcut) when
testing simply isn't proper testing.

-- 
Steve
___
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: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools

[Mark Millard]

On 2017-Nov-2, at 8:08 PM, Bryan Drewery  wrote:

> On 11/2/2017 7:47 PM, Mark Millard wrote:
>> [Top post as it does not flow with the prior material.]
>> 
>> Back-to-back repeats of the same buildworld buildkernel
>> command are rebuilding lots of obj-lib32 *.o files and
>> the like each time under WITH_META_MODE=yes for -r325351.
>> 
> 
> I think it is expected since I had to change the objdirs for build/cross
> tools again to fix your report.

FYI: that was after several prior builds with -r325351. It is
not just a first-repeat example.

> I am very confused how I never hit the issue you and Matt ran into. I
> had this commit sitting in my test branch for days.  It may just be due
> to SYSTEM_COMPILER getting triggered.  There's so many combinations of
> options in the early build that it's impossible to test all of them.

I had WITH_META_MODE=yes as I normally do but had done
the rm -fr of the tree content as well (because of
directory tree structure mismatches that would be in
the new build).

> Anyway if it continues to happen please also pass -dM to your make as it
> will tell us why it is rebuilding.

I'm about to try that.

>> Script started on Thu Nov  2 18:34:57 2017
>> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null 
>> SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host 
>> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make 
>> -j4 buildworld buildkernel
>> 
>> vs.
>> 
>> Script started on Thu Nov  2 18:34:57 2017
>> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null 
>> SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host 
>> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make 
>> -j4 buildworld buildkernel
>> 
>> 
>> # svnlite status -u -r325351 /usr/src | sort
>>*   320623   /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h
>> ?/usr/src/sys/amd64/conf/GENERIC-DBG
>> ?/usr/src/sys/amd64/conf/GENERIC-NODBG
>> ?/usr/src/sys/arm/conf/GENERIC-DBG
>> ?/usr/src/sys/arm/conf/GENERIC-NODBG
>> ?/usr/src/sys/arm64/conf/GENERIC-DBG
>> ?/usr/src/sys/arm64/conf/GENERIC-NODBG
>> ?/usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
>> ?/usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
>> ?/usr/src/sys/powerpc/conf/GENERICvtsc-DBG
>> ?/usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
>> M   325351   
>> /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
>> M   325351   /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
>> M   325351   /usr/src/crypto/openssl/crypto/armcap.c
>> M   325351   /usr/src/lib/libkvm/kvm_powerpc.c
>> M   325351   /usr/src/lib/libkvm/kvm_private.c
>> M   325351   /usr/src/sys/arm/allwinner/aw_usbphy.c
>> M   325351   /usr/src/sys/arm64/arm64/identcpu.c
>> M   325351   /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi
>> M   325351   /usr/src/sys/boot/ofw/Makefile.inc
>> M   325351   /usr/src/sys/boot/powerpc/Makefile.inc
>> M   325351   /usr/src/sys/boot/powerpc/boot1.chrp/Makefile
>> M   325351   /usr/src/sys/boot/powerpc/kboot/Makefile
>> M   325351   /usr/src/sys/boot/uboot/Makefile.inc
>> M   325351   /usr/src/sys/conf/kmod.mk
>> M   325351   /usr/src/sys/conf/ldscript.powerpc
>> M   325351   /usr/src/sys/kern/subr_pcpu.c
>> M   325351   /usr/src/sys/powerpc/aim/mmu_oea64.c
>> M   325351   /usr/src/sys/powerpc/ofw/ofw_machdep.c
>> M   325351   /usr/src/sys/powerpc/powerpc/interrupt.c
>> M   325351   /usr/src/sys/powerpc/powerpc/mp_machdep.c
>> M   325351   /usr/src/sys/powerpc/powerpc/trap.c
>> 
>> 
>> --
> stage 5.1: building lib32 shim libraries
>> --
>> . . .
>> --- obj ---
>> --- lib/libgcc_eh__PL ---
>> Building 
>> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libgcc_eh/libunwind.o
>> --- gnu/lib/libssp/libssp_nonshared__PL ---
>> Building 
>> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/gnu/lib/libssp/libssp_nonshared/_libinstall
>> . . .
>> . . .
>> 
>> And so on.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2017-Nov-2, at 5:30 PM, Bryan Drewery  wrote:
> 
> On 11/2/17 3:44 PM, Mark Millard wrote:
>>> Author: bdrewery
>>> Date: Thu Nov  2 22:23:00 2017
>>> New Revision: 325347
>>> URL: 
>>> https://svnweb.freebsd.org/changeset/base/325347
>>> 
>>> 
>>> Log:
>>> Something is very wrong
>>> 
>>> Modified:
>>> head/Makefile
>>> 
>>> Modified: head/Makefile
>>> ==
>>> --- head/Makefile   Thu 

Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools

[Bryan Drewery]

On 11/2/2017 7:47 PM, Mark Millard wrote:
> [Top post as it does not flow with the prior material.]
> 
> Back-to-back repeats of the same buildworld buildkernel
> command are rebuilding lots of obj-lib32 *.o files and
> the like each time under WITH_META_MODE=yes for -r325351.
> 

I think it is expected since I had to change the objdirs for build/cross
tools again to fix your report.

I am very confused how I never hit the issue you and Matt ran into. I
had this commit sitting in my test branch for days.  It may just be due
to SYSTEM_COMPILER getting triggered.  There's so many combinations of
options in the early build that it's impossible to test all of them.

Anyway if it continues to happen please also pass -dM to your make as it
will tell us why it is rebuilding.

> Script started on Thu Nov  2 18:34:57 2017
> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null 
> SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host 
> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make -j4 
> buildworld buildkernel
> 
> vs.
> 
> Script started on Thu Nov  2 18:34:57 2017
> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null 
> SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host 
> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make -j4 
> buildworld buildkernel
> 
> 
> # svnlite status -u -r325351 /usr/src | sort
> *   320623   /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h
> ?/usr/src/sys/amd64/conf/GENERIC-DBG
> ?/usr/src/sys/amd64/conf/GENERIC-NODBG
> ?/usr/src/sys/arm/conf/GENERIC-DBG
> ?/usr/src/sys/arm/conf/GENERIC-NODBG
> ?/usr/src/sys/arm64/conf/GENERIC-DBG
> ?/usr/src/sys/arm64/conf/GENERIC-NODBG
> ?/usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
> ?/usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
> ?/usr/src/sys/powerpc/conf/GENERICvtsc-DBG
> ?/usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
> M   325351   
> /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
> M   325351   /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
> M   325351   /usr/src/crypto/openssl/crypto/armcap.c
> M   325351   /usr/src/lib/libkvm/kvm_powerpc.c
> M   325351   /usr/src/lib/libkvm/kvm_private.c
> M   325351   /usr/src/sys/arm/allwinner/aw_usbphy.c
> M   325351   /usr/src/sys/arm64/arm64/identcpu.c
> M   325351   /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi
> M   325351   /usr/src/sys/boot/ofw/Makefile.inc
> M   325351   /usr/src/sys/boot/powerpc/Makefile.inc
> M   325351   /usr/src/sys/boot/powerpc/boot1.chrp/Makefile
> M   325351   /usr/src/sys/boot/powerpc/kboot/Makefile
> M   325351   /usr/src/sys/boot/uboot/Makefile.inc
> M   325351   /usr/src/sys/conf/kmod.mk
> M   325351   /usr/src/sys/conf/ldscript.powerpc
> M   325351   /usr/src/sys/kern/subr_pcpu.c
> M   325351   /usr/src/sys/powerpc/aim/mmu_oea64.c
> M   325351   /usr/src/sys/powerpc/ofw/ofw_machdep.c
> M   325351   /usr/src/sys/powerpc/powerpc/interrupt.c
> M   325351   /usr/src/sys/powerpc/powerpc/mp_machdep.c
> M   325351   /usr/src/sys/powerpc/powerpc/trap.c
> 
> 
> --
 stage 5.1: building lib32 shim libraries
> --
> . . .
> --- obj ---
> --- lib/libgcc_eh__PL ---
> Building 
> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libgcc_eh/libunwind.o
> --- gnu/lib/libssp/libssp_nonshared__PL ---
> Building 
> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/gnu/lib/libssp/libssp_nonshared/_libinstall
> --- lib/libcompiler_rt__PL ---
> Building 
> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libcompiler_rt/_libinstall
> Building 
> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libcompiler_rt/_installlinks
> --- _installlinks ---
> /usr/lib32/libgcc.a -> libcompiler_rt.a
> --- lib/libgcc_eh__PL ---
> Building 
> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libgcc_eh/libgcc_eh.a
> --- libgcc_eh.a ---
> building static gcc_eh library
> Building 
> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libgcc_eh/_libinstall
> --- gnu/lib/csu__L ---
> --- lib/csu__L ---
> --- lib/libcompiler_rt__L ---
> --- lib/libc__L ---
> --- gnu/lib/csu__L ---
> ===> gnu/lib/csu (obj,all,install)
> --- lib/csu__L ---
> ===> lib/csu (obj,all,install)
> --- lib/libcompiler_rt__L ---
> ===> lib/libcompiler_rt (obj,all,install)
> --- lib/libc__L ---
> ===> lib/libc (obj,all,install)
> --- lib/csu__L ---
> --- 

Re: Head build unsafe for /etc today

[Bryan Drewery]

On 11/2/2017 7:46 PM, Warner Losh wrote:
> 
> 
> On Thu, Nov 2, 2017 at 8:41 PM, Bryan Drewery  > wrote:
> 
> 
> 
> > On Nov 2, 2017, at 19:23, Steve Kargl  > wrote:
> >
> >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
> >>
> >>
>  On Nov 2, 2017, at 18:49, Steve Kargl 
>  > wrote:
> 
>  On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> 
>  On Nov 2, 2017, at 15:44, Mark Millard  > wrote:
> 
> >> Author: bdrewery
> >> Date: Thu Nov  2 22:23:00 2017
> >> New Revision: 325347
> >> URL:
> >> https://svnweb.freebsd.org/changeset/base/325347
> 
> >>
> >>
> >> Log:
> >> Something is very wrong
> 
> 
>  Unfortunately I only test with META_MODE these days which implies 
> -DNO_CLEAN.
> >>>
> >>> You're making changes to the build infrastructure and you're
> >>> not properly testing it before committing?  This is beyond
> >>> pointyhat material.
> >>
> >> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of 
> installworld and installkernel, several xdev and native-xtools, several full 
> DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, 
> tested several targets together, ran various special case tests for submakes, 
> played around with a ton of MAKEOBJDIRPREFIX cases, handled and tested 
> symlinked objdirs special, ran it through my work repro a few times, did 
> special testing in rescue/, and had a volunteer test release.  In the process 
>  I found a bmake bug, GPL_DTC build bug and several others I don’t recall 
> from the bus.
> >>
> >> What I missed was the “clean” buildworld because I forgot it even 
> exists. I’ve wanted to remove it for a year. I also forgot to test buildenv.
> >>
> >
> > If you did all the above under META_MODE, then no you did not
> > buildworld and buildkernel and all the other stuff you claim.
> 
> Are you accusing me of lying?
> 
> 
> > If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> > in whatever jail you use, then you're not properly testing
> > your changes to the build
> 
> I did that probably 100 times. And that isn’t even “the proper
> test”. Both clean and incremental are needed which I did. zfs
> snapshots help a lot there. I just never ran “_cleanobj” which does
> a full tree walk of clean. But I ran make clean in some subdirs many
> times.
> 
> > infrastructure.  As you have demonstrated,
> > Makefile, Makefile.inc1, and the *.mk files are sufficiently
> > complicated that proper testing
> 
> > should be done, and proper
> > testing means one doesn't takes shortcuts.
> 
> I took 0 shortcuts. As I said I *forgot* that case, among hundreds
> of cases.
> You’re welcome to do this work if you want. I guarantee you would
> not have tested even half of what I tested.
> 
> Hey can you fix universe to only build clang once please? I’ve been
> working up to that but I think you’re best to do it.
> 
> 
> Given the hundreds of commits to the build system and its complexity,
> I'm in awe this doesn't happen more often. Heck, I've done an order of
> magnitude fewer commits to the build system and broken it more often
> than you have, and that's when it was a much simpler beast than it is today.
> 
> Steve's just being overly grumpy imho.  Accidents happen despite one's
> best efforts. This is -current after all...

Sorry I became grumpy too...

I am truly sorry for anyone bit by this. I understand being angry about
it. I too was bitten by it and scrambled to get a fix in on a random
system I had up without much information on what the root cause was. At
first I thought it was the last minute bmake update which came in after
my change since I had no seen anything like this in my testing.  The
commit which caused the problem was reviewed, but the bug was dormant in
unchanged code.

The bug is fixed now, but I am going to keep the AUTO_OBJ feature off
for a few days until I add a few more seatbelts to prevent this again.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools

[Mark Millard]

[Top post as it does not flow with the prior material.]

Back-to-back repeats of the same buildworld buildkernel
command are rebuilding lots of obj-lib32 *.o files and
the like each time under WITH_META_MODE=yes for -r325351.

Script started on Thu Nov  2 18:34:57 2017
Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null 
SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host 
WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make -j4 
buildworld buildkernel

vs.

Script started on Thu Nov  2 18:34:57 2017
Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null 
SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host 
WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make -j4 
buildworld buildkernel


# svnlite status -u -r325351 /usr/src | sort
*   320623   /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h
?/usr/src/sys/amd64/conf/GENERIC-DBG
?/usr/src/sys/amd64/conf/GENERIC-NODBG
?/usr/src/sys/arm/conf/GENERIC-DBG
?/usr/src/sys/arm/conf/GENERIC-NODBG
?/usr/src/sys/arm64/conf/GENERIC-DBG
?/usr/src/sys/arm64/conf/GENERIC-NODBG
?/usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
?/usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
?/usr/src/sys/powerpc/conf/GENERICvtsc-DBG
?/usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
M   325351   
/usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
M   325351   /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
M   325351   /usr/src/crypto/openssl/crypto/armcap.c
M   325351   /usr/src/lib/libkvm/kvm_powerpc.c
M   325351   /usr/src/lib/libkvm/kvm_private.c
M   325351   /usr/src/sys/arm/allwinner/aw_usbphy.c
M   325351   /usr/src/sys/arm64/arm64/identcpu.c
M   325351   /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi
M   325351   /usr/src/sys/boot/ofw/Makefile.inc
M   325351   /usr/src/sys/boot/powerpc/Makefile.inc
M   325351   /usr/src/sys/boot/powerpc/boot1.chrp/Makefile
M   325351   /usr/src/sys/boot/powerpc/kboot/Makefile
M   325351   /usr/src/sys/boot/uboot/Makefile.inc
M   325351   /usr/src/sys/conf/kmod.mk
M   325351   /usr/src/sys/conf/ldscript.powerpc
M   325351   /usr/src/sys/kern/subr_pcpu.c
M   325351   /usr/src/sys/powerpc/aim/mmu_oea64.c
M   325351   /usr/src/sys/powerpc/ofw/ofw_machdep.c
M   325351   /usr/src/sys/powerpc/powerpc/interrupt.c
M   325351   /usr/src/sys/powerpc/powerpc/mp_machdep.c
M   325351   /usr/src/sys/powerpc/powerpc/trap.c


--
>>> stage 5.1: building lib32 shim libraries
--
. . .
--- obj ---
--- lib/libgcc_eh__PL ---
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libgcc_eh/libunwind.o
--- gnu/lib/libssp/libssp_nonshared__PL ---
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/gnu/lib/libssp/libssp_nonshared/_libinstall
--- lib/libcompiler_rt__PL ---
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libcompiler_rt/_libinstall
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libcompiler_rt/_installlinks
--- _installlinks ---
/usr/lib32/libgcc.a -> libcompiler_rt.a
--- lib/libgcc_eh__PL ---
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libgcc_eh/libgcc_eh.a
--- libgcc_eh.a ---
building static gcc_eh library
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libgcc_eh/_libinstall
--- gnu/lib/csu__L ---
--- lib/csu__L ---
--- lib/libcompiler_rt__L ---
--- lib/libc__L ---
--- gnu/lib/csu__L ---
===> gnu/lib/csu (obj,all,install)
--- lib/csu__L ---
===> lib/csu (obj,all,install)
--- lib/libcompiler_rt__L ---
===> lib/libcompiler_rt (obj,all,install)
--- lib/libc__L ---
===> lib/libc (obj,all,install)
--- lib/csu__L ---
--- obj_subdir_lib/csu/i386 ---
===> lib/csu/i386 (obj)
--- gnu/lib/csu__L ---
--- obj ---
--- lib/csu__L ---
--- obj ---
--- all_subdir_lib/csu/i386 ---
===> lib/csu/i386 (all)
--- lib/libcompiler_rt__L ---
--- obj ---
--- gnu/lib/csu__L ---
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/gnu/lib/csu/crtbegin.o
--- lib/csu__L ---
--- realinstall_subdir_lib/csu/i386 ---
===> lib/csu/i386 (install)
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/csu/i386/_FILESINS
--- gnu/lib/csu__L ---
Building 
/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/gnu/lib/csu/crtend.o
--- lib/libc_nonshared__L ---
===> lib/libc_nonshared 

Re: Head build unsafe for /etc today

[Warner Losh]

On Thu, Nov 2, 2017 at 8:41 PM, Bryan Drewery  wrote:

>
>
> > On Nov 2, 2017, at 19:23, Steve Kargl 
> wrote:
> >
> >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
> >>
> >>
>  On Nov 2, 2017, at 18:49, Steve Kargl  edu> wrote:
> 
>  On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> 
>  On Nov 2, 2017, at 15:44, Mark Millard  wrote:
> 
> >> Author: bdrewery
> >> Date: Thu Nov  2 22:23:00 2017
> >> New Revision: 325347
> >> URL:
> >> https://svnweb.freebsd.org/changeset/base/325347
> >>
> >>
> >> Log:
> >> Something is very wrong
> 
> 
>  Unfortunately I only test with META_MODE these days which implies
> -DNO_CLEAN.
> >>>
> >>> You're making changes to the build infrastructure and you're
> >>> not properly testing it before committing?  This is beyond
> >>> pointyhat material.
> >>
> >> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of
> installworld and installkernel, several xdev and native-xtools, several
> full DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir
> cleans, tested several targets together, ran various special case tests for
> submakes, played around with a ton of MAKEOBJDIRPREFIX cases, handled and
> tested symlinked objdirs special, ran it through my work repro a few times,
> did special testing in rescue/, and had a volunteer test release.  In the
> process  I found a bmake bug, GPL_DTC build bug and several others I don’t
> recall from the bus.
> >>
> >> What I missed was the “clean” buildworld because I forgot it even
> exists. I’ve wanted to remove it for a year. I also forgot to test buildenv.
> >>
> >
> > If you did all the above under META_MODE, then no you did not
> > buildworld and buildkernel and all the other stuff you claim.
>
> Are you accusing me of lying?
>
>
> > If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> > in whatever jail you use, then you're not properly testing
> > your changes to the build
>
> I did that probably 100 times. And that isn’t even “the proper test”. Both
> clean and incremental are needed which I did. zfs snapshots help a lot
> there. I just never ran “_cleanobj” which does a full tree walk of clean.
> But I ran make clean in some subdirs many times.
>
> > infrastructure.  As you have demonstrated,
> > Makefile, Makefile.inc1, and the *.mk files are sufficiently
> > complicated that proper testing
>
> > should be done, and proper
> > testing means one doesn't takes shortcuts.
>
> I took 0 shortcuts. As I said I *forgot* that case, among hundreds of
> cases.
> You’re welcome to do this work if you want. I guarantee you would not have
> tested even half of what I tested.
>
> Hey can you fix universe to only build clang once please? I’ve been
> working up to that but I think you’re best to do it.


Given the hundreds of commits to the build system and its complexity, I'm
in awe this doesn't happen more often. Heck, I've done an order of
magnitude fewer commits to the build system and broken it more often than
you have, and that's when it was a much simpler beast than it is today.

Steve's just being overly grumpy imho.  Accidents happen despite one's best
efforts. This is -current after all...

Warner
___
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: Head build unsafe for /etc today

[Bryan Drewery]

> On Nov 2, 2017, at 19:36, Glen Barber  wrote:
> 
>> On Thu, Nov 02, 2017 at 07:23:27PM -0700, Steve Kargl wrote:
>> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
 On Nov 2, 2017, at 18:49, Steve Kargl  
 wrote:
 You're making changes to the build infrastructure and you're
 not properly testing it before committing?  This is beyond
 pointyhat material. 
>>> 
>>> I ran 2 universes, dozens of buildworlds and buildkernels,
>>> dozens of installworld and installkernel, several xdev and
>>> native-xtools, several full DIRDEPS_BUILD builds and bootstraps,
>>> ran subdir builds, ran subdir cleans, tested several targets together,
>>> ran various special case tests for submakes, played around with a
>>> ton of MAKEOBJDIRPREFIX cases, handled and tested symlinked objdirs
>>> special, ran it through my work repro a few times, did special
>>> testing in rescue/, and had a volunteer test release.  In the process
>>> I found a bmake bug, GPL_DTC build bug and several others I don’t
>>> recall from the bus.
>>> 
>>> What I missed was the “clean” buildworld because I forgot it
>>> even exists. I’ve wanted to remove it for a year. I also forgot to
>>> test buildenv.
>>> 
>> 
>> If you did all the above under META_MODE, then no you did not 
>> buildworld and buildkernel and all the other stuff you claim.
>> If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
>> in whatever jail you use, then you're not properly testing 
>> your changes to the build infrastructure.
> 
> I did test this, personally, and missed it.

To be fair you didn’t test the AUTO_OBJ piece but did test the much more 
riskier changes to objdir handling. Thanks for that.


>> As you have demonstrated,
>> Makefile, Makefile.inc1, and the *.mk files are sufficiently 
>> complicated that proper testing should be done, and proper 
>> testing means one doesn't takes shortcuts.
>> 
> 
> Mistakes happen.  Things sometimes get accidentally missed.
> 
> Glen
> 

___
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: Head build unsafe for /etc today

[Bryan Drewery]

> On Nov 2, 2017, at 19:23, Steve Kargl  
> wrote:
> 
>> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
>> 
>> 
 On Nov 2, 2017, at 18:49, Steve Kargl  
 wrote:
 
 On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
 
 On Nov 2, 2017, at 15:44, Mark Millard  wrote:
 
>> Author: bdrewery
>> Date: Thu Nov  2 22:23:00 2017
>> New Revision: 325347
>> URL: 
>> https://svnweb.freebsd.org/changeset/base/325347
>> 
>> 
>> Log:
>> Something is very wrong
 
 
 Unfortunately I only test with META_MODE these days which implies 
 -DNO_CLEAN.
>>> 
>>> You're making changes to the build infrastructure and you're
>>> not properly testing it before committing?  This is beyond
>>> pointyhat material. 
>> 
>> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of 
>> installworld and installkernel, several xdev and native-xtools, several full 
>> DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, 
>> tested several targets together, ran various special case tests for 
>> submakes, played around with a ton of MAKEOBJDIRPREFIX cases, handled and 
>> tested symlinked objdirs special, ran it through my work repro a few times, 
>> did special testing in rescue/, and had a volunteer test release.  In the 
>> process  I found a bmake bug, GPL_DTC build bug and several others I don’t 
>> recall from the bus.
>> 
>> What I missed was the “clean” buildworld because I forgot it even exists. 
>> I’ve wanted to remove it for a year. I also forgot to test buildenv.
>> 
> 
> If you did all the above under META_MODE, then no you did not 
> buildworld and buildkernel and all the other stuff you claim.

Are you accusing me of lying?


> If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> in whatever jail you use, then you're not properly testing 
> your changes to the build

I did that probably 100 times. And that isn’t even “the proper test”. Both 
clean and incremental are needed which I did. zfs snapshots help a lot there. I 
just never ran “_cleanobj” which does a full tree walk of clean. But I ran make 
clean in some subdirs many times.

> infrastructure.  As you have demonstrated,
> Makefile, Makefile.inc1, and the *.mk files are sufficiently 
> complicated that proper testing

> should be done, and proper 
> testing means one doesn't takes shortcuts.

I took 0 shortcuts. As I said I *forgot* that case, among hundreds of cases.
You’re welcome to do this work if you want. I guarantee you would not have 
tested even half of what I tested. 

Hey can you fix universe to only build clang once please? I’ve been working up 
to that but I think you’re best to do it.

> 
> -- 
> Steve

___
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: Head build unsafe for /etc today

[Glen Barber]

On Thu, Nov 02, 2017 at 07:23:27PM -0700, Steve Kargl wrote:
> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
> > > On Nov 2, 2017, at 18:49, Steve Kargl  
> > > wrote:
> > > You're making changes to the build infrastructure and you're
> > > not properly testing it before committing?  This is beyond
> > > pointyhat material. 
> > 
> > I ran 2 universes, dozens of buildworlds and buildkernels,
> > dozens of installworld and installkernel, several xdev and
> > native-xtools, several full DIRDEPS_BUILD builds and bootstraps,
> > ran subdir builds, ran subdir cleans, tested several targets together,
> > ran various special case tests for submakes, played around with a
> > ton of MAKEOBJDIRPREFIX cases, handled and tested symlinked objdirs
> > special, ran it through my work repro a few times, did special
> > testing in rescue/, and had a volunteer test release.  In the process
> > I found a bmake bug, GPL_DTC build bug and several others I don’t
> > recall from the bus.
> > 
> > What I missed was the “clean” buildworld because I forgot it
> > even exists. I’ve wanted to remove it for a year. I also forgot to
> > test buildenv.
> > 
> 
> If you did all the above under META_MODE, then no you did not 
> buildworld and buildkernel and all the other stuff you claim.
> If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> in whatever jail you use, then you're not properly testing 
> your changes to the build infrastructure.

I did test this, personally, and missed it.

> As you have demonstrated,
> Makefile, Makefile.inc1, and the *.mk files are sufficiently 
> complicated that proper testing should be done, and proper 
> testing means one doesn't takes shortcuts.
> 

Mistakes happen.  Things sometimes get accidentally missed.

Glen



signature.asc
Description: PGP signature

Re: Head build unsafe for /etc today

[Steve Kargl]

On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
> 
> 
> > On Nov 2, 2017, at 18:49, Steve Kargl  
> > wrote:
> > 
> >> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> >> 
> >> On Nov 2, 2017, at 15:44, Mark Millard  wrote:
> >> 
>  Author: bdrewery
>  Date: Thu Nov  2 22:23:00 2017
>  New Revision: 325347
>  URL: 
>  https://svnweb.freebsd.org/changeset/base/325347
>  
>  
>  Log:
>  Something is very wrong
> >> 
> >> 
> >> Unfortunately I only test with META_MODE these days which implies 
> >> -DNO_CLEAN.
> > 
> > You're making changes to the build infrastructure and you're
> > not properly testing it before committing?  This is beyond
> > pointyhat material. 
> 
> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of 
> installworld and installkernel, several xdev and native-xtools, several full 
> DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, 
> tested several targets together, ran various special case tests for submakes, 
> played around with a ton of MAKEOBJDIRPREFIX cases, handled and tested 
> symlinked objdirs special, ran it through my work repro a few times, did 
> special testing in rescue/, and had a volunteer test release.  In the process 
>  I found a bmake bug, GPL_DTC build bug and several others I don’t recall 
> from the bus.
> 
> What I missed was the “clean” buildworld because I forgot it even exists. 
> I’ve wanted to remove it for a year. I also forgot to test buildenv.
> 

If you did all the above under META_MODE, then no you did not 
buildworld and buildkernel and all the other stuff you claim.
If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
in whatever jail you use, then you're not properly testing 
your changes to the build infrastructure.  As you have demonstrated,
Makefile, Makefile.inc1, and the *.mk files are sufficiently 
complicated that proper testing should be done, and proper 
testing means one doesn't takes shortcuts.

-- 
Steve
___
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: Head build unsafe for /etc today

[Bryan Drewery]

> On Nov 2, 2017, at 18:49, Steve Kargl  
> wrote:
> 
>> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
>> 
>> On Nov 2, 2017, at 15:44, Mark Millard  wrote:
>> 
 Author: bdrewery
 Date: Thu Nov  2 22:23:00 2017
 New Revision: 325347
 URL: 
 https://svnweb.freebsd.org/changeset/base/325347
 
 
 Log:
 Something is very wrong
>> 
>> 
>> Unfortunately I only test with META_MODE these days which implies -DNO_CLEAN.
> 
> You're making changes to the build infrastructure and you're
> not properly testing it before committing?  This is beyond
> pointyhat material. 

I ran 2 universes, dozens of buildworlds and buildkernels, dozens of 
installworld and installkernel, several xdev and native-xtools, several full 
DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir cleans, 
tested several targets together, ran various special case tests for submakes, 
played around with a ton of MAKEOBJDIRPREFIX cases, handled and tested 
symlinked objdirs special, ran it through my work repro a few times, did 
special testing in rescue/, and had a volunteer test release.  In the process  
I found a bmake bug, GPL_DTC build bug and several others I don’t recall from 
the bus.

What I missed was the “clean” buildworld because I forgot it even exists. I’ve 
wanted to remove it for a year. I also forgot to test buildenv.

By the way the bug ran into here was 3-4 years old and I avoided the exact case 
in some new code but missed that the problem was already existing subtly in 
bsd.obj.mk.

Having said all of that, I certainly don’t do so much testing normally but 
these changes warranted the time I put in.

> 
> -- 
> Steve

___
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: Head build unsafe for /etc today

[Steve Kargl]

On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> 
> On Nov 2, 2017, at 15:44, Mark Millard  wrote:
> 
> >> Author: bdrewery
> >> Date: Thu Nov  2 22:23:00 2017
> >> New Revision: 325347
> >> URL: 
> >> https://svnweb.freebsd.org/changeset/base/325347
> >> 
> >> 
> >> Log:
> >> Something is very wrong
> 
> 
> Unfortunately I only test with META_MODE these days which implies -DNO_CLEAN.

You're making changes to the build infrastructure and you're
not properly testing it before committing?  This is beyond
pointyhat material. 

-- 
Steve
___
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"

Head build unsafe for /etc today

[Bryan Drewery]

On Nov 2, 2017, at 15:44, Mark Millard  wrote:

>> Author: bdrewery
>> Date: Thu Nov  2 22:23:00 2017
>> New Revision: 325347
>> URL: 
>> https://svnweb.freebsd.org/changeset/base/325347
>> 
>> 
>> Log:
>> Something is very wrong


Unfortunately I only test with META_MODE these days which implies -DNO_CLEAN.

In the “clean” builds it was removing /sys/boot and /etc, but nothing else in 
/.  The problems have been fixed in head as of r325351.
The problem came in r325330.
This was in head for ~10 hours.

Sorry for the trouble.

>> 
>> Modified:
>> head/Makefile
>> 
>> Modified: head/Makefile
>> ==
>> --- head/MakefileThu Nov  2 21:58:18 2017(r325346)
>> +++ head/MakefileThu Nov  2 22:23:00 2017(r325347)
>> @@ -1,3 +1,4 @@
>> +.error Bad revision, please wait for a fix in head
>> #
>> # $FreeBSD$
>> #
> 
> I just happened to have started a cross build before
> this showed up based on -r325332 . It got:
> 
> --- clang-tblgen.full ---
> c++: error: no such file or directory: 
> '/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a'
> *** [clang-tblgen.full] Error code 1
> 
> But find shows:
> 
> # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name 
> "libllvmminimal*" -print | more
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a.meta
> 
> Comparing side-by-side shows obj-cross-tools vs.
> obj-bootstrap-tools :
> 
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
___
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: Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools

[Bryan Drewery]

On 11/2/17 3:44 PM, Mark Millard wrote:
>> Author: bdrewery
>> Date: Thu Nov  2 22:23:00 2017
>> New Revision: 325347
>> URL: 
>> https://svnweb.freebsd.org/changeset/base/325347
>>
>>
>> Log:
>>   Something is very wrong
>>
>> Modified:
>>   head/Makefile
>>
>> Modified: head/Makefile
>> ==
>> --- head/MakefileThu Nov  2 21:58:18 2017(r325346)
>> +++ head/MakefileThu Nov  2 22:23:00 2017(r325347)
>> @@ -1,3 +1,4 @@
>> +.error Bad revision, please wait for a fix in head
>>  #
>>  # $FreeBSD$
>>  #
> 
> I just happened to have started a cross build before
> this showed up based on -r325332 . It got:
> 
> --- clang-tblgen.full ---
> c++: error: no such file or directory: 
> '/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a'
> *** [clang-tblgen.full] Error code 1

Someone else reported this one as well but I have not been able to
reproduce it yet.

I've tweaked the commit causing it though, r325329.  Fixed in r325350.

> 
> But find shows:
> 
> # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name 
> "libllvmminimal*" -print | more
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a.meta
> 
> Comparing side-by-side shows obj-cross-tools vs.
> obj-bootstrap-tools :
> 
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools

[Mark Millard]

> Author: bdrewery
> Date: Thu Nov  2 22:23:00 2017
> New Revision: 325347
> URL: 
> https://svnweb.freebsd.org/changeset/base/325347
> 
> 
> Log:
>   Something is very wrong
> 
> Modified:
>   head/Makefile
> 
> Modified: head/Makefile
> ==
> --- head/Makefile Thu Nov  2 21:58:18 2017(r325346)
> +++ head/Makefile Thu Nov  2 22:23:00 2017(r325347)
> @@ -1,3 +1,4 @@
> +.error Bad revision, please wait for a fix in head
>  #
>  # $FreeBSD$
>  #

I just happened to have started a cross build before
this showed up based on -r325332 . It got:

--- clang-tblgen.full ---
c++: error: no such file or directory: 
'/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a'
*** [clang-tblgen.full] Error code 1

But find shows:

# find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name "libllvmminimal*" 
-print | more
/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal
/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a
/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a.meta

Comparing side-by-side shows obj-cross-tools vs.
obj-bootstrap-tools :

/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a
/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a


===
Mark Millard
markmi at dsl-only.net

___
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: r325250: panics on USB stick insert

[Mark Millard]

Poul-Henning Kamp phk at phk.freebsd.dk wrote on
Thu Nov 2 14:19:23 UTC 2017 :

> I updated to r325250M amd64 last night, and now my laptop panics in
> geom when I plug my mobile phone in.
> 
> I'll try to get a panic message when I'm in less of a hurry...

-r325272 has a geom fix to the earlier -r325227: -r325227 was
causing various folks problems.

-r325272 or later may avoid your problem.

===
Mark Millard
markmi at dsl-only.net

___
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: iwm not in GENERIC kernel

[Ngie Cooper]

> On Nov 2, 2017, at 09:53, Adrian Chadd  wrote:
> 
> ugh okay
> 
> So it's a chicken/egg problem.
> 
> You can't finish the device probe/attach until the firmware loads.
> 
> For iwn, you can read the chipset abilities and mac address from
> EPROM/flash on the chip without the firmware being loaded, so you can
> complete probe/attach before the root filesystem is mounted.
> 
> For iwm, you have to load the firmware before you can read the chipset
> abilities and MAC address so you can't complete probe/attach until
> AFTER the root filesystem is mounted.
> 
> If someone wants to go add all of that support in to have probe/attach
> deferred until after rootfs is available then please do so. Or, just
> support the firmware being 100% compiled in- but when I tried this the
> last time I ran out of some firmware arena size preventing other
> firmware for other chipsets from being loaded.
> 
> Otherwise this is the current hack. :)

It’s ok (better than nothing)!

Could you please write up bugs with your findings?

Thanks so much!
-Ngie
___
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: iwm not in GENERIC kernel

[Adrian Chadd]

ugh okay

So it's a chicken/egg problem.

You can't finish the device probe/attach until the firmware loads.

For iwn, you can read the chipset abilities and mac address from
EPROM/flash on the chip without the firmware being loaded, so you can
complete probe/attach before the root filesystem is mounted.

For iwm, you have to load the firmware before you can read the chipset
abilities and MAC address so you can't complete probe/attach until
AFTER the root filesystem is mounted.

If someone wants to go add all of that support in to have probe/attach
deferred until after rootfs is available then please do so. Or, just
support the firmware being 100% compiled in- but when I tried this the
last time I ran out of some firmware arena size preventing other
firmware for other chipsets from being loaded.

Otherwise this is the current hack. :)

Sorry!



-adrian
___
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: watchdog timeout problem

[YongHyeon PYUN]

On Thu, Nov 02, 2017 at 10:13:15AM -0400, Ernie Luzar wrote:
> Posted this 10/31/2017  got no reply.
> 
> Been getting these error messages since about release 10.0 I think.
> Have changed to new hardware box and new cable modem and still having
> the same error messages. Also occurs when I use em0 interface to connect 
> to the public internet instead of vge0.
> 
> vge0: flags=8843
> metric 0 mtu 1500
>   options=389b WOL_UCAST,WOL_MCAST,WOL_MAGIC>
>   ether 00:0b:db:19:33:18
>   hwaddr 10:00:60:21:00:93
>   inet xxx.xxx.xxx.xxx netmask 0xf000
> broadcast 255.255.255.255
>   nd6 options=29
>   media: Ethernet autoselect (1000baseT )
>   status: active
> 
> 
> 
> Oct 30 23:43:38 fbsd kernel: vge0: watchdog timeout
> Oct 30 23:43:38 fbsd kernel: vge0: link state changed to DOWN
> Oct 30 23:43:42 fbsd kernel: vge0: link state changed to UP

[...]

Would you show me the output of dmesg?

> 
> 11/2/2017 posting this now as a update
> 
> I have continued to research this problem.
> The "man watchdog" says that the command,
> watchdog -d  will provide debugging info, and
> watchdog -t  will set a new timeout timer value
> 
> When I issue either of those commands I get this error message
> watchdog: patting the dog: Operation not supported
> 
> The man page also says a value of -t 0  disables the watchdog function.
> 
> Issuing "watchdog -t 0" does not get that above error message, but the 
> watchdog function is still enabled because I am still getting the
> 
>  kernel: vge0: watchdog timeout
>  kernel: vge0: link state changed to DOWN
>  kernel: vge0: link state changed to UP
> 
> messages.
> 

The watchdog timeout message is generated when vge(4) didn't see
transmit completion interrupts.  It has nothing to do with
watchdog(8) or watchdog(4). 
___
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: r325250: panics on USB stick insert

[Hans Petter Selasky]

On 11/02/17 15:19, Poul-Henning Kamp wrote:

I updated to r325250M amd64 last night, and now my laptop panics in
geom when I plug my mobile phone in.

I'll try to get a panic message when I'm in less of a hurry...



This is likely GEOM related and not USB related. There are no recent 
changes in sys/dev/usb !


--HPS
___
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"

r325250: panics on USB stick insert

[Poul-Henning Kamp]

I updated to r325250M amd64 last night, and now my laptop panics in
geom when I plug my mobile phone in.

I'll try to get a panic message when I'm in less of a hurry...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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"

watchdog timeout problem

[Ernie Luzar]

Posted this 10/31/2017  got no reply.

Been getting these error messages since about release 10.0 I think.
Have changed to new hardware box and new cable modem and still having
the same error messages. Also occurs when I use em0 interface to connect 
to the public internet instead of vge0.


vge0: flags=8843
metric 0 mtu 1500
options=389b
ether 00:0b:db:19:33:18
hwaddr 10:00:60:21:00:93
inet xxx.xxx.xxx.xxx netmask 0xf000
broadcast 255.255.255.255
nd6 options=29
media: Ethernet autoselect (1000baseT )
status: active



Oct 30 23:43:38 fbsd kernel: vge0: watchdog timeout
Oct 30 23:43:38 fbsd kernel: vge0: link state changed to DOWN
Oct 30 23:43:42 fbsd kernel: vge0: link state changed to UP
Oct 30 23:58:39 fbsd kernel: vge0: watchdog timeout
Oct 30 23:58:39 fbsd kernel: vge0: link state changed to DOWN
Oct 30 23:58:43 fbsd kernel: vge0: link state changed to UP
Oct 31 01:08:38 fbsd kernel: vge0: watchdog timeout
Oct 31 01:08:38 fbsd kernel: vge0: link state changed to DOWN
Oct 31 01:08:42 fbsd kernel: vge0: link state changed to UP
Oct 31 01:53:39 fbsd kernel: vge0: watchdog timeout
Oct 31 01:53:39 fbsd kernel: vge0: link state changed to DOWN
Oct 31 01:53:43 fbsd kernel: vge0: link state changed to UPdob
Oct 31 04:58:46 fbsd kernel: vge0: watchdog timeout
Oct 31 04:58:46 fbsd kernel: vge0: link state changed to DOWN
Oct 31 04:58:50 fbsd kernel: vge0: link state changed to UP
Oct 31 05:23:49 fbsd kernel: vge0: watchdog timeout
Oct 31 05:23:49 fbsd kernel: vge0: link state changed to DOWN
Oct 31 05:23:52 fbsd kernel: vge0: link state changed to UP
Oct 31 05:57:40 fbsd kernel: vge0: watchdog timeout
Oct 31 05:57:40 fbsd kernel: vge0: link state changed to DOWN
Oct 31 05:57:43 fbsd kernel: vge0: link state changed to UP
Oct 31 09:21:43 fbsd kernel: vge0: watchdog timeout
Oct 31 09:21:43 fbsd kernel: vge0: link state changed to DOWN
Oct 31 09:21:47 fbsd kernel: vge0: link state changed to UP
Oct 31 09:28:21 fbsd kernel: vge0: watchdog timeout
Oct 31 09:28:21 fbsd kernel: vge0: link state changed to DOWN
Oct 31 09:28:25 fbsd kernel: vge0: link state changed to UP


11/2/2017 posting this now as a update

I have continued to research this problem.
The "man watchdog" says that the command,
watchdog -d  will provide debugging info, and
watchdog -t  will set a new timeout timer value

When I issue either of those commands I get this error message
watchdog: patting the dog: Operation not supported

The man page also says a value of -t 0  disables the watchdog function.

Issuing "watchdog -t 0" does not get that above error message, but the 
watchdog function is still enabled because I am still getting the


 kernel: vge0: watchdog timeout
 kernel: vge0: link state changed to DOWN
 kernel: vge0: link state changed to UP

messages.

Production box is running RELEASE AMD64 11.1 and has 16 MB memory, with 
2 Gigabit interface cards em0 & vge0.


Development box is running RELEASE i386 11.1 beta 1 and has 2 MB memory, 
with 2 100bps interface cards rl0 & xl0.


The 2 boxes are desktops manufactured by 2 different name brand 
companies.  Both computers run the same host services. Both computers 
experience the same watchdog problems.


This watchdog problem is also present in RELEASE 11.0 and if my memory 
is correct also occurred in the 10.x series.


I never paid attention to this problem until lately when I am now 
streaming HULU and the show stops because the internet connection is 
lost due to the link state being reset by watchdog. Now this problem is 
really a problem that is impacting me.


Can't see how this could be a configuration problem on my part. That is 
why I am posting here before I post a bug report.


Watchdog is in the kernel and debugging the kernel is way outside my 
abilities. Trying to get this problem in front of the correct audience.




___
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: Booting native 4K SSD disk from FreeBSD ?

[Toomas Soome]

With r325310, the UEFI boot with CURRENT should be ok with >512B sectors. The 
BIOS part is still work in the process.

rgds,
toomas


> On 4 Oct 2017, at 19:32, Allan Jude  wrote:
> 
> On 2017-10-04 05:27, Thomas Mueller wrote:
>> from Allan Jude:
>> 
 Anyone has any recommendations or experience about how to use native 4K
 disks with FreeBSD?
>> 
 --HPS
>> 
>>> It is not possible in legacy/BIOS mode, because the BIOS calls do not
>>> let you specify a sector size.
>> 
>>> However, you SHOULD be able to boot from the 4k device using UEFI.
>>> I am trying to debug a problem I am having with this on my new Mac,
>>> which has a 4k NVMe disk.
>> 
>> I've been trying to figure how to boot a FreeBSD system with UEFI as opposed 
>> to BIOS-style.
>> 
>> I read the documentation, but want to boot a partition that might not be the 
>> first BSD partition on the hard disk.
>> 
>> For instance, some UFS partitions might have a NetBSD installation, a 
>> different FreeBSD installation, or no OS installation.
>> 
>> I read the man page (uefi) and looked at the files in /boot; have an EFI 
>> partition set up with more than enough space.
>> 
>> I would also want to be able to boot other UEFI-capable OSes including 
>> Linux, NetBSD (if that works), and Haiku when and if possible. 
>> 
>> 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"
>> 
> 
> In this case, You likely want to install a tool like rEFInd, which will
> draw a menu of all of the installed OSes and let you pick.
> 
> I use this in two of my laptops, one dual boots freebsd and windows, and
> the other OS X and FreeBSD on my macbook pro
> 
> -- 
> Allan Jude
> ___
> 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: panic: vtopde on a uva/gpa 0x1030000 @r325228 (amd64)

[O. Hartmann]

On Wed, 1 Nov 2017 10:12:59 +0200
Andriy Gapon  wrote:

> On 01/11/2017 09:33, O. Hartmann wrote:
> > I have the same (or similar) probleme here on two boxes now, maybe more to
> > come as I start updating CURRENT cyclic.
> > 
> > Reverting r325227 solves to problem for now.  
> 
> Oliver,
> 
> David and I have been working on this and a fix is coming soon.
> Sorry for the trouble and thanks for the report.
> 

Everything is all right, the exclusion of r325227 helped over the problem and I
do not see any problems after the recent patch. Thanks for the fast repair. No
trouble induced, so far (old kernel ran perfectly).

Kind regards,
Oliver
___
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"