Re: -current build failure
On 24 Jul 2012, at 23:43, Konstantin Belousov wrote: As kan rightfully notes, the assumption that %fs:0 == *%fs:0 holds for userspace on amd64, and the same is true for %gs userspace on i386. The change you committed to clang/llvm/whatever it called just breaks useful optimization for FreeBSD. If you can suggest a way of differentiating the kernel and userspace compilation targets, then I would be happy to hear it and will make the appropriate change.Until then, I would rather have slightly sub-optimal code in userspace than incorrect code in kernelspace. Sigh Very helpful, thank you. 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
[head tinderbox] failure on powerpc64/powerpc
TB --- 2012-07-25 08:21:33 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-25 08:21:33 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-25 08:21:33 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-25 08:21:33 - cleaning the object tree TB --- 2012-07-25 08:21:33 - cvsupping the source tree TB --- 2012-07-25 08:21:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-25 08:22:39 - building world TB --- 2012-07-25 08:22:39 - CROSS_BUILD_TESTING=YES TB --- 2012-07-25 08:22:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-25 08:22:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-25 08:22:39 - SRCCONF=/dev/null TB --- 2012-07-25 08:22:39 - TARGET=powerpc TB --- 2012-07-25 08:22:39 - TARGET_ARCH=powerpc64 TB --- 2012-07-25 08:22:39 - TZ=UTC TB --- 2012-07-25 08:22:39 - __MAKE_CONF=/dev/null TB --- 2012-07-25 08:22:39 - cd /src TB --- 2012-07-25 08:22:39 - /usr/bin/make -B buildworld World build started on Wed Jul 25 08:22:40 UTC 2012 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../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=\powerpc64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDeclCXX.cpp -o CGDeclCXX.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../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=\powerpc64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGException.cpp -o CGException.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../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=\powerpc64-unknown-freebsd10.0\ -DDEFAULT_SYSROOT=\\ -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp -o CGExpr.o /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp: In member function 'clang::CodeGen::LValue clang::CodeGen::CodeGenFunction::EmitLValueForFieldInitialization(clang::CodeGen::LValue, const clang::FieldDecl*)': /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp:2113: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /src/lib/clang/libclangcodegen. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-25 09:14:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-25 09:14:27 - ERROR: failed to build world TB --- 2012-07-25 09:14:27 - 2367.34 user 363.77 system 3174.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current build failure
On Wed, Jul 25, 2012 at 09:03:58AM +0100, David Chisnall wrote: On 24 Jul 2012, at 23:43, Konstantin Belousov wrote: As kan rightfully notes, the assumption that %fs:0 == *%fs:0 holds for userspace on amd64, and the same is true for %gs userspace on i386. The change you committed to clang/llvm/whatever it called just breaks useful optimization for FreeBSD. If you can suggest a way of differentiating the kernel and userspace compilation targets, then I would be happy to hear it and will make the appropriate change.Until then, I would rather have slightly sub-optimal code in userspace than incorrect code in kernelspace. Try to differentiate on the memory layout model, the -mcmodel=kernel thing. It shall be passed down to the very last stage of the backend, I believe. Sigh Very helpful, thank you. David pgpYVyO8uzUMe.pgp Description: PGP signature
openssl upgrade, libcrypto, libssl confusion
In /usr/src/UPDATING I see 20120712: The OpenSSL has been upgraded to 1.0.1c. Any binaries requiring libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there are configuration changes. Make sure to merge /etc/ssl/openssl.cnf. Looking at this: # make -C /usr/src check-old-libs Checking for old libraries /lib/libcrypto.so.6 /usr/lib/libssl.so.6 # Am I correct that these 2 libraries can be safely deleted? However, I can't see any version 7 of these libs. Have these libs been replaced by some other lib? Finally, I've rebuilt mail/fetchmail and mail/mutt already several times, but the binaries still use these 2 libs: TZAV ldd /usr/local/bin/mutt /usr/local/bin/mutt: libncursesw.so.8 = /lib/libncursesw.so.8 (0x1202f6000) libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x1203aa000) libheimntlm.so.11 = /usr/lib/libheimntlm.so.11 (0x1203ca000) libkrb5.so.11 = /usr/lib/libkrb5.so.11 (0x1203e4000) libhx509.so.11 = /usr/lib/libhx509.so.11 (0x1204c6000) libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x12055) libcrypto.so.6 = /lib/libcrypto.so.6 (0x120562000) ^^^ libasn1.so.11 = /usr/lib/libasn1.so.11 (0x120812000) libwind.so.11 = /usr/lib/libwind.so.11 (0x120918000) libheimbase.so.11 = /usr/lib/libheimbase.so.11 (0x120952000) libroken.so.11 = /usr/lib/libroken.so.11 (0x120968000) libcrypt.so.5 = /lib/libcrypt.so.5 (0x120996000) libssl.so.6 = /usr/lib/libssl.so.6 (0x1209d) ^^^ libz.so.6 = /lib/libz.so.6 (0x120a72000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x120aaa000) libthr.so.3 = /lib/libthr.so.3 (0x120acc000) libc.so.7 = /lib/libc.so.7 (0x120b1a000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x120dca000) TZAV TZAV ldd /usr/local/bin/fetchmail /usr/local/bin/fetchmail: libopie.so.7 = /usr/lib/libopie.so.7 (0x12010) libcrypt.so.5 = /lib/libcrypt.so.5 (0x12011e000) libkvm.so.5 = /lib/libkvm.so.5 (0x120158000) libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x120178000) libssl.so.6 = /usr/lib/libssl.so.6 (0x12018a000) ^^^ libcrypto.so.6 = /lib/libcrypto.so.6 (0x12022c000) ^^^ libc.so.7 = /lib/libc.so.7 (0x1204dc000) libmd.so.6 = /lib/libmd.so.6 (0x12078c000) TZAV Or will the new library (what is it?) will not be used unless I delete the old ones? Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: openssl upgrade, libcrypto, libssl confusion
On Wed, Jul 25, 2012 at 12:30:29PM +0100, Anton Shterenlikht wrote: In /usr/src/UPDATING I see 20120712: The OpenSSL has been upgraded to 1.0.1c. Any binaries requiring libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there are configuration changes. Make sure to merge /etc/ssl/openssl.cnf. oops.. wait a minute, I'm still on # uname -a FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012 r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 # So this change shouldn't apply to me yet. Still there are *lots* of binaries, and libs linked with /lib/libcrypto.so.6: Binaries that are linked with: /lib/libcrypto.so.6 /bin/ed /bin/red /lib/geom/geom_eli.so /sbin/hastctl /sbin/hastd /usr/bin/bdes /usr/bin/bsdcpio /usr/bin/bsdtar /usr/bin/bsnmpget /usr/bin/bsnmpset /usr/bin/bsnmpwalk /usr/bin/chkey /usr/bin/cvs /usr/bin/dc /usr/bin/dig /usr/bin/fetch /usr/bin/host /usr/bin/hxtool /usr/bin/kadmin /usr/bin/kcc /usr/bin/kdestroy /usr/bin/kf /usr/bin/kgetcred /usr/bin/kinit /usr/bin/klist /usr/bin/kpasswd /usr/bin/ksu /usr/bin/kswitch /usr/bin/newkey /usr/bin/nslookup /usr/bin/nsupdate /usr/bin/openssl /usr/bin/scp /usr/bin/sftp /usr/bin/slogin /usr/bin/ssh /usr/bin/ssh-add /usr/bin/ssh-agent /usr/bin/ssh-keygen /usr/bin/ssh-keyscan /usr/bin/string2key /usr/bin/telnet /usr/bin/verify_krb5_conf /usr/games/factor /usr/lib/libarchive.so.6 /usr/lib/libbsnmp.so.6 /usr/lib/libfetch.so.6 /usr/lib/libgssapi_krb5.so.10 /usr/lib/libgssapi_ntlm.so.10 /usr/lib/libheimntlm.so.11 /usr/lib/libhx509.so.11 /usr/lib/libkdc.so.11 /usr/lib/libkrb5.so.11 /usr/lib/libmp.so.7 /usr/lib/libradius.so.4 /usr/lib/libssh.so.5 /usr/lib/libssl.so.6 /usr/lib/pam_krb5.so.5 /usr/lib/pam_ksu.so.5 /usr/lib/pam_ssh.so.5 /usr/libexec/digest-service and so on, so is it really right that I can safely delete it? Looking at this: # make -C /usr/src check-old-libs Checking for old libraries /lib/libcrypto.so.6 /usr/lib/libssl.so.6 # -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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
machine freezes when using USB disk and X
Hi, I have strange problem which I can reproduce. When I copy some 100GB to a disk via USB when X is not active, it works without any problems. When I copy some 100GB to a disk via USB when X is running, the machine freezes. It does not react to keyboard, mouse and network actions. When I use only X on the same machine and do the same copy via network, the machine behaves as expected. What could I do to locate the problem? Erich PS uname says: FreeBSD AMD620.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #38: Sat Jul 21 06:58:49 WIT 2012 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: use EM_LEGACY_IRQ in if_lem.c ?
lem is also used under VMware. Performance and stability should be tested there, too, before this change. -Andrew On Jul 24, 2012, at 4:20 PM, Luigi Rizzo wrote: if_lem.c (lem, one of the e1000 drivers) has 2 possible interrupt modes: EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas FAST_INTR has a custom handler that signals a taskqueue to do the job. I have no idea which actual hardware uses it (all of my Intel 1G cards use either em or igb), but lem is the driver used in qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet rates than the other. Any objections if i change the default to EM_LEGACY_IRQ ? 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 -- Andrew Boyerabo...@averesystems.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: RFC: use EM_LEGACY_IRQ in if_lem.c ?
On Wed, Jul 25, 2012 at 09:08:42AM -0400, Andrew Boyer wrote: lem is also used under VMware. Performance and stability should be tested there, too, before this change. i do not have VMware so i cannot test it myself, but at the end of this email you can find a suitable image and instructions to test it. This said the issue of stability has nothing to do with the hypervisor (as it changes things in the guest), and regarding performance it is likely to (slightly) improve performance on all hypervisors because the legacy driver saves a couple of MMIO accesses per interrupt (and such accesses cost ~10K cycles each, even with hw support) Test case: - fetch http://info.iet.unipi.it/~luigi/netmap/20120725-netmap-picobsd-head-amd64.bin - start your favourite hypervisor, something equivalent to qemu-system-x86_64 -m 512 -hda 20120725-netmap-picobsd-head-amd64.bin - within the image login and then run dhclient em0 netsend 10.0.2.2 5678 60 0 5 cheers luigi -Andrew On Jul 24, 2012, at 4:20 PM, Luigi Rizzo wrote: if_lem.c (lem, one of the e1000 drivers) has 2 possible interrupt modes: EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas FAST_INTR has a custom handler that signals a taskqueue to do the job. I have no idea which actual hardware uses it (all of my Intel 1G cards use either em or igb), but lem is the driver used in qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet rates than the other. Any objections if i change the default to EM_LEGACY_IRQ ? 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 -- Andrew Boyer abo...@averesystems.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 ___ 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: machine freezes when using USB disk and X
On Wednesday 25 July 2012 14:54:08 Erich Dollansky wrote: Hi, I have strange problem which I can reproduce. When I copy some 100GB to a disk via USB when X is not active, it works without any problems. When I copy some 100GB to a disk via USB when X is running, the machine freezes. It does not react to keyboard, mouse and network actions. When I use only X on the same machine and do the same copy via network, the machine behaves as expected. What could I do to locate the problem? Erich PS uname says: FreeBSD AMD620.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #38: Sat Jul 21 06:58:49 WIT 2012 You might want to check what interrupts are shared. Might be an IRQ problem. --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
Re: RFC: use EM_LEGACY_IRQ in if_lem.c ?
On 24 July 2012 13:20, Luigi Rizzo ri...@iet.unipi.it wrote: if_lem.c (lem, one of the e1000 drivers) has 2 possible interrupt modes: EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas FAST_INTR has a custom handler that signals a taskqueue to do the job. I have no idea which actual hardware uses it (all of my Intel 1G cards use either em or igb), but lem is the driver used in qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet rates than the other. Any objections if i change the default to EM_LEGACY_IRQ ? I suggest doing some digging to understand why. I bet we all know the answer, but it would be nice to have it documented and investigated. I bet em(4) isn't the only device that would benefit from this? 2c, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: use EM_LEGACY_IRQ in if_lem.c ?
On Wed, Jul 25, 2012 at 07:48:57AM -0700, Adrian Chadd wrote: On 24 July 2012 13:20, Luigi Rizzo ri...@iet.unipi.it wrote: if_lem.c (lem, one of the e1000 drivers) has 2 possible interrupt modes: EM_LEGACY_IRQ uses the standard dispatch mechanism, whereas FAST_INTR has a custom handler that signals a taskqueue to do the job. I have no idea which actual hardware uses it (all of my Intel 1G cards use either em or igb), but lem is the driver used in qemu, and there the EM_LEGACY_IRQ gives approx 10% higher packet rates than the other. Any objections if i change the default to EM_LEGACY_IRQ ? I suggest doing some digging to understand why. I bet we all know the answer, but it would be nice to have it documented and investigated. I bet em(4) isn't the only device that would benefit from this? I am not so sure i know the answer on bare iron (and my take is that the difference is more or less irrelevant there), but in the virtualized case the improvement is almost surely because the code used in FAST_INTR has a couple of MMIO accesses to disable/enable interrupts on the card while the taskqueue runs. These are expensive in a VM (such accesses cost ~10K cycles each, even with hw support) 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
[head tinderbox] failure on ia64/ia64
TB --- 2012-07-25 13:31:49 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-25 13:31:49 - 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 --- 2012-07-25 13:31:49 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-25 13:31:49 - cleaning the object tree TB --- 2012-07-25 13:31:49 - cvsupping the source tree TB --- 2012-07-25 13:31:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-25 13:32:51 - building world TB --- 2012-07-25 13:32:51 - CROSS_BUILD_TESTING=YES TB --- 2012-07-25 13:32:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-25 13:32:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-25 13:32:51 - SRCCONF=/dev/null TB --- 2012-07-25 13:32:51 - TARGET=ia64 TB --- 2012-07-25 13:32:51 - TARGET_ARCH=ia64 TB --- 2012-07-25 13:32:51 - TZ=UTC TB --- 2012-07-25 13:32:51 - __MAKE_CONF=/dev/null TB --- 2012-07-25 13:32:51 - cd /src TB --- 2012-07-25 13:32:51 - /usr/bin/make -B buildworld World build started on Wed Jul 25 13:32:52 UTC 2012 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 25 15:05:44 UTC 2012 TB --- 2012-07-25 15:05:44 - generating LINT kernel config TB --- 2012-07-25 15:05:44 - cd /src/sys/ia64/conf TB --- 2012-07-25 15:05:44 - /usr/bin/make -B LINT TB --- 2012-07-25 15:05:44 - cd /src/sys/ia64/conf TB --- 2012-07-25 15:05:44 - /usr/sbin/config -m LINT TB --- 2012-07-25 15:05:44 - building LINT kernel TB --- 2012-07-25 15:05:44 - CROSS_BUILD_TESTING=YES TB --- 2012-07-25 15:05:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-25 15:05:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-25 15:05:44 - SRCCONF=/dev/null TB --- 2012-07-25 15:05:44 - TARGET=ia64 TB --- 2012-07-25 15:05:44 - TARGET_ARCH=ia64 TB --- 2012-07-25 15:05:44 - TZ=UTC TB --- 2012-07-25 15:05:44 - __MAKE_CONF=/dev/null TB --- 2012-07-25 15:05:44 - cd /src TB --- 2012-07-25 15:05:44 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Jul 25 15:05:44 UTC 2012 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 [...] /src/sys/dev/e1000/if_lem.c: In function 'lem_xmit': /src/sys/dev/e1000/if_lem.c:1553: warning: nested extern declaration of 'netmap_drop' [-Wnested-externs] /src/sys/dev/e1000/if_lem.c:1732: warning: suggest parentheses around comparison in operand of [-Wparentheses] /src/sys/dev/e1000/if_lem.c:1757: warning: nested extern declaration of 'netmap_repeat' [-Wnested-externs] /src/sys/dev/e1000/if_lem.c: In function 'lem_txeof': /src/sys/dev/e1000/if_lem.c:3018: error: 'netmap_copy' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:3018: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:3018: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-25 15:13:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-25 15:13:34 - ERROR: failed to build LINT kernel TB --- 2012-07-25 15:13:34 - 4618.95 user 716.26 system 6105.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RFC: libkern version of inet_ntoa_r
During some ipfw/dummynet cleanup i noticed that the libkern version of inet_ntoa_r() is missing the buffer size argument that is present in the libc counterpart. Any objection if i fix it ? The change is trivial and the function is used only in a small number of places, see below (some of which are even commented out). # (cd ~/FreeBSD/head/sys; grep -r inet_ntoa_r .) ./libkern/inet_ntoa.c:inet_ntoa_r(struct in_addr ina, char *buf) ./net/flowtable.c: inet_ntoa_r(ssin-sin_addr, saddr); ./net/flowtable.c: inet_ntoa_r(dsin-sin_addr, daddr); ./net/flowtable.c: inet_ntoa_r(*(struct in_addr *) dsin-sin_addr, daddr); ./net/flowtable.c: inet_ntoa_r(*(struct in_addr *) hashkey[2], daddr); ./net/flowtable.c: inet_ntoa_r(*(struct in_addr *) hashkey[1], saddr); ./net/if_llatbl.c: inet_ntoa_r(sin-sin_addr, l3s); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./netinet/ipfw/ip_fw_log.c: inet_ntoa_r(ip-ip_src, src); ./netinet/ipfw/ip_fw_log.c: inet_ntoa_r(ip-ip_dst, dst); ./netinet/in.h:char *inet_ntoa_r(struct in_addr ina, char *buf); /* in libkern */ ./netinet/in_pcb.c: inet_ntoa_r(inc-inc_laddr, laddr_str); ./netinet/in_pcb.c: inet_ntoa_r(inc-inc_faddr, faddr_str); ./netinet/tcp_subr.c: inet_ntoa_r(inc-inc_faddr, sp); ./netinet/tcp_subr.c: inet_ntoa_r(inc-inc_laddr, sp); ./netinet/tcp_subr.c: inet_ntoa_r(ip-ip_src, sp); ./netinet/tcp_subr.c: inet_ntoa_r(ip-ip_dst, sp); 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: openssl upgrade, libcrypto, libssl confusion
On Wed, Jul 25, 2012 at 5:06 AM, Anton Shterenlikht me...@bristol.ac.uk wrote: On Wed, Jul 25, 2012 at 12:30:29PM +0100, Anton Shterenlikht wrote: In /usr/src/UPDATING I see 20120712: The OpenSSL has been upgraded to 1.0.1c. Any binaries requiring libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there are configuration changes. Make sure to merge /etc/ssl/openssl.cnf. oops.. wait a minute, I'm still on # uname -a FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012 r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 # So this change shouldn't apply to me yet. Still there are *lots* of binaries, and libs linked with /lib/libcrypto.so.6: Binaries that are linked with: /lib/libcrypto.so.6 ... and so on, so is it really right that I can safely delete it? Some ldd/objdump and grep magic will give you the answer you need. check-old-libs only points out candidates for removal based on existence. Cheers, -Garrett ___ 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: openssl upgrade, libcrypto, libssl confusion
Anton, I use mostly static openssl libraries, but I suppose it applies to the dynamic ones, too: with any OpenSSL version (including 1.0.1c), you need libcrypto and libssl. With the new OpenSSL version, you need the new library versions, and you must recompile your binary code to use the new dynamic libraries (because there probably some headers incompatibilities between the versions). You just misunderstood the release notes. Do not delete the library, just re-install the new version. Regards, Oleg -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Anton Shterenlikht Sent: Wednesday, July 25, 2012 4:30 AM To: freebsd-current@freebsd.org Subject: openssl upgrade, libcrypto, libssl confusion In /usr/src/UPDATING I see 20120712: The OpenSSL has been upgraded to 1.0.1c. Any binaries requiring libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there are configuration changes. Make sure to merge /etc/ssl/openssl.cnf. Looking at this: # make -C /usr/src check-old-libs Checking for old libraries /lib/libcrypto.so.6 /usr/lib/libssl.so.6 # Am I correct that these 2 libraries can be safely deleted? However, I can't see any version 7 of these libs. Have these libs been replaced by some other lib? Finally, I've rebuilt mail/fetchmail and mail/mutt already several times, but the binaries still use these 2 libs: TZAV ldd /usr/local/bin/mutt /usr/local/bin/mutt: libncursesw.so.8 = /lib/libncursesw.so.8 (0x1202f6000) libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x1203aa000) libheimntlm.so.11 = /usr/lib/libheimntlm.so.11 (0x1203ca000) libkrb5.so.11 = /usr/lib/libkrb5.so.11 (0x1203e4000) libhx509.so.11 = /usr/lib/libhx509.so.11 (0x1204c6000) libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x12055) libcrypto.so.6 = /lib/libcrypto.so.6 (0x120562000) ^^^ libasn1.so.11 = /usr/lib/libasn1.so.11 (0x120812000) libwind.so.11 = /usr/lib/libwind.so.11 (0x120918000) libheimbase.so.11 = /usr/lib/libheimbase.so.11 (0x120952000) libroken.so.11 = /usr/lib/libroken.so.11 (0x120968000) libcrypt.so.5 = /lib/libcrypt.so.5 (0x120996000) libssl.so.6 = /usr/lib/libssl.so.6 (0x1209d) ^^^ libz.so.6 = /lib/libz.so.6 (0x120a72000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x120aaa000) libthr.so.3 = /lib/libthr.so.3 (0x120acc000) libc.so.7 = /lib/libc.so.7 (0x120b1a000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x120dca000) TZAV TZAV ldd /usr/local/bin/fetchmail /usr/local/bin/fetchmail: libopie.so.7 = /usr/lib/libopie.so.7 (0x12010) libcrypt.so.5 = /lib/libcrypt.so.5 (0x12011e000) libkvm.so.5 = /lib/libkvm.so.5 (0x120158000) libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x120178000) libssl.so.6 = /usr/lib/libssl.so.6 (0x12018a000) ^^^ libcrypto.so.6 = /lib/libcrypto.so.6 (0x12022c000) ^^^ libc.so.7 = /lib/libc.so.7 (0x1204dc000) libmd.so.6 = /lib/libmd.so.6 (0x12078c000) TZAV Or will the new library (what is it?) will not be used unless I delete the old ones? Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: openssl upgrade, libcrypto, libssl confusion
On Wed, Jul 25, 2012 at 5:06 AM, Anton Shterenlikht me...@bristol.ac.uk wrote: On Wed, Jul 25, 2012 at 12:30:29PM +0100, Anton Shterenlikht wrote: In /usr/src/UPDATING I see 20120712: The OpenSSL has been upgraded to 1.0.1c. Any binaries requiring libcrypto.so.6 or libssl.so.6 must be recompiled. Also, there are configuration changes. Make sure to merge /etc/ssl/openssl.cnf. oops.. wait a minute, I'm still on # uname -a FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012 r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 # So this change shouldn't apply to me yet. Still there are *lots* of binaries, and libs linked with /lib/libcrypto.so.6: Binaries that are linked with: /lib/libcrypto.so.6 ... and so on, so is it really right that I can safely delete it? Some ldd/objdump and grep magic will give you the answer you need. check-old-libs only points out candidates for removal based on existence. Cheers, -Garrett That's scary. /usr/src/Makefile calles these obsolete, which means these can be safely deleted: # check-old-libs - List obsolete libraries. # delete-old-libs - Delete obsolete libraries. From what you are saying, and from what I observe, the algorithm used to determine whether the libs are obsolete cannot be trusted. For example, on another ia64 box, r238540, I get: # make -C /usr/src/ check-old-libs Checking for old libraries /usr/lib/libftpio.so.8 /lib/libz.so.5 /lib/libutil.so.8 # None of these are obsolete. First, the base OS programs (not ports) depend on these libs: (I usually use sysutils/libchk to check this) Binaries that are linked with: /usr/lib/libftpio.so.8 /usr/sbin/sysinstall Binaries that are linked with: /lib/libz.so.5 /usr/sbin/dtrace /usr/sbin/lockstat Binaries that are linked with: /lib/libutil.so.8 /usr/sbin/sysinstall Second, at least for libftpio.so.8, there is no newer version. Finally, how come I have base OS binaries linked against old libs, if I always do the orthodox make buildworld, make buildkernel, make installkernel, make installworld? This just shouldn't happen, right? # ls -al /lib/libz.so.* -r--r--r-- 1 root wheel 151200 Jul 18 2010 /lib/libz.so.5 -r--r--r-- 1 root wheel 155264 Jul 18 11:25 /lib/libz.so.6 # ldd /usr/sbin/dtrace /usr/sbin/dtrace: libdtrace.so.2 = /lib/libdtrace.so.2 (0x2000400b2000) libproc.so.2 = /usr/lib/libproc.so.2 (0x2000401b2000) libctf.so.2 = /lib/libctf.so.2 (0x2000401c6000) libelf.so.1 = /usr/lib/libelf.so.1 (0x2000401ee000) libz.so.5 = /lib/libz.so.5 (0x20004022e000) libthr.so.3 = /lib/libthr.so.3 (0x200040264000) libc.so.7 = /lib/libc.so.7 (0x2000402b2000) # ls -al /usr/sbin/dtrace -r-xr-xr-x 1 root wheel 58976 Jul 18 2010 /usr/sbin/dtrace Any why is dtrace so old? Something is not right here... ___ 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: Use of C99 extra long double math functions after r236148
On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote:
Many thanks to you three for implementing expl() with r238722 and r238724.
I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99 function?
It's not clear to me what you mean by test. If expl() is
not available in libm, then linking the code would fail.
So, testing for the existence of expl() (for example,
in a configure script) is as simple as
#include math.h
long double
func(long double x)
{
return (expl(x));
}
//---
#include stdio.h
#include math.h
int main(void)
{
double c = 2.0;
long double d = 2.0;
double e = exp(c);
long double f = expl(d);
printf(exp(%f) is %.*f\n, c, 90, e);
printf(expl(%Lf) is %.*Lf\n, d, 90, f);
If you mean testing that the output is correct, then
asking for 90 digits is of little use. The following
is sufficient (and my actually produce a digit or two
more than is available in number)
troutmask:fvwm:kargl[203] diff -u a.c.orig a.c
--- a.c.orig2012-07-25 09:38:31.0 -0700
+++ a.c 2012-07-25 09:40:36.0 -0700
@@ -1,5 +1,6 @@
#include stdio.h
#include math.h
+#include float.h
int main(void)
{
@@ -9,8 +10,8 @@
double e = exp(c);
long double f = expl(d);
- printf(exp(%f) is %.*f\n, c, 90, e);
- printf(expl(%Lf) is %.*Lf\n, d, 90, f);
+ printf(exp(%f) is %.*f\n, c, DBL_DIG+2, e);
+ printf(expl(%Lf) is %.*Lf\n, d, LDBL_DIG+2, f);
return 0;
}
return 0;
}
//---
Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards
it gives me:
exp(2.00) is
7.38905609893065040
expl(2.00) is
7.38905609893065022739
Already the sixteenth position after decimal point differs.
DBL_DIG is 15 on x86 hardware and LDBL_DIG is 18. You can
expect at most 15 correct digits from exp().
Please forgive me, if this is a really stupid approach for producing
some expl() output.
If you actually want to test expl() to see if it is producing
a decent result, you need a reference solution that contains
a higher precision. I use mpfr with 256 bits of precision.
troutmask:fvwm:kargl[213] ./testl -V 2
ULP = 0.3863
x = 2.00e+00
libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.3890560989306502272304274605750078131803155705518\
47324087127822522573796079054e+00
mpfr: 0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0
The 1st 'mpfr:' line is produced after converting the results
fof mpfr_exp() to long double. The 2nd 'mpfr:' line is
produced by mpfr_printf() where the number of printed
digits depends on the 256-bit precision. The last 'mpfr:'
line is mpfr_printf()'s hex formatting. Unfortunately, it
does not normalize the hex representation to start with
'0x1.', which makes comparison somewhat difficult.
--
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: MPSAFE VFS -- List of upcoming actions
On 7/21/12, Antony Mawer li...@mawer.org wrote: On Wed, Jul 18, 2012 at 6:45 PM, Attilio Rao atti...@freebsd.org wrote: 2012/7/18, Gustau Pérez i Querol gpe...@entel.upc.edu: Sorry fo the delay. About the ntfs support, I'd go with fuse and leave the most relevant filesystems in kernel space. In fact filesystems not particulary specific and not tied our kernel would go to userspace; thinks like smbfs, nwfs, ntfs, ext2 o ext4 for example should be in userspace (the list is incomplete and I don't really know if all of them are yet implemenent in userspace) in my opinion. That would make them easier to maintain (changes in the kernel would only affect fuse, once fixed all the userspace filesystem would work again). As a bonus, we would get many working fs based on fuse. In the server side gluster is a desirable thing; in the desktop things like gvfs (in the linux world gvfs is used not only by gnome but also by kde or xfce) or truecrypt I'm really concerned also about ntfs and smbfs at the moment. It seems that there is also a FUSE smbfs port, but I never used it and I'm not sure about its state at all. From what I understand, Apple have done a considerable amount of work on the FreeBSD-drived smbfs in the latest versions of OS X, based on the existing smbfs in tree: I've also found that there are 2 FUSE modules for smbfs but pho@ and flo@ still haven't tested them. It may make sense to do so before we commit FUSE to -CURRENT. However, thee is a plan by a $COMPANY to work on the in-kernel version of smbfs and lock it before 10.0 is shipped. In the unlikely events this doesn't happen we will came up with a different plan (assuming we will adopt anyway the FUSE module, if it proves to work well). http://www.opensource.apple.com/source/smb/smb-552.5/ I imagine things like the filesystem locking are probably somewhat different, but in terms of updating smbfs itself to support newer features it may be a good base (licensing permitting). smbfs at the moment lacks in some areas such as DFS support, although I do not know if the OS X version is any different there (given the consumer focus of their OS, probably not). There was also a version spun off by OpenSolaris: http://hub.opensolaris.org/bin/view/Project+smbfs/ which again was based on the FreeBSD + Apple versions. I also have a vested interest in NWFS continuing to work - only from a legacy point of view where we still interoperate with a number of Netware 6 servers through this. While those will likely eventually go away, more than likely before we move to 10.x, if there is anyone capable of working on it we could supply a test environment. Unfortunately the actual locking of the NWFS and NCP modules is outside my sphere of knowledge... If you have NCP, do you think you can try this netncp I never committed because lack of testing?: http://lists.freebsd.org/pipermail/freebsd-fs/2009-January/005617.html IIRC, Apple does a similar thing for netsmb (which suffers from a similar problem as netncp). Do you know if FUSE can support NWFS in any way? Starting providing stress-tests on the current codebase for NWFS/NetNCP (and report bugs found, preparing a list) could be a good way to start the locking effort. Interested developers then can look into such a list and provide necessary insight. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: Use of C99 extra long double math functions after r236148
On 11.07.2012 00:58 (UTC+2), David Schultz wrote:
On Tue, Jul 10, 2012, Rainer Hurling wrote:
On 10.07.2012 17:11 (UTC+2), David Schultz wrote:
On Tue, Jul 10, 2012, Rainer Hurling wrote:
On 10.07.2012 16:02 (UTC+2), Warner Losh wrote:
On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote:
As far as I understand from discussions on R mailing list
(r-de...@r-project.org), they plan to reduce the emulation and/or
workaround of long and complex math functions for FreeBSD and other
systems with their next releases of R devel. So we could really need
some
progress with our C99 conform math functions ;-)
Not having R would be a bit pain in my backside. That's one of the
practical considerations that I was talking about. It is very real, and
if I have to, I'll commit the #define junk I railed against to get it
back. Please, let's get some progress. I have some time to help.
Yes, thank you Warner, that is also my problem. As I wrote some weeks
ago (05/28/2012) when starting this thread, I am using FreeBSD as a
scientific desktop because of its good scaling properties. For some
years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and
some more.
If I would not be able to run upcoming versions of R on FreeBSD any
more, that would be really, really hard :-(
Do you have a list of the essential functions here? There are 17 long
double functions and some complex functions missing, but only a
handful of those are of general interest. The reason I ask is that if
R is just looking for a few missing functions that are already mostly
implemented, then the best solution is probably to finish that work.
But if it's expecting us to have something arcane like long double
Bessel functions of the first kind, then we need to pursue a workaround
in the short term.
That is, what I found by grepping the sources of a recent R development
version:
expl: src/nmath/pnchisq.c
Many thanks to you three for implementing expl() with r238722 and r238724.
I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99 function?
//---
#include stdio.h
#include math.h
int main(void)
{
double c = 2.0;
long double d = 2.0;
double e = exp(c);
long double f = expl(d);
printf(exp(%f) is %.*f\n, c, 90, e);
printf(expl(%Lf) is %.*Lf\n, d, 90, f);
return 0;
}
//---
Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards
it gives me:
exp(2.00) is
7.38905609893065040694182243896648287773132324218750
expl(2.00) is
7.38905609893065022739794267536694860609713941812515258789062500
Already the sixteenth position after decimal point differs.
Please forgive me, if this is a really stupid approach for producing
some expl() output.
uname -a: FreeBSD xxx.xxx.xxx 10.0-CURRENT FreeBSD 10.0-CURRENT #0
r238740: Tue Jul 24 18:08:13 CEST 2012
x...@xxx.xxx.xxx:/usr/obj/usr/src/sys/XXX amd64
Rainer
logl: src/nmath/dnbeta.c
src/nmath/pnbeta.c
Bruce has versions of these that could be committed with some cleanup.
It's a matter of sorting through about 1200 emails from him and 3
source trees to find the most up-to-date patches, then cleaning them
up and testing and committing them. I have no time right now, but I
will do at least the first step as soon as I can, and try to get the
patches to someone willing to do the final few steps.
log10l: src/extra/trio/trio.c
log1pl: src/nmath/pnbeta.c
If Bruce doesn't already have implementations of these, they are easy
wrappers around logl() or some internal k_logl in Bruce's implementation.
powl: src/extra/trio/triostr.c
src/extra/trio/trio.c
src/main/format.c
It's hard to do a good job on powl(), but the simple approach
(exp(log(x)*y)) plus a few special cases may suffice for many uses.
NEWS:l2044
The C99 functions acosh, asinh, atanh, snprintf and vsnprintf are
now required.
We have had them forever.
NEWS:l3032
The C99 double complex type is now required.
The C99 complex trigonometric functions (such as csin) are not
currently required (FreeBSD lacks most of them): substitutes are
used if they are missing.
We have these (but not the inverse trig functions).
NEWS:l3277
Complex arithmetic (notably z^n for complex z and integer n) gave
incorrect results since R 2.10.0 on platforms without C99 complex
support. This and some lesser issues in trigonometric functions
have been corrected.
Such platforms were rare (we know of Cygwin and FreeBSD).
However, because of new compiler optimizations in the way complex
arguments are handled, the same code was selected on x86_64 Linux
with gcc 4.5.x at the default -O2 optimization (but not at -O).
Not sure if this is relevant.
BTW: There seems to be a discrepancy about missing functions listed in
http://wiki.freebsd.org/MissingMathStuff
Re: Use of C99 extra long double math functions after r236148
On 07/25/12 11:29, Rainer Hurling wrote:
Many thanks to you three for implementing expl() with r238722 and r238724.
I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99 function?
//---
#include stdio.h
#include math.h
int main(void)
{
double c = 2.0;
long double d = 2.0;
double e = exp(c);
long double f = expl(d);
printf(exp(%f) is %.*f\n, c, 90, e);
printf(expl(%Lf) is %.*Lf\n, d, 90, f);
return 0;
}
//---
Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards
it gives me:
exp(2.00) is
7.38905609893065040694182243896648287773132324218750
expl(2.00) is
7.38905609893065022739794267536694860609713941812515258789062500
Just as a point of comparison, here is the answer computed using
Mathematica:
N[Exp[2], 50]
7.3890560989306502272304274605750078131803155705518
As you can see, the expl solution has only a few digits more accuracy
that exp.
___
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: Use of C99 extra long double math functions after r236148
On Wed, Jul 25, 2012 at 12:27:43PM -0500, Stephen Montgomery-Smith wrote: On 07/25/12 11:29, Rainer Hurling wrote: Many thanks to you three for implementing expl() with r238722 and r238724. I am not a C programmer, but would like to ask if the following example is correct and suituable as a minimalistic test of this new C99 function? (program deleted) Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards it gives me: exp(2.00) is 7.3890560989306504069 expl(2.00) is 7.38905609893065022739794 Just as a point of comparison, here is the answer computed using Mathematica: N[Exp[2], 50] 7.3890560989306502272304274605750078131803155705518 As you can see, the expl solution has only a few digits more accuracy that exp. Unless you are using sparc64 hardware. flame:kargl[204] ./testl -V 2 ULP = 0.2670 for x = 2.0e+00 mpfr exp: 7.389056098930650227230427460575008e+00 libm exp: 7.389056098930650227230427460575008e+00 -- 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: Use of C99 extra long double math functions after r236148
On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote:
On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote:
Many thanks to you three for implementing expl() with r238722 and r238724.
I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99 function?
It's not clear to me what you mean by test. If expl() is
not available in libm, then linking the code would fail.
So, testing for the existence of expl() (for example,
in a configure script) is as simple as
Sorry for not being clear enough. I didn't mean testing for the
existence, but for some comparable output between exp() and expl(), on a
system with expl() available in libm.
#include math.h
long double
func(long double x)
{
return (expl(x));
}
//---
#include stdio.h
#include math.h
int main(void)
{
double c = 2.0;
long double d = 2.0;
double e = exp(c);
long double f = expl(d);
printf(exp(%f) is %.*f\n, c, 90, e);
printf(expl(%Lf) is %.*Lf\n, d, 90, f);
If you mean testing that the output is correct, then
asking for 90 digits is of little use. The following
is sufficient (and my actually produce a digit or two
more than is available in number)
Ok, I understand. I printed the 90 digits to be able to take a look at
the decimal places, I did not expect to get valid digits in this area.
troutmask:fvwm:kargl[203] diff -u a.c.orig a.c
--- a.c.orig2012-07-25 09:38:31.0 -0700
+++ a.c 2012-07-25 09:40:36.0 -0700
@@ -1,5 +1,6 @@
#include stdio.h
#include math.h
+#include float.h
int main(void)
{
@@ -9,8 +10,8 @@
double e = exp(c);
long double f = expl(d);
- printf(exp(%f) is %.*f\n, c, 90, e);
- printf(expl(%Lf) is %.*Lf\n, d, 90, f);
+ printf(exp(%f) is %.*f\n, c, DBL_DIG+2, e);
+ printf(expl(%Lf) is %.*Lf\n, d, LDBL_DIG+2, f);
return 0;
}
Thanks, I was not aware of DBL_DIG and LDBL_DIG.
return 0;
}
//---
Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards
it gives me:
exp(2.00) is
7.38905609893065040
expl(2.00) is
7.38905609893065022739
Already the sixteenth position after decimal point differs.
DBL_DIG is 15 on x86 hardware and LDBL_DIG is 18. You can
expect at most 15 correct digits from exp().
Please forgive me, if this is a really stupid approach for producing
some expl() output.
If you actually want to test expl() to see if it is producing
a decent result, you need a reference solution that contains
a higher precision. I use mpfr with 256 bits of precision.
troutmask:fvwm:kargl[213] ./testl -V 2
ULP = 0.3863
x = 2.00e+00
libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.3890560989306502272304274605750078131803155705518\
47324087127822522573796079054e+00
mpfr: 0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0
The 1st 'mpfr:' line is produced after converting the results
fof mpfr_exp() to long double. The 2nd 'mpfr:' line is
produced by mpfr_printf() where the number of printed
digits depends on the 256-bit precision. The last 'mpfr:'
line is mpfr_printf()'s hex formatting. Unfortunately, it
does not normalize the hex representation to start with
'0x1.', which makes comparison somewhat difficult.
Many thanks also for this mpfr example. This helps me to understand a
little bit more what is going here. So on amd64 even the expl() result
is far from what mpfr provides.
___
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: Use of C99 extra long double math functions after r236148
On 07/25/12 12:31, Steve Kargl wrote: On Wed, Jul 25, 2012 at 12:27:43PM -0500, Stephen Montgomery-Smith wrote: On 07/25/12 11:29, Rainer Hurling wrote: Many thanks to you three for implementing expl() with r238722 and r238724. I am not a C programmer, but would like to ask if the following example is correct and suituable as a minimalistic test of this new C99 function? (program deleted) Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards it gives me: exp(2.00) is 7.3890560989306504069 expl(2.00) is 7.38905609893065022739794 Just as a point of comparison, here is the answer computed using Mathematica: N[Exp[2], 50] 7.3890560989306502272304274605750078131803155705518 As you can see, the expl solution has only a few digits more accuracy that exp. Unless you are using sparc64 hardware. flame:kargl[204] ./testl -V 2 ULP = 0.2670 for x = 2.0e+00 mpfr exp: 7.389056098930650227230427460575008e+00 libm exp: 7.389056098930650227230427460575008e+00 Yes. It would be nice if long on the Intel was as long as the sparc64. ___ 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: Use of C99 extra long double math functions after r236148
On Wed, Jul 25, 2012 at 07:33:07PM +0200, Rainer Hurling wrote:
On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote:
If you actually want to test expl() to see if it is producing
a decent result, you need a reference solution that contains
a higher precision. I use mpfr with 256 bits of precision.
troutmask:fvwm:kargl[213] ./testl -V 2
ULP = 0.3863
x = 2.00e+00
libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.3890560989306502272304274605750078131803155705518\
47324087127822522573796079054e+00
mpfr:
0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0
The 1st 'mpfr:' line is produced after converting the results
fof mpfr_exp() to long double. The 2nd 'mpfr:' line is
produced by mpfr_printf() where the number of printed
digits depends on the 256-bit precision. The last 'mpfr:'
line is mpfr_printf()'s hex formatting. Unfortunately, it
does not normalize the hex representation to start with
'0x1.', which makes comparison somewhat difficult.
Many thanks also for this mpfr example. This helps me to understand a
little bit more what is going here. So on amd64 even the expl() result
is far from what mpfr provides.
Of course!. MPFR is a multiple precision library. One specifies
the precision, and mpfr returns a value with that precision.
#include mpfr.h
int
main(void)
{
int i, j[5] = {24, 53, 64, 113, 256};
mpfr_t x, f;
for (i = 0; i 5; i++) {
/* Set working precision to j[i]. */
mpfr_inits2(j[i], x, f, MPFR_RNDN);
mpfr_set_ui(x, 2, MPFR_RNDN);
mpfr_exp(f, x, MPFR_RNDN);
mpfr_printf(exp(%Re) = %Re\n, x, f);
mpfr_clears(x, f, NULL);
}
}
troutmask:fvwm:kargl[222] cc -o z -I/usr/local/include a.c -L/usr/local/lib\
-lmpfr -lgmp
troutmask:fvwm:kargl[223] ./z
exp(2e+00) = 7.38905621e+00
exp(2e+00) = 7.3890560989306504e+00
exp(2e+00) = 7.3890560989306502274e+00
exp(2e+00) = 7.38905609893065022723042746057500802e+00
exp(2e+00) = 7.38905609893065022723042746057500781\
3180315570551847324087127822522573796079054e+00
--
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: MPSAFE VFS -- List of upcoming actions
On Wed, Jul 25, 2012 at 10:04 AM, Attilio Rao atti...@freebsd.org wrote: On 7/21/12, Antony Mawer li...@mawer.org wrote: On Wed, Jul 18, 2012 at 6:45 PM, Attilio Rao atti...@freebsd.org wrote: 2012/7/18, Gustau Pérez i Querol gpe...@entel.upc.edu: Sorry fo the delay. About the ntfs support, I'd go with fuse and leave the most relevant filesystems in kernel space. In fact filesystems not particulary specific and not tied our kernel would go to userspace; thinks like smbfs, nwfs, ntfs, ext2 o ext4 for example should be in userspace (the list is incomplete and I don't really know if all of them are yet implemenent in userspace) in my opinion. That would make them easier to maintain (changes in the kernel would only affect fuse, once fixed all the userspace filesystem would work again). As a bonus, we would get many working fs based on fuse. In the server side gluster is a desirable thing; in the desktop things like gvfs (in the linux world gvfs is used not only by gnome but also by kde or xfce) or truecrypt I'm really concerned also about ntfs and smbfs at the moment. It seems that there is also a FUSE smbfs port, but I never used it and I'm not sure about its state at all. From what I understand, Apple have done a considerable amount of work on the FreeBSD-drived smbfs in the latest versions of OS X, based on the existing smbfs in tree: I've also found that there are 2 FUSE modules for smbfs but pho@ and flo@ still haven't tested them. It may make sense to do so before we commit FUSE to -CURRENT. However, thee is a plan by a $COMPANY to work on the in-kernel version of smbfs and lock it before 10.0 is shipped. In the unlikely events this doesn't happen we will came up with a different plan (assuming we will adopt anyway the FUSE module, if it proves to work well). http://www.opensource.apple.com/source/smb/smb-552.5/ I imagine things like the filesystem locking are probably somewhat different, but in terms of updating smbfs itself to support newer features it may be a good base (licensing permitting). smbfs at the moment lacks in some areas such as DFS support, although I do not know if the OS X version is any different there (given the consumer focus of their OS, probably not). There was also a version spun off by OpenSolaris: http://hub.opensolaris.org/bin/view/Project+smbfs/ which again was based on the FreeBSD + Apple versions. I also have a vested interest in NWFS continuing to work - only from a legacy point of view where we still interoperate with a number of Netware 6 servers through this. While those will likely eventually go away, more than likely before we move to 10.x, if there is anyone capable of working on it we could supply a test environment. Unfortunately the actual locking of the NWFS and NCP modules is outside my sphere of knowledge... If you have NCP, do you think you can try this netncp I never committed because lack of testing?: http://lists.freebsd.org/pipermail/freebsd-fs/2009-January/005617.html IIRC, Apple does a similar thing for netsmb (which suffers from a similar problem as netncp). Do you know if FUSE can support NWFS in any way? Starting providing stress-tests on the current codebase for NWFS/NetNCP (and report bugs found, preparing a list) could be a good way to start the locking effort. Interested developers then can look into such a list and provide necessary insight. 1. The in-kernel smbfs is so far behind the SMB spec that I'm not sure that it's worthwhile maintaining it. It's SMB1.x based, which is pre-Vista; SMB2.1 has been out for a while and 3.0 is rolling around the corner in the next couple years (about the same time Windows XP is going to be EOS). 2. According to reports I have from internal sources, the Apple implementation is suboptimal from a performance perspective, in part because the Apple SMB client doesn't coalesce requests. I concur on the poor performance based on personal experience because NFS beats SMB hands down on OSX (comes close to saturating the physical media with NFS, and putters along at a fraction of the link speed with CIFS on my Macbook Pro with Lion), whereas running a Windows 7 client against samba36 yields performance I would expect (saturates gigabit). YMMV, -Garrett 1. http://windows.microsoft.com/en-us/windows/products/lifecycle ___ 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: machine freezes when using USB disk and X
Hi, On Wed, 25 Jul 2012 16:13:04 +0200 Hans Petter Selasky hsela...@c2i.net wrote: On Wednesday 25 July 2012 14:54:08 Erich Dollansky wrote: I have strange problem which I can reproduce. When I copy some 100GB to a disk via USB when X is not active, it works without any problems. When I copy some 100GB to a disk via USB when X is running, the machine freezes. It does not react to keyboard, mouse and network actions. When I use only X on the same machine and do the same copy via network, the machine behaves as expected. What could I do to locate the problem? Erich PS uname says: FreeBSD AMD620.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #38: Sat Jul 21 06:58:49 WIT 2012 You might want to check what interrupts are shared. Might be an IRQ problem. it does not look like. As it was working before since 8.0 without problems, I cannot imagine that this is the real problem even if they would be shared. I do not expect a solution for this. It is more or less a hint for developers working in the affected areas that there might be something wrong. Erich ___ 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: Use of C99 extra long double math functions after r236148
On Wed, 25 Jul 2012, Rainer Hurling wrote:
On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote:
On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote:
Many thanks to you three for implementing expl() with r238722 and r238724.
I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99 function?
It's not clear to me what you mean by test. If expl() is
not available in libm, then linking the code would fail.
So, testing for the existence of expl() (for example,
in a configure script) is as simple as
Sorry for not being clear enough. I didn't mean testing for the existence,
but for some comparable output between exp() and expl(), on a system with
expl() available in libm.
This is basically what I do to test exp() (with a few billion cases
automatically generated and compared). It is not sufficient for
checking expl(), except for consistency. (It is assumed that expl()
is reasonably accurate. If it is in fact less accurate than exp(),
this tends to show up in the comparisons.)
#include math.h
long double
func(long double x)
{
return (expl(x));
}
//---
#include stdio.h
#include math.h
int main(void)
{
double c = 2.0;
long double d = 2.0;
double e = exp(c);
long double f = expl(d);
printf(exp(%f) is %.*f\n, c, 90, e);
printf(expl(%Lf) is %.*Lf\n, d, 90, f);
If you mean testing that the output is correct, then
asking for 90 digits is of little use. The following
is sufficient (and my actually produce a digit or two
more than is available in number)
Ok, I understand. I printed the 90 digits to be able to take a look at the
decimal places, I did not expect to get valid digits in this area.
Use binary format (%a) for manual comparison. Don't print any more
bits than the format has. This is DBL_MANT_DIG (53) for doubles and
LDLBL_MANT_DIG (64 on x86) for long doubles. %a format is in nybbles
and tends to group the bits into nybbles badly. See below on reducing
problems from this. Decimal format has to print about 3 more digits
than are really meaningful, to allow recovering the original value
uniquely. For manual comparison, you need to print these extra digits
and manually round or ignore them as appropriate. The correct number
of extra digits is hard to determine. For the any, type, it is
DECIMAL_DIG (21) on x86. The corresponding number of normally-accurate
decimal digits for long doubles is given by LDBL_DIG (18). For
floats and doubles, this corresponds to FLT_DIG (6) and DBL_DIG (15).
Unfortunately, float.h doesn't define anything corresponding to
DECIMAL_DIG for the smaller types. 21 is a lot of digits and noise
digits take a long time to determine and ignore (its worse on sparc64
where DECIMAL_DIG is 36). I usually add 2 extra digits to the number
of normally-accurate digits. This is sloppy. 3 is needed in some
cases, depending on MANT_DIG and the bits in log(2) and/or log(10).
troutmask:fvwm:kargl[203] diff -u a.c.orig a.c
--- a.c.orig2012-07-25 09:38:31.0 -0700
+++ a.c 2012-07-25 09:40:36.0 -0700
@@ -1,5 +1,6 @@
#include stdio.h
#include math.h
+#include float.h
int main(void)
{
@@ -9,8 +10,8 @@
double e = exp(c);
long double f = expl(d);
- printf(exp(%f) is %.*f\n, c, 90, e);
- printf(expl(%Lf) is %.*Lf\n, d, 90, f);
+ printf(exp(%f) is %.*f\n, c, DBL_DIG+2, e);
+ printf(expl(%Lf) is %.*Lf\n, d, LDBL_DIG+2, f);
return 0;
}
Thanks, I was not aware of DBL_DIG and LDBL_DIG.
Steve is sloppy and adds 2 also :-). For long doubles, it is clear that
3 are strictly needed, since DECIMAL_DIG is 3 more.
For most long double functions on i386, you need to switch the rounding
precision to 64 bits around calls to them, and also to do any operations
on the results except printing them. expl() is one of the few large
functions that does the switch internally. So the above should work
(since it only prints), but (expl(d) + 0) should round to the default
53-bit precision and this give the same result as exp(d).
If you actually want to test expl() to see if it is producing
a decent result, you need a reference solution that contains
a higher precision. I use mpfr with 256 bits of precision.
troutmask:fvwm:kargl[213] ./testl -V 2
ULP = 0.3863
x = 2.00e+00
libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.3890560989306502272304274605750078131803155705518\
47324087127822522573796079054e+00
mpfr:
0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0
The 1st 'mpfr:' line is produced after converting the results
fof mpfr_exp() to long double. The 2nd 'mpfr:' line is
produced by mpfr_printf() where the number of printed
digits depends on the 256-bit precision. The last 'mpfr:'
line is mpfr_printf()'s hex formatting. Unfortunately, it
does not normalize the hex
Re: Use of C99 extra long double math functions after r236148
On Wed, 25 Jul 2012, Stephen Montgomery-Smith wrote: On 07/25/12 12:31, Steve Kargl wrote: On Wed, Jul 25, 2012 at 12:27:43PM -0500, Stephen Montgomery-Smith wrote: Just as a point of comparison, here is the answer computed using Mathematica: N[Exp[2], 50] 7.3890560989306502272304274605750078131803155705518 As you can see, the expl solution has only a few digits more accuracy that exp. Unless you are using sparc64 hardware. flame:kargl[204] ./testl -V 2 ULP = 0.2670 for x = 2.0e+00 mpfr exp: 7.389056098930650227230427460575008e+00 libm exp: 7.389056098930650227230427460575008e+00 Yes. It would be nice if long on the Intel was as long as the sparc64. You want it to be as slow as sparc64? (About 300 times slower, after scaling the CPU clock rates. Doubles on sparc64 are less than 2 times slower.) I forgot to mention in a previous reply is that expl has only a few more decimal digits of accuracy than exp because the extra precision on x86 wasn't designed to give much more accuracy. It was designed to give more chance of full double precision accuracy in naive code. It was designed in ~1980 when bits were expensive and the extra 11 provided by the 8087 were considered the best tradeoff between cost and accuracy. They only previde 2-3 extra decimal digits of accuracy. They are best thought of as guard bits. Floating point uses 1 or 2 guard bits internally. 11 extends that significantly and externalizes it, but is far from doubling the number of bits. Their use to provide extra precision was mostly defeated in C by bad C bindings and implementations. This was consolidated by my not using the extra bits for the default rounding precision in FreeBSD. This has been further consolidated by SSE not supporting extended precision. Now the naive code that uses doubles never gets the extra precision on amd64. Mixing of long doubles with doubles is much slower with SSE+i387 than with i387, since the long doubles are handled in different registers and must be translated with SSE+i387, while with i387, using long doubles is almost free (it actually has a negative cost in non-naive code since it allows avoiding extra precision in software). Thus SSE also inhibits using the extra precision intentionally. Bruce ___ 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
