From owner-freebsd-current@FreeBSD.ORG Mon Feb 26 23:42:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E52B16A401 for ; Mon, 26 Feb 2007 23:42:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id EAC8213C48D for ; Mon, 26 Feb 2007 23:42:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l1QNgb7V044454; Mon, 26 Feb 2007 18:42:44 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 26 Feb 2007 18:34:13 -0500 User-Agent: KMail/1.9.1 References: <20070223061822.GA1497@obelix.dsto.defence.gov.au> <20070223113439.GK39168@deviant.kiev.zoral.com.ua> In-Reply-To: <20070223113439.GK39168@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702261834.13911.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 26 Feb 2007 18:42:46 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2656/Mon Feb 26 15:24:59 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov , "Wilkinson, Alex" Subject: Re: kgdb(1) ... is it broken ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 23:42:54 -0000 On Friday 23 February 2007 06:34, Kostik Belousov wrote: > On Fri, Feb 23, 2007 at 03:18:23PM +0900, Wilkinson, Alex wrote: > > Hi all, > > > > I have a reasonably recent version of current that is panic'ing at least once > > every 2 days. When I run kgdb(1) to do a backtrace it aint working correctly. > > > > [FreeBSD 7.0-CURRENT #0: Wed Jan 24 14:24:54 WST 2007] > > > > e.g. > > > > The panic: > > > > NVRM: Xid (0001:00): 8, Channel 00000000 > > panic: Bad link elm 0xc4dc8900 next->prev != elm > > cpuid = 0 > > KDB: enter: panic > > [thread pid 909 tid 100080 ] > > Stopped at kdb_enter+0x32: leave > > db>tr > > Tracing pid 909 tid 100080 td 0xc47231b0 > > kdb_enter(c09ecabf,0,c09a4b15,e6a69a20,c47231b0,...) at kdb_enter+0x32 > > panic(c09a4b15,c4dc8900,4c,c09e8778,64,...) at panic+0x191 > > destroy_devl(c4714e80,e6a69a70,c0fe6cf0,c4dc8900,40,...) at destroy_devl+0x330 > > destroy_dev(c4dc8900,40,c47231b0,0,c4dc8900,...) at destroy_dev+0x13 > > nvidia_dev_close(c4dc8900,3,2000,c47231b0,c4e287d8,...) at nvidia_dev_close+0xa4 > > > > giant_close(c4dc8900,3,2000,c47231b0,e6a69adc,...) at giant_close+0x4f > > devfs_close(e6a69b28,3,c4e28754) at devfs_close+0x2d1 > > VOP_CLOSE_APV(c0a8de20,e6a69b28,c47231b0,c09f7b4c,11f,...) at VOP_CLOSE_APV+0x69 > > > > vn_close(c4e28754,3,c4306a80,c47231b0,203246,...) at vn_close+0x99 > > vn_closefile(c4bf0a20,c47231b0,c09e9165,889,c4e28754,...) at vn_closefile+0x88 > > fdrop_locked(c4bf0a20,c47231b0,2,c09ee59f,de,c47231b0,0,203246,c0b3b920,e6a69c24 > > ,c07517fb,c0af5494,0,c4b3522c,401,c09e9165,e6a69c4c,c0716a82,c4b3522c,1,c09ebc01 > > ,ae,0) at fdrop_locked+0xb9 > > closef(c4bf0a20,c47231b0,c09e9165,401,c0739bd6,...) at closef+0x1f4 > > kern_close(c47231b0,e,4,c4b346c0,1,...) at kern_close+0x188 > > syscall(e6a69d38) at syscall+0x155 > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (0, FreeBSD ELF32, nosys), eip = 0x2, esp = 0x203292, ebp = 0xc1d000 > > 01 --- > > MAXCPU(4000000,90ffff00,10c19ee7,58c28e8c,34c22fbb,...) at 0x2 > > db>panic > > panic: from debugger > > cpuid = 0 > > Uptime: 3d5h29m19s > > Physical memory: 1007 MB > > Dumping 219 MB: 204 188 172 156 140 124 108 92 76 60 44 28 12 > > Dump complete > > > > Upon a reboot I see this error: > > > > savecore: reboot after panic: Bad link elm 0xc4dc8900 next->prev != elm > > Feb 23 15:02:22 obelix savecore: reboot after panic: Bad link elm 0xc4dc8900 next->prev != elm > > > > And then the backtrace: > > > > #0 doadump () at pcpu.h:166 > > 166 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) where > > #0 doadump () at pcpu.h:166 > > #1 0xc0720c1b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:411 > > #2 0xc0720693 in panic (fmt=0xc09ab848 "from debugger") at > > /usr/src/sys/kern/kern_shutdown.c:567 > > #3 0xc047e490 in db_panic (addr=-1066121253, have_addr=0, count=-1, > > modif=0xe6a69810 "") at /usr/src/sys/ddb/db_command.c:433 > > #4 0xc047e870 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 > > #5 0xc04805fb in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 > > #6 0xc0744c19 in kdb_trap (type=0, code=0, tf=0xe6a699a4) at > > /usr/src/sys/kern/subr_kdb.c:502 > > #7 0xc0960ea5 in trap (frame=0xe6a699a4) at /usr/src/sys/i386/i386/trap.c:621 > > #8 0xc0948dbb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > #9 0x00000000 in ?? () > > (kgdb) > > > > Things just aint working as per normal. > > > > Has anyone had problems with running backtraces of kernel core dumps with kgdb(1) ? > > Try this patch, it shall allow to see useful backtrace in kgdb (I really > like to receive feedback on this one): > > Index: gnu/usr.bin/gdb/kgdb/trgt_i386.c > =================================================================== > RCS file: /usr/local/arch/ncvs/src/gnu/usr.bin/gdb/kgdb/trgt_i386.c,v > retrieving revision 1.5 > diff -u -r1.5 trgt_i386.c > --- gnu/usr.bin/gdb/kgdb/trgt_i386.c 11 Sep 2005 05:36:30 -0000 1.5 > +++ gnu/usr.bin/gdb/kgdb/trgt_i386.c 23 Feb 2007 11:31:39 -0000 > @@ -146,7 +146,7 @@ > *realnump = -1; > > ofs = (regnum >= I386_EAX_REGNUM && regnum <= I386_FS_REGNUM) > - ? kgdb_trgt_frame_offset[regnum] : -1; > + ? kgdb_trgt_frame_offset[regnum] + 4 : -1; > if (ofs == -1) > return; You can make the patch by dependent on the kern.osreldate (__FreeBSD_version) which is accesible as the global var 'osreldate' in the kernel and use the old offset for kernels before Kip's change so it works for both old and new. -- John Baldwin