Can somebody with the necessary skills help me with this?
$ cd /usr/ports/devel/libinotify/ make clean fake make test
I remember this used to work... Now, most of the times, the
'check_libinotify' process brings the CPU to 100% and it's stuck
in a sched_yield() loop:
31456/1022146
This diff is a first step towards removing all pseudo-driver #ifdef
in ether_output(). As for ether_input() the goal of this work is to
provide an elegant design to make it easier to turn pseudo-drivers
MP-safe.
So instead of including some bridge(4), vlan(4) and carp(4) specific
code in
On Wed, May 06, 2015 at 09:33:02PM -0400, James Turner wrote:
So I'm not quite sure how to explain this but I'm getting similiar
emails to the one below and it seems like opensmtpd should be rejecting
them as they don't seem like they are a valid format.
Have others seen emails like these?
On 6 May 2015 at 13:05, Martin Pieuchot m...@openbsd.org wrote:
On 20/04/15(Mon) 18:37, Mike Belopuhov wrote:
On Tue, Apr 14, 2015 at 22:08 +0300, Lauri Tirkkonen wrote:
On Tue, Apr 14 2015 20:40:58 +0200, Mike Belopuhov wrote:
According to 3.2 in RFC 7323:
Once TSopt has been
On 14 April 2015 at 21:08, Lauri Tirkkonen loth...@iki.fi wrote:
On Tue, Apr 14 2015 20:40:58 +0200, Mike Belopuhov wrote:
According to 3.2 in RFC 7323:
Once TSopt has been successfully negotiated, that is both SYN and
SYN,ACK contain TSopt, the TSopt MUST be sent in every non-RST
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's interrupts can interrupt on the
other one. Since we'll most likely be holding a kernel lock,
dealing with unlocking it might get hairy very fast. Instead
what we could do to improve the chances of a clean
Hi,
I'm investigating Alf Schlichting's report [1] of regression in ld.so
caused by my diff [2]. This regression reproduces on amd64-current too.
I found errors in my diff which break the dlclose/test1/prog2 test. But
what's really interesting -- is the dlclose/test1/prog3 test.
I found that
Hi,
As found while running the git test-suite (for an upcoming update
to git-2.4.0):
dcoppa@t420:/usr/pobj/git-2.4.0/git-2.4.0/t/trash directory.t7001-mv$ cd sub
dcoppa@t420:/usr/pobj/git-2.4.0/git-2.4.0/t/trash directory.t7001-mv/sub$ rm
-rf .git
By doing complex VFS shutdown operation, the system's memory image will
be modified a lot since a panic was triggered. I'd totally skip
vfs_shutdown() after a panic [1], then do the best to dump a kernel core
for analysis.
[1] OpenBSD's panic(9) sets RB_NOSYNC only when panicstr is already set
On Thu, May 7, 2015 at 5:42 PM, Sviatoslav Chagaev
sviatoslav.chag...@gmail.com wrote:
...
If we read the dynamic symbol tables of both libraries, here's what we
see:
$ readelf -sD libaa/libaa.so.1.0 libbb/libbb.so.1.0 | grep dup
31 34: 0bc0 3FUNC
On Wed, May 6, 2015 at 2:54 PM, Harri Porten por...@froglogic.com wrote:
Hi!
We've started to generate code coverage reports for test suites of some
projects on a regular basis. You'll find on overview for LibreSSL (Portable)
here:
In the not far future fd_getfile() will return the referenced file
instance, so dupfdopen() should be modified for the same reasons
that getsock() and getvnode().
The modified dupfdopen() receives a thread pointer instead of it's
file descriptor table and of it's file descriptor for duplication.
On Tue, May 05, 2015 at 11:02 -0700, Philip Guenther wrote:
On Tue, May 5, 2015 at 9:35 AM, Mike Belopuhov m...@belopuhov.com wrote:
...
Here's a diff to remedy this. This is the same chunk as in the
tsleep, except it uses semantics of msleep. IPL dance is there
to negate the IPL
13 matches
Mail list logo
