Re: Call for FreeBSD 2014Q1 (January-March) Status Reports

[Gabor Pali]

Dear FreeBSD Community,

Please note that the submission date for the 2014Q1 aka. January to
March 2014 Quarterly Status Reports is, April 7th, 2014, only 1 week
away.  Please consult my earlier message for the details:

2014-03-08 10:24 GMT+01:00 Gabor Pali :
> They do not have to be very long -- basically they may be about
> anything that lets people know what is going on around the FreeBSD
> Project.  Submission of reports is not restricted to committers:
> Anyone who is doing anything interesting and FreeBSD-related can (and
> therefore encouraged to) write one!
>
> The preferred and easiest submission method is to use the XML
> generator [1] with the result emailed as an attachment to us, that is,
> mont...@freebsd.org [2].  There is also an XML template [3] which can
> be filled out manually and attached if preferred.  For the expected
> content and style, please study our guidelines on how to write a good
> status report [4].  If you are still unsure what constitutes a good
> status report, check out the last issue [5].
>
> To enable compilation and publication of the quarterly report as soon
> as possible for the April 7th deadline, please be prompt with any
> report submissions you may have.
>
> We are looking forward to all of your 2014Q1 reports!
>
> Thanks,
> Gabor
>
>
> [1] http://www.freebsd.org/cgi/monthly.cgi
> [2] mailto:mont...@freebsd.org
> [3] http://www.freebsd.org/news/status/report-sample.xml
> [4] http://www.freebsd.org/news/status/howto.html
> [5] http://www.freebsd.org/news/status/report-2013-10-2013-12.html
___
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

[FreeBSD Tinderbox]

TB --- 2014-03-31 04:00:40 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-03-31 04:00:40 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-03-31 04:00:40 - starting HEAD tinderbox run for i386/i386
TB --- 2014-03-31 04:00:40 - cleaning the object tree
TB --- 2014-03-31 04:00:40 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-03-31 04:00:45 - At svn revision 263963
TB --- 2014-03-31 04:00:46 - building world
TB --- 2014-03-31 04:00:46 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 04:00:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 04:00:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 04:00:46 - SRCCONF=/dev/null
TB --- 2014-03-31 04:00:46 - TARGET=i386
TB --- 2014-03-31 04:00:46 - TARGET_ARCH=i386
TB --- 2014-03-31 04:00:46 - TZ=UTC
TB --- 2014-03-31 04:00:46 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 04:00:46 - cd /src
TB --- 2014-03-31 04:00:46 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Mar 31 04:00:53 UTC 2014
>>> 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 Mon Mar 31 07:30:25 UTC 2014
TB --- 2014-03-31 07:30:25 - generating LINT kernel config
TB --- 2014-03-31 07:30:25 - cd /src/sys/i386/conf
TB --- 2014-03-31 07:30:25 - /usr/bin/make -B LINT
TB --- 2014-03-31 07:30:25 - cd /src/sys/i386/conf
TB --- 2014-03-31 07:30:25 - /obj/i386.i386/src/tmp/legacy/usr/sbin/config -m 
LINT
TB --- 2014-03-31 07:30:25 - building LINT kernel
TB --- 2014-03-31 07:30:25 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 07:30:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 07:30:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 07:30:25 - SRCCONF=/dev/null
TB --- 2014-03-31 07:30:25 - TARGET=i386
TB --- 2014-03-31 07:30:25 - TARGET_ARCH=i386
TB --- 2014-03-31 07:30:25 - TZ=UTC
TB --- 2014-03-31 07:30:25 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 07:30:25 - cd /src
TB --- 2014-03-31 07:30:25 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Mar 31 07:30:25 UTC 2014
>>> 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
[...]
 ^
/src/sys/contrib/dev/acpica/include/acoutput.h:310:69: note: expanded from 
macro 'ACPI_DO_DEBUG_PRINT'
Function (Level, Line, Filename, Modulename, Component, 
__VA_ARGS__); \
^
/src/sys/contrib/dev/acpica/include/acoutput.h:294:44: note: expanded from 
macro 'ACPI_DO_WHILE0'
#define ACPI_DO_WHILE0(a)   do a while(0)
   ^
7 errors generated.
*** Error code 1

Stop.
bmake[1]: stopped in /obj/i386.i386/src/sys/LINT
*** Error code 1

Stop.
bmake: stopped in /src
*** [buildkernel] Error code 1

Stop in /src.
TB --- 2014-03-31 07:39:27 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2014-03-31 07:39:27 - ERROR: failed to build LINT kernel
TB --- 2014-03-31 07:39:27 - 10801.73 user 1549.50 system 13127.09 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"

[head tinderbox] failure on amd64/amd64

[FreeBSD Tinderbox]

TB --- 2014-03-31 04:00:40 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-03-31 04:00:40 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-03-31 04:00:40 - starting HEAD tinderbox run for amd64/amd64
TB --- 2014-03-31 04:00:40 - cleaning the object tree
TB --- 2014-03-31 04:00:40 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-03-31 04:00:45 - At svn revision 263963
TB --- 2014-03-31 04:00:46 - building world
TB --- 2014-03-31 04:00:46 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 04:00:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 04:00:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 04:00:46 - SRCCONF=/dev/null
TB --- 2014-03-31 04:00:46 - TARGET=amd64
TB --- 2014-03-31 04:00:46 - TARGET_ARCH=amd64
TB --- 2014-03-31 04:00:46 - TZ=UTC
TB --- 2014-03-31 04:00:46 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 04:00:46 - cd /src
TB --- 2014-03-31 04:00:46 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Mar 31 04:00:53 UTC 2014
>>> 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 Mon Mar 31 08:09:13 UTC 2014
TB --- 2014-03-31 08:09:13 - generating LINT kernel config
TB --- 2014-03-31 08:09:13 - cd /src/sys/amd64/conf
TB --- 2014-03-31 08:09:13 - /usr/bin/make -B LINT
TB --- 2014-03-31 08:09:13 - cd /src/sys/amd64/conf
TB --- 2014-03-31 08:09:13 - /obj/amd64.amd64/src/tmp/legacy/usr/sbin/config -m 
LINT
TB --- 2014-03-31 08:09:13 - building LINT kernel
TB --- 2014-03-31 08:09:13 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 08:09:13 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 08:09:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 08:09:13 - SRCCONF=/dev/null
TB --- 2014-03-31 08:09:13 - TARGET=amd64
TB --- 2014-03-31 08:09:13 - TARGET_ARCH=amd64
TB --- 2014-03-31 08:09:13 - TZ=UTC
TB --- 2014-03-31 08:09:13 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 08:09:13 - cd /src
TB --- 2014-03-31 08:09:13 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Mar 31 08:09:13 UTC 2014
>>> 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
[...]
 ^
/src/sys/contrib/dev/acpica/include/acoutput.h:310:69: note: expanded from 
macro 'ACPI_DO_DEBUG_PRINT'
Function (Level, Line, Filename, Modulename, Component, 
__VA_ARGS__); \
^
/src/sys/contrib/dev/acpica/include/acoutput.h:294:44: note: expanded from 
macro 'ACPI_DO_WHILE0'
#define ACPI_DO_WHILE0(a)   do a while(0)
   ^
6 errors generated.
*** Error code 1

Stop.
bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT
*** Error code 1

Stop.
bmake: stopped in /src
*** [buildkernel] Error code 1

Stop in /src.
TB --- 2014-03-31 08:16:53 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2014-03-31 08:16:53 - ERROR: failed to build LINT kernel
TB --- 2014-03-31 08:16:53 - 12444.62 user 1988.95 system 15373.00 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 ia64/ia64

[FreeBSD Tinderbox]

TB --- 2014-03-31 08:16:54 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-03-31 08:16:54 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-03-31 08:16:54 - starting HEAD tinderbox run for ia64/ia64
TB --- 2014-03-31 08:16:54 - cleaning the object tree
TB --- 2014-03-31 08:16:54 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-03-31 08:16:57 - At svn revision 263963
TB --- 2014-03-31 08:16:58 - building world
TB --- 2014-03-31 08:16:58 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 08:16:58 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 08:16:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 08:16:58 - SRCCONF=/dev/null
TB --- 2014-03-31 08:16:58 - TARGET=ia64
TB --- 2014-03-31 08:16:58 - TARGET_ARCH=ia64
TB --- 2014-03-31 08:16:58 - TZ=UTC
TB --- 2014-03-31 08:16:58 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 08:16:58 - cd /src
TB --- 2014-03-31 08:16:58 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Mar 31 08:17:05 UTC 2014
>>> 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 Mon Mar 31 09:53:14 UTC 2014
TB --- 2014-03-31 09:53:14 - generating LINT kernel config
TB --- 2014-03-31 09:53:14 - cd /src/sys/ia64/conf
TB --- 2014-03-31 09:53:14 - /usr/bin/make -B LINT
TB --- 2014-03-31 09:53:14 - cd /src/sys/ia64/conf
TB --- 2014-03-31 09:53:14 - /obj/ia64.ia64/src/tmp/legacy/usr/sbin/config -m 
LINT
TB --- 2014-03-31 09:53:14 - building LINT kernel
TB --- 2014-03-31 09:53:14 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 09:53:14 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 09:53:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 09:53:14 - SRCCONF=/dev/null
TB --- 2014-03-31 09:53:14 - TARGET=ia64
TB --- 2014-03-31 09:53:14 - TARGET_ARCH=ia64
TB --- 2014-03-31 09:53:14 - TZ=UTC
TB --- 2014-03-31 09:53:14 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 09:53:14 - cd /src
TB --- 2014-03-31 09:53:14 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Mar 31 09:53:14 UTC 2014
>>> 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 -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 
-mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/acpica/acpi_perf.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 -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 
-mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/acpica/acpi_powerres.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 -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 
-mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/acpica/acpi_quirk.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/a

RE: Call for testers: SNMPv3 support for bsnmpd(1)

[Marciano, Anthony]

Thanks Harti.

I did get the basic V3 configuration working in that I could walk the mib using 
authorization and encryption.

If Shteryana has the time, maybe he would be able to provide me with some 
information needed to configure and test V3 traps.

I don't have his e-mail so if you could forward this to him I would appreciate 
it.

Thanks!

Tony

-Original Message-
From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de] 
Sent: Sunday, March 30, 2014 8:22 AM
To: Marciano, Anthony
Cc: freebsd-current@freebsd.org; tomaro...@gmail.com
Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1)

Hi Anthony,

On Fri, 28 Mar 2014, Marciano, Anthony wrote:

MA>I've been tasked to get bsnmpd V3 working for my company. The post 
MA>referenced in the subject above gave me some insights but I'm still 
MA>stuck and was wondering if you would take the time to answer some 
MA>questions. I'm a snmpV3 newbie and have never worked with bsnmpd. I 
MA>have worked minimally with net-snmp V2.
MA>
MA>First, is there a document listing all of the configuration options 
MA>in the snmpd.confg file? It appears to differ from other packages 
MA>such as net-snmp.


I can answer only this question - I'm not very familiar with SNMPv3, but 
Shteryana should be able to help.

No, there is no document with all the setting. The reason is simple: the config 
file is just a set of SNMP SET PDUs executed at startup, SIGHUP or module load. 
The file is segmented into sections by %name lines with all segments having the 
same name beeing put together. At the begin of the file there is an implicit 
%snmpd line.

Each section is a SET PDU. The %snmpd PDU is executed on startup and SIGHUP, 
all other sections are executed when the corresponding module is beeing loaded 
or on SIGHUP if that module is already loaded when the SIGHUP occures.

So any writeable or creatable MIB variable can be put into the configuration 
file.

harti
___
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: Call for testers: SNMPv3 support for bsnmpd(1)

[Bjoern A. Zeeb]

On 31 Mar 2014, at 12:14 , Marciano, Anthony  wrote:

> Thanks Harti.
> 
> I did get the basic V3 configuration working in that I could walk the mib 
> using authorization and encryption.
> 
> If Shteryana has the time, maybe he would be able to provide me with some 
> information needed to configure and test V3 traps.
> 
> I don't have his e-mail so if you could forward this to him I would 
> appreciate it.

I’ve put her on Cc:


> -Original Message-
> From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de] 
> Sent: Sunday, March 30, 2014 8:22 AM
> To: Marciano, Anthony
> Cc: freebsd-current@freebsd.org; tomaro...@gmail.com
> Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1)
> 
> Hi Anthony,
> 
> On Fri, 28 Mar 2014, Marciano, Anthony wrote:
> 
> MA>I've been tasked to get bsnmpd V3 working for my company. The post 
> MA>referenced in the subject above gave me some insights but I'm still 
> MA>stuck and was wondering if you would take the time to answer some 
> MA>questions. I'm a snmpV3 newbie and have never worked with bsnmpd. I 
> MA>have worked minimally with net-snmp V2.
> MA>
> MA>First, is there a document listing all of the configuration options 
> MA>in the snmpd.confg file? It appears to differ from other packages 
> MA>such as net-snmp.
> 
> 
> I can answer only this question - I'm not very familiar with SNMPv3, but 
> Shteryana should be able to help.
> 
> No, there is no document with all the setting. The reason is simple: the 
> config file is just a set of SNMP SET PDUs executed at startup, SIGHUP or 
> module load. The file is segmented into sections by %name lines with all 
> segments having the same name beeing put together. At the begin of the file 
> there is an implicit %snmpd line.
> 
> Each section is a SET PDU. The %snmpd PDU is executed on startup and SIGHUP, 
> all other sections are executed when the corresponding module is beeing 
> loaded or on SIGHUP if that module is already loaded when the SIGHUP occures.
> 
> So any writeable or creatable MIB variable can be put into the configuration 
> file.
> 
> harti
> ___
> 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"

— 
Bjoern A. Zeeb ? ??? ??? ??:
'??? ???  ??  ??? ?? ?? ??? ??? ??? ? ? 
?? ?? ? ',  ? ?, "??? ? ?? ?", ?.???

___
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: Call for testers: SNMPv3 support for bsnmpd(1)

[Marciano, Anthony]

Many thanks!

-Original Message-
From: Bjoern A. Zeeb [mailto:bzeeb-li...@lists.zabbadoz.net] 
Sent: Monday, March 31, 2014 9:07 AM
To: Marciano, Anthony
Cc: Hartmut Brandt; freebsd-current@freebsd.org; tomaro...@gmail.com; 
syr...@freebsd.org
Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1)

On 31 Mar 2014, at 12:14 , Marciano, Anthony  wrote:

> Thanks Harti.
> 
> I did get the basic V3 configuration working in that I could walk the mib 
> using authorization and encryption.
> 
> If Shteryana has the time, maybe he would be able to provide me with some 
> information needed to configure and test V3 traps.
> 
> I don't have his e-mail so if you could forward this to him I would 
> appreciate it.

I've put her on Cc:


> -Original Message-
> From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de]
> Sent: Sunday, March 30, 2014 8:22 AM
> To: Marciano, Anthony
> Cc: freebsd-current@freebsd.org; tomaro...@gmail.com
> Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1)
> 
> Hi Anthony,
> 
> On Fri, 28 Mar 2014, Marciano, Anthony wrote:
> 
> MA>I've been tasked to get bsnmpd V3 working for my company. The post 
> MA>referenced in the subject above gave me some insights but I'm still 
> MA>stuck and was wondering if you would take the time to answer some 
> MA>questions. I'm a snmpV3 newbie and have never worked with bsnmpd. I 
> MA>have worked minimally with net-snmp V2.
> MA>
> MA>First, is there a document listing all of the configuration options 
> MA>in the snmpd.confg file? It appears to differ from other packages 
> MA>such as net-snmp.
> 
> 
> I can answer only this question - I'm not very familiar with SNMPv3, but 
> Shteryana should be able to help.
> 
> No, there is no document with all the setting. The reason is simple: the 
> config file is just a set of SNMP SET PDUs executed at startup, SIGHUP or 
> module load. The file is segmented into sections by %name lines with all 
> segments having the same name beeing put together. At the begin of the file 
> there is an implicit %snmpd line.
> 
> Each section is a SET PDU. The %snmpd PDU is executed on startup and SIGHUP, 
> all other sections are executed when the corresponding module is beeing 
> loaded or on SIGHUP if that module is already loaded when the SIGHUP occures.
> 
> So any writeable or creatable MIB variable can be put into the configuration 
> file.
> 
> harti
> ___
> 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"

- 
Bjoern A. Zeeb ? ??? ??? ??:
'??? ???  ??  ??? ?? ?? ??? ??? ??? ? ? 
?? ?? ? ',  ? ?, "??? ? ?? ?", ?.???

___
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: Call for testers: SNMPv3 support for bsnmpd(1)

[Shteryana Shopova]

Hi all,

The modules implementing SNMPv3 in bsnmpd(1) are snmp_usm(3),
snmp_vacm(3) and snmp_target(3) all based on standard RFC. snmp_usm(3)
handles v1/v2c and v3 user configuration including user name,
auth/priv protocol type and relevant keys. snmp_vacm(3) allows
restricting users to specific parts of the MIB tree, and
snmp_target(3) allows configuring destination hosts for SNMP traps and
notifications.

To get SNMPv3 traps, snmp_target(3) module needs to be loaded - the
default /etc/snmpd.config file contains commented out example
configuration, looking at snmp_target(3) man page should give some
hints too - basicly you need to set at least one entry in
snmpTargetAddrTable containing relevant connection parameters for the
host that should receive the notifications, one snmpTargetParamsTable
specifying the USM user credentials that should be used and one entry
in  snmpNotifyTable specifying for which tag whether a trap or
notification should be sent.
RFC 3413 also contains examples on how to fill in the SNMP-NOTIFICATION-MIB .

The standard SNMPv3 modules are somewhat too complicated for most
configurations though, so I've had the idea to implement a private
Begemot module with much simpler configuration that will fill
automatically the standard MIB trees with v3 user configuration but I
haven't gotten to actually implementing it yet.

cheers,
Shteryana


On Mon, Mar 31, 2014 at 4:07 PM, Bjoern A. Zeeb
 wrote:
> On 31 Mar 2014, at 12:14 , Marciano, Anthony  wrote:
>
>> Thanks Harti.
>>
>> I did get the basic V3 configuration working in that I could walk the mib 
>> using authorization and encryption.
>>
>> If Shteryana has the time, maybe he would be able to provide me with some 
>> information needed to configure and test V3 traps.
>>
>> I don't have his e-mail so if you could forward this to him I would 
>> appreciate it.
>
> I’ve put her on Cc:
>
>
>> -Original Message-
>> From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de]
>> Sent: Sunday, March 30, 2014 8:22 AM
>> To: Marciano, Anthony
>> Cc: freebsd-current@freebsd.org; tomaro...@gmail.com
>> Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1)
>>
>> Hi Anthony,
>>
>> On Fri, 28 Mar 2014, Marciano, Anthony wrote:
>>
>> MA>I've been tasked to get bsnmpd V3 working for my company. The post
>> MA>referenced in the subject above gave me some insights but I'm still
>> MA>stuck and was wondering if you would take the time to answer some
>> MA>questions. I'm a snmpV3 newbie and have never worked with bsnmpd. I
>> MA>have worked minimally with net-snmp V2.
>> MA>
>> MA>First, is there a document listing all of the configuration options
>> MA>in the snmpd.confg file? It appears to differ from other packages
>> MA>such as net-snmp.
>>
>>
>> I can answer only this question - I'm not very familiar with SNMPv3, but 
>> Shteryana should be able to help.
>>
>> No, there is no document with all the setting. The reason is simple: the 
>> config file is just a set of SNMP SET PDUs executed at startup, SIGHUP or 
>> module load. The file is segmented into sections by %name lines with all 
>> segments having the same name beeing put together. At the begin of the file 
>> there is an implicit %snmpd line.
>>
>> Each section is a SET PDU. The %snmpd PDU is executed on startup and SIGHUP, 
>> all other sections are executed when the corresponding module is beeing 
>> loaded or on SIGHUP if that module is already loaded when the SIGHUP occures.
>>
>> So any writeable or creatable MIB variable can be put into the configuration 
>> file.
>>
>> harti
>> ___
>> 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"
>
> —
> Bjoern A. Zeeb ? ??? ??? ??:
> '??? ???  ??  ??? ?? ?? ??? ??? ??? ? ? 
> ?? ?? ? ',  ? ?, "??? ? ?? ?", ?.???
>
___
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: sendmail Broken Pipe Error

[Kevin Oberman]

On Sun, Mar 30, 2014 at 12:44 PM, Allan Jude  wrote:

> On 2014-03-30 15:31, Willy Offermans wrote:
> > Hello Rick and FreeBSD friends,
> >
> > How can I save this setting in the rc.conf file to disable TSO at
> startup?
> >
>
> add -tso to the ifconfig line:
>
> ifconfig_bge0="inet  netmask  -tso"
> --
> Allan Jude
>
>
I'd recommend that people stop using the long obsolete netmask form of
ifconfig, especially when making suggestions to others. CIDR notation is
about two decades old now.

ifconfig_bge0="inet  -tso"

-- 
R. Kevin Oberman, Network Engineer, Retired
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"

RE: Call for testers: SNMPv3 support for bsnmpd(1)

[Marciano, Anthony]

Hi Shteryana,

Thank you for your quick response.

Currently, we are just looking to monitor standard objects such as interfaces 
and send traps accordingly.
Would it be possible to provide a trap example of what needs to be added to the 
snmpd.config file to monitor an object and have it sent via V3?

I've searched for this information and read through various RFCs but have not 
discovered any bsnmpd specific trap syntax and/or examples.

Thanks you.

Tony

-Original Message-
From: shtery...@gmail.com [mailto:shtery...@gmail.com] On Behalf Of Shteryana 
Shopova
Sent: Monday, March 31, 2014 10:10 AM
To: Bjoern A. Zeeb
Cc: Marciano, Anthony; Hartmut Brandt; freebsd-current@freebsd.org; 
tomaro...@gmail.com
Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1)

Hi all,

The modules implementing SNMPv3 in bsnmpd(1) are snmp_usm(3),
snmp_vacm(3) and snmp_target(3) all based on standard RFC. snmp_usm(3) handles 
v1/v2c and v3 user configuration including user name, auth/priv protocol type 
and relevant keys. snmp_vacm(3) allows restricting users to specific parts of 
the MIB tree, and
snmp_target(3) allows configuring destination hosts for SNMP traps and 
notifications.

To get SNMPv3 traps, snmp_target(3) module needs to be loaded - the default 
/etc/snmpd.config file contains commented out example configuration, looking at 
snmp_target(3) man page should give some hints too - basicly you need to set at 
least one entry in snmpTargetAddrTable containing relevant connection 
parameters for the host that should receive the notifications, one 
snmpTargetParamsTable specifying the USM user credentials that should be used 
and one entry in  snmpNotifyTable specifying for which tag whether a trap or 
notification should be sent.
RFC 3413 also contains examples on how to fill in the SNMP-NOTIFICATION-MIB .

The standard SNMPv3 modules are somewhat too complicated for most 
configurations though, so I've had the idea to implement a private Begemot 
module with much simpler configuration that will fill automatically the 
standard MIB trees with v3 user configuration but I haven't gotten to actually 
implementing it yet.

cheers,
Shteryana


On Mon, Mar 31, 2014 at 4:07 PM, Bjoern A. Zeeb 
 wrote:
> On 31 Mar 2014, at 12:14 , Marciano, Anthony  wrote:
>
>> Thanks Harti.
>>
>> I did get the basic V3 configuration working in that I could walk the mib 
>> using authorization and encryption.
>>
>> If Shteryana has the time, maybe he would be able to provide me with some 
>> information needed to configure and test V3 traps.
>>
>> I don't have his e-mail so if you could forward this to him I would 
>> appreciate it.
>
> I’ve put her on Cc:
>
>
>> -Original Message-
>> From: Hartmut Brandt [mailto:hartmut.bra...@dlr.de]
>> Sent: Sunday, March 30, 2014 8:22 AM
>> To: Marciano, Anthony
>> Cc: freebsd-current@freebsd.org; tomaro...@gmail.com
>> Subject: Re: Call for testers: SNMPv3 support for bsnmpd(1)
>>
>> Hi Anthony,
>>
>> On Fri, 28 Mar 2014, Marciano, Anthony wrote:
>>
>> MA>I've been tasked to get bsnmpd V3 working for my company. The post 
>> MA>referenced in the subject above gave me some insights but I'm 
>> MA>still stuck and was wondering if you would take the time to answer 
>> MA>some questions. I'm a snmpV3 newbie and have never worked with 
>> MA>bsnmpd. I have worked minimally with net-snmp V2.
>> MA>
>> MA>First, is there a document listing all of the configuration 
>> MA>options in the snmpd.confg file? It appears to differ from other 
>> MA>packages such as net-snmp.
>>
>>
>> I can answer only this question - I'm not very familiar with SNMPv3, but 
>> Shteryana should be able to help.
>>
>> No, there is no document with all the setting. The reason is simple: the 
>> config file is just a set of SNMP SET PDUs executed at startup, SIGHUP or 
>> module load. The file is segmented into sections by %name lines with all 
>> segments having the same name beeing put together. At the begin of the file 
>> there is an implicit %snmpd line.
>>
>> Each section is a SET PDU. The %snmpd PDU is executed on startup and SIGHUP, 
>> all other sections are executed when the corresponding module is beeing 
>> loaded or on SIGHUP if that module is already loaded when the SIGHUP occures.
>>
>> So any writeable or creatable MIB variable can be put into the configuration 
>> file.
>>
>> harti
>> ___
>> 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"
>
> —
> Bjoern A. Zeeb ? ??? ??? ??:
> '??? ???  ??  ??? ?? ?? ??? ??? ??? ? ? 
> ?? ?? ? ',  ? ?, "??? ? ?? ?", ?.???
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

TB --- 2014-03-31 15:30:23 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-03-31 15:30:23 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-03-31 15:30:23 - starting HEAD tinderbox run for i386/i386
TB --- 2014-03-31 15:30:23 - cleaning the object tree
TB --- 2014-03-31 15:32:53 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-03-31 15:32:59 - At svn revision 263972
TB --- 2014-03-31 15:33:00 - building world
TB --- 2014-03-31 15:33:00 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 15:33:00 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 15:33:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 15:33:00 - SRCCONF=/dev/null
TB --- 2014-03-31 15:33:00 - TARGET=i386
TB --- 2014-03-31 15:33:00 - TARGET_ARCH=i386
TB --- 2014-03-31 15:33:00 - TZ=UTC
TB --- 2014-03-31 15:33:00 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 15:33:00 - cd /src
TB --- 2014-03-31 15:33:00 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Mar 31 15:33:07 UTC 2014
>>> 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 Mon Mar 31 18:59:52 UTC 2014
TB --- 2014-03-31 18:59:52 - generating LINT kernel config
TB --- 2014-03-31 18:59:52 - cd /src/sys/i386/conf
TB --- 2014-03-31 18:59:52 - /usr/bin/make -B LINT
TB --- 2014-03-31 18:59:52 - cd /src/sys/i386/conf
TB --- 2014-03-31 18:59:52 - /obj/i386.i386/src/tmp/legacy/usr/sbin/config -m 
LINT
TB --- 2014-03-31 18:59:52 - building LINT kernel
TB --- 2014-03-31 18:59:52 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 18:59:52 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 18:59:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 18:59:52 - SRCCONF=/dev/null
TB --- 2014-03-31 18:59:52 - TARGET=i386
TB --- 2014-03-31 18:59:52 - TARGET_ARCH=i386
TB --- 2014-03-31 18:59:52 - TZ=UTC
TB --- 2014-03-31 18:59:52 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 18:59:52 - cd /src
TB --- 2014-03-31 18:59:52 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Mar 31 18:59:52 UTC 2014
>>> 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
[...]
 ^
/src/sys/contrib/dev/acpica/include/acoutput.h:310:69: note: expanded from 
macro 'ACPI_DO_DEBUG_PRINT'
Function (Level, Line, Filename, Modulename, Component, 
__VA_ARGS__); \
^
/src/sys/contrib/dev/acpica/include/acoutput.h:294:44: note: expanded from 
macro 'ACPI_DO_WHILE0'
#define ACPI_DO_WHILE0(a)   do a while(0)
   ^
7 errors generated.
*** Error code 1

Stop.
bmake[1]: stopped in /obj/i386.i386/src/sys/LINT
*** Error code 1

Stop.
bmake: stopped in /src
*** [buildkernel] Error code 1

Stop in /src.
TB --- 2014-03-31 19:08:54 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2014-03-31 19:08:54 - ERROR: failed to build LINT kernel
TB --- 2014-03-31 19:08:54 - 10796.46 user 1537.30 system 13110.77 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"

Re: [head tinderbox] failure on i386/i386

[Warner Losh]

On Mar 31, 2014, at 1:08 PM, FreeBSD Tinderbox  wrote:
> [...]
> ^
> /src/sys/contrib/dev/acpica/include/acoutput.h:310:69: note: expanded from 
> macro 'ACPI_DO_DEBUG_PRINT'
>Function (Level, Line, Filename, Modulename, Component, 
> __VA_ARGS__); \
>^
> /src/sys/contrib/dev/acpica/include/acoutput.h:294:44: note: expanded from 
> macro 'ACPI_DO_WHILE0'
> #define ACPI_DO_WHILE0(a)   do a while(0)
>   ^

I think this one is mine. Will have a fix shortly.

Warner


___
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

[FreeBSD Tinderbox]

TB --- 2014-03-31 15:30:23 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-03-31 15:30:23 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-03-31 15:30:23 - starting HEAD tinderbox run for amd64/amd64
TB --- 2014-03-31 15:30:24 - cleaning the object tree
TB --- 2014-03-31 15:33:17 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-03-31 15:33:20 - At svn revision 263972
TB --- 2014-03-31 15:33:21 - building world
TB --- 2014-03-31 15:33:21 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 15:33:21 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 15:33:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 15:33:21 - SRCCONF=/dev/null
TB --- 2014-03-31 15:33:21 - TARGET=amd64
TB --- 2014-03-31 15:33:21 - TARGET_ARCH=amd64
TB --- 2014-03-31 15:33:21 - TZ=UTC
TB --- 2014-03-31 15:33:21 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 15:33:21 - cd /src
TB --- 2014-03-31 15:33:21 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Mar 31 15:33:28 UTC 2014
>>> 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 Mon Mar 31 19:38:32 UTC 2014
TB --- 2014-03-31 19:38:32 - generating LINT kernel config
TB --- 2014-03-31 19:38:32 - cd /src/sys/amd64/conf
TB --- 2014-03-31 19:38:32 - /usr/bin/make -B LINT
TB --- 2014-03-31 19:38:32 - cd /src/sys/amd64/conf
TB --- 2014-03-31 19:38:32 - /obj/amd64.amd64/src/tmp/legacy/usr/sbin/config -m 
LINT
TB --- 2014-03-31 19:38:32 - building LINT kernel
TB --- 2014-03-31 19:38:32 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 19:38:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 19:38:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 19:38:32 - SRCCONF=/dev/null
TB --- 2014-03-31 19:38:32 - TARGET=amd64
TB --- 2014-03-31 19:38:32 - TARGET_ARCH=amd64
TB --- 2014-03-31 19:38:32 - TZ=UTC
TB --- 2014-03-31 19:38:32 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 19:38:32 - cd /src
TB --- 2014-03-31 19:38:32 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Mar 31 19:38:32 UTC 2014
>>> 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
[...]
 ^
/src/sys/contrib/dev/acpica/include/acoutput.h:310:69: note: expanded from 
macro 'ACPI_DO_DEBUG_PRINT'
Function (Level, Line, Filename, Modulename, Component, 
__VA_ARGS__); \
^
/src/sys/contrib/dev/acpica/include/acoutput.h:294:44: note: expanded from 
macro 'ACPI_DO_WHILE0'
#define ACPI_DO_WHILE0(a)   do a while(0)
   ^
6 errors generated.
*** Error code 1

Stop.
bmake[1]: stopped in /obj/amd64.amd64/src/sys/LINT
*** Error code 1

Stop.
bmake: stopped in /src
*** [buildkernel] Error code 1

Stop in /src.
TB --- 2014-03-31 19:45:49 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2014-03-31 19:45:49 - ERROR: failed to build LINT kernel
TB --- 2014-03-31 19:45:49 - 12431.71 user 1997.68 system 15325.57 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 ia64/ia64

[FreeBSD Tinderbox]

TB --- 2014-03-31 19:45:49 - tinderbox 2.21 running on freebsd-current.sentex.ca
TB --- 2014-03-31 19:45:49 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE 
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-03-31 19:45:49 - starting HEAD tinderbox run for ia64/ia64
TB --- 2014-03-31 19:45:49 - cleaning the object tree
TB --- 2014-03-31 19:46:49 - /usr/local/bin/svn stat --no-ignore /src
TB --- 2014-03-31 19:46:53 - At svn revision 263972
TB --- 2014-03-31 19:46:54 - building world
TB --- 2014-03-31 19:46:54 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 19:46:54 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 19:46:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 19:46:54 - SRCCONF=/dev/null
TB --- 2014-03-31 19:46:54 - TARGET=ia64
TB --- 2014-03-31 19:46:54 - TARGET_ARCH=ia64
TB --- 2014-03-31 19:46:54 - TZ=UTC
TB --- 2014-03-31 19:46:54 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 19:46:54 - cd /src
TB --- 2014-03-31 19:46:54 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Mar 31 19:47:01 UTC 2014
>>> 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 Mon Mar 31 21:23:33 UTC 2014
TB --- 2014-03-31 21:23:33 - generating LINT kernel config
TB --- 2014-03-31 21:23:33 - cd /src/sys/ia64/conf
TB --- 2014-03-31 21:23:33 - /usr/bin/make -B LINT
TB --- 2014-03-31 21:23:33 - cd /src/sys/ia64/conf
TB --- 2014-03-31 21:23:33 - /obj/ia64.ia64/src/tmp/legacy/usr/sbin/config -m 
LINT
TB --- 2014-03-31 21:23:33 - building LINT kernel
TB --- 2014-03-31 21:23:33 - CROSS_BUILD_TESTING=YES
TB --- 2014-03-31 21:23:33 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-03-31 21:23:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-03-31 21:23:33 - SRCCONF=/dev/null
TB --- 2014-03-31 21:23:33 - TARGET=ia64
TB --- 2014-03-31 21:23:33 - TARGET_ARCH=ia64
TB --- 2014-03-31 21:23:33 - TZ=UTC
TB --- 2014-03-31 21:23:33 - __MAKE_CONF=/dev/null
TB --- 2014-03-31 21:23:33 - cd /src
TB --- 2014-03-31 21:23:33 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Mar 31 21:23:33 UTC 2014
>>> 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 -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 
-mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/acpica/acpi_perf.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 -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 
-mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/acpica/acpi_powerres.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 -I/src/sys/contrib/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 
-mfixed-range=f32-f127 -fpic -ffreestanding -Werror  
/src/sys/dev/acpica/acpi_quirk.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/a

Re: ZFS panic in -CURRENT

[R. Tyler Croy]

Bumping this with more details

On Fri, 28 Mar 2014 09:53:32 -0700
R Tyler Croy  wrote:

> Apologies for the rough format here, I had to take a picture of this
> failure because I didn't know what else to do.
> 
> 
> 
> I'm building off of the GitHub freebsd.git mirror here, and the
> latest commit in the tree is neel@'s "Add an ioctl to suspend.."
> 
> My dmesg/pciconf are here:
> https://gist.github.com/rtyler/1faa854dff7c4396d9e8


As linked before, the dmesg and `pciconf -lv` output can be found here:


Also in addition to the photo from before of the panic, here's another
reproduction photo:


I'm running -CURRENT as of r263881 right now, with a custom kernel
which is built on top of the VT kernel
(https://github.com/rtyler/freebsd/blob/5e324960f1f2b7079de369204fe228db4a2ec99d/sys/amd64/conf/KIWI)

I'm able to get this panic *consistently* whenever a process accesses
my maildir folder which I sync with the mbsync program (isync package),
such as `mbsync personal` or when I back up the maildir with duplicity.
The commonality seems to be listing or accessing portions of this file
tree. Curiously enough it only seems to be isolated to that single
portion of the filesystem tree.

The zpool is also clean as far as errors go:

> [16:11:03] tyler:freebsd git:(master*) $ zpool status zroot
>   pool: zroot
>  state: ONLINE
> status: Some supported features are not enabled on the pool. The pool
> can still be used, but some features are unavailable.
> action: Enable all features using 'zpool upgrade'. Once this is done,
> the pool may no longer be accessible by software that does not
> support the features. See zpool-features(7) for details.
>   scan: scrub repaired 0 in 0h18m with 0 errors on Fri Mar 28 11:55:03
> 2014 config:
> 
> NAME  STATE READ WRITE CKSUM
> zroot ONLINE   0 0 0
>   ada0p3.eli  ONLINE   0 0 0
> 
> errors: No known data errors
> [16:19:57] tyler:freebsd git:(master*) $ 


I'm not sure what other data would be useful here, I can consistently
see the panic, but this data is highly personal, so I'm not sure how
much of a "repro case" I can give folks. :(

Cheers
-- 

- R. Tyler Croy

--
 Code: 
  Chatter: 

  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--
___
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: Re: UDP Lite support

[Kevin Lo]

On 2014/03/28 00:21, John Baldwin wrote:

On Thursday, March 27, 2014 5:32:16 am Kevin Lo wrote:

Are you interested in working on these and report back?

The revised patch is available at:
http://people.freebsd.org/~kevlo/udplite.diff

Thank you for your suggestions.


A few suggestions:

- I would just drop the INP lock and return EOPNOTSUPP directly rather
than using goto's to 'bad_setoptname' and 'bad_getoptname' so the
UDP-lite options are self-contained.

Fixed.

Thanks.


- I'm not a super big fan of all the udp_common_* macros only because
I think it obfuscates things.  At the very least, please move these
things out of the header and into udp_usrreq.c so they are closer
to the implementation.  I would even suggest making them inline
functions instead of macros.

Okay, I removed two udp_common_* macros.  I also renamed udp_common_init()
to udp_udplite_init() and moved it into udp_usrreq.c.  Using a macro here
to follow the style used in SCTP (sctp_os_bsd.h).

Here's a third version of the udp-lite patch:
http://people.freebsd.org/~kevlo/udplite.diff

Ok, I would say that udp_common_init() is actually a better name if you keep
the macro (which I think is fine) rather than udp_udplite_init() as the macro
is not specific to UDP Lite.  However, thanks for moving the macros out of the
header.


Thank you John.  glebius@ suggests we don't need to have two absolutely
equal uma zones since most systems don't run UDP-Lite.
If practice shows that a differentiation at zone level between UDP and
UDP-Lite PCBs is important, then it could be done later.

Following up with a fourth version of the udp-lite patch.
http://people.freebsd.org/~kevlo/udplite.diff

On top of the previous versions, this:
- removes a uma zone for udp-lite
- udp_common_ctlinput() belongs under #ifdef INET
- removes sysctl nodes for udp-lite.
- bumps version and adds my copyright.

Kevin


___
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: Re: UDP Lite support

[Joe Nosay]

On Mon, Mar 31, 2014 at 10:20 PM, Kevin Lo  wrote:

> On 2014/03/28 00:21, John Baldwin wrote:
>
>> On Thursday, March 27, 2014 5:32:16 am Kevin Lo wrote:
>>
>>> Are you interested in working on these and report back?
>>
> The revised patch is available at:
> http://people.freebsd.org/~kevlo/udplite.diff
>
 Thank you for your suggestions.
>>>
>>>  A few suggestions:

 - I would just drop the INP lock and return EOPNOTSUPP directly rather
 than using goto's to 'bad_setoptname' and 'bad_getoptname' so the
 UDP-lite options are self-contained.

>>> Fixed.
>>>
>> Thanks.
>>
>>  - I'm not a super big fan of all the udp_common_* macros only because
 I think it obfuscates things.  At the very least, please move these
 things out of the header and into udp_usrreq.c so they are closer
 to the implementation.  I would even suggest making them inline
 functions instead of macros.

>>> Okay, I removed two udp_common_* macros.  I also renamed
>>> udp_common_init()
>>> to udp_udplite_init() and moved it into udp_usrreq.c.  Using a macro here
>>> to follow the style used in SCTP (sctp_os_bsd.h).
>>>
>>> Here's a third version of the udp-lite patch:
>>> http://people.freebsd.org/~kevlo/udplite.diff
>>>
>> Ok, I would say that udp_common_init() is actually a better name if you
>> keep
>> the macro (which I think is fine) rather than udp_udplite_init() as the
>> macro
>> is not specific to UDP Lite.  However, thanks for moving the macros out
>> of the
>> header.
>>
>
> Thank you John.  glebius@ suggests we don't need to have two absolutely
> equal uma zones since most systems don't run UDP-Lite.
> If practice shows that a differentiation at zone level between UDP and
> UDP-Lite PCBs is important, then it could be done later.
>
> Following up with a fourth version of the udp-lite patch.
> http://people.freebsd.org/~kevlo/udplite.diff
>
> On top of the previous versions, this:
> - removes a uma zone for udp-lite
> - udp_common_ctlinput() belongs under #ifdef INET
> - removes sysctl nodes for udp-lite.
> - bumps version and adds my copyright.
>
> Kevin
>
>
>
Do I patch over the current src- which was already patched with version 3-
or do I just start new?
___
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: Call for testers: SNMPv3 support for bsnmpd(1)

[Hartmut Brandt]

On Mon, 31 Mar 2014, Marciano, Anthony wrote:

MA>Currently, we are just looking to monitor standard objects such as 
MA>interfaces and send traps accordingly. Would it be possible to provide 
MA>a trap example of what needs to be added to the snmpd.config file to 
MA>monitor an object and have it sent via V3?
MA>
MA>I've searched for this information and read through various RFCs but 
MA>have not discovered any bsnmpd specific trap syntax and/or examples.

Well, bsnmp can send only the standard traps currently. This is configured 
via the begemotTrapSinkTable (/usr/share/snmp/mibs/BEGEMOT-SNMPD.txt). 
Each row in the table is a trap target and all traps are sent to all 
targets in the table. I don't know, how this interacts with v3, though.

harti
___
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: UDP Lite support

[Kevin Lo]

Joe Nosay wrote:

On Mon, Mar 31, 2014 at 10:20 PM, Kevin Lo  wrote:


On 2014/03/28 00:21, John Baldwin wrote:


On Thursday, March 27, 2014 5:32:16 am Kevin Lo wrote:


Are you interested in working on these and report back?

The revised patch is available at:
http://people.freebsd.org/~kevlo/udplite.diff


Thank you for your suggestions.

  A few suggestions:

- I would just drop the INP lock and return EOPNOTSUPP directly rather
 than using goto's to 'bad_setoptname' and 'bad_getoptname' so the
 UDP-lite options are self-contained.


Fixed.


Thanks.

  - I'm not a super big fan of all the udp_common_* macros only because

 I think it obfuscates things.  At the very least, please move these
 things out of the header and into udp_usrreq.c so they are closer
 to the implementation.  I would even suggest making them inline
 functions instead of macros.


Okay, I removed two udp_common_* macros.  I also renamed
udp_common_init()
to udp_udplite_init() and moved it into udp_usrreq.c.  Using a macro here
to follow the style used in SCTP (sctp_os_bsd.h).

Here's a third version of the udp-lite patch:
http://people.freebsd.org/~kevlo/udplite.diff


Ok, I would say that udp_common_init() is actually a better name if you
keep
the macro (which I think is fine) rather than udp_udplite_init() as the
macro
is not specific to UDP Lite.  However, thanks for moving the macros out
of the
header.


Thank you John.  glebius@ suggests we don't need to have two absolutely
equal uma zones since most systems don't run UDP-Lite.
If practice shows that a differentiation at zone level between UDP and
UDP-Lite PCBs is important, then it could be done later.

Following up with a fourth version of the udp-lite patch.
http://people.freebsd.org/~kevlo/udplite.diff

On top of the previous versions, this:
 - removes a uma zone for udp-lite
 - udp_common_ctlinput() belongs under #ifdef INET
 - removes sysctl nodes for udp-lite.
 - bumps version and adds my copyright.

 Kevin




Do I patch over the current src- which was already patched with version 3-
or do I just start new?


Start new, thanks.

Kevin

___
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"

Leaving the Desktop Market

[Eitan Adler]

Hi all,

Some of you may have seen my posts entitled "Story of a Laptop User"
and "Story of a Desktop User".  For those of you who did not, it can
be a worthwhile read to see what life is like when using FreeBSD as a
desktop.  In short, it is an educational experience.  While FreeBSD
can be coerced to do the right thing, it is rarely there by default
and often doesn't work as well as we would expect.

The following are issues I haven't brought up in the past:

Battery life sucks:  it’s almost as if powerd wasn't running.  Windows
can run for five hours on my laptop while FreeBSD can barely make it
two hours.  I wonder what the key differences are?  Likely it’s that
we focus so much on performance that no one considers power.  ChromeOS
can run for 12 hours on some hardware;  why can't we make FreeBSD run
for 16?

Sound configuration lacks key documentation:  how can I automatically
change between headphones and external speakers?   You can't even do
that in middle of a song at all!  Trust me that you never want to be
staring at an HDA pin configuration.  I'll bet you couldn't even get
sound streaming to other machines working if you tried.

FreeBSD lacks vendor credibility: CUDA is unsupported.  Dropbox hasn't
released a client for FreeBSD.  Nvidia Optimus doesn't function on
FreeBSD.  Can you imagine telling someone to purchase a laptop with
the caveat: "but you won't be able to use your graphics card"?

In any case, half of our desktop support is emulation: flash and opera
only works because of the linuxulator.  There really isn't any reason
for vendors to bother supporting FreeBSD if we are just going to ape
Linux anyways.

That is why on this date I propose that we cease competing on the
desktop market.  FreeBSD should declare 2014 to be "year of the Linux
desktop" and start to rip out the pieces of the OS not needed for
server or embedded use.

Some of you may point to PCBSD and say that we have a chance, but I
must ask you: how does one flavor stand up to the thousands in the
Linux world?

Eitan Adler
___
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: Leaving the Desktop Market

[Julian Elischer]

On 4/1/14, 1:46 PM, Eitan Adler wrote:

Hi all


Hey it's not an apr 1 joke if it's true..

___
freebsd-hack...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-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: ZFS panic in -CURRENT

[Andriy Gapon]

on 01/04/2014 02:22 R. Tyler Croy said the following:
> Bumping this with more details
> 
> On Fri, 28 Mar 2014 09:53:32 -0700
> R Tyler Croy  wrote:
> 
>> Apologies for the rough format here, I had to take a picture of this
>> failure because I didn't know what else to do.
>>
>> 
>>
>> I'm building off of the GitHub freebsd.git mirror here, and the
>> latest commit in the tree is neel@'s "Add an ioctl to suspend.."
>>
>> My dmesg/pciconf are here:
>> https://gist.github.com/rtyler/1faa854dff7c4396d9e8
> 
> 
> As linked before, the dmesg and `pciconf -lv` output can be found here:
> 
> 
> Also in addition to the photo from before of the panic, here's another
> reproduction photo:
> 

Are you or have you even been running with any ZFS-related kernel patches?

> I'm running -CURRENT as of r263881 right now, with a custom kernel
> which is built on top of the VT kernel
> (https://github.com/rtyler/freebsd/blob/5e324960f1f2b7079de369204fe228db4a2ec99d/sys/amd64/conf/KIWI)
> 
> I'm able to get this panic *consistently* whenever a process accesses
> my maildir folder which I sync with the mbsync program (isync package),
> such as `mbsync personal` or when I back up the maildir with duplicity.
> The commonality seems to be listing or accessing portions of this file
> tree. Curiously enough it only seems to be isolated to that single
> portion of the filesystem tree.
> 
> The zpool is also clean as far as errors go:
> 
>> [16:11:03] tyler:freebsd git:(master*) $ zpool status zroot
>>   pool: zroot
>>  state: ONLINE
>> status: Some supported features are not enabled on the pool. The pool
>> can still be used, but some features are unavailable.
>> action: Enable all features using 'zpool upgrade'. Once this is done,
>> the pool may no longer be accessible by software that does not
>> support the features. See zpool-features(7) for details.
>>   scan: scrub repaired 0 in 0h18m with 0 errors on Fri Mar 28 11:55:03
>> 2014 config:
>>
>> NAME  STATE READ WRITE CKSUM
>> zroot ONLINE   0 0 0
>>   ada0p3.eli  ONLINE   0 0 0
>>
>> errors: No known data errors
>> [16:19:57] tyler:freebsd git:(master*) $ 
> 
> 
> I'm not sure what other data would be useful here, I can consistently
> see the panic, but this data is highly personal, so I'm not sure how
> much of a "repro case" I can give folks. :(
> 
> Cheers
> 


-- 
Andriy Gapon
___
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"