lkml.org 
[lkml]   [1997]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel Debugging Hardware
On Mon, 12 May 1997, Harald Koenig wrote:

-> - how many write cycles are possible for eeproms these days ? I remeber of some 10k cycles ?!
-> if this is still a limitation there would be no chance to log data online until
-> the system will crash (ok, it would be enough to record the oops once it happend
-> but that's usually not my subject)
->
-> what about using a 8k SRAM or similar ? using e.g. Tx etc. for power supply...
-> loosing data after power off is usually no big problem
I think an SRAM would be a better solution because of the longer lifetime.

-> - what about using a parallel port as interface ? while I already have
-> 8 serial ports they are usually all bussy (and standard COM1/COM2 are
-> locked for mouse & modem...). pretty often printer ports are free.
-> being able to use both ser/par port would be great (more possible users...)

A parallel port would be easier than a serial one because all you would need
is a counter and a bit of TTL logic. The parallel port has its own 5 volt
supply pin, it has several signal pins which can be (ab)used for read and
write signals. A bidirectional parallel port would of course be the easiest to
design for, but a unidirectional one is also possible at half the read speed
(which you only need after a crash so this speed does not matter much anyway).
I'll see if I can set up a small design for a bidirectional parallel port
sometime next week and then breadboard the thing together. I have some 32K
100ns SRAMs I gave up on ever using again, so this may be their break.

-> - I'd register only binary/compressed data which can be interpreted later
-> with some special tool. that way we can register more data (depends on
-> if you want to log all kernel msgs or just want to save some state of crash information)

Absolutely. This memory will be a scarce resource. You could write fixed
length blocks with a timestamp, the block with the earliest timestamp would be
the oldest one by definition and you would not have to worry about where you
started or finished.

I think there should be a small modification to (or an alterego of) the
parallel port driver that can simply write, read and reset the addresscounter
to 0. You may want to do something fancy and also be able to directly write an
address, but I think this feature should be optional or absent unless it's
absolutely needed as it makes the circuitry more complex. Maybe it should
also have a go at detecting the amount of memory installed. If you use a 16
bit counter you can have up to 64K for example and if you use an 8K RAM the
addresses will simply fold after 8K, 16K etc. You could write in a pattern of
256 bytes and see where you find that same pattern again. We would probably
not even have to specify the counter size so someone could build a board with
a 32 bit counter and install 4Gb SRAM as a log buffer ;-)

The actual writing/reading could best be done from userspace, for example
through the syslogd or klogd or a deamon that communicates with it. This would
also simplify things if somebody comes up with a serial and/or different
parallel version or even something completely different that's beyond our
imagination today.

-> anyway, I've always wondered if it wouldn't be possible (at least for many panics)
-> to write a complete system crash dump to a swap partition (assuming swap > real_mem)
-> which would be a big help for some problems too.
SCO does this. Its not very useful mostly because you can't debug a SCO
kernel. On linux this might be a different matter however. You could only
debug from this if ( freeswap >= real_mem ) at the time of the crash.
Even if you have this dump a record of your last 8K or so log would often be
useful.

--------------------------------------
Hugo Van den Berg - hbe@cypres.nl
Phone - +31 (0)30 - 60 25 400
Fax - +31 (0)30 - 60 50 799
--------------------------------------


\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2011 Jasper Spaans