Date: Fri, 13 Mar 2009 17:18:19 +0200 From: Mikolaj Golub <to.my.trociny@gmail.com> To: Nick Withers <nick@nickwithers.com> Cc: freebsd-stable@freebsd.org Subject: Re: NICs locking up, "*tcp_sc_h" Message-ID: <813adha1tw.fsf@zhuzha.ua1> In-Reply-To: <1236938184.1490.40.camel@localhost> (Nick Withers's message of "Fri\, 13 Mar 2009 20\:56\:24 %2B1100") References: <1236920519.1490.30.camel@localhost> <alpine.BSF.2.00.0903130935290.61873@fledge.watson.org> <1236938184.1490.40.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Mar 2009 20:56:24 +1100 Nick Withers wrote: > I'm sorry to ask what is probably a very simple question, but is there > somewhere I should look to get clues on debugging from a manually > generated dump? I tried "panic" after manually envoking the kernel > debugger but proved highly inept at getting from the dump the same > information "ps" / "where" gave me within the debugger live. You can capture ddb session in capture buffer and then extract it from the dump. In ddb run capture on do your debugging then run "panic" or "call doadump" and after reboot: ddb capture -M /var/crash/vmcore.X print > out I would recommend to increase debug.ddb.capture.bufsize sysctl variable to be sure all the ddb session will be captured. -- Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?813adha1tw.fsf>