I think that kmsgdump is a good place to start, but I do not think it does
enough. For example (and this is just off the top of my head) being able
to dump some of the kernel structures to disk, such as the run queue. The
monitor would need to know where these structures are in memory and a
little about their layout. But since we could find this out from the
kernel headers at compile time it would be possible to know how to snoop
this.
I think I will take a closer look at kmsgdump and see if I can get may
arms around what I am thinking about.
On Fri, 30 Jun 2000, Andreas Dilger wrote:
> Zone writes:
> > I still like a monitor program that is loaded into memory at kernel load
> > time that is given control in the event of a panic. If it knew how to
> > handle a text console, the keyboard and the floppy in a manner completely
> > independent of the kernel it could be used to help debug a crash by
> > producing a mini-dump to the floppy device.
>
> Such a thing already exists - it's called kmsgdump, and it dumps the
> current printk buffer to a floppy/serial/printer. It has its own
> (assembly) console handling code, and it gets called when the kernel
> panics, or through SysRQ. I've used it several times for debugging
> OOPSes when developing on my laptop, which doesn't have a serial port.
>
> Cheers, Andreas
> --
> Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
> \ would they cancel out, leaving him still hungry?"
> http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:09 EST