Project

General

Profile

Actions
Copy link

Bug #1277

closed

panic: spin_lock: 0xc89c9578, indefinite wait!

Added by thomas.nikolajsen almost 16 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Kernel
Target version:
4.2
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Using HEAD from Feb 1, 2009 I got
temporary freeze, ~1 minute, and then panic.

This SMP (w/ APIC_IO) kernel on UP host.

Freeze happens when accessing file with UFS filesystem
(for vkernel), just after output when fsck finishes:
vnconfig -cs labels vn0 FILE
fsck -y FILE
mount /dev/vn0s0a /mnt

I have seen this panic a few times;
not every time script w/ commands run.

Crash dump uploaded to leaf as *.41.

thomas

spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
Trace beginning at frame 0xd394db84
exponential_backoff(80000000,80000000,d394dba4,d394dbc0,c01b3bbe) at 
exponential_backoff+0xe7
exponential_backoff(ff800000,1,b,c89c9578,c8a53cb) at exponential_backoff+0xe7
spin_lock_wr_contested(c89c9578,d6191ec0) at spin_lock_wr_contested+0x51
lockmgr(c89c9578,1) at lockmgr+0xa8
vfs_busy(c89c9558,0) at vfs_busy+0x42
nlookup(d394dc38,c89c4458,c0f868a8,c89d8cd8,c0f868a8) at nlookup+0x41d
kern_mountctl(c909dc00,10,0,c101e8d8,88) at kern_mountctl+0x38
sys_mountctl(d394dcf0,6,0,0,c89d9398) at sys_mountctl+0x1f5
syscall2(d394dd40) at syscall2+0x265
Xint0x80_syscall() at Xint0x80_syscall+0x36
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
spin_lock: 0xc89c9578, indefinite wait!
panic: spin_lock: 0xc89c9578, indefinite wait!

mp_lock = 00000000; cpuid = 0
Trace beginning at frame 0xd394db64
panic(d394db88,d394dba4,17354e1f,d394dba4,d394db98) at panic+0x14d
panic(c035b7d8,c89c9578,80000000,80000000,d394dba4) at panic+0x14d
exponential_backoff(ff800000,1,3c,c89c9578,16feaf84) at exponential_backoff+0xfa
spin_lock_wr_contested(c89c9578,d6191ec0) at spin_lock_wr_contested+0x51
lockmgr(c89c9578,1) at lockmgr+0xa8
vfs_busy(c89c9558,0) at vfs_busy+0x42
nlookup(d394dc38,c89c4458,c0f868a8,c89d8cd8,c0f868a8) at nlookup+0x41d
kern_mountctl(c909dc00,10,0,c101e8d8,88) at kern_mountctl+0x38
sys_mountctl(d394dcf0,6,0,0,c89d9398) at sys_mountctl+0x1f5
syscall2(d394dd40) at syscall2+0x265
Xint0x80_syscall() at Xint0x80_syscall+0x36
Debugger("panic")

CPU0 stopping CPUs: 0x00000000
stopped
panic: from debugger
mp_lock = 00000000; cpuid = 0

Actions
Copy link
 #1

Updated by dillon almost 16 years ago

:New submission from Thomas Nikolajsen <>:
:
:Using HEAD from Feb 1, 2009 I got
:temporary freeze, ~1 minute, and then panic.
:
:This SMP (w/ APIC_IO) kernel on UP host.
:
:Freeze happens when accessing file with UFS filesystem
:(for vkernel), just after output when fsck finishes:
:vnconfig -cs labels vn0 FILE
:fsck -y FILE
:mount /dev/vn0s0a /mnt
:
:I have seen this panic a few times;
:not every time script w/ commands run.
:
:Crash dump uploaded to leaf as *.41.
:
: -thomas

Try fscking through the vn device.  fsck /dev/vn0s0a.  I can't
    imagine it would be happy if you were to fsck the file.
-Matt
Actions
Copy link
 #2

Updated by thomas.nikolajsen almost 16 years ago

I already did fsck the vn (was wrong in my original description).

Did:
vnconfig -cs labels vn0 FILE
fsck -y /dev/vn0s0a
mount /dev/vn0s0a /mnt
cd /usr/src; make installworld DESTDIR=/mnt

-thomas
Actions
Copy link
 #3

Updated by dillon almost 16 years ago

:Thomas Nikolajsen <> added the comment:
:
:I already did fsck the vn (was wrong in my original description).
:
:Did:
:vnconfig -cs labels vn0 FILE
:fsck -y /dev/vn0s0a
:mount /dev/vn0s0a /mnt
:cd /usr/src; make installworld DESTDIR=3D/mnt
:
: -thomas

It's not happy about something, that's for sure.  The mount structure
    looks completely corrupted.
Did you kldunload any modules prior to this blowup?  If the vn device
    is loaded via a kernel module, is the kernel module up-to-date?  Check
    the dates on everything in /boot/modules and make sure you no longer
    have a /modules directory (assuming your kernel is in /boot/kernel).
-Matt
Actions
Copy link
 #4

Updated by thomas.nikolajsen almost 16 years ago

No kldunload used; vn is via kernel module.
No (old) /modules, just /boot/modules.
I have updated kernel & modules (twice) since panic;
will double check next time panic occurs.
I always use 'make installkernel',
so kernel & modules should be in sync.

-thomas
Actions
Copy link
 #5

Updated by alexh about 15 years ago

The vn driver has changed quite a lot since February. Can you still reproduce
the issue?

Cheers,
Alex Hornung

Actions
Copy link
 #6

Updated by tuxillo almost 10 years ago

  • Description updated (diff)
  • Category set to Kernel
  • Status changed from New to Closed
  • Assignee deleted (0)
  • Target version set to 4.2

Hi,

No feedback and haven't seen similar reports indicating it could be a global problem so closing this one.

Cheers,
Antonio Huete

Actions
Copy link

Also available in: Atom PDF