[head tinderbox] failure on mips/mips
TB --- 2012-04-03 09:20:24 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-03 09:20:24 - starting HEAD tinderbox run for mips/mips TB --- 2012-04-03 09:20:24 - cleaning the object tree TB --- 2012-04-03 09:21:00 - cvsupping the source tree TB --- 2012-04-03 09:21:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-04-03 09:21:38 - building world TB --- 2012-04-03 09:21:38 - CROSS_BUILD_TESTING=YES TB --- 2012-04-03 09:21:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-03 09:21:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-03 09:21:38 - SRCCONF=/dev/null TB --- 2012-04-03 09:21:38 - TARGET=mips TB --- 2012-04-03 09:21:38 - TARGET_ARCH=mips TB --- 2012-04-03 09:21:38 - TZ=UTC TB --- 2012-04-03 09:21:38 - __MAKE_CONF=/dev/null TB --- 2012-04-03 09:21:38 - cd /src TB --- 2012-04-03 09:21:38 - /usr/bin/make -B buildworld World build started on Tue Apr 3 09:21:39 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 [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 kfd.8.gz === kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mips/src/tmp/usr/bin/ld: /obj/mips.mips/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mips/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-03 10:11:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-03 10:11:09 - ERROR: failed to build world TB --- 2012-04-03 10:11:09 - 2097.20 user 449.93 system 3044.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
-ffast-math in Ports and wrong generated code
Hello, I use one port from the Ports Collection, that works with FP. Having reinstalled it (its version was not changed) I noticed that it started to work incorrectly. After debugging and disassembling its code I found out that the -ffast-math option used for building was the result of wrongly generated code (I did not specify this option in /etc/make.conf). At least finite() function call was eliminated from the result Assembler code when -ffast-math option is used, tested on 9.0-STABLE and 10.0-CURRENT. Example test source code and generated code under 9.0-STABLE on amd64 by gcc from the base system: - #include math.h #include stdio.h void check_finite(double x) { printf(%d\n, finite(x)); } - % gcc -Wall -O2 -S finite.c - check_finite: .LFB3: subq$8, %rsp .LCFI0: callfinite -- call to finite() movl$.LC0, %edi movl%eax, %esi addq$8, %rsp xorl%eax, %eax jmp printf .LFE3: .size check_finite, .-check_finite - % gcc -Wall -O2 -ffast-math -S finite.c - check_finite: .LFB3: xorl%esi, %esi -- fake result from finite() movl$.LC0, %edi xorl%eax, %eax jmp printf .LFE3: .size check_finite, .-check_finite - Can somebody comment this? ___ 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: Potential deadlock on mbuf
On 02.04.2012 18:21, Alexandre Martins wrote: Dear, I have currently having troubles with a basic socket stress. The socket are setup to use non-blocking I/O. During this stress-test, the kernel is running mbuf exhaustion, the goal is to see system limits. If the program make a write on a socket during this mbuf exhaustion, it become blocked in write system call. The status of the process is zonelimit and whole network I/O fall in timeout. I have found the root cause of the block : http://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?view=markup#l1279 So, the question is : Why m_uiotombuf is called with a blocking parameter (M_WAITOK) even if is for a non-blocking socket ? Then, if M_NOWAIT is used, maybe it will be usefull to have an 'ENOMEM' error. This is a bit of an catch-22 we have here. Trouble is that when we return with EAGAIN the next select/poll cycle will tell you that this and possibly other sockets are writeable again, when in fact they are not due to kernel memory shortage. Then the application will tightly loop around the writeable non-writeable sockets. It's about the interaction of write with O_NONBLOCK and select/poll on the socket. Do you have any references how other OSes behave, in particular Linux? I've added bde@ as our resident standards compliance expert. Hopefully he can give us some more insight on this issue. -- Andre ___ 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: LSI supported mps(4) driver available
On 28 March 2012 03:51, Kenneth D. Merry k...@freebsd.org wrote: On Tue, Mar 27, 2012 at 23:50:31 +1030, Matt Thyer wrote: On 26 March 2012 23:55, Gary Palmer gpal...@freebsd.org wrote: On Mon, Mar 26, 2012 at 08:05:59PM +1030, Matt Thyer wrote: On Mar 26, 2012 3:43 AM, Garrett Cooper yaneg...@gmail.com wrote: On Sun, Mar 25, 2012 at 5:16 AM, Matt Thyer matt.th...@gmail.com wrote: Has this driver been MFC to 8-STABLE yet ? I'm asking because I updated my NAS on the 4th of March from 8-STABLE r225723 to r232477 and am now seeing 157,000 interrupts per second on irq 16 where my SuperMicro AOC-USAS2-L8i resides (this card uses the LSI SAS2008 chip). [snip] After encountering this problem I updated my firmware from phase 7 to phase 11 but this did not fix things. My question is: Is the LSI driver even in 8-STABLE yet?. If not I'll upgrade to 9-STABLE to get the new driver. If it is, then I want to downgrade to just before it came in to see if this high interrupt rate problem is fixed. I'm no export in svn, however: http://svnweb.freebsd.org/base?view=revisionamp;revision=230922 would appear to suggest that the new driver is in 8-Stable Gary It's painful to take this system back to r230921 due to intolerance for downtime from it's users so I'd like to investigate the cause of the problem and try patches/sysctls/whatever first. The drives I'm using are 7 x WDC WD20EARS-00M (3 are AB50, 4 are AB51) and 1 x WD20EARX-00P AB51. The WD20EARX-00P AB51 is a SATA 3 (6 Gbps) drive but the others are all SATA 2 (3 Gbps). I know the driver doesn't like mixed speeds in IR mode but I'm flashed with IT firmware as ZFS is doing my RAID (raidz2). I was having problems with the WD20EARX-00P AB51 drive being faulted by ZFS until I updated the firmware to 11 and now ZFS is happy (I've also done a full extended drive SMART test and the drive is fine). So what do people suggest (before reversion to r230921) ? If you're going to prove that it's the new LSI driver, you will probably have to go back to the old driver. You don't have to back out your entire tree, you can just back out the driver itself if you have an SVN tree. You can go into sys/dev/mps and do: svn update -r 230714 And then edit sys/conf/files and comment out these three lines: dev/mps/mps_config.coptional mps dev/mps/mps_mapping.c optional mps dev/mps/mps_sas_lsi.c optional mps Then you should be able to rebuild your kernel with the old driver and see if the problem occurs again. Ken -- Kenneth Merry k...@freebsd.org This didn't work for me so I removed my /usr/src and checked out 8-STABLE at revision 230921 (svn checkout -r 230921 http://svn.freebsd.org/base/stable/8 /usr/src). I've built world, kernel etc and installed it using GENERIC kernel done my mergemaster, delete old, delete old-libs and I still have the problem. I'm wondering if it's due to the single 6 Gb drive in my raidz2 (the other 7 are 3 Gb). I've heard that the new driver doesn't like mixed speeds in a raid set when using -IR firmware but I wouldn't expect an issue with ZFS with -IT firmware. It seems that there may be a general incompatibility with both the old and new drivers and the Western Digital WD20EARX-00P 6 Gbps drive. Unfortunately I cannot get the old 3 Gb drive anymore. I'll try moving the WD20EARX-00P drive to the on board SATA ports next. ___ 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: Failure to rebuild x11/nvidia-driver on head at r233697
On Friday, March 30, 2012 5:33:07 pm David Wolfskill wrote: On Fri, Mar 30, 2012 at 01:46:58PM -0400, John Baldwin wrote: ... You can actually use that on 8 and 9 as well. I think it's a likely a bug that it used VM_MEMATTR_UNCACHED in the first place and that it should have been using VM_MEMATTR_UNCACHEABLE all along. (Which is why I've renamed the obscure and not really useful VM_MEMATTR_UNCACHED.) ... OK; that seems to work, at least under stable/8 -- thanks! FYI, this should be fixed in the next driver release from NVIDIA. -- 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: ixgbe-2.4.4 compile error
On 04/02/2012 16:24, Rudy wrote: I used the 9.0-RELEASE memstick to install, did a cvsup to STABLE... When I downloaded Intel's (Jack's) ixgbe driver, I got an error: ixgbe_osdep.h:104: error: conflicting types for 'bool' @/sys/types.h:271: error: previous declaration of 'bool' was here This patch fixed the 'conflict'. diff -u @/sys/types.h.orig @/sys/types.h --- @/sys/types.h.orig 2012-04-02 14:18:26.0 -0700 +++ @/sys/types.h 2012-04-02 14:20:19.0 -0700 @@ -268,7 +268,7 @@ #if __STDC_VERSION__ 199901L __GNUC__ 3 !defined(__INTEL_COMPILER) typedef int _Bool; #endif -typedef _Bool bool; +// typedef _Bool bool; #endif /* !__bool_true_false_are_defined !__cplusplus */ Perhaps a more appropriate change would be in ixgbe_osdep.h: +#ifndef bool typedef boolean_t bool; +#endif This would change the size of the bool type as used in the ixgbe driver, but after a quick glance through the code, I don't think that would cause any trouble. Try it; if it passes traffic, it's probably correct. Eric ___ 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: LSI supported mps(4) driver available
On Mar 27, 2012 11:50 PM, Matt Thyer matt.th...@gmail.com wrote: I was having problems with the WD20EARX-00P AB51 drive being faulted by ZFS until I updated the firmware to 11 and now ZFS is happy (I've also done a full extended drive SMART test and the drive is fine). I forgot to mention that I'm still having problems after this phase 11 firmware upgrade with the 6 Gbps drive being kicked out of the raidz2 with write errors (even though a SMART full surface test says the drive is OK). This leads me to think that both the old and new drivers have a problem with the 6 Gbps WD20EARX-00P AB51 drive. Now that the 6 Gbps drive is on the Intel SATA controller things seem OK but it's a bit early to tell. Stay tuned! ___ 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: Failure to rebuild x11/nvidia-driver on head at r233697
On Tue, Apr 03, 2012 at 08:55:34AM -0400, John Baldwin wrote: ... You can actually use that on 8 and 9 as well. I think it's a likely a bug that it used VM_MEMATTR_UNCACHED in the first place and that it should have been using VM_MEMATTR_UNCACHEABLE all along. (Which is why I've renamed the obscure and not really useful VM_MEMATTR_UNCACHED.) ... OK; that seems to work, at least under stable/8 -- thanks! FYI, this should be fixed in the next driver release from NVIDIA. ... Cool; thanks for mentioning it. In the mean time, the patch (that I posted earlier) that replaces VM_MEMATTR_UNCACHED with VM_MEMATTR_UNCACHEABLE works for me under stable/8, stable/9, and head, so folks may want to use something like that if they don't want to wait. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpfxCCZtYUBu.pgp Description: PGP signature
Re: LSI supported mps(4) driver available
On Tue, Apr 03, 2012 at 10:52:25PM +0930, Matt Thyer wrote: On Mar 27, 2012 11:50 PM, Matt Thyer matt.th...@gmail.com wrote: I was having problems with the WD20EARX-00P AB51 drive being faulted by ZFS until I updated the firmware to 11 and now ZFS is happy (I've also done a full extended drive SMART test and the drive is fine). I forgot to mention that I'm still having problems after this phase 11 firmware upgrade with the 6 Gbps drive being kicked out of the raidz2 with write errors (even though a SMART full surface test says the drive is OK). This leads me to think that both the old and new drivers have a problem with the 6 Gbps WD20EARX-00P AB51 drive. Now that the 6 Gbps drive is on the Intel SATA controller things seem OK but it's a bit early to tell. Stay tuned! I think you should contact either SuperMicro or LSI and open a support case as it looks like there could be a problem with either the controller or the firmware when presented with mixed speed devices. Either way I think this needs to be escalated to the manufacturer. Regards, Gary ___ 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: -ffast-math in Ports and wrong generated code
On Tue, Apr 03, 2012 at 02:21:11PM +0300, Andrey Simonenko wrote: I use one port from the Ports Collection, that works with FP. Having reinstalled it (its version was not changed) I noticed that it started to work incorrectly. After debugging and disassembling its code I found out that the -ffast-math option used for building was the result of wrongly generated code (I did not specify this option in /etc/make.conf). At least finite() function call was eliminated from the result Assembler code when -ffast-math option is used, tested on 9.0-STABLE and 10.0-CURRENT. Example test source code and generated code under 9.0-STABLE on amd64 by gcc from the base system: - #include math.h #include stdio.h void check_finite(double x) { printf(%d\n, finite(x)); } - % gcc -Wall -O2 -S finite.c - check_finite: .LFB3: subq$8, %rsp .LCFI0: callfinite -- call to finite() movl$.LC0, %edi movl%eax, %esi addq$8, %rsp xorl%eax, %eax jmp printf .LFE3: .size check_finite, .-check_finite - % gcc -Wall -O2 -ffast-math -S finite.c - check_finite: .LFB3: xorl%esi, %esi -- fake result from finite() movl$.LC0, %edi xorl%eax, %eax jmp printf .LFE3: .size check_finite, .-check_finite - Can somebody comment this? Read the man page for gcc. With --fast-math, gcc assumes that the result of any FP operation is finite. So, the function call to finite() is eliminated as it is always true. -- 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: Potential deadlock on mbuf
On Tue, 3 Apr 2012, Andre Oppermann wrote: On 02.04.2012 18:21, Alexandre Martins wrote: Dear, I have currently having troubles with a basic socket stress. The socket are setup to use non-blocking I/O. During this stress-test, the kernel is running mbuf exhaustion, the goal is to see system limits. If the program make a write on a socket during this mbuf exhaustion, it become blocked in write system call. The status of the process is zonelimit and whole network I/O fall in timeout. I have found the root cause of the block : http://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?view=markup#l1279 So, the question is : Why m_uiotombuf is called with a blocking parameter (M_WAITOK) even if is for a non-blocking socket ? Then, if M_NOWAIT is used, maybe it will be usefull to have an 'ENOMEM' error. I'm surprised you can even see blocking of malloc(... M_WAITOK). O_NONBLOCK is mostly for operations that might block for a long time, but malloc() is not expected to block for long. Regular files are always so non-blocking that most file systems have no references to O_NONBLOCK (or FNONBLOCK), but file systems often execute memory allocation code that can easily block for as long as malloc() does. When malloc() starts blocking for a long time, lots of things will fail. This is a bit of an catch-22 we have here. Trouble is that when we return with EAGAIN the next select/poll cycle will tell you that this and possibly other sockets are writeable again, when in fact they are not due to kernel memory shortage. Then the application will tightly loop around the writeable non-writeable sockets. It's about the interaction of write with O_NONBLOCK and select/poll on the socket. This would be difficult to handle better. Do you have any references how other OSes behave, in particular Linux? I've added bde@ as our resident standards compliance expert. Hopefully he can give us some more insight on this issue. Standards won't say what happens at this level of detail. Blocking for network i/o is still completely broken at levels below sockets AFAIK. I (and ttcp) mainly wanted it to work for send() of udp. I saw no problems at the socket level, but driver queues just filled up and send() returned ENOBUFS. I wanted either the opposite of O_NONBLOCK (block until !ENOBUFS), or at least for select() to work for waiting until !ENOBUFS. But select() doesn't work at all for this. It seemed to work better in Linux. 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
Re: -ffast-math in Ports and wrong generated code
On Tue, 3 Apr 2012 14:21:11 +0300, Andrey Simonenko wrote: At least finite() function call was eliminated from the result Assembler code when -ffast-math option is used, tested on 9.0-STABLE and 10.0-CURRENT. The documentation for -ffast-math once (GCC 3.x?) contained -ffast-math Might allow some programs designed to not be too dependent on IEEE behavior for floating-point to run faster, or die trying. which seems like what you're observing. -ffast-math includes -ffinite-math-only which assumes that floating-point arguments and results are never NaNs or +-Infs. Compiling your code with -ffast-math -fno-finite-math-only should restore the call to finite(). -- Thomas Mueller ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote: ... You could try the patch attached. It adds support for size option suffixes (like 1g) and introduces swap limit (part of the older patch, not sure if it's any use). Patch is against 10-CURRENT. Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d ... After building: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 233772M: Mon Apr 2 05:42:48 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 with the referenced patch, I ran with it for the bulk of my daily activities on the laptop yesterday, then (this morning), I performed a source upgrade to: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1 233835M: Tue Apr 3 07:07:39 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 and nothing peculiar or unexpected happened at all. :-} As far as I can tell, the patch does no harm, and enables tmpfs size specifications to be more readily made and understood. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpAiRgZuH2kX.pgp Description: PGP signature
Re: Using TMPFS for /tmp and /var/run?
jb jb.1234abcd at gmail.com writes: ... There are memory management subsystem considerations against utilizing tmpfs (memory + swap) for /tmp: ... - Out-of-Memory (OOM) killer Due to it, on heavy loaded systems processes dying on memory pressure. - Pterodactyl The next MM subsystem feature. An urban legend ... The final frontier ... jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on mips/mips
TB --- 2012-04-03 17:15:04 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-03 17:15:04 - starting HEAD tinderbox run for mips/mips TB --- 2012-04-03 17:15:04 - cleaning the object tree TB --- 2012-04-03 17:15:44 - cvsupping the source tree TB --- 2012-04-03 17:15:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-04-03 17:16:26 - building world TB --- 2012-04-03 17:16:26 - CROSS_BUILD_TESTING=YES TB --- 2012-04-03 17:16:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-03 17:16:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-03 17:16:26 - SRCCONF=/dev/null TB --- 2012-04-03 17:16:26 - TARGET=mips TB --- 2012-04-03 17:16:26 - TARGET_ARCH=mips TB --- 2012-04-03 17:16:26 - TZ=UTC TB --- 2012-04-03 17:16:26 - __MAKE_CONF=/dev/null TB --- 2012-04-03 17:16:26 - cd /src TB --- 2012-04-03 17:16:26 - /usr/bin/make -B buildworld World build started on Tue Apr 3 17:16:27 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 [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 kfd.8.gz === kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mips/src/tmp/usr/bin/ld: /obj/mips.mips/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mips/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-03 18:04:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-03 18:04:29 - ERROR: failed to build world TB --- 2012-04-03 18:04:29 - 2033.38 user 432.95 system 2964.90 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -ffast-math in Ports and wrong generated code
Am 03.04.2012 13:21, schrieb Andrey Simonenko: Hello, I use one port from the Ports Collection, that works with FP. Having reinstalled it (its version was not changed) I noticed that it started to work incorrectly. After debugging and disassembling its code I found out that the -ffast-math option used for building was the result of wrongly generated code (I did not specify this option in /etc/make.conf). At least finite() function call was eliminated from the result Assembler code when -ffast-math option is used, tested on 9.0-STABLE and 10.0-CURRENT. Example test source code and generated code under 9.0-STABLE on amd64 by gcc from the base system: - Which port is affected? - Any idea whence the -ffast-math option came on your system? /etc/src.conf? Port's make config? ___ 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: Potential deadlock on mbuf
On Tue, 3 Apr 2012, Andre Oppermann wrote: On 02.04.2012 18:21, Alexandre Martins wrote: Dear, I have currently having troubles with a basic socket stress. The socket are setup to use non-blocking I/O. During this stress-test, the kernel is running mbuf exhaustion, the goal is to see system limits. If the program make a write on a socket during this mbuf exhaustion, it become blocked in write system call. The status of the process is zonelimit and whole network I/O fall in timeout. I have found the root cause of the block : http://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?view=markup#l1279 So, the question is : Why m_uiotombuf is called with a blocking parameter (M_WAITOK) even if is for a non-blocking socket ? Then, if M_NOWAIT is used, maybe it will be usefull to have an 'ENOMEM' error. I'm surprised you can even see blocking of malloc(... M_WAITOK). O_NONBLOCK is mostly for operations that might block for a long time, but malloc() is not expected to block for long. Regular files are always so non-blocking that most file systems have no references to O_NONBLOCK (or FNONBLOCK), but file systems often execute memory allocation code that can easily block for as long as malloc() does. When malloc() starts blocking for a long time, lots of things will fail. The fact is that all mbuf are used by connected sockets, waiting for program reading. But the program try to make a write for data transfert. So, the mbuf allocation block in waiting of available mbuf, but the only proccess wich can free mbuf is blocked. The mbuff allocation is deadlocked and host become unreachable. This is a bit of an catch-22 we have here. Trouble is that when we return with EAGAIN the next select/poll cycle will tell you that this and possibly other sockets are writeable again, when in fact they are not due to kernel memory shortage. Then the application will tightly loop around the writeable non-writeable sockets. It's about the interaction of write with O_NONBLOCK and select/poll on the socket. This would be difficult to handle better. I play with the flag. I switched it to M_NOWAIT en return a EAGAIN error if allocation failed. The program fail some write, but try again later and the host continue to be reachable. I agree that solution is not correct. Do you have any references how other OSes behave, in particular Linux? I've added bde@ as our resident standards compliance expert. Hopefully he can give us some more insight on this issue. Standards won't say what happens at this level of detail. Blocking for network i/o is still completely broken at levels below sockets AFAIK. I (and ttcp) mainly wanted it to work for send() of udp. I saw no problems at the socket level, but driver queues just filled up and send() returned ENOBUFS. I wanted either the opposite of O_NONBLOCK (block until !ENOBUFS), or at least for select() to work for waiting until !ENOBUFS. But select() doesn't work at all for this. It seemed to work better in Linux. Bruce Alexandre Martins ___ 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
Switching on/off 5V power to a USB port
I just got a little USB powered fan and it sure would be nice if I could have cron on my FreeBSD box turn it on or off at certain times by switching off the 5V line on a USB port. Anyone know how I can do that? Thanks. BTW this is a pretty decent fan for the money. :) http://www.amazon.com/gp/product/B0033WSDOM/ -- Ron McDowell San Antonio TX ___ 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: Switching on/off 5V power to a USB port
On Tue, 2012-04-03 at 17:13 -0500, Ron McDowell wrote: I just got a little USB powered fan and it sure would be nice if I could have cron on my FreeBSD box turn it on or off at certain times by switching off the 5V line on a USB port. Anyone know how I can do that? Thanks. BTW this is a pretty decent fan for the money. :) http://www.amazon.com/gp/product/B0033WSDOM/ The usbconfig(8) command has power_on and power_off commands. I've never used them so I can't say for sure they'll do what you want. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Switching on/off 5V power to a USB port
-Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Ron McDowell Sent: Tuesday, April 03, 2012 3:14 PM To: freebsd-current Subject: Switching on/off 5V power to a USB port I just got a little USB powered fan and it sure would be nice if I could have cron on my FreeBSD box turn it on or off at certain times by switching off the 5V line on a USB port. Anyone know how I can do that? Thanks. Alternatively, you could just plug your USB fan into your monitor. A fellow engineer and I discovered that most monitors power-down the USB ports when entering power-save mode (with Dell, HP, and Viewsonic, this is whenever the screen blanks due to inactivity; are you using DPMS and/or greensaver?). Walking away from the PC will cause the fan to [eventually] turn off, while waggling the mouse brings it back to life. BTW this is a pretty decent fan for the money. :) http://www.amazon.com/gp/product/B0033WSDOM/ We didn't have a USB powered fan, so we actually wired an internal case-fan to the 5V lead and went that route. Nice fan though. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: Switching on/off 5V power to a USB port
In message 4f7b761b.4030...@fuzzwad.org, Ron McDowell writes: I just got a little USB powered fan and it sure would be nice if I could have cron on my FreeBSD box turn it on or off at certain times by switching off the 5V line on a USB port. Anyone know how I can do that? Thanks. I have only found very few USB ports where it was possible to reliably control power with a published interface. Most USB-controllers support doing it, but most motherboards don't mount the necessary FET. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Switching on/off 5V power to a USB port
On 4/3/12 5:26 PM, Ian Lepore wrote: On Tue, 2012-04-03 at 17:13 -0500, Ron McDowell wrote: I just got a little USB powered fan and it sure would be nice if I could have cron on my FreeBSD box turn it on or off at certain times by switching off the 5V line on a USB port. Anyone know how I can do that? Thanks. BTW this is a pretty decent fan for the money. :) http://www.amazon.com/gp/product/B0033WSDOM/ The usbconfig(8) command has power_on and power_off commands. I've never used them so I can't say for sure they'll do what you want. -- Ian The good news is that usbconfig -u 4 -a 5 power_off|power_on works fine. Hardware is a Dell Latitude D-430 notebook running: FreeBSD d430 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r232714M: Fri Mar 9 12:41:34 CST 2012 rcm@d430:/usr/obj/usr/src/sys/GENERIC amd64 When booting up, the fan powers up just as: uhub7: vendor 0x413c product 0xa005, class 9/0, rev 2.00/25.07, addr 5 on usbus4 shows up, which was a pretty good clue to what device it is. Automatically turning it on is pure laziness on my part... turning it off is more about forgetfulness though. :) On 4/3/12 5:45 PM, Devin Teske wrote: Alternatively, you could just plug your USB fan into your monitor. A fellow engineer and I discovered that most monitors power-down the USB ports when entering power-save mode (with Dell, HP, and Viewsonic, this is whenever the screen blanks due to inactivity; are you using DPMS and/or greensaver?). Walking away from the PC will cause the fan to [eventually] turn off, while waggling the mouse brings it back to life. Devin, sorry, my monitor is too old to have USB ports on it...if it did that would be even a better solution. Thanks for the help everyone! -- Ron McDowell San Antonio TX ___ 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
trim/discard success story
Today I had reason to try the UFS trim support on the FreeBSD version of the Fusion-IO driver, and I'm pleased to say that it appears to work just fine.. on a 1.3TB flash card.. the numbers of 'sectors' that the drive considers to hold valid data is reduced after the contents of the drive is erased..: After newfs -E: hw.fusion.fio.fio0.data.stats: [...] 861327 [...] After writing a few GB to the filesystem but BEFORErm -r * pu05# sysctl hw.fusion.fio.fio0.data.stats hw.fusion.fio.fio0.data.stats: [...] 3628354 [...] Afterrm -r * pu05# sysctl hw.fusion.fio.fio0.data.stats hw.fusion.fio.fio0.data.stats: [...] 919690 [...] so from 861,327 packets valid to 3,628,354 packets valid, back to 919,690 packets valid. (since bitmaps etc are allocated as needed the growth is expected but will not grow forever). (yeah I know it never actually reached 1% full but it was a test, ok?) for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. ___ 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: Python won't build?
On Mar 31, 2012, at 10:21 PM, John Nielsen wrote: I updated a machine yesterday from 9-STABLE to 10-CURRENT (r233631). Everything went smoothly with the update itself, but I ran in to an issue with Python when rebuilding all of my installed ports. Python won't build; it complains about the definition of LONG_BIT. I had python27 installed but python26 does the same thing. I ran make delete-old and make delete-old-libs, no improvement. I even built a clean chroot environment via make installworld DESTDIR=..., (plus devfs and ports tree). Same problem. So.. is this the result of something in the FreeBSD source? Can anyone else reproduce this? What should I try next? So, no chorus of me toos. How about a works for me? I'm still not sure if this is something peculiar to this machine or not and I haven't fired up a clean virtual machine on different hardware to verify (though I'm not far from that...). Some of my own follow up: I tried rebuilding world with sources from today, 3/9 and 2/28 and got the same result, so if it's a regression on the FreeBSD end it's been there a while (and seemingly not related to the i386/amd64/x86 header cleanup, which led me to pick those revisions). I also tried setting tweaking newvers.sh to say 9.9-CURRENT and rebuilt world with no improvement, so if it's autotools or something else versus two-digit FreeBSD version problem it's something subtle. Looking in to the Python code, this block is what throws the error: /* from python27/work/Python-2.7.2/Include/pyport.h */ #ifndef LONG_BIT #define LONG_BIT (8 * SIZEOF_LONG) #endif #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). #endif It turns out the problem is not the one mentioned in the comment (bogus definition of LONG_BIT), but rather that SIZEOF_LONG is never defined. Comparing with another amd64 system running 9-STABLE, it looks like that ought to be defined during the configure step and end up in work/Python-2.7.2/portbld.shared/pyconfig.h. That is not happening on the maching running -CURRENT--pyconfig.h doesn't get created in the portbld.shared directory. It does exist in portbld.static (and on the well-behaving -STABLE machine the two are identical), so I copied it over. That lets the first stage of the build mostly finish but it fails linking the 'python' binary: cc -c -fno-strict-aliasing -O2 -pipe -march=athlon64 -fno-strict-aliasing -DNDEBUG -O2 -pipe -march=athlon64 -fno-strict-aliasing -I. -IInclude -I./../Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ./../Modules/python.c cc -pthread -Wl,--export-dynamic -o python Modules/python.o -L. -lpython2.7 -lutil -lm ./libpython2.7.so: undefined reference to `_PyImport_Inittab' *** [python] Error code 1 Stop in /opt/scratch/opt/ports/lang/python27/work/Python-2.7.2/portbld.shared. *** [pre-build] Error code 1 So there is something going on besides just the header file not being created. Does anyone have any ideas what it could be? I'm willing to believe this is a Python problem but I'd still like to know what changed on my end to uncover it before pursuing help from the Python folks. cc -c -fno-strict-aliasing -O2 -pipe -march=athlon64 -fno-strict-aliasing -DNDEBUG -O2 -pipe -march=athlon64 -fno-strict-aliasing -I. -IInclude -I./../Include -fPIC -DPy_BUILD_CORE -o Parser/acceler.o ./../Parser/acceler.c ... In file included from ./../Include/Python.h:58, from ./../Include/pgenheaders.h:10, from ./../Parser/acceler.c:13: ./../Include/pyport.h:849:2: error: #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). ... Stop in /opt/scratch/opt/ports/lang/python27/work/Python-2.7.2/portbld.shared. *** [pre-build] Error code 1 Thanks, JN ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on mips/mips
TB --- 2012-04-04 01:23:15 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-04-04 01:23:15 - starting HEAD tinderbox run for mips/mips TB --- 2012-04-04 01:23:15 - cleaning the object tree TB --- 2012-04-04 01:23:58 - cvsupping the source tree TB --- 2012-04-04 01:23:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-04-04 01:24:47 - building world TB --- 2012-04-04 01:24:47 - CROSS_BUILD_TESTING=YES TB --- 2012-04-04 01:24:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-04-04 01:24:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-04-04 01:24:47 - SRCCONF=/dev/null TB --- 2012-04-04 01:24:47 - TARGET=mips TB --- 2012-04-04 01:24:47 - TARGET_ARCH=mips TB --- 2012-04-04 01:24:47 - TZ=UTC TB --- 2012-04-04 01:24:47 - __MAKE_CONF=/dev/null TB --- 2012-04-04 01:24:47 - cd /src TB --- 2012-04-04 01:24:47 - /usr/bin/make -B buildworld World build started on Wed Apr 4 01:24:48 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 [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 kfd.8.gz === kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mips/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mips/src/tmp/usr/bin/ld: /obj/mips.mips/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mips/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-04-04 02:14:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-04-04 02:14:04 - ERROR: failed to build world TB --- 2012-04-04 02:14:04 - 2084.10 user 441.20 system 3049.15 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
On Tue, 3 Apr 2012, Julian Elischer wrote: for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. The major unknown issue with trim is how well the drives schedules/defers the trim operation so that it does not interfer with other I/Os. Also, it would be really bad if the drive applied trim after the block had been re-allocated for a write. It would also be really bad if the drive loses unrelated data if there is a power fail during trim. If writes get blocked by a pending trim, then trim would not help very much. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.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
compiling glib20 failed
hi gurus: i got problem with compiling glib20: === glib-2.28.8_4 depends on file: /usr/local/bin/perl5.10.1 - found /libexec/ld-elf.so.1: /usr/local/lib/liblzma.so.5: version XZ_5.0 required by /usr/bin/xz not defined === Missing license file for LGPL20 in /usr/ports/devel/glib20/work/glib-2.28.8/COPYING *** Error code 1 Stop in /usr/ports/devel/glib20. *** Error code 1 basically i was trying to install tshark on freebsd 8.1 but it told me i need to upgrade glib but i got into this mess. thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
My experience at Alacritech was that Trim was so expensive timewise that it could not be used in that application space. Instead, SECURITY ERASE on the relatively infrequent reboots cleaned things up pretty well. This should be with a grain of salt because I expect trim timings are not only vendor dependent but firmware release dependent. ___ 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: compiling glib20 failed
Hi, when did you update your ports tree? It works here on 8.3 with a ports tree from last week. Erich On Wednesday 04 April 2012 10:02:51 gahn wrote: hi gurus: i got problem with compiling glib20: === glib-2.28.8_4 depends on file: /usr/local/bin/perl5.10.1 - found /libexec/ld-elf.so.1: /usr/local/lib/liblzma.so.5: version XZ_5.0 required by /usr/bin/xz not defined === Missing license file for LGPL20 in /usr/ports/devel/glib20/work/glib-2.28.8/COPYING *** Error code 1 Stop in /usr/ports/devel/glib20. *** Error code 1 basically i was trying to install tshark on freebsd 8.1 but it told me i need to upgrade glib but i got into this mess. thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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: trim/discard success story
On 4/3/12 6:50 PM, Bob Friesenhahn wrote: On Tue, 3 Apr 2012, Julian Elischer wrote: for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. The major unknown issue with trim is how well the drives schedules/defers the trim operation so that it does not interfer with other I/Os. Also, it would be really bad if the drive applied trim after the block had been re-allocated for a write. It would also be really bad if the drive loses unrelated data if there is a power fail during trim. If writes get blocked by a pending trim, then trim would not help very much. well since I work for the drive manufacturer I can say that in this case it really is worth it. :-) But I'm glad that it is getting out there that trim aint as easy as it seems. The hard part about trim is making it so that if you get a power failure, the trimmed data says trimmed. In some cases, it is not important. For example when a filesystem is used, trimmed data will never be accessed again without first writing new data to that address. but for any application that assumes that trimmed data will return zero's it is a critical feature. Bob ___ 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: trim/discard success story
On 4/3/12 8:51 PM, Matthew Jacob wrote: My experience at Alacritech was that Trim was so expensive timewise that it could not be used in that application space. Instead, SECURITY ERASE on the relatively infrequent reboots cleaned things up pretty well. This should be with a grain of salt because I expect trim timings are not only vendor dependent but firmware release dependent. very true. In this case, on this drive, on this version.. it is fast. ___ 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