[head tinderbox] failure on mips/mips

2012-04-03 Thread FreeBSD Tinderbox
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

2012-04-03 Thread 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:

-
#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

2012-04-03 Thread Andre Oppermann

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

2012-04-03 Thread Matt Thyer
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

2012-04-03 Thread John Baldwin
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

2012-04-03 Thread Eric van Gyzen

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

2012-04-03 Thread Matt Thyer
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

2012-04-03 Thread David Wolfskill
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

2012-04-03 Thread Gary Palmer
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

2012-04-03 Thread Steve Kargl
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

2012-04-03 Thread Bruce Evans

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

2012-04-03 Thread Thomas Mueller
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?

2012-04-03 Thread David Wolfskill
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?

2012-04-03 Thread jb
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

2012-04-03 Thread FreeBSD Tinderbox
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

2012-04-03 Thread Matthias Andree
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

2012-04-03 Thread Alexandre MARTINS
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

2012-04-03 Thread Ron McDowell
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

2012-04-03 Thread Ian Lepore
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

2012-04-03 Thread Devin Teske

 -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

2012-04-03 Thread Poul-Henning Kamp
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

2012-04-03 Thread Ron McDowell

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

2012-04-03 Thread Julian Elischer
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?

2012-04-03 Thread John Nielsen
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

2012-04-03 Thread FreeBSD Tinderbox
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

2012-04-03 Thread Bob Friesenhahn

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

2012-04-03 Thread gahn
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

2012-04-03 Thread Matthew Jacob
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

2012-04-03 Thread Erich Dollansky
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

2012-04-03 Thread Julian Elischer

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

2012-04-03 Thread Julian Elischer

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