radeon panic: mtx_lock() of destroyed mutex @
/usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:128
Gavin Atkinson
gavin.atkinson at ury.york.ac.uk
Mon Dec 18 09:30:42 PST 2006
Hi all,
I have a reproduceable panic on
FreeBSD buffy.york.ac.uk 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #9: Tue Nov 28 13:12:09 GMT 2006 root at buffy.york.ac.uk:/usr/obj/usr/src/sys/BUFFY i386
My kernel config is as follows:
include GENERIC
ident BUFFY
nooptions PREEMPTION
nooptions COMPAT_FREEBSD5
options SMP
options KDB # Enable kernel debugger support.
options DDB # Support DDB.
options GDB # Support remote GDB.
options INVARIANTS # Enable calls of extra sanity checking
options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS
options WITNESS # Enable checks to detect deadlocks and cycles
options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed
options ALT_BREAK_TO_DEBUGGER
I load the radeon module from /boot/loader.conf.
If I'm in X (gnome), and run glxgears, a window opens with the first
frame, but then I get the following reproduceable panic:
panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:128
cpuid = 0
KDB: enter: panic
[thread pid 1526 tid 100117 ]
Stopped at kdb_enter+0x2b: nop
db> bt
Tracing pid 1526 tid 100117 td 0xc6d26600
kdb_enter(c08f4c9a) at kdb_enter+0x2b
panic(c08f3f3f,c0b950eb,80,c5024800,c50214c8,...) at panic+0x127
_mtx_lock_flags(c50214c8,0,c0b950eb,80,c50214ec,...) at _mtx_lock_flags+0x4a
radeon_wait_irq(c5021400,1,ebc81c40,c0ba9829,c502ac00,...) at radeon_wait_irq+0x8a
radeon_irq_wait(c502ac00,80046457,c53bb540,3,c6d26600,...) at radeon_irq_wait+0x58
drm_ioctl(c502ac00,80046457,c53bb540,3,c6d26600,c09df5c0,0,c08f0b10,131) at drm_ioctl+0x2a1
giant_ioctl(c502ac00,80046457,c53bb540,3,c6d26600,...) at giant_ioctl+0x33
devfs_ioctl_f(c7294510,80046457,c53bb540,c6cda180,c6d26600) at devfs_ioctl_f+0xaf
ioctl(c6d26600,ebc81d04) at ioctl+0x396
syscall(3b,3b,3b,8068000,8068000,...) at syscall+0x22f
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282b2fcf, esp = 0xbfbfe5dc, ebp= 0xbfbfe5f8 ---
db> show lock 0xc50214c8
class: sleep mutex
name: DRM IRQ lock
flags: {DEF}
state: {OWNED, CONTESTED}
db> reset
I've determined that this lock has been destroyed even before glxgears
runs - I guess it's just the first attempt at 3D rendering that triggers
it?
I'll try instrumenting the code somewhat to see what's happening...
Thanks,
Gavin
More information about the freebsd-stable
mailing list