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