Re: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8

[Timur I. Bakeyev]

Do you use net/samba36 port? Looks like you don't...

@@ -6336,12 +6373,13 @@
NSSSONAMEVERSIONSUFFIX=".2"
WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_linux.o"
;;
-   *freebsd[[5-9]]*)
+   *freebsd*)
# FreeBSD winbind client is implemented as a wrapper around
# the Linux version.
NSSSONAMEVERSIONSUFFIX=".1"
WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_freebsd.o \
../nsswitch/winbind_nss_linux.o"
+   WINBIND_WINS_NSS_EXTRA_OBJS="../nsswitch/wins_freebsd.o"
WINBIND_NSS="../nsswitch/nss_winbind.$SHLIBEXT"
WINBIND_WINS_NSS="../nsswitch/nss_wins.$SHLIBEXT"
;;


On Mon, Nov 10, 2014 at 1:14 PM, Julian Elischer  wrote:

> When I try use the libnss_winbind.so  that is generated by samba 3.6 I get
> the following message:
>
>  NSSWITCH(nss_load_module): winbind, Undefined symbol
> "nss_module_register".
>
> First I have to change its' name to nss_winbins.so.1 however because that
> is what nsswitch is looking for
> (BTW where is that documented??)
>
> then it finds it but fails as mentioned above.
>
> This same samba source generates good nss files in 8.0 but under 10 it
> fails.. Literally it's the same sources just checked out into a different
> build system. (10 vs 8).
>
> Has there been a change in the API for the nss modules? where it he API
> for nsswitch files documented?
>
> Julian
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Changing timezone without reboot/restarting each service?

[David Chisnall]

On 11 Nov 2014, at 03:35, Allan Jude  wrote:

> jkh@ mentioned this specifically when he gave his talk at EuroBSDCon and
> MeetBSD, about how Apple solved this in LaunchD, because apparently
> originally libc DID check /etc/localtime constantly.

Darwin also has the notify(3) interface, which allows one-bit messages to be 
transmitted either from the kernel to userspace or from userspace to userspace 
very cheaply.  This is ideal for this sort of 'something you've cached is 
change, go and do something expensive to fix it' use (time zone has changed, 
network connectivity has changed, power state has changed).  You can assign 
notifications to either file descriptors (that can be monitored with kqueue), 
to signals, or to flags in memory for things where polling is cheaper (as in 
this case - the libc functions could just check whether a specific flag is set 
in memory when accessing the time zone info and load a newer one if changed).

David

___
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: MK_ vs. WITH_/WITHOUT_ in release/Makefile

[Rick Miller]

On Mon, Nov 10, 2014 at 12:41 PM, Glen Barber  wrote:

> On Mon, Nov 10, 2014 at 09:38:08AM -0500, Rick Miller wrote:
> > Hi all,
> >
> > release/Makefile in CURRENT utilizes MK_* knobs vs. the WITH_/WITHOUT_*
> > knobs seen in release/Makefile in the STABLE/RELEASE branches.  Merging a
> > CURRENT version of the Makefile into a RELEASE branch and executing a
> > release build results in an error citing "MK_KERNEL_SYMBOLS can't be set
> by
> > a user".  Comparisons of the Makefile between CURRENT and STABLE/RELEASE
> > exposed the difference and changing the knobs from MK_ to WITHOUT_
> resolved
> > the error.
> >
> > I have little familiarity with these knobs, but was under the impression
> > the Makefile would not differ like this.  Is there documentation
> describing
> > the use of these knobs between the varying branches and how they are
> > changed from CURRENT to STABLE/RELEASE?
> >
>
> These changes are result of src.opts.mk changes (only available in
> head/) that allows specifying MK_FOO=no instead of WITHOUT_FOO=yes on
> the command line.
>
> The changes were applied to the release/Makefile because it allows more
> granular tuning for different stages of the release build.  For example,
> one might want to build userland/kernel with WITH_DEBUG_FILES=yes, but
> does not want that to apply to the resulting ISOs, so a "global"
> WITH_DEBUG_FILES=yes and target-specific MK_DEBUG_FILES=no do not
> collide.
>

Thanks, Glen & Scot...

The necessary bits exist in STABLE and were, therefore, merged from there
as opposed to CURRENT.  Your feedback is appreciated.

-- 
Take care
Rick Miller
___
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: HEADS-UP: amd64 UEFI boot is broken

[Ed Maste]

On 10 November 2014 20:17, Ed Maste  wrote:
> UEFI booting is broken for amd64 as of r273582 (Oct 24). The symptom
> is an apparent hang after the loader transfers control to the kernel
> (no output from the kernel is observed). Until this is addressed you
> can checkout an earlier revision or revert r273582 locally.

I have committed a workaround for this issue in r274382. The vt(4) EFI
framebuffer driver makes use of kernel infrastructure in a way that is
not correct, but works in practice, and this was caught by a new
assertion added in r273582. My change loosens the assertion to allow
efifb's use for now.

We will need to fix the early framebuffer implementation in a subsequent change.

-Ed
___
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: Unable to build world w/o clang on 11

[Chris H]

On Mon, 10 Nov 2014 19:52:48 -0800 "Chris H"  wrote

> On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl
>  wrote
> 
> > On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote:
> > > ===> lib/libdpv (depend)
> > > rm -f .depend
> > > CC='cc  ' mkdep -f .depend -a-I/usr/src/lib/libdpv -std=gnu99  
> > > /usr/src/lib
> > > /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c
> > > /usr/src/lib/libdpv/dprompt
> > > c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c
> > > /usr/src/lib/libdpv/ut
> > > il.c
> > > In file included from /usr/src/lib/libdpv/dialog_util.c:43:
> > > In file included from /usr/src/lib/libdpv/dialog_util.h:34:
> > > /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not
> > > found #include 
> > >  ^
> > > 1 error generated.
> > > /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not
> > > found 
> >
> > Until such time that you can get the tree to build without -j, don't
> > use it.
> > 
> > Now, the obvious question:  do you have figpar.h in /usr/src?
> Ugh... it's been a hectic day. Apparently it wasn't included in
> Revision: 274349
> Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014)
> 
> :P
> 
> I'll blow away src, and ports, and checkout what's ever available
> now. Hoping it's *now* included. ;)
> 
> Thank you *very* much rubbing my face in the obvious, Steve. :)
> 
> --Chris
Checked out the current version of src from head, that was available (r274365)
and gave it another go. While it *did* have the missing file. The results
were less than hoped for:

cc  -O2 -pipe   -I/usr/src/sbin/gbde/../../sys -DRESCUE -std=gnu99
-fstack-prote
ctor -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Ws
trict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign  
-c
 /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c
cc1: warnings being treated as errors
/usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c: In function
'ri
jndael_padEncrypt':
/usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:236: warning:
ca
st discards qualifiers from pointer target type
/usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:237: warning:
ca
st discards qualifiers from pointer target type
/usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:238: warning:
ca
st discards qualifiers from pointer target type
/usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c:239: warning:
ca
st discards qualifiers from pointer target type
*** Error code 1

Stop.
make[6]: stopped in /usr/src/sbin/gbde
*** Error code 1

Stop.
make[5]: stopped in /usr/obj/usr/src/rescue/rescue
*** Error code 1

Stop.
make[4]: stopped in /usr/src/rescue/rescue
*** Error code 1

Stop.
make[3]: stopped in /usr/src/rescue
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

While I recognize that -CURRENT is a moving target. Things
seem a bit brittle, at the moment. I'll check out what's
available now (revision), and hope for the best.

--Chris
> 
> > 
> > -- 
> > Steve
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
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: Unable to build world w/o clang on 11

[Garrett Cooper]

> On Nov 11, 2014, at 07:51, Chris H  wrote:
> 
> On Mon, 10 Nov 2014 19:52:48 -0800 "Chris H"  wrote
> 
>> On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl
>>  wrote
>> 
 On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote:
 ===> lib/libdpv (depend)
 rm -f .depend
 CC='cc  ' mkdep -f .depend -a-I/usr/src/lib/libdpv -std=gnu99  
 /usr/src/lib
 /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c
 /usr/src/lib/libdpv/dprompt
 c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c
 /usr/src/lib/libdpv/ut
 il.c
 In file included from /usr/src/lib/libdpv/dialog_util.c:43:
 In file included from /usr/src/lib/libdpv/dialog_util.h:34:
 /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not
 found #include 
 ^
 1 error generated.
 /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not
 found
>>> 
>>> Until such time that you can get the tree to build without -j, don't
>>> use it.
>>> 
>>> Now, the obvious question:  do you have figpar.h in /usr/src?
>> Ugh... it's been a hectic day. Apparently it wasn't included in
>> Revision: 274349
>> Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014)
>> 
>> :P
>> 
>> I'll blow away src, and ports, and checkout what's ever available
>> now. Hoping it's *now* included. ;)
>> 
>> Thank you *very* much rubbing my face in the obvious, Steve. :)
> Checked out the current version of src from head, that was available (r274365)
> and gave it another go. While it *did* have the missing file. The results
> were less than hoped for:

This issue was fixed just a few hours ago by des@

Cheers!
___
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: Changing timezone without reboot/restarting each service?

[Rui Paulo]

On Nov 11, 2014, at 00:56, David Chisnall  wrote:
> 
> On 11 Nov 2014, at 03:35, Allan Jude  wrote:
> 
>> jkh@ mentioned this specifically when he gave his talk at EuroBSDCon and
>> MeetBSD, about how Apple solved this in LaunchD, because apparently
>> originally libc DID check /etc/localtime constantly.
> 
> Darwin also has the notify(3) interface, which allows one-bit messages to be 
> transmitted either from the kernel to userspace or from userspace to 
> userspace very cheaply.  This is ideal for this sort of 'something you've 
> cached is change, go and do something expensive to fix it' use (time zone has 
> changed, network connectivity has changed, power state has changed).  You can 
> assign notifications to either file descriptors (that can be monitored with 
> kqueue), to signals, or to flags in memory for things where polling is 
> cheaper (as in this case - the libc functions could just check whether a 
> specific flag is set in memory when accessing the time zone info and load a 
> newer one if changed).

Except that's not how it works for network events: kernel control sockets are 
used to communicate between the kernel and userland about the state of the 
network.  Kernel control sockets carry kernel event messages.

--
Rui Paulo



___
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: HEADS-UP: amd64 UEFI boot is broken

[Adrian Chadd]

On 11 November 2014 07:12, Ed Maste  wrote:
> On 10 November 2014 20:17, Ed Maste  wrote:
>> UEFI booting is broken for amd64 as of r273582 (Oct 24). The symptom
>> is an apparent hang after the loader transfers control to the kernel
>> (no output from the kernel is observed). Until this is addressed you
>> can checkout an earlier revision or revert r273582 locally.
>
> I have committed a workaround for this issue in r274382. The vt(4) EFI
> framebuffer driver makes use of kernel infrastructure in a way that is
> not correct, but works in practice, and this was caught by a new
> assertion added in r273582. My change loosens the assertion to allow
> efifb's use for now.
>
> We will need to fix the early framebuffer implementation in a subsequent 
> change.

Woo, thanks!



-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Unable to build world w/o clang on 11

[Chris H]

On Tue, 11 Nov 2014 08:08:24 -0800 Garrett Cooper  wrote

> > On Nov 11, 2014, at 07:51, Chris H  wrote:
> > 
> > On Mon, 10 Nov 2014 19:52:48 -0800 "Chris H"  wrote
> > 
> >> On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl
> >>  wrote
> >> 
>  On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote:
>  ===> lib/libdpv (depend)
>  rm -f .depend
>  CC='cc  ' mkdep -f .depend -a-I/usr/src/lib/libdpv -std=gnu99  
>  /usr/src/lib
>  /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c
>  /usr/src/lib/libdpv/dprompt
>  c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c
>  /usr/src/lib/libdpv/ut
>  il.c
>  In file included from /usr/src/lib/libdpv/dialog_util.c:43:
>  In file included from /usr/src/lib/libdpv/dialog_util.h:34:
>  /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not
>  found #include 
>  ^
>  1 error generated.
>  /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not
>  found
> >>> 
> >>> Until such time that you can get the tree to build without -j, don't
> >>> use it.
> >>> 
> >>> Now, the obvious question:  do you have figpar.h in /usr/src?
> >> Ugh... it's been a hectic day. Apparently it wasn't included in
> >> Revision: 274349
> >> Last Changed Date: 2014-11-10 10:20:46 -0800 (Mon, 10 Nov 2014)
> >> 
> >> :P
> >> 
> >> I'll blow away src, and ports, and checkout what's ever available
> >> now. Hoping it's *now* included. ;)
> >> 
> >> Thank you *very* much rubbing my face in the obvious, Steve. :)
> > Checked out the current version of src from head, that was available
> > (r274365) and gave it another go. While it *did* have the missing file. The
> > results were less than hoped for:
> 
> This issue was fixed just a few hours ago by des@
> 
> Cheers!
Thanks for the info, and the words of hope, Garrett.
Indeed des@, *did* fix that, Thanks!
But sadly. blowing away ports, src, and obj. Then checking out
src r274382, and performing a buildworld. Although I got further.
it bombed at:

===> usr.sbin/hyperv (all)
===> usr.sbin/hyperv/tools (all)
cc  -O2 -pipe  
-I/usr/src/usr.sbin/hyperv/tools/../../../sys/dev/hyperv/utiliti
es -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
-
W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith
 -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold
-style-definition -Wno-pointer-sign   -c
/usr/src/usr.sbin/hyperv/tools/../../..
/contrib/hyperv/tools/hv_kvp_daemon.c
cc1: warnings being treated as errors
/usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c:
In
 function 'kvp_get_ip_info':
/usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c:814
: warning: 'ip_buffer' may be used uninitialized in this function
*** Error code 1

Stop.
make[5]: stopped in /usr/src/usr.sbin/hyperv/tools
*** Error code 1

Stop.
make[4]: stopped in /usr/src/usr.sbin/hyperv
*** Error code 1

Stop.
make[3]: stopped in /usr/src/usr.sbin
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

:(

Thanks again, Garrett. For taking the time to reply.

--Chris


___
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: Changing timezone without reboot/restarting each service?

[Dimitry Andric]

On 11 Nov 2014, at 04:28, Mark Felder  wrote:
> 
> On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote:
>> 
>> After changing timezones in Russia (with replacing /etc/localtime
>> with new file), I found that cron works in "old" timezone till
>> restart. And all other services do the same, but cron is most obvious
>> here :)
>> 
>> Looks like libc reads timezone only once and it could not be chamged
>> for process without restart (which leads to, effectivly, restart of
>> whole server).
>> 
>> Is it known problem? I think, it should be fixed somehow. I
>> understand, that re-check timezone file on each time-related call
>> could be expensive, though :(
>> 
> 
> I think this was one of the crowning achievements of systemd, but I'm
> sure someone can come up with something much more sane than that to
> address this problem.

Actually, it isn't:
http://www.freedesktop.org/wiki/Software/systemd/timedated/

This reads "Note that this service will not inform you about system time
changes. Use timerfd() with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET
for that."

So it mostly looks like a shared service to provide the graphical time
control panel for GNOME.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Unable to build world w/o clang on 11

[Dimitry Andric]

On 11 Nov 2014, at 20:04, Chris H  wrote:
...
> But sadly. blowing away ports, src, and obj. Then checking out
> src r274382, and performing a buildworld. Although I got further.
> it bombed at:
> 
> ===> usr.sbin/hyperv (all)
> ===> usr.sbin/hyperv/tools (all)
> cc  -O2 -pipe
> -I/usr/src/usr.sbin/hyperv/tools/../../../sys/dev/hyperv/utiliti
> es -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
> -
> W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith
> -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
> -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> -Wold
> -style-definition -Wno-pointer-sign   -c
> /usr/src/usr.sbin/hyperv/tools/../../..
> /contrib/hyperv/tools/hv_kvp_daemon.c
> cc1: warnings being treated as errors
> /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c:
> In
> function 'kvp_get_ip_info':
> /usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c:814
> : warning: 'ip_buffer' may be used uninitialized in this function

Yep, this is another false positive from gcc.  I've mailed a proposed
workaround to Xin Li, but for now, if you compile world and kernel with
gcc, use NO_WERROR= and WERROR= in your make.conf.  Especially the
kernel still needs a bunch of fixes to make it work with gcc again.

It's a pity the gcc tinderboxes have been taken offline.  Maybe this can
be added to the FreeBSD Jenkins instance now?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r273918 buildworld broke at semaphore

[John Baldwin]

On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote:
> First breakage in a long time. Error is:
> 
> In file included from cancelpoints_sem_new.c:47:
> /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has
> incomplete type 'struct _usem2'
> struct _usem2   _kern;
> ^
> /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward declaration
> of 'struct _usem2'
> struct _usem2   _kern;
>^
> cancelpoints_sem_new.c:66:33: error: use of undeclared identifier
> 'USEM_MAX_COUNT'
> _Static_assert(SEM_VALUE_MAX <= USEM_MAX_COUNT, "SEM_VALUE_MAX too large");
> ^
> cancelpoints_sem_new.c:335:15: warning: implicit declaration of function
> 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration]
> *sval = (int)USEM_COUNT(sem->_kern._count);
>  ^
> cancelpoints_sem_new.c:342:23: error: use of undeclared identifier
> 'UMTX_OP_SEM2_WAKE'
> return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL);
>  ^
> cancelpoints_sem_new.c:361:23: error: use of undeclared identifier
> 'UMTX_OP_SEM2_WAIT'
> return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0,
>  ^
> cancelpoints_sem_new.c:445:14: error: use of undeclared identifier
> 'USEM_HAS_WAITERS'
> if (count & USEM_HAS_WAITERS)
> ^
> 1 warning and 5 errors generated.

Seems like your tree is not fully up to date?  The changes to sem_new.c were 
committed in the same commit as the changes to sys/umtx.h.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r273165. ZFS ARC: possible memory leak to Inact

[John Baldwin]

On Wednesday, November 05, 2014 4:52:50 am Andriy Gapon wrote:
> On 04/11/2014 14:55, Steven Hartland wrote:
> > This is likely spikes in uma zones used by ARC.
> > 
> > The VM doesn't ever clean uma zones unless it hits a low memory condition, 
which
> > explains why your little script helps.
> > 
> > Check the output of vmstat -z to confirm.
> 
> Steve,
> 
> this is nonsense :-)  You know perfectly well that UMA memory is Wired not 
Inactive.

Grab the code at www.freebsd.org/~jhb/vm_objects/.  Build and load the kld and 
then use the vm_objects binary to generate a list of the active VM objects in 
the system along with counts of how many active / inactive pages each object 
contains.  For your case with lots of inactive memory, you probably want 
something like 'vm_objects | sort -n -k 2'.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Changing timezone without reboot/restarting each service?

[John Baldwin]

On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote:
> 
>  After changing timezones in Russia (with replacing /etc/localtime
> with new file), I found that cron works in "old" timezone till
> restart. And all other services do the same, but cron is most obvious
> here :)
> 
>  Looks like libc reads timezone only once and it could not be chamged
> for process without restart (which leads to, effectivly, restart of
> whole server).
> 
>  Is it known problem? I think, it should be fixed somehow. I
> understand, that re-check timezone file on each time-related call
> could be expensive, though :(

In practice, timezone changes are very rare, so rechecking the file is
quite expensive to do.  I think having to restart processes is fine for this.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Unable to build world w/o clang on 11

[Chris H]

On Tue, 11 Nov 2014 20:21:48 +0100 Dimitry Andric  wrote

> On 11 Nov 2014, at 20:04, Chris H  wrote:
> ...
> > But sadly. blowing away ports, src, and obj. Then checking out
> > src r274382, and performing a buildworld. Although I got further.
> > it bombed at:
> > 
> > ===> usr.sbin/hyperv (all)
> > ===> usr.sbin/hyperv/tools (all)
> > cc  -O2 -pipe
> > -I/usr/src/usr.sbin/hyperv/tools/../../../sys/dev/hyperv/utiliti
> > es -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
> > -Wno-format-y2k -
> > W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> > -Wpointer-arith
> > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
> > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
> > -Wredundant-decls -Wold
> > -style-definition -Wno-pointer-sign   -c
> > /usr/src/usr.sbin/hyperv/tools/../../..
> > /contrib/hyperv/tools/hv_kvp_daemon.c
> > cc1: warnings being treated as errors
> >
> >
/usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c:
> > In
> > function 'kvp_get_ip_info':
> >
> >
/usr/src/usr.sbin/hyperv/tools/../../../contrib/hyperv/tools/hv_kvp_daemon.c:
> > 814 : warning: 'ip_buffer' may be used uninitialized in this function
> 
> Yep, this is another false positive from gcc.  I've mailed a proposed
> workaround to Xin Li, but for now, if you compile world and kernel with
> gcc, use NO_WERROR= and WERROR= in your make.conf.  Especially the
> kernel still needs a bunch of fixes to make it work with gcc again.
> 
> It's a pity the gcc tinderboxes have been taken offline.  Maybe this can
> be added to the FreeBSD Jenkins instance now?

Thank you *very* much, Dimitry. For the informative reply.
Yes. I agree, adding a task for Jenkins seems like a *very*
good idea.

Well, it looks like a real gamble not going with defaults,
for now. I guess attempts using gcc as base compiler is off the
table, for now.
This must really hit some of the other ARCHS pretty hard. I
can't imagine trying to develop under these circumstances.
Here's hoping for improvements in this area soon!

Thanks again, Dimitry.

--Chris
> 
> -Dimitry


___
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: Changing timezone without reboot/restarting each service?

[Brooks Davis]

On Tue, Nov 11, 2014 at 01:57:40PM -0500, John Baldwin wrote:
> On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote:
> > 
> >  After changing timezones in Russia (with replacing /etc/localtime
> > with new file), I found that cron works in "old" timezone till
> > restart. And all other services do the same, but cron is most obvious
> > here :)
> > 
> >  Looks like libc reads timezone only once and it could not be chamged
> > for process without restart (which leads to, effectivly, restart of
> > whole server).
> > 
> >  Is it known problem? I think, it should be fixed somehow. I
> > understand, that re-check timezone file on each time-related call
> > could be expensive, though :(
> 
> In practice, timezone changes are very rare, so rechecking the file is
> quite expensive to do.  I think having to restart processes is fine for this.

For cron it seems like a neglegable cost as it has to check a file and a
directory at each interval.  For most other things it seems like a waste of
resources to check.

Even on systems like MacOS where this is solved better, lots of behavior
is application dependent.  For example, current versions of Omni Focus
behave very oddly when the timezone changes underneath them.  In
practice you need to restart the application when timezones change (such
as after a flight).  Just making libc aware isn't a magic bullet.

-- Brooks



pgpExOQT1Hx1X.pgp
Description: PGP signature

Re: Changing timezone without reboot/restarting each service?

[Charles Swiger]

On Nov 11, 2014, at 10:57 AM, John Baldwin  wrote:
> On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote:
>> 
>> After changing timezones in Russia (with replacing /etc/localtime
>> with new file), I found that cron works in "old" timezone till
>> restart. And all other services do the same, but cron is most obvious
>> here :)
>> 
>> Looks like libc reads timezone only once and it could not be chamged
>> for process without restart (which leads to, effectivly, restart of
>> whole server).
>> 
>> Is it known problem? I think, it should be fixed somehow. I
>> understand, that re-check timezone file on each time-related call
>> could be expensive, though :(
> 
> In practice, timezone changes are very rare, so rechecking the file is
> quite expensive to do.  I think having to restart processes is fine for this.

In theory, timezone changes should be very rare.

We've actually had about ten TZ updates in 2014; the most recent was FET -> MSK
for Belarus plus minor tweaks to IDT vs ICT.  If you're working within the scope
of a single country, I suspect that one could ignore the bulk of TZ updates and
be fine most of the time.

If you're world-wide, however, TZ update frequency becomes more noticeable

Regards,
-- 
-Chuck

___
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: Changing timezone without reboot/restarting each service?

[Mark Felder]

On Tue, Nov 11, 2014, at 13:16, Dimitry Andric wrote:
> On 11 Nov 2014, at 04:28, Mark Felder  wrote:
> > 
> > On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote:
> >> 
> >> After changing timezones in Russia (with replacing /etc/localtime
> >> with new file), I found that cron works in "old" timezone till
> >> restart. And all other services do the same, but cron is most obvious
> >> here :)
> >> 
> >> Looks like libc reads timezone only once and it could not be chamged
> >> for process without restart (which leads to, effectivly, restart of
> >> whole server).
> >> 
> >> Is it known problem? I think, it should be fixed somehow. I
> >> understand, that re-check timezone file on each time-related call
> >> could be expensive, though :(
> >> 
> > 
> > I think this was one of the crowning achievements of systemd, but I'm
> > sure someone can come up with something much more sane than that to
> > address this problem.
> 
> Actually, it isn't:
> http://www.freedesktop.org/wiki/Software/systemd/timedated/
> 
> This reads "Note that this service will not inform you about system time
> changes. Use timerfd() with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET
> for that."
> 
> So it mostly looks like a shared service to provide the graphical time
> control panel for GNOME.
> 

Aha, I guess the article I read was as reliable as jamming all that code
into PID 1. :-)
___
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: Changing timezone without reboot/restarting each service?

[John Baldwin]

On Tuesday, November 11, 2014 3:16:19 pm Charles Swiger wrote:
> On Nov 11, 2014, at 10:57 AM, John Baldwin  wrote:
> > On Monday, November 10, 2014 7:36:19 am Lev Serebryakov wrote:
> >> 
> >> After changing timezones in Russia (with replacing /etc/localtime
> >> with new file), I found that cron works in "old" timezone till
> >> restart. And all other services do the same, but cron is most obvious
> >> here :)
> >> 
> >> Looks like libc reads timezone only once and it could not be chamged
> >> for process without restart (which leads to, effectivly, restart of
> >> whole server).
> >> 
> >> Is it known problem? I think, it should be fixed somehow. I
> >> understand, that re-check timezone file on each time-related call
> >> could be expensive, though :(
> > 
> > In practice, timezone changes are very rare, so rechecking the file is
> > quite expensive to do.  I think having to restart processes is fine for 
> > this.
> 
> In theory, timezone changes should be very rare.
> 
> We've actually had about ten TZ updates in 2014; the most recent was FET -> 
> MSK
> for Belarus plus minor tweaks to IDT vs ICT.  If you're working within the 
> scope
> of a single country, I suspect that one could ignore the bulk of TZ updates 
> and
> be fine most of the time.
> 
> If you're world-wide, however, TZ update frequency becomes more noticeable

The vast majority of updates are historical changes however.  Having used a
timezone-aware version of cron for an international company so we can schedule
jobs across multiple timezones for a single machine (times N machines scattered
around the globe) for the last 4 or 5 years, FET -> MSK was the first time we
had a timezone change in that span that actually impacted our operations (and
we've just restarted cron / rebooted to cope).

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

netmap: extension to store user data per packet/slot?

[Franco Fichtner]

Hi Luigi,
hi all,

so I was running into logistics issues with netmap(4)
with regard to zero-copy and redirection through pipes:
working on a load-balancing framework revealed that it
is very hard to track a packet's origins to later move
it onward to the respective outgoing interface, be it
another device or the host stack.

Long story short: user data needs to be stored for the
packet buffer or slot.

There are three ways that I can see so far:

(1) Allocate a netmap pipe pair for each interface,
in case of transparent mode also a pipe for the
host stack each.  That's a lot of pipes and
most likely insane, but it won't extend the ABI.

(2) Store the additional data in the actual buffer.
That is sort of ok, but seems sluggish WRT cache
behaviour -- maybe the buffer won't be read but
it needs to be written.  Sure, we can store it at
the end, but there already resides the packet
timestamp if enabled (if I recall correctly).
Wouldn't extend the ABI per se, but might collide
with the timestamping

(3) Make room in struct netmap_slot itself like this:

diff --git a/sys/net/netmap.h b/sys/net/netmap.h
index 15ebf73..d0a9c0e 100644
--- a/sys/net/netmap.h
+++ b/sys/net/netmap.h
@@ -147,6 +147,7 @@ struct netmap_slot {
uint16_t len;   /* length for this slot */
uint16_t flags; /* buf changed, etc. */
uint64_t ptr;   /* pointer for indirect buffers */
+   uint64_t userdata;  /* reserved storage for caller */
 };

It could also be broken down in two fields with uint32_t
each; not sure what would be more sensible.  This of course
requires an API bump, although it should be backwards
compatible.

Any feedback on this is highly appreciated.


Cheers,
Franco
___
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: netmap: extension to store user data per packet/slot?

[Adrian Chadd]

... I'm confused. Do you have the slot id already, right? Why not
allocate an array of userdata pointers somewhere else and just use the
netmap slot id as an indirection into that?



-adrian


On 11 November 2014 13:13, Franco Fichtner  wrote:
> Hi Luigi,
> hi all,
>
> so I was running into logistics issues with netmap(4)
> with regard to zero-copy and redirection through pipes:
> working on a load-balancing framework revealed that it
> is very hard to track a packet's origins to later move
> it onward to the respective outgoing interface, be it
> another device or the host stack.
>
> Long story short: user data needs to be stored for the
> packet buffer or slot.
>
> There are three ways that I can see so far:
>
> (1) Allocate a netmap pipe pair for each interface,
> in case of transparent mode also a pipe for the
> host stack each.  That's a lot of pipes and
> most likely insane, but it won't extend the ABI.
>
> (2) Store the additional data in the actual buffer.
> That is sort of ok, but seems sluggish WRT cache
> behaviour -- maybe the buffer won't be read but
> it needs to be written.  Sure, we can store it at
> the end, but there already resides the packet
> timestamp if enabled (if I recall correctly).
> Wouldn't extend the ABI per se, but might collide
> with the timestamping
>
> (3) Make room in struct netmap_slot itself like this:
>
> diff --git a/sys/net/netmap.h b/sys/net/netmap.h
> index 15ebf73..d0a9c0e 100644
> --- a/sys/net/netmap.h
> +++ b/sys/net/netmap.h
> @@ -147,6 +147,7 @@ struct netmap_slot {
> uint16_t len;   /* length for this slot */
> uint16_t flags; /* buf changed, etc. */
> uint64_t ptr;   /* pointer for indirect buffers */
> +   uint64_t userdata;  /* reserved storage for caller */
>  };
>
> It could also be broken down in two fields with uint32_t
> each; not sure what would be more sensible.  This of course
> requires an API bump, although it should be backwards
> compatible.
>
> Any feedback on this is highly appreciated.
>
>
> Cheers,
> Franco
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r273918 buildworld broke at semaphore

[Henry Hu]

On Tue, Nov 11, 2014 at 1:33 PM, John Baldwin  wrote:

> On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote:
> > First breakage in a long time. Error is:
> >
> > In file included from cancelpoints_sem_new.c:47:
> > /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has
> > incomplete type 'struct _usem2'
> > struct _usem2   _kern;
> > ^
> > /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward
> declaration
> > of 'struct _usem2'
> > struct _usem2   _kern;
> >^
> > cancelpoints_sem_new.c:66:33: error: use of undeclared identifier
> > 'USEM_MAX_COUNT'
> > _Static_assert(SEM_VALUE_MAX <= USEM_MAX_COUNT, "SEM_VALUE_MAX too
> large");
> > ^
> > cancelpoints_sem_new.c:335:15: warning: implicit declaration of function
> > 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration]
> > *sval = (int)USEM_COUNT(sem->_kern._count);
> >  ^
> > cancelpoints_sem_new.c:342:23: error: use of undeclared identifier
> > 'UMTX_OP_SEM2_WAKE'
> > return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL);
> >  ^
> > cancelpoints_sem_new.c:361:23: error: use of undeclared identifier
> > 'UMTX_OP_SEM2_WAIT'
> > return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0,
> >  ^
> > cancelpoints_sem_new.c:445:14: error: use of undeclared identifier
> > 'USEM_HAS_WAITERS'
> > if (count & USEM_HAS_WAITERS)
> > ^
> > 1 warning and 5 errors generated.
>
> Seems like your tree is not fully up to date?  The changes to sem_new.c
> were
> committed in the same commit as the changes to sys/umtx.h.


Maybe it's another problem. buildworld may be picking up umtx.h from
/usr/include which is the old version.



>
> --
> John Baldwin
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>



-- 
Cheers,
Henry
___
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: r273918 buildworld broke at semaphore

[Beeblebrox]

Seems like your tree is not fully up to date?  The changes to
sem_new.c were
committed in the same commit as the changes to sys/umtx.h.


I deleted the entire contents of /usr/src, then did
# svn co svn://svn.freebsd.org/base/head
Buildworld breaks at same place (semaphore)

This error AFAIK, was already combined with:
http://freebsd.1045724.n5.nabble.com/r273910-build-failure-if-lt-sys-umtx-h-gt-is-out-of-date-td5961186.html

Speaking of "out-of-date",
http://freebsd.1045724.n5.nabble.com/version-number-error-with-ports-td5961642.html

Regards.

___
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: netmap: extension to store user data per packet/slot?

[Franco Fichtner]

Hi Adrian,

On 11 Nov 2014, at 22:22, Adrian Chadd  wrote:

> ... I'm confused. Do you have the slot id already, right? Why not
> allocate an array of userdata pointers somewhere else and just use the
> netmap slot id as an indirection into that?

The slot id is per ring and there are a lot of them.  In case of
zero-copy the slot changes at least 1.  Consider two processes
for the load balancing case.  Process 1 attaches to the devices
and Process 2 only has a a pipe pair for receiving and sending
packets back to Process 1 after processing, because only that
process has access to the real devices:

em0, em1, etc. <--RX/TX--> Process 1 <--pipe pair--> Process 2
(Hardware)(Balancer)  (Worker)

There is no way to trace packet origin back to em0 or em1 after
pushing the packets through the pipe pair unless either the
pipes are unique for each device or there is another means to
keep its state.

Should, however, the buffer id be unique that would make it
easy to do what you suggest, but I don't know the netmap(4)
internals by heart.

It seems a wee unnatural to rebuild tracing of packets in
userland when netmap(4) has all the infrastructure needed to
deal with this effectively, but I'm not opposed to doing that
to avoid API/ABI changes.  Speaking of those, should volatile
internals change regarding the buffer id that would also break
the attempts to deal with the issue consistently.


Cheers,
Franco
___
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: netmap: extension to store user data per packet/slot?

[Adrian Chadd]

On 11 November 2014 13:41, Franco Fichtner  wrote:
> Hi Adrian,
>
> On 11 Nov 2014, at 22:22, Adrian Chadd  wrote:
>
>> ... I'm confused. Do you have the slot id already, right? Why not
>> allocate an array of userdata pointers somewhere else and just use the
>> netmap slot id as an indirection into that?
>
> The slot id is per ring and there are a lot of them.  In case of
> zero-copy the slot changes at least 1.  Consider two processes
> for the load balancing case.  Process 1 attaches to the devices
> and Process 2 only has a a pipe pair for receiving and sending
> packets back to Process 1 after processing, because only that
> process has access to the real devices:
>
> em0, em1, etc. <--RX/TX--> Process 1 <--pipe pair--> Process 2
> (Hardware)(Balancer)  (Worker)
>
> There is no way to trace packet origin back to em0 or em1 after
> pushing the packets through the pipe pair unless either the
> pipes are unique for each device or there is another means to
> keep its state.
>
> Should, however, the buffer id be unique that would make it
> easy to do what you suggest, but I don't know the netmap(4)
> internals by heart.
>
> It seems a wee unnatural to rebuild tracing of packets in
> userland when netmap(4) has all the infrastructure needed to
> deal with this effectively, but I'm not opposed to doing that
> to avoid API/ABI changes.  Speaking of those, should volatile
> internals change regarding the buffer id that would also break
> the attempts to deal with the issue consistently.

Ah, I see. You're missing some unique identifier for each netmap
buffer. I thought there was one already. Silly me.

Luigi?



-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: netmap: extension to store user data per packet/slot?

[Franco Fichtner]

On 11 Nov 2014, at 22:48, Adrian Chadd  wrote:

> Ah, I see. You're missing some unique identifier for each netmap
> buffer. I thought there was one already. Silly me.

Exactly, and, no, thank you for making clear what is needed.  :)

A little more on this: I think struct netmap_slot is convenient
due to the fact that in zero-copy one wouldn't want to mess with
the actual buffer for speed and userland code already touches slot
internals for each ring transition so there is no performance
degradation.

The key benefit is that if userland can use this storage freely
netmap(4) doesn't get in the way of building complex setups that
require decoupled logic and each ring "hop" may alter the state
as required.


Cheers,
Franco
___
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"

Build failed in Jenkins: FreeBSD_HEAD #1820

[jenkins-admin]

See 

Changes:

[glebius] Remove SF_KQUEUE code.  This code was developed at Netflix, but was 
not
ever used.  It didn't go into stable/10, neither was documented.
It might be useful, but we collectively decided to remove it, rather
leave it abandoned and unmaintained.  It is removed in one single
commit, so restoring it should be easy, if anyone wants to reopen
this idea.

Sponsored by:   Netflix

[jhb] Add device ID for the T502-BT (dual-port 1G) adapter.

Reviewed by:np
MFC after:  1 week

[dteske] Fix whitespace.

Thanks to:  nwhitehorn

[jhb] Move NFS and TFTP filesystems before the synthetic filesystems (bzip,
gzip, and split).  "Real" filesystems should always be listed first so
that the "bare" filename is tried before alternate filenames.  For PXE
booting in particular this can remove a lot of spurious pathname lookups.

While here, move splitfs to the bottom after the bzip and gzip filesystems
as it is the least often used.

Tested by:  Prokash Sinha 
MFC after:  1 week

[jkim] Use the correct device.  Note this commit complements r274386.

PR: 194884

[dteske] Default `bsdconfig timezone' and `tzsetup' to `-s' in a VM.

Recommended by: cperciva
Reviewed by:cperciva
Relnotes:   tzsetup and bsdconfig now assume that the "hardware" clock 
inside a VM is set to UTC

[dim] Change kbdb's kthr::cpu field into an int, to avoid gcc warnings about
comparing it with NOCPU, which became -1 recently.  While here, avoid
using it for address calculations if it is negative.

Reviewed by:jhb, adrian
MFC after:  1 week

--
[...truncated 278416 lines...]
ctfconvert -L VERSION -g mv.o
--- ioctl.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99 -g -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  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc  -I. 
-I 
-I 
-I 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror  

--- hptproc.o ---
ctfconvert -L VERSION -g hptproc.o
--- hv_net_vsc.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99 -g -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  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc  -I. 
-I 
-I 
-I 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror  

--- ioctl.o ---
ctfconvert -L VERSION -g ioctl.o
--- gui_lib.o ---
ctfconvert -L VERSION -g gui_lib.o
--- hv_netvsc_drv_freebsd.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99 -g -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  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc  -I. 
-I 
-I 
-I 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror  

--- hv_rn

Re: netmap: extension to store user data per packet/slot?

[Luigi Rizzo]

Franco,
apparently you want some user-defined metadata to move
along with the packet, but i do not think it is
reasonable to put it in the slots.
If we do that, what about timestamps, flow IDs,
interface and queue index and all the rest of the things that
we normally find in an mbuf/skbuf ? This is not
going to scale.

Also consider that at some point you may use a different
arrangement (with packets passed along VALE switches
or physical interfaces etc.) i believe the most
reasonable place to put the extra info is at the end
of the packet and possibly bump the length in the slot
so you are safe in case the packet is copied.

There is no timestamp appended to the packet at the moment,
it was a feature i thought somebody may want to have,
but between the relative scarcity of hardware that provides
per-packet timestamps, and the questionable usefulness
of the same, i doubt it will be available.

cheers
luigi


On Tue, Nov 11, 2014 at 2:01 PM, Franco Fichtner 
wrote:

>
> On 11 Nov 2014, at 22:48, Adrian Chadd  wrote:
>
> > Ah, I see. You're missing some unique identifier for each netmap
> > buffer. I thought there was one already. Silly me.
>
> Exactly, and, no, thank you for making clear what is needed.  :)
>
> A little more on this: I think struct netmap_slot is convenient
> due to the fact that in zero-copy one wouldn't want to mess with
> the actual buffer for speed and userland code already touches slot
> internals for each ring transition so there is no performance
> degradation.
>
> The key benefit is that if userland can use this storage freely
> netmap(4) doesn't get in the way of building complex setups that
> require decoupled logic and each ring "hop" may alter the state
> as required.
>
>
> Cheers,
> Franco
>



-- 
-+---
 Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/. Universita` di Pisa
 TEL  +39-050-2211611   . via Diotisalvi 2
 Mobile   +39-338-6809875   . 56122 PISA (Italy)
-+---
___
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"

Jenkins build is back to normal : FreeBSD_HEAD #1821

[jenkins-admin]

See 

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

buildworld fails: spa_maxblocksize

[Russell L. Carter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

So the ztest link fails looking for spa_maxblocksize, which
is defined in

sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c

I don't see which lib it is included in. One of zpool, zfs,
or zfs_core, apparently.

As my build system is root on zfs, I am a bit nervous about
just installing those (shouldn't buildworld take care of
this?)

It looks to me that my buildworld environment is reaching
out to the exterior system, is that right?  I have set

export MAKEOBJDIRPREFIX=/usr/obj

before invoking buildworld, but it doesn't help.

Ideas?

Thanks,
Russell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUYsW4AAoJEFnLrGVSDFaE6RwP/RL43zI7dIp3Xl3WSEVpCjLH
uz7PLKjcHpJoLP8MU4cA6QYB+w2aIT6L5xEwdWDvFJXj1TIV0cgyd9Pn/nSmxKnD
2grZxcHmdKV9Lkmvegb6BaGs0ysSHbaVr95XIpRNCBXM9gE+8HIqLgFhkDPQCaRU
OjbOOjLpdfdW5qWlQasMBVwsnLJHpd0TJKwV43NQYMkmohLsQWbPvEA72N5X1131
UzJZGP2SMivNwlyW++V0ZbNflsaR40IsZk+1BJaHS5ywnFVgXqj1uFnv5l0TfzUE
nUsIcrQ00/ETpcypCnsHuJyUOKey/OzVyLLlzmSSpxUtDBU/2QKNxeVtkroLvJIf
w6IBR9H6mWIzebNKodxnP7jkE59yMpgEzvFzNHwuc3EVhYRLK4eD7TN524DV3/KK
81b2rdpaPXHh+PqFJQ82XHlpV1pCn0JxQNUjVOzuiXchg7HQAJdBrJhTGsb/g0Z/
KxEuk7t+WchcIakemFQNPmvyg3r2UfzMTyrNN2nxyCRSXk94Xgw8GyWl9f+5DmtR
m5gIdEVNpIijwBeYZ+ctDjzRrRJ+cwnVq/35Doiot+lvefDo3Ky00+5w8iHwPAmT
rJ1X/lX00CmBcaU/bginYBJCSckvBOuoU6pW6W8F3wvsVKCOmBnLTz5e64P/i62R
hLnD6BcqlmCORw6FqMaO
=totl
-END PGP SIGNATURE-
___
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: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8

[Julian Elischer]

On 11/11/14, 4:28 PM, Timur I. Bakeyev wrote:

Do you use net/samba36 port? Looks like you don't...

It occurred to me after posting to check the port and I found this..
The company decided to go the independent route before I joined so 
they don't use the port.

They have a huge set of diffs to samba so it kind of makes sense.


@@ -6336,12 +6373,13 @@
NSSSONAMEVERSIONSUFFIX=".2"
WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_linux.o"
;;
-   *freebsd[[5-9]]*)
+   *freebsd*)
# FreeBSD winbind client is implemented as a wrapper 
around

# the Linux version.
NSSSONAMEVERSIONSUFFIX=".1"
WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_freebsd.o \
../nsswitch/winbind_nss_linux.o"
+ WINBIND_WINS_NSS_EXTRA_OBJS="../nsswitch/wins_freebsd.o"
WINBIND_NSS="../nsswitch/nss_winbind.$SHLIBEXT"
WINBIND_WINS_NSS="../nsswitch/nss_wins.$SHLIBEXT"
;;


On Mon, Nov 10, 2014 at 1:14 PM, Julian Elischer > wrote:


When I try use the libnss_winbind.so  that is generated by samba
3.6 I get the following message:

 NSSWITCH(nss_load_module): winbind, Undefined symbol
"nss_module_register".

First I have to change its' name to nss_winbins.so.1 however
because that is what nsswitch is looking for
(BTW where is that documented??)

then it finds it but fails as mentioned above.

This same samba source generates good nss files in 8.0 but under
10 it fails.. Literally it's the same sources just checked out
into a different build system. (10 vs 8).

Has there been a change in the API for the nss modules? where it
he API for nsswitch files documented?

Julian
___
freebsd-current@freebsd.org 
mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org
"




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"