Re: LOR panic on mount -uw
On Thu, Oct 12, 2017 at 11:15 AM, John Baldwin wrote: > In this case the panic is separate from the LOR, and > for a panic we really > need the panic message in addition to the stack trace. With release kernels stack trace appears with this message, then it sits in ddb, forget how to print panic? panic: access but not attached With snapshots, both panic and stacktrace print but it doesn't ddb and goes straight to reboot. I forget how to make those enter ddb or 15sec countdown? In interim.. fatal trap 12 page fault while in kernel mode supervosor read data page not present process = mount I did file a ticket with script so anyone with a blank usb stick can recreate locally. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222948 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LOR panic on mount -uw
On Wed, Oct 11, 2017 at 5:18 PM, grarpamp wrote: > Let 12.0-current r324306 amd64 efi boot from usb to installer screen, Another way to trigger this one is boot snapshot install media single user verbose mdmfs -s 10m md /mnt umount -v /mnt [LOR stack backtrace, remains usable] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LOR panic on mount -uw
On Wednesday, October 11, 2017 05:18:17 PM grarpamp wrote: > Let 12.0-current r324306 amd64 efi boot from usb to installer screen, > try to write zeroes to an unallocated part of ada0, mount -uw a > separate part of ada0 ... > > 1st 0xc5ce5f0 ufs kern/vfs_mount.c:1274 > 2nd 0xc565b78 devfs ufs/ffs/ffs_vfsops.c:1414 > > db_trace_self_wrapper > vpanic > kassert_panic+0x126 > g_access+0x2b9/frame 0xfe0458a31550 > ffs_mount+0x1092/frame 0xfe0458a31700 > vfs_donmount+0x13b8/frame 0xfe0458a31940 > sys_nmount+0x72/frame 0xfe0458a31980 > amd64_syscall+0x79b/frame 0xfe0458a3a1b0 > Xfast_syscall+0xfb/frame 0xfe0458a31ab0 > syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a88d6a, rsp = > 0x7fffd428, rbp = 0x7fffd990 > kdb_enter+0x3b: movq $0,kdb_why In this case the panic is separate from the LOR, and for a panic we really need the panic message in addition to the stack trace. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
LOR panic on mount -uw
Let 12.0-current r324306 amd64 efi boot from usb to installer screen, try to write zeroes to an unallocated part of ada0, mount -uw a separate part of ada0 ... 1st 0xc5ce5f0 ufs kern/vfs_mount.c:1274 2nd 0xc565b78 devfs ufs/ffs/ffs_vfsops.c:1414 db_trace_self_wrapper vpanic kassert_panic+0x126 g_access+0x2b9/frame 0xfe0458a31550 ffs_mount+0x1092/frame 0xfe0458a31700 vfs_donmount+0x13b8/frame 0xfe0458a31940 sys_nmount+0x72/frame 0xfe0458a31980 amd64_syscall+0x79b/frame 0xfe0458a3a1b0 Xfast_syscall+0xfb/frame 0xfe0458a31ab0 syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a88d6a, rsp = 0x7fffd428, rbp = 0x7fffd990 kdb_enter+0x3b: movq $0,kdb_why ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic on mount
In message <[EMAIL PROTECTED]>, John Baldwin writes: > >It looks like the mutex is really held since the mtx_assert before >witness_unlock didn't trigger. You can try turning witness off for the time >being as a workaround. I'm not sure why witness would be broken, however. Revision 1.41 of sys/mutex.h seems to be the culprit. Before 1.41, the defined(LOCK_DEBUG) and !defined(LOCK_DEBUG) cases were identical except that with LOCK_DEBUG defined, the function versions of _mtx_*lock_* were used. After 1.41, the !defined(LOCK_DEBUG) case misses all the MPASS/KASSERT/LOCK_LOG/WITNESS bits. A simple workaround that seems to stop the panics is below. Ian Index: mutex.h === RCS file: /dump/FreeBSD-CVS/src/sys/sys/mutex.h,v retrieving revision 1.41 diff -u -r1.41 mutex.h --- mutex.h 2001/09/22 21:19:55 1.41 +++ mutex.h 2001/09/26 00:46:09 @@ -238,7 +238,7 @@ #define mtx_unlock(m) mtx_unlock_flags((m), 0) #define mtx_unlock_spin(m) mtx_unlock_spin_flags((m), 0) -#ifdef LOCK_DEBUG +#if 1 #definemtx_lock_flags(m, opts) \ _mtx_lock_flags((m), (opts), LOCK_FILE, LOCK_LINE) #definemtx_unlock_flags(m, opts) \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic on mount
On 25-Sep-01 Bill Fenner wrote:
>
> I also started getting this error with recent kernels (in the last
> day or so).
It looks like the mutex is really held since the mtx_assert before
witness_unlock didn't trigger. You can try turning witness off for the time
being as a workaround. I'm not sure why witness would be broken, however.
> Mounting root from ufs:/dev/ad0s1a
> panic: lock (sleep mutex) vnode interlock not locked @
> /usr/src/sys/kern/vfs_default.c:460
> Debugger("panic")
> Stopped at Debugger+0x44: pushl %ebx
> db> t
> Debugger(c03c5bbb) at Debugger+0x44
> panic(c03c8c40,c03c4b80,c03ccf20,c03cc8a0,1cc) at panic+0x70
> witness_unlock(c7765f2c,8,c03cc8a0,1cc,c7765f2c,1,c03c4ba0,f6) at
> witness_unlock+0x1d0
> _mtx_unlock_flags(c7765f2c,0,c03cc8a0,1cc,c0567bd0) at _mtx_unlock_flags+0x59
> vop_nolock(c0567be8,c0567bf8,c02920c2,c0567be8,c0567d4c) at vop_nolock+0x24
> vop_defaultop(c0567be8) at vop_defaultop+0x15
> vn_lock(c7765ec0,20002,c049f7c4,c0567d4c,c1346680) at vn_lock+0xca
> ffs_mountfs(c7765ec0,c1351600,c049f7c4,c0446900,c0567d4c) at ffs_mountfs+0x7e
> ffs_mount(c1351600,0,0,0,c049f7c4) at ffs_mount+0x67
> vfs_mountroot_try(c05447a8,c03cc48c) at vfs_mountroot_try+0x14e
> vfs_mountroot(0,564c00,564000,0,c012caac) at vfs_mountroot+0x5a
> mi_startup() at mi_startup+0x90
> begin() at begin+0x43
>
> I dunno how to get a dump from this point since kern.dumpdev hasn't been
> set..
>
> Bill
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic on mount
Julian Elischer wrote:
> You could probably set teh device using DDB, but I just use a serial debug
> link
Not a good strategy. dev_t is a pointer in -current.
We probably need a 'dumpon 13,0x00020001' ddb command that does something
like what sysctl_kern_dumpdev() does..
> On Mon, 24 Sep 2001, Bill Fenner wrote:
>
> >
> > I also started getting this error with recent kernels (in the last
> > day or so).
> >
> > Mounting root from ufs:/dev/ad0s1a
> > panic: lock (sleep mutex) vnode interlock not locked @ /usr/src/sys/kern/vf
s_default.c:460
> > Debugger("panic")
> > Stopped at Debugger+0x44: pushl %ebx
> > db> t
> > Debugger(c03c5bbb) at Debugger+0x44
> > panic(c03c8c40,c03c4b80,c03ccf20,c03cc8a0,1cc) at panic+0x70
> > witness_unlock(c7765f2c,8,c03cc8a0,1cc,c7765f2c,1,c03c4ba0,f6) at witness_u
nlock+0x1d0
> > _mtx_unlock_flags(c7765f2c,0,c03cc8a0,1cc,c0567bd0) at _mtx_unlock_flags+0x
59
> > vop_nolock(c0567be8,c0567bf8,c02920c2,c0567be8,c0567d4c) at vop_nolock+0x24
> > vop_defaultop(c0567be8) at vop_defaultop+0x15
> > vn_lock(c7765ec0,20002,c049f7c4,c0567d4c,c1346680) at vn_lock+0xca
> > ffs_mountfs(c7765ec0,c1351600,c049f7c4,c0446900,c0567d4c) at ffs_mountfs+0x
7e
> > ffs_mount(c1351600,0,0,0,c049f7c4) at ffs_mount+0x67
> > vfs_mountroot_try(c05447a8,c03cc48c) at vfs_mountroot_try+0x14e
> > vfs_mountroot(0,564c00,564000,0,c012caac) at vfs_mountroot+0x5a
> > mi_startup() at mi_startup+0x90
> > begin() at begin+0x43
> >
> > I dunno how to get a dump from this point since kern.dumpdev hasn't been
> > set..
> >
> > Bill
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> >
>
>
>
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic on mount
You could probably set teh device using DDB, but I just use a serial debug
link
On Mon, 24 Sep 2001, Bill Fenner wrote:
>
> I also started getting this error with recent kernels (in the last
> day or so).
>
> Mounting root from ufs:/dev/ad0s1a
> panic: lock (sleep mutex) vnode interlock not locked @
>/usr/src/sys/kern/vfs_default.c:460
> Debugger("panic")
> Stopped at Debugger+0x44: pushl %ebx
> db> t
> Debugger(c03c5bbb) at Debugger+0x44
> panic(c03c8c40,c03c4b80,c03ccf20,c03cc8a0,1cc) at panic+0x70
> witness_unlock(c7765f2c,8,c03cc8a0,1cc,c7765f2c,1,c03c4ba0,f6) at
>witness_unlock+0x1d0
> _mtx_unlock_flags(c7765f2c,0,c03cc8a0,1cc,c0567bd0) at _mtx_unlock_flags+0x59
> vop_nolock(c0567be8,c0567bf8,c02920c2,c0567be8,c0567d4c) at vop_nolock+0x24
> vop_defaultop(c0567be8) at vop_defaultop+0x15
> vn_lock(c7765ec0,20002,c049f7c4,c0567d4c,c1346680) at vn_lock+0xca
> ffs_mountfs(c7765ec0,c1351600,c049f7c4,c0446900,c0567d4c) at ffs_mountfs+0x7e
> ffs_mount(c1351600,0,0,0,c049f7c4) at ffs_mount+0x67
> vfs_mountroot_try(c05447a8,c03cc48c) at vfs_mountroot_try+0x14e
> vfs_mountroot(0,564c00,564000,0,c012caac) at vfs_mountroot+0x5a
> mi_startup() at mi_startup+0x90
> begin() at begin+0x43
>
> I dunno how to get a dump from this point since kern.dumpdev hasn't been
> set..
>
> Bill
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic on mount
I also started getting this error with recent kernels (in the last
day or so).
Mounting root from ufs:/dev/ad0s1a
panic: lock (sleep mutex) vnode interlock not locked @
/usr/src/sys/kern/vfs_default.c:460
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db> t
Debugger(c03c5bbb) at Debugger+0x44
panic(c03c8c40,c03c4b80,c03ccf20,c03cc8a0,1cc) at panic+0x70
witness_unlock(c7765f2c,8,c03cc8a0,1cc,c7765f2c,1,c03c4ba0,f6) at witness_unlock+0x1d0
_mtx_unlock_flags(c7765f2c,0,c03cc8a0,1cc,c0567bd0) at _mtx_unlock_flags+0x59
vop_nolock(c0567be8,c0567bf8,c02920c2,c0567be8,c0567d4c) at vop_nolock+0x24
vop_defaultop(c0567be8) at vop_defaultop+0x15
vn_lock(c7765ec0,20002,c049f7c4,c0567d4c,c1346680) at vn_lock+0xca
ffs_mountfs(c7765ec0,c1351600,c049f7c4,c0446900,c0567d4c) at ffs_mountfs+0x7e
ffs_mount(c1351600,0,0,0,c049f7c4) at ffs_mount+0x67
vfs_mountroot_try(c05447a8,c03cc48c) at vfs_mountroot_try+0x14e
vfs_mountroot(0,564c00,564000,0,c012caac) at vfs_mountroot+0x5a
mi_startup() at mi_startup+0x90
begin() at begin+0x43
I dunno how to get a dump from this point since kern.dumpdev hasn't been
set..
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic on mount
Mark Murray wrote: > > > > After compiling a new kernel, installing it, when my laptop > > tries to mount its drive, it panics with this message: > > > > panic: lock (sleep mutex) vnode interlock not locked @ > > ../../../kern/vfs_default.c:460 > > > > which is: > > > > if (ap->a_flags & LK_INTERLOCK) > > mtx_unlock(&ap->a_vp->v_interlock); > > I get exactly the same thing. > > Manual bactrace is: > > panic > witness_unlock > _mtx_unlock_flags > vop_nolock > vop_defaultop > vn_lock > ffs_mountfs > ffs_mount > vfs_mountroot_try > vfs_mountroot > mi_startup > begin Eww. I was looking at this as an Alpha SMP bug. I was just about to compile an x86 kernel with the same debug options in case it was a generic problem. :-( Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic on mount
> > After compiling a new kernel, installing it, when my laptop > tries to mount its drive, it panics with this message: > > panic: lock (sleep mutex) vnode interlock not locked @ > ../../../kern/vfs_default.c:460 > > which is: > > if (ap->a_flags & LK_INTERLOCK) >mtx_unlock(&ap->a_vp->v_interlock); I get exactly the same thing. Manual bactrace is: panic witness_unlock _mtx_unlock_flags vop_nolock vop_defaultop vn_lock ffs_mountfs ffs_mount vfs_mountroot_try vfs_mountroot mi_startup begin M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic on mount
Hello, After compiling a new kernel, installing it, when my laptop tries to mount its drive, it panics with this message: panic: lock (sleep mutex) vnode interlock not locked @ ../../../kern/vfs_default.c:460 which is: if (ap->a_flags & LK_INTERLOCK) mtx_unlock(&ap->a_vp->v_interlock); within the function vop_nolock. Thanks, Evan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
