Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Dec 2006 16:58:17 +0000
From:      Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>
To:        freebsd-stable@freebsd.org
Cc:        anholt@freebsd.org
Subject:   radeon panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:128
Message-ID:  <1166461097.1296.4.camel@buffy.york.ac.uk>

next in thread | raw e-mail | index | archive | help

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@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1166461097.1296.4.camel>