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
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]
___
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
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_
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
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 su
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
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 l
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
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
>
> 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
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_int
12 matches
Mail list logo
