freebsd stable - Dec 2006 - radeon panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:128

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

On Mon, 2006-12-18 at 16:58 +0000, Gavin Atkinson wrote:
> 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?
Indeed, what's happening is that something calls drm_irq_install() in
src/sys/dev/drm/drm_irq.c.  This code fails to allocate a resource:

        dev->irqrid = 0;
        dev->irqr = bus_alloc_resource_any(dev->device, SYS_RES_IRQ,
                                      &dev->irqrid, RF_SHAREABLE);

The error handler is then called, which destroys the IRQ mutex.  This
all happens while X is initialising.

Later on, when glxgears is run, radeon_wait_irq() in
src/sys/dev/drm/radeon_irq.c is called, which does a DRM_WAIT_ON, which
tries to acquire the destroyed mutex.

So, it looks like there should be some checking somewhere that
dev->irq_enabled is non-zero before trying to acquire this mutex.  I
don't know where it should go, though.

Gavin