Date: Sun, 12 Feb 2006 01:20:51 -0500 (EST) From: Kris Kennaway <kris@FreeBSD.org> To: FreeBSD-gnats-submit@FreeBSD.org Cc: Antoine Brodin <antoine.brodin@laposte.net> Subject: sparc64/93226: DEBUG_LOCKS (really stack_save()) causes panics on sparc64 Message-ID: <20060212062051.51200514CC@obsecurity.dyndns.org> Resent-Message-ID: <200602120630.k1C6U6dg049384@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 93226 >Category: sparc64 >Synopsis: DEBUG_LOCKS (really stack_save()) causes panics on sparc64 >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-sparc64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Feb 12 06:30:06 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Kris Kennaway >Release: FreeBSD 7.0-CURRENT sparc64 >Organization: >Environment: FreeBSD/sparc64 7.0 >Description: With option DEBUG_LOCKS in the kernel, the stack(9) code that is intended to save stack traces when lockmgr locks are acquired is broken: > panic: trap: fast data access mmu miss > cpuid = 1 > KDB: enter: panic > [thread pid 1 tid 100009 ] > Stopped at kdb_enter+0x3c: ta %xcc, 1 > db> wh > Tracing pid 1 tid 100009 td 0xfffff800fed24750 > panic() at panic+0x164 > trap() at trap+0x418 > -- fast data access mmu miss tar=0x7fdffffe000 %o7=0xc027c940 -- > stack_save() at stack_save+0x24 [...] >How-To-Repeat: Build and boot a kernel with options DEBUG_LOCKS >Fix: A similar bug existed on i386, and was fixed in http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/db_trace.c.diff?r1=1.69&r2=1.70 >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060212062051.51200514CC>