Le Wed, 25 Sep 2013 11:06:33 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
I'd like to understand why you think protecting these functions
w/ the _DETACHED check is correct... In kern_event.c, all
Le Wed, 25 Sep 2013 00:21:27 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
I'd like to understand why you think protecting these functions w/
the _DETACHED check is correct... In kern_event.c, all calls to
On Wed, Sep 25, 2013 at 09:58:05AM +0200, Patrick Lamaiziere wrote:
Le Wed, 25 Sep 2013 00:21:27 +0300,
Konstantin Belousov kostik...@gmail.com a ?crit :
Hello,
On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
I'd like to understand why you think protecting these
Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300:
On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
I'd like to understand why you think protecting these functions w/
the _DETACHED check is correct... In kern_event.c, all calls to
f_detach are
On Wed, Sep 25, 2013 at 09:19:54AM -0700, John-Mark Gurney wrote:
Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300:
On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
I'd like to understand why you think protecting these functions w/
the _DETACHED
Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 22:40 +0300:
On Wed, Sep 25, 2013 at 09:19:54AM -0700, John-Mark Gurney wrote:
Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300:
On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
I'd
Le Mon, 23 Sep 2013 23:31:41 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
...
Ok This has been mfced to 9.2-STABLE. But I still see this panic
with 9-2/STABLE of today (Revision : 255811). This may be better
because before the box paniced within minutes and now within
On Tue, Sep 24, 2013 at 09:44:27AM +0200, Patrick Lamaiziere wrote:
Le Mon, 23 Sep 2013 23:31:41 +0300,
Konstantin Belousov kostik...@gmail.com a ?crit :
Hello,
...
Ok This has been mfced to 9.2-STABLE. But I still see this panic
with 9-2/STABLE of today (Revision : 255811). This
Le Tue, 24 Sep 2013 11:29:09 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
...
Ok This has been mfced to 9.2-STABLE. But I still see this panic
with 9-2/STABLE of today (Revision : 255811). This may be better
because before the box paniced within minutes and now
On Tue, Sep 24, 2013 at 11:47:38AM +0200, Patrick Lamaiziere wrote:
Le Tue, 24 Sep 2013 11:29:09 +0300,
Konstantin Belousov kostik...@gmail.com a ?crit :
Hello,
...
Ok This has been mfced to 9.2-STABLE. But I still see this panic
with 9-2/STABLE of today (Revision : 255811).
Konstantin Belousov wrote this message on Tue, Sep 24, 2013 at 15:14 +0300:
On Tue, Sep 24, 2013 at 11:47:38AM +0200, Patrick Lamaiziere wrote:
Le Tue, 24 Sep 2013 11:29:09 +0300,
Konstantin Belousov kostik...@gmail.com a ?crit :
Hello,
...
Ok This has been mfced to
On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
I'd like to understand why you think protecting these functions w/
the _DETACHED check is correct... In kern_event.c, all calls to
f_detach are followed by knote_drop which will ensure that the knote
is removed and free, so no
Le Fri, 20 Sep 2013 15:17:05 +0200,
Patrick Lamaiziere patf...@davenulle.org a écrit :
Le Thu, 12 Sep 2013 10:36:43 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
Might be, your issue is that some filesystems do not care about
proper locking mode for the fifos. UFS
On Mon, Sep 23, 2013 at 03:37:08PM +0200, Patrick Lamaiziere wrote:
Le Fri, 20 Sep 2013 15:17:05 +0200,
Patrick Lamaiziere patf...@davenulle.org a ?crit :
Le Thu, 12 Sep 2013 10:36:43 +0300,
Konstantin Belousov kostik...@gmail.com a ?crit :
Hello,
Might be, your issue is that
Le Thu, 12 Sep 2013 10:36:43 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
Might be, your issue is that some filesystems do not care about proper
locking mode for the fifos. UFS carefully disables shared locking for
VFIFO, but it seems ZFS is not. I can propose the
On Wed, Sep 11, 2013 at 11:18:34PM +0200, Jimmy Olgeni wrote:
Hi,
On Wed, 11 Sep 2013, Konstantin Belousov wrote:
Also, do you have all options listed at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
enabled ?
This time I tried
On Wed, Sep 11, 2013 at 10:32:31PM +0200, Jimmy Olgeni wrote:
Hi,
On Wed, 11 Sep 2013, Konstantin Belousov wrote:
Could you list the lines around the the vfs_subr.c:4591 in your kernel ?
4591 is the VI_LOCK(vp) in filt_vfsvnode:
static int
filt_vfsvnode(struct knote *kn, long
On Thu, 12 Sep 2013, Konstantin Belousov wrote:
This time I tried with clang + these options and I got something more
interesting. All works fine until the lock violation below:
Clang is, well, not relevant there.
Still, with clang I could get a hard reset rather than a hang. But
maybe
On Thu, 12 Sep 2013, Konstantin Belousov wrote:
4591 is the VI_LOCK(vp) in filt_vfsvnode:
static int
filt_vfsvnode(struct knote *kn, long hint)
{
struct vnode *vp = (struct vnode *)kn-kn_hook;
int res;
VI_LOCK(vp);
^^^
if (kn-kn_sfflags
on 12/09/2013 10:36 Konstantin Belousov said the following:
UFS carefully disables shared locking for
VFIFO, but it seems ZFS is not.
In fact, ZFS should do that since r253603 (MFC-ed to stables as r254694 and
r254695): http://svnweb.freebsd.org/changeset/base/253603
If it still doesn't then
On Thu, 12 Sep 2013, Konstantin Belousov wrote:
Might be, your issue is that some filesystems do not care about proper
locking mode for the fifos. UFS carefully disables shared locking for
VFIFO, but it seems ZFS is not. I can propose the following band-aid,
which could help you.
This
On Thu, Sep 12, 2013 at 08:28:48PM +0200, Jimmy Olgeni wrote:
On Thu, 12 Sep 2013, Konstantin Belousov wrote:
Might be, your issue is that some filesystems do not care about proper
locking mode for the fifos. UFS carefully disables shared locking for
VFIFO, but it seems ZFS is not. I
On Thu, 12 Sep 2013, Konstantin Belousov wrote:
This certainly seems to improve things. I have been running builds
for the past couple of hours without any critical problem.
Ok, so it is ZFS indeed. I think I will commit the band-aid to head
shortly.
Thank you!
I spotted a few LORs but
on 12/09/2013 21:49 Konstantin Belousov said the following:
On Thu, Sep 12, 2013 at 08:28:48PM +0200, Jimmy Olgeni wrote:
On Thu, 12 Sep 2013, Konstantin Belousov wrote:
Might be, your issue is that some filesystems do not care about proper
locking mode for the fifos. UFS carefully disables
On Fri, Sep 13, 2013 at 12:40:28AM +0300, Andriy Gapon wrote:
on 12/09/2013 21:49 Konstantin Belousov said the following:
Ok, so it is ZFS indeed. I think I will commit the band-aid to head
shortly.
I am not sure if my message 5231a016.7060...@freebsd.org was intercepted by
NSA and
11.09.2013 18:07, Jimmy Olgeni wrote:
Perhaps I found something weird while running 9.2-RC3 FreeBSD
9.2-RC3 #0 r255393 (ZFS-only setup).
Unfortunately I'm not able to get a minidump for the latest RC, but at this
point I suspect that something is going on with glib20 and kqueue on both
On Wed, Sep 11, 2013 at 05:07:10PM +0200, Jimmy Olgeni wrote:
- However, this time I managed to get a minidump from the old -STABLE. I
saved it here:
http://olgeni.olgeni.com/~olgeni/core.txt.0
Could you list the lines around the the vfs_subr.c:4591 in your kernel ?
Also, do you have
Hi,
On Wed, 11 Sep 2013, Konstantin Belousov wrote:
Could you list the lines around the the vfs_subr.c:4591 in your kernel ?
4591 is the VI_LOCK(vp) in filt_vfsvnode:
static int
filt_vfsvnode(struct knote *kn, long hint)
{
struct vnode *vp = (struct vnode *)kn-kn_hook;
int
On Wed, 11 Sep 2013, Volodymyr Kostyrko wrote:
Can you try to build world WITH_CLANG_IS_CC? Clang generated code is known to
produce an instant coredump in situations where gcc generated code hits a
loop or becomes unresponsive.
I removed ccache, rebuilt with WITH_CLANG_IS_CC and it worked
On Wed, 11 Sep 2013, Volodymyr Kostyrko wrote:
11.09.2013 18:07, Jimmy Olgeni wrote:
Perhaps I found something weird while running 9.2-RC3 FreeBSD
9.2-RC3 #0 r255393 (ZFS-only setup).
Unfortunately I'm not able to get a minidump for the latest RC, but at this
point I suspect that
Hello,
Perhaps I found something weird while running 9.2-RC3 FreeBSD
9.2-RC3 #0 r255393 (ZFS-only setup).
Quick history of the problem:
- Lately, using a very recent -STABLE, the host would hang randomly while
building ports with poudriere (-J2) and using X11, without producing a
core
Hi,
On Wed, 11 Sep 2013, Konstantin Belousov wrote:
Also, do you have all options listed at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
enabled ?
This time I tried with clang + these options and I got something more
interesting. All works
32 matches
Mail list logo
