/src-client/sys/ufs/ufs/ufs_ihash.c:128
2nd 0xfc6feda0 ufs ihash (ufs ihash) @
/a/asami/portbuild/alpha/src-client/sys/ufs/ufs/ufs_ihash.c:124
Stack backtrace:
recursed on non-recursive lock (sleep mutex) vnode interlock @
/a/asami/portbuild/alpha/src-client/sys/ufs/ufs/ufs_ihash.c:128
first
One of my sparc64 package machines (running -current from Nov 21) died
overnight with the following:
recursed on non-recursive lock (sleep mutex) vnode interlock @
/var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128
first acquired @ /var/portbuild/sparc64/src-client/sys/ufs/ufs
Gang,
I don't know if this is a known issue or not, but:
lock order reversal
1st 0xe0002843d7a0 vnode interlock (vnode interlock) @
/q/src/sys/ufs/ufs/ufs_ihash.c:128
2nd 0xe4685300 ufs ihash (ufs ihash) @ /q/src/sys/ufs/ufs/ufs_ihash.c:124
Stack backtrace:
recursed o
On Sat, Oct 04, 2003 at 11:31:33PM -0700, Kris Kennaway wrote:
> I don't think I've seen this one before (i386, kernel built Sep 17).
> Is it already fixed?
>
No, not yet.
Regards,
Alan
>
> recursed on non-recursive lock (sleep mutex) vm page queue mutex @
>
I don't think I've seen this one before (i386, kernel built Sep 17).
Is it already fixed?
Kris
recursed on non-recursive lock (sleep mutex) vm page queue mutex @
/a/asami/portbuild/i386/src-client/sys/kern/vfs_bio.c:3630
first acquired @ /a/asami/portbuild/i386/src-client/sys/vm/vm
6fd7c, ebp = 0 ---
recursed on non-recursive lock (sleep mutex) vm page queue mutex @ kern/vfs_bio.c:1550
first acquired @ vm/vm_pageout.c:405
panic: recurse
cpuid = 0; lapic.id =
boot() called on cpu#0
- Christian
--
Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED]
GP
--On Sunday, November 17, 2002 2:54 PM -0500 Robert Watson
<[EMAIL PROTECTED]> wrote:
Hmm. It looks like there is indeed a lock leak in the RFTHREAD code.
Maybe a change like the following might help:
PROC_LOCK(p2);
psignal(p2, SIGKILL);
71
> 2nd 0xc03cfce0 proctree (proctree) @ ../../../kern/kern_fork.c:596
> recursed on non-recursive lock (sleep mutex) process lock @
> ../../../kern/kern_fork.c:599
> first acquired @ ../../../kern/kern_fork.c:571
> panic: recurse
> cpuid = 1; lapic.id = 0100
> Debugger("
running dnet on a SMP kernel causes the kernel to panic.
lock order reversal
1st 0xc2c803e8 process lock (process lock) @
../../../kern/kern_fork.c:571
2nd 0xc03cfce0 proctree (proctree) @ ../../../kern/kern_fork.c:596
recursed on non-recursive lock (sleep mutex) process lock @
../../../kern
On 23-Sep-01 Munehiro Matsuda wrote:
> Hi all,
>
> Here's another one from src-cur.4972.gz. It's repeatable.
> ---
># ps -ae
> lock order reversal
> 1st 0xc7fe4d08 process lock @ ../../../kern/kern_proc.c:215
> 2nd 0xc03e6620 Gian
Hi all,
Here's another one from src-cur.4972.gz. It's repeatable.
---
# ps -ae
lock order reversal
1st 0xc7fe4d08 process lock @ ../../../kern/kern_proc.c:215
2nd 0xc03e6620 Giant @ ../../../kern/subr_trap.c:98
exclusive (sleep mut
On 23 Sep, Munehiro Matsuda wrote:
> Hi,
>
> I got following panic with recent -current (src-cur.4972.gz):
>
> recursed on non-recursive lock (sleep mutex) process lock @
>../../../i386/i386/trap.c:807
> first acquired @ ../../../kern/subr_trap.c:100
> panic: re
Hi,
I got following panic with recent -current (src-cur.4972.gz):
recursed on non-recursive lock (sleep mutex) process lock @
../../../i386/i386/trap.c:807
first acquired @ ../../../kern/subr_trap.c:100
panic: recurse
syncing disks... panic: bremfree: bp 0xc3bbd5ec not locked
System rebooted
On Sun, 27 May 2001 17:32:15 -0700 (PDT), John Baldwin <[EMAIL PROTECTED]> said:
> Please try http://www.FreeBSD.org/~jhb/patches/vm.patch it fixes
> several places where we hold the vm lock across VOP's, etc.
Does that mean you've upgraded it? The last time I tried it (shortly
after you
On 26-May-01 Michael Harnois wrote:
> I finally got this much. I hope it helps.
>
> lock order reversal
> 1st 0xc03af0a0 mntvnode @ ../../ufs/ffs/ffs_vnops.c:1007
> 2nd 0xc8b539cc vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:1016
>
> recursed on non-recursive lock (slee
After I'd been up a couple of hours I had a spontaneous reboot. No
idea why. Still a lot better than I'd been doing ...
--
Michael D. Harnois[EMAIL PROTECTED]
Redeemer Lutheran Church Washburn, Iowa
Earth has its boundaries, but human stupidity is l
On Sun, 27 May 2001 03:59:20 +0200, Thomas Moestl <[EMAIL PROTECTED]> said:
> The attached patch just unlocks vm_mtx before this call and
> reacquires the it when it's done. This works for me
Me, too. So far, at least ... uptime 25 minutes, swapping, X running,
none of which I could do b
On Sat, 2001/05/26 at 11:07:36 -0500, Michael Harnois wrote:
> I finally got this much. I hope it helps.
>
> lock order reversal
> 1st 0xc03af0a0 mntvnode @ ../../ufs/ffs/ffs_vnops.c:1007
> 2nd 0xc8b539cc vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:1016
>
> recursed
I finally got this much. I hope it helps.
lock order reversal
1st 0xc03af0a0 mntvnode @ ../../ufs/ffs/ffs_vnops.c:1007
2nd 0xc8b539cc vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:1016
recursed on non-recursive lock (sleep mutex) vm @ ../../ufs/ufs/ufs_readwrite.c:420
first acquired @ ../../vm
19 matches
Mail list logo
