Date: Mon, 18 Dec 2006 18:11:40 +0000 From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: freebsd-stable@freebsd.org Cc: anholt@freebsd.org Subject: Re: radeon panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:128 Message-ID: <1166465500.1292.7.camel@buffy.york.ac.uk> In-Reply-To: <1166461097.1296.4.camel@buffy.york.ac.uk> References: <1166461097.1296.4.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1166465500.1292.7.camel>