From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 13 20:37:21 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9B0D16A420; Mon, 13 Feb 2006 20:37:21 +0000 (GMT) (envelope-from antoine@peanut.dreadbsd.org) Received: from barton.dreadbsd.org (peanut.dreadbsd.org [82.67.196.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB11143D55; Mon, 13 Feb 2006 20:37:20 +0000 (GMT) (envelope-from antoine@peanut.dreadbsd.org) Received: from barton.dreadbsd.org (localhost [127.0.0.1]) by barton.dreadbsd.org (8.13.4/8.13.4) with ESMTP id k1DKbJF9013097; Mon, 13 Feb 2006 21:37:19 +0100 (CET) (envelope-from antoine@peanut.dreadbsd.org) Received: (from antoine@localhost) by barton.dreadbsd.org (8.13.4/8.13.1/Submit) id k1DKbJth013096; Mon, 13 Feb 2006 21:37:19 +0100 (CET) (envelope-from antoine) Date: Mon, 13 Feb 2006 21:37:19 +0100 From: Antoine Brodin To: John Baldwin Message-Id: <20060213213719.7767921e.antoine.brodin@laposte.net> In-Reply-To: <200602131430.11228.jhb@freebsd.org> References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <200602131223.51561.jhb@freebsd.org> <20060213193613.547d1b8f.antoine.brodin@laposte.net> <200602131430.11228.jhb@freebsd.org> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.12; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org Subject: Re: sparc64/93226: DEBUG_LOCKS (really stack_save()) causes panics on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 20:37:21 -0000 John Baldwin wrote: > On Monday 13 February 2006 13:36, Antoine Brodin wrote: > > John Baldwin wrote: > > > If there are kernel functions before the assembly ones (dependent on link > > > order) then this would wrongly bail when it hit those. I think you need > > > to do what the ddb stack tracing code does which is to lookup the symbol > > > name and do a bcmp() on the first 4 chars to recognize trapframes. > > > > I ran objdump -d on a sparc64 kernel and it looks like tl0_* and tl1_* > > are always at the beginning of the code, there is some kind of magic. > > magic aside, it would be best to use the same algorithm in both places IMO. > It would also be a lot more intuitive to other folks later on. There are 2 reasons why I didn't use db_search_symbol() and db_symbol_values() : - first they aren't reentrant, they use a global variable db_last_symtab and they can panic if a thread sets db_last_symtab to 0 while another one is using it. I found this in my mail archive : %%% Stopped at X_db_symbol_values+0x18: cmpl $0,0xc(%eax) db> trace Tracing pid 34983 tid 100093 td 0xc2e9c640 X_db_symbol_values(0,c0738214,e84859f4,e84859c4,7c) at X_db_symbol_values+0x18 db_symbol_values(c0738214,e84859f4,0,c89d19c8,0) at db_symbol_values+0x40 %%% It can be fixed easily but I don't have the fix anymore. You can use linker_ddb_search_symbol() and linker_ddb_symbol_values() too that are safer. - the second reason is performance. if you replace CTRSTACK(KTR_LOCK, &stack, 0, 1); by CTRSTACK(KTR_LOCK, &stack, 0, 0); in kern_lock.c, i.e. if you print the symbol name in the ktr traces, you will notice that your box is extremely slow. (you type ls, you wait 4 or 5 seconds and you have the result) voila Antoine