From owner-freebsd-stable@FreeBSD.ORG Mon Dec 18 17:30:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B248416A40F; Mon, 18 Dec 2006 17:30:42 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw4.york.ac.uk (mail-gw4.york.ac.uk [144.32.128.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62DF643C9F; Mon, 18 Dec 2006 17:30:40 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw4.york.ac.uk (8.13.6/8.13.6) with ESMTP id kBIGwm9L001141; Mon, 18 Dec 2006 16:58:48 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.8/8.13.6) with ESMTP id kBIGwRZG001367; Mon, 18 Dec 2006 16:58:27 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.8/8.13.6/Submit) id kBIGwRlp001366; Mon, 18 Dec 2006 16:58:27 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: freebsd-stable@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 Dec 2006 16:58:17 +0000 Message-Id: <1166461097.1296.4.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: anholt@freebsd.org Subject: radeon panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:128 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2006 17:30:42 -0000 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