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
