On 02 Jan, 2016, at 12:01 EST, Taylor R Campbell
wrote:
> Date: Fri, 1 Jan 2016 14:37:53 -0500
> From: Thor Lancelot Simon
> If I do that, we'll get a cpurng entropy source even on CPUs that don't
> actually have one. I'd rather
Hi,
Thank you for comments. I update the patch.
On 2015/12/25 17:49, Kengo NAKAHARA wrote:
> I MP-ify gif(4) interface and ip_encap which is required by gif(4).
>
> Here is the patch
> http://www.netbsd.org/~knakahara/gif-mp-ify/gif-mp-ify.patch
Here is the updated patch.
On Tue, 5 Jan 2016, Taylor R Campbell wrote:
Date: Tue, 5 Jan 2016 09:39:15 +0800 (PHT)
From: Paul Goyette
On Tue, 5 Jan 2016, Taylor R Campbell wrote:
> So I think DIAGNOSTIC condition is wrong. I think the right condition
> is probably uio->uio_vmspace ==
Continuing on the saga of using filemon(4) and specifying STDOUT_FILENO
for the activity log ... (I got the answer to my earlier question so
quickly, I figure maybe I'll get lucky again!)
With the recently-committed change to spec_vnops.c rev 1.60, the filemon
code now successfully writes
Date: Tue, 5 Jan 2016 17:30:35 +0900
From: Kengo NAKAHARA
I use rw_init() for gif_softc_list_lock instead of rw_obj_alloc().
However, I still use rw_obj_alloc() for struct gif_softc.gif_lock.
If I use rw_init() for struct gif_softc.gif_lock, it would be the
p...@vps1.whooppee.com (Paul Goyette) writes:
>cv_wait() at cv_wait+0x116
>fd_close() at fd_close+0x39a
>fd_free() at fd_free+0x178
>exit1() at exit1+0x10a
>sys_exit() at sys_exit+0x3a
>syscall() at syscall+0x9c
>--- syscall (number 1) ---
>So I guess I need to figure out which/what condvar it
On Wed, Jan 06, 2016 at 11:38:00AM +0800, Paul Goyette wrote:
> On Wed, 6 Jan 2016, Taylor R Campbell wrote:
>
> > Date: Tue, 5 Jan 2016 21:48:42 -0500
> > From: Thor Lancelot Simon
> >
> > You can probably use workqueues for this. Looking at the manual page
> > again for
Hi,
On 2016/01/06 3:40, Taylor R Campbell wrote:
>Date: Tue, 5 Jan 2016 17:30:35 +0900
>From: Kengo NAKAHARA
>
>I use rw_init() for gif_softc_list_lock instead of rw_obj_alloc().
>However, I still use rw_obj_alloc() for struct gif_softc.gif_lock.
>If I
Date: Tue, 5 Jan 2016 21:48:42 -0500
From: Thor Lancelot Simon
You can probably use workqueues for this. Looking at the manual page
again for the first time in years, I think it's a little misleading --
what I believe is meant by "A work must not be enqueued again
On Wed, Jan 06, 2016 at 08:10:36AM +0800, Paul Goyette wrote:
>
> Does anyone have any good suggestions for how to arrange for another
> thread/lwp to run so it can remove the extra reference to the logging
> descriptor?
You can probably use workqueues for this. Looking at the manual page
again
On Wed, 6 Jan 2016, Taylor R Campbell wrote:
Date: Tue, 5 Jan 2016 21:48:42 -0500
From: Thor Lancelot Simon
You can probably use workqueues for this. Looking at the manual page
again for the first time in years, I think it's a little misleading --
what I believe is
On Tue, 5 Jan 2016, Thor Lancelot Simon wrote:
On Wed, Jan 06, 2016 at 11:38:00AM +0800, Paul Goyette wrote:
On Wed, 6 Jan 2016, Taylor R Campbell wrote:
Date: Tue, 5 Jan 2016 21:48:42 -0500
From: Thor Lancelot Simon
You can probably use workqueues for this. Looking at
p...@whooppee.com (Paul Goyette) writes:
>I'm pretty sure that the device in question is the console terminal
>driver /dev/console since the problem does not happen if filemon is
>sending the entries to a "real" file. But I can't figure why it is
>waiting, so I don't know what I should do to
On Tue, 5 Jan 2016, Stephan wrote:
# crash
Crash version 7.99.25, image version 7.99.25.
Output from a running system is unreliable.
crash> trace/t 0t455
trace: pid 455 lid 1 at 0xfe8002ff0ce0
sleepq_block() at sleepq_block+0xa2
cv_wait() at cv_wait+0x116
fd_close() at fd_close+0x39a
On Tue, 5 Jan 2016, Michael van Elst wrote:
p...@vps1.whooppee.com (Paul Goyette) writes:
cv_wait() at cv_wait+0x116
fd_close() at fd_close+0x39a
fd_free() at fd_free+0x178
exit1() at exit1+0x10a
sys_exit() at sys_exit+0x3a
syscall() at syscall+0x9c
--- syscall (number 1) ---
So I guess I
> # crash
> Crash version 7.99.25, image version 7.99.25.
> Output from a running system is unreliable.
> crash> trace/t 0t455
> trace: pid 455 lid 1 at 0xfe8002ff0ce0
> sleepq_block() at sleepq_block+0xa2
> cv_wait() at cv_wait+0x116
> fd_close() at fd_close+0x39a
> fd_free() at fd_free+0x178
> # crash
> Crash version 7.99.25, image version 7.99.25.
> Output from a running system is unreliable.
> crash> trace/t 0t455
> trace: pid 455 lid 1 at 0xfe8002ff0ce0
> sleepq_block() at sleepq_block+0xa2
> cv_wait() at cv_wait+0x116
> fd_close() at fd_close+0x39a
> fd_free() at fd_free+0x178
On Wed, 6 Jan 2016, Paul Goyette wrote:
I need to figure out why this is a problem when filemon(4) "borrows" the fd
for stdout, but is not a problem when it borrows a real file.
OK, I figured out what's going on.
In the failure scenario, we have the following events:
1. Process
This scenario reminds me of:
https://www.sqlite.org/compile.html#minimum_file_descriptor
-bch
On 1/5/16, Paul Goyette wrote:
> On Wed, 6 Jan 2016, Paul Goyette wrote:
>
>> I need to figure out why this is a problem when filemon(4) "borrows" the
>> fd
>> for stdout,
On Tue, 5 Jan 2016, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
I'm pretty sure that the device in question is the console terminal
driver /dev/console since the problem does not happen if filemon is
sending the entries to a "real" file. But I can't figure why it is
20 matches
Mail list logo