[head tinderbox] failure on i386/pc98
TB --- 2013-07-31 02:44:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-31 02:44:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-31 02:44:22 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-07-31 02:44:22 - cleaning the object tree TB --- 2013-07-31 02:45:39 - /usr/local/bin/svn stat /src TB --- 2013-07-31 02:45:53 - At svn revision 253823 TB --- 2013-07-31 02:45:54 - building world TB --- 2013-07-31 02:45:54 - CROSS_BUILD_TESTING=YES TB --- 2013-07-31 02:45:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-31 02:45:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-31 02:45:54 - SRCCONF=/dev/null TB --- 2013-07-31 02:45:54 - TARGET=pc98 TB --- 2013-07-31 02:45:54 - TARGET_ARCH=i386 TB --- 2013-07-31 02:45:54 - TZ=UTC TB --- 2013-07-31 02:45:54 - __MAKE_CONF=/dev/null TB --- 2013-07-31 02:45:54 - cd /src TB --- 2013-07-31 02:45:54 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Jul 31 02:46:02 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Jul 31 06:02:05 UTC 2013 TB --- 2013-07-31 06:02:05 - generating LINT kernel config TB --- 2013-07-31 06:02:05 - cd /src/sys/pc98/conf TB --- 2013-07-31 06:02:05 - /usr/bin/make -B LINT TB --- 2013-07-31 06:02:06 - cd /src/sys/pc98/conf TB --- 2013-07-31 06:02:06 - /usr/sbin/config -m LINT TB --- 2013-07-31 06:02:06 - building LINT kernel TB --- 2013-07-31 06:02:06 - CROSS_BUILD_TESTING=YES TB --- 2013-07-31 06:02:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-31 06:02:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-31 06:02:06 - SRCCONF=/dev/null TB --- 2013-07-31 06:02:06 - TARGET=pc98 TB --- 2013-07-31 06:02:06 - TARGET_ARCH=i386 TB --- 2013-07-31 06:02:06 - TZ=UTC TB --- 2013-07-31 06:02:06 - __MAKE_CONF=/dev/null TB --- 2013-07-31 06:02:06 - cd /src TB --- 2013-07-31 06:02:06 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Jul 31 06:02:06 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/kern/subr_taskqueue.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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/kern/subr_trap.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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/kern/subr_turnstile.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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
Re: ldd runs linux programs
On 7/30/13 4:54 AM, Mateusz Guzik wrote: On Mon, Jul 29, 2013 at 11:56:25AM -0400, Mark Johnston wrote: 127276 suggests running the binary as is (which I don't like) and achieves this with a hacky way. So if we really want to do this, the patch should be reworked to detect Linux binaries properly. In general we should gain linux_ldd (like linux_kdump) and our ldd should work only on FreeBSD binaries. The last part is achieved with my patch. markj, are you working on this? Not really; my original fix for this problem was essentially the same as yours. That is, just change ldd(1) to bail if the OS ABI byte isn't equal to ELFOSABI_FREEBSD. That's the change I have committed in my local tree right now. Then I thought I'd try to get ldd to work properly with Linux binaries as well, but wasn't sure what the right approach should be. As the above PR suggests, the easy thing to do is to just pass LD_TRACE_LOADED_OBJECTS and not LD_32_TRACE_LOADED_OBJECTS for 32-bit ELF objects if the OS isn't FreeBSD. This feels somewhat hacky to me, but I didn't really see another approach. That said, I think your patch should be committed since it's clearly an improvement over the current behaviour. I'm willing to test and commit it, and clean up the open PRs. If you could expand on the right way to handle Linux binaries, I'd be willing to implement and commit that too. I don't quite understand your reference to linux_kdump though - I have no such program on my laptop running CURRENT, and ktrace+kdump seem to work fine with the Linux binaries under /compat/linux. Well, there was linux_kdump in ports but it apparently got obsolete as necessary support for included in our regular kdump. So it may make sense to teach our ldd how to deal with Linux binaries for consistency, but its unclear for me if this is better than providing linux_ldd. Also there is the problem of (not) appending /compat/linux to printed paths (for Linux binaries the kernel performs file lookups against /compat/linux first). I'm not that interested in this problem though. :P That being said, if you want to do something with this, I suggest cleaning up PRs and reviving discussion in http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/127276 if linux binaries are installed then chain to libexec/linux-ldd just like fsck chains to various specific fsck binaries. If there is no such chain loadable ldd, then just refuse to do anything. ___ 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: Problem with curret in vmware
Can I suggest? We desperately need for vmware page at wiki. I created stub, will fill it with known info to me, help and experience appreciated! https://wiki.freebsd.org/VmWare P.S. Some time ago there was message in lists, about improved speed of intel-emulated network card under vmware, this could go there too. 2013/7/31 Bryan Venteicher bry...@daemoninthecloset.org On Tuesday, July 30, 2013 5:25:06 am Alexander Yerenkow wrote: Hello all. I have panics in vmware with installed vmwaretools (they are guessed culprit). Seems that memory balooning (or using more memory in all vms than there is in host) produces some kind of weird behavior in FreeBSD. This vm aren't shutted down now, is there somethin I can do to help investigate this? Panic screens: http://gits.kiev.ua/FreeBSD/panic1.png http://gits.kiev.ua/FreeBSD/panic2.png Looks like their code needs to be updated to work with locking changes in HEAD. Attilio is probably the best person to ask. This highlights why we should move away from the poorly supported, out of tree, unfriendly licensed VMware tools. I have a port of the vmxnet3 from OpenBSD [1] that I intend to commit in time for 10. Next, I hope to look at the OpenBSD vmt [2] VMware tools driver. The balloon is a bit trickier. AFAIK, OpenBSD doesn't have a driver for easy porting. The VMware tools driver for FreeBSD is GPL licensed, and VMware has shown no interest/ability to relicense their tools. Likely, the best way forward is to port their CDDL licensed Solaris driver. [1] - http://svnweb.freebsd.org/base/projects/vmxnet/sys/dev/vmware/vmxnet3/ [2] - http://www.openbsd.org/cgi-bin/man.cgi?query=vmtapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Regards, Alexander Yerenkow ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ldd runs linux programs
On 7/30/13 5:37 AM, David Chisnall wrote: On 29 Jul 2013, at 21:54, Mateusz Guzik mjgu...@gmail.com wrote: Well, there was linux_kdump in ports but it apparently got obsolete as necessary support for included in our regular kdump. So it may make sense to teach our ldd how to deal with Linux binaries for consistency, but its unclear for me if this is better than providing linux_ldd. Also there is the problem of (not) appending /compat/linux to printed paths (for Linux binaries the kernel performs file lookups against /compat/linux first). I'm not that interested in this problem though. :P That being said, if you want to do something with this, I suggest cleaning up PRs and reviving discussion in http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/127276 What would be the correct behaviour for non-native binaries? Stacy Son and Brooks Davis have been working on providing a kernel activator for QEMU user mode, which lets us run, for example, MIPS or ARM binaries on x86. If you have a MIPS64 ELF file and you run ldd on it, what would the correct behaviour be? Once you have identified the binary type, you chain to the appropriate binary in libexec. if you can't find it, then you just exit. 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-07-31 06:13:30 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-31 06:13:30 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-31 06:13:30 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-31 06:13:30 - cleaning the object tree TB --- 2013-07-31 06:14:27 - /usr/local/bin/svn stat /src TB --- 2013-07-31 06:14:34 - At svn revision 253823 TB --- 2013-07-31 06:14:35 - building world TB --- 2013-07-31 06:14:35 - CROSS_BUILD_TESTING=YES TB --- 2013-07-31 06:14:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-31 06:14:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-31 06:14:35 - SRCCONF=/dev/null TB --- 2013-07-31 06:14:35 - TARGET=sparc64 TB --- 2013-07-31 06:14:35 - TARGET_ARCH=sparc64 TB --- 2013-07-31 06:14:35 - TZ=UTC TB --- 2013-07-31 06:14:35 - __MAKE_CONF=/dev/null TB --- 2013-07-31 06:14:35 - cd /src TB --- 2013-07-31 06:14:35 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Jul 31 06:14:42 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Jul 31 07:20:30 UTC 2013 TB --- 2013-07-31 07:20:30 - generating LINT kernel config TB --- 2013-07-31 07:20:30 - cd /src/sys/sparc64/conf TB --- 2013-07-31 07:20:30 - /usr/bin/make -B LINT TB --- 2013-07-31 07:20:31 - cd /src/sys/sparc64/conf TB --- 2013-07-31 07:20:31 - /usr/sbin/config -m LINT TB --- 2013-07-31 07:20:31 - building LINT kernel TB --- 2013-07-31 07:20:31 - CROSS_BUILD_TESTING=YES TB --- 2013-07-31 07:20:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-31 07:20:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-31 07:20:31 - SRCCONF=/dev/null TB --- 2013-07-31 07:20:31 - TARGET=sparc64 TB --- 2013-07-31 07:20:31 - TARGET_ARCH=sparc64 TB --- 2013-07-31 07:20:31 - TZ=UTC TB --- 2013-07-31 07:20:31 - __MAKE_CONF=/dev/null TB --- 2013-07-31 07:20:31 - cd /src TB --- 2013-07-31 07:20:31 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Jul 31 07:20:31 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_smp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_stack.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_taskqueue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-07-31 04:50:31 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-31 04:50:31 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-31 04:50:31 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-07-31 04:50:31 - cleaning the object tree TB --- 2013-07-31 04:51:41 - /usr/local/bin/svn stat /src TB --- 2013-07-31 04:51:48 - At svn revision 253823 TB --- 2013-07-31 04:51:49 - building world TB --- 2013-07-31 04:51:49 - CROSS_BUILD_TESTING=YES TB --- 2013-07-31 04:51:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-31 04:51:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-31 04:51:49 - SRCCONF=/dev/null TB --- 2013-07-31 04:51:49 - TARGET=powerpc TB --- 2013-07-31 04:51:49 - TARGET_ARCH=powerpc TB --- 2013-07-31 04:51:49 - TZ=UTC TB --- 2013-07-31 04:51:49 - __MAKE_CONF=/dev/null TB --- 2013-07-31 04:51:49 - cd /src TB --- 2013-07-31 04:51:49 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Jul 31 04:51:57 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Jul 31 07:28:19 UTC 2013 TB --- 2013-07-31 07:28:19 - generating LINT kernel config TB --- 2013-07-31 07:28:19 - cd /src/sys/powerpc/conf TB --- 2013-07-31 07:28:19 - /usr/bin/make -B LINT TB --- 2013-07-31 07:28:19 - cd /src/sys/powerpc/conf TB --- 2013-07-31 07:28:19 - /usr/sbin/config -m LINT TB --- 2013-07-31 07:28:19 - building LINT kernel TB --- 2013-07-31 07:28:19 - CROSS_BUILD_TESTING=YES TB --- 2013-07-31 07:28:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-31 07:28:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-31 07:28:19 - SRCCONF=/dev/null TB --- 2013-07-31 07:28:19 - TARGET=powerpc TB --- 2013-07-31 07:28:19 - TARGET_ARCH=powerpc TB --- 2013-07-31 07:28:19 - TZ=UTC TB --- 2013-07-31 07:28:19 - __MAKE_CONF=/dev/null TB --- 2013-07-31 07:28:19 - cd /src TB --- 2013-07-31 07:28:19 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Jul 31 07:28:19 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_smp.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_stack.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_taskqueue.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
CURRENT r253690: fetch(1) fails with: Certificate verification failed for ...
Updating several ports on CURRENT fails with a fetch error, which expresses itself via [math/eigen3] Certificate verification failed for /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV CA-1 34380876968:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1168: fetch: https://bitbucket.org/eigen/eigen/get/3.2.0.tar.bz2: Authentication error Similar failing ports are (in my case): math/eigen3 math/openblas devel/bzr Others havn't been revealed as faulty. Today, I updated the ports on a CURRENT box which has CURRENT r253690/amd64. Everything went smooth, even the ports in question got fetched and updated properly. After the update of the main OS to CURRENT: FreeBSD 10.0-CURRENT #0 r253834: Wed Jul 31 10:32:01 CEST 2013 the system now rejects the fetch of the source file with the described error. I haven't found anything explaining this strange behaviour. Any suggestions? Oliver signature.asc Description: PGP signature
Re: CURRENT r253690: fetch(1) fails with: Certificate verification failed for ...
On 7/31/2013 3:16 AM, O. Hartmann wrote: Updating several ports on CURRENT fails with a fetch error, which expresses itself via [math/eigen3] This should be fixed now. SSL Certificate Verification has been disabled in ports since the distinfo is already fetched securely and used to check the checksum of the downloaded distfile. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
port graphics/blender fails to compile due to issue in math.h: error: controlling expression type 'unsigned int' not compatible with any generic association type [...] isnan' __fp_type_select(x, __in
On most recent CUURENT (FreeBSD 10.0-CURRENT #4 r253800: Tue Jul 30 13:41:11 CEST 2013 amd64 ) port garphics/blender fails to compile due to the following error. I guess this has to do with the changes necessary to math.h/cmath and the c++11 standard issue. [...] Scanning dependencies of target bf_imbuf_cineon [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineon_dpx.c.o [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineonlib.c.o /usr/ports/graphics/blender/work/blender-2.68/source/blender/imbuf/intern/cineon/cineonlib.c:280:70: error: controlling expression type 'unsigned int' not compatible with any generic association type if (cineon-element[i].refLowData == CINEON_UNDEFINED_U32 || isnan(cineon-element[i].refLowData)) ^ /usr/include/math.h:118:19: note: expanded from macro 'isnan' __fp_type_select(x, __inline_isnanf, __inline_isnan, __inline_isnanl) ^ /usr/include/math.h:86:49: note: expanded from macro '__fp_type_select' #define __fp_type_select(x, f, d, ld) _Generic((x), \ ^ /usr/ports/graphics/blender/work/blender-2.68/source/blender/imbuf/intern/cineon/cineonlib.c:283:71: error: controlling expression type 'unsigned int' not compatible with any generic association type if (cineon-element[i].refHighData == CINEON_UNDEFINED_U32 || isnan(cineon-element[i].refHighData)) ^~ /usr/include/math.h:118:19: note: expanded from macro 'isnan' __fp_type_select(x, __inline_isnanf, __inline_isnan, __inline_isnanl) ^ /usr/include/math.h:86:49: note: expanded from macro '__fp_type_select' #define __fp_type_select(x, f, d, ld) _Generic((x), \ signature.asc Description: PGP signature
Re: CURRENT r253690: fetch(1) fails with: Certificate verification failed for ...
On Wed, 31 Jul 2013 07:45:33 -0700 Bryan Drewery bdrew...@freebsd.org wrote: On 7/31/2013 3:16 AM, O. Hartmann wrote: Updating several ports on CURRENT fails with a fetch error, which expresses itself via [math/eigen3] This should be fixed now. SSL Certificate Verification has been disabled in ports since the distinfo is already fetched securely and used to check the checksum of the downloaded distfile. Yes, it seem so. oh signature.asc Description: PGP signature
Re: CURRENT: Ivy Bridge CPU (i3-3220) and Intel Bull Mountain RNG (options RDRAND_RNG)
On Tue, 30 Jul 2013 16:07:48 +0200 Julian Stecklina jstec...@os.inf.tu-dresden.de wrote: On 07/30/2013 01:46 PM, O. Hartmann wrote: I tried the new option options RDRAND_RNG on my SOHO server, equipted with a Intel i3-3220 Ivy Brdige CPU, which is supposed to have the Bull Mountain random number generator as a piece of hardware in its uncore. Enabling the kernel option doesn't reveal any presence of such a hardware number generator. sysct kern.random always reports kern.random.adaptors: yarrow By intentionally disallowing yarrow via commenting out options YARROW_RNG, the box reports no adaptors loaded. So, either this Ivy Bridge has been castrated and ripped off by Intel of its RNG or FreeBSD isn't capable of detecting it properly or I'm incapable of properly configure the kernel. This might be Erratum BV54: Problem: On processors that support the RDRAND instruction, that capability should be reported via the setting of CPUID.01H:ECX.RDRAND[bit 30]. Due to this erratum, that bit will not be set, and the execution of the RDRAND instruction will result in a #UD exception. Implication: Software will not be able to utilize the RDRAND instruction http://www.intel.de/content/dam/www/public/us/en/documents/specification-updates/3rd-gen-core-desktop-specification-update.pdf Julian It seems, this decoupling of the adaptors has been removed/refected again! All those neat switches are gone with r253845 signature.asc Description: PGP signature
Please check in this simple patch: misc/180976 Fixed vfork/rfork arguments in truss(1)
http://www.freebsd.org/cgi/query-pr.cgi?pr=180976 Thank you, Yuri ___ 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: Problem with curret in vmware
On Tuesday, July 30, 2013 5:25:06 am Alexander Yerenkow wrote: Hello all. I have panics in vmware with installed vmwaretools (they are guessed culprit). Seems that memory balooning (or using more memory in all vms than there is in host) produces some kind of weird behavior in FreeBSD. This vm aren't shutted down now, is there somethin I can do to help investigate this? Panic screens: http://gits.kiev.ua/FreeBSD/panic1.png http://gits.kiev.ua/FreeBSD/panic2.png Looks like their code needs to be updated to work with locking changes in HEAD. Attilio is probably the best person to ask. This highlights why we should move away from the poorly supported, out of tree, unfriendly licensed VMware tools. I have a port of the vmxnet3 from OpenBSD [1] that I intend to commit in time for 10. Next, I hope to look at the OpenBSD vmt [2] VMware tools driver. The balloon is a bit trickier. AFAIK, OpenBSD doesn't have a driver for easy porting. The VMware tools driver for FreeBSD is GPL licensed, and VMware has shown no interest/ability to relicense their tools. Likely, the best way forward is to port their CDDL licensed Solaris driver. [1] - http://svnweb.freebsd.org/base/projects/vmxnet/sys/dev/vmware/vmxnet3/ [2] - http://www.openbsd.org/cgi-bin/man.cgi?query=vmtapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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: ldd runs linux programs
On Wednesday, July 31, 2013 2:36:14 am Julian Elischer wrote: On 7/30/13 4:54 AM, Mateusz Guzik wrote: On Mon, Jul 29, 2013 at 11:56:25AM -0400, Mark Johnston wrote: 127276 suggests running the binary as is (which I don't like) and achieves this with a hacky way. So if we really want to do this, the patch should be reworked to detect Linux binaries properly. In general we should gain linux_ldd (like linux_kdump) and our ldd should work only on FreeBSD binaries. The last part is achieved with my patch. markj, are you working on this? Not really; my original fix for this problem was essentially the same as yours. That is, just change ldd(1) to bail if the OS ABI byte isn't equal to ELFOSABI_FREEBSD. That's the change I have committed in my local tree right now. Then I thought I'd try to get ldd to work properly with Linux binaries as well, but wasn't sure what the right approach should be. As the above PR suggests, the easy thing to do is to just pass LD_TRACE_LOADED_OBJECTS and not LD_32_TRACE_LOADED_OBJECTS for 32-bit ELF objects if the OS isn't FreeBSD. This feels somewhat hacky to me, but I didn't really see another approach. That said, I think your patch should be committed since it's clearly an improvement over the current behaviour. I'm willing to test and commit it, and clean up the open PRs. If you could expand on the right way to handle Linux binaries, I'd be willing to implement and commit that too. I don't quite understand your reference to linux_kdump though - I have no such program on my laptop running CURRENT, and ktrace+kdump seem to work fine with the Linux binaries under /compat/linux. Well, there was linux_kdump in ports but it apparently got obsolete as necessary support for included in our regular kdump. So it may make sense to teach our ldd how to deal with Linux binaries for consistency, but its unclear for me if this is better than providing linux_ldd. Also there is the problem of (not) appending /compat/linux to printed paths (for Linux binaries the kernel performs file lookups against /compat/linux first). I'm not that interested in this problem though. :P That being said, if you want to do something with this, I suggest cleaning up PRs and reviving discussion in http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/127276 if linux binaries are installed then chain to libexec/linux-ldd just like fsck chains to various specific fsck binaries. If there is no such chain loadable ldd, then just refuse to do anything. That is not how ldd works. ldd always runs the program. It is the program (specifically the rtld of the new program) which changes its behavior based on environment variables. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ldd runs linux programs
On Mon, Jul 29, 2013 at 10:54:49PM +0200, Mateusz Guzik wrote: On Mon, Jul 29, 2013 at 11:56:25AM -0400, Mark Johnston wrote: 127276 suggests running the binary as is (which I don't like) and achieves this with a hacky way. So if we really want to do this, the patch should be reworked to detect Linux binaries properly. In general we should gain linux_ldd (like linux_kdump) and our ldd should work only on FreeBSD binaries. The last part is achieved with my patch. markj, are you working on this? Not really; my original fix for this problem was essentially the same as yours. That is, just change ldd(1) to bail if the OS ABI byte isn't equal to ELFOSABI_FREEBSD. That's the change I have committed in my local tree right now. Then I thought I'd try to get ldd to work properly with Linux binaries as well, but wasn't sure what the right approach should be. As the above PR suggests, the easy thing to do is to just pass LD_TRACE_LOADED_OBJECTS and not LD_32_TRACE_LOADED_OBJECTS for 32-bit ELF objects if the OS isn't FreeBSD. This feels somewhat hacky to me, but I didn't really see another approach. That said, I think your patch should be committed since it's clearly an improvement over the current behaviour. I'm willing to test and commit it, and clean up the open PRs. If you could expand on the right way to handle Linux binaries, I'd be willing to implement and commit that too. I don't quite understand your reference to linux_kdump though - I have no such program on my laptop running CURRENT, and ktrace+kdump seem to work fine with the Linux binaries under /compat/linux. Well, there was linux_kdump in ports but it apparently got obsolete as necessary support for included in our regular kdump. So it may make sense to teach our ldd how to deal with Linux binaries for consistency, but its unclear for me if this is better than providing linux_ldd. Also there is the problem of (not) appending /compat/linux to printed paths (for Linux binaries the kernel performs file lookups against /compat/linux first). I'm not that interested in this problem though. :P What do you think of the patch below, which just sets both variables in the compat case? It's somewhat less intrusive than the patch in the PR. If that's no good then I'll just commit your original patch; I really just want to fix the fact that the example pipeline in the ldd(1) man page starts a GTK program (some Adobe Flash thingy to be specific) when run in /usr/local/bin on my desktop machine. :) Thanks, -Mark diff --git a/usr.bin/ldd/ldd.c b/usr.bin/ldd/ldd.c index 00c8797..71e9c8d 100644 --- a/usr.bin/ldd/ldd.c +++ b/usr.bin/ldd/ldd.c @@ -51,6 +51,7 @@ __FBSDID($FreeBSD$); #ifdef COMPAT_32BIT #defineLD_ LD_32_ +#defineLD_COMPAT_ LD_ #else #defineLD_ LD_ #endif @@ -211,6 +212,13 @@ main(int argc, char *argv[]) /* ld.so magic */ setenv(LD_ TRACE_LOADED_OBJECTS, yes, 1); +#ifdef COMPAT_32BIT + /* +* Set this for the benefit of runtime linkers that don't know +* we're in compat mode. +*/ + setenv(LD_COMPAT_ TRACE_LOADED_OBJECTS, yes, 1); +#endif if (fmt1 != NULL) setenv(LD_ TRACE_LOADED_OBJECTS_FMT1, fmt1, 1); if (fmt2 != NULL) ___ 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: Please check in this simple patch: misc/180976 Fixed vfork/rfork arguments in truss(1)
On Wed, Jul 31, 2013 at 11:24:31AM -0700, Yuri wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=180976 I've committed a modified version of the patch as r253850. Thanks! -Mark ___ 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
