Re: ucom_free Fatal trap on shutdown / module unload
Hi Johannes, Thank you for your patience! http://svnweb.freebsd.org/changeset/base/268078 --HPS ___ 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 --- 2014-07-01 06:20:57 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-01 06:20:57 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-01 06:20:57 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2014-07-01 06:20:57 - cleaning the object tree TB --- 2014-07-01 06:21:57 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-01 06:22:01 - At svn revision 268065 TB --- 2014-07-01 06:22:02 - building world TB --- 2014-07-01 06:22:02 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 06:22:02 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 06:22:02 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 06:22:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 06:22:02 - SRCCONF=/dev/null TB --- 2014-07-01 06:22:02 - TARGET=sparc64 TB --- 2014-07-01 06:22:02 - TARGET_ARCH=sparc64 TB --- 2014-07-01 06:22:02 - TZ=UTC TB --- 2014-07-01 06:22:02 - __MAKE_CONF=/dev/null TB --- 2014-07-01 06:22:02 - cd /src TB --- 2014-07-01 06:22:02 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jul 1 06:22:09 UTC 2014 >>> 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 Tue Jul 1 07:35:57 UTC 2014 TB --- 2014-07-01 07:35:57 - generating LINT kernel config TB --- 2014-07-01 07:35:57 - cd /src/sys/sparc64/conf TB --- 2014-07-01 07:35:57 - /usr/bin/make -B LINT TB --- 2014-07-01 07:35:57 - cd /src/sys/sparc64/conf TB --- 2014-07-01 07:35:57 - /obj/sparc64.sparc64/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-01 07:35:57 - building LINT kernel TB --- 2014-07-01 07:35:57 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 07:35:57 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 07:35:57 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 07:35:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 07:35:57 - SRCCONF=/dev/null TB --- 2014-07-01 07:35:57 - TARGET=sparc64 TB --- 2014-07-01 07:35:57 - TARGET_ARCH=sparc64 TB --- 2014-07-01 07:35:57 - TZ=UTC TB --- 2014-07-01 07:35:57 - __MAKE_CONF=/dev/null TB --- 2014-07-01 07:35:57 - cd /src TB --- 2014-07-01 07:35:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 1 07:35:57 UTC 2014 >>> 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 [...] ld -b binary --no-warn-mismatch -d -warn-common -r -o t5fw_cfg.fwo t5fw_cfg.fw uudecode -o t5fw.fw /src/sys/dev/cxgbe/firmware/t5fw-1.11.27.0.bin.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o t5fw.fwo t5fw.fw 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-builtin -ffreestanding -fstack-protector -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -Werror /src/sys/dev/dc/if_dc.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-builtin -ffreestanding -fstack-protector -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -Werror /src/sys/dev/dc/dcphy.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-builtin -ffreestanding -fstack-protector -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -Werror /src/sys/dev/dc/pnphy.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmi
Re: FreeBSD iscsi target
Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: > Does freebsd iscsi target supports: > 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. > 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) > 3. Multiple connections per session No; see above. > 4. Dynamic Lun allocation/resize Yes. > 5. Target redirection It's in Perforce; I'll try to get it into 11-HEAD shortly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc/powerpc
TB --- 2014-07-01 05:50:42 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-01 05:50:42 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-01 05:50:42 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2014-07-01 05:50:42 - cleaning the object tree TB --- 2014-07-01 05:51:58 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-01 05:52:05 - At svn revision 268065 TB --- 2014-07-01 05:52:06 - building world TB --- 2014-07-01 05:52:06 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 05:52:06 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 05:52:06 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 05:52:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 05:52:06 - SRCCONF=/dev/null TB --- 2014-07-01 05:52:06 - TARGET=powerpc TB --- 2014-07-01 05:52:06 - TARGET_ARCH=powerpc TB --- 2014-07-01 05:52:06 - TZ=UTC TB --- 2014-07-01 05:52:06 - __MAKE_CONF=/dev/null TB --- 2014-07-01 05:52:06 - cd /src TB --- 2014-07-01 05:52:06 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jul 1 05:52:13 UTC 2014 >>> 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 Tue Jul 1 09:36:23 UTC 2014 TB --- 2014-07-01 09:36:23 - generating LINT kernel config TB --- 2014-07-01 09:36:23 - cd /src/sys/powerpc/conf TB --- 2014-07-01 09:36:23 - /usr/bin/make -B LINT TB --- 2014-07-01 09:36:23 - cd /src/sys/powerpc/conf TB --- 2014-07-01 09:36:23 - /obj/powerpc.powerpc/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-01 09:36:23 - building LINT kernel TB --- 2014-07-01 09:36:23 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 09:36:23 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 09:36:23 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 09:36:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 09:36:23 - SRCCONF=/dev/null TB --- 2014-07-01 09:36:23 - TARGET=powerpc TB --- 2014-07-01 09:36:23 - TARGET_ARCH=powerpc TB --- 2014-07-01 09:36:23 - TZ=UTC TB --- 2014-07-01 09:36:23 - __MAKE_CONF=/dev/null TB --- 2014-07-01 09:36:23 - cd /src TB --- 2014-07-01 09:36:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 1 09:36:23 UTC 2014 >>> 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 [...] ld -b binary --no-warn-mismatch -d -warn-common -r -o t4fw.fwo t4fw.fw cc -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-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -c t5fw_cfg.c cp /src/sys/dev/cxgbe/firmware/t5fw_cfg.txt t5fw_cfg.fw ld -b binary --no-warn-mismatch -d -warn-common -r -o t5fw_cfg.fwo t5fw_cfg.fw uudecode -o t5fw.fw /src/sys/dev/cxgbe/firmware/t5fw-1.11.27.0.bin.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o t5fw.fwo t5fw.fw 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-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -Werror /src/sys/dev/dc/if_dc.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-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector
[head tinderbox] failure on powerpc64/powerpc
TB --- 2014-07-01 06:02:07 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-01 06:02:07 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-01 06:02:07 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2014-07-01 06:02:07 - cleaning the object tree TB --- 2014-07-01 06:03:52 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-01 06:03:55 - At svn revision 268065 TB --- 2014-07-01 06:03:56 - building world TB --- 2014-07-01 06:03:56 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 06:03:56 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 06:03:56 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 06:03:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 06:03:56 - SRCCONF=/dev/null TB --- 2014-07-01 06:03:56 - TARGET=powerpc TB --- 2014-07-01 06:03:56 - TARGET_ARCH=powerpc64 TB --- 2014-07-01 06:03:56 - TZ=UTC TB --- 2014-07-01 06:03:56 - __MAKE_CONF=/dev/null TB --- 2014-07-01 06:03:56 - cd /src TB --- 2014-07-01 06:03:56 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jul 1 06:04:03 UTC 2014 >>> 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 Tue Jul 1 10:19:25 UTC 2014 TB --- 2014-07-01 10:19:25 - generating LINT kernel config TB --- 2014-07-01 10:19:25 - cd /src/sys/powerpc/conf TB --- 2014-07-01 10:19:25 - /usr/bin/make -B LINT TB --- 2014-07-01 10:19:25 - cd /src/sys/powerpc/conf TB --- 2014-07-01 10:19:25 - /obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-01 10:19:25 - skipping LINT kernel TB --- 2014-07-01 10:19:25 - cd /src/sys/powerpc/conf TB --- 2014-07-01 10:19:25 - /obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin/config -m GENERIC TB --- 2014-07-01 10:19:25 - skipping GENERIC kernel TB --- 2014-07-01 10:19:25 - cd /src/sys/powerpc/conf TB --- 2014-07-01 10:19:25 - /obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin/config -m GENERIC64 TB --- 2014-07-01 10:19:25 - building GENERIC64 kernel TB --- 2014-07-01 10:19:25 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 10:19:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 10:19:25 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 10:19:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 10:19:25 - SRCCONF=/dev/null TB --- 2014-07-01 10:19:25 - TARGET=powerpc TB --- 2014-07-01 10:19:25 - TARGET_ARCH=powerpc64 TB --- 2014-07-01 10:19:25 - TZ=UTC TB --- 2014-07-01 10:19:25 - __MAKE_CONF=/dev/null TB --- 2014-07-01 10:19:25 - cd /src TB --- 2014-07-01 10:19:25 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Tue Jul 1 10:19:26 UTC 2014 >>> 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 [...] ctfconvert -L VERSION -g if_bge.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -gdwarf-2 -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -Werror /src/sys/dev/cpufreq/ichss.c ctfconvert -L VERSION -g ichss.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -gdwarf-2 -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -Werror /src/sys/dev/dc/if_dc.c ctfconvert -L VERSION -g if_dc.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiag
Re: [CURRENT]: weird memory/linker problem?
Am Mon, 23 Jun 2014 17:22:25 +0200
Dimitry Andric schrieb:
> On 23 Jun 2014, at 16:31, O. Hartmann wrote:
> > Am Sun, 22 Jun 2014 10:10:04 -0700
> > Adrian Chadd schrieb:
> >> When they segfault, where do they segfault?
> ...
> > GIMP, LaTeX work, nothing special, but a bit memory consuming regrading
> > GIMP) I tried
> > updating the ports tree and surprisingly the tree is left over in a unclean
> > condition
> > while /usr/bin/svn segfault (on console: pid 18013 (svn), uid 0: exited on
> > signal 11
> > (core dumped)).
> >
> > Using /usr/local/bin/svn, which is from the devel/subversion port, performs
> > well,
> > while FreeBSD 11's svn contribution dies as described. It did not hours ago!
>
> I think what Adrian meant was: can you run svn (or another crashing
> program) in gdb, and post a backtrace? Or maybe run ktrace, and see
> where it dies?
>
> Alternatively, put a core dump and the executable (with debug info) in a
> tarball, and upload it somewhere, so somebody else can analyze it.
>
> -Dimitry
>
It's me again, with the same weird story.
After a couple of days silence, the mysterious entity in my computer is back.
This time
it is again a weird compiler message of failure (trying to buildworld):
[...]
c++ -O2 -pipe -O3 -O3
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
-Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11
-fno-exceptions
-fno-rtti -Wno-c++11-extensions
-c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Host.cpp
-o Host.o
--- GraphWriter.o --- In file included
from
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/GraphWriter.cpp:14:
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/GraphWriter.h:269:10:
error: use of undeclared identifier 'DOD'; did you mean 'DOT'? O <<
DOD::EscapeString(Label); ^~~
DOT
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/GraphWriter.h:35:11:
note: 'DOT' declared here namespace DOT { // Private functions... ^ 1 error
generated.
*** [GraphWriter.o] Error code 1
Well, in the past I saw many of those messages, especially not found labels of
routines
in shared objects/libraries or even those "funny" misspelled messages shown
above.
I can not reproduce them after a reboot, but as long as the system is running
with this
error occured, it is sticky. So in order to compile the OS successfully, I
reboot.
Does anyone have an idea what this could be? Since it affects at the moment
only one
machine (the other CoreDuo has been retired in the meanwhile), it feels a bit
like a
miscompilation on a certain type of CPU.
Thanks for your patience,
Oliver
signature.asc
Description: PGP signature
[head tinderbox] failure on arm/arm
TB --- 2014-07-01 10:30:46 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-01 10:30:46 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-01 10:30:46 - starting HEAD tinderbox run for arm/arm TB --- 2014-07-01 10:30:46 - cleaning the object tree TB --- 2014-07-01 10:30:46 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-01 10:30:51 - At svn revision 268087 TB --- 2014-07-01 10:30:52 - building world TB --- 2014-07-01 10:30:52 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 10:30:52 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 10:30:52 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 10:30:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 10:30:52 - SRCCONF=/dev/null TB --- 2014-07-01 10:30:52 - TARGET=arm TB --- 2014-07-01 10:30:52 - TARGET_ARCH=arm TB --- 2014-07-01 10:30:52 - TZ=UTC TB --- 2014-07-01 10:30:52 - __MAKE_CONF=/dev/null TB --- 2014-07-01 10:30:52 - cd /src TB --- 2014-07-01 10:30:52 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jul 1 10:30:59 UTC 2014 >>> 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 Tue Jul 1 13:50:26 UTC 2014 TB --- 2014-07-01 13:50:26 - generating LINT kernel config TB --- 2014-07-01 13:50:26 - cd /src/sys/arm/conf TB --- 2014-07-01 13:50:26 - /usr/bin/make -B LINT TB --- 2014-07-01 13:50:26 - cd /src/sys/arm/conf TB --- 2014-07-01 13:50:26 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-01 13:50:26 - building LINT kernel TB --- 2014-07-01 13:50:26 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 13:50:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 13:50:26 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 13:50:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 13:50:26 - SRCCONF=/dev/null TB --- 2014-07-01 13:50:26 - TARGET=arm TB --- 2014-07-01 13:50:26 - TARGET_ARCH=arm TB --- 2014-07-01 13:50:26 - TZ=UTC TB --- 2014-07-01 13:50:26 - __MAKE_CONF=/dev/null TB --- 2014-07-01 13:50:26 - cd /src TB --- 2014-07-01 13:50:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 1 13:50:26 UTC 2014 >>> 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 [...] machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `kernelstack' at91_machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `minidataclean' ep80219_machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `msgbufpv' at91_machdep.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_mem' uart_cpu_fdt.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_io' uart_cpu_fdt.o: warning: previous common is here kbd.o: In function `kbd_register': /src/sys/dev/kbd/kbd.c:(.text+0x42c): undefined reference to `__stop_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x430): undefined reference to `__start_set_kbddriver_set' kbd.o: In function `kbd_get_switch': /src/sys/dev/kbd/kbd.c:(.text+0x5c0): undefined reference to `__start_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x5c4): undefined reference to `__stop_set_kbddriver_set' kbd.o: In function `kbd_configure': /src/sys/dev/kbd/kbd.c:(.text+0x898): undefined reference to `__start_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x89c): undefined reference to `__stop_set_kbddriver_set' *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-07-01 14:07:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-07-01 14:07:48 - ERROR: failed to build LINT kernel TB --- 2014-07-01 14:07:48 - 10431.13 user 1766.10 system 13021.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.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 and utf-8 directory names
M&S - Krasznai András wrote, On 06/30/2014 08:30: There is a partition formatted for FAT32 where I store documents which I would like to view (and edit) both in windows and freebsd. The problem is that if the path name contains certain Hungarian characters (e.g o with double accent), then libreoffice in FreeBSD refuses to open them complaining about illegal characters. The directory was created in windows, the document also, and I can handle them perfectly from windows (what is more, libreoffice under a linux can also open those documents). Some accented characters are shown as a question mark in FreeBSD, and some others are as a black rectangle; these latter are causing problems. If a file-nam contains such characters then the file is shown as 0- length in Midnight Commander. This is not limited to Hungarian characters. There are bugs in FreeBSD's FAT handling code. According to an IRC discussion with "mux", FreeBSD has plenty of VOP_LOOKUP bugs, and this case hits such a bug. To allow FreeBSD to read files with fancy UTF-8 characters in their names, mount the FAT32 partition with ``-o shortnames''. Then, you won't be able to use proper file naming (so this is not even a workaround), but at least you'll be able to read the said files. Poke the FreeBSD developers to start fixing bugs, maybe (but not very likely) that will help. Also, you're at least the 3rd user (I'm at least the 2nd) that runs into this case; ie., here's a report: http://forums.freebsd.org/showthread.php?t=14612 (of course, this does not contain a solution). ___ 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]: weird memory/linker problem?
DOT => DOD
444F54 => 444F44
That's a single-bit flip. Bad memory, perhaps?
Anton
-Original Message-
From: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of O. Hartmann
Sent: Tuesday, July 01, 2014 8:08 AM
To: Dimitry Andric
Cc: Adrian Chadd; FreeBSD CURRENT
Subject: Re: [CURRENT]: weird memory/linker problem?
Am Mon, 23 Jun 2014 17:22:25 +0200
Dimitry Andric schrieb:
> On 23 Jun 2014, at 16:31, O. Hartmann wrote:
> > Am Sun, 22 Jun 2014 10:10:04 -0700
> > Adrian Chadd schrieb:
> >> When they segfault, where do they segfault?
> ...
> > GIMP, LaTeX work, nothing special, but a bit memory consuming
> > regrading GIMP) I tried updating the ports tree and surprisingly the
> > tree is left over in a unclean condition while /usr/bin/svn segfault
> > (on console: pid 18013 (svn), uid 0: exited on signal 11 (core dumped)).
> >
> > Using /usr/local/bin/svn, which is from the devel/subversion port,
> > performs well, while FreeBSD 11's svn contribution dies as described. It
> > did not hours ago!
>
> I think what Adrian meant was: can you run svn (or another crashing
> program) in gdb, and post a backtrace? Or maybe run ktrace, and see
> where it dies?
>
> Alternatively, put a core dump and the executable (with debug info) in
> a tarball, and upload it somewhere, so somebody else can analyze it.
>
> -Dimitry
>
It's me again, with the same weird story.
After a couple of days silence, the mysterious entity in my computer is back.
This time it is again a weird compiler message of failure (trying to
buildworld):
[...]
c++ -O2 -pipe -O3 -O3
c++ -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
-Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11
-fno-exceptions -fno-rtti -Wno-c++11-extensions -c
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Host.cpp -o
Host.o
--- GraphWriter.o --- In file included
from
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/GraphWriter.cpp:14:
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/GraphWriter.h:269:10:
error: use of undeclared identifier 'DOD'; did you mean 'DOT'? O <<
DOD::EscapeString(Label); ^~~ DOT
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/GraphWriter.h:35:11:
note: 'DOT' declared here namespace DOT { // Private functions... ^ 1 error
generated.
*** [GraphWriter.o] Error code 1
Well, in the past I saw many of those messages, especially not found labels of
routines in shared objects/libraries or even those "funny" misspelled messages
shown above.
I can not reproduce them after a reboot, but as long as the system is running
with this error occured, it is sticky. So in order to compile the OS
successfully, I reboot.
Does anyone have an idea what this could be? Since it affects at the moment
only one machine (the other CoreDuo has been retired in the meanwhile), it
feels a bit like a miscompilation on a certain type of CPU.
Thanks for your patience,
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: freebsd and utf-8 directory names
Hi, I am not very satisfied with this situation. Today I was looking up the Hungarian FreeBSD site, but the Hungarian translation of the handbook deals only with settings for German, Russian and Japanese environment. A little additional info: I installed xfe (x11-fm/xfe) file manager in the same freebsd configuration. This application displays and handles those diretories and files perfectly, but as soon as I want to open such a file with double click on it (I set xfe to invoke libreoffice in this case) libreoffice still refuses to open the file. Even midnight commander fails to handle such files. What does xfe do differently? rgds András -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of d...@gmx.com Sent: Tuesday, July 01, 2014 4:42 PM To: freebsd-current@freebsd.org Subject: Re: freebsd and utf-8 directory names M&S - Krasznai András wrote, On 06/30/2014 08:30: > There is a partition formatted for FAT32 where I store documents which I > would like to view (and edit) both in windows and freebsd. > > The problem is that if the path name contains certain Hungarian characters > (e.g o with double accent), then libreoffice in FreeBSD refuses to open them > complaining about illegal characters. The directory was created in windows, > the document also, and I can handle them perfectly from windows (what is > more, libreoffice under a linux can also open those documents). Some accented > characters are shown as a question mark in FreeBSD, and some others are as a > black rectangle; these latter are causing problems. If a file-nam contains > such characters then the file is shown as 0- length in Midnight Commander. This is not limited to Hungarian characters. There are bugs in FreeBSD's FAT handling code. According to an IRC discussion with "mux", FreeBSD has plenty of VOP_LOOKUP bugs, and this case hits such a bug. To allow FreeBSD to read files with fancy UTF-8 characters in their names, mount the FAT32 partition with ``-o shortnames''. Then, you won't be able to use proper file naming (so this is not even a workaround), but at least you'll be able to read the said files. Poke the FreeBSD developers to start fixing bugs, maybe (but not very likely) that will help. Also, you're at least the 3rd user (I'm at least the 2nd) that runs into this case; ie., here's a report: http://forums.freebsd.org/showthread.php?t=14612 (of course, this does not contain a solution). ___ 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: freebsd and utf-8 directory names
M&S - Krasznai András wrote, On 07/01/2014 17:07: I installed xfe (x11-fm/xfe) file manager in the same freebsd configuration. This application displays and handles those diretories and files perfectly, but as soon as I want to open such a file with double click on it (I set xfe to invoke libreoffice in this case) libreoffice still refuses to open the file. [...] What does xfe do differently? What do you mean by "handling and displaying properly"? Listing (directory contents) is one thing, being able to stat or open the file is different. ___ 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]: weird memory/linker problem?
On 2014-07-01 16:48, Rang, Anton wrote:
DOT => DOD
444F54 => 444F44
That's a single-bit flip. Bad memory, perhaps?
Very likely, especially if the system does not have ECC
It just happens on rare occasions that a alpha particle, power cycle, or
any things else disruptive damages a memory cell. And it could be that
it requires a special pattern of accesses to actually exhibit the error.
In the past (199x's) 'make buildworld' used to be a rather good memory
tester. But nowadays look at
http://www.memtest.org/
This tool has found all of the bad memory in all the systems I used and
or build for others...
Note that it might take a few runs and some more heat to actually
trigger the faulty cell, but memtest86 will usually find it.
Note that on big systems with lots of memory it can take a loong
time to run just one full testset to completion.
--WjW
Anton
-Original Message-
From: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of O. Hartmann
Sent: Tuesday, July 01, 2014 8:08 AM
To: Dimitry Andric
Cc: Adrian Chadd; FreeBSD CURRENT
Subject: Re: [CURRENT]: weird memory/linker problem?
Am Mon, 23 Jun 2014 17:22:25 +0200
Dimitry Andric schrieb:
On 23 Jun 2014, at 16:31, O. Hartmann wrote:
Am Sun, 22 Jun 2014 10:10:04 -0700
Adrian Chadd schrieb:
When they segfault, where do they segfault?
...
GIMP, LaTeX work, nothing special, but a bit memory consuming
regrading GIMP) I tried updating the ports tree and surprisingly the
tree is left over in a unclean condition while /usr/bin/svn segfault
(on console: pid 18013 (svn), uid 0: exited on signal 11 (core dumped)).
Using /usr/local/bin/svn, which is from the devel/subversion port,
performs well, while FreeBSD 11's svn contribution dies as described. It did
not hours ago!
I think what Adrian meant was: can you run svn (or another crashing
program) in gdb, and post a backtrace? Or maybe run ktrace, and see
where it dies?
Alternatively, put a core dump and the executable (with debug info) in
a tarball, and upload it somewhere, so somebody else can analyze it.
-Dimitry
It's me again, with the same weird story.
After a couple of days silence, the mysterious entity in my computer is back.
This time it is again a weird compiler message of failure (trying to
buildworld):
[...]
c++ -O2 -pipe -O3 -O3
c++ -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
-Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11
-fno-exceptions -fno-rtti -Wno-c++11-extensions -c
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Host.cpp -o
Host.o
--- GraphWriter.o --- In file included
from
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/GraphWriter.cpp:14:
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/GraphWriter.h:269:10:
error: use of undeclared identifier 'DOD'; did you mean 'DOT'? O <<
DOD::EscapeString(Label); ^~~ DOT
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/GraphWriter.h:35:11:
note: 'DOT' declared here namespace DOT { // Private functions... ^ 1 error
generated.
*** [GraphWriter.o] Error code 1
Well, in the past I saw many of those messages, especially not found labels of routines
in shared objects/libraries or even those "funny" misspelled messages shown
above.
I can not reproduce them after a reboot, but as long as the system is running
with this error occured, it is sticky. So in order to compile the OS
successfully, I reboot.
Does anyone have an idea what this could be? Since it affects at the moment
only one machine (the other CoreDuo has been retired in the meanwhile), it
feels a bit like a miscompilation on a certain type of CPU.
Thanks for your patience,
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"
___
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"
userland breakage, zfs ?
Just updated two machines in the fbsd cluser, buildworld/kernel, installkernel, reboot into single user. zfs from oldworld (pre installworld) doesn't work and segfaults in new and magical ways. Trying to mount root from zfs:zroot []... Enter full pathname of shell or RETURN for /bin/sh: Cannot read termcap database; using dumb terminal settings. # zfs set readonly=off zroot internal error: pInvalid argumentid 19 (zfs), uid 0: exited on signal 6 Abort trap I guess, I could multiuser the box on old kernel and installworld from multiuser, but this could lead to disaster. I see no indication of ABI breakage of this kind in UPDATING, so ... any ideas? sean ___ 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 and utf-8 directory names
Den 30. juni 2014 08:56, skrev Rainer Hurling: Am 30.06.2014 08:30 (UTC+1) schrieb M&S - Krasznai András: Hi I have been using FreeBSD as desktop since 2003, and living in a mixed (windows-linux) environment I installed FreeBSd along with my usual (Windows 7) work environment, I have a dualboot configured laptop. I use FreeBSD-10 STABLE. There is a partition formatted for FAT32 where I store documents which I would like to view (and edit) both in windows and freebsd. The problem is that if the path name contains certain Hungarian characters (e.g o with double accent), then libreoffice in FreeBSD refuses to open them complaining about illegal characters. The directory was created in windows, the document also, and I can handle them perfectly from windows (what is more, libreoffice under a linux can also open those documents). Some accented characters are shown as a question mark in FreeBSD, and some others are as a black rectangle; these latter are causing problems. If a file-nam contains such characters then the file is shown as 0- length in Midnight Commander. I tried some steps described in the „Localization” part of the FreeBSD Handbook, but things did not improve. I installed PC-BSD with Hungarian language support, thinking that it would handle the localized directory names correctly but no, it gives the same error message. This problem is really annoying. How could I solve it? In my German environment I also use FAT32 formatted drives, mounted like: /dev/adaXsX /XXXmsdosfs rw,large,-Lde_DE.UTF-8 0 0 This should also work for Hungarian? I second this advice, it should work well for any language (It certainly is fine for my Norwegian). To expand on Rainer's suggestion: The -L parameter in the mount line is from the mount_msdosfs(8) utility. The man page says: -L locale Specify locale name used for file name conversions for DOS and Win'95 names. By default ISO 8859-1 assumed as local character set. The locale of your environment and mount command must match. In my case it is: LC_CTYPE=no_NO.UTF-8 mount_msdosfs -L no_NO.UTF-8 /dev/da3s1 /mnt/tmp (Regarding whether the default of ISO 8859-1 for mount_msdosfs should be changed to some UTF-8 locale to better match what people are using in this age is an entirely different matter. ;-) Best regards, Gyrd ^_^ HTH, Rainer Hurling Krasznai András rendszermérnök M&S Informatikai Zrt. 1136 Budapest, Pannónia u. 17/A. Telefon: +36 1 703-2923 Mobil:+36 30 703-2923 ___ 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: [CURRENT]: weird memory/linker problem?
Am Tue, 01 Jul 2014 17:23:14 +0200
Willem Jan Withagen schrieb:
> On 2014-07-01 16:48, Rang, Anton wrote:
> > DOT => DOD
> >
> > 444F54 => 444F44
> >
> > That's a single-bit flip. Bad memory, perhaps?
>
> Very likely, especially if the system does not have ECC
> It just happens on rare occasions that a alpha particle, power cycle, or
> any things else disruptive damages a memory cell. And it could be that
> it requires a special pattern of accesses to actually exhibit the error.
>
> In the past (199x's) 'make buildworld' used to be a rather good memory
> tester. But nowadays look at
> http://www.memtest.org/
>
> This tool has found all of the bad memory in all the systems I used and
> or build for others...
> Note that it might take a few runs and some more heat to actually
> trigger the faulty cell, but memtest86 will usually find it.
>
> Note that on big systems with lots of memory it can take a loong
> time to run just one full testset to completion.
>
> --WjW
I already testet via memtest86+ (had to download the linux image, the port on
FreeBSD is
broken on CURRENT). It didn't find anything strange so far.
I will do another test.
I realised, that on that that specific box, the chipset temperature is 81 Grad
Celius.
The chipset is a Eaglelake P45 - in which the memory controller resides on that
old
platform. dmidecode gives:
Manufacturer: ASUSTeK Computer INC.
Product Name: P5Q-WS
Version: Rev 1.xx
>
>
> >
> > Anton
> >
> > -Original Message-
> > From: owner-freebsd-curr...@freebsd.org
> > [mailto:owner-freebsd-curr...@freebsd.org] On
> > Behalf Of O. Hartmann Sent: Tuesday, July 01, 2014 8:08 AM
> > To: Dimitry Andric
> > Cc: Adrian Chadd; FreeBSD CURRENT
> > Subject: Re: [CURRENT]: weird memory/linker problem?
> >
> > Am Mon, 23 Jun 2014 17:22:25 +0200
> > Dimitry Andric schrieb:
> >
> >> On 23 Jun 2014, at 16:31, O. Hartmann wrote:
> >>> Am Sun, 22 Jun 2014 10:10:04 -0700
> >>> Adrian Chadd schrieb:
> When they segfault, where do they segfault?
> >> ...
> >>> GIMP, LaTeX work, nothing special, but a bit memory consuming
> >>> regrading GIMP) I tried updating the ports tree and surprisingly the
> >>> tree is left over in a unclean condition while /usr/bin/svn segfault
> >>> (on console: pid 18013 (svn), uid 0: exited on signal 11 (core dumped)).
> >>>
> >>> Using /usr/local/bin/svn, which is from the devel/subversion port,
> >>> performs well, while FreeBSD 11's svn contribution dies as described. It
> >>> did not
> >>> hours ago!
> >>
> >> I think what Adrian meant was: can you run svn (or another crashing
> >> program) in gdb, and post a backtrace? Or maybe run ktrace, and see
> >> where it dies?
> >>
> >> Alternatively, put a core dump and the executable (with debug info) in
> >> a tarball, and upload it somewhere, so somebody else can analyze it.
> >>
> >> -Dimitry
> >>
> >
> > It's me again, with the same weird story.
> >
> > After a couple of days silence, the mysterious entity in my computer is
> > back. This
> > time it is again a weird compiler message of failure (trying to buildworld):
> >
> > [...]
> > c++ -O2 -pipe -O3 -O3
> > c++ -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
> > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
> > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
> > -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
> > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
> > -D__STDC_CONSTANT_MACROS
> > -fno-strict-aliasing
> > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
> > -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11
> > -fno-exceptions -fno-rtti -Wno-c++11-extensions
> > -c
> > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Host.cpp
> > -o
> > Host.o --- GraphWriter.o --- In file included
> > from
> > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/GraphWriter.cpp:14:
> >
> > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/GraphWriter.h:269:10:
> > error: use of undeclared identifier 'DOD'; did you mean 'DOT'? O <<
> > DOD::EscapeString(Label); ^~~
> > DOT
> > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/GraphWriter.h:35:11:
> > note: 'DOT' declared here namespace DOT { // Private functions... ^ 1 error
> > generated. *** [GraphWriter.o] Error code 1
> >
> >
> > Well, in the past I saw many of those messages, especially not found labels
> > of
> > routines in shared objects/libraries or even those "funny" misspelled
> > messages shown
> > above.
> >
> > I can not reproduce them after a reboot, but as long as the system is
> > running with
> > this error occured, it is sticky. So in order to compile the OS
> > successfully, I
> > reboot.
> >
> > Does an
Re: freebsd and utf-8 directory names
On Tue, Jul 01, 2014 at 04:41:56PM +0200, d...@gmx.com wrote: > > Poke the FreeBSD developers to start fixing bugs, maybe (but > not very likely) that will help. > Or become a FreeBSD developer, fix the problem, submit a patch, and make everyone happy. Yes, I know the path of least resistance is to moan about how the FreeBSD developers won't fix your problem. -- 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 and utf-8 directory names
Steve Kargl wrote, On 07/01/2014 17:30: Or become a FreeBSD developer, fix the problem, submit a patch, and make everyone happy. I would be very interested in 1-on-1 coaching from you. I will pay for your work with awesome patches. ___ 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 and utf-8 directory names
xfe display the file and directory names correctly together with creation date and time (simple 'ls' does not; it shows double question marks in the place of Hungarian characters. ls | od -c shows that such characters are represented in ls output as two characters e.g. 241 253 or such, I can test again but now I do not remember the exact numbers; the first of the two is the same for all Hungarian characters) rgds András -Original Message- From: d...@gmx.com [mailto:d...@gmx.com] Sent: Tuesday, July 01, 2014 5:20 PM To: M&S - Krasznai András; freebsd-current@freebsd.org Subject: Re: freebsd and utf-8 directory names M&S - Krasznai András wrote, On 07/01/2014 17:07: > I installed xfe (x11-fm/xfe) file manager in the same freebsd configuration. > This application displays and handles those diretories and files perfectly, > but as soon as I want to open such a file with double click on it (I set xfe > to invoke libreoffice in this case) libreoffice still refuses to open the > file. > [...] > What does xfe do differently? What do you mean by "handling and displaying properly"? Listing (directory contents) is one thing, being able to stat or open the file is different. ___ 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 and utf-8 directory names
hi I use the -L hu_HU.UTF-8 option in fstab, but I admit I forgot to set the LCxxx variables. I will test it soon. rgds András -Original Message- From: Gyrd Thane Lange [mailto:gyrd...@thanelange.no] Sent: Tuesday, July 01, 2014 5:30 PM To: Rainer Hurling; M&S - Krasznai András; freebsd-current@freebsd.org Subject: Re: freebsd and utf-8 directory names Den 30. juni 2014 08:56, skrev Rainer Hurling: > Am 30.06.2014 08:30 (UTC+1) schrieb M&S - Krasznai András: >> Hi >> >> I have been using FreeBSD as desktop since 2003, and living in a mixed >> (windows-linux) environment I installed FreeBSd along with my usual (Windows >> 7) work environment, I have a dualboot configured laptop. I use FreeBSD-10 >> STABLE. >> >> There is a partition formatted for FAT32 where I store documents which I >> would like to view (and edit) both in windows and freebsd. >> >> The problem is that if the path name contains certain Hungarian characters >> (e.g o with double accent), then libreoffice in FreeBSD refuses to open them >> complaining about illegal characters. The directory was created in windows, >> the document also, and I can handle them perfectly from windows (what is >> more, libreoffice under a linux can also open those documents). Some >> accented characters are shown as a question mark in FreeBSD, and some others >> are as a black rectangle; these latter are causing problems. If a file-nam >> contains such characters then the file is shown as 0- length in Midnight >> Commander. >> >> I tried some steps described in the „Localization” part of the FreeBSD >> Handbook, but things did not improve. >> >> I installed PC-BSD with Hungarian language support, thinking that it would >> handle the localized directory names correctly but no, it gives the same >> error message. >> >> This problem is really annoying. How could I solve it? > > In my German environment I also use FAT32 formatted drives, mounted like: > > /dev/adaXsX /XXXmsdosfs rw,large,-Lde_DE.UTF-8 0 0 > > This should also work for Hungarian? I second this advice, it should work well for any language (It certainly is fine for my Norwegian). To expand on Rainer's suggestion: The -L parameter in the mount line is from the mount_msdosfs(8) utility. The man page says: -L locale Specify locale name used for file name conversions for DOS and Win'95 names. By default ISO 8859-1 assumed as local character set. The locale of your environment and mount command must match. In my case it is: LC_CTYPE=no_NO.UTF-8 mount_msdosfs -L no_NO.UTF-8 /dev/da3s1 /mnt/tmp (Regarding whether the default of ISO 8859-1 for mount_msdosfs should be changed to some UTF-8 locale to better match what people are using in this age is an entirely different matter. ;-) Best regards, Gyrd ^_^ > > HTH, > Rainer Hurling > > >> Krasznai András >> rendszermérnök >> M&S Informatikai Zrt. >> 1136 Budapest, Pannónia u. 17/A. >> Telefon: +36 1 703-2923 >> Mobil:+36 30 703-2923 > ___ > 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: userland breakage, zfs ?
I'll take a look on this. On Tue, Jul 1, 2014 at 8:28 AM, Sean Bruno wrote: > Just updated two machines in the fbsd cluser, buildworld/kernel, > installkernel, reboot into single user. > > zfs from oldworld (pre installworld) doesn't work and segfaults in new > and magical ways. > > Trying to mount root from zfs:zroot []... > Enter full pathname of shell or RETURN for /bin/sh: > Cannot read termcap database; > using dumb terminal settings. > # zfs set readonly=off zroot > internal error: pInvalid argumentid > 19 (zfs), uid 0: exited on signal 6 > Abort trap > > > I guess, I could multiuser the box on old kernel and installworld from > multiuser, but this could lead to disaster. I see no indication of ABI > breakage of this kind in UPDATING, so ... any ideas? > > sean > > ___ > 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" > -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die ___ 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: userland breakage, zfs ?
On Tue, 2014-07-01 at 08:41 -0700, Xin LI wrote: > I'll take a look on this. > > I'm updating from: FreeBSD chaos.ysv.freebsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r267362: Wed Jun 11 15:50:24 UTC 2014 sbr...@chaos.ysv.freebsd.org:/usr/obj/usr/src/sys/CHAOS amd64 sean > On Tue, Jul 1, 2014 at 8:28 AM, Sean Bruno > wrote: > Just updated two machines in the fbsd cluser, > buildworld/kernel, > installkernel, reboot into single user. > > zfs from oldworld (pre installworld) doesn't work and > segfaults in new > and magical ways. > > Trying to mount root from zfs:zroot []... > Enter full pathname of shell or RETURN for /bin/sh: > Cannot read termcap database; > using dumb terminal settings. > # zfs set readonly=off zroot > internal error: pInvalid argumentid > 19 (zfs), uid 0: exited on signal 6 > Abort trap > > > I guess, I could multiuser the box on old kernel and > installworld from > multiuser, but this could lead to disaster. I see no > indication of ABI > breakage of this kind in UPDATING, so ... any ideas? > > sean > > ___ > 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" > > > > > -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > ___ 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]: weird memory/linker problem?
On 2014-07-01 17:33, O. Hartmann wrote: Am Tue, 01 Jul 2014 17:23:14 +0200 Willem Jan Withagen schrieb: On 2014-07-01 16:48, Rang, Anton wrote: DOT => DOD 444F54 => 444F44 That's a single-bit flip. Bad memory, perhaps? Very likely, especially if the system does not have ECC It just happens on rare occasions that a alpha particle, power cycle, or any things else disruptive damages a memory cell. And it could be that it requires a special pattern of accesses to actually exhibit the error. In the past (199x's) 'make buildworld' used to be a rather good memory tester. But nowadays look at http://www.memtest.org/ This tool has found all of the bad memory in all the systems I used and or build for others... Note that it might take a few runs and some more heat to actually trigger the faulty cell, but memtest86 will usually find it. Note that on big systems with lots of memory it can take a loong time to run just one full testset to completion. --WjW I already testet via memtest86+ (had to download the linux image, the port on FreeBSD is broken on CURRENT). It didn't find anything strange so far. I will do another test. I realised, that on that that specific box, the chipset temperature is 81 Grad Celius. The chipset is a Eaglelake P45 - in which the memory controller resides on that old platform. dmidecode gives: Manufacturer: ASUSTeK Computer INC. Product Name: P5Q-WS Version: Rev 1.xx Hi Oliver, I've build several (5+) systems with these boards (from memory they date around 2009??). And if I recall right, one of them is still functional. The first one broke down in a couple of weeks, and the other did not survive time either. The auxiliary chips on that board do run hot, but I never realized this hot. Is 81C is the CPU temp from sysctl, or did you measure the cooling body on the motherboard. In the later case it is just too hot, probably. But even if it is the temp on the chip itself, I've rrarely seen temps go up this high. You can need to run the memtest86 for more than 6-10 complete runs with all the tests. If the memtests do not reveal anything broken, then you get into even more wizardry stuff, like bad power etc... Especially since it only occurs on occasion, it is going to be a nightmare to find the root cause of this. Other than replacing hardware piece by piece, which won't be easy given the age of the board and parts. You could go into the bios, and try to config ram access at a slower speed and see if the problem goes away. Then it could be that you are running an the edge of the spec with regards to ram timing. But like I said, it is all lots of funky details that can interact in strange and unexpected ways. --WjW ___ 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 and utf-8 directory names
On Tue, Jul 01, 2014 at 05:36:20PM +0200, d...@gmx.com wrote: > Steve Kargl wrote, On 07/01/2014 17:30: > > Or become a FreeBSD developer, fix the problem, submit a patch, > > and make everyone happy. > > I would be very interested in 1-on-1 coaching from you. > I will pay for your work with awesome patches. As I have no use for UTF-8 and msdosfs works for me, I have no interest here. As far as coaching, I'll give you the secret to how I started fixing libm: step 1. Obtain src/ step 2. Read relevent files in src/ step 3. Find problem. step 4. Search literature. step 5. Fix problem. step 6. Submit patch 6a. Receive review of patch. 6b. Fix patch based on review. 6c. Resubmit patch. [[step 7. commit patch] step 8. goto step 2. Repeat often enough and be rewarded with commit bit and step 7 is no longer optional. -- 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 and utf-8 directory names
Steve Kargl wrote, On 07/01/2014 18:34: As far as coaching, I'll give you the secret to how I started fixing libm: step 1. Obtain src/ step 2. Read relevent files in src/ step 3. Find problem. step 4. Search literature. step 5. Fix problem. step 6. Submit patch 6a. Receive review of patch. 6b. Fix patch based on review. 6c. Resubmit patch. [[step 7. commit patch] step 8. goto step 2. In other words, "You, the general user, should learn the art of operating system development (on your own) for the sole purpose of being able to fix the bug yourself." ___ 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"
gpart(8) man page missing list documentation
Looking at the man page for gpart(8) on a recent 10-stable system, I was trying to find out what the -a option to list does. (shown in the output of gpart when run with no parameters). Interestingly, despite “list” being highlighted in paragraph text as an action for the command, it does not appear in the summary at the top of the page, nor in the detailed DESCRIPTION section that describes each of the actions. This appears to still be the case on HEAD, as well. I assume this is worth fixing and MFC’ing? Thanks. - Chris ___ 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]: weird memory/linker problem?
Am Tue, 01 Jul 2014 17:57:26 +0200 Willem Jan Withagen schrieb: > On 2014-07-01 17:33, O. Hartmann wrote: > > Am Tue, 01 Jul 2014 17:23:14 +0200 > > Willem Jan Withagen schrieb: > > > >> On 2014-07-01 16:48, Rang, Anton wrote: > >>> DOT => DOD > >>> > >>> 444F54 => 444F44 > >>> > >>> That's a single-bit flip. Bad memory, perhaps? > >> > >> Very likely, especially if the system does not have ECC > >> It just happens on rare occasions that a alpha particle, power cycle, or > >> any things else disruptive damages a memory cell. And it could be that > >> it requires a special pattern of accesses to actually exhibit the error. > >> > >> In the past (199x's) 'make buildworld' used to be a rather good memory > >> tester. But nowadays look at > >>http://www.memtest.org/ > >> > >> This tool has found all of the bad memory in all the systems I used and > >> or build for others... > >> Note that it might take a few runs and some more heat to actually > >> trigger the faulty cell, but memtest86 will usually find it. > >> > >> Note that on big systems with lots of memory it can take a loong > >> time to run just one full testset to completion. > >> > >> --WjW > > > > I already testet via memtest86+ (had to download the linux image, the port > > on FreeBSD > > is broken on CURRENT). It didn't find anything strange so far. > > > > I will do another test. > > > > I realised, that on that that specific box, the chipset temperature is 81 > > Grad Celius. > > The chipset is a Eaglelake P45 - in which the memory controller resides on > > that old > > platform. dmidecode gives: > > > > Manufacturer: ASUSTeK Computer INC. > > Product Name: P5Q-WS > > Version: Rev 1.xx > Hello Willem, > Hi Oliver, > > I've build several (5+) systems with these boards (from memory they date > around 2009??). And if I recall right, one of them is still functional. > The first one broke down in a couple of weeks, and the other did not > survive time either. > > The auxiliary chips on that board do run hot, but I never realized this > hot. Is 81C is the CPU temp from sysctl, or did you measure the cooling > body on the motherboard. In the later case it is just too hot, probably. > But even if it is the temp on the chip itself, I've rrarely seen temps > go up this high. The temperature is seen in BIOS and by the usage of one of those health daemon, found in ports (forgot about the name). There is no sysctl MIB showing the chipset temperature on that board, as far as I know. > > You can need to run the memtest86 for more than 6-10 complete runs with > all the tests. Last time I ran memtest86+ it took ~ 1 1/2 days to finish. > > If the memtests do not reveal anything broken, then you get into even > more wizardry stuff, like bad power etc... Especially since it only > occurs on occasion, it is going to be a nightmare to find the root cause > of this. Other than replacing hardware piece by piece, which won't be > easy given the age of the board and parts. > > You could go into the bios, and try to config ram access at a slower > speed and see if the problem goes away. Then it could be that you are > running an the edge of the spec with regards to ram timing. > > But like I said, it is all lots of funky details that can interact in > strange and unexpected ways. > > --WjW I will check memory these days again. Regards, Oliver signature.asc Description: PGP signature
Re: freebsd and utf-8 directory names
On 1 Jul 2014, at 15:41, d...@gmx.com wrote: > Also, you're at least the 3rd user (I'm at least the 2nd) that runs into this > case; ie., here's a report: http://forums.freebsd.org/showthread.php?t=14612 > (of course, this does not contain a solution). Please note that forums.freebsd.org is not a bug tracker. I tried searching the bug tracker for bugs with FAT and filename or FAT and utf-8/utf8/character in their names and could not find any reference to this issue. If you actually want to see bugs fixed, rather than just complain about them, please file them here: https://bugs.freebsd.org/bugzilla/enter_bug.cgi Make sure that you provide all of the steps required to reproduce them. David ___ 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 and utf-8 directory names
On Tue, Jul 01, 2014 at 06:53:31PM +0200, d...@gmx.com wrote: > Steve Kargl wrote, On 07/01/2014 18:34: > >As far as coaching, I'll give you > > the secret to how I started fixing libm: > > > > step 1. Obtain src/ > > step 2. Read relevent files in src/ > > step 3. Find problem. > > step 4. Search literature. > > step 5. Fix problem. > > step 6. Submit patch > > 6a. Receive review of patch. > > 6b. Fix patch based on review. > > 6c. Resubmit patch. > > [[step 7. commit patch] > > step 8. goto step 2. > > In other words, "You, the general user, should learn the art > of operating system development (on your own) for the sole > purpose of being able to fix the bug yourself." No. In other words, "If fixing the bug is so important to you that it must be fixed, then perhaps, you should take the initiative to learn enough to fix the bug." Or, in other other words, "Give a man a fish, he eats for a day; teach a man to fish, he eats for a lifetime." Finally, as a general user, it is often counter-productive to include vailed invectives in your emails to a public list. See for example: "Poke the FreeBSD developers to start fixing bugs, maybe (but not very likely) that will help." Sheesh, as if FreeBSD developer never fix any bugs. -- 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 and utf-8 directory names
On Tue, 1 Jul 2014, d...@gmx.com wrote: In other words, "You, the general user, should learn the art of operating system development (on your own) for the sole purpose of being able to fix the bug yourself." It's one approach to solving a technical problem, but not the only one. You can fix it yourself, possibly involving a lot of learning. Or you can ask, encourage, or even pay others to fix it. This should all start with a bug report to make sure the problem is documented. If people already know there are bugs in the msdosfs code, those same people should be able to supply details to fill out the bug report. ___ 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 and utf-8 directory names
M&S - Krasznai Andr??s wrote: > xfe display the file and directory names correctly together with creation > date and time (simple 'ls' does not; it shows double question marks in the > place of Hungarian characters. > > ls | od -c > > shows that such characters are represented in ls output as two characters > e.g. 241 253 or such, I can test again but now I do not remember the exact > numbers; the first of the two is the same for all Hungarian characters) That says to me that your locale is still not set correctly. The ls on it's own could be due to a non-compatible terminal emulator, but the fact that 'od' is showing two bytes rather than trying to display a character (however messed up the output may be) implies the characters are simply not valid in the locale you have set. It would be useful to have the exact numbers from the 'od' (a test filename with more than 2 Hungarian characters would be useful) and an approximate description (or screenshot) on how they should look. cheers, jamie ___ 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: gpart(8) man page missing list documentation
On Tue, 1 Jul 2014, Chris Ross wrote: Looking at the man page for gpart(8) on a recent 10-stable system, I was trying to find out what the -a option to list does. (shown in the output of gpart when run with no parameters). Interestingly, despite ?list? being highlighted in paragraph text as an action for the command, it does not appear in the summary at the top of the page, nor in the detailed DESCRIPTION section that describes each of the actions. This appears to still be the case on HEAD, as well. I assume this is worth fixing and MFC?ing? A PR was just entered for that: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191534 "list" and "status" and a couple of others that only apply for some GEOM modules (load, unload) are part of the base GEOM command set. I was going to say we should just refer the reader to another page, maybe geom(8). But gmirror(8) does include those commands in the synopsis. We should be consistent with this, and I'd lean toward doing it the way gmirror(8) does now. ___ 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"
HEADSUP -- ZFS users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, As some of you may have already noticed, I have accidentally introduced a regression when implementing backward compatibility to existing zfs binaries when importing a recent ZFS change as of r268075, which will cause system to block on 'kmem arena' when running _old_ zfs(8) binaries, due to an overlooked incompatibility of kernel data structures. If this happens, the quickest recovery method would be to roll back to previous kernel by booting into single user mode, mount -uw /, then copy /boot/kernel.old/* to /boot/kernel . The compatibility code was tested against old kernel so if you are doing 'make installkernel installworld' (NOT RECOMMENDED: new userland is NOT guaranteed to work with old kernel) rather than booting to a new kernel, then you would probably be unaffected. I have a working fix and am testing it right now. The fix will be committed after I have done sufficient testing, and I'll send another headsup once everything is settled. Sorry for the inconvenience and thanks for your patience. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJTswQiAAoJEJW2GBstM+nsrxkP/iuyV5CYFtdBTaLONTEihGYH Y5GpkrSy14Dikz+kAhCVBs6BlbEe94tpHvpL7tHKbIfmXQthWXj9WSW5F4PDrJGN FOLTCGfS0IHfKe2hzAln8jJW+E5uECgL/mLlPVbiVFf1gLsbHgy+YoOS46Zmr4Ro JmW7zChvIT2ZFvF8NJbP22PThf0R5IRPU9EKSbF1BioUUAePyh3Ml6TlGofCFAFT kBSuLhRDw6p42SJ+tWHixdPKVFJHj4qrYtAdBCLTa/jeLYUuD1R0wfk3XyZHH6r9 8dfN0L4GVM9vjvh1qD9AC1TZy1IbwE1TsBnmipo2bU8BLxey8/TxdtimLC/JoXol EcBfsO/GfOcLxvYEdD6ZstOZkAcGRfpxbe8ECfEia3od9bM11eCBo1OTdAHlCnGg VxhoCzWGtL6Ma3EApZpOELG43wE+8N9tv3ylM30QTEcJ27SS03mewQUTnXPHFvZq D0kSC6CSF1WfFIm5aS8NkkrZKazhdig7TasBXWq13p9u2p5wvAgPZlh2qWF4uBdb oP1o/c9kbYyiduUrRDWwL6iGcD4YQG/9vpPntwH17B4r8i6Nf69E1KeU32FUDfbk Lfn7lY9M2NgsCH5MQrWygR6NfeirEtpq0cGgu6FPnUHq0PAxkl9CtrjEBa3RPLXa NCYxWySbYXV+I1jKYoZU =eO6S -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: Fix Emulex "oce" driver in CURRENT
El 30.06.2014 18:36, Stefano Garzarella escribió: Hello, I had problems during some experiments with Emulex and "oce" driver in CURRENT. I found several bugs in the "oce" driver and this patch fixes them. At least with some cards, the driver simply does not work. It causes a panic when there is some traffic. The relevant bug report is here. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183391 The latest version available from the Emulex website works. But the version bundled with 9.3 and at least -STABLE (which is the same version bundled with -CURRENT) does cause panics on 10- and 9- It's quite easy to reproduce. Link two machines, fire iperf to generate traffic and watch the almost instant panic. Borja. ___ 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: gpart(8) man page missing list documentation
On 2014-07-01 14:49, Warren Block wrote: On Tue, 1 Jul 2014, Chris Ross wrote: Looking at the man page for gpart(8) on a recent 10-stable system, I was trying to find out what the -a option to list does. (shown in the output of gpart when run with no parameters). Interestingly, despite ?list? being highlighted in paragraph text as an action for the command, it does not appear in the summary at the top of the page, nor in the detailed DESCRIPTION section that describes each of the actions. This appears to still be the case on HEAD, as well. I assume this is worth fixing and MFC?ing? A PR was just entered for that: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191534 "list" and "status" and a couple of others that only apply for some GEOM modules (load, unload) are part of the base GEOM command set. I was going to say we should just refer the reader to another page, maybe geom(8). But gmirror(8) does include those commands in the synopsis. We should be consistent with this, and I'd lean toward doing it the way gmirror(8) does now. ___ 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" Chris: Just looked at gmirror(8) and geom(8) and I concur that having it listed in the synopsis with a reference in the description would suffice nicely. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips/mips
TB --- 2014-07-01 18:18:31 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-01 18:18:31 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-01 18:18:31 - starting HEAD tinderbox run for mips/mips TB --- 2014-07-01 18:18:31 - cleaning the object tree TB --- 2014-07-01 18:18:31 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-01 18:18:35 - At svn revision 268087 TB --- 2014-07-01 18:18:36 - building world TB --- 2014-07-01 18:18:36 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 18:18:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 18:18:36 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 18:18:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 18:18:36 - SRCCONF=/dev/null TB --- 2014-07-01 18:18:36 - TARGET=mips TB --- 2014-07-01 18:18:36 - TARGET_ARCH=mips TB --- 2014-07-01 18:18:36 - TZ=UTC TB --- 2014-07-01 18:18:36 - __MAKE_CONF=/dev/null TB --- 2014-07-01 18:18:36 - cd /src TB --- 2014-07-01 18:18:36 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jul 1 18:18:43 UTC 2014 >>> 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 Tue Jul 1 19:19:39 UTC 2014 TB --- 2014-07-01 19:19:39 - cd /src/sys/mips/conf TB --- 2014-07-01 19:19:39 - /obj/mips.mips/src/tmp/legacy/usr/sbin/config -m ADM5120 TB --- 2014-07-01 19:19:39 - skipping ADM5120 kernel TB --- 2014-07-01 19:19:39 - cd /src/sys/mips/conf TB --- 2014-07-01 19:19:39 - /obj/mips.mips/src/tmp/legacy/usr/sbin/config -m ALCHEMY TB --- 2014-07-01 19:19:39 - skipping ALCHEMY kernel TB --- 2014-07-01 19:19:39 - cd /src/sys/mips/conf TB --- 2014-07-01 19:19:39 - /obj/mips.mips/src/tmp/legacy/usr/sbin/config -m ALFA_HORNET_UB TB --- 2014-07-01 19:19:39 - building ALFA_HORNET_UB kernel TB --- 2014-07-01 19:19:39 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 19:19:39 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 19:19:39 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 19:19:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 19:19:39 - SRCCONF=/dev/null TB --- 2014-07-01 19:19:39 - TARGET=mips TB --- 2014-07-01 19:19:39 - TARGET_ARCH=mips TB --- 2014-07-01 19:19:39 - TZ=UTC TB --- 2014-07-01 19:19:39 - __MAKE_CONF=/dev/null TB --- 2014-07-01 19:19:39 - cd /src TB --- 2014-07-01 19:19:39 - /usr/bin/make -B buildkernel KERNCONF=ALFA_HORNET_UB >>> Kernel build for ALFA_HORNET_UB started on Tue Jul 1 19:19:39 UTC 2014 >>> 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 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -gdwarf-2 -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 --param max-inline-insns-single=1000 -Werror /src/sys/kern/init_sysent.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -gdwarf-2 -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 --param max-inline-insns-single=1000 -Werror /src/sys/kern/ksched.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -gdwarf-2 -fno-common -finline-limit=8000 --param inline-unit
[head tinderbox] failure on ia64/ia64
TB --- 2014-07-01 18:08:45 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-01 18:08:45 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-01 18:08:45 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-07-01 18:08:45 - cleaning the object tree TB --- 2014-07-01 18:10:02 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-01 18:10:29 - At svn revision 268087 TB --- 2014-07-01 18:10:30 - building world TB --- 2014-07-01 18:10:30 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 18:10:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 18:10:30 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 18:10:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 18:10:30 - SRCCONF=/dev/null TB --- 2014-07-01 18:10:30 - TARGET=ia64 TB --- 2014-07-01 18:10:30 - TARGET_ARCH=ia64 TB --- 2014-07-01 18:10:30 - TZ=UTC TB --- 2014-07-01 18:10:30 - __MAKE_CONF=/dev/null TB --- 2014-07-01 18:10:30 - cd /src TB --- 2014-07-01 18:10:30 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jul 1 18:10:38 UTC 2014 >>> 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 Tue Jul 1 19:44:23 UTC 2014 TB --- 2014-07-01 19:44:23 - generating LINT kernel config TB --- 2014-07-01 19:44:23 - cd /src/sys/ia64/conf TB --- 2014-07-01 19:44:23 - /usr/bin/make -B LINT TB --- 2014-07-01 19:44:23 - cd /src/sys/ia64/conf TB --- 2014-07-01 19:44:23 - /obj/ia64.ia64/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-01 19:44:23 - building LINT kernel TB --- 2014-07-01 19:44:23 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 19:44:23 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 19:44:23 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 19:44:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 19:44:23 - SRCCONF=/dev/null TB --- 2014-07-01 19:44:23 - TARGET=ia64 TB --- 2014-07-01 19:44:23 - TARGET_ARCH=ia64 TB --- 2014-07-01 19:44:23 - TZ=UTC TB --- 2014-07-01 19:44:23 - __MAKE_CONF=/dev/null TB --- 2014-07-01 19:44:23 - cd /src TB --- 2014-07-01 19:44:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 1 19:44:23 UTC 2014 >>> 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 -x assembler-with-cpp -Wa,-x -DLOCORE -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-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -Werror /src/sys/libkern/ia64/__udivsi3.S cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -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-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -Werror /src/sys/libkern/ia64/__umoddi3.S cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -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-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -Werror /src/sys/libkern/ia64/__umodsi3.S cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -
[head tinderbox] failure on mips64/mips
TB --- 2014-07-01 18:33:43 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-01 18:33:43 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-01 18:33:43 - starting HEAD tinderbox run for mips64/mips TB --- 2014-07-01 18:33:43 - cleaning the object tree TB --- 2014-07-01 18:34:53 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-01 18:34:56 - At svn revision 268087 TB --- 2014-07-01 18:34:57 - building world TB --- 2014-07-01 18:34:57 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 18:34:57 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 18:34:57 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 18:34:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 18:34:57 - SRCCONF=/dev/null TB --- 2014-07-01 18:34:57 - TARGET=mips TB --- 2014-07-01 18:34:57 - TARGET_ARCH=mips64 TB --- 2014-07-01 18:34:57 - TZ=UTC TB --- 2014-07-01 18:34:57 - __MAKE_CONF=/dev/null TB --- 2014-07-01 18:34:57 - cd /src TB --- 2014-07-01 18:34:57 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jul 1 18:35:04 UTC 2014 >>> 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 Tue Jul 1 19:35:32 UTC 2014 TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m ADM5120 TB --- 2014-07-01 19:35:32 - skipping ADM5120 kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m ALCHEMY TB --- 2014-07-01 19:35:32 - skipping ALCHEMY kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m ALFA_HORNET_UB TB --- 2014-07-01 19:35:32 - skipping ALFA_HORNET_UB kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP121 TB --- 2014-07-01 19:35:32 - skipping AP121 kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP91 TB --- 2014-07-01 19:35:32 - skipping AP91 kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP93 TB --- 2014-07-01 19:35:32 - skipping AP93 kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP94 TB --- 2014-07-01 19:35:32 - skipping AP94 kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AP96 TB --- 2014-07-01 19:35:32 - skipping AP96 kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR71XX_BASE TB --- 2014-07-01 19:35:32 - skipping AR71XX_BASE kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR724X_BASE TB --- 2014-07-01 19:35:32 - skipping AR724X_BASE kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR91XX_BASE TB --- 2014-07-01 19:35:32 - skipping AR91XX_BASE kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR933X_BASE TB --- 2014-07-01 19:35:32 - skipping AR933X_BASE kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m AR934X_BASE TB --- 2014-07-01 19:35:32 - skipping AR934X_BASE kernel TB --- 2014-07-01 19:35:32 - cd /src/sys/mips/conf TB --- 2014-07-01 19:35:32 - /obj/mips.mips64/src/tmp/legacy/usr/sbin/config -m BERI_DE4_BASE TB --- 2014-07-01 19:35:32 - building BERI_DE4_BASE kernel TB --- 2014-07-01 19:35:32 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 19:35:32 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 19:35:32 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 19:35:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 19:35:32 - SRCCONF=/dev/null TB --- 2014-07-01 19:35:32 - TARGET=mips TB --- 2014-07-01 19:35:32 - TARGET_ARCH=mips64 TB --- 2014-07-01 19:35:32 - TZ=UTC TB --- 2014-07-01 19:35:32 - __MAKE_CONF=/dev/null TB --- 2014-07-01 19:35:32 - cd /src TB --- 2014-07-01 19:35:32 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_BASE >>> Kernel build for BERI_DE4_B
Re: Fix Emulex "oce" driver in CURRENT
On Tue, Jul 1, 2014 at 8:58 PM, wrote: > El 30.06.2014 18:36, Stefano Garzarella escribió: > > Hello, >> I had problems during some experiments with Emulex and "oce" driver in >> CURRENT. >> I found several bugs in the "oce" driver and this patch fixes them. >> > > At least with some cards, the driver simply does not work. It causes a > panic when there is some traffic. > > The relevant bug report is here. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183391 > > The latest version available from the Emulex website works. But the > version bundled with 9.3 and at least -STABLE (which is the same version > bundled with -CURRENT) does cause panics on 10- and 9- > i compared the code on the emulex website (10.0.747.0 ?) with the one in HEAD and it does not seem much different, but perhaps you have some other version in mind ? The bugs found by stefano exist also in the emulex version above. cheers luigi ___ 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: HEADSUP -- ZFS users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Should be fixed in r268116. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJTsyDiAAoJEJW2GBstM+nsz+kQAJQQHq6tlIhv3MrCzaEF9BWw PKKdRPKXfBI4d2DD/WIx16q62bI/8T9iSEMLheyiVPpnMWor6AUmDIvZFAtWYuHD i1SW5bPXKQUGgQXXhrRGH3goD/2K2YW+96yotBHn5Qq5yF6UHixK6aALE1y75UlH BcYkkuytCSjdTyU7Ujk6unHjMMhg39I36sYt/dLCR6zh6vuMuuCYVNxn61iKVMEG oXL/GZTQrzABQ4OBT3+kkbBvFX8UC9qHM9jP4pS/Z2ldf5DHemTPseDVgyAZi7Fq feapjOGAlpgkE/IhXkYuOUEYgbnLhKuzZ8QuwNtyGNI+kjzDHvRZoo3NQa1AUCDg sNaCh+IYK0A+gdL8yAboc2rUXebZsVpwP/fq2YtZ6BgZohDoT3p67yXwxBlf6GDw 7+niYeY3mZtddCIteLAkgB6a7jOO/HIW6hrmp6QeAHRUhS5e8OO5an08Wk8fY0n7 +gwFJPt9iidVpyQZwYQY9Gg0563azeII3j7MZy2bIYRFYHDfMWYt/JaBRS39kET/ Yw+lahYRwAO0WQFPy4e4c69BfL+k59B5QAi3c/u/8B9Mm7XEh1ufItcrfOl9KNRg NpCiqOewtoUJSOwv7T1gr3eEwyKYQR0aFnKd4zPc2tCknZtUz4c1ylv6xX89mU6Z TWkI7+SiBvF0gplro3Uo =qMaa -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"
HeadsUp: NFSv4.1 server code merged into head
Hi, I just merged the NFSv4.1 server code from projects/nfsv4.1-server into head (r268115). You will need to rebuild kernels and all NFS related modules, including a "config " after this update. It is a rather large merge, but I hope it doesn't cause any regression for non-NFSv4.1 NFS stuff. I posted a request for testing/review about a month ago and haven't received any negative feedback, so I assumed no news was good news. Sorry in advance for any grief this commit might cause, rick ps: I will be bumping __FreeBSD_version, since the internal calls between the NFS related modules has now changed somewhat. (It is not obvious to me if this is necessary, so if someone would prefer __FreeBSD_version not be bumped, please email asap.) ___ 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 --- 2014-07-01 20:05:39 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-01 20:05:39 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-01 20:05:39 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2014-07-01 20:05:40 - cleaning the object tree TB --- 2014-07-01 20:06:43 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-01 20:06:50 - At svn revision 268087 TB --- 2014-07-01 20:06:51 - building world TB --- 2014-07-01 20:06:51 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 20:06:51 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 20:06:51 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 20:06:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 20:06:51 - SRCCONF=/dev/null TB --- 2014-07-01 20:06:51 - TARGET=sparc64 TB --- 2014-07-01 20:06:51 - TARGET_ARCH=sparc64 TB --- 2014-07-01 20:06:51 - TZ=UTC TB --- 2014-07-01 20:06:51 - __MAKE_CONF=/dev/null TB --- 2014-07-01 20:06:51 - cd /src TB --- 2014-07-01 20:06:51 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Tue Jul 1 20:06:59 UTC 2014 >>> 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 Tue Jul 1 21:12:53 UTC 2014 TB --- 2014-07-01 21:12:53 - generating LINT kernel config TB --- 2014-07-01 21:12:53 - cd /src/sys/sparc64/conf TB --- 2014-07-01 21:12:53 - /usr/bin/make -B LINT TB --- 2014-07-01 21:12:53 - cd /src/sys/sparc64/conf TB --- 2014-07-01 21:12:53 - /obj/sparc64.sparc64/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-01 21:12:53 - building LINT kernel TB --- 2014-07-01 21:12:53 - CROSS_BUILD_TESTING=YES TB --- 2014-07-01 21:12:53 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-01 21:12:53 - MAKESYSPATH=/src/share/mk TB --- 2014-07-01 21:12:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-01 21:12:53 - SRCCONF=/dev/null TB --- 2014-07-01 21:12:53 - TARGET=sparc64 TB --- 2014-07-01 21:12:53 - TARGET_ARCH=sparc64 TB --- 2014-07-01 21:12:53 - TZ=UTC TB --- 2014-07-01 21:12:53 - __MAKE_CONF=/dev/null TB --- 2014-07-01 21:12:53 - cd /src TB --- 2014-07-01 21:12:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 1 21:12:53 UTC 2014 >>> 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-builtin -ffreestanding -fstack-protector -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -Werror /src/sys/dev/le/if_le_ledma.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-builtin -ffreestanding -fstack-protector -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -Werror /src/sys/dev/le/lebuffer_sbus.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_bus_if.m -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-builtin -ffreestanding -fstack-protector -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -Werror ofw_bus_if.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-
Re: svn commit: r267977 - head/bin/mv
On Fri, Jun 27, 2014 at 04:06:53PM -0700, Xin Li wrote:
> [moving discussion to freebsd-current@]
> On 06/27/14 15:23, Jilles Tjoelker wrote:
> > On Fri, Jun 27, 2014 at 07:57:54PM +, Xin LI wrote:
> >> Author: delphij
> >> Date: Fri Jun 27 19:57:54 2014
> >> New Revision: 267977
> >> URL: http://svnweb.freebsd.org/changeset/base/267977
> >> Log:
> >> Always set UF_ARCHIVE on target (because they are by definition new files
> >> and should be archived) and ignore error when we can't set it (e.g. NFS).
> >> Reviewed by: ken
> >> MFC after: 2 weeks
> >> Modified:
> >> head/bin/mv/mv.c
> >> Modified: head/bin/mv/mv.c
> >> ==
> >> --- head/bin/mv/mv.c Fri Jun 27 19:50:30 2014(r267976)
> >> +++ head/bin/mv/mv.c Fri Jun 27 19:57:54 2014(r267977)
> >> @@ -337,8 +337,8 @@ err: if (unlink(to))
> >> * on a file that we copied, i.e., that we didn't create.)
> >> */
> >>errno = 0;
> >> - if (fchflags(to_fd, sbp->st_flags))
> >> - if (errno != EOPNOTSUPP || sbp->st_flags != 0)
> >> + if (fchflags(to_fd, sbp->st_flags | UF_ARCHIVE))
> >> + if (errno != EOPNOTSUPP || ((sbp->st_flags & ~UF_ARCHIVE) != 0))
> >>warn("%s: set flags (was: 0%07o)", to, sbp->st_flags);
> >>
> >>tval[0].tv_sec = sbp->st_atime;
> > The part ignoring failures to set UF_ARCHIVE is OK. However, it seems
> > inconsistent to set UF_ARCHIVE on a cross-filesystem mv of a single
> > file, but not on a cross-filesystem mv of a directory tree or a file
> > newly created via shell output redirection.
> > If UF_ARCHIVE is supposed to be set automatically, I think this should
> > be done in the kernel, like msdosfs already does. However, I'm not sure
> > this is actually a useful feature: backup programs are smarter than an
> > archive attribute these days.
> The flag is supposed to be set automatically (as my understanding of the
> ZFS portion of implementation).
OK, I did not know that ZFS set UF_ARCHIVE automatically. If so, blindly
copying st_flags like the old code did is indeed suboptimal.
> However in order to implement that way, we will have to stat() the
> target file (attached). Personally, I think this is a little bit
> wasteful, but it would probably something that we have to do if we
> implement a switch to turn off automatic UF_ARCHIVE behavior.
This seems better. For example, it avoids UF_ARCHIVE spreading around
randomly on UFS.
Nits: the errno = 0 assignment seems unnecessary, "can not" should be
"cannot".
> Index: bin/mv/mv.c
> ===
> --- bin/mv/mv.c (revision 267984)
> +++ bin/mv/mv.c (working copy)
> @@ -278,6 +278,7 @@ fastcopy(const char *from, const char *to, struct
> static char *bp = NULL;
> mode_t oldmode;
> int nread, from_fd, to_fd;
> + struct stat to_sb;
>
> if ((from_fd = open(from, O_RDONLY, 0)) < 0) {
> warn("fastcopy: open() failed (from): %s", from);
> @@ -329,6 +330,7 @@ err: if (unlink(to))
>*/
> preserve_fd_acls(from_fd, to_fd, from, to);
> (void)close(from_fd);
> +
> /*
>* XXX
>* NFS doesn't support chflags; ignore errors unless there's reason
> @@ -336,10 +338,19 @@ err:if (unlink(to))
>* if the server supports flags and we were trying to *remove* flags
>* on a file that we copied, i.e., that we didn't create.)
>*/
> - errno = 0;
> - if (fchflags(to_fd, sbp->st_flags | UF_ARCHIVE))
> - if (errno != EOPNOTSUPP || ((sbp->st_flags & ~UF_ARCHIVE) != 0))
> - warn("%s: set flags (was: 0%07o)", to, sbp->st_flags);
> + if (fstat(to_fd, &to_sb) == 0) {
> + if ((sbp->st_flags & ~UF_ARCHIVE) !=
> + (to_sb.st_flags & ~UF_ARCHIVE)) {
> + errno = 0;
> + if (fchflags(to_fd,
> + sbp->st_flags | (to_sb.st_flags & UF_ARCHIVE)))
> + if (errno != EOPNOTSUPP ||
> + ((sbp->st_flags & ~UF_ARCHIVE) != 0))
> + warn("%s: set flags (was: 0%07o)",
> + to, sbp->st_flags);
> + }
> + } else
> + warn("%s: can not stat", to);
>
> tval[0].tv_sec = sbp->st_atime;
> tval[1].tv_sec = sbp->st_mtime;
--
Jilles Tjoelker
___
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 and utf-8 directory names
David Chisnall wrote, On 07/01/2014 19:06: Please note that forums.freebsd.org is not a bug tracker. I tried searching the bug tracker for bugs with FAT and filename or FAT and utf-8/utf8/character in their names and could not find any reference to this issue. If you actually want to see bugs fixed, rather than just complain about them, please file them here: https://bugs.freebsd.org/bugzilla/enter_bug.cgi Make sure that you provide all of the steps required to reproduce them. I neglected to submit a bug report because: (1) there were already at least 3 bug reports related to (FAT32 and) character sets or encodings, some of them even had patches; (2) the reports were very old, indicating that the FreeBSD developers don't care about FAT32; (3) at least one report was seemingly related, and I didn't want to create a(nother) possible duplicate. But now, eat this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540 ___ 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 iscsi target
On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: > Hi. I've replied in private, but just for the record: > > On 0627T0927, Sreenivasa Honnur wrote: > > Does freebsd iscsi target supports: > > 1. ACL (access control lists) > > In 10-STABLE there is a way to control access based on initiator > name and IP address. > > > 2. iSNS > > No; it's one of the iSCSI features that seem to only be used > for marketing purposes :-) > > > 3. Multiple connections per session > > No; see above. I think this is help for 40G links. ___ 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 --- 2014-07-02 00:00:50 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-02 00:00:50 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-02 00:00:50 - starting HEAD tinderbox run for arm/arm TB --- 2014-07-02 00:00:50 - cleaning the object tree TB --- 2014-07-02 00:02:09 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-02 00:02:12 - At svn revision 268131 TB --- 2014-07-02 00:02:13 - building world TB --- 2014-07-02 00:02:13 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 00:02:13 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 00:02:13 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 00:02:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 00:02:13 - SRCCONF=/dev/null TB --- 2014-07-02 00:02:13 - TARGET=arm TB --- 2014-07-02 00:02:13 - TARGET_ARCH=arm TB --- 2014-07-02 00:02:13 - TZ=UTC TB --- 2014-07-02 00:02:13 - __MAKE_CONF=/dev/null TB --- 2014-07-02 00:02:13 - cd /src TB --- 2014-07-02 00:02:13 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Wed Jul 2 00:02:20 UTC 2014 >>> 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 Wed Jul 2 03:19:53 UTC 2014 TB --- 2014-07-02 03:19:53 - generating LINT kernel config TB --- 2014-07-02 03:19:53 - cd /src/sys/arm/conf TB --- 2014-07-02 03:19:53 - /usr/bin/make -B LINT TB --- 2014-07-02 03:19:53 - cd /src/sys/arm/conf TB --- 2014-07-02 03:19:53 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-02 03:19:53 - building LINT kernel TB --- 2014-07-02 03:19:53 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 03:19:53 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 03:19:53 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 03:19:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 03:19:53 - SRCCONF=/dev/null TB --- 2014-07-02 03:19:53 - TARGET=arm TB --- 2014-07-02 03:19:53 - TARGET_ARCH=arm TB --- 2014-07-02 03:19:53 - TZ=UTC TB --- 2014-07-02 03:19:53 - __MAKE_CONF=/dev/null TB --- 2014-07-02 03:19:53 - cd /src TB --- 2014-07-02 03:19:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 2 03:19:53 UTC 2014 >>> 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 [...] machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `kernelstack' at91_machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `minidataclean' ep80219_machdep.o: warning: previous common is here pxa_machdep.o: warning: multiple common of `msgbufpv' at91_machdep.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_mem' uart_cpu_fdt.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_io' uart_cpu_fdt.o: warning: previous common is here kbd.o: In function `kbd_register': /src/sys/dev/kbd/kbd.c:(.text+0x42c): undefined reference to `__stop_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x430): undefined reference to `__start_set_kbddriver_set' kbd.o: In function `kbd_get_switch': /src/sys/dev/kbd/kbd.c:(.text+0x5c0): undefined reference to `__start_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x5c4): undefined reference to `__stop_set_kbddriver_set' kbd.o: In function `kbd_configure': /src/sys/dev/kbd/kbd.c:(.text+0x898): undefined reference to `__start_set_kbddriver_set' /src/sys/dev/kbd/kbd.c:(.text+0x89c): undefined reference to `__stop_set_kbddriver_set' *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-07-02 03:37:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-07-02 03:37:09 - ERROR: failed to build LINT kernel TB --- 2014-07-02 03:37:09 - 10432.02 user 1715.45 system 12978.79 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.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 i386/i386
TB --- 2014-07-02 00:00:50 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-02 00:00:50 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-02 00:00:50 - starting HEAD tinderbox run for i386/i386 TB --- 2014-07-02 00:00:50 - cleaning the object tree TB --- 2014-07-02 00:00:50 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-02 00:00:55 - At svn revision 268131 TB --- 2014-07-02 00:00:56 - building world TB --- 2014-07-02 00:00:56 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 00:00:56 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 00:00:56 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 00:00:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 00:00:56 - SRCCONF=/dev/null TB --- 2014-07-02 00:00:56 - TARGET=i386 TB --- 2014-07-02 00:00:56 - TARGET_ARCH=i386 TB --- 2014-07-02 00:00:56 - TZ=UTC TB --- 2014-07-02 00:00:56 - __MAKE_CONF=/dev/null TB --- 2014-07-02 00:00:56 - cd /src TB --- 2014-07-02 00:00:56 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Wed Jul 2 00:01:07 UTC 2014 >>> 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 Wed Jul 2 03:29:17 UTC 2014 TB --- 2014-07-02 03:29:17 - generating LINT kernel config TB --- 2014-07-02 03:29:17 - cd /src/sys/i386/conf TB --- 2014-07-02 03:29:17 - /usr/bin/make -B LINT TB --- 2014-07-02 03:29:17 - cd /src/sys/i386/conf TB --- 2014-07-02 03:29:17 - /obj/i386.i386/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-02 03:29:17 - building LINT kernel TB --- 2014-07-02 03:29:17 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 03:29:17 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 03:29:17 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 03:29:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 03:29:17 - SRCCONF=/dev/null TB --- 2014-07-02 03:29:17 - TARGET=i386 TB --- 2014-07-02 03:29:17 - TARGET_ARCH=i386 TB --- 2014-07-02 03:29:17 - TZ=UTC TB --- 2014-07-02 03:29:17 - __MAKE_CONF=/dev/null TB --- 2014-07-02 03:29:17 - cd /src TB --- 2014-07-02 03:29:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 2 03:29:18 UTC 2014 >>> 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 -Wno-unused-function -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 -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -mno-aes -mno-avx -Werror -pg /src/sys/dev/ath/ath_hal/ar9002/ar9285.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal 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 -Wno-unused-function -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 -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -mno-aes -mno-avx -Werror -pg /src/sys/dev/ath/ath_hal/ar9002/ar9287.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal 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 -Wno-unused-function -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 -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -mno-aes -mno-avx -Werror -pg /src/s
[head tinderbox] failure on amd64/amd64
TB --- 2014-07-02 00:00:50 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-02 00:00:50 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-02 00:00:50 - starting HEAD tinderbox run for amd64/amd64 TB --- 2014-07-02 00:00:50 - cleaning the object tree TB --- 2014-07-02 00:00:50 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-02 00:00:54 - At svn revision 268131 TB --- 2014-07-02 00:00:55 - building world TB --- 2014-07-02 00:00:55 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 00:00:55 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 00:00:55 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 00:00:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 00:00:55 - SRCCONF=/dev/null TB --- 2014-07-02 00:00:55 - TARGET=amd64 TB --- 2014-07-02 00:00:55 - TARGET_ARCH=amd64 TB --- 2014-07-02 00:00:55 - TZ=UTC TB --- 2014-07-02 00:00:55 - __MAKE_CONF=/dev/null TB --- 2014-07-02 00:00:55 - cd /src TB --- 2014-07-02 00:00:55 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Wed Jul 2 00:01:07 UTC 2014 >>> 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 Wed Jul 2 04:08:16 UTC 2014 TB --- 2014-07-02 04:08:16 - generating LINT kernel config TB --- 2014-07-02 04:08:16 - cd /src/sys/amd64/conf TB --- 2014-07-02 04:08:16 - /usr/bin/make -B LINT TB --- 2014-07-02 04:08:16 - cd /src/sys/amd64/conf TB --- 2014-07-02 04:08:16 - /obj/amd64.amd64/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-02 04:08:16 - building LINT kernel TB --- 2014-07-02 04:08:16 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 04:08:16 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 04:08:16 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 04:08:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 04:08:16 - SRCCONF=/dev/null TB --- 2014-07-02 04:08:16 - TARGET=amd64 TB --- 2014-07-02 04:08:16 - TARGET_ARCH=amd64 TB --- 2014-07-02 04:08:16 - TZ=UTC TB --- 2014-07-02 04:08:16 - __MAKE_CONF=/dev/null TB --- 2014-07-02 04:08:16 - cd /src TB --- 2014-07-02 04:08:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 2 04:08:16 UTC 2014 >>> 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 -Wno-unused-function -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 -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -mno-aes -mno-avx -Werror -pg /src/sys/dev/ath/ath_hal/ar9002/ar9285.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal 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 -Wno-unused-function -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 -DGPROF -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -mno-aes -mno-avx -Werror -pg /src/sys/dev/ath/ath_hal/ar9002/ar9287.c -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal 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 -Wno-unused
[head tinderbox] failure on mips/mips
TB --- 2014-07-02 04:16:54 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-02 04:16:54 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-02 04:16:54 - starting HEAD tinderbox run for mips/mips TB --- 2014-07-02 04:16:54 - cleaning the object tree TB --- 2014-07-02 04:17:48 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-02 04:17:51 - At svn revision 268131 TB --- 2014-07-02 04:17:52 - building world TB --- 2014-07-02 04:17:52 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 04:17:52 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 04:17:52 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 04:17:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 04:17:52 - SRCCONF=/dev/null TB --- 2014-07-02 04:17:52 - TARGET=mips TB --- 2014-07-02 04:17:52 - TARGET_ARCH=mips TB --- 2014-07-02 04:17:52 - TZ=UTC TB --- 2014-07-02 04:17:52 - __MAKE_CONF=/dev/null TB --- 2014-07-02 04:17:52 - cd /src TB --- 2014-07-02 04:17:52 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Wed Jul 2 04:17:59 UTC 2014 >>> 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 Wed Jul 2 05:21:11 UTC 2014 TB --- 2014-07-02 05:21:11 - cd /src/sys/mips/conf TB --- 2014-07-02 05:21:11 - /obj/mips.mips/src/tmp/legacy/usr/sbin/config -m ADM5120 TB --- 2014-07-02 05:21:11 - skipping ADM5120 kernel TB --- 2014-07-02 05:21:11 - cd /src/sys/mips/conf TB --- 2014-07-02 05:21:11 - /obj/mips.mips/src/tmp/legacy/usr/sbin/config -m ALCHEMY TB --- 2014-07-02 05:21:11 - skipping ALCHEMY kernel TB --- 2014-07-02 05:21:11 - cd /src/sys/mips/conf TB --- 2014-07-02 05:21:11 - /obj/mips.mips/src/tmp/legacy/usr/sbin/config -m ALFA_HORNET_UB TB --- 2014-07-02 05:21:11 - building ALFA_HORNET_UB kernel TB --- 2014-07-02 05:21:11 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 05:21:11 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 05:21:11 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 05:21:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 05:21:11 - SRCCONF=/dev/null TB --- 2014-07-02 05:21:11 - TARGET=mips TB --- 2014-07-02 05:21:11 - TARGET_ARCH=mips TB --- 2014-07-02 05:21:11 - TZ=UTC TB --- 2014-07-02 05:21:11 - __MAKE_CONF=/dev/null TB --- 2014-07-02 05:21:11 - cd /src TB --- 2014-07-02 05:21:11 - /usr/bin/make -B buildkernel KERNCONF=ALFA_HORNET_UB >>> Kernel build for ALFA_HORNET_UB started on Wed Jul 2 05:21:11 UTC 2014 >>> 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 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -gdwarf-2 -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 --param max-inline-insns-single=1000 -Werror /src/sys/kern/init_sysent.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -gdwarf-2 -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 --param max-inline-insns-single=1000 -Werror /src/sys/kern/ksched.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -gdwarf-2 -fno-common -finline-limit=8000 --param inline-unit
[head tinderbox] failure on ia64/ia64
TB --- 2014-07-02 03:39:46 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-02 03:39:46 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-02 03:39:46 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-07-02 03:39:46 - cleaning the object tree TB --- 2014-07-02 03:40:50 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-02 03:40:53 - At svn revision 268131 TB --- 2014-07-02 03:40:54 - building world TB --- 2014-07-02 03:40:54 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 03:40:54 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 03:40:54 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 03:40:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 03:40:54 - SRCCONF=/dev/null TB --- 2014-07-02 03:40:54 - TARGET=ia64 TB --- 2014-07-02 03:40:54 - TARGET_ARCH=ia64 TB --- 2014-07-02 03:40:54 - TZ=UTC TB --- 2014-07-02 03:40:54 - __MAKE_CONF=/dev/null TB --- 2014-07-02 03:40:54 - cd /src TB --- 2014-07-02 03:40:54 - /usr/bin/make -B buildworld >>> Building an up-to-date bmake(1) >>> World build started on Wed Jul 2 03:41:02 UTC 2014 >>> 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 Wed Jul 2 05:18:03 UTC 2014 TB --- 2014-07-02 05:18:03 - generating LINT kernel config TB --- 2014-07-02 05:18:03 - cd /src/sys/ia64/conf TB --- 2014-07-02 05:18:03 - /usr/bin/make -B LINT TB --- 2014-07-02 05:18:03 - cd /src/sys/ia64/conf TB --- 2014-07-02 05:18:03 - /obj/ia64.ia64/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-07-02 05:18:04 - building LINT kernel TB --- 2014-07-02 05:18:04 - CROSS_BUILD_TESTING=YES TB --- 2014-07-02 05:18:04 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-02 05:18:04 - MAKESYSPATH=/src/share/mk TB --- 2014-07-02 05:18:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-02 05:18:04 - SRCCONF=/dev/null TB --- 2014-07-02 05:18:04 - TARGET=ia64 TB --- 2014-07-02 05:18:04 - TARGET_ARCH=ia64 TB --- 2014-07-02 05:18:04 - TZ=UTC TB --- 2014-07-02 05:18:04 - __MAKE_CONF=/dev/null TB --- 2014-07-02 05:18:04 - cd /src TB --- 2014-07-02 05:18:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 2 05:18:04 UTC 2014 >>> 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 -x assembler-with-cpp -Wa,-x -DLOCORE -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-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -Werror /src/sys/libkern/ia64/__udivsi3.S cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -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-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -Werror /src/sys/libkern/ia64/__umoddi3.S cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -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-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -Werror /src/sys/libkern/ia64/__umodsi3.S cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -
Re: FreeBSD iscsi target
On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov wrote: > On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: > > > Hi. I've replied in private, but just for the record: > > > > On 0627T0927, Sreenivasa Honnur wrote: > > > Does freebsd iscsi target supports: > > > 1. ACL (access control lists) > > > > In 10-STABLE there is a way to control access based on initiator > > name and IP address. > > > > > 2. iSNS > > > > No; it's one of the iSCSI features that seem to only be used > > for marketing purposes :-) > > > > > 3. Multiple connections per session > > > > No; see above. > > I think this is help for 40G links. > I assume that you are looking at transfer of large amounts of data over 40G links. Assuming that tis is the case, yes, multiple connections per session can help you. If you have not done so, you should also look at http://fasterdata.es.net. It is a bit linux-centric these days, but still provides a lot of information on moving data efficiently over fast links. IIt is evolving continually, but did not discuss iSCSI last I knew. ESnet has an Nx100G backbone and many users (most notably the LHC at CERN) who regularly move increasingly large volumes of data, often around the clock, making efficient use of available bandwidth is critical. The network researchers there have put in significant efforts in determining how to best optimize such operations. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: [head tinderbox] failure on mips/mips
On Wed, Jul 02, 2014 at 05:22:29AM +, FreeBSD Tinderbox wrote: > cc1: warnings being treated as errors > /src/sys/kern/kern_exec.c: In function 'kern_execve': > /src/sys/kern/kern_exec.c:346: warning: 'newsigacts' may be used > uninitialized in this function > /src/sys/kern/kern_exec.c:346: note: 'newsigacts' was declared here > *** Error code 1 > Should be fixed with r268136 -- Mateusz Guzik ___ 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 and utf-8 directory names
Ok, I wrote yesterday that I will test it (again, I would say, because when I recognised the problem I did some testing. I picked up the FreeBSD Handbook and repeated the procedure listed in the "localization" section - with no success or at most half success). Naturally I may have made mistake, may have omitted some steps, but I will repeat. anyway, the whole thing started as working in a Windows environment I wanted to setup FreeBSD as a second operating system on my laptop, and I wanted to be able to do my work using freebsd only. The partitioning was done originally from Windows, Fat32 was formatted from Windows 7, and I use fat32 because when I started to use FreeBSD the NTFS support in FreeBSD was only for reading. The directory structure was created from windows, most of the files are various documents created either by me or my colleaugues and most of them are in some of Microsoft document format for compatibility reasons (I mean compatibility with my colleaugues). rgds András Krasznai -Original Message- From: Jamie Landeg-Jones [mailto:ja...@dyslexicfish.net] Sent: Tuesday, July 01, 2014 7:40 PM To: M&S - Krasznai András; freebsd-current@freebsd.org; d...@gmx.com Subject: Re: freebsd and utf-8 directory names M&S - Krasznai Andr??s wrote: > xfe display the file and directory names correctly together with creation > date and time (simple 'ls' does not; it shows double question marks in the > place of Hungarian characters. > > ls | od -c > > shows that such characters are represented in ls output as two characters > e.g. 241 253 or such, I can test again but now I do not remember the exact > numbers; the first of the two is the same for all Hungarian characters) That says to me that your locale is still not set correctly. The ls on it's own could be due to a non-compatible terminal emulator, but the fact that 'od' is showing two bytes rather than trying to display a character (however messed up the output may be) implies the characters are simply not valid in the locale you have set. It would be useful to have the exact numbers from the 'od' (a test filename with more than 2 Hungarian characters would be useful) and an approximate description (or screenshot) on how they should look. cheers, jamie ___ 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"
