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

[John Baldwin]

On Monday 18 December 2006 13:11, Gavin Atkinson wrote:
> 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.

Probably it needs to not create the /dev/drm0 device unless it is able to 
allocate resources.  That is, it should do something like this in attach:

	bus_alloc_resource_any(..., SYS_RES_MEMORY, ...)
	bus_alloc_resource_any(..., SYS_RES_IRQ, ...)
	bus_setup_intr(...)
	make_dev(...)

Where if any step fails it undoes the previous steps and fails to attach.

-- 
John Baldwin