Re: Possible kqueue related issue on STABLE/RC.
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 hours
(still using poudriere).
panic:
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808ebfcd
stack pointer = 0x28:0xff824c2e0630
frame pointer = 0x28:0xff824c2e06a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 54243 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80939ad6 at kdb_backtrace+0x66
#1 0x808ffacd at panic+0x1cd
#2 0x80cdfbe9 at trap_fatal+0x289
#3 0x80cdff4f at trap_pfault+0x20f
#4 0x80ce0504 at trap+0x344
#5 0x80cc9b43 at calltrap+0x8
#6 0x8099d043 at filt_vfsvnode+0xf3
#7 0x808c4793 at kqueue_register+0x3e3
#8 0x808c4de8 at kern_kevent+0x108
#9 0x808c5950 at sys_kevent+0x90
#10 0x80cdf3a8 at amd64_syscall+0x5d8
#11 0x80cc9e27 at Xfast_syscall+0xf7
Full core.txt :
http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for
frame 8
p *kn
(kgdb) frame 8
#8 0x8099d043 in filt_vfsvnode (kn=0xfe0147a7f000, hint=0)
at /usr/src/sys/kern/vfs_subr.c:4600
4600VI_LOCK(vp);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0},
kn_kq = 0xfe01079a6200, kn_kevent = {ident = 62, filter = -4,
flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status = 24,
kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp = 0xfe016949e190,
p_proc = 0xfe016949e190, p_aio = 0xfe016949e190,
p_lio = 0xfe016949e190}, kn_fop = 0x812fd440,
kn_hook = 0xfe0119d0b1f8, kn_hookid = 0}
Also, please follow
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
to recompile kernel with the debugging options and try to recreate
the panic.
It's building.
Thanks, regards
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
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 may be better
because before the box paniced within minutes and now within hours
(still using poudriere).
panic:
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808ebfcd
stack pointer = 0x28:0xff824c2e0630
frame pointer = 0x28:0xff824c2e06a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 54243 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80939ad6 at kdb_backtrace+0x66
#1 0x808ffacd at panic+0x1cd
#2 0x80cdfbe9 at trap_fatal+0x289
#3 0x80cdff4f at trap_pfault+0x20f
#4 0x80ce0504 at trap+0x344
#5 0x80cc9b43 at calltrap+0x8
#6 0x8099d043 at filt_vfsvnode+0xf3
#7 0x808c4793 at kqueue_register+0x3e3
#8 0x808c4de8 at kern_kevent+0x108
#9 0x808c5950 at sys_kevent+0x90
#10 0x80cdf3a8 at amd64_syscall+0x5d8
#11 0x80cc9e27 at Xfast_syscall+0xf7
Full core.txt :
http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for
frame 8
p *kn
(kgdb) frame 8
#8 0x8099d043 in filt_vfsvnode (kn=0xfe0147a7f000, hint=0)
at /usr/src/sys/kern/vfs_subr.c:4600
4600 VI_LOCK(vp);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0},
kn_kq = 0xfe01079a6200, kn_kevent = {ident = 62, filter = -4,
flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status = 24,
kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp = 0xfe016949e190,
p_proc = 0xfe016949e190, p_aio = 0xfe016949e190,
p_lio = 0xfe016949e190}, kn_fop = 0x812fd440,
kn_hook = 0xfe0119d0b1f8, kn_hookid = 0}
From the kgdb, also please do
p *(struct vnode *)0xfe0119d0b1f8
Also, please follow
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
to recompile kernel with the debugging options and try to recreate
the panic.
It's building.
Please try the following.
diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
index aa165a0..5715f35 100644
--- a/sys/kern/vfs_subr.c
+++ b/sys/kern/vfs_subr.c
@@ -4421,10 +4421,14 @@ filt_vfsdetach(struct knote *kn)
static int
filt_vfsread(struct knote *kn, long hint)
{
- struct vnode *vp = (struct vnode *)kn-kn_hook;
+ struct vnode *vp;
struct vattr va;
int res;
+ if ((kn-kn_status KN_DETACHED) != 0)
+ return (0);
+ vp = (struct vnode *)kn-kn_hook;
+
/*
* filesystem is gone, so set the EOF flag and schedule
* the knote for deletion.
@@ -4450,8 +4454,11 @@ filt_vfsread(struct knote *kn, long hint)
static int
filt_vfswrite(struct knote *kn, long hint)
{
- struct vnode *vp = (struct vnode *)kn-kn_hook;
+ struct vnode *vp;
+ if ((kn-kn_status KN_DETACHED) != 0)
+ return (0);
+ vp = (struct vnode *)kn-kn_hook;
VI_LOCK(vp);
/*
@@ -4469,9 +4476,12 @@ filt_vfswrite(struct knote *kn, long hint)
static int
filt_vfsvnode(struct knote *kn, long hint)
{
- struct vnode *vp = (struct vnode *)kn-kn_hook;
+ struct vnode *vp;
int res;
+ if ((kn-kn_status KN_DETACHED) != 0)
+ return (0);
+ vp = (struct vnode *)kn-kn_hook;
VI_LOCK(vp);
if (kn-kn_sfflags hint)
kn-kn_fflags |= hint;
pgp0ungmMXQcb.pgp
Description: PGP signature
Re: Possible kqueue related issue on STABLE/RC.
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 within
hours (still using poudriere).
panic:
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808ebfcd
stack pointer = 0x28:0xff824c2e0630
frame pointer = 0x28:0xff824c2e06a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 54243 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80939ad6 at kdb_backtrace+0x66
#1 0x808ffacd at panic+0x1cd
#2 0x80cdfbe9 at trap_fatal+0x289
#3 0x80cdff4f at trap_pfault+0x20f
#4 0x80ce0504 at trap+0x344
#5 0x80cc9b43 at calltrap+0x8
#6 0x8099d043 at filt_vfsvnode+0xf3
#7 0x808c4793 at kqueue_register+0x3e3
#8 0x808c4de8 at kern_kevent+0x108
#9 0x808c5950 at sys_kevent+0x90
#10 0x80cdf3a8 at amd64_syscall+0x5d8
#11 0x80cc9e27 at Xfast_syscall+0xf7
Full core.txt :
http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for
frame 8
p *kn
(kgdb) frame 8
#8 0x8099d043 in filt_vfsvnode (kn=0xfe0147a7f000,
hint=0) at /usr/src/sys/kern/vfs_subr.c:4600
4600VI_LOCK(vp);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0},
kn_kq = 0xfe01079a6200, kn_kevent = {ident = 62, filter = -4,
flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status =
24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp =
0xfe016949e190, p_proc = 0xfe016949e190, p_aio =
0xfe016949e190, p_lio = 0xfe016949e190}, kn_fop =
0x812f0, kn_hook = 0xfe0119d0b1f8, kn_hookid = 0}
From the kgdb, also please do
p *(struct vnode *)0xfe0119d0b1f8
With a kernel with debug info, this panic becomes mtx_lock() of
destroyed mutex
panic: mtx_lock() of destroyed mutex
http://user.lamaiziere.net/patrick/public/panic_mtx_lock.txt
@ /usr/src/sys/kern/vfs_subr.c:4600 cpuid = 2
KDB: stack backtrace:
#0 0x80920286 at kdb_backtrace+0x66
#1 0x808e738d at panic+0x1cd
#2 0x808d58d6 at _mtx_lock_flags+0x116
#3 0x8098143b at filt_vfsvnode+0x3b
#4 0x808b213a at kqueue_register+0x4ca
#5 0x808b2688 at kern_kevent+0x108
#6 0x808b3190 at sys_kevent+0x90
#7 0x80cbd975 at amd64_syscall+0x2f5
#8 0x80ca8557 at Xfast_syscall+0xf7
(kgdb) frame 5
#5 0x808b213a in kqueue_register (kq=0xfe00ddc98900,
kev=0xff824bb5f880, td=0xfe00b1e7f000, waitok=1) at
/usr/src/sys/kern/kern_event.c:1136
1136event = kn-kn_fop-f_event(kn, 0);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0xfe011c232b00},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0}, kn_kq =
0xfe00ddc98900,
kn_kevent = {ident = 62, filter = -4, flags = 32784, fflags = 0, data = 0,
udata = 0x0}, kn_status = 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {
p_fp = 0xfe00ddd4d870, p_proc = 0xfe00ddd4d870, p_aio =
0xfe00ddd4d870, p_lio = 0xfe00ddd4d870}, kn_fop = 0x812fcca0,
kn_hook = 0xfe02064a6000, kn_hookid = 0}
(kgdb) p *(struct vnode *)0xfe02064a6000
$2 = {v_type = VBAD, v_tag = 0x80d89084 none, v_op = 0x0, v_data =
0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xfe020d3e6000,
tqe_prev = 0xfe0086625a68}, v_un = {vu_mount = 0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0,
le_prev = 0xff8000de9698}, v_hash = 238022, v_cache_src = {lh_first =
0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfe02064a6060},
v_cache_dd = 0x0,
v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object =
{lo_name = 0x80f56e48 ufs, lo_flags = 91881472, lo_data = 0,
lo_witness = 0xff80006c3400}, lk_lock = 1, lk_exslpfail = 0, lk_timo
= 51, lk_pri = 96, lk_stack = {depth = 12, pcs = {18446744071571296822,
18446744071573768556, 18446744071576111075, 18446744071606114523,
18446744071576111075, 18446744071572113927, 18446744071572067653,
18446744071606111219,
18446744071572016126, 18446744071572018094, 18446744071575427445,
18446744071575340375, 0, 0, 0, 0, 0, 0}}}, v_interlock = {lock_object = {
lo_name = 0x80f6f8a3 vnode interlock, lo_flags
Re: Possible kqueue related issue on STABLE/RC.
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). This may be better
because before the box paniced within minutes and now within
hours (still using poudriere).
panic:
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808ebfcd
stack pointer = 0x28:0xff824c2e0630
frame pointer = 0x28:0xff824c2e06a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 54243 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80939ad6 at kdb_backtrace+0x66
#1 0x808ffacd at panic+0x1cd
#2 0x80cdfbe9 at trap_fatal+0x289
#3 0x80cdff4f at trap_pfault+0x20f
#4 0x80ce0504 at trap+0x344
#5 0x80cc9b43 at calltrap+0x8
#6 0x8099d043 at filt_vfsvnode+0xf3
#7 0x808c4793 at kqueue_register+0x3e3
#8 0x808c4de8 at kern_kevent+0x108
#9 0x808c5950 at sys_kevent+0x90
#10 0x80cdf3a8 at amd64_syscall+0x5d8
#11 0x80cc9e27 at Xfast_syscall+0xf7
Full core.txt :
http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for
frame 8
p *kn
(kgdb) frame 8
#8 0x8099d043 in filt_vfsvnode (kn=0xfe0147a7f000,
hint=0) at /usr/src/sys/kern/vfs_subr.c:4600
4600 VI_LOCK(vp);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0},
kn_kq = 0xfe01079a6200, kn_kevent = {ident = 62, filter = -4,
flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status =
24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp =
0xfe016949e190, p_proc = 0xfe016949e190, p_aio =
0xfe016949e190, p_lio = 0xfe016949e190}, kn_fop =
0x812f0, kn_hook = 0xfe0119d0b1f8, kn_hookid = 0}
From the kgdb, also please do
p *(struct vnode *)0xfe0119d0b1f8
With a kernel with debug info, this panic becomes mtx_lock() of
destroyed mutex
panic: mtx_lock() of destroyed mutex
http://user.lamaiziere.net/patrick/public/panic_mtx_lock.txt
@ /usr/src/sys/kern/vfs_subr.c:4600 cpuid = 2
KDB: stack backtrace:
#0 0x80920286 at kdb_backtrace+0x66
#1 0x808e738d at panic+0x1cd
#2 0x808d58d6 at _mtx_lock_flags+0x116
#3 0x8098143b at filt_vfsvnode+0x3b
#4 0x808b213a at kqueue_register+0x4ca
#5 0x808b2688 at kern_kevent+0x108
#6 0x808b3190 at sys_kevent+0x90
#7 0x80cbd975 at amd64_syscall+0x2f5
#8 0x80ca8557 at Xfast_syscall+0xf7
(kgdb) frame 5
#5 0x808b213a in kqueue_register (kq=0xfe00ddc98900,
kev=0xff824bb5f880, td=0xfe00b1e7f000, waitok=1) at
/usr/src/sys/kern/kern_event.c:1136
1136 event = kn-kn_fop-f_event(kn, 0);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next =
0xfe011c232b00}, kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev =
0x0}, kn_kq = 0xfe00ddc98900,
kn_kevent = {ident = 62, filter = -4, flags = 32784, fflags = 0, data = 0,
udata = 0x0}, kn_status = 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {
p_fp = 0xfe00ddd4d870, p_proc = 0xfe00ddd4d870, p_aio =
0xfe00ddd4d870, p_lio = 0xfe00ddd4d870}, kn_fop = 0x812fcca0,
kn_hook = 0xfe02064a6000, kn_hookid = 0}
(kgdb) p *(struct vnode *)0xfe02064a6000
$2 = {v_type = VBAD, v_tag = 0x80d89084 none, v_op = 0x0, v_data =
0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xfe020d3e6000,
tqe_prev = 0xfe0086625a68}, v_un = {vu_mount = 0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0,
le_prev = 0xff8000de9698}, v_hash = 238022, v_cache_src = {lh_first =
0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfe02064a6060},
v_cache_dd = 0x0,
v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object =
{lo_name = 0x80f56e48 ufs, lo_flags = 91881472, lo_data = 0,
lo_witness = 0xff80006c3400}, lk_lock = 1, lk_exslpfail = 0,
lk_timo = 51, lk_pri = 96, lk_stack = {depth = 12, pcs =
{18446744071571296822,
18446744071573768556, 18446744071576111075, 18446744071606114523,
18446744071576111075, 18446744071572113927, 18446744071572067653,
18446744071606111219,
18446744071572016126,
Re: Possible kqueue related issue on STABLE/RC.
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 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 (still using poudriere).
panic:
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808ebfcd
stack pointer = 0x28:0xff824c2e0630
frame pointer = 0x28:0xff824c2e06a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 54243 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80939ad6 at kdb_backtrace+0x66
#1 0x808ffacd at panic+0x1cd
#2 0x80cdfbe9 at trap_fatal+0x289
#3 0x80cdff4f at trap_pfault+0x20f
#4 0x80ce0504 at trap+0x344
#5 0x80cc9b43 at calltrap+0x8
#6 0x8099d043 at filt_vfsvnode+0xf3
#7 0x808c4793 at kqueue_register+0x3e3
#8 0x808c4de8 at kern_kevent+0x108
#9 0x808c5950 at sys_kevent+0x90
#10 0x80cdf3a8 at amd64_syscall+0x5d8
#11 0x80cc9e27 at Xfast_syscall+0xf7
Full core.txt :
http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for
frame 8
p *kn
(kgdb) frame 8
#8 0x8099d043 in filt_vfsvnode (kn=0xfe0147a7f000,
hint=0) at /usr/src/sys/kern/vfs_subr.c:4600
4600VI_LOCK(vp);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0},
kn_kq = 0xfe01079a6200, kn_kevent = {ident = 62, filter = -4,
flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status =
24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp =
0xfe016949e190, p_proc = 0xfe016949e190, p_aio =
0xfe016949e190, p_lio = 0xfe016949e190}, kn_fop =
0x812f0, kn_hook = 0xfe0119d0b1f8, kn_hookid = 0}
From the kgdb, also please do
p *(struct vnode *)0xfe0119d0b1f8
With a kernel with debug info, this panic becomes mtx_lock() of
destroyed mutex
panic: mtx_lock() of destroyed mutex
http://user.lamaiziere.net/patrick/public/panic_mtx_lock.txt
@ /usr/src/sys/kern/vfs_subr.c:4600 cpuid = 2
KDB: stack backtrace:
#0 0x80920286 at kdb_backtrace+0x66
#1 0x808e738d at panic+0x1cd
#2 0x808d58d6 at _mtx_lock_flags+0x116
#3 0x8098143b at filt_vfsvnode+0x3b
#4 0x808b213a at kqueue_register+0x4ca
#5 0x808b2688 at kern_kevent+0x108
#6 0x808b3190 at sys_kevent+0x90
#7 0x80cbd975 at amd64_syscall+0x2f5
#8 0x80ca8557 at Xfast_syscall+0xf7
(kgdb) frame 5
#5 0x808b213a in kqueue_register (kq=0xfe00ddc98900,
kev=0xff824bb5f880, td=0xfe00b1e7f000, waitok=1) at
/usr/src/sys/kern/kern_event.c:1136
1136event = kn-kn_fop-f_event(kn, 0);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next =
0xfe011c232b00}, kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev =
0x0}, kn_kq = 0xfe00ddc98900,
kn_kevent = {ident = 62, filter = -4, flags = 32784, fflags = 0, data =
0, udata = 0x0}, kn_status = 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {
p_fp = 0xfe00ddd4d870, p_proc = 0xfe00ddd4d870, p_aio =
0xfe00ddd4d870, p_lio = 0xfe00ddd4d870}, kn_fop =
0x812fcca0,
kn_hook = 0xfe02064a6000, kn_hookid = 0}
(kgdb) p *(struct vnode *)0xfe02064a6000
$2 = {v_type = VBAD, v_tag = 0x80d89084 none, v_op = 0x0, v_data
= 0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xfe020d3e6000,
tqe_prev = 0xfe0086625a68}, v_un = {vu_mount = 0x0, vu_socket =
0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0,
le_prev = 0xff8000de9698}, v_hash = 238022, v_cache_src = {lh_first
= 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfe02064a6060},
v_cache_dd = 0x0,
v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object
= {lo_name = 0x80f56e48 ufs, lo_flags = 91881472, lo_data = 0,
lo_witness = 0xff80006c3400}, lk_lock = 1, lk_exslpfail = 0,
lk_timo = 51, lk_pri = 96, lk_stack = {depth = 12, pcs =
{18446744071571296822,
Re: Possible kqueue related issue on STABLE/RC.
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 more f_event calls will be called on that knote.. My current belief is that what happens is a glitch in the kqueue_register(). After a new knote is created and attached, the kq lock is dropped and then f_event() is called. If the vnode is reclaimed or possible freed meantime, f_event() seems to dereference freed memory, since kn_hook points to freed vnode. The issue as I see it is that vnode lifecycle is detached from the knote lifecycle. Might be, only the second patch, which acquires a hold reference on the vnode for each knote, is really needed. But before going into any conclusions, I want to see the testing results. pgpE9EQ09ovgc.pgp Description: PGP signature
FreeBSD 9.1 ix driver vlan problem
Hello Jack, list, I've been dealing with a nagging problem for a day now and decided to ask a quick question here. Basically I am building a brand new FreeBSD 9.1-RELEASE router which has a dual port fiber NIC (X520-SR2 10GbE Dual-Port Server Adapter (82599ES) 10GBASE-SR - LC). The network card is recognized fine by the ix driver and overall works fine. The issue is when I start adding vlans to this card. It seems like every time I add a brand new vlan it freezes all the rest of the vlans already configured on that one physical interface. I loose ping between my locally connected peers. Example: ifconfig vlan200 create # this is OK ifconfig vlan200 inet 1.2.3.1/30 vlan 200 vlandev ix1 description DEBUG # this second line makes the rest of the vlans freeze for 6-7 seconds On the switch side (Juniper) the physical interface flaps. There's nothing in logs/dmesg. If I configure the above vlan on an em0 interface - things are just smooth. I read some similar complaints that have surfaced in the past: * http://readlist.com/lists/freebsd.org/freebsd-net/5/26378.html * http://marc.info/?l=freebsd-netm=130929760904438 Any idea what might be the problem? Any improvements in 9.2-RC4 in this regards? Thank you in advance, -- Rumen Telbizov Unix Systems Administrator http://telbizov.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
