Re: beta2 panic: VAPPEND without VWRITE
schrieb Rick Macklem am 02.10.2011 00:39 (localtime): Harald Schmalzbauer wrote: schrieb Attilio Rao am 01.10.2011 16:49 (localtime): Can you please show the panic message? Sorry, I forgot to add it here: free indoe /var/123088 had 8 blocks panic: VAPPEND withour VWRITE cpuid = 0 KDB: enter: panic [ thread pid 1445 tid 100126 ] Stopped at kbd_enter+0x2b: movq $0,0x918a52(%rip) db bt Tracing pid 1445 tid 100126 td 0xfe000510d460 kdb_enter() at kbd_enter+0x3b panic() at panic+0x180 vn_isdisk() at vn_isdisk ufs_accessx() at ufs_accessx+0x188 vop_stdaccess() at vop_stdaccess+0x43 unionfs_access() at unionfs_access+0x1c4 vn_open_cred() at vn_open_cred+0x547 kern_opneat() at kern_openat+0x1f9 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp = 0x7fffb388, rbp = 0x8 --- I'ts reproducable with exact the same hex-numbers with 'scp' when scp tries to alter knwon_hosts, which is on unionfs. You could try the attached one line patch. Since VAPPEND is a modifier for VWRITE, it makes sense to clear it along with VWRITE, I think? rick Thanks for your help. Unfortunately I can neither comment on the patch, nor reproduce the panic... I tried the patch and all seems fine, but also without the patch (the exactly same kernel some days ago, but machine was rebooted since). Of course, the machine has been rebooted after the panic too, when I was able to reproduce the panic easily. Any idea why the pnaic was once reproducable and now isn't anymore? Of course, _nothing_ was changed since then, besides bootme flag on one GPT partition. 9-beta2 never booted since then... No hardware has changed either !?! *kopfkratz* Thanks, -Harry Here's some LORs, I havenÄt checked if they're already known. I don't have the known-LORs-URL handy... lock order reversal: 1st 0xfe000519c278 unionfs (unionfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:356 2nd 0xfe000519c458 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2246 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vputx() at vputx+0x328 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0x105 vrecycle() at vrecycle+0x4c unionfs_inactive() at unionfs_inactive+0x20 vinactive() at vinactive+0x72 vputx() at vputx+0x386 kern_statat_vnhook() at kern_statat_vnhook+0x11d kern_statat() at kern_statat+0x15 stat() at stat+0x2a syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (188, FreeBSD ELF64, stat), rip = 0x800dc7ecc, rsp = 0x7fffd6a8, rbp = 0x801441190 --- lock order reversal: 1st 0xff80e9bf59f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xfe00051a7a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x909 ufs_mkdir() at ufs_mkdir+0x44d VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x290 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800933eec, rsp = 0x7fffd768, rbp = 0x800c07050 --- lock order reversal: 1st 0xfe000514f818 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134 2nd 0xff80e9bf59f8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:260 3rd 0xfe0005706278 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b vfs_hash_get() at vfs_hash_get+0xd5 ffs_vgetf() at ffs_vgetf+0x48 softdep_sync_buf() at softdep_sync_buf+0x393 ffs_syncvnode() at ffs_syncvnode+0x2b3 ffs_truncate() at ffs_truncate+0x477 ufs_direnter() at ufs_direnter+0x73b ufs_mkdir() at ufs_mkdir+0x44d VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x290 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (136, FreeBSD
Re: BETA2 panic
On 30-09-2011 17:52, Adrian Chadd wrote: Hi, Would you please try this patch? Make sure that witness and the rest of the lock debugging is enabled. I've been working on this problem with someone else on the list (but I can't trigger it myself; I think I need to get some dual-CPU wireless test hardware.) My laptop has been running with your patch for almost 8 hours now. No panics. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
beta2 panic: VAPPEND without VWRITE
Hello, I got the following panic with 9.0-beta2: cpuid = 0 KDB: enter: panic [ thread pid 1445 tid 100126 ] Stopped at kbd_enter+0x2b: movq$0,0x918a52(%rip) db bt Tracing pid 1445 tid 100126 td 0xfe000510d460 kdb_enter() at kbd_enter+0x3b panic() at panic+0x180 vn_isdisk() at vn_isdisk ufs_accessx() at ufs_accessx+0x188 vop_stdaccess() at vop_stdaccess+0x43 unionfs_access() at unionfs_access+0x1c4 vn_open_cred() at vn_open_cred+0x547 kern_opneat() at kern_openat+0x1f9 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp = 0x7fffb388, rbp = 0x8 --- Please tell how to provide more information if needed. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: beta2 panic: VAPPEND without VWRITE
Can you please show the panic message? Attilio 2011/10/1 Harald Schmalzbauer h.schmalzba...@omnilan.de: Hello, I got the following panic with 9.0-beta2: cpuid = 0 KDB: enter: panic [ thread pid 1445 tid 100126 ] Stopped at kbd_enter+0x2b: movq $0,0x918a52(%rip) db bt Tracing pid 1445 tid 100126 td 0xfe000510d460 kdb_enter() at kbd_enter+0x3b panic() at panic+0x180 vn_isdisk() at vn_isdisk ufs_accessx() at ufs_accessx+0x188 vop_stdaccess() at vop_stdaccess+0x43 unionfs_access() at unionfs_access+0x1c4 vn_open_cred() at vn_open_cred+0x547 kern_opneat() at kern_openat+0x1f9 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp = 0x7fffb388, rbp = 0x8 --- Please tell how to provide more information if needed. Thanks, -Harry -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: beta2 panic: VAPPEND without VWRITE
schrieb Attilio Rao am 01.10.2011 16:49 (localtime): Can you please show the panic message? Sorry, I forgot to add it here: free indoe /var/123088 had 8 blocks panic: VAPPEND withour VWRITE cpuid = 0 KDB: enter: panic [ thread pid 1445 tid 100126 ] Stopped at kbd_enter+0x2b: movq$0,0x918a52(%rip) db bt Tracing pid 1445 tid 100126 td 0xfe000510d460 kdb_enter() at kbd_enter+0x3b panic() at panic+0x180 vn_isdisk() at vn_isdisk ufs_accessx() at ufs_accessx+0x188 vop_stdaccess() at vop_stdaccess+0x43 unionfs_access() at unionfs_access+0x1c4 vn_open_cred() at vn_open_cred+0x547 kern_opneat() at kern_openat+0x1f9 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp = 0x7fffb388, rbp = 0x8 --- I'ts reproducable with exact the same hex-numbers with 'scp' when scp tries to alter knwon_hosts, which is on unionfs. Here's some LORs, I havenÄt checked if they're already known. I don't have the known-LORs-URL handy... lock order reversal: 1st 0xfe000519c278 unionfs (unionfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:356 2nd 0xfe000519c458 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2246 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vputx() at vputx+0x328 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0x105 vrecycle() at vrecycle+0x4c unionfs_inactive() at unionfs_inactive+0x20 vinactive() at vinactive+0x72 vputx() at vputx+0x386 kern_statat_vnhook() at kern_statat_vnhook+0x11d kern_statat() at kern_statat+0x15 stat() at stat+0x2a syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (188, FreeBSD ELF64, stat), rip = 0x800dc7ecc, rsp = 0x7fffd6a8, rbp = 0x801441190 --- lock order reversal: 1st 0xff80e9bf59f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xfe00051a7a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x909 ufs_mkdir() at ufs_mkdir+0x44d VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x290 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800933eec, rsp = 0x7fffd768, rbp = 0x800c07050 --- lock order reversal: 1st 0xfe000514f818 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134 2nd 0xff80e9bf59f8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:260 3rd 0xfe0005706278 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b vfs_hash_get() at vfs_hash_get+0xd5 ffs_vgetf() at ffs_vgetf+0x48 softdep_sync_buf() at softdep_sync_buf+0x393 ffs_syncvnode() at ffs_syncvnode+0x2b3 ffs_truncate() at ffs_truncate+0x477 ufs_direnter() at ufs_direnter+0x73b ufs_mkdir() at ufs_mkdir+0x44d VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x290 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800933eec, rsp = 0x7fffdbb8, rbp = 0x7fffdee6 --- Thanks, -Harry cpuid = 0 KDB: enter: panic [ thread pid 1445 tid 100126 ] Stopped at kbd_enter+0x2b: movq$0,0x918a52(%rip) db bt Tracing pid 1445 tid 100126 td 0xfe000510d460 kdb_enter() at kbd_enter+0x3b panic() at panic+0x180 vn_isdisk() at vn_isdisk ufs_accessx() at ufs_accessx+0x188 vop_stdaccess() at vop_stdaccess+0x43 unionfs_access() at unionfs_access+0x1c4 vn_open_cred() at vn_open_cred+0x547 kern_opneat() at kern_openat+0x1f9 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp = 0x7fffb388, rbp = 0x8 --- signature.asc Description: OpenPGP digital signature
Re: BETA2 panic
On 1 October 2011 20:46, Joel Dahl j...@vnode.se wrote: My laptop has been running with your patch for almost 8 hours now. No panics. Do you have all of the -current debugging enabled (witness, invariants, etc) ? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: beta2 panic: VAPPEND without VWRITE
Harald Schmalzbauer wrote: schrieb Attilio Rao am 01.10.2011 16:49 (localtime): Can you please show the panic message? Sorry, I forgot to add it here: free indoe /var/123088 had 8 blocks panic: VAPPEND withour VWRITE cpuid = 0 KDB: enter: panic [ thread pid 1445 tid 100126 ] Stopped at kbd_enter+0x2b: movq $0,0x918a52(%rip) db bt Tracing pid 1445 tid 100126 td 0xfe000510d460 kdb_enter() at kbd_enter+0x3b panic() at panic+0x180 vn_isdisk() at vn_isdisk ufs_accessx() at ufs_accessx+0x188 vop_stdaccess() at vop_stdaccess+0x43 unionfs_access() at unionfs_access+0x1c4 vn_open_cred() at vn_open_cred+0x547 kern_opneat() at kern_openat+0x1f9 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp = 0x7fffb388, rbp = 0x8 --- I'ts reproducable with exact the same hex-numbers with 'scp' when scp tries to alter knwon_hosts, which is on unionfs. You could try the attached one line patch. Since VAPPEND is a modifier for VWRITE, it makes sense to clear it along with VWRITE, I think? rick Here's some LORs, I havenÄt checked if they're already known. I don't have the known-LORs-URL handy... lock order reversal: 1st 0xfe000519c278 unionfs (unionfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:356 2nd 0xfe000519c458 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2246 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vputx() at vputx+0x328 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0x105 vrecycle() at vrecycle+0x4c unionfs_inactive() at unionfs_inactive+0x20 vinactive() at vinactive+0x72 vputx() at vputx+0x386 kern_statat_vnhook() at kern_statat_vnhook+0x11d kern_statat() at kern_statat+0x15 stat() at stat+0x2a syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (188, FreeBSD ELF64, stat), rip = 0x800dc7ecc, rsp = 0x7fffd6a8, rbp = 0x801441190 --- lock order reversal: 1st 0xff80e9bf59f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xfe00051a7a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x909 ufs_mkdir() at ufs_mkdir+0x44d VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x290 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800933eec, rsp = 0x7fffd768, rbp = 0x800c07050 --- lock order reversal: 1st 0xfe000514f818 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134 2nd 0xff80e9bf59f8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:260 3rd 0xfe0005706278 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b vfs_hash_get() at vfs_hash_get+0xd5 ffs_vgetf() at ffs_vgetf+0x48 softdep_sync_buf() at softdep_sync_buf+0x393 ffs_syncvnode() at ffs_syncvnode+0x2b3 ffs_truncate() at ffs_truncate+0x477 ufs_direnter() at ufs_direnter+0x73b ufs_mkdir() at ufs_mkdir+0x44d VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x290 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800933eec, rsp = 0x7fffdbb8, rbp = 0x7fffdee6 --- Thanks, -Harry cpuid = 0 KDB: enter: panic [ thread pid 1445 tid 100126 ] Stopped at kbd_enter+0x2b: movq $0,0x918a52(%rip) db bt Tracing pid 1445 tid 100126 td 0xfe000510d460 kdb_enter() at kbd_enter+0x3b panic() at panic+0x180 vn_isdisk() at vn_isdisk ufs_accessx() at ufs_accessx+0x188 vop_stdaccess() at vop_stdaccess+0x43 unionfs_access() at unionfs_access+0x1c4 vn_open_cred() at vn_open_cred+0x547 kern_opneat() at kern_openat+0x1f9 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c
Re: BETA2 panic
On 02-10-2011 0:54, Adrian Chadd wrote: On 1 October 2011 20:46, Joel Dahl j...@vnode.se wrote: My laptop has been running with your patch for almost 8 hours now. No panics. Do you have all of the -current debugging enabled (witness, invariants, etc) ? I'm running GENERIC, so yes. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
Hi, Would you please try this patch? Make sure that witness and the rest of the lock debugging is enabled. I've been working on this problem with someone else on the list (but I can't trigger it myself; I think I need to get some dual-CPU wireless test hardware.) Thanks, Adrian net80211-swbmiss-2.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On Tue, Sep 6, 2011 at 22:42, Joel Dahl j...@vnode.se wrote: On 05-09-2011 9:02, Bernhard Schmidt wrote: On Mon, Sep 5, 2011 at 08:24, Joel Dahl j...@vnode.se wrote: On 05-09-2011 5:09, Adrian Chadd wrote: On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. While doing so, can you enable at least some debugging? wlandebug +state or even better wlandebug 0x It smells like that something is poking the SW bmiss handler while not in RUN state and therefore you're hitting a KASSERT(). Question is if the bmiss timer isn't stopped/drained somewhere or if there is too excessive call. Exactly what in the wlandebug output are you looking for? I've posted a pic at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like right before the panic. This is with wlandebug 0x. Thanks, so, looks like it is scanning while the panic happens. At that point it should actually never ever care about beacon misses.. this is strange, really. Can you try to comment out the call to ieee80211_beacon_miss() on line 2936 in if_iwn.c? If the panic no longer happens the issue is somewhere in the conditions before that call. I've also installed kernels all the way back to revision 222980, but they all panic, which I think is somewhat odd. I think this is an issue related to iwn(4), which had its last commit prior to that. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On 07-09-2011 10:59, Bernhard Schmidt wrote: On Tue, Sep 6, 2011 at 22:42, Joel Dahl j...@vnode.se wrote: On 05-09-2011 9:02, Bernhard Schmidt wrote: On Mon, Sep 5, 2011 at 08:24, Joel Dahl j...@vnode.se wrote: On 05-09-2011 5:09, Adrian Chadd wrote: On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. While doing so, can you enable at least some debugging? wlandebug +state or even better wlandebug 0x It smells like that something is poking the SW bmiss handler while not in RUN state and therefore you're hitting a KASSERT(). Question is if the bmiss timer isn't stopped/drained somewhere or if there is too excessive call. Exactly what in the wlandebug output are you looking for? I've posted a pic at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like right before the panic. This is with wlandebug 0x. Thanks, so, looks like it is scanning while the panic happens. At that point it should actually never ever care about beacon misses.. this is strange, really. Can you try to comment out the call to ieee80211_beacon_miss() on line 2936 in if_iwn.c? If the panic no longer happens the issue is somewhere in the conditions before that call. Hm, this is with bwn(4), not iwn(4). :) -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On Wed, Sep 7, 2011 at 12:53, Joel Dahl j...@vnode.se wrote: On 07-09-2011 10:59, Bernhard Schmidt wrote: On Tue, Sep 6, 2011 at 22:42, Joel Dahl j...@vnode.se wrote: On 05-09-2011 9:02, Bernhard Schmidt wrote: On Mon, Sep 5, 2011 at 08:24, Joel Dahl j...@vnode.se wrote: On 05-09-2011 5:09, Adrian Chadd wrote: On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. While doing so, can you enable at least some debugging? wlandebug +state or even better wlandebug 0x It smells like that something is poking the SW bmiss handler while not in RUN state and therefore you're hitting a KASSERT(). Question is if the bmiss timer isn't stopped/drained somewhere or if there is too excessive call. Exactly what in the wlandebug output are you looking for? I've posted a pic at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like right before the panic. This is with wlandebug 0x. Thanks, so, looks like it is scanning while the panic happens. At that point it should actually never ever care about beacon misses.. this is strange, really. Can you try to comment out the call to ieee80211_beacon_miss() on line 2936 in if_iwn.c? If the panic no longer happens the issue is somewhere in the conditions before that call. Hm, this is with bwn(4), not iwn(4). :) Uhm.. right, I'm sorry, missed that Still.. two options, remove IEEE80211_FEXT_SWBMISS or try with ifconfig wlan0 -bgscan -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On 05-09-2011 9:02, Bernhard Schmidt wrote: On Mon, Sep 5, 2011 at 08:24, Joel Dahl j...@vnode.se wrote: On 05-09-2011 5:09, Adrian Chadd wrote: On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. While doing so, can you enable at least some debugging? wlandebug +state or even better wlandebug 0x It smells like that something is poking the SW bmiss handler while not in RUN state and therefore you're hitting a KASSERT(). Question is if the bmiss timer isn't stopped/drained somewhere or if there is too excessive call. Exactly what in the wlandebug output are you looking for? I've posted a pic at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like right before the panic. This is with wlandebug 0x. I've also installed kernels all the way back to revision 222980, but they all panic, which I think is somewhat odd. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On 04-09-2011 14:45, Garrett Cooper wrote: On Sun, Sep 4, 2011 at 1:22 PM, Joel Dahl j...@vnode.se wrote: On 04-09-2011 10:56, Garrett Cooper wrote: On Sun, Sep 4, 2011 at 10:04 AM, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Is your wireless turned off? If so, it looks like the state transition code isn't being handled properly between bwn(4) and net80211(4), in particular because your wireless card was still in 'scan' mode. No, it's always on. I can ping over the wireless for a few minutes, until it panics. Hmm.. and the wireless card always appears on? Assuming the firmware isn't buggy (did you update it recently? have you booted other OSes, i.e. Windows or Linux that could be updating the firmware automatically on load?), it should keep the light for the wireless NIC properly lit. Sure, it always appears on. This laptop has been running freebsd exclusively for at least a year. FWIW, the same RF switch is changed on/off message from bwn has always been there on this machine. I also noticed them on my old laptop, an HP 6715b. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On 05-09-2011 5:09, Adrian Chadd wrote: On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On 5 September 2011 14:24, Joel Dahl j...@vnode.se wrote: There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. Thanks, that'd be great! adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On Mon, Sep 5, 2011 at 08:24, Joel Dahl j...@vnode.se wrote: On 05-09-2011 5:09, Adrian Chadd wrote: On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Yes, I'll do that tonight. While doing so, can you enable at least some debugging? wlandebug +state or even better wlandebug 0x It smells like that something is poking the SW bmiss handler while not in RUN state and therefore you're hitting a KASSERT(). Question is if the bmiss timer isn't stopped/drained somewhere or if there is too excessive call. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
BETA2 panic
Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On Sun, Sep 4, 2011 at 10:04 AM, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Is your wireless turned off? If so, it looks like the state transition code isn't being handled properly between bwn(4) and net80211(4), in particular because your wireless card was still in 'scan' mode. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On 04-09-2011 10:56, Garrett Cooper wrote: On Sun, Sep 4, 2011 at 10:04 AM, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Is your wireless turned off? If so, it looks like the state transition code isn't being handled properly between bwn(4) and net80211(4), in particular because your wireless card was still in 'scan' mode. No, it's always on. I can ping over the wireless for a few minutes, until it panics. Any particular commit you think I should try to back out? -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On 5 September 2011 01:04, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Hi, There weren't many commits between BETA1 and -HEAD in the wireless area; would you please do a binary search of the kernel revisions (no need to do full buildworlds) to find which commit broke it? Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: BETA2 panic
On Sun, Sep 4, 2011 at 1:22 PM, Joel Dahl j...@vnode.se wrote: On 04-09-2011 10:56, Garrett Cooper wrote: On Sun, Sep 4, 2011 at 10:04 AM, Joel Dahl j...@vnode.se wrote: Hi, I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop panics just a few minutes after booting. This is 100% reproducible, it panics every time. I've got a pic with the backtrace here: http://www.vnode.se/sc/panic_20110904.jpg Is your wireless turned off? If so, it looks like the state transition code isn't being handled properly between bwn(4) and net80211(4), in particular because your wireless card was still in 'scan' mode. No, it's always on. I can ping over the wireless for a few minutes, until it panics. Hmm.. and the wireless card always appears on? Assuming the firmware isn't buggy (did you update it recently? have you booted other OSes, i.e. Windows or Linux that could be updating the firmware automatically on load?), it should keep the light for the wireless NIC properly lit. Any particular commit you think I should try to back out? Not in particular (in fact if_bwn has been untouched after 9.0-BETA1 was cut), but as Adrian suggested you should bisect the source of failure.. it would be a wise idea to load if_bwn as a module after boot to see if the behavior persists; next I would try out a revision sometime between r18 (9.0 Beta1) and your head revision. Some commits of interest that you might want to try backing out and testing are: - 224717 - 225139 HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
