Re: 10.0-BETA1 i386 on VirtualBox
On Tue, Nov 05, 2013 at 09:02:22AM +0200, Konstantin Belousov wrote: K> First, all reported instances have ata attachment for the ada0, except K> of milu (possibly). So this means that kernel does transient remapping, K> and very different code path is executed comparing with what I thought K> initially. The path is simpler than the pure unmapped i/o. K> K> Second, I use QEMU with the ata0 attachment for the disks regularly, and K> I do not have an issue. I also did not see a report from the real h/w. K> K> Third point is that all reports are i386. Is there anybody with amd64, K> vbox, ata and the same corruption hiddent by disabling unmapped i/o ? K> K> In what way the non-working images were installed ? Is it possible to K> produce the problematic installs by doing it one way, and non-problematic K> by another ? The only known way to get FreeBSD working is to turn off unmapped io in loader. Any tweaking of "hardware" in VB or changes in the install process do not affect. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10.0-BETA1 i386 on VirtualBox
On Mon, Nov 04, 2013 at 08:53:41PM +0400, Gleb Smirnoff wrote: > On Mon, Nov 04, 2013 at 06:38:25PM +0200, Konstantin Belousov wrote: > K> Also please show me the CPU features banner from the boot in the VB, > K> like this: > > I have already collected them all. See attaches. > > Legend: > > dmesg.bb pwd_mkdb crashes during install > dmesg.milu.pngpwd_mkdb crashes during install > dmesg.think installation succeeds, but world build crashes instantly > dmesg.ru all works > dmesg.morannonall works First, all reported instances have ata attachment for the ada0, except of milu (possibly). So this means that kernel does transient remapping, and very different code path is executed comparing with what I thought initially. The path is simpler than the pure unmapped i/o. Second, I use QEMU with the ata0 attachment for the disks regularly, and I do not have an issue. I also did not see a report from the real h/w. Third point is that all reports are i386. Is there anybody with amd64, vbox, ata and the same corruption hiddent by disabling unmapped i/o ? In what way the non-working images were installed ? Is it possible to produce the problematic installs by doing it one way, and non-problematic by another ? pgpqGG70LZE0H.pgp Description: PGP signature
Re: CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
On Mon, Nov 04, 2013 at 10:09:54PM -0700, Ian Lepore wrote: I> > > /usr/src/sys/dev/aic7xxx/aic7xxx.seq I> > > > make[2]: exec(aicasm) failed (No such file or directory) I> > > > *** Error code 1 I> > > > I> > > > Stop. I> > > > make[2]: stopped in /usr/obj/usr/src/sys/GENERIC I> > > > *** Error code 1 I> > > > I> > > > Stop. I> > > > make[1]: stopped in /usr/src I> > > I> > > Did you update your source and then "make buildkernel" without I> > > buildworld? If so, a "make kernel-toolchain" should create the aicasm I> > > tool and get you back on track. I> > > I> > I> > really odd as i built a kernel this morning no problem, then updated the I> > tree and went to build another kernel and got that. I> > working through it, thanks for the input.. I> > I> I> You were just unlucky that your updates bracketed my checkin that I> changed the build process for the aicasm tool so that it gets built as I> part of the toolchain rather than as part of the kernel now. Before this change, the toolchain was not required for kernel build if you aren't cross building. And now it is. This breaks the kernel build procedure documented in handbook for years, and brings a lot of discomfort to developers. Now to test a trivial change to kernel I need first to compile clang. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
On Mon, 2013-11-04 at 19:44 -0500, Outback Dingo wrote: > On Mon, Nov 4, 2013 at 7:36 PM, Ian Lepore wrote: > > > On Mon, 2013-11-04 at 19:25 -0500, Outback Dingo wrote: > > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls > > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > > > -Wmissing-include-dirs -fdiagnostics-show-option > > > -Wno-error-tautological-compare -Wno-error-empty-body > > > -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys > > > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > > > -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal > > > -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > > > -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe > > > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > > > -include opt_global.h -fno-omit-frame-pointer > > -mno-omit-leaf-frame-pointer > > > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > > > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > > > -fstack-protector /usr/src/sys/amd64/amd64/genassym.c > > > NM='nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s > > > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p > > > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q > > > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h > > > awk -f /usr/src/sys/tools/acpi_quirks2h.awk > > > /usr/src/sys/dev/acpica/acpi_quirks > > > aicasm -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq > > > -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath > > > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal > > > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa > > -I/usr/src/sys/dev/cxgb > > > -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt > > > -I/usr/src/sys/cam/scsi -I/usr/src/sys/dev/aic7xxx -o aic7xxx_seq.h -r > > > aic7xxx_reg.h -p aic7xxx_reg_print.c -i > > > /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h > > /usr/src/sys/dev/aic7xxx/aic7xxx.seq > > > make[2]: exec(aicasm) failed (No such file or directory) > > > *** Error code 1 > > > > > > Stop. > > > make[2]: stopped in /usr/obj/usr/src/sys/GENERIC > > > *** Error code 1 > > > > > > Stop. > > > make[1]: stopped in /usr/src > > > > Did you update your source and then "make buildkernel" without > > buildworld? If so, a "make kernel-toolchain" should create the aicasm > > tool and get you back on track. > > > > really odd as i built a kernel this morning no problem, then updated the > tree and went to build another kernel and got that. > working through it, thanks for the input.. > You were just unlucky that your updates bracketed my checkin that changed the build process for the aicasm tool so that it gets built as part of the toolchain rather than as part of the kernel now. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-11-05 04:30:28 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 04:30:28 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 04:30:28 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-11-05 04:30:28 - cleaning the object tree TB --- 2013-11-05 04:30:28 - /usr/local/bin/svn stat /src TB --- 2013-11-05 04:30:32 - At svn revision 257658 TB --- 2013-11-05 04:30:33 - building world TB --- 2013-11-05 04:30:33 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 04:30:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 04:30:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 04:30:33 - SRCCONF=/dev/null TB --- 2013-11-05 04:30:33 - TARGET=sparc64 TB --- 2013-11-05 04:30:33 - TARGET_ARCH=sparc64 TB --- 2013-11-05 04:30:33 - TZ=UTC TB --- 2013-11-05 04:30:33 - __MAKE_CONF=/dev/null TB --- 2013-11-05 04:30:33 - cd /src TB --- 2013-11-05 04:30:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 5 04:30:40 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/sparc/sparc.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/sparc/long-double-switch.opt > optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option "-Wno-static-in-inline" *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 04:40:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 04:40:09 - ERROR: failed to build world TB --- 2013-11-05 04:40:09 - 410.42 user 96.27 system 580.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc64/powerpc
TB --- 2013-11-05 04:16:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 04:16:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 04:16:20 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-11-05 04:16:20 - cleaning the object tree TB --- 2013-11-05 04:16:20 - /usr/local/bin/svn stat /src TB --- 2013-11-05 04:16:24 - At svn revision 257658 TB --- 2013-11-05 04:16:25 - building world TB --- 2013-11-05 04:16:25 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 04:16:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 04:16:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 04:16:25 - SRCCONF=/dev/null TB --- 2013-11-05 04:16:25 - TARGET=powerpc TB --- 2013-11-05 04:16:25 - TARGET_ARCH=powerpc64 TB --- 2013-11-05 04:16:25 - TZ=UTC TB --- 2013-11-05 04:16:25 - __MAKE_CONF=/dev/null TB --- 2013-11-05 04:16:25 - cd /src TB --- 2013-11-05 04:16:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 5 04:16:32 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/rs6000.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/sysv4.opt > optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option "-Wno-static-in-inline" *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 04:30:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 04:30:28 - ERROR: failed to build world TB --- 2013-11-05 04:30:28 - 656.49 user 132.34 system 847.99 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-11-05 04:03:08 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 04:03:08 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 04:03:08 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-05 04:03:08 - cleaning the object tree TB --- 2013-11-05 04:03:08 - /usr/local/bin/svn stat /src TB --- 2013-11-05 04:03:11 - At svn revision 257658 TB --- 2013-11-05 04:03:12 - building world TB --- 2013-11-05 04:03:12 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 04:03:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 04:03:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 04:03:12 - SRCCONF=/dev/null TB --- 2013-11-05 04:03:12 - TARGET=powerpc TB --- 2013-11-05 04:03:12 - TARGET_ARCH=powerpc TB --- 2013-11-05 04:03:12 - TZ=UTC TB --- 2013-11-05 04:03:12 - __MAKE_CONF=/dev/null TB --- 2013-11-05 04:03:12 - cd /src TB --- 2013-11-05 04:03:12 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 5 04:03:19 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/rs6000.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/sysv4.opt > optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option "-Wno-static-in-inline" *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 04:16:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 04:16:20 - ERROR: failed to build world TB --- 2013-11-05 04:16:20 - 644.41 user 88.50 system 792.07 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips64/mips
TB --- 2013-11-05 03:53:33 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 03:53:33 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 03:53:33 - starting HEAD tinderbox run for mips64/mips TB --- 2013-11-05 03:53:34 - cleaning the object tree TB --- 2013-11-05 03:53:34 - /usr/local/bin/svn stat /src TB --- 2013-11-05 03:53:37 - At svn revision 257658 TB --- 2013-11-05 03:53:38 - building world TB --- 2013-11-05 03:53:38 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 03:53:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 03:53:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 03:53:38 - SRCCONF=/dev/null TB --- 2013-11-05 03:53:38 - TARGET=mips TB --- 2013-11-05 03:53:38 - TARGET_ARCH=mips64 TB --- 2013-11-05 03:53:38 - TZ=UTC TB --- 2013-11-05 03:53:38 - __MAKE_CONF=/dev/null TB --- 2013-11-05 03:53:38 - cd /src TB --- 2013-11-05 03:53:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 5 03:53:45 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/mips/mips.opt > optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O -pipe -G0 -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option "-Wno-static-in-inline" *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 04:03:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 04:03:08 - ERROR: failed to build world TB --- 2013-11-05 04:03:08 - 447.70 user 85.58 system 574.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips/mips
TB --- 2013-11-05 03:44:09 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 03:44:09 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 03:44:09 - starting HEAD tinderbox run for mips/mips TB --- 2013-11-05 03:44:09 - cleaning the object tree TB --- 2013-11-05 03:44:09 - /usr/local/bin/svn stat /src TB --- 2013-11-05 03:44:12 - At svn revision 257658 TB --- 2013-11-05 03:44:13 - building world TB --- 2013-11-05 03:44:13 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 03:44:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 03:44:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 03:44:13 - SRCCONF=/dev/null TB --- 2013-11-05 03:44:13 - TARGET=mips TB --- 2013-11-05 03:44:13 - TARGET_ARCH=mips TB --- 2013-11-05 03:44:13 - TZ=UTC TB --- 2013-11-05 03:44:13 - __MAKE_CONF=/dev/null TB --- 2013-11-05 03:44:13 - cd /src TB --- 2013-11-05 03:44:13 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 5 03:44:21 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/mips/mips.opt > optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O -pipe -G0 -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option "-Wno-static-in-inline" *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 03:53:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 03:53:33 - ERROR: failed to build world TB --- 2013-11-05 03:53:33 - 446.05 user 70.59 system 564.05 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on ia64/ia64
TB --- 2013-11-05 03:34:27 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 03:34:27 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 03:34:27 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-11-05 03:34:27 - cleaning the object tree TB --- 2013-11-05 03:34:27 - /usr/local/bin/svn stat /src TB --- 2013-11-05 03:34:31 - At svn revision 257658 TB --- 2013-11-05 03:34:32 - building world TB --- 2013-11-05 03:34:32 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 03:34:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 03:34:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 03:34:32 - SRCCONF=/dev/null TB --- 2013-11-05 03:34:32 - TARGET=ia64 TB --- 2013-11-05 03:34:32 - TARGET_ARCH=ia64 TB --- 2013-11-05 03:34:32 - TZ=UTC TB --- 2013-11-05 03:34:32 - __MAKE_CONF=/dev/null TB --- 2013-11-05 03:34:32 - cd /src TB --- 2013-11-05 03:34:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 5 03:34:39 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/ia64/ia64.opt > optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist > options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-ia64.o /src/gnu/lib/libgcc/../../../contrib/gcc/config/ia64/unwind-ia64.c cc1: error: unrecognized command line option "-Wno-static-in-inline" *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 03:44:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 03:44:09 - ERROR: failed to build world TB --- 2013-11-05 03:44:09 - 452.38 user 67.11 system 581.46 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/04/13 18:26, Thomas Mueller wrote: > Question that arises is how does the system know where to send the email, and > through what SMTP server, especially if panicmail_autosubmit="YES". The code assumes that your system knows how to deliver email. An out-of-the-box FreeBSD install has sendmail and can do this. If you don't enable panicmail_autosubmit then it also assumes you're reading or forwarding root's email -- which you should be doing anyway. > In the case of a kernel panic, wouldn't the system crash/freeze, and would it > then be able to compose an email message? The email is generated from the crashdump when the system next boots. > I use mail/mpop and mail/msmtp rather than messing with sendmail or postfix; > have multiple email accounts and inboxes. > > Now come to think of it, I don't think I ever sent an email from FreeBSD as > root, only as nonroot. Don't you get "daily run output" and "security run output" emails? > Something like panicmail ought to be ported to NetBSD pkgsrc, considering > that NetBSD seems so much more unstable and crash-prone than FreeBSD on my > hardware. Go right ahead. It's a small shell script -- might even work fine without any changes. It's BSD licensed, of course. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Automated submission of kernel panic reports: sysutils/panicmail
On Mon, Nov 4, 2013, at 20:26, Thomas Mueller wrote: > > Hi all, > > > After considerable review on freebsd-hackers (thanks dt71 and jilles!) I > > have > > now added sysutils/panicmail to the FreeBSD ports tree. If you install this > > and add > > panicmail_enable="YES" > > to your /etc/rc.conf, a panic report will be generated and sent to root@ for > > you to review and submit (via email). You can skip the reviewing step and > > submit panics automatically by setting panicmail_autosubmit="YES". > > > The panics submitted are encrypted to an RSA key which I hold in order to > > keep > > them secure in transit; and I intend to keep the raw panic reports > > confidential > > except to the minimum extent necessary for other developers to help me > > process > > the incoming reports. > > > If I receive enough panic reports to be useful, I hope to provide developers > > with aggregate statistics. This may include: > > > * regular email reports listing the "top panics", to help guide developers > > towards the most fertile areas for stability improvements; > > > * email to specific developers alerting them to recurring panics in code > > they > > maintain (especially if it becomes clear that the panic has been recently > > introduced); and > > > * guidance to re@ and secteam@ about how often a particular panic occurs if > > an errata notice is being considered > > > as well as other yet-to-be-imagined reports of a similarly aggregate and > > anonymized nature. > > > So please install the sysutils/panicmail port and enable it in rc.conf! > > This > > all depends on getting useful data, and I can't do that without your help. > > -- > > Colin Percival > > Security Officer Emeritus, FreeBSD | The power to serve > > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid > > Question that arises is how does the system know where to send the email, > and through what SMTP server, especially if panicmail_autosubmit="YES". > Every computer on the planet has the capability of being able to send email directly without an SMTP server. The only question is if the receiving end is willing to accept it, or discard it as spam. > In the case of a kernel panic, wouldn't the system crash/freeze, and > would it then be able to compose an email message? > This is all handled on the next boot after the panic. > I use mail/mpop and mail/msmtp rather than messing with sendmail or > postfix; have multiple email accounts and inboxes. > Does it provide a compatible /usr/sbin/sendmail binary? If so, it will just work^TM. > Now come to think of it, I don't think I ever sent an email from FreeBSD > as root, only as nonroot. > > Something like panicmail ought to be ported to NetBSD pkgsrc, considering > that NetBSD seems so much more unstable and crash-prone than FreeBSD on > my hardware. > I hope more projects pick this up too. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Automated submission of kernel panic reports: sysutils/panicmail
> Hi all, > After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have > now added sysutils/panicmail to the FreeBSD ports tree. If you install this > and add > panicmail_enable="YES" > to your /etc/rc.conf, a panic report will be generated and sent to root@ for > you to review and submit (via email). You can skip the reviewing step and > submit panics automatically by setting panicmail_autosubmit="YES". > The panics submitted are encrypted to an RSA key which I hold in order to keep > them secure in transit; and I intend to keep the raw panic reports > confidential > except to the minimum extent necessary for other developers to help me process > the incoming reports. > If I receive enough panic reports to be useful, I hope to provide developers > with aggregate statistics. This may include: > * regular email reports listing the "top panics", to help guide developers > towards the most fertile areas for stability improvements; > * email to specific developers alerting them to recurring panics in code they > maintain (especially if it becomes clear that the panic has been recently > introduced); and > * guidance to re@ and secteam@ about how often a particular panic occurs if > an errata notice is being considered > as well as other yet-to-be-imagined reports of a similarly aggregate and > anonymized nature. > So please install the sysutils/panicmail port and enable it in rc.conf! This > all depends on getting useful data, and I can't do that without your help. -- > Colin Percival > Security Officer Emeritus, FreeBSD | The power to serve > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid Question that arises is how does the system know where to send the email, and through what SMTP server, especially if panicmail_autosubmit="YES". In the case of a kernel panic, wouldn't the system crash/freeze, and would it then be able to compose an email message? I use mail/mpop and mail/msmtp rather than messing with sendmail or postfix; have multiple email accounts and inboxes. Now come to think of it, I don't think I ever sent an email from FreeBSD as root, only as nonroot. Something like panicmail ought to be ported to NetBSD pkgsrc, considering that NetBSD seems so much more unstable and crash-prone than FreeBSD on my hardware. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
On Mon, Nov 4, 2013 at 7:36 PM, Ian Lepore wrote: > On Mon, 2013-11-04 at 19:25 -0500, Outback Dingo wrote: > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > > -Wmissing-include-dirs -fdiagnostics-show-option > > -Wno-error-tautological-compare -Wno-error-empty-body > > -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys > > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > > -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal > > -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > > -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe > > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > > -include opt_global.h -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer > > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > > -fstack-protector /usr/src/sys/amd64/amd64/genassym.c > > NM='nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s > > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p > > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q > > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h > > awk -f /usr/src/sys/tools/acpi_quirks2h.awk > > /usr/src/sys/dev/acpica/acpi_quirks > > aicasm -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq > > -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath > > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal > > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa > -I/usr/src/sys/dev/cxgb > > -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt > > -I/usr/src/sys/cam/scsi -I/usr/src/sys/dev/aic7xxx -o aic7xxx_seq.h -r > > aic7xxx_reg.h -p aic7xxx_reg_print.c -i > > /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h > /usr/src/sys/dev/aic7xxx/aic7xxx.seq > > make[2]: exec(aicasm) failed (No such file or directory) > > *** Error code 1 > > > > Stop. > > make[2]: stopped in /usr/obj/usr/src/sys/GENERIC > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/src > > Did you update your source and then "make buildkernel" without > buildworld? If so, a "make kernel-toolchain" should create the aicasm > tool and get you back on track. > really odd as i built a kernel this morning no problem, then updated the tree and went to build another kernel and got that. working through it, thanks for the input.. > > -- Ian > > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
On Mon, 2013-11-04 at 19:25 -0500, Outback Dingo wrote: > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal > -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector /usr/src/sys/amd64/amd64/genassym.c > NM='nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h > awk -f /usr/src/sys/tools/acpi_quirks2h.awk > /usr/src/sys/dev/acpica/acpi_quirks > aicasm -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb > -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt > -I/usr/src/sys/cam/scsi -I/usr/src/sys/dev/aic7xxx -o aic7xxx_seq.h -r > aic7xxx_reg.h -p aic7xxx_reg_print.c -i > /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h /usr/src/sys/dev/aic7xxx/aic7xxx.seq > make[2]: exec(aicasm) failed (No such file or directory) > *** Error code 1 > > Stop. > make[2]: stopped in /usr/obj/usr/src/sys/GENERIC > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src Did you update your source and then "make buildkernel" without buildworld? If so, a "make kernel-toolchain" should create the aicasm tool and get you back on track. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/amd64/amd64/genassym.c NM='nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h awk -f /usr/src/sys/tools/acpi_quirks2h.awk /usr/src/sys/dev/acpica/acpi_quirks aicasm -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -I/usr/src/sys/cam/scsi -I/usr/src/sys/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h /usr/src/sys/dev/aic7xxx/aic7xxx.seq make[2]: exec(aicasm) failed (No such file or directory) *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 4, 2013, at 2:43 PM, Kurt Lidl wrote: >> On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: >>> On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin >>> wrote: >>> Hi all, >>> >>> Here's a chance to test out the kernel selection menu enhancements >>> to the boot loader menu before they go into HEAD. >>> >>> Discussion welcome, feedback desired. >>> >>> No recompile needed, just drop the new forth files onto a HEAD or >>> stable/9 box and reboot. >>> -- >>> Cheers, >>> Devin >>> >>> where are the forth files in question? >>> >> >> D'Oh! >> >> Here they are: >> >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ >> >> Supplied as patches to either stable/9 or head. >> -- >> Devin > > Hmmm. I saw no appreciable changes to behavior when I patched all > the files in /boot with these versions. This was on a sparc64 host > running 10-BETA3 (compile this morning). > Excellent! Thank you for testing. NB: That's what *should* happen on sparc64 since that architecture doesn't actually enable the beastie menu (sad, I know... I wish that the beastie menu was active on all platforms by default). > Notably, the kernel and modules still loaded before presenting me > with the option to tell it which kernel to load: > > Executing last command: boot /pci@1f,0/pci@1/scsi@8/disk@0,0:a > Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0:a File and args: > > >> FreeBSD/sparc64 ZFS boot block > Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a > Consoles: Open Firmware console > \ > FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 > (r...@snap.freebsd.org, Sun Oct 27 07:20:42 UTC 2013) > bootpath="zfs:sys/ROOT/default:" > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x8d54c0+0x66180 syms=[0x8+0x954f0+0x8+0x8d7ef] > /boot/kernel/zfs.ko text=0x223328 data=0xa4e0+0x17fc0 > syms=[0x8+0x197b8+0x8+0x143f8] > loading required module 'opensolaris' > /boot/kernel/opensolaris.ko text=0x3130 data=0x2c8+0x2030 > syms=[0x8+0xd98+0x8+0x929] > /boot/kernel/geom_mirror.ko text=0x38430 data=0x5b0+0x20 > syms=[0x8+0x16b0+0x8+0x119e] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel] in 9 seconds... > You can try enabling the beastie menu on sparc64 by editing /boot/loader.rc: === Change #1 in /boot/loader.rc to enable beastie menu === Find: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu start Change "start" to "initialize" as shown below: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu initialize === Change #2 in [same file] to enable beastie menu === Find: \ Uncomment to enable boot menu \ include /boot/beastie.4th \ beastie-start Uncomment "beastie-start" as shown below: \ Uncomment to enable boot menu \ include /boot/beastie.4th beastie-start == If you find that making those two trivial changes, that you are able to load the menu... then maybe it's time for us to start thinking about enabling the beastie menu by-default for the sparc64 architecture. Does anybody else have any thoughts on enabling it for sparc64? -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: newcons comming
On Mon, Nov 04, 2013 at 10:30:39AM -0500, Ed Maste wrote: | On 4 November 2013 02:16, Kevin Oberman wrote: | > Excellent news. I'm really looking forward to newcons. Guess it's time to | > move my T520 to 10-Stable (or Beta) | | I'm running a Newcons kernel on my Thinkpad X220 now and it's working | well, with a few minor quirks. This is with the X-related packages | rebuilt with WITH_NEW_XORG= and WITH_KMS= in /etc/make.conf. | | > Are you booting directly to X or using startx from the console? In either | > case, I think that i915kms should auto-load at the start of X, so you | > should not need to pre-load it. | | I log in and running startx. i915kms does auto-load. | | > Does newcons require VESA? If not, you should be able to remove it from | > your kernel to get suspend/resume working from X. | | It does not use VESA - it's removed from GENERIC on the newcons | branch. Suspend and resume generally works on my X220 now, from X or | console. There are some outstanding issues, for example the X display | sometimes ends up corrupted after resume; stopping and restarting X | fixes that. Adding vidcontrol -s 1 < /dev/ttyv0 to /etc/rc.suspend and vidcontrol -s 9 < /dev/ttyv0 to /etc/rc.resume fixed that for me. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (r257598) panic: Assertion tmp->tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On 2013-11-04 11:27, Konstantin Belousov wrote:
On Mon, Nov 04, 2013 at 10:43:06AM -0600, Bryan Drewery wrote:
On 2013-11-04 10:27, Konstantin Belousov wrote:
> On Mon, Nov 04, 2013 at 08:35:17AM -0600, Bryan Drewery wrote:
>> 11.0-CURRENT #87 r257598
>>
>> During a poudriere build.
>>
>> It creates a tmpfs, builds a port in a jail using that tmpfs and then
>> removes the tmpfs and recreate the tmpfs before building the next
>> port.
>>
>> > panic: Assertion tmp->tm_pages_used == 0 failed at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
>> > cpuid = 9
>> > KDB: stack backtrace:
>> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe1247ee57a0
>> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850
>> > vpanic() at vpanic+0x126/frame 0xfe1247ee5890
>> > kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900
>> > tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930
>> > dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0
>> > sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0
>> > amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0
>> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0
>> > --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp =
0x7fffd198, rbp = 0x7fffd2b0 ---
>> > Uptime: 44m40s
>>
>> > (kgdb) #0 doadump (textdump=1) at pcpu.h:219
>> > #1 0x808bcf87 in kern_reboot (howto=260)
>> > at /usr/src/sys/kern/kern_shutdown.c:447
>> > #2 0x808bd495 in vpanic (fmt=,
>> > ap=) at /usr/src/sys/kern/kern_shutdown.c:754
>> > #3 0x808bd326 in kassert_panic (fmt=)
>> > at /usr/src/sys/kern/kern_shutdown.c:642
>> > #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
>> > mntflags=)
>> > at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
>> > #5 0x8095e1af in dounmount (mp=0xf810502cd660,
flags=134742016,
>> > td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324
>> > #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490,
>> > uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212
>> > #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0)
>> > at subr_syscall.c:134
>> > #8 0x80c9c90b in Xfast_syscall ()
>> > at /usr/src/sys/amd64/amd64/exception.S:391
>> > #9 0x0008008a02fa in ?? ()
>
> Do you have core ?
> I want to see the struct tmpfs_mount content for the tmpfs mount point
> which caused the panic.
Yes.
Hopefully this is what you're asking for:
(kgdb) frame
#4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
mntflags=) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
316 MPASS(tmp->tm_pages_used == 0);
(kgdb) print *mp
$2 = {mnt_mtx = {lock_object = {lo_name = 0x80f11f09 "struct
mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness =
0xfe6d3b00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = {tqe_next
=
0xf8116be06660, tqe_prev = 0xf81050257688}, mnt_op =
0x81e1b940, mnt_vfc = 0x81e1ba60, mnt_vnodecovered =
0xf8104fb0c3b0,
mnt_syncer = 0x0, mnt_ref = 1, mnt_nvnodelist = {tqh_first = 0x0,
tqh_last = 0xf810502cd6c0}, mnt_nvnodelistsize = 0,
mnt_activevnodelist = {tqh_first = 0x0, tqh_last =
0xf810502cd6d8},
mnt_activevnodelistsize = 0, mnt_writeopcount = 1, mnt_kern_flag =
16777225, mnt_flag = 4096, mnt_opt = 0xf80014424ae0, mnt_optnew =
0x0, mnt_maxsymlinklen = 0,
mnt_stat = {f_version = 537068824, f_type = 135, f_flags = 4096,
f_bsize = 4096, f_iosize = 4096, f_blocks = 17125058, f_bfree =
17049291, f_bavail = 17049291, f_files = 2147483647, f_ffree =
2147473906, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0,
f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax
=
255, f_owner = 0, f_fsid = {
val = {-2029977679, 135}}, f_charspare = '\0' times>,
f_fstypename = "tmpfs\000\000\000\000\000\000\000\000\000\000",
f_mntfromname = "tmpfs", '\0' , f_mntonname =
"/poudriere/data/build/exp-91amd64-default-xzibition/08/usr/local",
'\0'
}, mnt_cred = 0xf8001418e100, mnt_data =
0xf80fedf75700,
mnt_time = 0, mnt_iosize_max = 65536, mnt_export = 0x0, mnt_label =
0x0, mnt_hashseed = 4132690418, mnt_lockref = 0, mnt_secondary_writes
=
0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_gjprovider =
0x0, mnt_explock = {lock_object = {lo_name = 0x80f11f1a
"explock", lo_flags = 108199936, lo_data = 0, lo_witness =
0xfe6eb280},
lk_lock = 1, lk_exslpfail = 0, lk_timo = 0, lk_pri = 96},
mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers =
{tqh_first = 0x0, tqh_last = 0xf810502cd980}}
(kgdb) print *(struct tmpfs_mount *)(mp)->mnt_data
$3 = {tm_pages_max = 18446744073709551615, tm_pages_used =
18446744073709551615, tm_root = 0xf8104ff44828, tm_nodes_max =
2147483647, tm_ino_unr = 0xf8002fd65080, tm_nodes_inuse = 0,
tm_maxfilesize = 9223372
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin wrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. -- Devin Hmmm. I saw no appreciable changes to behavior when I patched all the files in /boot with these versions. This was on a sparc64 host running 10-BETA3 (compile this morning). Notably, the kernel and modules still loaded before presenting me with the option to tell it which kernel to load: Executing last command: boot /pci@1f,0/pci@1/scsi@8/disk@0,0:a Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0:a File and args: >> FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console \ FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 (r...@snap.freebsd.org, Sun Oct 27 07:20:42 UTC 2013) bootpath="zfs:sys/ROOT/default:" Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x8d54c0+0x66180 syms=[0x8+0x954f0+0x8+0x8d7ef] /boot/kernel/zfs.ko text=0x223328 data=0xa4e0+0x17fc0 syms=[0x8+0x197b8+0x8+0x143f8] loading required module 'opensolaris' /boot/kernel/opensolaris.ko text=0x3130 data=0x2c8+0x2030 syms=[0x8+0xd98+0x8+0x929] /boot/kernel/geom_mirror.ko text=0x38430 data=0x5b0+0x20 syms=[0x8+0x16b0+0x8+0x119e] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... -Kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/04/13 04:49, Alfred Perlstein wrote: > Colin, have you had a few minutes to check out the crash reporting facilities > in > FreeNAS? Yes. > The reason I ask is that: > > 1) we would like to share code. > 2) we have this running for a few months now and have a huge corpus of > information. > 3) we are building a nice UI (screenshots attached) over it, we have a couple > of > thousands of lines of code we can share for this. Once I have a useful number of panics collected, I was hoping to take the best pieces from FreeNAS's processing, from the SoC project, and from the processing I've been doing of automatic panic reports from EC2 instances. > We send a minimal set of information: kernel stack trace, ddb buffer and > hardware. Just enough to get some very, very handy stuff. I'm currently sending the dump header and what I get from kgdb 'bt'. If I find that I'm missing something important, I can always add it to a new version of the panicmail port. ;-) > I can share with you offline the crash server code, it's django and relatively > straight forward. I'll come back to you about this once I have some data. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/04/13 10:49, d...@gmx.com wrote: > Colin Percival wrote, On 11/04/2013 11:41: >> After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have >> now added sysutils/panicmail to the FreeBSD ports tree. > > The pkesh script is probably still in need of a big review (S00N(TM)...). Go for it! It's a very simple script. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Automated submission of kernel panic reports: sysutils/panicmail
Colin Percival wrote, On 11/04/2013 11:41: After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. The pkesh script is probably still in need of a big review (S00N(TM)...). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Using a swap file
On Thu, Oct 31, 2013 at 5:05 AM, Hiroki Sato wrote: > Rostislav Krasny wrote > in : > > ro> But I have no 'late' option in my /etc/fstab: > ro> > ro> root@saturn:~ # cat /etc/fstab > ro> # DeviceMountpointFStypeOptionsDumpPass# > ro> /dev/ada0s2a/ufsrw11 > ro> mdnoneswapsw,file=/swapfile00 > ro> > ro> Then why 'swapon -a' (without -L) doesn't work? It's either buggy or > confusing. > > After r255265 the option file= implies late. It is because a > file-backed swap space likely to be on a mounted filesystem after the > "swap" line. > > I realized that that assumption was odd and confusing as you pointed > out. The user should specify a swap line with file= after the mount > entry, and there is no problem with it. I will fix it. Hope to see the fix in the upcoming 10.0 release and in the Handbook. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (r257598) panic: Assertion tmp->tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On Mon, Nov 04, 2013 at 10:43:06AM -0600, Bryan Drewery wrote:
> On 2013-11-04 10:27, Konstantin Belousov wrote:
> > On Mon, Nov 04, 2013 at 08:35:17AM -0600, Bryan Drewery wrote:
> >> 11.0-CURRENT #87 r257598
> >>
> >> During a poudriere build.
> >>
> >> It creates a tmpfs, builds a port in a jail using that tmpfs and then
> >> removes the tmpfs and recreate the tmpfs before building the next
> >> port.
> >>
> >> > panic: Assertion tmp->tm_pages_used == 0 failed at
> >> > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
> >> > cpuid = 9
> >> > KDB: stack backtrace:
> >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> >> > 0xfe1247ee57a0
> >> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850
> >> > vpanic() at vpanic+0x126/frame 0xfe1247ee5890
> >> > kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900
> >> > tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930
> >> > dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0
> >> > sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0
> >> > amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0
> >> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0
> >> > --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp =
> >> > 0x7fffd198, rbp = 0x7fffd2b0 ---
> >> > Uptime: 44m40s
> >>
> >> > (kgdb) #0 doadump (textdump=1) at pcpu.h:219
> >> > #1 0x808bcf87 in kern_reboot (howto=260)
> >> > at /usr/src/sys/kern/kern_shutdown.c:447
> >> > #2 0x808bd495 in vpanic (fmt=,
> >> > ap=) at /usr/src/sys/kern/kern_shutdown.c:754
> >> > #3 0x808bd326 in kassert_panic (fmt=)
> >> > at /usr/src/sys/kern/kern_shutdown.c:642
> >> > #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
> >> > mntflags=)
> >> > at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
> >> > #5 0x8095e1af in dounmount (mp=0xf810502cd660,
> >> > flags=134742016,
> >> > td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324
> >> > #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490,
> >> > uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212
> >> > #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0)
> >> > at subr_syscall.c:134
> >> > #8 0x80c9c90b in Xfast_syscall ()
> >> > at /usr/src/sys/amd64/amd64/exception.S:391
> >> > #9 0x0008008a02fa in ?? ()
> >
> > Do you have core ?
> > I want to see the struct tmpfs_mount content for the tmpfs mount point
> > which caused the panic.
>
> Yes.
>
> Hopefully this is what you're asking for:
>
> (kgdb) frame
> #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
> mntflags=) at
> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
> 316 MPASS(tmp->tm_pages_used == 0);
>
> (kgdb) print *mp
> $2 = {mnt_mtx = {lock_object = {lo_name = 0x80f11f09 "struct
> mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness =
> 0xfe6d3b00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = {tqe_next =
> 0xf8116be06660, tqe_prev = 0xf81050257688}, mnt_op =
> 0x81e1b940, mnt_vfc = 0x81e1ba60, mnt_vnodecovered =
> 0xf8104fb0c3b0,
>mnt_syncer = 0x0, mnt_ref = 1, mnt_nvnodelist = {tqh_first = 0x0,
> tqh_last = 0xf810502cd6c0}, mnt_nvnodelistsize = 0,
> mnt_activevnodelist = {tqh_first = 0x0, tqh_last = 0xf810502cd6d8},
> mnt_activevnodelistsize = 0, mnt_writeopcount = 1, mnt_kern_flag =
> 16777225, mnt_flag = 4096, mnt_opt = 0xf80014424ae0, mnt_optnew =
> 0x0, mnt_maxsymlinklen = 0,
>mnt_stat = {f_version = 537068824, f_type = 135, f_flags = 4096,
> f_bsize = 4096, f_iosize = 4096, f_blocks = 17125058, f_bfree =
> 17049291, f_bavail = 17049291, f_files = 2147483647, f_ffree =
> 2147473906, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0,
> f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax =
> 255, f_owner = 0, f_fsid = {
>val = {-2029977679, 135}}, f_charspare = '\0' ,
> f_fstypename = "tmpfs\000\000\000\000\000\000\000\000\000\000",
> f_mntfromname = "tmpfs", '\0' , f_mntonname =
> "/poudriere/data/build/exp-91amd64-default-xzibition/08/usr/local", '\0'
> }, mnt_cred = 0xf8001418e100, mnt_data =
> 0xf80fedf75700,
>mnt_time = 0, mnt_iosize_max = 65536, mnt_export = 0x0, mnt_label =
> 0x0, mnt_hashseed = 4132690418, mnt_lockref = 0, mnt_secondary_writes =
> 0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_gjprovider =
> 0x0, mnt_explock = {lock_object = {lo_name = 0x80f11f1a
> "explock", lo_flags = 108199936, lo_data = 0, lo_witness =
> 0xfe6eb280},
> lk_lock = 1, lk_exslpfail = 0, lk_timo = 0, lk_pri = 96},
> mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers =
> {tqh_first = 0x0, tqh_last = 0xf810502cd980}}
>
> (kgdb) print *(struct tmpfs_mount *)(mp)->mnt_data
> $3 = {tm_pages_max = 1844674
Re: newcons comming
On Sun, Nov 03, 2013 at 11:16:53PM -0800, Kevin Oberman wrote: |On Thu, Oct 31, 2013 at 2:01 PM, Doug Ambrisko |wrote: | | On Fri, Oct 25, 2013 at 03:18:47PM +0300, Aleksandr Rybalko wrote: | | Hello fellow hackers! | | | | I finally reach the point when I can work with newcons instead of | | syscons on my laptop. Yes, I know it still buggy and have a lot of | | style(9) problems. But we really have to get it into HEAD and 10.0 to | | enable shiny new Xorg features, drivers, etc. | | I built the kernel from: | A A A A base/user/ed/newcons/ | and installed it on my new ThinkPad T530 with Intel graphics chip. | In general it works better since now syspend and resume works with | and without X. A However, as with my prior ThinkPads I need to switch | out of X to suspend and resume. A So I have vidcontrol -s 1 in my | /etc/rc.suspend and vidcontrol -s 9 in /etc/rc.resume. A If I don't | the display ends up corrupted but somewhat working. | | I had to kldload i915kms in /etc/rc.local since having it there at | boot via /boot/loader.conf resulted in the system not booting. A I need | i915kms for X so I don't need to use vesa mode. | | The FreeBSD logo on boot is interesting but I'd prefer seeing | FreeBSD boot messages to see what is happening. A I'm not sure if | there is a flag to disable that since I have played with it much. | | However, on a whole it is much improved since with i915kms and | newcons when in X via vesa I couldn't switch to a non-X display | since it was blank. | |Excellent news. I'm really looking forward to newcons. Guess it's time to |move my T520 to 10-Stable (or Beta) |. |Since I'm not running 10, I may simply be clueless. If so, please ignore |the rest of this. Newcons isn't in 10 yet but in its own branch. |Are you booting directly to X or using startx from the console? In either |case, I think that i915kms should auto-load at the start of X, so you |should not need to pre-load it. I use XDM to start X. Auto load might not quite work for me since I run X in a vimage jail. I find it easier to keep my base system a minimal install to start up a bounch of vimage jails. I have two "mains" that are FreeBSD -current that I leap frog and then have a couple of -stable release (ie. 9.0 and 9.2 now) that I use to build ports. I nulls mount the /var/db/pkg, /usr/local and /usr/ports of that release between those so my ports tend to be fixed in time. I have some patches to jail to allow any sysctls and to set what the OS reports for uname etc. Then pkg_add, ports builds thinks it is running on that version of FreeBSD (ie. 9.2 release). This makes it easier for me to run -current and let me add things without issue later on trying to add something new. I do have to build modules outside so it is in sync. with my base OS. |Does newcons require VESA? If not, you should be able to remove it from |your kernel to get suspend/resume working from X. As soon as I went to newcons the suspend and resume started to work. I don't have vesa kldload or static in the kernel. I auto switch out of X on suspend and switch back to X on resume to ensure that on resume the X display isn't messed up (lines shifted etc.). If I don't do this then the X gets messed up. I can see stuff working on the LCD it's just messed up. Brightness seems messed up, I patched acpi_video to also set the 2nd LCD (SB.PCI0.PEG.VID.LCD0._BCM) so that works since the keys don't work. However when X comes back from resume or dpms then it is full bridgtness. So I need to figure that out. I also run into the "N" compatibility issue with the iwn 6205 that Sean did so I #ifdef'ed that out like he did. Now the 6205 works fine. My other laptop with a 5300 didn't have this issue. My only real problem right now is that this new laptop came with a defective key so I'm waiting to get that replaced and then I'll switch to it. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10.0-BETA1 i386 on VirtualBox
On Mon, Nov 04, 2013 at 06:38:25PM +0200, Konstantin Belousov wrote: K> Also please show me the CPU features banner from the boot in the VB, K> like this: I have already collected them all. See attaches. Legend: dmesg.bbpwd_mkdb crashes during install dmesg.milu.png pwd_mkdb crashes during install dmesg.think installation succeeds, but world build crashes instantly dmesg.ruall works dmesg.morannon all works -- Totus tuus, Glebius. Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-BETA2 #0 r257166: Sat Oct 26 21:52:30 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz (1727.60-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 0x6 Model = 0x17 Stepping = 10 Features=0x783fbbf Features2=0x209 real memory = 268369920 (255 MB) avail memory = 239337472 (228 MB) kbd1 at kbdmux0 random: initialized acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link2: BIOS IRQ 9 for 0.7.INTA does not match previous BIOS IRQ 10 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 vgapci0: mem 0xe000-0xe07f irq 11 at device 2.0 on pci0 em0: port 0xd010-0xd017 mem 0xf000-0xf001 irq 10 at device 3.0 on pci0 em0: Ethernet address: 08:00:27:e4:ea:db pci0: at device 4.0 (no driver attached) pcm0: port 0xd100-0xd1ff,0xd200-0xd23f irq 5 at device 5.0 on pci0 pcm0: ohci0: mem 0xf0804000-0xf0804fff irq 11 at device 6.0 on pci0 usbus0 on ohci0 pci0: at device 7.0 (no driver attached) battery0: on acpi0 acpi_acad0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 pmtimer0 on isa0 orm0: at iomem 0xc-0xc7fff,0xe2000-0xe7fff pnpid ORM on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 ppc0: parallel port not found. Timecounters tick every 10.000 msec pcm0: measured ac97 link rate at 27783 Hz usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-6 device ada0: Serial Number VB7ab20517-23848df6 ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) ada0: 4096MB (8388608 512 byte sectors: 16H 63S/T 8322C) ada0: Previously was known as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number VB2-01700376 cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [301071 x 2048 byte records] uhub0: 8 ports with 8 removable, self powered random: unblocking device. Timecounter "TSC" frequency 1727604551 Hz quality 800 Trying to mount root from cd9660:/dev/iso9660/FREEBSD_INSTALL [ro]... pid 901 (less), uid 0: exited on signal 11 pid 957 (less), uid 0: exited on signal 11 Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-BETA2 #0 r257166: Sat Oct 26 21:52:30 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (1637.34-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9 Features=0x783f3bf Features2=0x209 AMD Features=0x800 real memory = 134152192 (127 MB) avail memory = 107679744 (102 MB) kbd1 at kbdmux0 random: initialized acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link2: BIOS IRQ 9 for 0.7.INTA does not match previous BIOS
Re: (r257598) panic: Assertion tmp->tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On 2013-11-04 10:27, Konstantin Belousov wrote:
On Mon, Nov 04, 2013 at 08:35:17AM -0600, Bryan Drewery wrote:
11.0-CURRENT #87 r257598
During a poudriere build.
It creates a tmpfs, builds a port in a jail using that tmpfs and then
removes the tmpfs and recreate the tmpfs before building the next
port.
> panic: Assertion tmp->tm_pages_used == 0 failed at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
> cpuid = 9
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1247ee57a0
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850
> vpanic() at vpanic+0x126/frame 0xfe1247ee5890
> kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900
> tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930
> dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0
> sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0
> amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0
> --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp =
0x7fffd198, rbp = 0x7fffd2b0 ---
> Uptime: 44m40s
> (kgdb) #0 doadump (textdump=1) at pcpu.h:219
> #1 0x808bcf87 in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:447
> #2 0x808bd495 in vpanic (fmt=,
> ap=) at /usr/src/sys/kern/kern_shutdown.c:754
> #3 0x808bd326 in kassert_panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:642
> #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
> mntflags=)
> at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
> #5 0x8095e1af in dounmount (mp=0xf810502cd660, flags=134742016,
> td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324
> #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490,
> uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212
> #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0)
> at subr_syscall.c:134
> #8 0x80c9c90b in Xfast_syscall ()
> at /usr/src/sys/amd64/amd64/exception.S:391
> #9 0x0008008a02fa in ?? ()
Do you have core ?
I want to see the struct tmpfs_mount content for the tmpfs mount point
which caused the panic.
Yes.
Hopefully this is what you're asking for:
(kgdb) frame
#4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
mntflags=) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
316 MPASS(tmp->tm_pages_used == 0);
(kgdb) print *mp
$2 = {mnt_mtx = {lock_object = {lo_name = 0x80f11f09 "struct
mount mtx", lo_flags = 16973824, lo_data = 0, lo_witness =
0xfe6d3b00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = {tqe_next =
0xf8116be06660, tqe_prev = 0xf81050257688}, mnt_op =
0x81e1b940, mnt_vfc = 0x81e1ba60, mnt_vnodecovered =
0xf8104fb0c3b0,
mnt_syncer = 0x0, mnt_ref = 1, mnt_nvnodelist = {tqh_first = 0x0,
tqh_last = 0xf810502cd6c0}, mnt_nvnodelistsize = 0,
mnt_activevnodelist = {tqh_first = 0x0, tqh_last = 0xf810502cd6d8},
mnt_activevnodelistsize = 0, mnt_writeopcount = 1, mnt_kern_flag =
16777225, mnt_flag = 4096, mnt_opt = 0xf80014424ae0, mnt_optnew =
0x0, mnt_maxsymlinklen = 0,
mnt_stat = {f_version = 537068824, f_type = 135, f_flags = 4096,
f_bsize = 4096, f_iosize = 4096, f_blocks = 17125058, f_bfree =
17049291, f_bavail = 17049291, f_files = 2147483647, f_ffree =
2147473906, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0,
f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax =
255, f_owner = 0, f_fsid = {
val = {-2029977679, 135}}, f_charspare = '\0' ,
f_fstypename = "tmpfs\000\000\000\000\000\000\000\000\000\000",
f_mntfromname = "tmpfs", '\0' , f_mntonname =
"/poudriere/data/build/exp-91amd64-default-xzibition/08/usr/local", '\0'
}, mnt_cred = 0xf8001418e100, mnt_data =
0xf80fedf75700,
mnt_time = 0, mnt_iosize_max = 65536, mnt_export = 0x0, mnt_label =
0x0, mnt_hashseed = 4132690418, mnt_lockref = 0, mnt_secondary_writes =
0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_gjprovider =
0x0, mnt_explock = {lock_object = {lo_name = 0x80f11f1a
"explock", lo_flags = 108199936, lo_data = 0, lo_witness =
0xfe6eb280},
lk_lock = 1, lk_exslpfail = 0, lk_timo = 0, lk_pri = 96},
mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers =
{tqh_first = 0x0, tqh_last = 0xf810502cd980}}
(kgdb) print *(struct tmpfs_mount *)(mp)->mnt_data
$3 = {tm_pages_max = 18446744073709551615, tm_pages_used =
18446744073709551615, tm_root = 0xf8104ff44828, tm_nodes_max =
2147483647, tm_ino_unr = 0xf8002fd65080, tm_nodes_inuse = 0,
tm_maxfilesize = 9223372036854775807, tm_nodes_used = {lh_first = 0x0},
allnode_lock = {lock_object = {lo_name = 0x81e1aa47 "tmpfs
allnode lock",
lo_flags = 16908288, lo_data = 0, lo_witness =
0xfe6ecd80}, mtx_lock = 6}, tm_dir
Re: 10.0-BETA1 i386 on VirtualBox
On Mon, Nov 04, 2013 at 12:30:09PM +0100, Maciej Milewski wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03.11.2013 15:41, Konstantin Belousov wrote: > > On Sun, Nov 03, 2013 at 05:46:01PM +0400, Gleb Smirnoff wrote: > >> Maciej, Boris, > >> > >> On Sun, Nov 03, 2013 at 04:29:11PM +0400, Boris Bobrov wrote: > >> B> > I traced this down to r248521: > >> B> > svn log -r248521 > >> B> > > --- > >> B> > - r248521 | kib | 2013-03-19 16:08:15 +0100 (Tue, 19 Mar 2013) | 5 > >> B> > lines > >> B> > > >> B> > UFS support of the unmapped i/o for the user data buffers. > >> B> > > >> B> > Sponsored by: The FreeBSD Foundation > >> B> > Tested by: pho, scottl, jhb, bf > >> B> > > >> B> > > --- > >> B> > - > >> B> > > >> B> > The last working revision is 248520. > >> B> > >> B> Yes, I confirm that. > >> > >> Thanks for you help! > >> > >> Can you please now try unpatched vanilla 10.0-BETA2 iso file and when it > >> boots set in loader (before kernel): > >> > >> OK set vfs.unmapped_buf_allowed=0 > >> OK boot > > > > Show what disk driver is used, also show the output of hw.ncpu, both > > from the guest. > Konstantin, > do you need any other/more info from guest host? > Other than hw.ncpu=1 > Disk is > ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 > and second test instance is > ada0 at ata0 bus 0 scbus0 target 0 lun 0 So both ahci and ata attached disks show the bug ? Also please show me the CPU features banner from the boot in the VB, like this: CPU: Intel(R) Core(TM) i7-4770S CPU @ 3.10GHz (2993.13-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306c3 Family = 0x6 Model = 0x3c Stepping = 3 Features=0xbfebfbff Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800 AMD Features2=0x21 Standard Extended Features=0x2fbb TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) > > Is Gleb's loader hint the final right solution for this problem? Probably not. This smells like a bug in the vbox. It is especially suspicious that only some i/o transfers cause corruption. pgpIHt1IrS9yS.pgp Description: PGP signature
Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
On Mon, Nov 04, 2013 at 12:11:02PM +0100, Erwin Lansing wrote: E> > On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote: E> > G> > Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff : E> > G> > E> > G> > > On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote: E> > G> > > Ö> Altough bind removed from FreeBSD 10 distribution, "/etc/rc.d/named" E> > G> > script E> > G> > > Ö> still exists. E> > G> > > Ö> and this script depends on "/etc/mtree/BIND.chroot.dist" file but E> > G> > there is E> > G> > > Ö> no such file in source tree. E> > G> > > Ö> I think this file was forgotten to be removed. E> > G> > > Ö> E> > G> > > Ö> And also, named_* definitions still exists in /etc/defaults/rc.conf E> > G> > file. E> > G> > > E> > G> > > Please review attached file that removes named from /etc. E> > G> > E> > G> > It would be great if the port would learn to install its own script etc. E> > G> > in time for that change. (Unless it’s already there, and I’m just too blind E> > G> > to see it.) E> > G> E> > G> No you are not blind. Installing bind from ports still relies on the E> > G> /etc/rc.d/named script. E> > E> > Erwin, can you please handle that? E> E> Things are much worse that this, the ports are completely written under the assumption that there is a Bind in base, which of course would already break with WITHOUT_BIND before Bind was completely removed. It will be hard to fix without breaking the installed base of 8 and 9. Sigh. E> E> I'll try to work on it this week, but unfortunately have a full schedule of meetings and travel as well. What should we do with src? IMO, we should proceed with removal of remnants of bind in src. In the worst case, if you can't handle it this week, the situation will be the following: 1) 8.x, 9.x users are okay 2) 10+.x users w/o bind are okay 3) 10+.x users with bind have problems If we skip updating src, then situation would be: 1) 8.x, 9.x users are okay 2) 10+.x users w/o bind have problems 3) 10+.x users with bind are okay I think, there are less 10.x users with bind, than 10.x without it. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (r257598) panic: Assertion tmp->tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On Mon, Nov 04, 2013 at 08:35:17AM -0600, Bryan Drewery wrote: > 11.0-CURRENT #87 r257598 > > During a poudriere build. > > It creates a tmpfs, builds a port in a jail using that tmpfs and then > removes the tmpfs and recreate the tmpfs before building the next port. > > > panic: Assertion tmp->tm_pages_used == 0 failed at > > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 > > cpuid = 9 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe1247ee57a0 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850 > > vpanic() at vpanic+0x126/frame 0xfe1247ee5890 > > kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900 > > tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930 > > dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0 > > sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0 > > amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0 > > --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp = > > 0x7fffd198, rbp = 0x7fffd2b0 --- > > Uptime: 44m40s > > > (kgdb) #0 doadump (textdump=1) at pcpu.h:219 > > #1 0x808bcf87 in kern_reboot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:447 > > #2 0x808bd495 in vpanic (fmt=, > > ap=) at /usr/src/sys/kern/kern_shutdown.c:754 > > #3 0x808bd326 in kassert_panic (fmt=) > > at /usr/src/sys/kern/kern_shutdown.c:642 > > #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660, > > mntflags=) > > at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 > > #5 0x8095e1af in dounmount (mp=0xf810502cd660, flags=134742016, > > td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324 > > #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490, > > uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212 > > #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0) > > at subr_syscall.c:134 > > #8 0x80c9c90b in Xfast_syscall () > > at /usr/src/sys/amd64/amd64/exception.S:391 > > #9 0x0008008a02fa in ?? () Do you have core ? I want to see the struct tmpfs_mount content for the tmpfs mount point which caused the panic. pgpXHa9Qv8giA.pgp Description: PGP signature
Re: (r257598) panic: Assertion tmp->tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On 2013-11-04 09:35, Bryan Drewery wrote: > 11.0-CURRENT #87 r257598 > > During a poudriere build. > > It creates a tmpfs, builds a port in a jail using that tmpfs and then > removes the tmpfs and recreate the tmpfs before building the next port. > >> panic: Assertion tmp->tm_pages_used == 0 failed at >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 >> cpuid = 9 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe1247ee57a0 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850 >> vpanic() at vpanic+0x126/frame 0xfe1247ee5890 >> kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900 >> tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930 >> dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0 >> sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0 >> amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0 >> --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp = >> 0x7fffd198, rbp = 0x7fffd2b0 --- >> Uptime: 44m40s >> (kgdb) #0 doadump (textdump=1) at pcpu.h:219 >> #1 0x808bcf87 in kern_reboot (howto=260) >> at /usr/src/sys/kern/kern_shutdown.c:447 >> #2 0x808bd495 in vpanic (fmt=, >> ap=) at /usr/src/sys/kern/kern_shutdown.c:754 >> #3 0x808bd326 in kassert_panic (fmt=) >> at /usr/src/sys/kern/kern_shutdown.c:642 >> #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660, >> mntflags=) >> at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 >> #5 0x8095e1af in dounmount (mp=0xf810502cd660, flags=134742016, >> td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324 >> #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490, >> uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212 >> #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0) >> at subr_syscall.c:134 >> #8 0x80c9c90b in Xfast_syscall () >> at /usr/src/sys/amd64/amd64/exception.S:391 >> #9 0x0008008a02fa in ?? () > Not sure if it is related, but I had a similar looking panic on a 10.0-BETA1 machine after doing a zfs receive: Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x378 fault code= supervisor read data, page not present instruction pointer = 0x20:0x8089bf51 stack pointer = 0x28:0xfe1835d715d0 frame pointer = 0x28:0xfe1835d71650 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 44435 (zfs) trap number = 12 panic: page fault cpuid = 5 KDB: stack backtrace: #0 0x808e7580 at kdb_backtrace+0x60 #1 0x808af065 at panic+0x155 #2 0x80c8e292 at trap_fatal+0x3a2 #3 0x80c8e569 at trap_pfault+0x2c9 #4 0x80c8dcf6 at trap+0x5e6 #5 0x80c75022 at calltrap+0x8 #6 0x8094a32b at vflush+0x48b #7 0x8189e682 at zfs_umount+0x112 #8 0x809434f5 at dounmount+0x4b5 #9 0x80943004 at sys_unmount+0x3d4 #10 0x80c8eb87 at amd64_syscall+0x357 #11 0x80c7530b at Xfast_syscall+0xfb -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: newcons comming
On 4 November 2013 02:16, Kevin Oberman wrote: > Excellent news. I'm really looking forward to newcons. Guess it's time to > move my T520 to 10-Stable (or Beta) I'm running a Newcons kernel on my Thinkpad X220 now and it's working well, with a few minor quirks. This is with the X-related packages rebuilt with WITH_NEW_XORG= and WITH_KMS= in /etc/make.conf. > Are you booting directly to X or using startx from the console? In either > case, I think that i915kms should auto-load at the start of X, so you > should not need to pre-load it. I log in and running startx. i915kms does auto-load. > Does newcons require VESA? If not, you should be able to remove it from > your kernel to get suspend/resume working from X. It does not use VESA - it's removed from GENERIC on the newcons branch. Suspend and resume generally works on my X220 now, from X or console. There are some outstanding issues, for example the X display sometimes ends up corrupted after resume; stopping and restarting X fixes that. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
(r257598) panic: Assertion tmp->tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
11.0-CURRENT #87 r257598 During a poudriere build. It creates a tmpfs, builds a port in a jail using that tmpfs and then removes the tmpfs and recreate the tmpfs before building the next port. > panic: Assertion tmp->tm_pages_used == 0 failed at > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 > cpuid = 9 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1247ee57a0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850 > vpanic() at vpanic+0x126/frame 0xfe1247ee5890 > kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900 > tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930 > dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0 > sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0 > --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp = > 0x7fffd198, rbp = 0x7fffd2b0 --- > Uptime: 44m40s > (kgdb) #0 doadump (textdump=1) at pcpu.h:219 > #1 0x808bcf87 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:447 > #2 0x808bd495 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:754 > #3 0x808bd326 in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:642 > #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660, > mntflags=) > at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 > #5 0x8095e1af in dounmount (mp=0xf810502cd660, flags=134742016, > td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324 > #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490, > uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212 > #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0) > at subr_syscall.c:134 > #8 0x80c9c90b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:391 > #9 0x0008008a02fa in ?? () -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/4/13, 2:41 AM, Colin Percival wrote: Hi all, After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. If you install this and add panicmail_enable="YES" to your /etc/rc.conf, a panic report will be generated and sent to root@ for you to review and submit (via email). You can skip the reviewing step and submit panics automatically by setting panicmail_autosubmit="YES". The panics submitted are encrypted to an RSA key which I hold in order to keep them secure in transit; and I intend to keep the raw panic reports confidential except to the minimum extent necessary for other developers to help me process the incoming reports. If I receive enough panic reports to be useful, I hope to provide developers with aggregate statistics. This may include: * regular email reports listing the "top panics", to help guide developers towards the most fertile areas for stability improvements; * email to specific developers alerting them to recurring panics in code they maintain (especially if it becomes clear that the panic has been recently introduced); and * guidance to re@ and secteam@ about how often a particular panic occurs if an errata notice is being considered as well as other yet-to-be-imagined reports of a similarly aggregate and anonymized nature. So please install the sysutils/panicmail port and enable it in rc.conf! This all depends on getting useful data, and I can't do that without your help. Colin, have you had a few minutes to check out the crash reporting facilities in FreeNAS? The reason I ask is that: 1) we would like to share code. 2) we have this running for a few months now and have a huge corpus of information. 3) we are building a nice UI (screenshots attached) over it, we have a couple of thousands of lines of code we can share for this. Our scripts can be found here: 1) A startup script that sends us the crashes on system start: https://github.com/freenas/freenas/blob/master/nanobsd/Files/etc/rc.d/ix_textdump 2) A script to submit data at boot OR from command line that sends more comprehensive system information "ixdiagnose": https://github.com/freenas/freenas/blob/master/nanobsd/Files/usr/local/bin/ixdiagnose 3) A very simple script to upload that report: https://github.com/freenas/freenas/blob/master/nanobsd/Files/usr/local/bin/crashuploader We send a minimal set of information: kernel stack trace, ddb buffer and hardware. Just enough to get some very, very handy stuff. I can share with you offline the crash server code, it's django and relatively straight forward. The screenshots can also be seen at: http://people.freebsd.org/~alfred/crashreporter/ We could modify our framework for FreeBSD to do so by checking for a sentinel file depending on the host type and only auto-sending if we see that. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10.0-BETA1 i386 on VirtualBox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.11.2013 15:41, Konstantin Belousov wrote: > On Sun, Nov 03, 2013 at 05:46:01PM +0400, Gleb Smirnoff wrote: >> Maciej, Boris, >> >> On Sun, Nov 03, 2013 at 04:29:11PM +0400, Boris Bobrov wrote: >> B> > I traced this down to r248521: >> B> > svn log -r248521 >> B> > --- >> B> > - r248521 | kib | 2013-03-19 16:08:15 +0100 (Tue, 19 Mar 2013) | 5 >> B> > lines >> B> > >> B> > UFS support of the unmapped i/o for the user data buffers. >> B> > >> B> > Sponsored by: The FreeBSD Foundation >> B> > Tested by: pho, scottl, jhb, bf >> B> > >> B> > --- >> B> > - >> B> > >> B> > The last working revision is 248520. >> B> >> B> Yes, I confirm that. >> >> Thanks for you help! >> >> Can you please now try unpatched vanilla 10.0-BETA2 iso file and when it >> boots set in loader (before kernel): >> >> OK set vfs.unmapped_buf_allowed=0 >> OK boot > > Show what disk driver is used, also show the output of hw.ncpu, both > from the guest. Konstantin, do you need any other/more info from guest host? Other than hw.ncpu=1 Disk is ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 and second test instance is ada0 at ata0 bus 0 scbus0 target 0 lun 0 Is Gleb's loader hint the final right solution for this problem? - -- Pozdrawiam, Maciej Milewski -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ3hUEACgkQPQ1pa2ELkNl26wCdG0wsFWMxu+iN4Xig/I4lQ5pv i+gAn1OAVEvf0vXAZu4PRmr9+oEkW+jA =9+kM -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
On 04 Nov 2013, at 09:34, Gleb Smirnoff wrote: > [adding maintainer to Cc] > > On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote: > G> > Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff : > G> > > G> > > On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote: > G> > > Ö> Altough bind removed from FreeBSD 10 distribution, "/etc/rc.d/named" > G> > script > G> > > Ö> still exists. > G> > > Ö> and this script depends on "/etc/mtree/BIND.chroot.dist" file but > G> > there is > G> > > Ö> no such file in source tree. > G> > > Ö> I think this file was forgotten to be removed. > G> > > Ö> > G> > > Ö> And also, named_* definitions still exists in /etc/defaults/rc.conf > G> > file. > G> > > > G> > > Please review attached file that removes named from /etc. > G> > > G> > It would be great if the port would learn to install its own script etc. > G> > in time for that change. (Unless it’s already there, and I’m just too > blind > G> > to see it.) > G> > G> No you are not blind. Installing bind from ports still relies on the > G> /etc/rc.d/named script. > > Erwin, can you please handle that? Things are much worse that this, the ports are completely written under the assumption that there is a Bind in base, which of course would already break with WITHOUT_BIND before Bind was completely removed. It will be hard to fix without breaking the installed base of 8 and 9. Sigh. I'll try to work on it this week, but unfortunately have a full schedule of meetings and travel as well. Erwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/04/13 02:47, Bob Bishop wrote: > On 4 Nov 2013, at 10:41, Colin Percival wrote: >> After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have >> now added sysutils/panicmail to the FreeBSD ports tree. [etc] > > Nice. Is this applicable to all supported branches? Yes... the code should work all the way back to 5.0 (it's an rc.d script), although I doubt ports infrastructure will allow you to install anything from today's ports tree on a system running FreeBSD 5.0. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Automated submission of kernel panic reports: sysutils/panicmail
Hi, On 4 Nov 2013, at 10:41, Colin Percival wrote: > Hi all, > > After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have > now added sysutils/panicmail to the FreeBSD ports tree. [etc] Nice. Is this applicable to all supported branches? -- Bob Bishop r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Automated submission of kernel panic reports: sysutils/panicmail
Hi all, After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. If you install this and add panicmail_enable="YES" to your /etc/rc.conf, a panic report will be generated and sent to root@ for you to review and submit (via email). You can skip the reviewing step and submit panics automatically by setting panicmail_autosubmit="YES". The panics submitted are encrypted to an RSA key which I hold in order to keep them secure in transit; and I intend to keep the raw panic reports confidential except to the minimum extent necessary for other developers to help me process the incoming reports. If I receive enough panic reports to be useful, I hope to provide developers with aggregate statistics. This may include: * regular email reports listing the "top panics", to help guide developers towards the most fertile areas for stability improvements; * email to specific developers alerting them to recurring panics in code they maintain (especially if it becomes clear that the panic has been recently introduced); and * guidance to re@ and secteam@ about how often a particular panic occurs if an errata notice is being considered as well as other yet-to-be-imagined reports of a similarly aggregate and anonymized nature. So please install the sysutils/panicmail port and enable it in rc.conf! This all depends on getting useful data, and I can't do that without your help. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
[adding maintainer to Cc] On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote: G> > Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff : G> > G> > > On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote: G> > > Ö> Altough bind removed from FreeBSD 10 distribution, "/etc/rc.d/named" G> > script G> > > Ö> still exists. G> > > Ö> and this script depends on "/etc/mtree/BIND.chroot.dist" file but G> > there is G> > > Ö> no such file in source tree. G> > > Ö> I think this file was forgotten to be removed. G> > > Ö> G> > > Ö> And also, named_* definitions still exists in /etc/defaults/rc.conf G> > file. G> > > G> > > Please review attached file that removes named from /etc. G> > G> > It would be great if the port would learn to install its own script etc. G> > in time for that change. (Unless it’s already there, and I’m just too blind G> > to see it.) G> G> No you are not blind. Installing bind from ports still relies on the G> /etc/rc.d/named script. Erwin, can you please handle that? -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
