Re: fusefs-kmod does not work on 8-STABLE?
On Fri, Apr 12, 2013 at 07:12:39PM +0200, Dimitry Andric wrote:
Does anyone have a clue why new ld(1) plays so badly with our system
toolchain on 8.x (at least)?
Maybe because there is almost 10 years difference between those
implementations? :-)
In any case, to figure out what is different, just try linking the
kernel module with the system ld and the ports ld, and comparing
readelf -a output.
Good idea. I've uploaded both outputs if someone wants to take a look.
Not surprisingly, bad output is shorter: readelf(1) reported only 16
section headers vs. good 18 (missing .got, .gnu_debuglink, and empty
.bss, yet having .eh_frame instead). Haven't look more closely yet:
http://193.124.210.26/readelf.bad
http://193.124.210.26/readelf.good
Or upload both module versions somewhere, so we can all have a look.
Sure, at the same URL, hello{.c,_bad.ko,_good.ko}. Although it should be
pretty easy to reproduce locally: just install fresh devel/binutils, put
$localbase/bin in front of your $path, and rebuild hello.ko (or any your
favorite module).
./danfe
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
In the previous version (0.61), the process of checking file names against the list of known files in the repository was inefficient and most likely accounts for the slow down you're seeing. I've reimplemented it using a binary search tree and the lookup phase is no longer a bottleneck. I'm sorry but 0.62 still locks while fetching from a local repository: last pid: 74701; load averages: 2.24, 2.52, 2.56 up 772+03:32:23 13:19:55 96 processes: 2 running, 94 sleeping CPU: 14.8% user, 0.0% nice, 40.3% system, 0.7% interrupt, 44.2% idle Mem: 1191M Active, 436M Inact, 248M Wired, 76M Cache, 112M Buf, 50M Free Swap: 1024M Total, 232M Used, 792M Free, 22% Inuse PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 30193 root 1 1170 56220K 9108K CPU11 99:16 96.39% svnup The send/receive queues are filled up and not changing over time: root@alpha:~# netstat -an | fgrep -w 3690 tcp48192 24576 81.30.199.66.3690 81.30.199.66.44473 ESTABLISHED tcp4 24576 16384 81.30.199.66.44473 81.30.199.66.3690 ESTABLISHED tcp4 0 0 *.3690 *.*LISTEN root@alpha:~# kdump | head -40 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) I think you should either use blocking IO or catch IO errors. And please consider to set the socket options too. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
here is what I used to use (not 100% match, but quite close): indent -bad -bap -bbb -d4 -di1 -fc1 -i4 -nip -npsl -nut $* -- Markiyan. On 13.04.2013 02:38, John Mehr wrote: On Thu, 11 Apr 2013 01:39:32 -0700 (PDT) mrb...@gmail.com wrote: On Thursday, April 11, 2013 1:14:57 PM UTC+6, mrb...@gmail.com wrote: I've placed the patched svnup.c (0.56), the diff and two statically linked binaries on http://ftp.ufanet.ru/pub/boco/freebsd/svnup/ I'm sorry, svnup.c.diff is the patch against filtered thru indent svnup.c, with different formatting (see README). The patch against the original svnup.c v0.56 is named svnup.c.diff-original. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Hello, Speaking of indent(1), does anyone know of a set of command line parameters that can reformat source code to style(9) guidelines (or a close approximation)? Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
The only thing I would like to add -- tree lookup did make a good effect on CPU consumption. -- Markiyan. On 13.04.2013 10:38, mrb...@gmail.com wrote: In the previous version (0.61), the process of checking file names against the list of known files in the repository was inefficient and most likely accounts for the slow down you're seeing. I've reimplemented it using a binary search tree and the lookup phase is no longer a bottleneck. I'm sorry but 0.62 still locks while fetching from a local repository: last pid: 74701; load averages: 2.24, 2.52, 2.56 up 772+03:32:23 13:19:55 96 processes: 2 running, 94 sleeping CPU: 14.8% user, 0.0% nice, 40.3% system, 0.7% interrupt, 44.2% idle Mem: 1191M Active, 436M Inact, 248M Wired, 76M Cache, 112M Buf, 50M Free Swap: 1024M Total, 232M Used, 792M Free, 22% Inuse PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 30193 root 1 1170 56220K 9108K CPU11 99:16 96.39% svnup The send/receive queues are filled up and not changing over time: root@alpha:~# netstat -an | fgrep -w 3690 tcp48192 24576 81.30.199.66.3690 81.30.199.66.44473 ESTABLISHED tcp4 24576 16384 81.30.199.66.44473 81.30.199.66.3690 ESTABLISHED tcp4 0 0 *.3690 *.*LISTEN root@alpha:~# kdump | head -40 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) I think you should either use blocking IO or catch IO errors. And please consider to set the socket options too. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On 13.04.2013 11:29, Markiyan Kushnir wrote: The only thing I would like to add -- tree lookup did make a good effect on CPU consumption. John, I'm just curious, did you consider sys/tree.h for tree implementation? I realize that it wouldn't be well portable to Linux. Any way, did you have other considerations to use your own tree implementation in svnup? -- Markiyan. -- Markiyan. On 13.04.2013 10:38, mrb...@gmail.com wrote: In the previous version (0.61), the process of checking file names against the list of known files in the repository was inefficient and most likely accounts for the slow down you're seeing. I've reimplemented it using a binary search tree and the lookup phase is no longer a bottleneck. I'm sorry but 0.62 still locks while fetching from a local repository: last pid: 74701; load averages: 2.24, 2.52, 2.56 up 772+03:32:23 13:19:55 96 processes: 2 running, 94 sleeping CPU: 14.8% user, 0.0% nice, 40.3% system, 0.7% interrupt, 44.2% idle Mem: 1191M Active, 436M Inact, 248M Wired, 76M Cache, 112M Buf, 50M Free Swap: 1024M Total, 232M Used, 792M Free, 22% Inuse PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 30193 root 1 1170 56220K 9108K CPU11 99:16 96.39% svnup The send/receive queues are filled up and not changing over time: root@alpha:~# netstat -an | fgrep -w 3690 tcp48192 24576 81.30.199.66.3690 81.30.199.66.44473 ESTABLISHED tcp4 24576 16384 81.30.199.66.44473 81.30.199.66.3690 ESTABLISHED tcp4 0 0 *.3690 *.*LISTEN root@alpha:~# kdump | head -40 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) 30193 svnupRET write -1 errno 35 Resource temporarily unavailable 30193 svnupCALL write(0x3,0x8843a000,0xd91) I think you should either use blocking IO or catch IO errors. And please consider to set the socket options too. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gnutls compile issues
On Apr 13, 2013, at 03:15, dparussa...@baysidegrp.com.au wrote: I am having issues compiling gnutls-2.12.23 on Freebsd 6.4 stable platform. Please find the following errors. Any help much appropriated. checking whether wchar.h uses 'inline' correctly... no configure: error: wchar.h cannot be used with this compiler (cc -std=gnu99 -O2 -fno-strict-aliasing -pipe -I/usr/local/include/p11-kit-1 -I/usr/local/include -fPIC -D_THREAD_SAFE). This is a known interoperability problem of glibc = 2.5 with gcc = 4.3 in C99 mode. You have four options: - Add the flag -fgnu89-inline to CC and reconfigure, or - Fix your include files, using parts of http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b037a293a48718af30d706c2e18c929d0e69a621, or - Use a gcc version older than 4.3, or - Don't use the flags -std=c99 or -std=gnu99. Let me start by saying 6.4 is totally unsupported, but you are most likely aware of that. :-) That said, I don't think 6.4 already had complete C99 support, so this is probably why the configure script fails. You can see the script itself gives you a few hints for a workaround. Since 6.4 is already using a gcc version older than 4.3, and the fix your include files hint is only valid for glibc, the best option is to make sure -std=c99 or -std=gnu99 is *not* used. For example, if you are building this manually, try setting ac_cv_prog_cc_c99=no in configure's environment, like so: ac_cv_prog_cc_c99=no ./configure If you are building this from the port, try adding a line: CONFIGURE_ENV+= ac_cv_prog_cc_c99=no in the port's Makefile. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipv6_addrs_IF aliases in rc.conf(5)
On Thu, Jan 17, 2013 at 7:24 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin sch...@gmail.com wrote:
2012/12/26 Kimmo Paasiala kpaas...@gmail.com:
I've revised the patch again and updated it at gihub,
https://gist.github.com/4362018. It can now be applied at top level
of sources (/usr/src typically). It now does the deconfiguration in
reverse order of the configuration, meaning the aliases configured
with ipv6_addrs_IF are removed before the ones configured with
ifconfig_IF_aliasN=inet6
Adapted for FreeBSD 8.2, works fine:
--- network.subr.orig 2011-02-17 05:19:39.0 +0300
+++ network.subr2012-12-28 00:46:38.0 +0400
@@ -312,6 +312,12 @@ afexists()
# 1 otherwise.
ipv6if()
{
+ # Test for $ipv6_addrs_IF. If it exists then the
+ # interface should be configured for IPv6
+ _tmpargs=$(get_if_var $_if ipv6_addrs_IF)
+ if [ -n ${_tmpargs} ]; then
+ return 0
+ fi
if ! checkyesno ipv6_enable; then
return 1
fi
@@ -948,7 +954,12 @@ network6_interface_setup()
rtsol_interface=no
ifconfig $i inet6 ${ipv6_ifconfig} alias
fi
-
+ ipv6_addrs=`get_if_var $i ipv6_addrs_IF`
+ if [ -n ${ipv6_addrs} ]; then
+ rtsol_available=no
+ rtsol_interface=no
+ ipv6_addrs_common ${i} alias
+ fi
# Wireless NIC cards are virtualized through the wlan
interface
if ! is_wired_interface ${i}; then
case ${i} in
@@ -1178,3 +1189,39 @@ network6_getladdr()
esac
done
}
+
+ipv6_addrs_common()
+{
+ local _ret _if _action _ip6prefix _ip6prefixes
+ local _ip6addr _prefixlen
+ local _range _ip6net _ip6low _ip6high
+ _ret=1
+ _if=$1
+ _action=$2
+ # get the prefixes from ipv6_addrs_IF variable
+ _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
+ for _ip6prefix in ${_ip6prefixes}; do
+ _ip6addr=${_ip6prefix%%/*}
+ _prefixlen=${_ip6prefix##*/}
+ _range=${_ip6addr##*:}
+ _ip6net=${_ip6addr%:*}
+ _ip6low=${_range%-*}
+ _ip6high=${_range#*-}
+ # If deleting an alias, set _prefixlen to null string.
+ if [ ${_action} = -alias ]; then
+ _prefixlen=
+ else
+ _prefixlen=prefixlen $_prefixlen
+ fi
+ _ip6high=$((0x${_ip6high}))
+ _ip6count=$((0x${_ip6low}))
+ while [ ${_ip6count} -le ${_ip6high} ]; do
+ # Re-uses the _ip6addr variable from above
+ _ip6addr=$(printf %x ${_ip6count})
+ eval ifconfig ${_if} inet6
${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}
+ _ip6count=$((${_ip6count}+1))
+ _ret=0
+ done
+ done
+ return $_ret
+}
--
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin
I don't have an 8.X system to test but I guess it's fine.
Any more interest in this? I'd love to see this added, not because I
wrote it but because I want to contribute in any way I can.
-Kimmo
Sorry to resurrect this thread but since nothing has happened in about
three months I have to ask: What can I do to have this commited to
HEAD? I'd be even willing to become a src committer if that's what is
required. I feel that I'm compentent enough. Who can I contact?
-Kimmo
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipv6_addrs_IF aliases in rc.conf(5)
Hi -- On 13.04.2013, at 14:29, Kimmo Paasiala kpaas...@gmail.com wrote: [great deal of simplification by ipv6_addrs_IF] Sorry to resurrect this thread but since nothing has happened in about three months I have to ask: What can I do to have this commited to HEAD? +1 Nowadays -where IPv6 becomes more and more available by ISPs- I *really* would like to see this simplification implemented, soon, very soon. The current scheme is way to much error prone, and, its a pain in the ass! Thanks for the patch, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gnutls compile issues
Thanks Dimitry, I've tried with the ENV variable in the Makefile. But still getting the same error. Any other ideas? I need to get the gnutls working on this system. Cheers, On Sat, April 13, 2013 21:52, Dimitry Andric wrote: On Apr 13, 2013, at 03:15, dparussa...@baysidegrp.com.au wrote: I am having issues compiling gnutls-2.12.23 on Freebsd 6.4 stable platform. Please find the following errors. Any help much appropriated. checking whether wchar.h uses 'inline' correctly... no configure: error: wchar.h cannot be used with this compiler (cc -std=gnu99 -O2 -fno-strict-aliasing -pipe -I/usr/local/include/p11-kit-1 -I/usr/local/include -fPIC -D_THREAD_SAFE). This is a known interoperability problem of glibc = 2.5 with gcc = 4.3 in C99 mode. You have four options: - Add the flag -fgnu89-inline to CC and reconfigure, or - Fix your include files, using parts of http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b037a293a48718af3 0d706c2e18c929d0e69a621, or - Use a gcc version older than 4.3, or - Don't use the flags -std=c99 or -std=gnu99. Let me start by saying 6.4 is totally unsupported, but you are most likely aware of that. :-) That said, I don't think 6.4 already had complete C99 support, so this is probably why the configure script fails. You can see the script itself gives you a few hints for a workaround. Since 6.4 is already using a gcc version older than 4.3, and the fix your include files hint is only valid for glibc, the best option is to make sure -std=c99 or -std=gnu99 is *not* used. For example, if you are building this manually, try setting ac_cv_prog_cc_c99=no in configure's environment, like so: ac_cv_prog_cc_c99=no ./configure If you are building this from the port, try adding a line: CONFIGURE_ENV+= ac_cv_prog_cc_c99=no in the port's Makefile. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: kern/165903: mbuf leak
To follow-up: I installed 9.1-RELEASE last night, then went and cvsup'ed to the latest that RELENG_9 would give me. Everything is completely stock, I have not modified any config files other than filling out the setup questions (hostname, em0 set to DHCP, added a base user so I can ssh to it) Mu current uname -a is: FreeBSD test 9.1-STABLE FreeBSD 9.1-STABLE #0: Sat Apr 13 00:29:24 ADT 2013 root@test:/usr/obj/usr/src/sys/GENERIC amd64 I am still having the same mbuf drain problem, that doesn't exist on 9.0-STABLE of July 2012. It's only been 2 hours since my last reboot, and you can already see the drain starting. I expect this box will be unresponsive on the network sometime tomorrow. All that has been running is a ssh connection that wasn't moving any traffic. Here is a dump of the requested logs. Please note that I give the stats at boot, then ~2 hours later. Please let me know how I can help this move forward. - After Boot Sat Apr 13 17:41:04 ADT 2013 root@test:/usr/home/aatech # vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 89, 13, 89, 0, 0 UMA Zones: 640, 0, 89, 1, 89, 0, 0 UMA Slabs: 568, 0,3817, 5,6208, 0, 0 UMA RCntSlabs: 568, 0, 273, 0, 273, 0, 0 UMA Hash: 256, 0, 3, 12, 4, 0, 0 16 Bucket: 152, 0, 64, 11, 64, 0, 0 32 Bucket: 280, 0, 51, 5, 51, 0, 0 64 Bucket: 536, 0, 34, 1, 34, 62, 0 128 Bucket:1048, 0, 41, 1, 41, 676, 0 VM OBJECT: 232, 0, 977, 31, 10100, 0, 0 MAP:232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 150257, 33, 246,8450, 0, 0 MAP ENTRY: 120, 0, 753, 115, 23051, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 323, 4, 323, 0, 0 16: 16, 0,2486, 202, 38914, 0, 0 32: 32, 0,2990, 444, 16915, 0, 0 64: 64, 0,7243, 261, 37658, 0, 0 128:128, 0,8311, 186, 12364, 0, 0 256:256, 0, 465, 75,3012, 0, 0 512:512, 0, 613, 66,3743, 0, 0 1024: 1024, 0, 34, 162,4785, 0, 0 2048: 2048, 0,5129, 141,5692, 0, 0 4096: 4096, 0, 421, 34,6083, 0, 0 Files: 80, 0, 78, 102,3712, 0, 0 rl_entry:40, 0, 29, 223, 29, 0, 0 TURNSTILE: 136, 0, 115, 45, 115, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1184, 0, 44, 28, 893, 0, 0 THREAD:1160, 0, 98, 16, 98, 0, 0 SLEEPQUEUE: 80, 0, 115, 30, 115, 0, 0 VMSPACE:392, 0, 26, 24, 876, 0, 0 cpuset: 72, 0, 51, 49, 51, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet:256, 0, 288, 224,1462, 0, 0 mbuf: 256, 0, 2, 266, 380, 0, 0 mbuf_cluster: 2048, 25600, 512, 16, 512, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 9, 6, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 144,3498, 0, 0 ttyinq: 160, 0, 180, 60, 765, 0, 0 ttyoutq:256, 0, 95, 25, 407, 0, 0 ata_request:328, 0, 0, 48, 86, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr:24, 0, 0, 0, 0, 0, 0 FPU_save_area: 832, 0, 0, 0, 0, 0, 0 VNODE: 504, 0, 490, 30, 516, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 36,7095, 0, 0 S VFS Cache:108, 0, 475,
Re: kern/165903: mbuf leak
On Sat, Apr 13, 2013 at 11:02:17PM +, Chris Forgeron wrote: To follow-up: I installed 9.1-RELEASE last night, then went and cvsup'ed to the latest that RELENG_9 would give me. Everything is completely stock, I have not modified any config files other than filling out the setup questions (hostname, em0 set to DHCP, added a base user so I can ssh to it) Mu current uname -a is: FreeBSD test 9.1-STABLE FreeBSD 9.1-STABLE #0: Sat Apr 13 00:29:24 ADT 2013 root@test:/usr/obj/usr/src/sys/GENERIC amd64 I am still having the same mbuf drain problem, that doesn't exist on 9.0-STABLE of July 2012. It's only been 2 hours since my last reboot, and you can already see the drain starting. I expect this box will be unresponsive on the network sometime tomorrow. All that has been running is a ssh connection that wasn't moving any traffic. Here is a dump of the requested logs. Please note that I give the stats at boot, then ~2 hours later. Please let me know how I can help this move forward. - After Boot Sat Apr 13 17:41:04 ADT 2013 root@test:/usr/home/aatech # vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 89, 13, 89, 0, 0 UMA Zones: 640, 0, 89, 1, 89, 0, 0 UMA Slabs: 568, 0,3817, 5,6208, 0, 0 UMA RCntSlabs: 568, 0, 273, 0, 273, 0, 0 UMA Hash: 256, 0, 3, 12, 4, 0, 0 16 Bucket: 152, 0, 64, 11, 64, 0, 0 32 Bucket: 280, 0, 51, 5, 51, 0, 0 64 Bucket: 536, 0, 34, 1, 34, 62, 0 128 Bucket:1048, 0, 41, 1, 41, 676, 0 VM OBJECT: 232, 0, 977, 31, 10100, 0, 0 MAP:232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 150257, 33, 246,8450, 0, 0 MAP ENTRY: 120, 0, 753, 115, 23051, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 323, 4, 323, 0, 0 16: 16, 0,2486, 202, 38914, 0, 0 32: 32, 0,2990, 444, 16915, 0, 0 64: 64, 0,7243, 261, 37658, 0, 0 128:128, 0,8311, 186, 12364, 0, 0 256:256, 0, 465, 75,3012, 0, 0 512:512, 0, 613, 66,3743, 0, 0 1024: 1024, 0, 34, 162,4785, 0, 0 2048: 2048, 0,5129, 141,5692, 0, 0 4096: 4096, 0, 421, 34,6083, 0, 0 Files: 80, 0, 78, 102,3712, 0, 0 rl_entry:40, 0, 29, 223, 29, 0, 0 TURNSTILE: 136, 0, 115, 45, 115, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1184, 0, 44, 28, 893, 0, 0 THREAD:1160, 0, 98, 16, 98, 0, 0 SLEEPQUEUE: 80, 0, 115, 30, 115, 0, 0 VMSPACE:392, 0, 26, 24, 876, 0, 0 cpuset: 72, 0, 51, 49, 51, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet:256, 0, 288, 224,1462, 0, 0 mbuf: 256, 0, 2, 266, 380, 0, 0 mbuf_cluster: 2048, 25600, 512, 16, 512, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 9, 6, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 144,3498, 0, 0 ttyinq: 160, 0, 180, 60, 765, 0, 0 ttyoutq:256, 0, 95, 25, 407, 0, 0 ata_request:328, 0, 0, 48, 86, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr:24, 0, 0, 0, 0, 0, 0 FPU_save_area: 832, 0, 0, 0, 0, 0, 0 VNODE: 504, 0, 490, 30, 516, 0, 0 VNODEPOLL: 112, 0,
RE: kern/165903: mbuf leak
Interesting about the drivers - I will look into that tomorrow, I could be on an older version. I started down that path a little while ago, but when pkng wasn't quite ready, I just reverted to the old ways/ommands that seemed to work. Here is the dump of the requested commands. I will point out the most interesting one first: dmsg It's flooded with: arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast Checking an older 9.0-STABLE from july, I see the same message flood in dmesg, but these machines are not exhausting mbuf. Perhaps there is a leak in handling this condition? Please note: I will also have this problem with the vmware VMXNET3 driver using vmware's official tools, so it's not just em at fault. Here is the rest. I left pciconf verbose Thanks. root@test:/usr/home/aatech # sysctl -a dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.5 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 handle=\_SB_.PCI0.P2P0.S1F0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x100f subvendor=0x15ad subdevice=0x0750 class=0x02 dev.em.0.%parent: pci2 dev.em.0.nvm: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.tx_desc_fail1: 0 dev.em.0.tx_desc_fail2: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1086325321 dev.em.0.rx_control: 32770 dev.em.0.fc_high_water: 47104 dev.em.0.fc_low_water: 45604 dev.em.0.fifo_workaround: 0 dev.em.0.fifo_reset: 0 dev.em.0.txd_head: 23 dev.em.0.txd_tail: 24 dev.em.0.rxd_head: 138 dev.em.0.rxd_tail: 137 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 73008 dev.em.0.mac_stats.good_pkts_recvd: 49029 dev.em.0.mac_stats.bcast_pkts_recvd: 0 dev.em.0.mac_stats.mcast_pkts_recvd: 0 dev.em.0.mac_stats.rx_frames_64: 0 dev.em.0.mac_stats.rx_frames_65_127: 45990 dev.em.0.mac_stats.rx_frames_128_255: 2446 dev.em.0.mac_stats.rx_frames_256_511: 592 dev.em.0.mac_stats.rx_frames_512_1023: 1 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 3809187 dev.em.0.mac_stats.good_octets_txd: 441363 dev.em.0.mac_stats.total_pkts_txd: 3497 dev.em.0.mac_stats.good_pkts_txd: 3497 dev.em.0.mac_stats.bcast_pkts_txd: 0 dev.em.0.mac_stats.mcast_pkts_txd: 0 dev.em.0.mac_stats.tx_frames_64: 418 dev.em.0.mac_stats.tx_frames_65_127: 2678 dev.em.0.mac_stats.tx_frames_128_255: 131 dev.em.0.mac_stats.tx_frames_256_511: 213 dev.em.0.mac_stats.tx_frames_512_1023: 49 dev.em.0.mac_stats.tx_frames_1024_1522: 8 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.wake: 0 root@test:/usr/home/aatech # cat pciconf.txt hostb0@pci0:0:0:0: class=0x06 card=0x197615ad chip=0x71908086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '440BX/ZX/DX - 82443BX/ZX/DX Host bridge' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x chip=0x71918086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '440BX/ZX/DX - 82443BX/ZX/DX AGP bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:7:0: class=0x060100 card=0x197615ad chip=0x71108086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4 ISA' class = bridge subclass = PCI-ISA atapci0@pci0:0:7:1: class=0x01018a card=0x197615ad chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4 IDE' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0x10c0, size 16, enabled
Re: kern/165903: mbuf leak
On Sun, Apr 14, 2013 at 12:02:56AM +, Chris Forgeron wrote: Interesting about the drivers - I will look into that tomorrow, I could be on an older version. I started down that path a little while ago, but when pkng wasn't quite ready, I just reverted to the old ways/ommands that seemed to work. Here is the dump of the requested commands. I will point out the most interesting one first: dmsg It's flooded with: arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast Checking an older 9.0-STABLE from july, I see the same message flood in dmesg, but these machines are not exhausting mbuf. Perhaps there is a leak in handling this condition? Please note: I will also have this problem with the vmware VMXNET3 driver using vmware's official tools, so it's not just em at fault. Here is the rest. I left pciconf verbose Thanks. root@test:/usr/home/aatech # sysctl -a dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.5 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 handle=\_SB_.PCI0.P2P0.S1F0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x100f subvendor=0x15ad subdevice=0x0750 class=0x02 dev.em.0.%parent: pci2 dev.em.0.nvm: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.tx_desc_fail1: 0 dev.em.0.tx_desc_fail2: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1086325321 dev.em.0.rx_control: 32770 dev.em.0.fc_high_water: 47104 dev.em.0.fc_low_water: 45604 dev.em.0.fifo_workaround: 0 dev.em.0.fifo_reset: 0 dev.em.0.txd_head: 23 dev.em.0.txd_tail: 24 dev.em.0.rxd_head: 138 dev.em.0.rxd_tail: 137 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 73008 dev.em.0.mac_stats.good_pkts_recvd: 49029 dev.em.0.mac_stats.bcast_pkts_recvd: 0 dev.em.0.mac_stats.mcast_pkts_recvd: 0 dev.em.0.mac_stats.rx_frames_64: 0 dev.em.0.mac_stats.rx_frames_65_127: 45990 dev.em.0.mac_stats.rx_frames_128_255: 2446 dev.em.0.mac_stats.rx_frames_256_511: 592 dev.em.0.mac_stats.rx_frames_512_1023: 1 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 3809187 dev.em.0.mac_stats.good_octets_txd: 441363 dev.em.0.mac_stats.total_pkts_txd: 3497 dev.em.0.mac_stats.good_pkts_txd: 3497 dev.em.0.mac_stats.bcast_pkts_txd: 0 dev.em.0.mac_stats.mcast_pkts_txd: 0 dev.em.0.mac_stats.tx_frames_64: 418 dev.em.0.mac_stats.tx_frames_65_127: 2678 dev.em.0.mac_stats.tx_frames_128_255: 131 dev.em.0.mac_stats.tx_frames_256_511: 213 dev.em.0.mac_stats.tx_frames_512_1023: 49 dev.em.0.mac_stats.tx_frames_1024_1522: 8 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.wake: 0 root@test:/usr/home/aatech # cat pciconf.txt hostb0@pci0:0:0:0: class=0x06 card=0x197615ad chip=0x71908086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '440BX/ZX/DX - 82443BX/ZX/DX Host bridge' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x chip=0x71918086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '440BX/ZX/DX - 82443BX/ZX/DX AGP bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:7:0: class=0x060100 card=0x197615ad chip=0x71108086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4 ISA' class = bridge subclass = PCI-ISA atapci0@pci0:0:7:1: class=0x01018a card=0x197615ad chip=0x71118086 rev=0x01 hdr=0x00
auditdistd user preventing installkernel
Hi all I was updating a newly installed FreeBSD 9.1 RELEASE box to 9-STABLE, and was preparing to install the kernel in order to reboot to test it. However I was immediately hit with this: # make installkernel DESTDIR=/ROOT/9-STABLE-2013-04-13 ERROR: Required auditdistd user is missing, see /usr/src/UPDATING. *** [installcheck_UGID] Error code 1 I did see UPDATING... 20121218: With the addition of auditdistd(8), a new auditdistd user is now depended on during installworld. mergemaster -p can be used to add the user prior to installworld, as documented in the handbook. It instructed me to run mergemaster -p prior to installworld (this should always be done anyway, according to updating). But I'm not installing world yet, just the kernel. Should UPDATING be corrected? Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
