Date: Thu, 11 Jan 2007 13:00:28 -0500 From: John Baldwin <jhb@freebsd.org> 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: <200701111300.29080.jhb@freebsd.org> In-Reply-To: <1166465500.1292.7.camel@buffy.york.ac.uk> References: <1166461097.1296.4.camel@buffy.york.ac.uk> <1166465500.1292.7.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200701111300.29080.jhb>