Hi,
> A PR (Problem Report) in the kern category with an attached unified
> diff would seem adequate if you cannot commit the changes yourself.
I am glad that others will filter my proposals.
kern/48787 can be counted as a successful one.
kern/48797 demonstrates that i need to free myself more f
On Sat, 10 May 2014 01:29:47 +
Taylor R Campbell wrote:
>Is it expected in vcache_common() for the interlock to remain held even
>if returning an error?
>
> vget unconditionally drops the interlock, so it will never remain
> held, error or not.
Oh, thanks. I can now see that vget()
Date: Fri, 9 May 2014 19:01:04 -0400
From: Matthew Mondor
Is it expected in vcache_common() for the interlock to remain held even
if returning an error?
vget unconditionally drops the interlock, so it will never remain
held, error or not.
On Wed, 30 Apr 2014 17:15:16 +0200
"J. Hannken-Illjes" wrote:
> > vcache_get(mp, key, key_len, vpp) to lookup and possibly load a vnode.
> > vcache_lookup(mp, key, key_len, vpp) to lookup a vnode.
> > vcache_remove(mp, key, key_len) to remove a vnode from the cache.
> > VFS_LOAD_NODE(mp, vp, key,
On Tue, 06 May 2014 12:20:53 +0200
"Thomas Schmitt" wrote:
> How to properly submit them ?
A PR (Problem Report) in the kern category with an attached unified
diff would seem adequate if you cannot commit the changes yourself.
Sorry if that is already obvious to you.
Unfortunately I'm not perso
This just started happening to me recently on my mail server. I added
some info to PR kern/48586 but I am not entirely sure that I have the
same issue. I am running Postfix from the base plus Dovecot, Apache
and Spamassassin daemon from pkgsrc.
This happens to me at least once a day and can't be
