[head tinderbox] failure on sparc64/sparc64
TB --- 2013-02-21 09:15:47 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 09:15:47 - 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-02-21 09:15:47 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-02-21 09:15:47 - cleaning the object tree TB --- 2013-02-21 09:15:47 - /usr/local/bin/svn stat /src TB --- 2013-02-21 09:15:50 - At svn revision 247073 TB --- 2013-02-21 09:15:51 - building world TB --- 2013-02-21 09:15:51 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 09:15:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 09:15:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 09:15:51 - SRCCONF=/dev/null TB --- 2013-02-21 09:15:51 - TARGET=sparc64 TB --- 2013-02-21 09:15:51 - TARGET_ARCH=sparc64 TB --- 2013-02-21 09:15:51 - TZ=UTC TB --- 2013-02-21 09:15:51 - __MAKE_CONF=/dev/null TB --- 2013-02-21 09:15:51 - cd /src TB --- 2013-02-21 09:15:51 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 09:15:56 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 10:17:36 UTC 2013 TB --- 2013-02-21 10:17:36 - generating LINT kernel config TB --- 2013-02-21 10:17:36 - cd /src/sys/sparc64/conf TB --- 2013-02-21 10:17:36 - /usr/bin/make -B LINT TB --- 2013-02-21 10:17:36 - cd /src/sys/sparc64/conf TB --- 2013-02-21 10:17:36 - /usr/sbin/config -m LINT TB --- 2013-02-21 10:17:36 - building LINT kernel TB --- 2013-02-21 10:17:36 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 10:17:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 10:17:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 10:17:36 - SRCCONF=/dev/null TB --- 2013-02-21 10:17:36 - TARGET=sparc64 TB --- 2013-02-21 10:17:36 - TARGET_ARCH=sparc64 TB --- 2013-02-21 10:17:36 - TZ=UTC TB --- 2013-02-21 10:17:36 - __MAKE_CONF=/dev/null TB --- 2013-02-21 10:17:36 - cd /src TB --- 2013-02-21 10:17:36 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 10:17:36 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/pci/amdsmb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/pci/if_rl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/pci/intpm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-02-21 08:00:29 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 08:00:29 - 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-02-21 08:00:29 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-02-21 08:00:29 - cleaning the object tree TB --- 2013-02-21 08:00:29 - /usr/local/bin/svn stat /src TB --- 2013-02-21 08:00:32 - At svn revision 247073 TB --- 2013-02-21 08:00:33 - building world TB --- 2013-02-21 08:00:33 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 08:00:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 08:00:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 08:00:33 - SRCCONF=/dev/null TB --- 2013-02-21 08:00:33 - TARGET=powerpc TB --- 2013-02-21 08:00:33 - TARGET_ARCH=powerpc TB --- 2013-02-21 08:00:33 - TZ=UTC TB --- 2013-02-21 08:00:33 - __MAKE_CONF=/dev/null TB --- 2013-02-21 08:00:33 - cd /src TB --- 2013-02-21 08:00:33 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 08:00:38 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 10:24:38 UTC 2013 TB --- 2013-02-21 10:24:38 - generating LINT kernel config TB --- 2013-02-21 10:24:38 - cd /src/sys/powerpc/conf TB --- 2013-02-21 10:24:38 - /usr/bin/make -B LINT TB --- 2013-02-21 10:24:38 - cd /src/sys/powerpc/conf TB --- 2013-02-21 10:24:38 - /usr/sbin/config -m LINT TB --- 2013-02-21 10:24:38 - building LINT kernel TB --- 2013-02-21 10:24:38 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 10:24:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 10:24:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 10:24:38 - SRCCONF=/dev/null TB --- 2013-02-21 10:24:38 - TARGET=powerpc TB --- 2013-02-21 10:24:38 - TARGET_ARCH=powerpc TB --- 2013-02-21 10:24:38 - TZ=UTC TB --- 2013-02-21 10:24:38 - __MAKE_CONF=/dev/null TB --- 2013-02-21 10:24:38 - cd /src TB --- 2013-02-21 10:24:38 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 10:24:38 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/amdsmb.c cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/if_rl.c cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/intpm.c cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000
[head tinderbox] failure on i386/pc98
TB --- 2013-02-21 06:05:47 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 06:05:47 - 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-02-21 06:05:47 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-02-21 06:05:47 - cleaning the object tree TB --- 2013-02-21 06:05:47 - /usr/local/bin/svn stat /src TB --- 2013-02-21 06:05:53 - At svn revision 247073 TB --- 2013-02-21 06:05:54 - building world TB --- 2013-02-21 06:05:54 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 06:05:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 06:05:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 06:05:54 - SRCCONF=/dev/null TB --- 2013-02-21 06:05:54 - TARGET=pc98 TB --- 2013-02-21 06:05:54 - TARGET_ARCH=i386 TB --- 2013-02-21 06:05:54 - TZ=UTC TB --- 2013-02-21 06:05:54 - __MAKE_CONF=/dev/null TB --- 2013-02-21 06:05:54 - cd /src TB --- 2013-02-21 06:05:54 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 06:05:58 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 09:00:17 UTC 2013 TB --- 2013-02-21 09:00:17 - generating LINT kernel config TB --- 2013-02-21 09:00:17 - cd /src/sys/pc98/conf TB --- 2013-02-21 09:00:17 - /usr/bin/make -B LINT TB --- 2013-02-21 09:00:17 - cd /src/sys/pc98/conf TB --- 2013-02-21 09:00:17 - /usr/sbin/config -m LINT TB --- 2013-02-21 09:00:17 - building LINT kernel TB --- 2013-02-21 09:00:17 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 09:00:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 09:00:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 09:00:17 - SRCCONF=/dev/null TB --- 2013-02-21 09:00:17 - TARGET=pc98 TB --- 2013-02-21 09:00:17 - TARGET_ARCH=i386 TB --- 2013-02-21 09:00:17 - TZ=UTC TB --- 2013-02-21 09:00:17 - __MAKE_CONF=/dev/null TB --- 2013-02-21 09:00:17 - cd /src TB --- 2013-02-21 09:00:17 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 09:00:17 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 09:08:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 09:08:13 - ERROR: failed to build LINT kernel TB --- 2013-02-21 09:08:13 - 8612.45 user 1321.82 system 10945.53 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.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-02-21 06:17:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 06:17:25 - 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-02-21 06:17:25 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-02-21 06:17:25 - cleaning the object tree TB --- 2013-02-21 06:17:25 - /usr/local/bin/svn stat /src TB --- 2013-02-21 06:17:28 - At svn revision 247073 TB --- 2013-02-21 06:17:29 - building world TB --- 2013-02-21 06:17:29 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 06:17:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 06:17:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 06:17:29 - SRCCONF=/dev/null TB --- 2013-02-21 06:17:29 - TARGET=ia64 TB --- 2013-02-21 06:17:29 - TARGET_ARCH=ia64 TB --- 2013-02-21 06:17:29 - TZ=UTC TB --- 2013-02-21 06:17:29 - __MAKE_CONF=/dev/null TB --- 2013-02-21 06:17:29 - cd /src TB --- 2013-02-21 06:17:29 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 06:17:33 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 07:50:56 UTC 2013 TB --- 2013-02-21 07:50:56 - generating LINT kernel config TB --- 2013-02-21 07:50:56 - cd /src/sys/ia64/conf TB --- 2013-02-21 07:50:56 - /usr/bin/make -B LINT TB --- 2013-02-21 07:50:56 - cd /src/sys/ia64/conf TB --- 2013-02-21 07:50:56 - /usr/sbin/config -m LINT TB --- 2013-02-21 07:50:56 - building LINT kernel TB --- 2013-02-21 07:50:56 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 07:50:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 07:50:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 07:50:56 - SRCCONF=/dev/null TB --- 2013-02-21 07:50:56 - TARGET=ia64 TB --- 2013-02-21 07:50:56 - TARGET_ARCH=ia64 TB --- 2013-02-21 07:50:56 - TZ=UTC TB --- 2013-02-21 07:50:56 - __MAKE_CONF=/dev/null TB --- 2013-02-21 07:50:56 - cd /src TB --- 2013-02-21 07:50:56 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 07:50:56 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000
Re: Dtrace: Module is no longer loaded
Hi, On Feb 19, 2013, at 16:03, Andriy Gapon a...@freebsd.org wrote: Couple of thoughts: - is your kernel installed in the typical location? yup. - what does the following produce? readelf -a -W /boot/kernel/kernel | fgrep shstrtab readelf -a -W /boot/kernel/kernel | fgrep SUNW_ctf # readelf -a -W /boot/kernel/kernel | fgrep shstrtab [24] .shstrtab STRTAB 7975ee 000124 00 0 0 1 # readelf -a -W /boot/kernel/kernel | fgrep SUNW_ctf [22] .SUNW_ctf PROGBITS 74ed68 048872 00 0 0 4 And then: # dtrace -n 'syscall:::' dtrace: invalid probe specifier syscall /usr/lib/dtrace/psinfo.d, line 90: failed to resolve type kernel`struct thread * for identifier curthread: Module is no longer loaded Lars ___ 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: -CURRENT userland regression
on 21/02/2013 01:16 Xin Li said the following: I think it's unlikely -- I have r247057 of sys/ which worked fine... userland 246957 works good by the way. Just a very wild guess - are you sure that it is the userland that is to blame? It is rather unfortunate that we install boot blocks, including loader which gets _really_ installed, as part of installworld (and they are built as part of buildworld). So there is a possibility that it is loader that causes the trouble. I would try to rule that out. -- Andriy Gapon ___ 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: -CURRENT userland regression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/21/13 12:19 AM, Andriy Gapon wrote: on 21/02/2013 01:16 Xin Li said the following: I think it's unlikely -- I have r247057 of sys/ which worked fine... userland 246957 works good by the way. Just a very wild guess - are you sure that it is the userland that is to blame? It is rather unfortunate that we install boot blocks, including loader which gets _really_ installed, as part of installworld (and they are built as part of buildworld). So there is a possibility that it is loader that causes the trouble. I would try to rule that out. Since loader is in /sys/ which I have updated to -HEAD and done a full buildworld/buildkernel cycle, can I rule loader out, or did I missed something? (my experiment was to update src/ to a certain revision, then update src/sys/ to latest, then a full buildworld buildkernel) I do not have console access and had some other tasks yesterday so I didn't continue the tests further but will do it today. Cheers, -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJRJdxXAAoJEG80Jeu8UPuz8TEIALTGsoH7tbTOk7Hh3QJPeuHc PU3VLWo7fb3puoPnQXu1eAlTuAjXGpw2+3ITjgmunGWWpN2ABeFGIauIPk7RAWLV E6/c/EpTfFNDWG0KoSDGJnDoTQ1KO9zp17Gp6KfaVYL3MLYEo/tNXWUBfdfg0ddv 4dNocl34GvPK4LXonIw+oBy2ha5MkzL4BARGP2QgYsv07uMk0MZ8fUSngmQFCiaD LpOVe/mPoBc5GmBI7TZENBN/g9mMVNVu9gZXvQronnw52N3wNxIxy7jmWdv5uLUf PXOjLrx930d88tN3HOjgtxrwbZBRyIJUdckbhXthpezlMsy81vWfn2+x9agG+mk= =9OlU -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: ale(4) cannot negotiate as GigE
On Wed, Feb 20, 2013 at 06:08:53AM +, Alexey Dokuchaev wrote: On Wed, Feb 20, 2013 at 01:37:39PM +0900, YongHyeon PYUN wrote: On Tue, Feb 19, 2013 at 08:23:02AM +, Alexey Dokuchaev wrote: ale0@pci0:2:0:0:class=0x02 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR8121/AR8113/AR8114 Gigabit or Fast Ethernet' class = network subclass = ethernet According the the specs, it should be GigE. [...] There is a fast etherenet version(L2E) so I'm not sure what you have. Could you show me dmesg output(ale(4) atphy(4) only) and devinfo -rv | grep atphy? $ dmesg | egrep ale\|atphy ale0: Atheros AR8121/AR8113/AR8114 PCIe Ethernet port 0xcc00-0xcc7f mem 0xfe9c-0xfe9f irq 17 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. miibus0: MII bus on ale0 atphy0: Atheros F1 10/100/1000 PHY PHY 0 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow $ devinfo -rv | grep atphy atphy0 pnpinfo oui=0xc82e model=0x1 rev=0x9 at phyno=0 Hmm, it's still not clear whether the controller is Gigabit or not. Could you try attached patch and let me the output? I'm not sure why it happens; maybe it's somehow related to a handful of those ale0: link state changed to DOWN/UP flip-flops I see in dmesg(8), before it can finally obtain DHCP lease? That's normal when you initiate auto-negotiation with dhclient. Yes, I've already seen your lengthy explanation [1], thanks! I remember these adapters had problems in the past, like infamous Corrupted MAC on input disconnect messages, but I don't recall that I could not use it in GigE mode. [...] If you still see the Corrupted MAC on input message, let me know. No, those are long gone now (hopefully; at least I haven't seen them for a while). ./danfe [1] http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020662.html Index: sys/dev/ale/if_ale.c === --- sys/dev/ale/if_ale.c (revision 246937) +++ sys/dev/ale/if_ale.c (working copy) @@ -497,6 +497,9 @@ ale_attach(device_t dev) sc-ale_flags |= ALE_FLAG_FASTETHER; } } +#if 1 + printf(ale_flags = 0x%08x\n, sc-ale_flags); +#endif /* * All known controllers seems to require 4 bytes alignment * of Tx buffers to make Tx checksum offload with custom ___ 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: ale(4) cannot negotiate as GigE
On Thu, Feb 21, 2013 at 05:33:35PM +0900, YongHyeon PYUN wrote: On Wed, Feb 20, 2013 at 06:08:53AM +, Alexey Dokuchaev wrote: $ dmesg | egrep ale\|atphy ale0: Atheros AR8121/AR8113/AR8114 PCIe Ethernet port 0xcc00-0xcc7f mem 0xfe9c-0xfe9f irq 17 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. miibus0: MII bus on ale0 atphy0: Atheros F1 10/100/1000 PHY PHY 0 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow $ devinfo -rv | grep atphy atphy0 pnpinfo oui=0xc82e model=0x1 rev=0x9 at phyno=0 Hmm, it's still not clear whether the controller is Gigabit or not. Could you try attached patch and let me the output? ale_flags = 0x0040 ./danfe ___ 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: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin j...@freebsd.org wrote: On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov kostik...@gmail.com wrote: Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was simple. SMP case is more complex and rather new for me. Recently, I was solving a problem with PCPU stuff. For example, PCPU_GET is implemented by one instruction on i386 arch. So, a need of atomicity with respect to interrupts can be overlooked. On load-store archs, the implementation which works in SMP case is not so simple. And what works in UP case (single PCPU), not works in SMP case. Believe me, mysterious and sporadic 'mutex not owned' assertions and others ones caused by curthreads mess, it takes a while ... Note that PCPU_GET() is not needed to be atomic. The reason is that the code which uses its result would not be atomic (single-instruction or whatever, see below). Thus, either the preemption should not matter since the action with the per-cpu data is advisory, as is in the case of i386 pmap you noted. or some external measures should be applied in advance to the containing region (which you proposed, by bracing with sched_pin()). So, it's advisory in the case of i386 pmap... Well, if you can live with that, I can too. Also, note that it is not interrupts but preemption which is concern. Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, however, sched_pin() and critical_enter() and their counterparts are implemented with help of curthread. And curthread definition falls to PCPU_GET(curthread) if not defined in other way. So, curthread should be atomic with respect to interrupts and in general, PCPU_GET() should be too. Note that spinlock_enter() definitions often (always) use curthread too. Anyhow, it's defined in MD code and can be defined for each arch separately. curthread is a bit magic. :) If you perform a context switch during an interrupt (which will change 'curthread') you also change your register state. When you resume, the register state is also restored. This means that while something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' never is. However, it is true that actually reading curthread has to be atomic. If your read of curthread looks like: mov pcpu reg, r0 add offset of pc_curthread, r0 ld r0, r1 Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that pc_curthread is the first thing in 'struct pcpu' (and always will be, you could add a CTASSERT to future-proof). In that case, you can remove the 'add' instruction and instead just do: ld pcpu reg, r1 which is fine. Just for the record. There are three extra (coprocessor) registers per a core in arm11mpcore (armv6k). Unfortunately only one is Privileged. The other ones are respectively User Read only and User Read Write. For now, we are using the Privileged one to store pcpu pointer (curthread is correctly set during each context switch). Thus, using a coprocessor register means that reading of curthread is not a single instruction implementation now. After we figured out the curthread issue in SMP case, using a fixed (processor) register for pcpu is an option. Meanwhile, we disable interrupts before reading of curthread and enable them after. The same is done for other PCPU stuff. For now we have not stable system enough for profiling, however, when it will be, it would be interesting to learn how various implementations of curthread reading impact system performance. Svata ___ 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 Testing Facility
On 21.02.13 15:04, Mehmet Erol Sanliturk wrote: Dear All , During development of FreeBSD , testing is very vital . To my knowledge ( which may not be correct ) , at present , Tinderbox is used to only compilation correctness , means Syntax is tested . I have downloaded ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-CURRENT-amd64-20130216-r246877-release.iso and tried to install it on an Intel DG965WH main board . During the first booting , it generated a panic message and entered into debug mode . For me it has crashed , because I do not know what to do in debug mode . On this main board , it is possible to completely install and successfully run Windows 7 , Fedora 15 , 17 , 18 , Mageia OpenSuSE I stopped right here. None of the software you compare FreeBSD-current to is an development build. On the other hand, you downloaded an cutting-edge development build of FreeBSD (not released software) and expected it to be stable. It is not. This is why it is not released. It might not always break, but it might also damage your data and (possibly) hardware too. Unless you agree to accept these risks, you should not play with development versions of software. Having said that, the DG965WH is quite old hardware and any stable version of FreeBSD should work just fine there. You are unlikely to see any benefit of the unreleased versions that are still in development, such as supporting very new hardware etc. Sorry if any of this sounds too hard, but it is reflecting reality. This mailing list, freebsd-current exists to facilitate discussion between those, who know they are running highly unstable, still in development version of FreeBSD that needs lots of work to become more stable. Daniel ___ 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 Testing Facility
On Thu, Feb 21, 2013 at 5:14 AM, Daniel Kalchev dan...@digsys.bg wrote: On 21.02.13 15:04, Mehmet Erol Sanliturk wrote: Dear All , During development of FreeBSD , testing is very vital . To my knowledge ( which may not be correct ) , at present , Tinderbox is used to only compilation correctness , means Syntax is tested . I have downloaded ftp://ftp.freebsd.org/pub/**FreeBSD/snapshots/amd64/amd64/** ISO-IMAGES/10.0/FreeBSD-10.0-**CURRENT-amd64-20130216-** r246877-release.isoftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-CURRENT-amd64-20130216-r246877-release.iso and tried to install it on an Intel DG965WH main board . During the first booting , it generated a panic message and entered into debug mode . For me it has crashed , because I do not know what to do in debug mode . On this main board , it is possible to completely install and successfully run Windows 7 , Fedora 15 , 17 , 18 , Mageia OpenSuSE I stopped right here. None of the software you compare FreeBSD-current to is an development build. On the other hand, you downloaded an cutting-edge development build of FreeBSD (not released software) and expected it to be stable. It is not. This is why it is not released. It might not always break, but it might also damage your data and (possibly) hardware too. Unless you agree to accept these risks, you should not play with development versions of software. Having said that, the DG965WH is quite old hardware and any stable version of FreeBSD should work just fine there. You are unlikely to see any benefit of the unreleased versions that are still in development, such as supporting very new hardware etc. Sorry if any of this sounds too hard, but it is reflecting reality. This mailing list, freebsd-current exists to facilitate discussion between those, who know they are running highly unstable, still in development version of FreeBSD that needs lots of work to become more stable. Daniel I will not support your views . My main idea is to describe how we can help to improve FreeBSD testing . The problem is A snapshot intended for testing , is NOT able to boot. . If you ask , do I know what I am doing : My answer is I am working in computing since 1970 . Thank you very much . Mehmet Erol Sanliturk ___ 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 arm/arm
TB --- 2013-02-21 12:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 12:20:17 - 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-02-21 12:20:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-21 12:20:17 - cleaning the object tree TB --- 2013-02-21 12:25:57 - /usr/local/bin/svn stat /src TB --- 2013-02-21 12:26:00 - At svn revision 247093 TB --- 2013-02-21 12:26:01 - building world TB --- 2013-02-21 12:26:01 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 12:26:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 12:26:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 12:26:01 - SRCCONF=/dev/null TB --- 2013-02-21 12:26:01 - TARGET=arm TB --- 2013-02-21 12:26:01 - TARGET_ARCH=arm TB --- 2013-02-21 12:26:01 - TZ=UTC TB --- 2013-02-21 12:26:01 - __MAKE_CONF=/dev/null TB --- 2013-02-21 12:26:01 - cd /src TB --- 2013-02-21 12:26:01 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 12:26:06 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 14:15:42 UTC 2013 TB --- 2013-02-21 14:15:42 - generating LINT kernel config TB --- 2013-02-21 14:15:42 - cd /src/sys/arm/conf TB --- 2013-02-21 14:15:42 - /usr/bin/make -B LINT TB --- 2013-02-21 14:15:42 - cd /src/sys/arm/conf TB --- 2013-02-21 14:15:42 - /usr/sbin/config -m LINT TB --- 2013-02-21 14:15:42 - building LINT kernel TB --- 2013-02-21 14:15:42 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 14:15:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 14:15:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 14:15:42 - SRCCONF=/dev/null TB --- 2013-02-21 14:15:42 - TARGET=arm TB --- 2013-02-21 14:15:42 - TARGET_ARCH=arm TB --- 2013-02-21 14:15:42 - TZ=UTC TB --- 2013-02-21 14:15:42 - __MAKE_CONF=/dev/null TB --- 2013-02-21 14:15:42 - cd /src TB --- 2013-02-21 14:15:42 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 14:15:42 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppc/ppc.c
Re: Kernel hang r247079 mps/vfs/zfs?
Hi, I was testing a patch on r246300 or so, and wanted to see if it would apply cleanly to a newer copy of HEAD. Well it did, except I had a hang at boot, shortly after ZFS version and the last scsi devices appear. This easily could have been related to the patch I was testing, so I wiped /usr/src/ and /usr/obj (after booting kernel.old) and rebuilt world and kernel cleanly. I assumed that would resolve the issue, but it did not. The hang happens right after zfs is announced, and the last da devices (some of which are usb) are reported. It comes before the noisy output of mps. Hang is complete, and single user or verbose don't yield much. I'm having trouble exfiltrating a dmesg from it, but it may be unrelated to the userland issues reported earlier, as single user does not resolve it for me. The svn up was at 11:20 pacific (GMT +8). Anyone else seeing similar issues? Hardware is an LSI mps device, 9210 crossflashed m1015. Pool is a zfs mirror. Works fine booting from r246300 kernel. Motherboard is an AMD Tyan. Pulling USB headers off the board didn't resolve it. I am experiencing a similar hang when updating from r246190 to r247017 on my all zfs system. The system has two drives in a zfs mirror and hangs after detecting the hard drives. The last thing seen is the ada1: Previously was known as ad8 message, then it hangs completely, unable to even ctrl-alt-del or even get the numlock key to toggle the light. System is: CPU: AMD Phenom(tm) II X4 955 Processor (3214.39-MHz K8-class CPU) with ASUS M4A78LT-M board. Let me know if other details will help. Steve ___ 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 Testing Facility
On 2/21/2013 5:04 AM, Mehmet Erol Sanliturk wrote: Dear All , During development of FreeBSD , testing is very vital . ... This in general is a good suggestion. Most companies do such automated testing as a matter of course. Note however that this is a volunteer effort. Were you volunteering to set up such an automated, possibly testzilla driven, facility? It would certainly help the quality, although as others have noted snapshots are often likely to be broken. ___ 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 Testing Facility
On Feb 21, 2013, at 2:23 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Thu, Feb 21, 2013 at 5:14 AM, Daniel Kalchev dan...@digsys.bg wrote: On 21.02.13 15:04, Mehmet Erol Sanliturk wrote: Dear All , During development of FreeBSD , testing is very vital . To my knowledge ( which may not be correct ) , at present , Tinderbox is used to only compilation correctness , means Syntax is tested . I have downloaded ftp://ftp.freebsd.org/pub/**FreeBSD/snapshots/amd64/amd64/** ISO-IMAGES/10.0/FreeBSD-10.0-**CURRENT-amd64-20130216-** r246877-release.isoftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-CURRENT-amd64-20130216-r246877-release.iso and tried to install it on an Intel DG965WH main board . During the first booting , it generated a panic message and entered into debug mode . For me it has crashed , because I do not know what to do in debug mode . On this main board , it is possible to completely install and successfully run Windows 7 , Fedora 15 , 17 , 18 , Mageia OpenSuSE I stopped right here. None of the software you compare FreeBSD-current to is an development build. On the other hand, you downloaded an cutting-edge development build of FreeBSD (not released software) and expected it to be stable. It is not. This is why it is not released. It might not always break, but it might also damage your data and (possibly) hardware too. Unless you agree to accept these risks, you should not play with development versions of software. Having said that, the DG965WH is quite old hardware and any stable version of FreeBSD should work just fine there. You are unlikely to see any benefit of the unreleased versions that are still in development, such as supporting very new hardware etc. Sorry if any of this sounds too hard, but it is reflecting reality. This mailing list, freebsd-current exists to facilitate discussion between those, who know they are running highly unstable, still in development version of FreeBSD that needs lots of work to become more stable. Daniel I will not support your views . My main idea is to describe how we can help to improve FreeBSD testing . The problem is A snapshot intended for testing , is NOT able to boot. . If you ask , do I know what I am doing : My answer is I am working in computing since 1970 . And in all that time you've never heard of nightly builds being broken ? ___ 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 i386/i386
TB --- 2013-02-21 12:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 12:20:17 - 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-02-21 12:20:17 - starting HEAD tinderbox run for i386/i386 TB --- 2013-02-21 12:20:17 - cleaning the object tree TB --- 2013-02-21 12:27:03 - /usr/local/bin/svn stat /src TB --- 2013-02-21 12:27:06 - At svn revision 247093 TB --- 2013-02-21 12:27:07 - building world TB --- 2013-02-21 12:27:07 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 12:27:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 12:27:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 12:27:07 - SRCCONF=/dev/null TB --- 2013-02-21 12:27:07 - TARGET=i386 TB --- 2013-02-21 12:27:07 - TARGET_ARCH=i386 TB --- 2013-02-21 12:27:07 - TZ=UTC TB --- 2013-02-21 12:27:07 - __MAKE_CONF=/dev/null TB --- 2013-02-21 12:27:07 - cd /src TB --- 2013-02-21 12:27:07 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 12:27:12 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 15:12:06 UTC 2013 TB --- 2013-02-21 15:12:06 - generating LINT kernel config TB --- 2013-02-21 15:12:06 - cd /src/sys/i386/conf TB --- 2013-02-21 15:12:06 - /usr/bin/make -B LINT TB --- 2013-02-21 15:12:06 - cd /src/sys/i386/conf TB --- 2013-02-21 15:12:06 - /usr/sbin/config -m LINT TB --- 2013-02-21 15:12:07 - building LINT kernel TB --- 2013-02-21 15:12:07 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 15:12:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 15:12:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 15:12:07 - SRCCONF=/dev/null TB --- 2013-02-21 15:12:07 - TARGET=i386 TB --- 2013-02-21 15:12:07 - TARGET_ARCH=i386 TB --- 2013-02-21 15:12:07 - TZ=UTC TB --- 2013-02-21 15:12:07 - __MAKE_CONF=/dev/null TB --- 2013-02-21 15:12:07 - cd /src TB --- 2013-02-21 15:12:07 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 15:12:07 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 15:22:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 15:22:30 - ERROR: failed to build LINT kernel TB --- 2013-02-21 15:22:30 - 8483.52 user 1309.46 system 10932.48 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.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: FreeBSD Testing Facility
On Thu, Feb 21, 2013 at 7:04 AM, Matthew Jacob mja...@freebsd.org wrote: On 2/21/2013 5:04 AM, Mehmet Erol Sanliturk wrote: Dear All , During development of FreeBSD , testing is very vital . ... This in general is a good suggestion. Most companies do such automated testing as a matter of course. Note however that this is a volunteer effort. Were you volunteering to set up such an automated, possibly testzilla driven, facility? It would certainly help the quality, although as others have noted snapshots are often likely to be broken. I am not able to design , implement and manage such a facility ( most important problem is health ) , but as an individual I want to participate to testing as much as I can . In the source tree , there are testing software . There are other testing sites . By cosolidating them as a distributed testing facility will help making FreeBSD much more robust and increase development speed . My idea is that a wide testing applicators may resolve many problems at the beginning . All the people which are trying snapshots or are using current developments will likely participate such a testing community and produce results in a structured and cooperative way . For example , assume a component for boot up to login ( included ) is modified . Instead of preparing a many hundred mega bytes complete snapshot , only a small boot only snapshot may be prepared and presented to testers . After verifying that the boot process is correct , the more complete snapshots may be prepared . In that way , time and money will not be wasted by including unnecessary parts . Please , consider each component in that way . At present , many tools are already present in the ports tree . Thank you very much . Mehmet Erol Sanliturk ___ 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
r247095 Boot Failure
I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm running ZFS as root with a mirrored root pool. Here's a pic of the box failing: https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/GoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg There isn't much useful information in the pic. No crash dump is generated. Where do I go from here? I can boot into kernel.old and that works as a workaround for now. Thanks, Shawn ___ 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
Kernel hang r247079 mps/vfs/zfs?
--Meant to reply to list as well-- On Thu, Feb 21, 2013 at 2:32 PM, Steve Wills swi...@freebsd.org wrote: I am experiencing a similar hang when updating from r246190 to r247017 on my all zfs system. The system has two drives in a zfs mirror and hangs after detecting the hard drives. The last thing seen is the ada1: Previously was known as ad8 message, then it hangs completely, unable to even ctrl-alt-del or even get the numlock key to toggle the light. System is: CPU: AMD Phenom(tm) II X4 955 Processor (3214.39-MHz K8-class CPU) with ASUS M4A78LT-M board. Let me know if other details will help. Steve Symptoms are identical to mine as far as I can tell. I did see fatal trap flash in one case, but couldn't read the crash info. It doesn't always just hang, once I got fatal trap and a reboot, other times I got a hard reboot without fatal trap printout. Unfortunately I wasn't able to catch anything other than fatal trap... before the machine cycled. Matt ___ 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 Testing Facility
Decent testing system is a pretty complex system to be. I spent some time in this area, and gave it up, at least till better times :) But anyway, at least booting/working network stack/firewall could be easily tested with VMs. There just need to be a person dedicated to this, which is lacking now. -- Regards, Alexander Yerenkow ___ 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 Testing Facility
On Thu, Feb 21, 2013 at 7:21 AM, Fleuriot Damien m...@my.gd wrote: On Feb 21, 2013, at 2:23 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Thu, Feb 21, 2013 at 5:14 AM, Daniel Kalchev dan...@digsys.bg wrote: On 21.02.13 15:04, Mehmet Erol Sanliturk wrote: Dear All , During development of FreeBSD , testing is very vital . To my knowledge ( which may not be correct ) , at present , Tinderbox is used to only compilation correctness , means Syntax is tested . I have downloaded ftp://ftp.freebsd.org/pub/**FreeBSD/snapshots/amd64/amd64/** ISO-IMAGES/10.0/FreeBSD-10.0-**CURRENT-amd64-20130216-** r246877-release.iso ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-CURRENT-amd64-20130216-r246877-release.iso and tried to install it on an Intel DG965WH main board . During the first booting , it generated a panic message and entered into debug mode . For me it has crashed , because I do not know what to do in debug mode . On this main board , it is possible to completely install and successfully run Windows 7 , Fedora 15 , 17 , 18 , Mageia OpenSuSE I stopped right here. None of the software you compare FreeBSD-current to is an development build. On the other hand, you downloaded an cutting-edge development build of FreeBSD (not released software) and expected it to be stable. It is not. This is why it is not released. It might not always break, but it might also damage your data and (possibly) hardware too. Unless you agree to accept these risks, you should not play with development versions of software. Having said that, the DG965WH is quite old hardware and any stable version of FreeBSD should work just fine there. You are unlikely to see any benefit of the unreleased versions that are still in development, such as supporting very new hardware etc. Sorry if any of this sounds too hard, but it is reflecting reality. This mailing list, freebsd-current exists to facilitate discussion between those, who know they are running highly unstable, still in development version of FreeBSD that needs lots of work to become more stable. Daniel I will not support your views . My main idea is to describe how we can help to improve FreeBSD testing . The problem is A snapshot intended for testing , is NOT able to boot. . If you ask , do I know what I am doing : My answer is I am working in computing since 1970 . And in all that time you've never heard of nightly builds being broken ? Please , please , DO NOT understand my message in a different context . I am NOT saying that a snapshot may not be broken . I am saying that Let's test components as much as possible to generate more complex components. . After generating working components , we will start to test their union . At present , we are testing a complex system without testing its parts . This wastes much effort , time , money , etc. . To solve this problem , let's establish a distributed testing computing structure . Thank you very much . Mehmet Erol Sanliturk ___ 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 Testing Facility
On 2/21/2013 7:32 AM, Alexander Yerenkow wrote: There just need to be a person dedicated to this, which is lacking now. That is correct insofar as it goes. That's why we're not all terribly interested in suggestions about what *could* be done- just what somebody is doing. ___ 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: r247095 Boot Failure
On Thu, Feb 21, 2013 at 10:28:15AM -0500, Shawn Webb wrote: I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm running ZFS as root with a mirrored root pool. Here's a pic of the box failing: https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/GoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg There isn't much useful information in the pic. No crash dump is generated. Where do I go from here? Take a look at the -CURRENT userland regression thread. You may be able to boot if you choose safe mode in the boot loader menu. Regards, Navdeep I can boot into kernel.old and that works as a workaround for now. Thanks, Shawn ___ 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 ___ 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: r247095 Boot Failure
On Thu, Feb 21, 2013 at 3:34 PM, Navdeep Parhar npar...@gmail.com wrote: Take a look at the -CURRENT userland regression thread. You may be able to boot if you choose safe mode in the boot loader menu. Regards, Navdeep What is safe mode as far as boot flags? boot -sv doesn't work on my system... Matt ___ 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: r247095 Boot Failure
On 21 February 2013 19:38, matt sendtom...@gmail.com wrote: On Thu, Feb 21, 2013 at 3:34 PM, Navdeep Parhar npar...@gmail.com wrote: Take a look at the -CURRENT userland regression thread. You may be able to boot if you choose safe mode in the boot loader menu. Regards, Navdeep What is safe mode as far as boot flags? Currently that corresponds to: set kern.smp.disabled=1 set hw.ata.ata_dma=0 set hw.ata.atapi_dma=0 set hw.ata.wc=0 set hw.eisa_slots=0 set kern.eventtimer.periodic=1 set kern.geom.part.check_integrity=0 See /boot/menu-commands.4th -- wbr, pluknet ___ 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: -CURRENT userland regression
On Wednesday, February 20, 2013 5:21:50 pm Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) safe mode toggles a few different things IIRC, can you narrow it down to a single setting? -- John Baldwin ___ 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 Testing Facility
On Thu, Feb 21, 2013 at 7:34 AM, Matthew Jacob mja...@freebsd.org wrote: On 2/21/2013 7:32 AM, Alexander Yerenkow wrote: There just need to be a person dedicated to this, which is lacking now. That is correct insofar as it goes. That's why we're not all terribly interested in suggestions about what *could* be done- just what somebody is doing. Please do not assume that ideas are not important . A question asked about Why soap film is becoming colored when lighted ? generated Quantum mechanics to supply a reasonable answer . After generating an applicable plan , it may be that there exist people to implement it . I am reading messages that people are asking for project ideas . It may be that some will be interested in some a project if it is defined very well . Without a plan , what can be done and how , and who will handled it ? Thank you very much . Mehmet Erol Sanliturk ___ 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: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote: On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin j...@freebsd.org wrote: On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus wrote: On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov kostik...@gmail.com wrote: Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP case was simple. SMP case is more complex and rather new for me. Recently, I was solving a problem with PCPU stuff. For example, PCPU_GET is implemented by one instruction on i386 arch. So, a need of atomicity with respect to interrupts can be overlooked. On load-store archs, the implementation which works in SMP case is not so simple. And what works in UP case (single PCPU), not works in SMP case. Believe me, mysterious and sporadic 'mutex not owned' assertions and others ones caused by curthreads mess, it takes a while ... Note that PCPU_GET() is not needed to be atomic. The reason is that the code which uses its result would not be atomic (single-instruction or whatever, see below). Thus, either the preemption should not matter since the action with the per-cpu data is advisory, as is in the case of i386 pmap you noted. or some external measures should be applied in advance to the containing region (which you proposed, by bracing with sched_pin()). So, it's advisory in the case of i386 pmap... Well, if you can live with that, I can too. Also, note that it is not interrupts but preemption which is concern. Yes and no. In theory, yes, a preemption is a concern. In FreeBSD, however, sched_pin() and critical_enter() and their counterparts are implemented with help of curthread. And curthread definition falls to PCPU_GET(curthread) if not defined in other way. So, curthread should be atomic with respect to interrupts and in general, PCPU_GET() should be too. Note that spinlock_enter() definitions often (always) use curthread too. Anyhow, it's defined in MD code and can be defined for each arch separately. curthread is a bit magic. :) If you perform a context switch during an interrupt (which will change 'curthread') you also change your register state. When you resume, the register state is also restored. This means that while something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' never is. However, it is true that actually reading curthread has to be atomic. If your read of curthread looks like: mov pcpu reg, r0 add offset of pc_curthread, r0 ld r0, r1 Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that pc_curthread is the first thing in 'struct pcpu' (and always will be, you could add a CTASSERT to future-proof). In that case, you can remove the 'add' instruction and instead just do: ld pcpu reg, r1 which is fine. Just for the record. There are three extra (coprocessor) registers per a core in arm11mpcore (armv6k). Unfortunately only one is Privileged. The other ones are respectively User Read only and User Read Write. For now, we are using the Privileged one to store pcpu pointer (curthread is correctly set during each context switch). Thus, using a coprocessor register means that reading of curthread is not a single instruction implementation now. After we figured out the curthread issue in SMP case, using a fixed (processor) register for pcpu is an option. Meanwhile, we disable interrupts before reading of curthread and enable them after. The same is done for other PCPU stuff. For now we have not stable system enough for profiling, however, when it will be, it would be interesting to learn how various implementations of curthread reading impact system performance. curthread is read _a lot_, so I would expect this to hurt. What we did on Alpha was to use a fixed register for pcpu access, but we used the equivalent of a coprocessor register to also store the value so we could set that fixed register on entry to the kernel (userland was free to use the register for its own purposes). -- John Baldwin ___ 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 Testing Facility
On Thu, Feb 21, 2013 at 7:32 AM, Alexander Yerenkow yeren...@gmail.comwrote: Decent testing system is a pretty complex system to be. I spent some time in this area, and gave it up, at least till better times :) But anyway, at least booting/working network stack/firewall could be easily tested with VMs. There just need to be a person dedicated to this, which is lacking now. -- Regards, Alexander Yerenkow With BOINC , people are trying to solve very complex problems by contributing as much as what they can do to solve its parts . A similar structure may be established for FreeBSD . As an example , booting in virtual machine may be possible , but in a real machine may not work . Some main boards may work , but others may not work . The FreeBSD project can not establish a very large testing farm . People wanting to participate may contribute very much . Every one will not test every thing . For that reason a database will be constructed at the beginning to contain ( user , parts can be tested ). When a test is required , by querying the database , a message will be send to the prospective users to inform them about the tests . The users will apply tests and return the results . At present , there are call for testing messages . In such an organized community , such messages will produce much more structured and effective results . Thank you very much . Mehmet Erol Sanliturk ___ 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 amd64/amd64
TB --- 2013-02-21 12:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 12:20:17 - 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-02-21 12:20:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-02-21 12:20:17 - cleaning the object tree TB --- 2013-02-21 12:27:26 - /usr/local/bin/svn stat /src TB --- 2013-02-21 12:27:30 - At svn revision 247093 TB --- 2013-02-21 12:27:31 - building world TB --- 2013-02-21 12:27:31 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 12:27:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 12:27:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 12:27:31 - SRCCONF=/dev/null TB --- 2013-02-21 12:27:31 - TARGET=amd64 TB --- 2013-02-21 12:27:31 - TARGET_ARCH=amd64 TB --- 2013-02-21 12:27:31 - TZ=UTC TB --- 2013-02-21 12:27:31 - __MAKE_CONF=/dev/null TB --- 2013-02-21 12:27:31 - cd /src TB --- 2013-02-21 12:27:31 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 12:27:35 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 stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Thu Feb 21 15:45:25 UTC 2013 TB --- 2013-02-21 15:45:25 - generating LINT kernel config TB --- 2013-02-21 15:45:25 - cd /src/sys/amd64/conf TB --- 2013-02-21 15:45:25 - /usr/bin/make -B LINT TB --- 2013-02-21 15:45:25 - cd /src/sys/amd64/conf TB --- 2013-02-21 15:45:25 - /usr/sbin/config -m LINT TB --- 2013-02-21 15:45:25 - building LINT kernel TB --- 2013-02-21 15:45:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 15:45:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 15:45:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 15:45:25 - SRCCONF=/dev/null TB --- 2013-02-21 15:45:25 - TARGET=amd64 TB --- 2013-02-21 15:45:25 - TARGET_ARCH=amd64 TB --- 2013-02-21 15:45:25 - TZ=UTC TB --- 2013-02-21 15:45:25 - __MAKE_CONF=/dev/null TB --- 2013-02-21 15:45:25 - cd /src TB --- 2013-02-21 15:45:25 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 15:45:25 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 15:56:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 15:56:32 - ERROR: failed to build LINT kernel TB --- 2013-02-21 15:56:32 - 9823.25 user 1700.77 system 12974.48 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.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: r247095 Boot Failure
On Thu, Feb 21, 2013 at 03:38:41PM +, matt wrote: On Thu, Feb 21, 2013 at 3:34 PM, Navdeep Parhar npar...@gmail.com wrote: Take a look at the -CURRENT userland regression thread. You may be able to boot if you choose safe mode in the boot loader menu. Regards, Navdeep What is safe mode as far as boot flags? This is the forth code that sets up safe mode: : safemode_enable ( -- ) s set kern.smp.disabled=1 evaluate s set hw.ata.ata_dma=0 evaluate s set hw.ata.atapi_dma=0 evaluate s set hw.ata.wc=0 evaluate s set hw.eisa_slots=0 evaluate s set kern.eventtimer.periodic=1 evaluate s set kern.geom.part.check_integrity=0 evaluate ; loader.conf should be able to set up those variables too (temporarily, as a workaround). I wonder which one does the trick - smp.disabled or eventtimer_periodic, or ..? Regards, Navdeep boot -sv doesn't work on my system... Matt ___ 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: r247095 Boot Failure
On Thu, Feb 21, 2013 at 3:46 PM, Sergey Kandaurov pluk...@gmail.com wrote: Currently that corresponds to: set kern.smp.disabled=1 set hw.ata.ata_dma=0 set hw.ata.atapi_dma=0 set hw.ata.wc=0 set hw.eisa_slots=0 set kern.eventtimer.periodic=1 set kern.geom.part.check_integrity=0 See /boot/menu-commands.4th -- wbr, pluknet Enabling beastie, safe mode boots. The userland thread wasn't terribly descriptive about symptoms, and this sure doesn't *look* like a userland problem. Trying to reduce it to a specific option First, no variables or alternate kernels work until I type show (that seems broken) Setting all of the kern variables allow it to boot Setting all of the hw.ata.*dma doesn't change anything Setting hw.ata.wc causes a panic/reboot Matt ___ 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: r247095 Boot Failure
On Thu, Feb 21, 2013 at 3:46 PM, Sergey Kandaurov pluk...@gmail.comwrote: Currently that corresponds to: set kern.smp.disabled=1 set hw.ata.ata_dma=0 set hw.ata.atapi_dma=0 set hw.ata.wc=0 set hw.eisa_slots=0 set kern.eventtimer.periodic=1 set kern.geom.part.check_integrity=0 See /boot/menu-commands.4th -- wbr, pluknet It's kern.smp.disabled=1 that allows boot. Matt ___ 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-02-21 14:29:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 14:29:42 - 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-02-21 14:29:42 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-02-21 14:29:42 - cleaning the object tree TB --- 2013-02-21 14:30:53 - /usr/local/bin/svn stat /src TB --- 2013-02-21 14:30:56 - At svn revision 247093 TB --- 2013-02-21 14:30:57 - building world TB --- 2013-02-21 14:30:57 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 14:30:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 14:30:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 14:30:57 - SRCCONF=/dev/null TB --- 2013-02-21 14:30:57 - TARGET=ia64 TB --- 2013-02-21 14:30:57 - TARGET_ARCH=ia64 TB --- 2013-02-21 14:30:57 - TZ=UTC TB --- 2013-02-21 14:30:57 - __MAKE_CONF=/dev/null TB --- 2013-02-21 14:30:57 - cd /src TB --- 2013-02-21 14:30:57 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 14:31:01 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 16:04:28 UTC 2013 TB --- 2013-02-21 16:04:28 - generating LINT kernel config TB --- 2013-02-21 16:04:28 - cd /src/sys/ia64/conf TB --- 2013-02-21 16:04:28 - /usr/bin/make -B LINT TB --- 2013-02-21 16:04:28 - cd /src/sys/ia64/conf TB --- 2013-02-21 16:04:28 - /usr/sbin/config -m LINT TB --- 2013-02-21 16:04:28 - building LINT kernel TB --- 2013-02-21 16:04:28 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 16:04:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 16:04:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 16:04:28 - SRCCONF=/dev/null TB --- 2013-02-21 16:04:28 - TARGET=ia64 TB --- 2013-02-21 16:04:28 - TARGET_ARCH=ia64 TB --- 2013-02-21 16:04:28 - TZ=UTC TB --- 2013-02-21 16:04:28 - __MAKE_CONF=/dev/null TB --- 2013-02-21 16:04:28 - cd /src TB --- 2013-02-21 16:04:28 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 16:04:28 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000
Re: r247095 Boot Failure
Shawn Webb wrote this message on Thu, Feb 21, 2013 at 10:28 -0500: I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm running ZFS as root with a mirrored root pool. Here's a pic of the box failing: https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/GoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg There isn't much useful information in the pic. No crash dump is generated. Where do I go from here? I can boot into kernel.old and that works as a workaround for now. Some how, my changes to gcc in r247012 is causing this, even when using the default of clang as cc... I was able to reproduce a crash myself, and then I just backed my change and the new kernel booted... I'm about to do a binary diff between the broken kernel and the new kernel (since I only installed the kernel, not userland) and figure out which part of the system.. But clearly, we are still using gcc somehow in our kernel builds... If I don't figure out what it is in a few hours, I'll back out the change... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: -CURRENT userland regression
Andriy Gapon wrote this message on Thu, Feb 21, 2013 at 10:19 +0200: on 21/02/2013 01:16 Xin Li said the following: I think it's unlikely -- I have r247057 of sys/ which worked fine... userland 246957 works good by the way. Just a very wild guess - are you sure that it is the userland that is to blame? It is rather unfortunate that we install boot blocks, including loader which gets _really_ installed, as part of installworld (and they are built as part of buildworld). So there is a possibility that it is loader that causes the trouble. I would try to rule that out. As I posted in a different thread, apparently my gcc AES changes (r247012) manages to break a clang built kernel... I'm in the process of debugging right now... I did the usual: make buildworld make buildkernel make installkernel shutdown -r now and the kernel hung... I then reverted r247012 and did the above again, and the machine is running again: FreeBSD carbon.funkthat.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r247075M: Thu Feb 21 00:49:57 PST 2013 j...@carbon.funkthat.com:/usr/obj/usr/src/sys/GENERIC amd64 And I haven't installworld yet... so somehow supporting the AES instructions in gcc causes the kernel to miscompile... I'm now going to diff the two kernels to find out what's different... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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 i386/pc98
TB --- 2013-02-21 14:22:13 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 14:22:13 - 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-02-21 14:22:13 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-02-21 14:22:13 - cleaning the object tree TB --- 2013-02-21 14:23:13 - /usr/local/bin/svn stat /src TB --- 2013-02-21 14:23:18 - At svn revision 247093 TB --- 2013-02-21 14:23:19 - building world TB --- 2013-02-21 14:23:19 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 14:23:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 14:23:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 14:23:19 - SRCCONF=/dev/null TB --- 2013-02-21 14:23:19 - TARGET=pc98 TB --- 2013-02-21 14:23:19 - TARGET_ARCH=i386 TB --- 2013-02-21 14:23:19 - TZ=UTC TB --- 2013-02-21 14:23:19 - __MAKE_CONF=/dev/null TB --- 2013-02-21 14:23:19 - cd /src TB --- 2013-02-21 14:23:19 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 14:23:24 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 17:16:41 UTC 2013 TB --- 2013-02-21 17:16:41 - generating LINT kernel config TB --- 2013-02-21 17:16:41 - cd /src/sys/pc98/conf TB --- 2013-02-21 17:16:41 - /usr/bin/make -B LINT TB --- 2013-02-21 17:16:41 - cd /src/sys/pc98/conf TB --- 2013-02-21 17:16:41 - /usr/sbin/config -m LINT TB --- 2013-02-21 17:16:41 - building LINT kernel TB --- 2013-02-21 17:16:41 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 17:16:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 17:16:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 17:16:41 - SRCCONF=/dev/null TB --- 2013-02-21 17:16:41 - TARGET=pc98 TB --- 2013-02-21 17:16:41 - TARGET_ARCH=i386 TB --- 2013-02-21 17:16:41 - TZ=UTC TB --- 2013-02-21 17:16:41 - __MAKE_CONF=/dev/null TB --- 2013-02-21 17:16:41 - cd /src TB --- 2013-02-21 17:16:41 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 17:16:41 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c:724:2: error: implicit declaration of function 'critical_leave' is invalid in C99 [-Werror,-Wimplicit-function-declaration] PPC_CONFIG_UNLOCK(ppc); ^ /src/sys/dev/ppc/ppc.c:91:33: note: expanded from macro 'PPC_CONFIG_UNLOCK' #define PPC_CONFIG_UNLOCK(ppc) critical_leave() ^ 1 error generated. *** [ppc.o] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 17:24:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 17:24:37 - ERROR: failed to build LINT kernel TB --- 2013-02-21 17:24:37 - 8611.15 user 1339.27 system 10943.82 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.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
DVD/CD lost after r246713
Hi, When trying to update a i386 system from r245422 to r246923, the DVD/CD devices cd0/cd1 could no more be attached. Here is a relevant part of a verbose dmaeg: pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: WDC WD3200AAJB-00J3A0 01.03E01 ATA-8 device pass0: Serial Number WD-WCAV2F115406 pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass1 at ata0 bus 0 scbus0 target 1 lun 0 pass1: WDC WD600BB-75CAA0 16.06V16 ATA-5 device pass1: Serial Number WD-WMA8F2128712 pass1: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass2 at ata1 bus 0 scbus1 target 0 lun 0 pass2: SAMSUNG DVD-ROM SD-616T F310 Removable CD-ROM SCSI-0 device pass2: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) pass3 at ata1 bus 0 scbus1 target 1 lun 0 pass3: HL-DT-ST CD-RW GCE-8481B C102 Removable CD-ROM SCSI-0 device pass3: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) TSC timecounter discards lower 1 bit(s) Timecounter TSC-low frequency 1196040076 Hz quality 800 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered GEOM: new disk cd0 GEOM: new disk cd1 GEOM: new disk ada0 GEOM: new disk ada1 uhub3: 6 ports with 6 removable, self powered ugen0.2: Logitech at usbus0 ums0: Logitech Optical USB Mouse, class 0/0, rev 2.00/3.40, addr 2 on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 ata1: reset tp1 mask=03 ostat0=d0 ostat1=50 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=10 stat1=10 devices=0x3 (cd0:ata1:0:0:0): got CAM status 0x50 (cd0:ata1:0:0:0): fatal error, failed to attach to device (cd0:ata1:0:0:0): lost device, 4 refs Opened disk cd0 - 6 (cd0:ata1:0:0:0): removing device entryata1: reset tp1 mask=03 ostat0=50 ostat1=d0 ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=10 stat1=10 devices=0x3 (cd1:ata1:0:1:0): got CAM status 0x50 (cd1:ata1:0:1:0): fatal error, failed to attach to device (cd1:ata1:0:1:0): lost device, 4 refs Opened disk cd1 - 6 (cd1:ata1:0:1:0): removing device entry First i tried some snapshots from allbsd.org, to verify that the same problem existed with independently generated systems, then I made a search to find that the culprit was: Author: kib Date: Tue Feb 12 16:57:20 2013 New Revision: 246713 URL: http://svnweb.freebsd.org/changeset/base/246713 Log: Reform the busdma API so that new types may be added without modifying every architecture's busdma_machdep.c. It is done by unifying the bus_dmamap_load_buffer() routines so that they may be called from MI code. The MD busdma is then given a chance to do any final processing in the complete() callback. The cam changes unify the bus_dmamap_load* handling in cam drivers. The arm and mips implementations are updated to track virtual addresses for sync(). Previously this was done in a type specific way. Now it is done in a generic way by recording the list of virtuals in the map. Submitted by: jeff (sponsored by EMC/Isilon) Reviewed by: kan (previous version), scottl, mjacob (isp(4), no objections for target mode changes) Discussed with:ian (arm changes) Tested by:marius (sparc64), mips (jmallet), isci(4) on x86 (jharris), amd64 (Fabian Keil freebsd-listen at fabiankeil.de) I even tried to rebuild the system WITHOUT_CLANG, just to eliminate the compiler factor (with r247000 applied of course). If necessary I can send complete verbose dmesg at r245422 and r246923. Thanks for your attention CBu P.S. GREAT THANKS to allbsd.org for this its very useful collection of working memstick images ! but with the remark that the documented revision numbers seems to be inexacts: the 246711 snapshot exhibited this same problem (?!) ___ 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 Testing Facility
On Thu, Feb 21, 2013 at 4:43 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Thu, Feb 21, 2013 at 7:32 AM, Alexander Yerenkow yeren...@gmail.comwrote: Decent testing system is a pretty complex system to be. I spent some time in this area, and gave it up, at least till better times :) But anyway, at least booting/working network stack/firewall could be easily tested with VMs. There just need to be a person dedicated to this, which is lacking now. -- Regards, Alexander Yerenkow With BOINC , people are trying to solve very complex problems by contributing as much as what they can do to solve its parts . A similar structure may be established for FreeBSD . As an example , booting in virtual machine may be possible , but in a real machine may not work . Some main boards may work , but others may not work . The FreeBSD project can not establish a very large testing farm . People wanting to participate may contribute very much . Every one will not test every thing . We certainly want to have a system that allows to perform tests in an automated fashion. Both compile and runtime tests but I don't see us running a huge lab of desktop or even worse laptop class hardware to verify that everything works. So the only way to go is limited testing if a new snapshot runs at all and then perform a few runtime tests and probably some benchmarks to find major regressions. Running a BOINC kind of system sounds like out of reach and not worth the work. BOINC works because it's cool to find aliens or prove that Einstein was wrong but testing software is not cool. In your special case it looks like you hit some bug so please file a PR and provide as much details as possible to track down what is causing this. -- Bernhard Froehlich http://www.bluelife.at/ ___ 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: -CURRENT userland regression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-21 10:31:31 -0500, John Baldwin wrote: On Wednesday, February 20, 2013 5:21:50 pm Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) safe mode toggles a few different things IIRC, can you narrow it down to a single setting? kern.smp.disabled=1 Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRJl45AAoJECXpabHZMqHO/I0IALhqfW2uSY+IoCOvtSN7eQGM IRmzRiFtoz7sXb5OiNlHjwZdRcQR4t6656EUyItDjr3XbXvnGaNL/nk+B9moSgSi NmHpEWQ4yNTJKYUAnvw4NGHKkiOpmNsrAA5i8EEQQesQGuwke0eYaeHMb5R5Wvsu lyWTB0ZH1XV8VehvTir3vo7MWaGjYYp8l09YpaDUYTpn364Fx+jBgsG5qKWdrHMn l/TwMLmWB6Mij2K8+FeS9PIijFKhaTh2s5xa1/xX3vFuR0mhMfNm7OfadXy1KKsL YcTm4Q0QYDkfoxwoS6+AWKVk1LMrF8vah8kHalKp5JCtNv3p1jr5RupalYI9zgo= =1D9R -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
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-02-21 17:28:41 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 17:28:41 - 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-02-21 17:28:41 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-02-21 17:28:41 - cleaning the object tree TB --- 2013-02-21 17:30:05 - /usr/local/bin/svn stat /src TB --- 2013-02-21 17:30:08 - At svn revision 247093 TB --- 2013-02-21 17:30:09 - building world TB --- 2013-02-21 17:30:09 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 17:30:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 17:30:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 17:30:09 - SRCCONF=/dev/null TB --- 2013-02-21 17:30:09 - TARGET=sparc64 TB --- 2013-02-21 17:30:09 - TARGET_ARCH=sparc64 TB --- 2013-02-21 17:30:09 - TZ=UTC TB --- 2013-02-21 17:30:09 - __MAKE_CONF=/dev/null TB --- 2013-02-21 17:30:09 - cd /src TB --- 2013-02-21 17:30:09 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 17:30:14 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 18:31:42 UTC 2013 TB --- 2013-02-21 18:31:42 - generating LINT kernel config TB --- 2013-02-21 18:31:42 - cd /src/sys/sparc64/conf TB --- 2013-02-21 18:31:42 - /usr/bin/make -B LINT TB --- 2013-02-21 18:31:42 - cd /src/sys/sparc64/conf TB --- 2013-02-21 18:31:42 - /usr/sbin/config -m LINT TB --- 2013-02-21 18:31:42 - building LINT kernel TB --- 2013-02-21 18:31:42 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 18:31:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 18:31:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 18:31:42 - SRCCONF=/dev/null TB --- 2013-02-21 18:31:42 - TARGET=sparc64 TB --- 2013-02-21 18:31:42 - TARGET_ARCH=sparc64 TB --- 2013-02-21 18:31:42 - TZ=UTC TB --- 2013-02-21 18:31:42 - __MAKE_CONF=/dev/null TB --- 2013-02-21 18:31:42 - cd /src TB --- 2013-02-21 18:31:42 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 18:31:43 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/pci/amdsmb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/pci/if_rl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/pci/intpm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror
Re: -CURRENT userland regression
On Thu, Feb 21, 2013 at 12:49:45PM -0500, Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-21 10:31:31 -0500, John Baldwin wrote: On Wednesday, February 20, 2013 5:21:50 pm Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) safe mode toggles a few different things IIRC, can you narrow it down to a single setting? kern.smp.disabled=1 As the public service announcement, jmg will commit the following patch. Until that, apply and rebuild both world and kernel. diff --git a/contrib/binutils/opcodes/i386-opc.h b/contrib/binutils/opcodes/i386-opc.h index 45589d8..27c1dab 100644 --- a/contrib/binutils/opcodes/i386-opc.h +++ b/contrib/binutils/opcodes/i386-opc.h @@ -73,15 +73,16 @@ typedef struct template #define CpuSSE4_20x80 /* SSE4.2 Instructions required */ #define CpuXSAVE0x100 /* XSAVE Instructions required */ #define CpuAES 0x200 /* AES Instructions required */ -#define CpuPCLMUL 0x400 /* Carry-less Multiplication extensions */ - -/* SSE4.1/4.2 Instructions required */ -#define CpuSSE4 (CpuSSE4_1|CpuSSE4_2) /* These flags are set by gas depending on the flag_code. */ #define Cpu64 0x400 /* 64bit support required */ #define CpuNo64 0x800 /* Not supported in the 64bit mode */ +#define CpuPCLMUL 0x1000 /* Carry-less Multiplication extensions */ + +/* SSE4.1/4.2 Instructions required */ +#define CpuSSE4 (CpuSSE4_1|CpuSSE4_2) + /* The default value for unknown CPUs - enable all features to avoid problems. */ #define CpuUnknownFlags (Cpu186|Cpu286|Cpu386|Cpu486|Cpu586|Cpu686 \ |CpuP4|CpuSledgehammer|CpuMMX|CpuMMX2|CpuSSE|CpuSSE2|CpuSSE3|CpuVMX \ pgpa44_xzYKWn.pgp Description: PGP signature
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-02-21 16:13:45 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 16:13:45 - 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-02-21 16:13:45 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-02-21 16:13:45 - cleaning the object tree TB --- 2013-02-21 16:14:47 - /usr/local/bin/svn stat /src TB --- 2013-02-21 16:14:51 - At svn revision 247093 TB --- 2013-02-21 16:14:52 - building world TB --- 2013-02-21 16:14:52 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 16:14:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 16:14:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 16:14:52 - SRCCONF=/dev/null TB --- 2013-02-21 16:14:52 - TARGET=powerpc TB --- 2013-02-21 16:14:52 - TARGET_ARCH=powerpc TB --- 2013-02-21 16:14:52 - TZ=UTC TB --- 2013-02-21 16:14:52 - __MAKE_CONF=/dev/null TB --- 2013-02-21 16:14:52 - cd /src TB --- 2013-02-21 16:14:52 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 21 16:14:56 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Feb 21 18:37:32 UTC 2013 TB --- 2013-02-21 18:37:32 - generating LINT kernel config TB --- 2013-02-21 18:37:32 - cd /src/sys/powerpc/conf TB --- 2013-02-21 18:37:32 - /usr/bin/make -B LINT TB --- 2013-02-21 18:37:32 - cd /src/sys/powerpc/conf TB --- 2013-02-21 18:37:32 - /usr/sbin/config -m LINT TB --- 2013-02-21 18:37:33 - building LINT kernel TB --- 2013-02-21 18:37:33 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 18:37:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 18:37:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 18:37:33 - SRCCONF=/dev/null TB --- 2013-02-21 18:37:33 - TARGET=powerpc TB --- 2013-02-21 18:37:33 - TARGET_ARCH=powerpc TB --- 2013-02-21 18:37:33 - TZ=UTC TB --- 2013-02-21 18:37:33 - __MAKE_CONF=/dev/null TB --- 2013-02-21 18:37:33 - cd /src TB --- 2013-02-21 18:37:33 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Feb 21 18:37:33 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/amdsmb.c cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/if_rl.c cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/pci/intpm.c cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000
Re: r247095 Boot Failure
Am 02/21/13 16:28, schrieb Shawn Webb: I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm running ZFS as root with a mirrored root pool. Here's a pic of the box failing: https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/GoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg There isn't much useful information in the pic. No crash dump is generated. Where do I go from here? I can boot into kernel.old and that works as a workaround for now. Thanks, Shawn Well, I guess you faced the same problem I reported in two days ago. I have this crash on ALL(!) of my FreeBSD 10.0-CURRENT boxes, which use CLANG as the default compiler as well as setting CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++1 The working kernel on those boxes is FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:20:30 CET 2013/amd64 On our Intel Core2Duo (Q6600/E8400) boxes the crash looks like yours in the picture, but sometimes there is trap 18 or trap 16 instead of the cryptic signs. On a more modern Ivy-Bridge i3-3220, I get blinking, funky funny clock characters on the screen - this box uitilizes as a server the Intel iGPU of the CPU. Since I use customized kernels, I tried to start with the official GENERIC kernel and disabling every setting in /boot/loader.conf, but the result is even with such a setting the same - all boxes crashes with the kernel sources r246949. I also tried to enable the debugging features in the customized kernel (as they are enabled in the GENERIC), but there is no chance to get any backtrace, the kernel simply gets stuck or - on the mentioned box with the ivy Bridge, simply blinking funnily as a home computer in the late 80s. Sorry for being unable to report more substantial facts on that. Oliver signature.asc Description: OpenPGP digital signature
Re: r247095 Boot Failure
On Thu, Feb 21, 2013 at 08:40:44PM +0100, O. Hartmann wrote: Am 02/21/13 16:28, schrieb Shawn Webb: I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm running ZFS as root with a mirrored root pool. Here's a pic of the box failing: https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/GoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg There isn't much useful information in the pic. No crash dump is generated. Where do I go from here? I can boot into kernel.old and that works as a workaround for now. Thanks, Shawn Well, I guess you faced the same problem I reported in two days ago. I have this crash on ALL(!) of my FreeBSD 10.0-CURRENT boxes, which use CLANG as the default compiler as well as setting CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++1 The working kernel on those boxes is FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:20:30 CET 2013/amd64 On our Intel Core2Duo (Q6600/E8400) boxes the crash looks like yours in the picture, but sometimes there is trap 18 or trap 16 instead of the cryptic signs. On a more modern Ivy-Bridge i3-3220, I get blinking, funky funny clock characters on the screen - this box uitilizes as a server the Intel iGPU of the CPU. Since I use customized kernels, I tried to start with the official GENERIC kernel and disabling every setting in /boot/loader.conf, but the result is even with such a setting the same - all boxes crashes with the kernel sources r246949. I also tried to enable the debugging features in the customized kernel (as they are enabled in the GENERIC), but there is no chance to get any backtrace, the kernel simply gets stuck or - on the mentioned box with the ivy Bridge, simply blinking funnily as a home computer in the late 80s. Sorry for being unable to report more substantial facts on that. The supposed fix was committed as r247117. pgpQhxzEdDqJD.pgp Description: PGP signature
Re: r247095 Boot Failure
Am 02/21/13 20:51, schrieb Konstantin Belousov: On Thu, Feb 21, 2013 at 08:40:44PM +0100, O. Hartmann wrote: Am 02/21/13 16:28, schrieb Shawn Webb: I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm running ZFS as root with a mirrored root pool. Here's a pic of the box failing: https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/GoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg There isn't much useful information in the pic. No crash dump is generated. Where do I go from here? I can boot into kernel.old and that works as a workaround for now. Thanks, Shawn Well, I guess you faced the same problem I reported in two days ago. I have this crash on ALL(!) of my FreeBSD 10.0-CURRENT boxes, which use CLANG as the default compiler as well as setting CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++1 The working kernel on those boxes is FreeBSD 10.0-CURRENT #0 r246949: Mon Feb 18 22:20:30 CET 2013/amd64 On our Intel Core2Duo (Q6600/E8400) boxes the crash looks like yours in the picture, but sometimes there is trap 18 or trap 16 instead of the cryptic signs. On a more modern Ivy-Bridge i3-3220, I get blinking, funky funny clock characters on the screen - this box uitilizes as a server the Intel iGPU of the CPU. Since I use customized kernels, I tried to start with the official GENERIC kernel and disabling every setting in /boot/loader.conf, but the result is even with such a setting the same - all boxes crashes with the kernel sources r246949. I also tried to enable the debugging features in the customized kernel (as they are enabled in the GENERIC), but there is no chance to get any backtrace, the kernel simply gets stuck or - on the mentioned box with the ivy Bridge, simply blinking funnily as a home computer in the late 80s. Sorry for being unable to report more substantial facts on that. The supposed fix was committed as r247117. Simply compiling a new kernel doesn't resolve the problem. -- Updating /usr/src using Subversion -- /usr/local/bin/svn update -r HEAD Updating '.': At revision 247121. This kernel crashes the same way. As it is supposed to be a gcc-change, I guess I have to recompile the whole world? Doing so by now. If not necessary to build world - then the bug is still persent - at least in my case. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: r247095 Boot Failure
On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: The supposed fix was committed as r247117. Simply compiling a new kernel doesn't resolve the problem. See the commit message why your kernel appears to not work. http://svnweb.freebsd.org/base?view=revisionrevision=247117 Did you update gas before building the new kernel? -- Steve ___ 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: r247095 Boot Failure
I'm building now. I should know whether or not it works. I'm assuming the updated gas is in base? My userland is r247095, but my kernel is r246990. On Thu, Feb 21, 2013 at 3:21 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: The supposed fix was committed as r247117. Simply compiling a new kernel doesn't resolve the problem. See the commit message why your kernel appears to not work. http://svnweb.freebsd.org/base?view=revisionrevision=247117 Did you update gas before building the new kernel? -- Steve ___ 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: r247095 Boot Failure
Am 02/21/13 22:01, schrieb Shawn Webb: I'm building now. I should know whether or not it works. I'm assuming the updated gas is in base? My userland is r247095, but my kernel is r246990. On Thu, Feb 21, 2013 at 3:21 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: The supposed fix was committed as r247117. Simply compiling a new kernel doesn't resolve the problem. See the commit message why your kernel appears to not work. http://svnweb.freebsd.org/base?view=revisionrevision=247117 Did you update gas before building the new kernel? -- Steve Update now in progress, didn't update gas in the first place. Oliver signature.asc Description: OpenPGP digital signature
Re: r247095 Boot Failure
The results are in: success! Thanks everyone. This is why I love FreeBSD: the community is amazing! On Thu, Feb 21, 2013 at 4:54 PM, O. Hartmann ohart...@zedat.fu-berlin.dewrote: Am 02/21/13 22:01, schrieb Shawn Webb: I'm building now. I should know whether or not it works. I'm assuming the updated gas is in base? My userland is r247095, but my kernel is r246990. On Thu, Feb 21, 2013 at 3:21 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: The supposed fix was committed as r247117. Simply compiling a new kernel doesn't resolve the problem. See the commit message why your kernel appears to not work. http://svnweb.freebsd.org/base?view=revisionrevision=247117 Did you update gas before building the new kernel? -- Steve Update now in progress, didn't update gas in the first place. Oliver ___ 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: [patch] i386 pmap sysmaps_pcpu[] atomic access
On Thu, Feb 21, 2013 at 4:43 PM, John Baldwin j...@freebsd.org wrote: curthread is a bit magic. :) If you perform a context switch during an interrupt (which will change 'curthread') you also change your register state. When you resume, the register state is also restored. This means that while something like 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' never is. However, it is true that actually reading curthread has to be atomic. If your read of curthread looks like: mov pcpu reg, r0 add offset of pc_curthread, r0 ld r0, r1 Then that will indeed break. Alpha used a fixed register for 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to depend on the fact that pc_curthread is the first thing in 'struct pcpu' (and always will be, you could add a CTASSERT to future-proof). In that case, you can remove the 'add' instruction and instead just do: ld pcpu reg, r1 which is fine. Just for the record. There are three extra (coprocessor) registers per a core in arm11mpcore (armv6k). Unfortunately only one is Privileged. The other ones are respectively User Read only and User Read Write. For now, we are using the Privileged one to store pcpu pointer (curthread is correctly set during each context switch). Thus, using a coprocessor register means that reading of curthread is not a single instruction implementation now. After we figured out the curthread issue in SMP case, using a fixed (processor) register for pcpu is an option. Meanwhile, we disable interrupts before reading of curthread and enable them after. The same is done for other PCPU stuff. For now we have not stable system enough for profiling, however, when it will be, it would be interesting to learn how various implementations of curthread reading impact system performance. curthread is read _a lot_, so I would expect this to hurt. What we did on Alpha was to use a fixed register for pcpu access, but we used the equivalent of a coprocessor register to also store the value so we could set that fixed register on entry to the kernel (userland was free to use the register for its own purposes). Interesting solution. Thanks. Svata ___ 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: r247095 Boot Failure
Am 02/21/13 22:55, schrieb Shawn Webb: The results are in: success! Thanks everyone. This is why I love FreeBSD: the community is amazing! On Thu, Feb 21, 2013 at 4:54 PM, O. Hartmann ohart...@zedat.fu-berlin.dewrote: Am 02/21/13 22:01, schrieb Shawn Webb: I'm building now. I should know whether or not it works. I'm assuming the updated gas is in base? My userland is r247095, but my kernel is r246990. On Thu, Feb 21, 2013 at 3:21 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Feb 21, 2013 at 09:14:07PM +0100, O. Hartmann wrote: The supposed fix was committed as r247117. Simply compiling a new kernel doesn't resolve the problem. See the commit message why your kernel appears to not work. http://svnweb.freebsd.org/base?view=revisionrevision=247117 Did you update gas before building the new kernel? -- Steve Update now in progress, didn't update gas in the first place. Oliver Works for me, too. Thanks a lot. oh signature.asc Description: OpenPGP digital signature
Re: No ZFS when loading modules from loeader prompt
On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: At the loader prompt, I need to unload the buggy kernel and load the old working one via load /boot/kernel.old/kernel Then I load also the ZFS related modules load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko Issuing boot at the end of that stage boots the kernel - the old one -successfully - but there is no working ZFS and no ZFS volume gets mounted although the rc.conf is executed correctly. What am I doing wrong at that point? Why isn't ZFS run and mount properly? Last time I ran into this problem, the issue was that unload also unloaded the zpool.cache file and the ZFS code relied on that to find the kernel. I don't recall what the workaround was. On 2013-Feb-20 08:17:46 -0800, Freddie Cash fjwc...@gmail.com wrote: Sounds like a perfect use case for Boot Environments. Create a new BE, install the new kernel into it, set it as the default, reboot. If it fails, you manually set the previous BE as the default, and reboot. That way, your known-good, working environment is never affected. How do you change your BE in the loader? Or how do you change your BE when you can't boot? -- Peter Jeremy pgpHx5Un14coz.pgp Description: PGP signature
Re: r247095 Boot Failure
OK here as well. Tested sandybridge opteron. Matt On Thu, Feb 21, 2013 at 10:28 PM, O. Hartmann ohart...@zedat.fu-berlin.dewrote: Works for me, too. Thanks a lot. oh ___ 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: ale(4) cannot negotiate as GigE
On Thu, Feb 21, 2013 at 12:43:44PM +, Alexey Dokuchaev wrote: On Thu, Feb 21, 2013 at 05:33:35PM +0900, YongHyeon PYUN wrote: On Wed, Feb 20, 2013 at 06:08:53AM +, Alexey Dokuchaev wrote: $ dmesg | egrep ale\|atphy ale0: Atheros AR8121/AR8113/AR8114 PCIe Ethernet port 0xcc00-0xcc7f mem 0xfe9c-0xfe9f irq 17 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. miibus0: MII bus on ale0 atphy0: Atheros F1 10/100/1000 PHY PHY 0 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow $ devinfo -rv | grep atphy atphy0 pnpinfo oui=0xc82e model=0x1 rev=0x9 at phyno=0 Hmm, it's still not clear whether the controller is Gigabit or not. Could you try attached patch and let me the output? ale_flags = 0x0040 Thanks for the info. Indeed, your controller is AR8121 Gigabit etherent(L1E). I guess the PHY initialization is not complete. Would you try attached patch? ./danfe Index: sys/dev/ale/if_ale.c === --- sys/dev/ale/if_ale.c(revision 246937) +++ sys/dev/ale/if_ale.c(working copy) @@ -406,11 +406,11 @@ CSR_WRITE_2(sc, ALE_GPHY_CTRL, GPHY_CTRL_HIB_EN | GPHY_CTRL_HIB_PULSE | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_PLL_ON); - DELAY(1000); + DELAY(2000); CSR_WRITE_2(sc, ALE_GPHY_CTRL, GPHY_CTRL_EXT_RESET | GPHY_CTRL_HIB_EN | GPHY_CTRL_HIB_PULSE | GPHY_CTRL_SEL_ANA_RESET | GPHY_CTRL_PHY_PLL_ON); - DELAY(1000); + DELAY(2000); #defineATPHY_DBG_ADDR 0x1D #defineATPHY_DBG_DATA 0x1E ___ 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: ale(4) cannot negotiate as GigE
On Fri, Feb 22, 2013 at 10:13:08AM +0900, YongHyeon PYUN wrote: On Thu, Feb 21, 2013 at 12:43:44PM +, Alexey Dokuchaev wrote: ale_flags = 0x0040 Thanks for the info. Indeed, your controller is AR8121 Gigabit etherent(L1E). I guess the PHY initialization is not complete. Would you try attached patch? Thanks for the patch. Unfortunately, it's still 100baseTX full-duplex after driver reload. Even tried delaying for 3000, no difference. :( ./danfe ___ 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: No ZFS when loading modules from loeader prompt
I haven't used BEs yet, as I have no ZFS-on-root systems. I just know that's how they're supposed to work, and that's the desired use case for them. Vermaden from FreeBSD Forums would be a better one to ask, as he uses them a lot and was one of the people behind BE support in FreeBSD. On 2013-02-21 4:38 PM, Peter Jeremy pe...@rulingia.com wrote: On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: At the loader prompt, I need to unload the buggy kernel and load the old working one via load /boot/kernel.old/kernel Then I load also the ZFS related modules load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko Issuing boot at the end of that stage boots the kernel - the old one -successfully - but there is no working ZFS and no ZFS volume gets mounted although the rc.conf is executed correctly. What am I doing wrong at that point? Why isn't ZFS run and mount properly? Last time I ran into this problem, the issue was that unload also unloaded the zpool.cache file and the ZFS code relied on that to find the kernel. I don't recall what the workaround was. On 2013-Feb-20 08:17:46 -0800, Freddie Cash fjwc...@gmail.com wrote: Sounds like a perfect use case for Boot Environments. Create a new BE, install the new kernel into it, set it as the default, reboot. If it fails, you manually set the previous BE as the default, and reboot. That way, your known-good, working environment is never affected. How do you change your BE in the loader? Or how do you change your BE when you can't boot? -- Peter Jeremy ___ 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
FreeBSD current rev today about 1-2pm
I updated current today and now the system refuses to boot and my 3ware card constantly has it's LED on and it resets. booting the old kernel boots up fine ? ___ 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: [RFC/RFT] calloutng
The patch has been splitted in smaller logical chunks in order to
improve readability and facilitate review.
The whole code can be found here:
http://people.freebsd.org/~davide/calloutng_split/
In particular:
http://people.freebsd.org/~davide/calloutng_split/sbintime.diff brings
the new type 32.32 fixed point used in lieu of 'int ticks' for the new
callout mechanism and relative functions (conversion from to
{timeval,bintime,timespec}, sbinuptime(), getsbinuptime())
This change is preliminary to
http://people.freebsd.org/~davide/calloutng_split/callout_internals.diff
which contains all the callout changes internally (introduction of
direct dispatching, conversion to sbintime, new precision mechanism)
http://people.freebsd.org/~davide/calloutng_split/cpuidle.diff (see
r242905) introduce some optimization in the sleep time calculation
and choose of the optimal sleep state, when CPU is idle.
http://people.freebsd.org/~mav/calloutng-20130221/libprocstatfix.diff
is a workaround in libprocstat in order to allow world to build after
changes. About this one, I'm not quite sure is the best solution, so
if there are other opinions, I'd be more than happy to hear.
Other patches available in the directory converts some kernel
consumers of callout(9) to the new interface (nanosleep, poll, select,
kqueue, syscons, etc...).
My plan is to commit the whole patchset March 4th, unless there are
valid reasons to not do so.
Any cooment is (as always) appreciated.
Thanks,
Davide
___
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 current rev today about 1-2pm
On Thu, Feb 21, 2013 at 09:50:11PM -0600, Chris wrote: I updated current today and now the system refuses to boot and my 3ware card constantly has it's LED on and it resets. booting the old kernel boots up fine ? Which timezone? 1-2pm is a little ambiguous. Do you have sources with revision 247117 or later? -- Steve ___ 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 current rev today about 1-2pm
On 2/21/2013 9:54 PM, Steve Kargl wrote: On Thu, Feb 21, 2013 at 09:50:11PM -0600, Chris wrote: I updated current today and now the system refuses to boot and my 3ware card constantly has it's LED on and it resets. booting the old kernel boots up fine ? Which timezone? 1-2pm is a little ambiguous. Do you have sources with revision 247117 or later? Timezone is CST -6 GMT Working kernel is from 02-11-2012 non working kernel is from today around that time. I am not on the FreeBSD box to check actual rev. ___ 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 current rev today about 1-2pm
On 02/21/13 19:58, Chris wrote: On 2/21/2013 9:54 PM, Steve Kargl wrote: On Thu, Feb 21, 2013 at 09:50:11PM -0600, Chris wrote: I updated current today and now the system refuses to boot and my 3ware card constantly has it's LED on and it resets. booting the old kernel boots up fine ? Which timezone? 1-2pm is a little ambiguous. Do you have sources with revision 247117 or later? Timezone is CST -6 GMT Working kernel is from 02-11-2012 non working kernel is from today around that time. I am not on the FreeBSD box to check actual rev. ___ 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 Sounds like the problem from yesterday, my mps0 didn't get to come up before the system hung. It looked like a storage system failure. Get newer sources and try again. Get them from svn, not sure what csup is doing anymore. The patch came around 19:13 GMT. http://freshbsd.org/commit/freebsd/r247117 Matt ___ 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 current rev today about 1-2pm
On 2/21/2013 10:42 PM, matt wrote: On 02/21/13 19:58, Chris wrote: On 2/21/2013 9:54 PM, Steve Kargl wrote: On Thu, Feb 21, 2013 at 09:50:11PM -0600, Chris wrote: I updated current today and now the system refuses to boot and my 3ware card constantly has it's LED on and it resets. booting the old kernel boots up fine ? Which timezone? 1-2pm is a little ambiguous. Do you have sources with revision 247117 or later? Timezone is CST -6 GMT Working kernel is from 02-11-2012 non working kernel is from today around that time. I am not on the FreeBSD box to check actual rev. ___ 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 Sounds like the problem from yesterday, my mps0 didn't get to come up before the system hung. It looked like a storage system failure. Get newer sources and try again. Get them from svn, not sure what csup is doing anymore. The patch came around 19:13 GMT. http://freshbsd.org/commit/freebsd/r247117 Matt ___ 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 I will try again tomorrow. Thank you for the heads up :) ___ 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
r245741 (clang as cc) can not build binaries for GEODE processor
Hello, freebsd-current. I have -CURRENT i386 installation which runs r245741 now. Default compiler is clang: cc --version FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: i386-unknown-freebsd10.0 Thread model: posix This system is used to build NanoBSD images (and ports for these images) for my home router, which has AMD Geode CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) Build system has only one setting in /etc/src.conf and /etc/make.conf: MALLOC_PRODUCTION=yes NanoBSD image build includes many options, and CPUTYPE=geode is among them. Today I've rebuilt all ports (including samba36) and image (from r247117). And new samba port (samba36-3.6.12) failed to start on target system (with Geode CPU). It gets SIGILL (!!!). I was able to get core file by running testparam in NFS-mounted R/W file system, but after that GDB (on build system, as NanoBSD image doesn't contain one) says, that it could not access memory at failure address to show disassembly: gdb /usr/local/bin/testparm ~/testparm.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... Core was generated by `testparm'. Program terminated with signal 4, Illegal instruction. #0 0x010351d6 in ?? () (gdb) x/i $pc 0x10351d6: Cannot access memory at address 0x10351d6 (gdb) bt #0 0x010351d6 in ?? () #1 0x in ?? () (gdb) -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: No ZFS when loading modules from loeader prompt
on 22/02/2013 02:38 Peter Jeremy said the following: On Wed, Feb 20, 2013 at 7:05 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: At the loader prompt, I need to unload the buggy kernel and load the old working one via load /boot/kernel.old/kernel Then I load also the ZFS related modules load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko Issuing boot at the end of that stage boots the kernel - the old one -successfully - but there is no working ZFS and no ZFS volume gets mounted although the rc.conf is executed correctly. What am I doing wrong at that point? Why isn't ZFS run and mount properly? Last time I ran into this problem, the issue was that unload also unloaded the zpool.cache file and the ZFS code relied on that to find the kernel. I don't recall what the workaround was. zpool.cache should not be required any longer for the root pool. It is still required to auto-import other pools after boot. On 2013-Feb-20 08:17:46 -0800, Freddie Cash fjwc...@gmail.com wrote: Sounds like a perfect use case for Boot Environments. Create a new BE, install the new kernel into it, set it as the default, reboot. If it fails, you manually set the previous BE as the default, and reboot. That way, your known-good, working environment is never affected. How do you change your BE in the loader? Or how do you change your BE when you can't boot? Short answer: you set currdev in loader prompt. A high-level overview of FreeBSD ZFS boot process is here: http://ru.kyivbsd.org.ua/arhiv/2012/kyivbsd12-gapon-zfs.pdf?attredirects=0d=1 Section ZFS Boot Process -- Andriy Gapon ___ 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
