Re: svn - but smaller?

[mrboco]

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

[Markiyan Kushnir]

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?

[Markiyan Kushnir]

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?

[Markiyan Kushnir]

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

[Dimitry Andric]

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  uses 'inline' correctly... no
> configure: error:  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
>
> ,
> 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)

[Kimmo Paasiala]

On Thu, Jan 17, 2013 at 7:24 AM, Kimmo Paasiala  wrote:
> On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin  wrote:
>> 2012/12/26 Kimmo Paasiala :
>>
>>> 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)

[Michael Grimm]

Hi --

On 13.04.2013, at 14:29, Kimmo Paasiala  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

[dparussalla]

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  uses 'inline' correctly... no configure:
>> error:  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
>> > 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

[Chris Forgeron]

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

[Jeremy Chadwick]

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,   

RE: kern/165903: mbuf leak

[Chris Forgeron]

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
none0@pci0:0

Re: kern/165903: mbuf leak

[Jeremy Chadwick]

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 

auditdistd user preventing installkernel

[Tom Evans]

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"