Capturing dmesg upon system crash on 6.3

[Yehonatan Yossef]

> > > > > > 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
> 

Thanks Mel, DDB is a great help.