Re: radeon panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:128
On Monday 18 December 2006 13:11, Gavin Atkinson wrote: On Mon, 2006-12-18 at 16:58 +, 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]:/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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: radeon panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:128
On Mon, 2006-12-18 at 16:58 +, 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
