From owner-freebsd-current@FreeBSD.ORG Tue Dec 4 06:06:17 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A778A16A417 for ; Tue, 4 Dec 2007 06:06:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outB.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id 94CBC13C465 for ; Tue, 4 Dec 2007 06:06:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 03 Dec 2007 22:06:17 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 949B6126B9E; Mon, 3 Dec 2007 22:06:16 -0800 (PST) Message-ID: <4754EE5A.7050904@elischer.org> Date: Mon, 03 Dec 2007 22:06:18 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Marcel Moolenaar References: <4754D411.6060608@elischer.org> <4754E54C.20104@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: remote gdb failures in recent builds (last 6 months or so.) 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: Tue, 04 Dec 2007 06:06:17 -0000 Marcel Moolenaar wrote: > On Dec 3, 2007, at 9:27 PM, Julian Elischer wrote: > >> It's slowly been getting worse (across many pairs of machines) over >> the last few years. finally today it just doesn't work at all. I've >> used this pair of machines many times before. usually it takes "luck" >> to get synced up but once it's synced, it's solid. > > How do you start the connection? I seem to recall that starting with > the gdb client is not a good idea, because the gdb client will try > a couple of commands first to see if the stub supports them. If the > stub is not ready, then the gdb client may think the stub is not > capable of certain features. > > I typically have the kernel break into the GDB debugger first and > then I start the gdb client... > first the kernel panic'd then I was in kdb on the serial console (com1) then I typed "gdb" followed by 's'. I'm not worried so much about the panic as its an experimental kernel, but by not being able to debug it.. # panic: Bad tailq NEXT(0xd9f356f8->tqh_last) != NULL cpuid = 1 KDB: enter: panic [thread pid 19 tid 100037 ] Stopped at kdb_enter+0x32: leave db> tr Tracing pid 19 tid 100037 td 0xc5fabc60 kdb_enter(c076ae89,1,c074ea89,ee832c2c,1,...) at kdb_enter+0x32 panic(c074ea89,d9f356f8,c076c29e,1a3,25e,...) at panic+0x124 callout_reset(c08aa700,1,c0636140,0,c5feb000,c5fabc60,ee832c70,3,c08aa634,c08aa9 dummynet_task(0,1,c076f439,50,c61dec9c,...) at dummynet_task+0x332 taskqueue_run(c61dec80,c61dec9c,c0762a86,0,c0769a89,...) at taskqueue_run+0x10b taskqueue_thread_loop(c08aa5f0,ee832d38,c07673b9,30c,c5fabc60,...) at taskqueue8 fork_exit(c05add90,c08aa5f0,ee832d38) at fork_exit+0x120 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xee832d70, ebp = 0 --- db> gdb Step to enter the remote GDB backend. db>