Capturing dmesg upon system crash on 6.3

[Mel]

On Monday 25 February 2008 14:44:28 Yehonatan Yossef wrote:
> > On Monday 25 February 2008 13:32:01 Yehonatan Yossef wrote:
> > > > > I'm facing a system reboot upon loading of the driver, and
> > > >
> > > > I could use
> > > >
> > > > > a tool for capturing dmesg upon system crash (such as
> >
> > netconsole
> >
> > > > > on Linux).
> > > >
> > > > Your kernel isn't setup for driver development:
> > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-ha
> > > > ndbook/kerneldebug.html
> > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kern
> > > > elconfig.html
> > > >
> > > > Basically, your system is rebooting cause the kernel panics and
> > > > you're not setup for crash dumps, or anything that could help you
> > > > diagnose the panic.
> > > > --
> > > > Mel
> > >
> > > I've setup the dumpdev/dumpdir and I get a vmcore image
> >
> > upon a crash.
> >
> > > I don't really understand how to use kgdb in order to read
> >
> > it but more
> >
> > > than that - I don't need that much of data. I only want the dmesg
> > > report at the moment, see at what point my driver went
> >
> > crazy. Is it possible?
> >
> >
> > Uhm, no. Fundamental logic flaw: when a kernel is stopped,
> > you can't issue userland commands. All you have when you use
> > ddb, is the contents of the registers, ram and backtrace.
> >
> > You really want ddb in the kernel: when a kernel panics,
> > it'll drop to ddb and you can examine registers and do a
> > backtrace, instead of dumping core and rebooting. It should
> > point exactly to where your driver went crazy.
> > --
> > Mel
>
> I meant making the dmesg log sent over the network/serial console to a
> linux machine. I just found out about syslogd, I'm trying to figure out
> how to use it.
> DDB sounds like a great option for deeper debugging, I'll use it.

Ooh, sorry, totally got your question wrong.
Serial should really be the way to go. But it depends when you load your 
driver. If your driver panics the kernel before it gets to loading syslogd, 
there may not be much sent.
You could help this by not loading the network interface on bootup, but via 
cron instead, so that you're sure syslogd is up and running when you load the 
driver. Of course this assumes a working main network interface and that the 
driver isn't loaded automatically by /boot/loader.conf.
-- 
Mel