From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 12 05:26:04 2006 Return-Path: X-Original-To: freebsd-sparc64@hub.freebsd.org Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D0DC16A420; Sun, 12 Feb 2006 05:26:04 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D828043D45; Sun, 12 Feb 2006 05:26:03 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1C5Q3Af042260; Sun, 12 Feb 2006 05:26:03 GMT (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1C5Q30h042256; Sun, 12 Feb 2006 05:26:03 GMT (envelope-from kris) Date: Sun, 12 Feb 2006 05:26:03 GMT From: Kris Kennaway Message-Id: <200602120526.k1C5Q30h042256@freefall.freebsd.org> To: gaspolo@gmail.com, kris@FreeBSD.org, freebsd-sparc64@FreeBSD.org Cc: Subject: Re: sparc64/77417: [panic] with high usage of cpu when lan users exchange file from lan only 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: Sun, 12 Feb 2006 05:26:04 -0000 Synopsis: [panic] with high usage of cpu when lan users exchange file from lan only State-Changed-From-To: open->closed State-Changed-By: kris State-Changed-When: Sun Feb 12 05:25:52 UTC 2006 State-Changed-Why: Feedback timeout http://www.freebsd.org/cgi/query-pr.cgi?pr=77417 From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 12 06:27:13 2006 Return-Path: X-Original-To: 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 7619416A420 for ; Sun, 12 Feb 2006 06:27:13 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 367FE43D45 for ; Sun, 12 Feb 2006 06:27:13 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 1FA6C1A3C1B for ; Sat, 11 Feb 2006 22:27:13 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 65EC9514CC; Sun, 12 Feb 2006 01:27:12 -0500 (EST) Date: Sun, 12 Feb 2006 01:27:12 -0500 From: Kris Kennaway To: Kris Kennaway Message-ID: <20060212062712.GA55462@xor.obsecurity.org> References: <20060122191205.GA48267@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <20060122191205.GA48267@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: sparc64@FreeBSD.org Subject: Re: panic in tsb_tte_lookup() 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: Sun, 12 Feb 2006 06:27:13 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 22, 2006 at 02:12:05PM -0500, Kris Kennaway wrote: > 12-processor e4500 running 7.0: >=20 > panic: trap: data access error >=20 > db> wh > Tracing pid 57006 tid 100210 td 0xfffff80256141110 > panic() at panic+0x164 > trap() at trap+0x418 > -- data access error %o7=3D0xc0305490 -- > tsb_tte_lookup() at tsb_tte_lookup+0xd0 > pmap_copy() at pmap_copy+0xe0 > vm_map_copy_entry() at vm_map_copy_entry+0x12c > vmspace_fork() at vmspace_fork+0x2f4 > vm_forkproc() at vm_forkproc+0xe4 > fork1() at fork1+0xe14 > fork() at fork+0x10 > syscall() at syscall+0x2dc > -- syscall (2, FreeBSD ELF64, fork) %o7=3D0x1101a0 -- > userland() at 0x40649088 > user trace: trap %o7=3D0x1101a0 > pc 0x40649088, sp 0x7fdffffd701 > pc 0x106890, sp 0x7fdffffd7c1 > pc 0x1072b0, sp 0x7fdffffd981 > pc 0x10a498, sp 0x7fdffffda71 > pc 0x10be24, sp 0x7fdffffdc21 > pc 0x1065e8, sp 0x7fdffffdce1 For the benefits of the archives (and possibly myself the next time I encounter this and have forgotten again) this and related panics are because the e4500 detected a hardware failure in one of the CPU boards and tried to take it offline, and FreeBSD was blithely unaware of this and promptly panicked. Kris --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD7tVAWry0BWjoQKURAnrPAJ9NmYV0l0nRJUZ839Sa3bmmS/TfsACfeUnh D2JIX488CmT+RzC9F+yEFo4= =i8Y5 -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 12 06:30:07 2006 Return-Path: X-Original-To: freebsd-sparc64@hub.freebsd.org Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9A8B16A420 for ; Sun, 12 Feb 2006 06:30:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E71E43D45 for ; Sun, 12 Feb 2006 06:30:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1C6U6HB049389 for ; Sun, 12 Feb 2006 06:30:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1C6U6dg049384; Sun, 12 Feb 2006 06:30:06 GMT (envelope-from gnats) Resent-Date: Sun, 12 Feb 2006 06:30:06 GMT Resent-Message-Id: <200602120630.k1C6U6dg049384@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-sparc64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Kris Kennaway Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F0DA16A420 for ; Sun, 12 Feb 2006 06:20:52 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2072443D45 for ; Sun, 12 Feb 2006 06:20:52 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 00C8C1A3C1B; Sat, 11 Feb 2006 22:20:51 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 51200514CC; Sun, 12 Feb 2006 01:20:51 -0500 (EST) Message-Id: <20060212062051.51200514CC@obsecurity.dyndns.org> Date: Sun, 12 Feb 2006 01:20:51 -0500 (EST) From: Kris Kennaway To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Antoine Brodin Subject: 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: Sun, 12 Feb 2006 06:30:08 -0000 >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: From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 12 06:30:35 2006 Return-Path: X-Original-To: freebsd-sparc64@hub.freebsd.org Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B77DD16A422; Sun, 12 Feb 2006 06:30:35 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FBC43D48; Sun, 12 Feb 2006 06:30:35 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1C6UYkT049847; Sun, 12 Feb 2006 06:30:34 GMT (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1C6UYbB049819; Sun, 12 Feb 2006 06:30:34 GMT (envelope-from kris) Date: Sun, 12 Feb 2006 06:30:34 GMT From: Kris Kennaway Message-Id: <200602120630.k1C6UYbB049819@freefall.freebsd.org> To: passworld@bk.ru, kris@FreeBSD.org, freebsd-sparc64@FreeBSD.org Cc: Subject: Re: sparc64/91334: FreeBSD 6.0 don't support tftp boot from remot tftp server (installing for sparc) 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: Sun, 12 Feb 2006 06:30:35 -0000 Synopsis: FreeBSD 6.0 don't support tftp boot from remot tftp server (installing for sparc) State-Changed-From-To: open->feedback State-Changed-By: kris State-Changed-When: Sun Feb 12 06:30:00 UTC 2006 State-Changed-Why: Did Miles' documentation help you? http://www.freebsd.org/cgi/query-pr.cgi?pr=91334 From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 12 22:14:34 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 9BA4A16A42A for ; Sun, 12 Feb 2006 22:14:34 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BCA243D4C for ; Sun, 12 Feb 2006 22:14:30 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) by newtrinity.zeist.de (8.12.11/8.12.11/ZEIST.DE) with ESMTP id k1CMETRT035434; Sun, 12 Feb 2006 23:14:29 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id k1CMEOCC035433; Sun, 12 Feb 2006 23:14:24 +0100 (CET) (envelope-from marius) Date: Sun, 12 Feb 2006 23:14:24 +0100 From: Marius Strobl To: Andreas Tobler Message-ID: <20060212231423.M53619@newtrinity.zeist.de> References: <20060205122153.O68720@newtrinity.zeist.de> <43E5E70D.1090209@pop.agri.ch> <20060205132234.P68720@newtrinity.zeist.de> <43E60F45.4070004@pop.agri.ch> <20060205175656.S68720@newtrinity.zeist.de> <43E7B94E.3070805@pop.agri.ch> <20060207170055.B53619@newtrinity.zeist.de> <43E8FC6B.50705@pop.agri.ch> <20060208173546.D53619@newtrinity.zeist.de> <43EE7108.2040200@pop.agri.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <43EE7108.2040200@pop.agri.ch>; from toa@pop.agri.ch on Sun, Feb 12, 2006 at 12:19:36AM +0100 X-AntiVirus-modified: yes X-AntiVirus: checked by AntiVir Milter (version: 1.1.2-1; AVE: 6.33.0.31; VDF: 6.33.0.229; host: newtrinity.zeist.de) Cc: freebsd-sparc64@freebsd.org Subject: Re: profiling with cc 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: Sun, 12 Feb 2006 22:14:35 -0000 On Sun, Feb 12, 2006 at 12:19:36AM +0100, Andreas Tobler wrote: > Marius Strobl wrote: > > On Tue, Feb 07, 2006 at 09:00:43PM +0100, Andreas Tobler wrote: > >> Attached what I have so far. I built a libc_p.a and I can compile some > >> code with -pg and do some investigations with gprof now. > >> > >> Done on an enterprise 2 2x296MHz 896MB. > >> > >> FreeBSD enterprise.andreas.nets 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun > >> Feb 5 08:20:12 CET 2006 > >> andreast@enterprise.andreas.nets:/usr/obj/home/andreast/devel/src/sys/GENERIC > >> sparc64 > >> > >> What I do not know yet, is the fact, how reliably the figures are. > >> > > > > It should work fine for C functions but the ENTRY macro in > > sparc64/include/asm.h has to be changed to call _mcount() so profiling > > info is also gathered for asm functions (e.g. those in libc). > > Ok, after some reading I got confused. > > Do you expect an ENTRY for normal operation and one for PROFILED work? An ENTRY_NOPROFILE which just never calls _mcount() and basically does what ENTRY currently does and a new ENTRY that calls _mcount() depending on whether GPROF is defined. I currently however don't see where/when GPROF would be defined for userland so this might actually be only relevant for kernel profiling. The latter would surprise me though. > > > >> Would you mind giving me some feedback if the attached is useful/needs > >> rework? > >> > > > > It has some style issues and inconsitencies (see style(9) and other > > inline asm in e.g. sparc64/include/cpufunc.h). Otherwise it looks > > good but probably needs a PIC version of the MCOUNT asm so it also > > works when compiling with -p. > > > Regarding inline asm, do you mean something like this: > #define MCOUNT ({ \ > __asm __volatile( \ > " .global __mcount ; " \ > "__mcount: ; " \ > " add %o7, 8, %o1 ; " \ > "1: call 2f ; " \ > " nop ; " \ > "2: add %o7, _mcount - 1b, %o2 ; " \ > " ld [%o2], %o2 ; " \ > " jmpl %o2, %g0 ; " \ > " add %i7, 8, %o0 ; "); > }) Yes, that's what I meant regarding the style of the inline asm. The only minor issue in the above version is that the instruction which is executed in the delay slot is not extra indented by one space. > > style 9 is good to have, but I seem to run in corner cases (my > impression). It would be helpful for me to point out exactly what you > mean I'm doing 'wrong'. The other issue with your last patch was that you added macros with #defined and changed one that way while the rest of the file adheres to style(9) and uses #define. > Going through the code shows some > inconsistencies and I am confused, as said ;) Depends at what code you look at. F.e. the code in sys/kern and sys/sparc64 generally pretty much adheres to style(9) while quite a lot device drivers do not. Regarding the sparc64 MCOUNT macro for userland I think it would be better to follow the approach of the i386 version, i.e. to let it define a C function and only determine frompc and selfpc via inline asm instead of an asm function. That way we don't need to distinguish between the PIC and !PIC case as the compiler will do the necessary work for us. When compiling libc with -O2 GCC generates exactly the same asm we'd do in the pure asm variant for the !PIC case. For the PIC case the generated asm is even better optimized as we could do in a generic way in a pure asm variant. Marius -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 13 11:02:48 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 1606916A422 for ; Mon, 13 Feb 2006 11:02:48 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D37D543D45 for ; Mon, 13 Feb 2006 11:02:47 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1DB2luQ067455 for ; Mon, 13 Feb 2006 11:02:47 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1DB2kKW067449 for freebsd-sparc64@freebsd.org; Mon, 13 Feb 2006 11:02:46 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 13 Feb 2006 11:02:46 GMT Message-Id: <200602131102.k1DB2kKW067449@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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 11:02:48 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/09/14] sparc64/71729sparc64 printf in kernel thread causes panic on S o [2004/10/21] sparc64/72962sparc64 [sysinstall] Sysinstall panics on sparc64 o [2005/04/27] sparc64/80410sparc64 [netgraph] netgraph is causing crash with o [2005/05/11] sparc64/80890sparc64 [panic] kmem_malloc(73728): kmem_map too o [2005/06/23] sparc64/82569sparc64 USB mass storage plug/unplug causes syste o [2005/11/24] sparc64/89486sparc64 firefox and thunderbird is broken on spar o [2006/01/16] sparc64/91882sparc64 Ultra 10 mouse/keyboard o [2006/01/20] sparc64/92033sparc64 [dc] dc(4) issues on Ultra10 8 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/22] sparc64/72998sparc64 [kernel] [patch] set_mcontext() change sy s [2005/06/26] sparc64/82681sparc64 [dc] dc state messages o [2005/12/13] sparc64/90316sparc64 Keyboard "lock" key lights not working pr f [2006/01/05] sparc64/91334sparc64 FreeBSD 6.0 don't support tftp boot from o [2006/02/12] sparc64/93226sparc64 DEBUG_LOCKS (really stack_save()) causes 5 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 13 11:50:11 2006 Return-Path: X-Original-To: freebsd-sparc64@hub.freebsd.org Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E67116A420 for ; Mon, 13 Feb 2006 11:50:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09CB243D46 for ; Mon, 13 Feb 2006 11:50:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1DBo6qr074439 for ; Mon, 13 Feb 2006 11:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1DBo6S1074438; Mon, 13 Feb 2006 11:50:06 GMT (envelope-from gnats) Date: Mon, 13 Feb 2006 11:50:06 GMT Message-Id: <200602131150.k1DBo6S1074438@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: Antoine Brodin Cc: 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 Reply-To: Antoine Brodin 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 11:50:11 -0000 The following reply was made to PR sparc64/93226; it has been noted by GNATS. From: Antoine Brodin To: bug-followup@FreeBSD.org, kris@FreeBSD.org Cc: Subject: Re: sparc64/93226: DEBUG_LOCKS (really stack_save()) causes panics on sparc64 Date: Mon, 13 Feb 2006 12:44:34 +0100 This is a multi-part message in MIME format. --Multipart=_Mon__13_Feb_2006_12_44_34_+0100_lHFJ6LWhOkOa2zgV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Here is a proposed patch. It is untested (just compile tested) since I don't have this hardware. --Multipart=_Mon__13_Feb_2006_12_44_34_+0100_lHFJ6LWhOkOa2zgV Content-Type: text/plain; name="sparc64-stack_save.diff" Content-Disposition: attachment; filename="sparc64-stack_save.diff" Content-Transfer-Encoding: 7bit Index: sys/sparc64/sparc64/db_trace.c =================================================================== RCS file: /home/ncvs/src/sys/sparc64/sparc64/db_trace.c,v retrieving revision 1.24 diff -u -p -r1.24 db_trace.c --- sys/sparc64/sparc64/db_trace.c 3 Aug 2005 04:27:39 -0000 1.24 +++ sys/sparc64/sparc64/db_trace.c 13 Feb 2006 11:31:13 -0000 @@ -307,6 +307,12 @@ stack_save(struct stack *st) callpc = fp->fr_pc; if (!INKERNEL(callpc)) break; + /* + * Don't bother traversing trap-frames. + * tl0_* and tl1_* are just below fork_trampoline + */ + if (callpc < (vm_offset_t)fork_trampoline) + break; if (stack_put(st, callpc) == -1) break; fp = (struct frame *)(fp->fr_fp + SPOFF); --Multipart=_Mon__13_Feb_2006_12_44_34_+0100_lHFJ6LWhOkOa2zgV-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 13 18:19:12 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 E839616A420 for ; Mon, 13 Feb 2006 18:19:12 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81B5C43D72 for ; Mon, 13 Feb 2006 18:18:49 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 8364877 for multiple; Mon, 13 Feb 2006 13:18:09 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k1DIIkid050977; Mon, 13 Feb 2006 13:18:46 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-sparc64@freebsd.org, Antoine Brodin Date: Mon, 13 Feb 2006 12:23:50 -0500 User-Agent: KMail/1.9.1 References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> In-Reply-To: <200602131150.k1DBo6S1074438@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602131223.51561.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1286/Mon Feb 13 06:41:56 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: 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 18:19:13 -0000 On Monday 13 February 2006 06:50, Antoine Brodin wrote: > The following reply was made to PR sparc64/93226; it has been noted by > GNATS. > > From: Antoine Brodin > To: bug-followup@FreeBSD.org, kris@FreeBSD.org > Cc: > Subject: Re: sparc64/93226: DEBUG_LOCKS (really stack_save()) causes panics > on sparc64 > Date: Mon, 13 Feb 2006 12:44:34 +0100 > > This is a multi-part message in MIME format. > > --Multipart=_Mon__13_Feb_2006_12_44_34_+0100_lHFJ6LWhOkOa2zgV > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > > Here is a proposed patch. > > It is untested (just compile tested) since I don't have this hardware. > > --Multipart=_Mon__13_Feb_2006_12_44_34_+0100_lHFJ6LWhOkOa2zgV > Content-Type: text/plain; > name="sparc64-stack_save.diff" > Content-Disposition: attachment; > filename="sparc64-stack_save.diff" > Content-Transfer-Encoding: 7bit > > Index: sys/sparc64/sparc64/db_trace.c > =================================================================== > RCS file: /home/ncvs/src/sys/sparc64/sparc64/db_trace.c,v > retrieving revision 1.24 > diff -u -p -r1.24 db_trace.c > --- sys/sparc64/sparc64/db_trace.c 3 Aug 2005 04:27:39 -0000 1.24 > +++ sys/sparc64/sparc64/db_trace.c 13 Feb 2006 11:31:13 -0000 > @@ -307,6 +307,12 @@ stack_save(struct stack *st) > callpc = fp->fr_pc; > if (!INKERNEL(callpc)) > break; > + /* > + * Don't bother traversing trap-frames. > + * tl0_* and tl1_* are just below fork_trampoline > + */ > + if (callpc < (vm_offset_t)fork_trampoline) > + break; > if (stack_put(st, callpc) == -1) > break; > fp = (struct frame *)(fp->fr_fp + SPOFF); 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 13 18:36:16 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 D5D7F16A420; Mon, 13 Feb 2006 18:36:16 +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 D370143D6D; Mon, 13 Feb 2006 18:36:15 +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 k1DIaEuQ012663; Mon, 13 Feb 2006 19:36:14 +0100 (CET) (envelope-from antoine@peanut.dreadbsd.org) Received: (from antoine@localhost) by barton.dreadbsd.org (8.13.4/8.13.1/Submit) id k1DIaDI0012662; Mon, 13 Feb 2006 19:36:13 +0100 (CET) (envelope-from antoine) Date: Mon, 13 Feb 2006 19:36:13 +0100 From: Antoine Brodin To: John Baldwin Message-Id: <20060213193613.547d1b8f.antoine.brodin@laposte.net> In-Reply-To: <200602131223.51561.jhb@freebsd.org> References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <200602131223.51561.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 18:36:17 -0000 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. Cheers, Antoine From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 13 19:48:45 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 8967B16A420 for ; Mon, 13 Feb 2006 19:48:45 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86FFB43D70 for ; Mon, 13 Feb 2006 19:48:44 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 8370598 for multiple; Mon, 13 Feb 2006 14:47:58 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k1DJmZNb051482; Mon, 13 Feb 2006 14:48:36 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Antoine Brodin Date: Mon, 13 Feb 2006 14:30:09 -0500 User-Agent: KMail/1.9.1 References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <200602131223.51561.jhb@freebsd.org> <20060213193613.547d1b8f.antoine.brodin@laposte.net> In-Reply-To: <20060213193613.547d1b8f.antoine.brodin@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602131430.11228.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1286/Mon Feb 13 06:41:56 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 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 19:48:45 -0000 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org 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 From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 14 01:49:01 2006 Return-Path: X-Original-To: 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 790C216A420; Tue, 14 Feb 2006 01:48:59 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F9543D48; Tue, 14 Feb 2006 01:48:58 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id k1E1mw9V032101; Mon, 13 Feb 2006 20:48:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id k1E1mvnN051814; Mon, 13 Feb 2006 20:48:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C4B117302F; Mon, 13 Feb 2006 20:48:57 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060214014857.C4B117302F@freebsd-current.sentex.ca> Date: Mon, 13 Feb 2006 20:48:57 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 01:49:01 -0000 TB --- 2006-02-14 01:08:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-02-14 01:08:39 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-02-14 01:08:39 - cleaning the object tree TB --- 2006-02-14 01:09:11 - checking out the source tree TB --- 2006-02-14 01:09:11 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-02-14 01:09:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-02-14 01:16:45 - building world (CFLAGS=-O2 -pipe) TB --- 2006-02-14 01:16:45 - cd /src TB --- 2006-02-14 01:16:45 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] ===> usr.sbin/bsnmpd/modules/snmp_hostres (depend) cat /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_tree.def | gensnmptree -e host hrStorageOther hrStorageRam hrStorageVirtualMemory hrStorageFixedDisk hrStorageRemovableDisk hrStorageFloppyDisk hrStorageCompactDisc hrStorageRamDisk hrStorageFlashMemory hrStorageNetworkDisk hrDeviceOther hrDeviceUnknown hrDeviceProcessor hrDeviceNetwork hrDevicePrinter hrDeviceDiskStorage hrDeviceVideo hrDeviceAudio hrDeviceCoprocessor hrDeviceKeyboard hrDeviceModem hrDeviceParallelPort hrDevicePointing hrDeviceSerialPort hrDeviceTape hrDeviceClock hrDeviceVolatileMemory hrDeviceNonVolatileMemory hrFSOther hrFSUnknown hrFSBerkeleyFFS hrFSSys5FS hrFSFat hrFSHPFS hrFSHFS hrFSMFS hrFSNTFS hrFSVNode hrFSJournaled hrFSiso9660 hrFSRockRidge hrFSNFS hrFSNetware hrFSAFS hrFSDFS hrFSAppleshare hrFSRFS hrFSDGCFS hrFSBFS hrFSFAT32 hrFSLinuxExt2 > hostres_oid.h cat /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_tree.def | gensnmptree -p hostres_ rm -f .depend mkdep -f .depend -a -DNDEBUG -I/src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/common_source -I. /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_begemot.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_device_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_fs_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_network_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_partition_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_printer_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_processor_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_scalars.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_snmp.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_storage_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_swinstalled_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_swrun_tbl.c /src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/common_ source/printcap.c hostres_tree.c echo snmp_hostres.so.4: /obj/sparc64/src/tmp/usr/lib/libkvm.a /obj/sparc64/src/tmp/usr/lib/libdevinfo.a /obj/sparc64/src/tmp/usr/lib/libm.a /obj/sparc64/src/tmp/usr/lib/libgeom.a /obj/sparc64/src/tmp/usr/lib/libmemstat.a >> .depend ===> usr.sbin/bsnmpd/modules/snmp_mibII (depend) make: don't know how to make mibII_begemot.c. Stop *** Error code 2 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-02-14 01:48:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-02-14 01:48:57 - ERROR: failed to build world TB --- 2006-02-14 01:48:57 - tinderbox aborted TB --- 0.87 user 4.91 system 2418.26 real From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 14 08:48:03 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 A2BE816A420; Tue, 14 Feb 2006 08:48:03 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5133143D55; Tue, 14 Feb 2006 08:47:59 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) by newtrinity.zeist.de (8.12.11/8.12.11/ZEIST.DE) with ESMTP id k1E8lsfZ082414; Tue, 14 Feb 2006 09:47:54 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id k1E8ljCH082413; Tue, 14 Feb 2006 09:47:45 +0100 (CET) (envelope-from marius) Date: Tue, 14 Feb 2006 09:47:44 +0100 From: Marius Strobl To: Antoine Brodin Message-ID: <20060214094744.A81690@newtrinity.zeist.de> References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <200602131223.51561.jhb@freebsd.org> <20060213193613.547d1b8f.antoine.brodin@laposte.net> <200602131430.11228.jhb@freebsd.org> <20060213213719.7767921e.antoine.brodin@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060213213719.7767921e.antoine.brodin@laposte.net>; from antoine.brodin@laposte.net on Mon, Feb 13, 2006 at 09:37:19PM +0100 X-AntiVirus-modified: yes X-AntiVirus: checked by AntiVir Milter (version: 1.1.2-1; AVE: 6.33.0.31; VDF: 6.33.0.232; host: newtrinity.zeist.de) 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: Tue, 14 Feb 2006 08:48:03 -0000 On Mon, Feb 13, 2006 at 09:37:19PM +0100, Antoine Brodin wrote: > 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) > Can't we just use what's done in support.S and add two dummy symbols to mark the begin and end of the asm functions in question? Marius -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 14 19:54:41 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 AFE2716A420; Tue, 14 Feb 2006 19:54:41 +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 8C1DF43D58; Tue, 14 Feb 2006 19:54:37 +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 k1EJsXrM006764; Tue, 14 Feb 2006 20:54:33 +0100 (CET) (envelope-from antoine@peanut.dreadbsd.org) Received: (from antoine@localhost) by barton.dreadbsd.org (8.13.4/8.13.1/Submit) id k1EJsWg5006763; Tue, 14 Feb 2006 20:54:32 +0100 (CET) (envelope-from antoine) Date: Tue, 14 Feb 2006 20:54:32 +0100 From: Antoine Brodin To: Marius Strobl Message-Id: <20060214205432.38121641.antoine.brodin@laposte.net> In-Reply-To: <20060214094744.A81690@newtrinity.zeist.de> References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <200602131223.51561.jhb@freebsd.org> <20060213193613.547d1b8f.antoine.brodin@laposte.net> <200602131430.11228.jhb@freebsd.org> <20060213213719.7767921e.antoine.brodin@laposte.net> <20060214094744.A81690@newtrinity.zeist.de> 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: Tue, 14 Feb 2006 19:54:41 -0000 Marius Strobl wrote: > On Mon, Feb 13, 2006 at 09:37:19PM +0100, Antoine Brodin wrote: > > 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) > > > > Can't we just use what's done in support.S and add two dummy symbols > to mark the begin and end of the asm functions in question? There's already a tl0_base symbol. You can add a tl0_end (or tl1_end ?) symbol between tl1_intr and fork_trampoline. Cheers, Antoine From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 14 21:45:18 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 65EB416A420 for ; Tue, 14 Feb 2006 21:45:18 +0000 (GMT) (envelope-from toa@pop.agri.ch) Received: from exsmtp02.agrinet.ch (exsmtp02.agrinet.ch [81.221.252.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 329A443D68 for ; Tue, 14 Feb 2006 21:45:16 +0000 (GMT) (envelope-from toa@pop.agri.ch) Received: from smtp.messaging.ch ([10.50.252.215]) by exsmtp02.agrinet.ch with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 22:45:15 +0100 Received: from [192.168.225.5] ([80.219.88.141]) by smtp.messaging.ch with id xZlj1T00232ylCo0000000 for freebsd-sparc64@freebsd.org; Tue, 14 Feb 2006 22:45:44 +0100 X-IMP: RBL MAPS_ORDB: 0.00, RBL SORBS: 0.10, RBL SPAMCOP: 0.00, RBL SBL+XBL: 0.00, URL RHS: 0.00, URL SURBL: 0.00 Message-ID: <43F24F6A.8070108@pop.agri.ch> Date: Tue, 14 Feb 2006 22:45:14 +0100 From: Andreas Tobler User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Marius Strobl References: <20060205122153.O68720@newtrinity.zeist.de> <43E5E70D.1090209@pop.agri.ch> <20060205132234.P68720@newtrinity.zeist.de> <43E60F45.4070004@pop.agri.ch> <20060205175656.S68720@newtrinity.zeist.de> <43E7B94E.3070805@pop.agri.ch> <20060207170055.B53619@newtrinity.zeist.de> <43E8FC6B.50705@pop.agri.ch> <20060208173546.D53619@newtrinity.zeist.de> <43EE7108.2040200@pop.agri.ch> <20060212231423.M53619@newtrinity.zeist.de> In-Reply-To: <20060212231423.M53619@newtrinity.zeist.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2006 21:45:15.0473 (UTC) FILETIME=[F0BF1410:01C631AF] Cc: freebsd-sparc64@freebsd.org Subject: Re: profiling with cc 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: Tue, 14 Feb 2006 21:45:18 -0000 Marius Strobl wrote: >>> It should work fine for C functions but the ENTRY macro in >>> sparc64/include/asm.h has to be changed to call _mcount() so profiling >>> info is also gathered for asm functions (e.g. those in libc). >> Ok, after some reading I got confused. >> >> Do you expect an ENTRY for normal operation and one for PROFILED work? > > An ENTRY_NOPROFILE which just never calls _mcount() and basically does > what ENTRY currently does and a new ENTRY that calls _mcount() depending > on whether GPROF is defined. I currently however don't see where/when > GPROF would be defined for userland so this might actually be only > relevant for kernel profiling. The latter would surprise me though. Ok. Fine. And good, it's not just only me. Grepping through the sources made me wonder where all these defines are done, e.g. GPROF, GNUPROF. And I got stuck.... > >>>> Would you mind giving me some feedback if the attached is useful/needs >>>> rework? >>>> >>> It has some style issues and inconsitencies (see style(9) and other >>> inline asm in e.g. sparc64/include/cpufunc.h). Otherwise it looks >>> good but probably needs a PIC version of the MCOUNT asm so it also >>> works when compiling with -p. >> >> Regarding inline asm, do you mean something like this: >> #define MCOUNT ({ \ >> __asm __volatile( \ >> " .global __mcount ; " \ >> "__mcount: ; " \ >> " add %o7, 8, %o1 ; " \ >> "1: call 2f ; " \ >> " nop ; " \ >> "2: add %o7, _mcount - 1b, %o2 ; " \ >> " ld [%o2], %o2 ; " \ >> " jmpl %o2, %g0 ; " \ >> " add %i7, 8, %o0 ; "); >> }) > > Yes, that's what I meant regarding the style of the inline asm. The > only minor issue in the above version is that the instruction which > is executed in the delay slot is not extra indented by one space. Ok, I missed this one, I simply did not pay attention on delay slots and their handling. Heh, every bit in the existing code has its meaning.... And to be honest, I never paid attention to delay slots at all. Now I read the issue behind and I think I understand the basics. > >> style 9 is good to have, but I seem to run in corner cases (my >> impression). It would be helpful for me to point out exactly what you >> mean I'm doing 'wrong'. > > The other issue with your last patch was that you added macros with > #defined and changed one that way while the rest of the file > adheres to style(9) and uses #define. Hide myself :) > >> Going through the code shows some >> inconsistencies and I am confused, as said ;) > > Depends at what code you look at. F.e. the code in sys/kern and > sys/sparc64 generally pretty much adheres to style(9) while quite > a lot device drivers do not. I was grepping through the whole src/sys and src/lib tree. Thanks for giving reliable parts where to look for good examples. Maybe I was to generic when I said 'inconsistencies' but now I got more examples and I see where to go, certainly I won't catch all the details next time, but I hope a few more. > Regarding the sparc64 MCOUNT macro for userland I think it would > be better to follow the approach of the i386 version, i.e. to let > it define a C function and only determine frompc and selfpc via > inline asm instead of an asm function. That way we don't need to > distinguish between the PIC and !PIC case as the compiler will > do the necessary work for us. When compiling libc with -O2 GCC > generates exactly the same asm we'd do in the pure asm variant > for the !PIC case. For the PIC case the generated asm is even > better optimized as we could do in a generic way in a pure asm > variant. To summarize: - Take the sys/i386/include/profile.h as a 'template' for the mcount userland implementation. - Take care of the formatting style and have a look in the sys/kern |sys/sparc64 code. - Do _not_ change existing code if not necessary... Marius, thanks a lot for you comments, I appreciate them as I am not used to the fbsd coding rules. Regards, Andreas From owner-freebsd-sparc64@FreeBSD.ORG Wed Feb 15 02:53:42 2006 Return-Path: X-Original-To: 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 BC35916A420; Wed, 15 Feb 2006 02:53:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B75F843D49; Wed, 15 Feb 2006 02:53:41 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id k1F2reJ1085430; Tue, 14 Feb 2006 21:53:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4/8.13.4) with ESMTP id k1F2rwwN044144; Tue, 14 Feb 2006 21:53:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 65AB57302F; Tue, 14 Feb 2006 21:53:40 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060215025340.65AB57302F@freebsd-current.sentex.ca> Date: Tue, 14 Feb 2006 21:53:40 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2006 02:53:42 -0000 TB --- 2006-02-15 01:54:24 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-02-15 01:54:24 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-02-15 01:54:24 - cleaning the object tree TB --- 2006-02-15 01:54:34 - checking out the source tree TB --- 2006-02-15 01:54:34 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-02-15 01:54:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-02-15 02:02:14 - building world (CFLAGS=-O2 -pipe) TB --- 2006-02-15 02:02:14 - cd /src TB --- 2006-02-15 02:02:14 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/sbin/ifconfig/ifmedia.c:345: error: (near initialization for `ifm_subtype_ethernet_descriptions[16]') /src/sbin/ifconfig/ifmedia.c:345: error: `IFM_10GBASE_LR' undeclared here (not in a function) /src/sbin/ifconfig/ifmedia.c:345: error: initializer element is not constant /src/sbin/ifconfig/ifmedia.c:345: error: (near initialization for `ifm_subtype_ethernet_descriptions[17].ifmt_word') /src/sbin/ifconfig/ifmedia.c:345: error: initializer element is not constant /src/sbin/ifconfig/ifmedia.c:345: error: (near initialization for `ifm_subtype_ethernet_descriptions[17]') /src/sbin/ifconfig/ifmedia.c:345: error: initializer element is not constant /src/sbin/ifconfig/ifmedia.c:345: error: (near initialization for `ifm_subtype_ethernet_descriptions[18]') *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-02-15 02:53:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-02-15 02:53:40 - ERROR: failed to build world TB --- 2006-02-15 02:53:40 - tinderbox aborted TB --- 0.38 user 1.88 system 3555.82 real From owner-freebsd-sparc64@FreeBSD.ORG Thu Feb 16 12:48:32 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 95FF616A420; Thu, 16 Feb 2006 12:48:32 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E988943D46; Thu, 16 Feb 2006 12:48:31 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) by newtrinity.zeist.de (8.12.11/8.12.11/ZEIST.DE) with ESMTP id k1GCmUr1058287; Thu, 16 Feb 2006 13:48:30 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id k1GCmOQK058284; Thu, 16 Feb 2006 13:48:24 +0100 (CET) (envelope-from marius) Date: Thu, 16 Feb 2006 13:48:24 +0100 From: Marius Strobl To: Antoine Brodin , jhb@freebsd.org Message-ID: <20060216134823.S53619@newtrinity.zeist.de> References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <200602131223.51561.jhb@freebsd.org> <20060213193613.547d1b8f.antoine.brodin@laposte.net> <200602131430.11228.jhb@freebsd.org> <20060213213719.7767921e.antoine.brodin@laposte.net> <20060214094744.A81690@newtrinity.zeist.de> <20060214205432.38121641.antoine.brodin@laposte.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060214205432.38121641.antoine.brodin@laposte.net>; from antoine.brodin@laposte.net on Tue, Feb 14, 2006 at 08:54:32PM +0100 X-AntiVirus-modified: yes X-AntiVirus: checked by AntiVir Milter (version: 1.1.2-1; AVE: 6.33.0.31; VDF: 6.33.0.240; host: newtrinity.zeist.de) 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: Thu, 16 Feb 2006 12:48:32 -0000 --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 14, 2006 at 08:54:32PM +0100, Antoine Brodin wrote: > Marius Strobl wrote: > > On Mon, Feb 13, 2006 at 09:37:19PM +0100, Antoine Brodin wrote: > > > 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) > > > > > > > Can't we just use what's done in support.S and add two dummy symbols > > to mark the begin and end of the asm functions in question? > > There's already a tl0_base symbol. You can add a tl0_end (or tl1_end ?) > symbol between tl1_intr and fork_trampoline. > Ok, how about the attached patch? It uses two pairs of dummy symbols in exception.S to determine in stack_save() whether it was one of the tl0_*() or tl1_*() asm functions; one pair for those in the .trap section that is "magically" placed at the beginning of the .text section via the linker script and the other pair for those in the regular .text section. That way we don't rely on the location of these functions in the kernel and don't have the performance penalty of *search_symbol()/*symbol_values(). For consistency db_backtrace() is changed to also use the new markers instead of bcmp()'ing with the symbol names. Marius -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="db_tl.diff" Index: exception.S =================================================================== RCS file: /mnt/futile/usr/data/bsd/cvs/fbsd/src/sys/sparc64/sparc64/exception.S,v retrieving revision 1.71 diff -u -r1.71 exception.S --- exception.S 16 Jan 2006 01:35:25 -0000 1.71 +++ exception.S 16 Feb 2006 11:59:50 -0000 @@ -166,6 +166,10 @@ ldx [ASP_REG + 0], %g1 ; \ inc 16, ASP_REG + .globl tl_text_begin +tl_text_begin: + nop + ENTRY(tl1_kstack_fault) rdpr %tl, %g1 1: cmp %g1, 2 @@ -1818,6 +1822,10 @@ .endm .sect .trap + .globl tl_trap_begin +tl_trap_begin: + nop + .align 0x8000 .globl tl0_base @@ -2015,6 +2023,10 @@ tl1_gen T_RSTRWP_VIRT ! 0x303 tl1_reserved 252 ! 0x304-0x3ff + .globl tl_trap_end +tl_trap_end: + nop + /* * User trap entry point. * @@ -2901,6 +2913,10 @@ retry END(tl1_intr) + .globl tl_text_end +tl_text_end: + nop + /* * Freshly forked processes come here when switched to for the first time. * The arguments to fork_exit() have been setup in the locals, we must move Index: db_trace.c =================================================================== RCS file: /mnt/futile/usr/data/bsd/cvs/fbsd/src/sys/sparc64/sparc64/db_trace.c,v retrieving revision 1.24 diff -u -r1.24 db_trace.c --- db_trace.c 3 Aug 2005 04:27:39 -0000 1.24 +++ db_trace.c 16 Feb 2006 11:51:27 -0000 @@ -49,6 +49,11 @@ #include #include +extern char tl_trap_begin[]; +extern char tl_trap_end[]; +extern char tl_text_begin[]; +extern char tl_text_end[]; + #define INKERNEL(va) \ ((va) >= VM_MIN_KERNEL_ADDRESS && (va) <= VM_MAX_KERNEL_ADDRESS) @@ -259,8 +264,10 @@ name = "(null)"; fp = (struct frame *)(db_get_value((db_addr_t)&fp->fr_fp, sizeof(fp->fr_fp), FALSE) + SPOFF); - if (bcmp(name, "tl0_", 4) == 0 || - bcmp(name, "tl1_", 4) == 0) { + if ((value > (u_long)tl_trap_begin && + value < (u_long)tl_trap_end) || + (value > (u_long)tl_text_begin && + value < (u_long)tl_text_end)) { tf = (struct trapframe *)(fp + 1); npc = db_get_value((db_addr_t)&tf->tf_tpc, sizeof(tf->tf_tpc), FALSE); @@ -307,6 +314,12 @@ callpc = fp->fr_pc; if (!INKERNEL(callpc)) break; + /* Don't bother traversing trap frames. */ + if ((callpc > (u_long)tl_trap_begin && + callpc < (u_long)tl_trap_end) || + (callpc > (u_long)tl_text_begin && + callpc < (u_long)tl_text_end)) + break; if (stack_put(st, callpc) == -1) break; fp = (struct frame *)(fp->fr_fp + SPOFF); --uZ3hkaAS1mZxFaxD-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Feb 16 17:43:43 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 7B83616A420; Thu, 16 Feb 2006 17:43:43 +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 AB1A443D72; Thu, 16 Feb 2006 17:43:38 +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 k1GHhTGB005814; Thu, 16 Feb 2006 18:43:29 +0100 (CET) (envelope-from antoine@peanut.dreadbsd.org) Received: (from antoine@localhost) by barton.dreadbsd.org (8.13.4/8.13.1/Submit) id k1GHhSPf005813; Thu, 16 Feb 2006 18:43:28 +0100 (CET) (envelope-from antoine) Date: Thu, 16 Feb 2006 18:43:28 +0100 From: Antoine Brodin To: Marius Strobl Message-Id: <20060216184328.749c4454.antoine.brodin@laposte.net> In-Reply-To: <20060216134823.S53619@newtrinity.zeist.de> References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <200602131223.51561.jhb@freebsd.org> <20060213193613.547d1b8f.antoine.brodin@laposte.net> <200602131430.11228.jhb@freebsd.org> <20060213213719.7767921e.antoine.brodin@laposte.net> <20060214094744.A81690@newtrinity.zeist.de> <20060214205432.38121641.antoine.brodin@laposte.net> <20060216134823.S53619@newtrinity.zeist.de> 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: Thu, 16 Feb 2006 17:43:43 -0000 Marius Strobl wrote: > Ok, how about the attached patch? It uses two pairs of dummy symbols > in exception.S to determine in stack_save() whether it was one of the > tl0_*() or tl1_*() asm functions; one pair for those in the .trap > section that is "magically" placed at the beginning of the .text > section via the linker script and the other pair for those in the > regular .text section. That way we don't rely on the location of > these functions in the kernel and don't have the performance penalty > of *search_symbol()/*symbol_values(). For consistency db_backtrace() > is changed to also use the new markers instead of bcmp()'ing with > the symbol names. If this fixes the panic, that's excellent Cheers, Antoine From owner-freebsd-sparc64@FreeBSD.ORG Thu Feb 16 23:14:50 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 04ACA16A42A for ; Thu, 16 Feb 2006 23:14:50 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id D645743D69 for ; Thu, 16 Feb 2006 23:14:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 9262840 for multiple; Thu, 16 Feb 2006 18:14:47 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k1GNEM5H086940; Thu, 16 Feb 2006 18:14:27 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marius Strobl Date: Thu, 16 Feb 2006 18:09:36 -0500 User-Agent: KMail/1.9.1 References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <20060214205432.38121641.antoine.brodin@laposte.net> <20060216134823.S53619@newtrinity.zeist.de> In-Reply-To: <20060216134823.S53619@newtrinity.zeist.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602161809.38389.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1291/Thu Feb 16 15:15:09 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-sparc64@freebsd.org, Antoine Brodin 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: Thu, 16 Feb 2006 23:14:50 -0000 On Thursday 16 February 2006 07:48, Marius Strobl wrote: > On Tue, Feb 14, 2006 at 08:54:32PM +0100, Antoine Brodin wrote: > > Marius Strobl wrote: > > > On Mon, Feb 13, 2006 at 09:37:19PM +0100, Antoine Brodin wrote: > > > > 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) > > > > > > Can't we just use what's done in support.S and add two dummy symbols > > > to mark the begin and end of the asm functions in question? > > > > There's already a tl0_base symbol. You can add a tl0_end (or tl1_end ?) > > symbol between tl1_intr and fork_trampoline. > > Ok, how about the attached patch? It uses two pairs of dummy symbols > in exception.S to determine in stack_save() whether it was one of the > tl0_*() or tl1_*() asm functions; one pair for those in the .trap > section that is "magically" placed at the beginning of the .text > section via the linker script and the other pair for those in the > regular .text section. That way we don't rely on the location of > these functions in the kernel and don't have the performance penalty > of *search_symbol()/*symbol_values(). For consistency db_backtrace() > is changed to also use the new markers instead of bcmp()'ing with > the symbol names. Looks like a winner, thanks! -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org