Le Wed, 25 Sep 2013 11:06:33 +0300,
Konstantin Belousov 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
> > > > call
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:
> >
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 _D
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 ar
On Wed, Sep 25, 2013 at 09:58:05AM +0200, Patrick Lamaiziere wrote:
> Le Wed, 25 Sep 2013 00:21:27 +0300,
> Konstantin Belousov 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/
>
Le Wed, 25 Sep 2013 00:21:27 +0300,
Konstantin Belousov 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
> > f_detach ar
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
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 a ?crit :
> >
> > Hello,
> >
> > ...
> >
> > > > > > Ok This has been mfced to 9.2-ST
On Tue, Sep 24, 2013 at 11:47:38AM +0200, Patrick Lamaiziere wrote:
> Le Tue, 24 Sep 2013 11:29:09 +0300,
> Konstantin Belousov 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 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 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 b
Le Mon, 23 Sep 2013 23:31:41 +0300,
Konstantin Belousov 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 hours
> > (sti
On Mon, Sep 23, 2013 at 03:37:08PM +0200, Patrick Lamaiziere wrote:
> Le Fri, 20 Sep 2013 15:17:05 +0200,
> Patrick Lamaiziere a ?crit :
>
> > Le Thu, 12 Sep 2013 10:36:43 +0300,
> > Konstantin Belousov a ?crit :
> >
> > Hello,
> >
> > > Might be, your issue is that some filesystems do not car
Le Fri, 20 Sep 2013 15:17:05 +0200,
Patrick Lamaiziere a écrit :
> Le Thu, 12 Sep 2013 10:36:43 +0300,
> Konstantin Belousov 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
> > lock
Le Thu, 12 Sep 2013 10:36:43 +0300,
Konstantin Belousov 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 following band-aid,
> wh
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
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 carefu
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 no
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
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 certa
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 i
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 & hi
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 there
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
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
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
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 something
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 dump
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 f
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, 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 h
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
-STABL
32 matches
Mail list logo