Re: hacking - aio_sendfile()
On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: Hiya, I've started writing an aio_sendfile() syscall. http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff Yes, the diff is against -HEAD and not stable/9. It's totally horrible, hackish and likely bad. I've only done some very, very basic testing to ensure it actually works; i haven't at all stress tested it out yet. It's also very naive - I'm not at all doing any checks to see whether I can short-cut to do the aio there and then; I'm always queuing the sendfile() op through the worker threads. That's likely stupid and inefficient in a lot of cases, but it at least gets the syscall up and working. Yes, it is naive, but for different reason. The kern_sendfile() is synchronous function, it only completes after the other end of the network communication allows it. This means that calling kern_sendfile() from the aio thread blocks the thread indefinitely by unbounded sleep. Your implementation easily causes exhaustion of the aio thread pool, blocking the whole aio subsystem. It is known that our aio does not work for sockets for the same reason. I object against adding more code with the same defect. Proper route seems to rewrite aio for sockets using the upcalls. The same should be done for sendfile, if sendfile is given aio flavor. I'd like some feedback and possibly some help in stress testing it to make sure it's functioning well. Thanks, -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org pgpGk5VC33yBq.pgp Description: PGP signature
Re: [head tinderbox] failure on sparc64/sparc64
On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: I don't get why this is dying. any ideas? Maybe because sparc64's ucontext.h is getting pulled in, and it has this: #define mc_flagsmc_global[0] Regards, Navdeep adrian On 10 July 2013 21:18, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2013-07-11 02:56:02 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 02:56:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 02:56:02 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-11 02:56:02 - cleaning the object tree TB --- 2013-07-11 02:56:56 - /usr/local/bin/svn stat /src TB --- 2013-07-11 02:57:06 - At svn revision 253161 TB --- 2013-07-11 02:57:07 - building world TB --- 2013-07-11 02:57:07 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 02:57:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 02:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 02:57:07 - SRCCONF=/dev/null TB --- 2013-07-11 02:57:07 - TARGET=sparc64 TB --- 2013-07-11 02:57:07 - TARGET_ARCH=sparc64 TB --- 2013-07-11 02:57:07 - TZ=UTC TB --- 2013-07-11 02:57:07 - __MAKE_CONF=/dev/null TB --- 2013-07-11 02:57:07 - cd /src TB --- 2013-07-11 02:57:07 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Jul 11 02:57:14 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jul 11 04:07:01 UTC 2013 TB --- 2013-07-11 04:07:01 - generating LINT kernel config TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf TB --- 2013-07-11 04:07:01 - /usr/bin/make -B LINT TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf TB --- 2013-07-11 04:07:01 - /usr/sbin/config -m LINT TB --- 2013-07-11 04:07:01 - building LINT kernel TB --- 2013-07-11 04:07:01 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 04:07:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 04:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 04:07:01 - SRCCONF=/dev/null TB --- 2013-07-11 04:07:01 - TARGET=sparc64 TB --- 2013-07-11 04:07:01 - TARGET_ARCH=sparc64 TB --- 2013-07-11 04:07:01 - TZ=UTC TB --- 2013-07-11 04:07:01 - __MAKE_CONF=/dev/null TB --- 2013-07-11 04:07:01 - cd /src TB --- 2013-07-11 04:07:01 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99
Re: [head tinderbox] failure on sparc64/sparc64
On 11 July 2013 00:05, Navdeep Parhar npar...@gmail.com wrote: On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: I don't get why this is dying. any ideas? Maybe because sparc64's ucontext.h is getting pulled in, and it has this: #define mc_flagsmc_global[0] Ugh, we should fix this. When did this happen? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on sparc64/sparc64
On Thu, Jul 11, 2013 at 12:07:33AM -0700, Adrian Chadd wrote: On 11 July 2013 00:05, Navdeep Parhar npar...@gmail.com wrote: On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: I don't get why this is dying. any ideas? Maybe because sparc64's ucontext.h is getting pulled in, and it has this: #define mc_flagsmc_global[0] Ugh, we should fix this. When did this happen? You tell me. I was just running cscope in my spare time ;-) ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2013-07-10 17:52, Kevin Oberman pisze: On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder f...@feld.me wrote: On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm trash...@odo.in-berlin.de wrote: Will that patch make it into 9.2? If I am not mistaken, that patch isn't in stable yet. I would also like to see this patch hit 9.x sooner than later. It's so painful when someone forgets to fix the alias numbering on servers with many, many IPv4 and IPv6 addresses... Please, please, please, please, ...! Freeze is only two days away, so time for 9.2 is almost over and I can see no good reason NOT to get this done. +1 to that, please commit it. -- best regards, Lukasz Wasikowski ___ 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: Improved SYN Cookies: Looking for testers
On 10.07.2013 15:18, Fabian Keil wrote: Andre Oppermann an...@freebsd.org wrote: We have a SYN cookie implementation for quite some time now but it has some limitations with current realities for window scaling and SACK encoding the in the few available bits. This patch updates and improves SYN cookies mainly by: a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN (initial sequence number) without the use of timestamp bits. b) switching to the very fast and cryptographically strong SipHash-2-4 hash MAC algorithm to protect the SYN cookie against forgery. The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). Please find it here for testing: http://people.freebsd.org/~andre/syncookie-20130708.diff I've been using the patch for a couple of days and didn't notice any issues so far. Privoxy's regression tests continue to work as expected as well. Thanks for testing and reporting back. Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1 as well to bypass the syn cache entirely? It will give a bit of debug log output which is it telling you mostly about rounding to the next nearest index value. You can send the output privately to me to spot unexpected outliers, if any. BTW, I think kern/173309 could be closed. OK. -- 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: hacking - aio_sendfile()
Hiya, I'm more interested in the API than the implementation at the moment. Yes, you're right - it should eventually be driven using disk io completion upcalls which triggers the push of data into the socket buffer. I totally agree. I'm hacking up some libevent-ish looking thing that uses kqueue and wraps aio, read, write, and other event types into something I can easily shoehorn this stuff into. I'll then throughly test it (and other options) out. You're right, it's likely going to end up with a whole lot of aio threads sitting there waiting for disk IO to complete - and at that point, I'll start hacking at sendfile() to split it into two halves and have it driven by a completion call from g_up or wherever, triggering the socket write side of things. There are some other questions too - like whether the IO completion should just queue socket IO (and have it potentially block in the TCP code) or whether it should funnel completions into a per-CPU aio completion thread which does the socket write bit. That way disk IO completion isn't going to be blocked by longer-held locks in the networking stack. Thanks, -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Hi Bruce,
You're joining in this discussion starting in the middle, so you probably
missed the earlier explanation.
On 11 Jul 2013, at 05:21, Bruce Evans b...@optusnet.com.au wrote:
I don't see how any conforming program can access the isnan() function
directly. It is just as protected as __isnan() would be. (isnan)()
gives the function (the function prototype uses this), but conforming
programs can't do that since the function might not exist. Maybe some
non-conforming program like autoconfig reads math.h or libm.a and
creates a bug for C++.
The cmath header defines a template function isnan that invokes the isnan
macro, but then undefines the isnan macro. This causes a problem because when
someone does something along the lines of using namespace std then they end up
with two functions called isnan and the compiler gets to pick the one to use.
Unfortunately, std::isnan() returns a bool, whereas isnan() returns an int.
The C++ headers are not required to be conforming C code, because they are not
C, and our math.h causes namespace pollution in C++ when included from cmath.
The FreeBSD isnan() implementation would be broken by removing the
isnan() function from libm.a or ifdefing it in math.h. Changing the
function to __isnan() would cause compatibility problems. The function
is intentionally named isnan() to reduce compatibility problems.
On OS X this is avoided because their isnan() macro expands to call one of the
__-prefixed inline functions (which adopt your suggestion of being implemented
as x != x, for all types). I am not sure that this is required for standards
conformance, but it is certainly cleaner. Your statement that having the
function not called isnan() causes compatibility problems is demonstrably
false, as neither OS X nor glibc has a function called isnan() and, unlike us,
they do not experience problems with this macro.
It would also be nice to implement these macros using _Generic when compiling
in C11 mode, as it will allow the compiler to produce more helpful warning
messages. I would propose this implementation:
#if __has_builtin(__builtin_isnan)
#define isnan(x) __builtin_isnan(x)
#else
static __inline int
__isnanf(float __x)
{
return (__x != __x);
}
static __inline int
__isnand(double __x)
{
return (__x != __x);
}
static __inline int
__isnanl(long double __x)
{
return (__x != __x);
}
#if __STDC_VERSION__ = 201112L
#define isnan(x) _Generic((x), \
float: __isnanf(x),\
double: __isnand(x), \
long double: __isnanl(x))
#else
#define isnan(x)\
((sizeof (x) == sizeof (float)) ? __isnanf(x) \
: (sizeof (x) == sizeof (double)) ? __isnand(x)\
: __isnanl(x))
#endif
#endif
For a trivial example of why this is an improvement in terms of error
reporting, consider this trivial piece of code:
int is(int x)
{
return isnan(x);
}
With our current implementation, this compiles and links without any warnings,
although it will have somewhat interesting results at run time. With the
__builtin_isnan() version, clang reports this error:
isnan.c:35:15: error: floating point classification requires argument of
floating point type (passed in 'int')
return isnan(x);
^
(and then some more about the macro expansion)
With the C11 version, it reports this error:
isnan.c:35:15: error: controlling expression type 'int' not compatible with any
generic association type
return isnan(x);
^
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: hacking - aio_sendfile()
On Thu, Jul 11, 2013 at 01:37:19AM -0700, Adrian Chadd wrote: Hiya, I'm more interested in the API than the implementation at the moment. Yes, you're right - it should eventually be driven using disk io completion upcalls which triggers the push of data into the socket buffer. I totally agree. I'm hacking up some libevent-ish looking thing that uses kqueue and wraps aio, read, write, and other event types into something I can easily shoehorn this stuff into. I'll then throughly test it (and other options) out. You're right, it's likely going to end up with a whole lot of aio threads sitting there waiting for disk IO to complete - and at that point, I'll start hacking at sendfile() to split it into two halves and have it driven by a completion call from g_up or wherever, triggering the socket write side of things. There are some other questions too - like whether the IO completion should just queue socket IO (and have it potentially block in the TCP code) or whether it should funnel completions into a per-CPU aio completion thread which does the socket write bit. That way disk IO completion isn't going to be blocked by longer-held locks in the networking stack. No, it is not disk I/O which is problematic there. It is socket I/O e.g. wait for the socket buffers lomark in the kern_sendfile() which causes unbounded sleep. Look for the sbwait() call, both in the kern_sendfile() itself, and in the pru_send methods of the protocols, e.g. in sosend_generic(). The wait scope controlled by the other side of connection and allow it to completely block the aio subsystem. Disk I/O is supposed to finish in the finite time. pgpVyo_YYHh1i.pgp Description: PGP signature
Re: hacking - aio_sendfile()
On 11 July 2013 02:36, Konstantin Belousov kostik...@gmail.com wrote: No, it is not disk I/O which is problematic there. It is socket I/O e.g. wait for the socket buffers lomark in the kern_sendfile() which causes unbounded sleep. Look for the sbwait() call, both in the kern_sendfile() itself, and in the pru_send methods of the protocols, e.g. in sosend_generic(). The wait scope controlled by the other side of connection and allow it to completely block the aio subsystem. Disk I/O is supposed to finish in the finite time. Even if the destination socket is marked as NONBLOCK? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 2013-07-11 06:21, Bruce Evans wrote:
On Wed, 10 Jul 2013, Garrett Wollman wrote:
On Wed, 10 Jul 2013 22:12:59 +0200, Tijl Coosemans t...@freebsd.org said:
I think isnan(double) and isinf(double) in math.h should only be
visible if (_BSD_VISIBLE || _XSI_VISIBLE) __ISO_C_VISIBLE 1999.
For C99 and higher there should only be the isnan/isinf macros.
I believe you are correct. POSIX.1-2008 (which is aligned with C99)
consistently calls isnan() a macro, and gives a pseudo-prototype of
int isnan(real-floating x);
Almost any macro may be implemented as a function, if no conforming
program can tell the difference. It is impossible for technical reasons
to implement isnan() as a macro (except on weird implementations where
all real-floating types are physically the same). In the FreeBSD
implementation, isnan() is a macro, but it is also a function, and
the macro expands to the function in double precision:
% #defineisnan(x)\
% ((sizeof (x) == sizeof (float)) ? __isnanf(x)\
% : (sizeof (x) == sizeof (double)) ? isnan(x)\
% : __isnanl(x))
The C99 standard says isnan is a macro. I would say that only means
defined(isnan) is true. Whether that macro then expands to function
calls or not is not important.
I don't see how any conforming program can access the isnan() function
directly. It is just as protected as __isnan() would be. (isnan)()
gives the function (the function prototype uses this), but conforming
programs can't do that since the function might not exist.
I don't think the standard allows a function to be declared with the same
name as a standard macro (it does allow the reverse: define a macro with
the same name as a standard function). I believe the following code is
C99 conforming but it currently does not compile with our math.h:
--
#include math.h
int (isnan)(int a, int b, int c) {
return (a + b + c);
}
--
signature.asc
Description: OpenPGP digital signature
Re: hacking - aio_sendfile()
On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote: On 11 July 2013 02:36, Konstantin Belousov kostik...@gmail.com wrote: No, it is not disk I/O which is problematic there. It is socket I/O e.g. wait for the socket buffers lomark in the kern_sendfile() which causes unbounded sleep. Look for the sbwait() call, both in the kern_sendfile() itself, and in the pru_send methods of the protocols, e.g. in sosend_generic(). The wait scope controlled by the other side of connection and allow it to completely block the aio subsystem. Disk I/O is supposed to finish in the finite time. Even if the destination socket is marked as NONBLOCK? You mean, would a sleep for the socket buffer space cause aio thread block is the socket is put in nonblocking mode ? Or something else ? No, it would not block the thread. But I cannot consider the aio_sendfile(2) implementation useful if it requires non-blocking socket. Also, what about other thread changing the socket to blocking mode while sendfile is in flight ? pgpJdSazseJ69.pgp Description: PGP signature
Re: hacking - aio_sendfile()
Adrian, On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: A I've started writing an aio_sendfile() syscall. A A http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff A A Yes, the diff is against -HEAD and not stable/9. A A It's totally horrible, hackish and likely bad. I've only done some A very, very basic testing to ensure it actually works; i haven't at all A stress tested it out yet. It's also very naive - I'm not at all doing A any checks to see whether I can short-cut to do the aio there and A then; I'm always queuing the sendfile() op through the worker threads. A That's likely stupid and inefficient in a lot of cases, but it at A least gets the syscall up and working. A A I'd like some feedback and possibly some help in stress testing it to A make sure it's functioning well. Apart from problem pointed out by Kostik, there is a race between aio thread starting with aio_process_sendfile() and file descriptor (or socket descriptor) going away. Thus, kern_sendfile() needs to be split into two parts: kern_sendfile_pre() and kern_sendfile() that should contain only the sending cycle. The kern_sendfile_pre() should contain: fgetvp_read(uap-fd, vp) vm_object_reference_locked(vp-v_object) Referencing the socket is probably also required. Current synchronous code doesn't do it. The do_sendfile() function should call kern_sendfile_pre() and then kern_sendfile(). The aio code should perform kern_sendfile_pre() in the new syscall itself in context of calling process, and kern_sendfile() in async context. P.S. Some time ago I have started hacking on the above. -- Totus tuus, Glebius. ___ 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: Filesystem wedges caused by r251446
John Baldwin wrote: On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: Konstantin Belousov wrote: Care to provide any useful information ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug-deadlocks.html Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? Use kgdb. 'proc pid', then 'bt'. So, I setup a remote kbgd session, but I still can't figure out how to get at the information we need. (kgdb) proc 5176 only supported for core file target In the mean time, I'll just force it to make a core dump from ddb. However, I can't reacreate the issue while the mirror (gmirror) is rebuilding, so we'll have to wait for that to finish. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on sparc64/sparc64
I think it´s in your kernel config file LINT. In your log we can read this Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013 I had the same issue with current yesterday. 2013/7/11 Navdeep Parhar npar...@gmail.com On Thu, Jul 11, 2013 at 12:07:33AM -0700, Adrian Chadd wrote: On 11 July 2013 00:05, Navdeep Parhar npar...@gmail.com wrote: On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: I don't get why this is dying. any ideas? Maybe because sparc64's ucontext.h is getting pulled in, and it has this: #define mc_flagsmc_global[0] Ugh, we should fix this. When did this happen? You tell me. I was just running cscope in my spare time ;-) ___ freebsd-spar...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 To unsubscribe, send any mail to freebsd-sparc64-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Thu, 11 Jul 2013, David Chisnall wrote: You're joining in this discussion starting in the middle, so you probably missed the earlier explanation. I was mainly addressing a C99 point. I know little about C++ or C11. On 11 Jul 2013, at 05:21, Bruce Evans b...@optusnet.com.au wrote: I don't see how any conforming program can access the isnan() function directly. It is just as protected as __isnan() would be. (isnan)() gives the function (the function prototype uses this), but conforming programs can't do that since the function might not exist. Maybe some non-conforming program like autoconfig reads math.h or libm.a and creates a bug for C++. The cmath header defines a template function isnan that invokes the isnan macro, but then undefines the isnan macro. This causes a problem because when someone does something along the lines of using namespace std then they end up with two functions called isnan and the compiler gets to pick the one to use. Unfortunately, std::isnan() returns a bool, whereas isnan() returns an int. The C++ headers are not required to be conforming C code, because they are not C, and our math.h causes namespace pollution in C++ when included from cmath. math.h is also not required to be conforming C code, let alone C++ code, so there is only a practical requirement that it works when included in the C++ implementation. The FreeBSD isnan() implementation would be broken by removing the isnan() function from libm.a or ifdefing it in math.h. Changing the function to __isnan() would cause compatibility problems. The function is intentionally named isnan() to reduce compatibility problems. On OS X this is avoided because their isnan() macro expands to call one of the __-prefixed inline functions (which adopt your suggestion of being implemented as x != x, for all types). I am not sure that this is required for standards conformance, but it is certainly cleaner. Your statement that having the function not called isnan() causes compatibility problems is demonstrably false, as neither OS X nor glibc has a function called isnan() and, unlike us, they do not experience problems with this macro. The compatibility that I'm talking about is with old versions of FreeBSD. isnan() is still in libc as a function since that was part of the FreeBSD ABI and too many things depended on getting it from there. It was recently removed from libc.so, but is still in libm.a. This causes some implementation problems in libm that are still not completely solved. I keep having to edit msun/src/s_isnan.c the msun sources are more portable. Mostly I need to kill the isnan() there so that it doesn't get in the way of the one in libc. This mostly works even if there is none in libc, since the builtins result in neither being used. isnanf() is more of a problem, since it is mapped to __isnanf() and there is no builtin for __isnanf(). The old functions have actually been removed from libc.a too. They only in libc_pic.a. libc.a still has isnan.o, but that is bogus since isnan.o is now empty. It would also be nice to implement these macros using _Generic when compiling in C11 mode, as it will allow the compiler to produce more helpful warning messages. I would propose this implementation: #if __has_builtin(__builtin_isnan) This won't work for me, since I develop and test msun with old compilers that don't support __has_builtin(). Much the same set of compilers also don't have enough FP builtins. It also doesn't even work. clang has squillions of builtins that aren't really builtines so they reduce to libcalls. gcc has fewer builtins, but still many that reduce to libcalls. An example is fma(). __has_builtin(__builtin_fma) is true for clang on amd64 (freefall), but at least freefalls's CPU doesn't support fma in hardware, so the builtin can't really work, and in fact it doesn't -- it reduces to a libcall. This might change if the hardware supports fma, but then __has_builtin(__builtin_fma) would be even more useless for telling if fma is worth using. C99 has macros FP_FAST_FMA[FL] whose implementation makes them almost equally useless. For example, ia64 has fma in hardware and the implementation defines all of FP_FAST_FMA[FL] for ia64. But fma is implemented as an extern function, partly because there is no way to tell if __builtin_fma is any good (but IIRC, __builtin_fma is no good on ia64 either, since it reduces to the same extern function). The extern function is slow (something like 20 cycles instead of 1 for the fma operation). But if you ignore the existence of the C99 fma API and just write expressions of the form (a*x + b), then gcc on ia64 will automatically use the hardware fma, although this is technically wrong in some fenv environments. For gcc-4.2.1, __has_builtin(__builtin_fma) is a syntax error. I test with gcc-3.x. It is also missing __builtin_isnan(). The msun implementation knows that isnan() and other classification macros are
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 11 Jul 2013, at 13:11, Bruce Evans b...@optusnet.com.au wrote:
math.h is also not required to be conforming C code, let alone C++ code,
so there is only a practical requirement that it works when included
in the C++ implementation.
Working with the C++ implementation is the problem that we are trying to solve.
The compatibility that I'm talking about is with old versions of FreeBSD.
isnan() is still in libc as a function since that was part of the FreeBSD
ABI and too many things depended on getting it from there. It was recently
removed from libc.so, but is still in libm.a. This causes some
implementation problems in libm that are still not completely solved. I
keep having to edit msun/src/s_isnan.c the msun sources are more portable.
Mostly I need to kill the isnan() there so that it doesn't get in the
way of the one in libc. This mostly works even if there is none in libc,
since the builtins result in neither being used. isnanf() is more of a
problem, since it is mapped to __isnanf() and there is no builtin for
__isnanf(). The old functions have actually been removed from libc.a
too. They only in libc_pic.a. libc.a still has isnan.o, but that is bogus
since isnan.o is now empty.
I don't see a problem with changing the name of the function in the header and
leaving the old symbol in libm for legacy code.
It would also be nice to implement these macros using _Generic when
compiling in C11 mode, as it will allow the compiler to produce more helpful
warning messages. I would propose this implementation:
#if __has_builtin(__builtin_isnan)
This won't work for me, since I develop and test msun with old compilers
that don't support __has_builtin(). Much the same set of compilers also
don't have enough FP builtins.
Please look in cdefs.h, which defines __has_builtin(x) to 0 if we the compiler
does not support it. It is therefore safe to use __has_builtin() in any
FreeBSD header.
It also doesn't even work. clang has squillions of builtins that
aren't really builtines so they reduce to libcalls.
Which, again, is not a problem for code outside of libm. If libm needs
different definitions of these macros then that's fine, but they should be
private to libm, not installed as public headers.
The msun implementation knows that isnan() and other classification
macros are too slow to actually use, and rarely uses them.
Which makes any concerns that only apply to msun internals irrelevant from the
perspective of discussing what goes into this header.
#define isnan(x) __builtin_isnan(x)
#else
static __inline int
__isnanf(float __x)
{
return (__x != __x);
}
Here we can do better in most cases by hard-coding this without the ifdef.
They will generate the same code. Clang expands the builtin in the LLVM IR to
a fcmp uno, so will generate the correct code even when doing fast math
optimisations.
static __inline int
__isnand(double __x)
{
return (__x != __x);
}
__isnand() is a strange name, and doesn't match compiler conventions for
builtins. Compilers use __builtin_isnan() and map this to the libcall
__isnan().
That's fine.
static __inline int
__isnanl(long double __x)
{
return (__x != __x);
}
#if __STDC_VERSION__ = 201112L
#define isnan(x) _Generic((x), \
float: __isnanf(x),\
double: __isnand(x), \
long double: __isnanl(x))
Does _Generic() have no side effects, like sizeof()?
Yes.
#else
#define isnan(x)\
((sizeof (x) == sizeof (float)) ? __isnanf(x) \
: (sizeof (x) == sizeof (double)) ? __isnand(x)\
: __isnanl(x))
#endif
#endif
Both cases need to use __builtin_isnan[fl]() and depend on compiler
magic to have any chance of avoiding side effects from loads and
parameter passing.
Generic stuff doesn't seem to work right for either isnan() or
__builtin_isnan(), though it could for at least the latter. According
to a quick grep of strings $(which clang), __builtin_classify() is
generic but __builtin_isnan*() isn't (the former has no type suffixes
but the latter does, and testing shows that the latter doesn't work
without the suffices).
I'm not sure what you were testing:
$ cat isnan2.c
int test(float f, double d, long double l)
{
return __builtin_isnan(f) |
__builtin_isnan(d) |
__builtin_isnan(l);
}
$ clang isnan2.c -S -emit-llvm -o - -O1
...
%cmp = fcmp uno float %f, 0.00e+00
%cmp1 = fcmp uno double %d, 0.00e+00
%or4 = or i1 %cmp, %cmp1
%cmp2 = fcmp uno x86_fp80 %l, 0xK
...
As you can see, it parses them as generics and generates different IR for each.
I don't believe that there's a way that these would be translated back into
libcalls in the back end.
For a trivial example of why this is an improvement in terms of error
reporting, consider this trivial piece of code:
Re: Filesystem wedges caused by r251446
On Thursday, July 11, 2013 6:54:35 am Ian FREISLICH wrote: John Baldwin wrote: On Thursday, July 04, 2013 5:03:29 am Ian FREISLICH wrote: Konstantin Belousov wrote: Care to provide any useful information ? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug-deadlocks.html Well, the system doesn't deadlock it's perfectly useable so long as you don't touch the file that's wedged. A lot of the time the userland process is unkillable, but often it is killable. How do I get from from the PID to where the FS is stuck in the kernel? Use kgdb. 'proc pid', then 'bt'. So, I setup a remote kbgd session, but I still can't figure out how to get at the information we need. (kgdb) proc 5176 only supported for core file target In the mean time, I'll just force it to make a core dump from ddb. However, I can't reacreate the issue while the mirror (gmirror) is rebuilding, so we'll have to wait for that to finish. Sorrry, just run 'sudo kgdb' on the box itself. You can inspect the running kernel without having to stop it. -- 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: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Thu, 11 Jul 2013, Tijl Coosemans wrote:
On 2013-07-11 06:21, Bruce Evans wrote:
On Wed, 10 Jul 2013, Garrett Wollman wrote:
On Wed, 10 Jul 2013 22:12:59 +0200, Tijl Coosemans t...@freebsd.org said:
I think isnan(double) and isinf(double) in math.h should only be
visible if (_BSD_VISIBLE || _XSI_VISIBLE) __ISO_C_VISIBLE 1999.
For C99 and higher there should only be the isnan/isinf macros.
I believe you are correct. POSIX.1-2008 (which is aligned with C99)
consistently calls isnan() a macro, and gives a pseudo-prototype of
int isnan(real-floating x);
Almost any macro may be implemented as a function, if no conforming
program can tell the difference. It is impossible for technical reasons
to implement isnan() as a macro (except on weird implementations where
all real-floating types are physically the same). In the FreeBSD
implementation, isnan() is a macro, but it is also a function, and
the macro expands to the function in double precision:
% #defineisnan(x)\
% ((sizeof (x) == sizeof (float)) ? __isnanf(x)\
% : (sizeof (x) == sizeof (double)) ? isnan(x)\
% : __isnanl(x))
The C99 standard says isnan is a macro. I would say that only means
defined(isnan) is true. Whether that macro then expands to function
calls or not is not important.
I think it means only that defined(isnan) is true. isnan() can still be
a function (declared or just in the compile-time namespace somewhere,
or in a library object). It is reserved in the compile-time namespace,
and the standard doesn't cover library objects, so conforming applications
can't reference either except via the isnan() macro (if that has its
strange historical implementation).
I don't see how any conforming program can access the isnan() function
directly. It is just as protected as __isnan() would be. (isnan)()
gives the function (the function prototype uses this), but conforming
programs can't do that since the function might not exist.
I don't think the standard allows a function to be declared with the same
name as a standard macro (it does allow the reverse: define a macro with
the same name as a standard function). I believe the following code is
C99 conforming but it currently does not compile with our math.h:
--
#include math.h
int (isnan)(int a, int b, int c) {
return (a + b + c);
}
--
I think isnan is just reserved, so you can't redefine it an any way. I
think the reverse is even less allowed. Almost any standard function may
be implemented as a macro, and then any macro definition of it would
conflict with the previous macro even more than with a previous prototype.
E.g.:
/* Header. */
void exit(int);
#define exit(x) __exit(x)
/* Application. */
#undef exit /* non-conforming */
#define exit(x) my_exit(x) /* conflicts without the #undef */
Now suppose the header doesn't define exit().
#define exit(x) my_exit(x)
This hides the protoype but doesn't automatically cause problems, especially
if exit() is not used after this point. But this is still non-conforming,
since exit() is reserved.
Here are some relevant parts of C99 (n869.txt):
%%%
-- Each identifier with file scope listed in any of the
following subclauses (including the future library
directions) is reserved for use as macro and as an
identifier with file scope in the same name space if
any of its associated headers is included.
[#2] No other identifiers are reserved. If the program
declares or defines an identifier in a context in which it
is reserved (other than as allowed by 7.1.4), or defines a
reserved identifier as a macro name, the behavior is
undefined.
[#3] If the program removes (with #undef) any macro
definition of an identifier in the first group listed above,
the behavior is undefined.
%%%
Without any include of a header that is specified to declare exit(),
file scope things are permitted for it, including defining it and
making it a static function, but not making it an extern function.
isnan is reserved for use as a macro and as an identifier with file
scope by the first clause above. Thus (isnan) cannot even be defined
as a static function. But (isnan) is not reserved in inner scopes.
I thought that declarations like int (isnan); are impossible since
they look like syntax errors, but this syntax seems to be allowed an
actually work with gcc-3.3.3 and TenDRA-5.0.0. So you can have
variables with silly names like (isnan) and (getchar) :-). However,
(NULL) for a variable name doesn't work, and (isnan) is a syntax error
for struct member names. The compilers may be correct in allowing
(isnan) but not (NULL) for variables. isnan happens to be function-like,
so the parentheses are special for (isnan), but the parentheses are not
special for
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 11 Jul 2013, at 13:11, Bruce Evans b...@optusnet.com.au wrote: The error message for the __builtin_isnan() version is slightly better up to where it says more. The less-unportable macro can do more classification and detect problems at compile time using __typeof(). The attached patch fixes the related test cases in the libc++ test suite. Please review. This does not use __builtin_isnan(), but it does: - Stop exposing isnan and isinf in the header. We already have __isinf in libc, so this is used instead. - Call the static functions for isnan __inline__isnan*() so that they don't conflict with the ones in libm. - Add an __fp_type_select() macro that uses either __Generic(), __builtin_choose_expr() / __builtin_choose_expr(), or sizeof() comparisons, depending on what the compiler supports. - Refactor all of the type-generic macros to use __fp_type_select(). David isnan.diff Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: hacking - aio_sendfile()
I reference the source/dest FDs in the queue method. Is that not good enough? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: hacking - aio_sendfile()
On Thu, Jul 11, 2013 at 07:45:19AM -0700, Adrian Chadd wrote: A I reference the source/dest FDs in the queue method. Is that not good enough? I see. Should probably work, but needs testing. -- Totus tuus, Glebius. ___ 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: hacking - aio_sendfile()
On 11 July 2013 07:51, Gleb Smirnoff gleb...@freebsd.org wrote: On Thu, Jul 11, 2013 at 07:45:19AM -0700, Adrian Chadd wrote: A I reference the source/dest FDs in the queue method. Is that not good enough? I see. Should probably work, but needs testing. It's terrible - I'd think I should pass the file ref's into kern_sendfile() so I'm sure that the process hasn't close/dup'ed an FD in its place in the meantime. Is that better? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Thu, 11 Jul 2013, David Chisnall wrote:
On 11 Jul 2013, at 13:11, Bruce Evans b...@optusnet.com.au wrote:
math.h is also not required to be conforming C code, let alone C++ code,
so there is only a practical requirement that it works when included
in the C++ implementation.
Working with the C++ implementation is the problem that we are trying to solve.
The compatibility that I'm talking about is with old versions of FreeBSD.
isnan() is still in libc as a function since that was part of the FreeBSD
ABI and too many things depended on getting it from there. It was recently
...
I don't see a problem with changing the name of the function in the header and
leaving the old symbol in libm for legacy code.
I don't even see why old code needs the symbol. Old code should link to
old compat libraries that still have it.
It would also be nice to implement these macros using _Generic when compiling
in C11 mode, as it will allow the compiler to produce more helpful warning
messages. I would propose this implementation:
#if __has_builtin(__builtin_isnan)
This won't work for me, since I develop and test msun with old compilers
that don't support __has_builtin(). Much the same set of compilers also
don't have enough FP builtins.
Please look in cdefs.h, which defines __has_builtin(x) to 0 if we the compiler
does not support it. It is therefore safe to use __has_builtin() in any
FreeBSD header.
The old compilers run on old systems that don't have that in cdefs.h
(though I sometimes edit it to add compatibility cruft like that). msun
sources are otherwise portable to these systems. Well, not quite. They
are not fully modular and also depend on stuff in libc/include and
libc/${ARCH}. I have to update or edit headers there.
This hack also doesn't work with gcc in -current. gcc has __builtin_isnan
but not __has_builtin(), so __has_builtin(__builtin_isnan) gives the wrong
result 0.
It also doesn't even work. clang has squillions of builtins that
aren't really builtines so they reduce to libcalls.
Which, again, is not a problem for code outside of libm. If libm needs
different definitions of these macros then that's fine, but they should be
private to libm, not installed as public headers.
Yes it is. It means that nothing should use isnan() or FP_FAST_FMA* outside
of libm either, since isnan() is too slow and FP_FAST_FMA* can't be trusted.
Even the implementation can't reliably tell if __builtin_isnan is usuable
or better than alternatives.
The msun implementation knows that isnan() and other classification
macros are too slow to actually use, and rarely uses them.
Which makes any concerns that only apply to msun internals irrelevant from the
perspective of discussing what goes into this header.
No, the efficiency of isnan() is more important for externals, because the
internals already have work-arounds.
#define isnan(x) __builtin_isnan(x)
#else
static __inline int
__isnanf(float __x)
{
return (__x != __x);
}
Here we can do better in most cases by hard-coding this without the ifdef.
They will generate the same code. Clang expands the builtin in the LLVM IR to
a fcmp uno, so will generate the correct code even when doing fast math
optimisations.
On some arches the same, and not affected by -ffast-math. But this
is not necessarily the fastest code, so it is a performance bug if clang
akways generates the same code for the builtin. Bit tests are faster in
some cases, and may be required to prevent exceptions for signaling NaNs.
-ffast-math could reasonably optimize x != x to false. It already assumes
that things like overflow and NaN results can't happen, so why not optimize
further by assuming that NaN inputs can't happen?
Generic stuff doesn't seem to work right for either isnan() or
__builtin_isnan(), though it could for at least the latter. According
to a quick grep of strings $(which clang), __builtin_classify() is
generic but __builtin_isnan*() isn't (the former has no type suffixes
but the latter does, and testing shows that the latter doesn't work
without the suffices).
I'm not sure what you were testing:
Mostly isnan() without including math.h, and gcc. I was confused by
gcc converting floats to doubles.
$ cat isnan2.c
int test(float f, double d, long double l)
{
return __builtin_isnan(f) |
__builtin_isnan(d) |
__builtin_isnan(l);
}
$ clang isnan2.c -S -emit-llvm -o - -O1
...
%cmp = fcmp uno float %f, 0.00e+00
%cmp1 = fcmp uno double %d, 0.00e+00
%or4 = or i1 %cmp, %cmp1
%cmp2 = fcmp uno x86_fp80 %l, 0xK
...
As you can see, it parses them as generics and generates different IR for each.
I don't believe that there's a way that these would be translated back into
libcalls in the back end.
Yes, most cases work right. gcc converts f to double and compares the
result, but that mostly works. It would be just a pessimization except
te conversion gives an
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-07-11 14:27:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 14:27:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 14:27:18 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-11 14:27:18 - cleaning the object tree TB --- 2013-07-11 14:28:24 - /usr/local/bin/svn stat /src TB --- 2013-07-11 14:28:39 - At svn revision 253186 TB --- 2013-07-11 14:28:40 - building world TB --- 2013-07-11 14:28:40 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 14:28:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 14:28:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 14:28:40 - SRCCONF=/dev/null TB --- 2013-07-11 14:28:40 - TARGET=sparc64 TB --- 2013-07-11 14:28:40 - TARGET_ARCH=sparc64 TB --- 2013-07-11 14:28:40 - TZ=UTC TB --- 2013-07-11 14:28:40 - __MAKE_CONF=/dev/null TB --- 2013-07-11 14:28:40 - cd /src TB --- 2013-07-11 14:28:40 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Jul 11 14:28:47 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jul 11 15:39:09 UTC 2013 TB --- 2013-07-11 15:39:09 - generating LINT kernel config TB --- 2013-07-11 15:39:09 - cd /src/sys/sparc64/conf TB --- 2013-07-11 15:39:09 - /usr/bin/make -B LINT TB --- 2013-07-11 15:39:09 - cd /src/sys/sparc64/conf TB --- 2013-07-11 15:39:09 - /usr/sbin/config -m LINT TB --- 2013-07-11 15:39:09 - building LINT kernel TB --- 2013-07-11 15:39:09 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 15:39:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 15:39:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 15:39:09 - SRCCONF=/dev/null TB --- 2013-07-11 15:39:09 - TARGET=sparc64 TB --- 2013-07-11 15:39:09 - TARGET_ARCH=sparc64 TB --- 2013-07-11 15:39:09 - TZ=UTC TB --- 2013-07-11 15:39:09 - __MAKE_CONF=/dev/null TB --- 2013-07-11 15:39:09 - cd /src TB --- 2013-07-11 15:39:09 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jul 11 15:39:09 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float
fix for SVN r253208 breaking buildkernel with gcc
Seems gcc is rather fussy about propagating 'const' and fails to compile /usr/src/sys/crypto/siphash/siphash.c after SVN r253208. I believe the attached patch is correct but please review .. imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fix for SVN r253208 breaking buildkernel with gcc
On 07/11/13 12:07, Michael Butler wrote:
Seems gcc is rather fussy about propagating 'const' and fails to compile
/usr/src/sys/crypto/siphash/siphash.c after SVN r253208.
I believe the attached patch is correct but please review ..
imb
grr .. missing attachment :-(
Index: /usr/src/sys/crypto/siphash/siphash.c
===
--- /usr/src/sys/crypto/siphash/siphash.c (revision 253210)
+++ /usr/src/sys/crypto/siphash/siphash.c (working copy)
@@ -119,7 +119,8 @@
void
SipHash_Update(SIPHASH_CTX *ctx, const void *src, size_t len)
{
- uint64_t m, *p;
+ uint64_t m;
+ const uint64_t *p;
const uint8_t *s;
size_t rem;
@@ -144,13 +145,13 @@
/* Optimze for 64bit aligned/unaligned access. */
if (((uintptr_t)s 0x7) == 0) {
- for (p = (uint64_t *)s; len 0; len--, p++) {
+ for (p = (const uint64_t *)s; len 0; len--, p++) {
m = le64toh(*p);
ctx-v[3] ^= m;
SipRounds(ctx, 0);
ctx-v[0] ^= m;
}
- s = (uint8_t *)p;
+ s = (const uint8_t *)p;
} else {
for (; len 0; len--, s += 8) {
m = le64dec(s);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: fix for SVN r253208 breaking buildkernel with gcc
On 11.07.2013 18:09, Michael Butler wrote:
On 07/11/13 12:07, Michael Butler wrote:
Seems gcc is rather fussy about propagating 'const' and fails to compile
/usr/src/sys/crypto/siphash/siphash.c after SVN r253208.
I believe the attached patch is correct but please review ..
imb
grr .. missing attachment :-(
Thanks, applied your patch in r253214.
--
Andre
Index: /usr/src/sys/crypto/siphash/siphash.c
===
--- /usr/src/sys/crypto/siphash/siphash.c (revision 253210)
+++ /usr/src/sys/crypto/siphash/siphash.c (working copy)
@@ -119,7 +119,8 @@
void
SipHash_Update(SIPHASH_CTX *ctx, const void *src, size_t len)
{
- uint64_t m, *p;
+ uint64_t m;
+ const uint64_t *p;
const uint8_t *s;
size_t rem;
@@ -144,13 +145,13 @@
/* Optimze for 64bit aligned/unaligned access. */
if (((uintptr_t)s 0x7) == 0) {
- for (p = (uint64_t *)s; len 0; len--, p++) {
+ for (p = (const uint64_t *)s; len 0; len--, p++) {
m = le64toh(*p);
ctx-v[3] ^= m;
SipRounds(ctx, 0);
ctx-v[0] ^= m;
}
- s = (uint8_t *)p;
+ s = (const uint8_t *)p;
} else {
for (; len 0; len--, s += 8) {
m = le64dec(s);
___
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: [head tinderbox] failure on sparc64/sparc64
On Thursday, July 11, 2013 3:07:33 am Adrian Chadd wrote: On 11 July 2013 00:05, Navdeep Parhar npar...@gmail.com wrote: On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: I don't get why this is dying. any ideas? Maybe because sparc64's ucontext.h is getting pulled in, and it has this: #define mc_flagsmc_global[0] Ugh, we should fix this. When did this happen? annotate is your friend. It's over 10 years old: Working file: /home/jhb/work/freebsd/svn/head/sys/sparc64/include/ucontext.h r105733 | jake | 2002-10-22 14:03:15 -0400 (Tue, 22 Oct 2002) | 13 lines - Expand struct trapframe to 256 bytes, make all fields fixed width and the same size. Add some fields that previously overlapped with something else or were missing. - Make struct regs and struct mcontext (minus floating point) the same as struct trapframe so converting between them is easy (null). - Add space for saving floating point state to struct mcontext. This requires that it be 64 byte aligned. - Add assertions that none of these structures change size, as they are part of the ABI. - Remove some dead code in sendsig(). - Save and restore %gsr in struct trapframe. Remember to restore %fsr. - Add some comments to exception.S. -- 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: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Thu, 11 Jul 2013, David Chisnall wrote:
On 11 Jul 2013, at 13:11, Bruce Evans b...@optusnet.com.au wrote:
The error message for the __builtin_isnan() version is slightly better up
to where it says more.
The less-unportable macro can do more classification and detect problems
at compile time using __typeof().
The attached patch fixes the related test cases in the libc++ test suite.
Please review.
OK if the ifdefs work and the style bugs are fixed.
This does not use __builtin_isnan(), but it does:
- Stop exposing isnan and isinf in the header. We already have __isinf in
libc, so this is used instead.
- Call the static functions for isnan __inline__isnan*() so that they don't
conflict with the ones in libm.
- Add an __fp_type_select() macro that uses either __Generic(),
__builtin_choose_expr() / __builtin_choose_expr(), or sizeof() comparisons,
depending on what the compiler supports.
- Refactor all of the type-generic macros to use __fp_type_select().
% Index: src/math.h
% ===
% --- src/math.h(revision 253148)
% +++ src/math.h(working copy)
% @@ -80,28 +80,39 @@
% #define FP_NORMAL 0x04
% #define FP_SUBNORMAL0x08
% #define FP_ZERO 0x10
% +
% +#if __STDC_VERSION__ = 201112L
% +#define __fp_type_select(x, f, d, ld) _Generic((x), \
% + float: f(x),\
% + double: d(x), \
% + long double: ld(x))
The normal formatting of this is unclear. Except for the tab after #define.
math.h has only 1 other instance of a space after #define.
% +#elif __GNUC_PREREQ__(5, 1)
% +#define __fp_type_select(x, f, d, ld) __builtin_choose_expr(
\
% + __builtin_types_compatible_p(__typeof (x), long double), ld(x),\
% + __builtin_choose_expr(\
% + __builtin_types_compatible_p(__typeof (x), double), d(x),\
% +__builtin_choose_expr( \
% + __builtin_types_compatible_p(__typeof (x), float), f(x), (void)0)))
Extra space after __typeof.
Normal formatting doesn't march to the right like this...
% +#else
% +#define __fp_type_select(x, f, d, ld) \
% + ((sizeof (x) == sizeof (float)) ? f(x)\
% + : (sizeof (x) == sizeof (double)) ? d(x) \
% + : ld(x))
... or like this.
Extra space after sizeof (bug copied from old code).
% +#endif
% +
% +
% +
Extra blank lines.
% #define fpclassify(x) \
% -((sizeof (x) == sizeof (float)) ? __fpclassifyf(x) \
% -: (sizeof (x) == sizeof (double)) ? __fpclassifyd(x) \
% -: __fpclassifyl(x))
Example of normal style in old code (except for the space after sizeof(),
and the backslashes aren't line up like they are in some other places in
this file).
% ...
% @@ -119,10 +130,8 @@
% #define isunordered(x, y) (isnan(x) || isnan(y))
% #endif /* __MATH_BUILTIN_RELOPS */
%
% -#define signbit(x) \
% -((sizeof (x) == sizeof (float)) ? __signbitf(x) \
% -: (sizeof (x) == sizeof (double)) ? __signbit(x) \
% -: __signbitl(x))
% +#define signbit(x) \
% + __fp_type_select(x, __signbitf, __signbit, __signbitl)
The tab lossage is especially obvious here.
This macro definition fits on 1 line now. Similarly for others except
__inline_isnan*, which takes 2 lines. __inline_isnan* should be named
less verbosely, without __inline. I think this doesn't cause any
significant conflicts with libm. Might need __always_inline.
__fp_type_select is also verbose.
%
% typedef __double_t double_t;
% typedef __float_t float_t;
% @@ -175,6 +184,7 @@
% int __isfinite(double) __pure2;
% int __isfinitel(long double) __pure2;
% int __isinff(float) __pure2;
% +int __isinf(double) __pure2;
% int __isinfl(long double) __pure2;
% int __isnanf(float) __pure2;
% int __isnanl(long double) __pure2;
% @@ -185,6 +195,23 @@
% int __signbitf(float) __pure2;
% int __signbitl(long double) __pure2;
The declarations of old extern functions can probably be removed too
when they are replaced by inlines (only __isnan*() for now) . I think
the declarations of __isnan*() are now only used to prevent warnings
(at higher warning levels than have ever been used) in the file that
implement the functions.
%
% +static __inline int
% +__inline_isnanf(float __x)
% +{
% + return (__x != __x);
% +}
% +static __inline int
% +__inline_isnan(double __x)
% +{
% + return (__x != __x);
% +}
% +static __inline int
% +__inline_isnanl(long double __x)
% +{
% + return (__x != __x);
% +}
% +
% +
Extra blank lines.
Some insertion sort errors. In this file, APIs are mostly sorted in the
order double, float, long double.
All the inline functions except __inline_isnan*() only evaluate their
args once, so they can be simpler
Re: hacking - aio_sendfile()
On Jul 10, 2013, at 11:17 PM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: Hiya, I've started writing an aio_sendfile() syscall. http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff Yes, the diff is against -HEAD and not stable/9. It's totally horrible, hackish and likely bad. I've only done some very, very basic testing to ensure it actually works; i haven't at all stress tested it out yet. It's also very naive - I'm not at all doing any checks to see whether I can short-cut to do the aio there and then; I'm always queuing the sendfile() op through the worker threads. That's likely stupid and inefficient in a lot of cases, but it at least gets the syscall up and working. Yes, it is naive, but for different reason. The kern_sendfile() is synchronous function, it only completes after the other end of the network communication allows it. This means that calling kern_sendfile() from the aio thread blocks the thread indefinitely by unbounded sleep. No, kern_sendfile is async unless you specify the SF_SYNC hack flag. Otherwise, it'll fill the socket buffer and then return immediately, unless the socket buffer is full and the socket is set to blocking mode. That's outside the scope, as I said in my previous email. Scott ___ 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: hacking - aio_sendfile()
On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote: On Jul 10, 2013, at 11:17 PM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: Hiya, I've started writing an aio_sendfile() syscall. http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff Yes, the diff is against -HEAD and not stable/9. It's totally horrible, hackish and likely bad. I've only done some very, very basic testing to ensure it actually works; i haven't at all stress tested it out yet. It's also very naive - I'm not at all doing any checks to see whether I can short-cut to do the aio there and then; I'm always queuing the sendfile() op through the worker threads. That's likely stupid and inefficient in a lot of cases, but it at least gets the syscall up and working. Yes, it is naive, but for different reason. The kern_sendfile() is synchronous function, it only completes after the other end of the network communication allows it. This means that calling kern_sendfile() from the aio thread blocks the thread indefinitely by unbounded sleep. No, kern_sendfile is async unless you specify the SF_SYNC hack flag. Otherwise, it'll fill the socket buffer and then return immediately, unless the socket buffer is full and the socket is set to blocking mode. That's outside the scope, as I said in my previous email. You do not understand what I said, please re-read both my mail and code before replying. Implementing aio_sendfile() as proposed would create yet another possibility of indefinitely block all processes using aio. pgpZPbm2SyxrI.pgp Description: PGP signature
Re: hacking - aio_sendfile()
On Jul 11, 2013, at 2:56 AM, Konstantin Belousov kostik...@gmail.com wrote: On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote: On 11 July 2013 02:36, Konstantin Belousov kostik...@gmail.com wrote: No, it is not disk I/O which is problematic there. It is socket I/O e.g. wait for the socket buffers lomark in the kern_sendfile() which causes unbounded sleep. Look for the sbwait() call, both in the kern_sendfile() itself, and in the pru_send methods of the protocols, e.g. in sosend_generic(). The wait scope controlled by the other side of connection and allow it to completely block the aio subsystem. Disk I/O is supposed to finish in the finite time. Even if the destination socket is marked as NONBLOCK? You mean, would a sleep for the socket buffer space cause aio thread block is the socket is put in nonblocking mode ? Or something else ? No, it would not block the thread. But I cannot consider the aio_sendfile(2) implementation useful if it requires non-blocking socket. Also, what about other thread changing the socket to blocking mode while sendfile is in flight ? Just as with other aspects of sendfile, it's up to the caller to protect this kind of state. Objecting to aio_sendfile() simply for the reason you state is absurd and against the design goals of sendfile. Scott ___ 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: hacking - aio_sendfile()
On Jul 11, 2013, at 11:48 AM, Konstantin Belousov kostik...@gmail.com wrote: On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote: On Jul 10, 2013, at 11:17 PM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: Hiya, I've started writing an aio_sendfile() syscall. http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff Yes, the diff is against -HEAD and not stable/9. It's totally horrible, hackish and likely bad. I've only done some very, very basic testing to ensure it actually works; i haven't at all stress tested it out yet. It's also very naive - I'm not at all doing any checks to see whether I can short-cut to do the aio there and then; I'm always queuing the sendfile() op through the worker threads. That's likely stupid and inefficient in a lot of cases, but it at least gets the syscall up and working. Yes, it is naive, but for different reason. The kern_sendfile() is synchronous function, it only completes after the other end of the network communication allows it. This means that calling kern_sendfile() from the aio thread blocks the thread indefinitely by unbounded sleep. No, kern_sendfile is async unless you specify the SF_SYNC hack flag. Otherwise, it'll fill the socket buffer and then return immediately, unless the socket buffer is full and the socket is set to blocking mode. That's outside the scope, as I said in my previous email. You do not understand what I said, please re-read both my mail and code before replying. Implementing aio_sendfile() as proposed would create yet another possibility of indefinitely block all processes using aio. I'm lost, maybe I missed some emails? I see a set of emails where you incorrectly state that kern_sendfile() will always call sbwait(), and then you backtrack on that and claim that it's unacceptable to enforce that SS_NBIO be used for aio operations. I apologize if I'm missing something here. Scott ___ 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: hacking - aio_sendfile()
On Thu, Jul 11, 2013 at 12:04:57PM -0700, Scott Long wrote: On Jul 11, 2013, at 11:48 AM, Konstantin Belousov kostik...@gmail.com wrote: On Thu, Jul 11, 2013 at 11:44:32AM -0700, Scott Long wrote: On Jul 10, 2013, at 11:17 PM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: Hiya, I've started writing an aio_sendfile() syscall. http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff Yes, the diff is against -HEAD and not stable/9. It's totally horrible, hackish and likely bad. I've only done some very, very basic testing to ensure it actually works; i haven't at all stress tested it out yet. It's also very naive - I'm not at all doing any checks to see whether I can short-cut to do the aio there and then; I'm always queuing the sendfile() op through the worker threads. That's likely stupid and inefficient in a lot of cases, but it at least gets the syscall up and working. Yes, it is naive, but for different reason. The kern_sendfile() is synchronous function, it only completes after the other end of the network communication allows it. This means that calling kern_sendfile() from the aio thread blocks the thread indefinitely by unbounded sleep. No, kern_sendfile is async unless you specify the SF_SYNC hack flag. Otherwise, it'll fill the socket buffer and then return immediately, unless the socket buffer is full and the socket is set to blocking mode. That's outside the scope, as I said in my previous email. You do not understand what I said, please re-read both my mail and code before replying. Implementing aio_sendfile() as proposed would create yet another possibility of indefinitely block all processes using aio. I'm lost, maybe I missed some emails? I see a set of emails where you incorrectly state that kern_sendfile() will always call sbwait(), and then you backtrack on that and claim that it's unacceptable to enforce that SS_NBIO be used for aio operations. I apologize if I'm missing something here. Can you cite my exact text where I claimed that kern_sendfile() always calls sbwait ? I wrote about this explicitely, stating that it is very easy to make kern_sendfile() sleep for the socket buffer space, and the duration of the sleep is user-controllable. As result, it allows to hang all processes doing aio calls, since aio thread pool is finite. I am sorry for retyping this and stealing your time by repeating. Making the kern_sendfile() to behave from the aio context as if the SS_NBIO was set on the socket contradicts the behaviour of other aio operations. E.g. aio_read and aio_write do not perform short reads and writes to not block the aio daemon threads (which is the cause of buggy behaviour of existing aio syscalls on sockets). More, I do not think that setting SS_NBIO is enough to prevent the blocking of aio threads in kern_sendfile(). The send socket buffer is locked exclusively by kern_sendfile(). Other thread which entered sendfile(2) and was deliberately put to sleep on the low watermark, still owns the so_snd sx. This means that aio threads trying to do kern_sendfile() on this socket would be also blocked, for duration controlled by other end. That said, even assuming SS_NBIO is always enforced and other sleep points are identified and worked around, the only benefit of such implementation comparing with the direct sendfile(2) call would be preventing the use of the calling thread context for disk i/o. FreeBSD recently gained aio_mlock(2) which allows to get the same result in non-hackish way. pgp2L4b4m0tRA.pgp Description: PGP signature
[head tinderbox] failure on i386/i386
TB --- 2013-07-11 17:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 17:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 17:00:18 - starting HEAD tinderbox run for i386/i386 TB --- 2013-07-11 17:00:18 - cleaning the object tree TB --- 2013-07-11 17:00:18 - /usr/local/bin/svn stat /src TB --- 2013-07-11 17:00:23 - At svn revision 253214 TB --- 2013-07-11 17:00:24 - building world TB --- 2013-07-11 17:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 17:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 17:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 17:00:24 - SRCCONF=/dev/null TB --- 2013-07-11 17:00:24 - TARGET=i386 TB --- 2013-07-11 17:00:24 - TARGET_ARCH=i386 TB --- 2013-07-11 17:00:24 - TZ=UTC TB --- 2013-07-11 17:00:24 - __MAKE_CONF=/dev/null TB --- 2013-07-11 17:00:24 - cd /src TB --- 2013-07-11 17:00:24 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Jul 11 17:00:31 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jul 11 20:12:25 UTC 2013 TB --- 2013-07-11 20:12:25 - generating LINT kernel config TB --- 2013-07-11 20:12:25 - cd /src/sys/i386/conf TB --- 2013-07-11 20:12:25 - /usr/bin/make -B LINT TB --- 2013-07-11 20:12:25 - cd /src/sys/i386/conf TB --- 2013-07-11 20:12:25 - /usr/sbin/config -m LINT TB --- 2013-07-11 20:12:25 - building LINT kernel TB --- 2013-07-11 20:12:25 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 20:12:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 20:12:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 20:12:25 - SRCCONF=/dev/null TB --- 2013-07-11 20:12:25 - TARGET=i386 TB --- 2013-07-11 20:12:25 - TARGET_ARCH=i386 TB --- 2013-07-11 20:12:25 - TZ=UTC TB --- 2013-07-11 20:12:25 - __MAKE_CONF=/dev/null TB --- 2013-07-11 20:12:25 - cd /src TB --- 2013-07-11 20:12:25 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jul 11 20:12:25 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Thu Jul 11 20:46:43 UTC 2013 TB --- 2013-07-11 20:46:43 - cd /src/sys/i386/conf TB --- 2013-07-11 20:46:43 - /usr/sbin/config -m LINT-NOINET TB --- 2013-07-11 20:46:43 - building LINT-NOINET kernel TB --- 2013-07-11 20:46:43 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 20:46:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 20:46:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 20:46:43 - SRCCONF=/dev/null TB --- 2013-07-11 20:46:43 - TARGET=i386 TB --- 2013-07-11 20:46:43 - TARGET_ARCH=i386 TB --- 2013-07-11 20:46:43 - TZ=UTC TB --- 2013-07-11 20:46:43 - __MAKE_CONF=/dev/null TB --- 2013-07-11 20:46:43 - cd /src TB --- 2013-07-11 20:46:43 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Thu Jul 11 20:46:43 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Thu Jul 11 21:17:55 UTC 2013 TB --- 2013-07-11 21:17:55 - cd /src/sys/i386/conf TB --- 2013-07-11 21:17:55 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-07-11 21:17:55 - building LINT-NOINET6 kernel TB --- 2013-07-11 21:17:55 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:17:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 21:17:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 21:17:55 - SRCCONF=/dev/null TB --- 2013-07-11 21:17:55 - TARGET=i386 TB --- 2013-07-11 21:17:55 - TARGET_ARCH=i386 TB --- 2013-07-11 21:17:55 - TZ=UTC TB --- 2013-07-11 21:17:55 - __MAKE_CONF=/dev/null TB --- 2013-07-11 21:17:55 - cd /src TB --- 2013-07-11 21:17:55 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Thu Jul 11 21:17:55 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Thu Jul 11 21:49:28 UTC 2013 TB --- 2013-07-11 21:49:28 - cd /src/sys/i386/conf TB --- 2013-07-11 21:49:28 - /usr/sbin/config -m LINT-NOIP TB --- 2013-07-11 21:49:28 - building LINT-NOIP kernel TB --- 2013-07-11 21:49:28 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:49:28 - MAKEOBJDIRPREFIX=/obj
[head tinderbox] failure on amd64/amd64
TB --- 2013-07-11 17:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 17:00:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 17:00:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-11 17:00:18 - cleaning the object tree TB --- 2013-07-11 17:00:18 - /usr/local/bin/svn stat /src TB --- 2013-07-11 17:00:23 - At svn revision 253214 TB --- 2013-07-11 17:00:24 - building world TB --- 2013-07-11 17:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 17:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 17:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 17:00:24 - SRCCONF=/dev/null TB --- 2013-07-11 17:00:24 - TARGET=amd64 TB --- 2013-07-11 17:00:24 - TARGET_ARCH=amd64 TB --- 2013-07-11 17:00:24 - TZ=UTC TB --- 2013-07-11 17:00:24 - __MAKE_CONF=/dev/null TB --- 2013-07-11 17:00:24 - cd /src TB --- 2013-07-11 17:00:24 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Jul 11 17:00:31 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Thu Jul 11 20:48:41 UTC 2013 TB --- 2013-07-11 20:48:41 - generating LINT kernel config TB --- 2013-07-11 20:48:41 - cd /src/sys/amd64/conf TB --- 2013-07-11 20:48:41 - /usr/bin/make -B LINT TB --- 2013-07-11 20:48:41 - cd /src/sys/amd64/conf TB --- 2013-07-11 20:48:41 - /usr/sbin/config -m LINT TB --- 2013-07-11 20:48:41 - building LINT kernel TB --- 2013-07-11 20:48:41 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 20:48:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 20:48:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 20:48:41 - SRCCONF=/dev/null TB --- 2013-07-11 20:48:41 - TARGET=amd64 TB --- 2013-07-11 20:48:41 - TARGET_ARCH=amd64 TB --- 2013-07-11 20:48:41 - TZ=UTC TB --- 2013-07-11 20:48:41 - __MAKE_CONF=/dev/null TB --- 2013-07-11 20:48:41 - cd /src TB --- 2013-07-11 20:48:41 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jul 11 20:48:41 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Thu Jul 11 21:20:29 UTC 2013 TB --- 2013-07-11 21:20:29 - cd /src/sys/amd64/conf TB --- 2013-07-11 21:20:29 - /usr/sbin/config -m LINT-NOINET TB --- 2013-07-11 21:20:29 - building LINT-NOINET kernel TB --- 2013-07-11 21:20:29 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:20:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 21:20:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 21:20:29 - SRCCONF=/dev/null TB --- 2013-07-11 21:20:29 - TARGET=amd64 TB --- 2013-07-11 21:20:29 - TARGET_ARCH=amd64 TB --- 2013-07-11 21:20:29 - TZ=UTC TB --- 2013-07-11 21:20:29 - __MAKE_CONF=/dev/null TB --- 2013-07-11 21:20:29 - cd /src TB --- 2013-07-11 21:20:29 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Thu Jul 11 21:20:30 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Thu Jul 11 21:50:20 UTC 2013 TB --- 2013-07-11 21:50:20 - cd /src/sys/amd64/conf TB --- 2013-07-11 21:50:20 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-07-11 21:50:20 - building LINT-NOINET6 kernel TB --- 2013-07-11 21:50:20 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 21:50:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 21:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 21:50:20 - SRCCONF=/dev/null TB --- 2013-07-11 21:50:20 - TARGET=amd64 TB --- 2013-07-11 21:50:20 - TARGET_ARCH=amd64 TB --- 2013-07-11 21:50:20 - TZ=UTC TB --- 2013-07-11 21:50:20 - __MAKE_CONF=/dev/null TB --- 2013-07-11 21:50:20 - cd /src TB --- 2013-07-11 21:50:20 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Thu Jul 11 21:50:20 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Thu Jul 11 22:20:11 UTC 2013 TB --- 2013-07-11 22:20:11 - cd /src/sys/amd64/conf TB --- 2013-07-11 22:20:11 - /usr/sbin/config -m LINT-NOIP TB --- 2013-07-11 22:20:11 - building LINT-NOIP kernel TB --- 2013-07-11 22:20:11 -
Re: NFS panic: newnfs_copycred: negative nfsc_ngroups (client HEAD r253033, server 9.1-R)
Bryan Drewery wrote: I received this panic on the client while doing heavy parallel reads/writes over NFS. I only recently moved these files to NFS, so I don't know whether or not it's a recent regression. Client: HEAD r253033 Server: 9.1-R core.txt: http://people.freebsd.org/~bdrewery/nfs.txt fstab of related paths: tank:/tank/distfiles/freebsd/mnt/distfiles nfs rw,bg,noatime,intr,rsize=65536,wsize=65536,readahead=8,nfsv4 0 0 tank:/usr/packages/ /mnt/all-packages nfs rw,bg,noatime,soft,retrycnt=3,rsize=65536,wsize=65536,readahead=8,nfsv4 0 0 The mount options soft and intr should never be used for NFSv4. If an RPC fails with ETIMEDOUT or EINTR it can leave the open state in an undefined state. If you still get one of these crashes with all hard mounts, email again, since that would imply a client bug. (This is documented in the BUGS sections of mount_nfs(1), but not very well.;-) I'm not sure if this undefined open state could cause the crash, but it seems plausible, since the crash indicates garbage for the credentials in the open state structure. rick Server: params on these paths: -maproot=root -network 10.10.0.0/16 tcpdump at the time: 21:43:05.396585 IP 10.10.0.7.4180315003 10.10.0.5.2049: 168 getattr fh 0,4/2 21:43:05.396589 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48265029:48266477, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 21:43:05.396603 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48266477:48267925, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 21:43:05.396605 IP 10.10.0.7.946 10.10.0.5.2049: Flags [.], ack 48266477, win 3916, options [nop,nop,TS val 596674 ecr 1950216660], length 0 21:43:05.396608 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48267925:48269373, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 21:43:05.396621 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48269373:48270821, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 21:43:05.396624 IP 10.10.0.7.946 10.10.0.5.2049: Flags [.], ack 48269373, win 3870, options [nop,nop,TS val 596674 ecr 1950216660], length 0 21:43:05.396641 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48270821:48272269, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 21:43:05.396653 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48272269:48273717, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 21:43:05.396656 IP 10.10.0.7.946 10.10.0.5.2049: Flags [.], ack 48272269, win 3825, options [nop,nop,TS val 596674 ecr 1950216660], length 0 21:43:05.396659 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48273717:48275165, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 21:43:05.396671 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48275165:48276613, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 21:43:05.396674 IP 10.10.0.7.946 10.10.0.5.2049: Flags [.], ack 48275165, win 3780, options [nop,nop,TS val 596674 ecr 1950216660], length 0 21:43:05.396676 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48276613:48278061, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 ecr 596674], length 1448 21:43:05.396689 IP 10.10.0.5.2049 10.10.0.7.946: Flags [.], seq 48278061:48279509, ack 4394885, win 29124, options [nop,nop,TS val Write failed: Broken pipe I have nfsuserd running on both client/server. nfscbd is running. nfs_client_enable=yes in rc.conf. User lookups seem to work fine: -rw-r--r-- 1 root bryan 1554804 Jul 6 10:50 /mnt/distfiles/pkg-1.1.4.tar.xz I ran a find -ls on these paths and all files return a user/group. I am guessing there is a race condition with files being written and looking up the associated groups. -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-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: hacking - aio_sendfile()
On 2013/07/11 14:17, Konstantin Belousov wrote: On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: Hiya, I've started writing an aio_sendfile() syscall. http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff Yes, the diff is against -HEAD and not stable/9. It's totally horrible, hackish and likely bad. I've only done some very, very basic testing to ensure it actually works; i haven't at all stress tested it out yet. It's also very naive - I'm not at all doing any checks to see whether I can short-cut to do the aio there and then; I'm always queuing the sendfile() op through the worker threads. That's likely stupid and inefficient in a lot of cases, but it at least gets the syscall up and working. Yes, it is naive, but for different reason. The kern_sendfile() is synchronous function, it only completes after the other end of the network communication allows it. This means that calling kern_sendfile() from the aio thread blocks the thread indefinitely by unbounded sleep. Your implementation easily causes exhaustion of the aio thread pool, blocking the whole aio subsystem. It is known that our aio does not work for sockets for the same reason. I object against adding more code with the same defect. Proper route seems to rewrite aio for sockets using the upcalls. The same should be done for sendfile, if sendfile is given aio flavor. Yes, current aio implementation is horrible, it only works for fast disk I/O, I think the thread pool size is enough to saturate disks, but for socket or pipe I/O, it does not work well, the thread pool is too easy to be exhausted. I even think the support for socket and pipe in aio code should be cut and thrown away, because you can always use kqueue + non-blocking I/O. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-07-12 01:00:05 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 01:00:05 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 01:00:05 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-12 01:00:05 - cleaning the object tree TB --- 2013-07-12 01:01:29 - /usr/local/bin/svn stat /src TB --- 2013-07-12 01:01:32 - At svn revision 253214 TB --- 2013-07-12 01:01:33 - building world TB --- 2013-07-12 01:01:33 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 01:01:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 01:01:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 01:01:33 - SRCCONF=/dev/null TB --- 2013-07-12 01:01:33 - TARGET=sparc64 TB --- 2013-07-12 01:01:33 - TARGET_ARCH=sparc64 TB --- 2013-07-12 01:01:33 - TZ=UTC TB --- 2013-07-12 01:01:33 - __MAKE_CONF=/dev/null TB --- 2013-07-12 01:01:33 - cd /src TB --- 2013-07-12 01:01:33 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jul 12 01:01:40 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Jul 12 02:05:13 UTC 2013 TB --- 2013-07-12 02:05:13 - generating LINT kernel config TB --- 2013-07-12 02:05:13 - cd /src/sys/sparc64/conf TB --- 2013-07-12 02:05:13 - /usr/bin/make -B LINT TB --- 2013-07-12 02:05:13 - cd /src/sys/sparc64/conf TB --- 2013-07-12 02:05:13 - /usr/sbin/config -m LINT TB --- 2013-07-12 02:05:13 - building LINT kernel TB --- 2013-07-12 02:05:13 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 02:05:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 02:05:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 02:05:13 - SRCCONF=/dev/null TB --- 2013-07-12 02:05:13 - TARGET=sparc64 TB --- 2013-07-12 02:05:13 - TARGET_ARCH=sparc64 TB --- 2013-07-12 02:05:13 - TZ=UTC TB --- 2013-07-12 02:05:13 - __MAKE_CONF=/dev/null TB --- 2013-07-12 02:05:13 - cd /src TB --- 2013-07-12 02:05:13 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Jul 12 02:05:13 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float
Re: ipv6_addrs_IF aliases in rc.conf(5)
Kevin Oberman rkober...@gmail.com wrote in can6yy1srswemj2_bjx_drzmxgk4tf50_ode8o8i2d6wtrgw...@mail.gmail.com: rk On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder f...@feld.me wrote: rk rk On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm rk trash...@odo.in-berlin.de wrote: rk rk Will that patch make it into 9.2? If I am not mistaken, that patch isn't rk in stable yet. rk rk rk I would also like to see this patch hit 9.x sooner than later. It's so rk painful when someone forgets to fix the alias numbering on servers with rk many, many IPv4 and IPv6 addresses... rk rk rk Please, please, please, please, ...! rk rk Freeze is only two days away, so time for 9.2 is almost over and I can see rk no good reason NOT to get this done. r252015 was merged to stable/9 today. -- Hiroki pgpwhHHP9UTVY.pgp Description: PGP signature
Re: ipv6_addrs_IF aliases in rc.conf(5)
On Thu, Jul 11, 2013 at 9:56 PM, Hiroki Sato h...@freebsd.org wrote: Kevin Oberman rkober...@gmail.com wrote in can6yy1srswemj2_bjx_drzmxgk4tf50_ode8o8i2d6wtrgw...@mail.gmail.com: rk On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder f...@feld.me wrote: rk rk On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm rk trash...@odo.in-berlin.de wrote: rk rk Will that patch make it into 9.2? If I am not mistaken, that patch isn't rk in stable yet. rk rk rk I would also like to see this patch hit 9.x sooner than later. It's so rk painful when someone forgets to fix the alias numbering on servers with rk many, many IPv4 and IPv6 addresses... rk rk rk Please, please, please, please, ...! rk rk Freeze is only two days away, so time for 9.2 is almost over and I can see rk no good reason NOT to get this done. r252015 was merged to stable/9 today. -- Hiroki Just under the wire! I'm sure that I am not the only one who appreciates it. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on armv6/arm
TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-12 04:10:19 - cleaning the object tree TB --- 2013-07-12 04:10:19 - /usr/local/bin/svn stat /src TB --- 2013-07-12 04:10:23 - At svn revision 253248 TB --- 2013-07-12 04:10:24 - building world TB --- 2013-07-12 04:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 04:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 04:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 04:10:24 - SRCCONF=/dev/null TB --- 2013-07-12 04:10:24 - TARGET=arm TB --- 2013-07-12 04:10:24 - TARGET_ARCH=armv6 TB --- 2013-07-12 04:10:24 - TZ=UTC TB --- 2013-07-12 04:10:24 - __MAKE_CONF=/dev/null TB --- 2013-07-12 04:10:24 - cd /src TB --- 2013-07-12 04:10:24 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jul 12 04:10:33 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~~ /obj/arm.armv6/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~ /obj/arm.armv6/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x),\ ^~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 05:40:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 05:40:17 - ERROR: failed to build world TB --- 2013-07-12 05:40:17 - 4330.73 user 682.20 system 5397.30 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on arm/arm
TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-12 04:10:19 - cleaning the object tree TB --- 2013-07-12 04:10:19 - /usr/local/bin/svn stat /src TB --- 2013-07-12 04:10:23 - At svn revision 253248 TB --- 2013-07-12 04:10:24 - building world TB --- 2013-07-12 04:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 04:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 04:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 04:10:24 - SRCCONF=/dev/null TB --- 2013-07-12 04:10:24 - TARGET=arm TB --- 2013-07-12 04:10:24 - TARGET_ARCH=arm TB --- 2013-07-12 04:10:24 - TZ=UTC TB --- 2013-07-12 04:10:24 - __MAKE_CONF=/dev/null TB --- 2013-07-12 04:10:24 - cd /src TB --- 2013-07-12 04:10:24 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jul 12 04:10:32 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~~ /obj/arm.arm/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~ /obj/arm.arm/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x),\ ^~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 05:40:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 05:40:15 - ERROR: failed to build world TB --- 2013-07-12 05:40:15 - 4327.65 user 679.95 system 5396.15 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-07-12 04:10:19 - cleaning the object tree TB --- 2013-07-12 04:18:47 - /usr/local/bin/svn stat /src TB --- 2013-07-12 04:18:50 - At svn revision 253248 TB --- 2013-07-12 04:18:51 - building world TB --- 2013-07-12 04:18:51 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 04:18:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 04:18:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 04:18:51 - SRCCONF=/dev/null TB --- 2013-07-12 04:18:51 - TARGET=amd64 TB --- 2013-07-12 04:18:51 - TARGET_ARCH=amd64 TB --- 2013-07-12 04:18:51 - TZ=UTC TB --- 2013-07-12 04:18:51 - __MAKE_CONF=/dev/null TB --- 2013-07-12 04:18:51 - cd /src TB --- 2013-07-12 04:18:51 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jul 12 04:18:58 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~~ /obj/amd64.amd64/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~ /obj/amd64.amd64/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x),\ ^~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 05:45:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 05:45:37 - ERROR: failed to build world TB --- 2013-07-12 05:45:37 - 4353.59 user 679.80 system 5717.27 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2013-07-12 04:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-12 04:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-12 04:10:19 - starting HEAD tinderbox run for i386/i386 TB --- 2013-07-12 04:10:19 - cleaning the object tree TB --- 2013-07-12 04:18:19 - /usr/local/bin/svn stat /src TB --- 2013-07-12 04:18:22 - At svn revision 253248 TB --- 2013-07-12 04:18:23 - building world TB --- 2013-07-12 04:18:23 - CROSS_BUILD_TESTING=YES TB --- 2013-07-12 04:18:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-12 04:18:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-12 04:18:23 - SRCCONF=/dev/null TB --- 2013-07-12 04:18:23 - TARGET=i386 TB --- 2013-07-12 04:18:23 - TARGET_ARCH=i386 TB --- 2013-07-12 04:18:23 - TZ=UTC TB --- 2013-07-12 04:18:23 - __MAKE_CONF=/dev/null TB --- 2013-07-12 04:18:23 - cd /src TB --- 2013-07-12 04:18:23 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jul 12 04:18:30 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] ^~~~ /obj/i386.i386/src/tmp/usr/include/math.h:128:20: note: expanded from macro 'signbit' #define signbit(x) __fp_type_select(x, __signbitf, __signbit, __signbitl) ^~ /obj/i386.i386/src/tmp/usr/include/math.h:91:2: note: expanded from macro '__fp_type_select' __builtin_types_compatible_p(__typeof(x), long double), ld(x),\ ^~ 6 errors generated. *** Error code 1 Stop. make: stopped in /src/gnu/lib/libstdc++ *** Error code 1 Stop. make: stopped in /src/gnu/lib *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-12 05:45:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-12 05:45:02 - ERROR: failed to build world TB --- 2013-07-12 05:45:02 - 4337.52 user 685.93 system 5682.32 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.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
