Bug #1277

panic: spin_lock: 0xc89c9578, indefinite wait!

Added by thomas.nikolajsen over 5 years ago. Updated over 4 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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

History

#1 Updated by dillon over 5 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

#2 Updated by thomas.nikolajsen over 5 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

#3 Updated by dillon over 5 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

#4 Updated by thomas.nikolajsen over 5 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

#5 Updated by alexh over 4 years ago

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

Cheers,
Alex Hornung

Also available in: Atom PDF