Luigi Rizzo | 28 Jul 14:19 2015
Picon
Picon

eventfd lookalike in FreeBSD ?

Hi,
for some work we are doing on bhyve, we need some lightweight mechanism that
a kernel thread can use to wake up another user thread possibly
waiting for some event.

If the recipient of the event were a kernel thread it would simply
do a tsleep(chan...) and the sender would do a wakeup() or wakeup_one().

Do we have an equally simple option for a recipient that is a
userspace thread using something that is already in the kernel ?
Do we have some blocking syscall that ends up doing a tsleep in
a predictable way ?

I suppose I could create a kqueue() descriptor and instruct the kernel
thread side to post an event instead of doing the wakeup, but
this seems a bit more expensive on both endpoints.

cheers
luigi
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

jenkins-admin | 28 Jul 09:17 2015
Picon

FreeBSD_HEAD_i386 - Build #693 - Failure

FreeBSD_HEAD_i386 - Build #693 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/693/console

Change summaries:

285934 by kib:
Remove full barrier from the amd64 atomic_load_acq_*().  Strong
ordering semantic of x86 CPUs makes only the compiler barrier
neccessary to give the acquire behaviour.

Existing implementation ensured sequentially consistent semantic for
load_acq, making much stronger guarantee than required by standard's
definition of the load acquire.  Consumers which depend on the barrier
are believed to be identified and already fixed to use proper
operations.

Noted by:	alc (long time ago)
Reviewed by:	alc, bde
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks

285933 by kib:
Remove useless acquire semantic from the atomic_add operation before
sosend().  The only release on the xp_snt_cnt is done after sosend(),
with an intent to synchronize with load_acq in svc_vc_ack().

(Continue reading)

Sydney Meyer | 27 Jul 23:49 2015

IPSEC stop works after r285336

Hello,

I'm having the same problem with IPSec, running -current with r285794.

Don't know if this helps, but "netstat -s -p esp" shows packets dropped; bad ilen.
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

jenkins-admin | 27 Jul 23:23 2015
Picon

FreeBSD_HEAD-tests - Build #1226 - Unstable

FreeBSD_HEAD-tests - Build #1226 - Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1226/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1226/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1226/console

Change summaries:

No changes

The end of the build log:

[...truncated 4429 lines...]
[192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:last_library_directory  ->  passed  [0.699s]
[192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:middle_library_directory  ->  passed  [0.290s]
[192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:missing_library  ->  passed  [0.425s]
[192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:single_library_directory  ->  passed  [1.168s]
[192.168.10.2] out: libexec/rtld-elf/ld_library_pathfds:wrong_library_directories  ->  passed  [1.007s]
[192.168.10.2] out: libexec/atf/atf-sh/atf_check_test:equal  ->  passed  [1.994s]
[192.168.10.2] out: libexec/atf/atf-sh/atf_check_test:experr_mismatch  ->  passed  [1.188s]
[192.168.10.2] out: libexec/atf/atf-sh/atf_check_test:expout_mismatch  ->  passed  [0.838s]
[192.168.10.2] out: libexec/atf/atf-sh/atf_check_test:flush_stdout_on_death  ->  passed  [1.674s]
[192.168.10.2] out: libexec/atf/atf-sh/atf_check_test:info_ok  ->  passed  [0.938s]
[192.168.10.2] out: libexec/atf/atf-sh/atf_check_test:null_stderr  ->  passed  [0.424s]
[192.168.10.2] out: libexec/atf/atf-sh/atf_check_test:null_stdout  ->  passed  [1.100s]
[192.168.10.2] out: libexec/atf/atf-sh/config_test:get  ->  passed  [0.762s]
[192.168.10.2] out: libexec/atf/atf-sh/config_test:has  ->  passed  [0.495s]
[192.168.10.2] out: libexec/atf/atf-sh/integration_test:arguments  ->  passed  [1.076s]
[192.168.10.2] out: libexec/atf/atf-sh/integration_test:custom_shell__command_line  ->  passed  [0.768s]
[192.168.10.2] out: libexec/atf/atf-sh/integration_test:custom_shell__shebang  ->  passed  [0.462s]
(Continue reading)

jenkins-admin | 27 Jul 16:54 2015
Picon

FreeBSD_HEAD - Build #3011 - Failure

FreeBSD_HEAD - Build #3011 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3011/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3011/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3011/console

Change summaries:

285909 by marius:
- Probe UICLASS_CDC/UISUBCLASS_ABSTRACT_CONTROL_MODEL/0xff again. This
  variant of Microsoft RNDIS, i. e. their unofficial version of CDC ACM,
  has been disabled in r261544 for resolving a conflict with umodem(4).
  Eventually, in r275790 that problem was dealt with in the right way.
  However, r275790 failed to put probing of RNDIS devices in question
  back.
- Initialize the device prior to querying it, as required by the RNDIS
  specification. Otherwise already determining the MAC address may fail
  rightfully.
- On detach, halt the device again.
- Use UCDC_SEND_ENCAPSULATED_{COMMAND,RESPONSE}. While these macros are
  resolving to the same values as UR_{CLEAR_FEATURE,GET_STATUS}, the
  former set is way more appropriate in this context.
- Report unknown - rather: unimplemented - events unconditionally and
  not just in debug mode. This ensures that we'll get some hint of what
  is going wrong instead of the driver silently failing.
- Deal with the Microsoft ActiveSync requirement of using an input buffer
  the size of the expected reply or larger - except for variably sized
  replies - when querying a device.
- Fix some pointless NULL checks, style bugs etc.

(Continue reading)

jenkins-admin | 27 Jul 16:18 2015
Picon

FreeBSD_HEAD_i386 - Build #686 - Failure

FreeBSD_HEAD_i386 - Build #686 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/686/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/686/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/686/console

Change summaries:

285909 by marius:
- Probe UICLASS_CDC/UISUBCLASS_ABSTRACT_CONTROL_MODEL/0xff again. This
  variant of Microsoft RNDIS, i. e. their unofficial version of CDC ACM,
  has been disabled in r261544 for resolving a conflict with umodem(4).
  Eventually, in r275790 that problem was dealt with in the right way.
  However, r275790 failed to put probing of RNDIS devices in question
  back.
- Initialize the device prior to querying it, as required by the RNDIS
  specification. Otherwise already determining the MAC address may fail
  rightfully.
- On detach, halt the device again.
- Use UCDC_SEND_ENCAPSULATED_{COMMAND,RESPONSE}. While these macros are
  resolving to the same values as UR_{CLEAR_FEATURE,GET_STATUS}, the
  former set is way more appropriate in this context.
- Report unknown - rather: unimplemented - events unconditionally and
  not just in debug mode. This ensures that we'll get some hint of what
  is going wrong instead of the driver silently failing.
- Deal with the Microsoft ActiveSync requirement of using an input buffer
  the size of the expected reply or larger - except for variably sized
  replies - when querying a device.
- Fix some pointless NULL checks, style bugs etc.

(Continue reading)

Slawa Olhovchenkov | 27 Jul 14:14 2015
Picon

Re: duration of buildworld

On Mon, Jul 27, 2015 at 01:06:15PM +0100, David Chisnall wrote:

> On 27 Jul 2015, at 13:00, Slawa Olhovchenkov <slw <at> zxy.spb.ru> wrote:
> > 
> > May be swap trashing on clang compilation?
> 
> 4GB ought to be enough for building clang with -j2.  A few of the
> template-heavy files can use 500+MB of RAM compiling and linking
> with BFD ld can easily hit 1GB (a lot more for a debug build - don't
> try this on a 32-bit system!).

I am try building 9.x with lot of memory and see about 1GB consumption
when comiling (not linking) four clang library. I am don't know how
clang in head consumption memory with self-compilation. And we don't
know about available memory at this system (may be firefox runing?)

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Hans Petter Selasky | 27 Jul 13:02 2015

E1000 mbuf leaks

Hi,

I'm currently doing some busdma work, and possibly stepped over some 
driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf 
chain is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()" 
for that error code or is there a possible memory leak in all E1000 
drivers? See attached patch.

> Index: if_em.c
> ===================================================================
> --- if_em.c	(revision 284591)
> +++ if_em.c	(working copy)
>  <at>  <at>  -2027,9 +2027,6  <at>  <at> 
>  		/* Try it again, but only once */
>  		remap = 0;
>  		goto retry;
> -	} else if (error == ENOMEM) {
> -		adapter->no_tx_dma_setup++;
> -		return (error);
>  	} else if (error != 0) {
>  		adapter->no_tx_dma_setup++;
>  		m_freem(*m_headp);
> Index: if_igb.c
> ===================================================================
> --- if_igb.c	(revision 284591)
> +++ if_igb.c	(working copy)
>  <at>  <at>  -1905,9 +1905,6  <at>  <at> 
>  				goto retry;
>  			} else
>  				return (error);
(Continue reading)

Matthias Apitz | 27 Jul 07:58 2015
Picon

duration of buildworld


Hello,

Yesterday I grabbed r285885 from SVN and launched a 

# make -j2 buildworld

which is still running after 19 hours on a server of 2 CPU of the type
Intel(R) Core(TM)2 Extreme CPU X9100   <at>  3.06GHz and 4 GByte memory.

Last time in January with r276659 on the same host it took only some 8
hours, IIRC.

Is there anything wrong of what could cause this change of the build
time?

Thanks

	matthias

--

-- 
Matthias Apitz, ✉ guru <at> unixarea.de, http://www.unixarea.de/  ☎ +49-176-38902045
No! Nein! ¡No! Όχι! -- Ευχαριστούμε!
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Benjamin Kaduk | 27 Jul 04:38 2015
Picon

FreeBSD Quarterly Status Report - Second Quarter 2015


FreeBSD Project Quarterly Status Report: April - June 2015

   The second quarter of 2015, from April to June, was another period of
   busy activity for FreeBSD. This report is the largest we have published
   so far.

   The cluster and release engineering teams continued to improve the
   structures that support FreeBSD's build, maintenance, and installation.
   Projects ran the gamut from security and speed improvements to
   virtualization and storage appliances. New kernel drivers and
   capabilities were added, while work to make FreeBSD run on various ARM
   architectures continued at a rapid pace. The Ports Collection grew,
   even while adding capabilities and fixing problems. Outside projects
   like pkgsrc have become interested in adding support. Documentation was
   a major focus, one that is often complimented by people new to FreeBSD.
   BSDCan 2015 was a great success, turning many hours of sleep
   deprivation into an even greater amount of inspiration.

   As always, a great deal of this activity was directly sponsored by the
   Foundation. The project's status as a first-class operating system owes
   a great deal to the Foundation's past and ongoing work.

   The number and detail of these reports really gives only a tiny glimpse
   of all that is happening. A huge portion of FreeBSD development takes
   place all the time, including bug fixes, feature improvements,
   rewrites, and imports of new code. This ongoing work is difficult,
   time-consuming, and, far too often, unrecognized. We should take a
   moment to consider and thank not just the contributors listed here, but
   also the end users, bug submitters, port maintainers, coders, security
(Continue reading)

jenkins-admin | 27 Jul 02:07 2015
Picon

FreeBSD_HEAD-tests - Build #1224 - Unstable

FreeBSD_HEAD-tests - Build #1224 - Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1224/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1224/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1224/console

Change summaries:

No changes

The end of the build log:

[...truncated 4434 lines...]
[192.168.10.2] out: sys/kern/kern_descrip_test:kern_maxfiles__increase  ->  skipped: Required
configuration property 'allow_sysctl_side_effects' not defined  [0.000s]
[192.168.10.2] out: sys/kern/ptrace_test:ptrace__parent_sees_exit_after_child_debugger  -> 
passed  [0.086s]
[192.168.10.2] out: sys/kern/ptrace_test:ptrace__parent_sees_exit_after_unrelated_debugger  -> 
passed  [0.108s]
[192.168.10.2] out: sys/kern/ptrace_test:ptrace__parent_wait_after_attach  ->  passed  [0.052s]
[192.168.10.2] out: sys/kern/ptrace_test:ptrace__parent_wait_after_trace_me  ->  passed  [0.098s]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:accept  ->  passed  [0.246s]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:bind  ->  passed  [0.037s]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:connect  ->  passed  [0.037s]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:create_socket  ->  passed  [0.088s]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:create_socketpair  ->  passed  [0.044s]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:eagain_128k_128k  ->  passed  [0.046s]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:eagain_128k_8k  ->  passed  [0.038s]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:eagain_8k_128k  ->  passed  [0.037s]
[192.168.10.2] out: sys/kern/unix_seqpacket_test:eagain_8k_8k  ->  passed  [0.074s]
(Continue reading)


Gmane