Index of ./pub/linux-patches/kmsgdump/0.4.1
Contents of README
19991024
Changes for KMSGDUMP 0.4.1
Henrique M. Holschuh helped me to understand why
kmsgdump couldn't compile on some gcc/gas combinations. He did a lot of
compilations for that. Thanks to him.
Neil reported me several conditions under which
kmsgdump crashed and/or reported empty messages because do_syslog caused the
crash which kmsgdump could catch and work around thanks to the checkpoints.
Now this is fixed and a new syslog function has been implemented.
Neil also sent me a patch for 2.3.22. Since I've changed several things in
the last release, it was simpler for me to upgrade from 2.2.13, but his
patch at least confirmed me that I was not wrong in my porting because it
semt like his. Thanks go to Neil too.
I modified a bit the checkpointing method. Now, there are retry points and
check points. Check points are more numerous than retry points. My goal is
to show, as soon as possible, a list of all check points where a crash has
been detected. This would have helped me even more with the bug related to
do_syslog.
Other plans are :
- copy the code into low-space memory at boot time, when the kernel is
still under good conditions.
- don't copy the log messages anymore, but just a pointer to them. The
real mode code will fetch them through a flat real mode switch.
- truncate the file on the diskette to eliminate the trailing zeroes.
- change the colors so that they won't remember you Windows anymore.
I'd prefer to say they are Solaris colors, because Windows doesn't use
cyan ;-)
19990923 : The compilation error due to old versions of "as" has been
temporarily worked around in these new patches.
Changes for KMSGDUMP 0.4.0
Features include :
- recover from kernel panic (when possible, of course)
- automated mode or interactive user-friendly interface
- ability to print on a parallel printer instead of writing on a diskette
- choose RAW or FAT format
People reported some problems and asked for new features which are now
implemented among with others :
- code checkpointing : if the kernel is really under weird conditions, it
is possible that even my code generates kernel panics, and the kernel
enters in a loop between panic and kmsgdump... this has been reported
only once, but once is greater than never. Now, every portion of code
is checkpointed and will not be executed if called again. This way, the
number of loops is limited and the rebooting process progresses till the
reset of the CPU itself, so even if it's very hard to reach it, there are
many more chances that at least the system reboots hardly.
- the diskette used to dump can be checked to see if it can be used for that
or not, thus preventing from dumps on unwanted diskettes.
- when a diskette is formated as FAT, a little code is inserted on the boot
sector to make it redirect the boot to the first bios hard disk. This way,
if the bios boot sequence can't be setup to force a boot from hard disk
first, the diskette will redirect it.
- every parameter can be configured via /proc/sys/kernel/kmsgdump.
- the documentation (Documentation/kmsgdump.txt) has been updated.
- the size of the messages buffer can be configured at compile time. Someone
told me he needed to set his buffer size to 32 kB. This is now possible.
- the diskette is now really formated to 1.44 MB and is more compatible with
DOS/Windows/mtools.
- thanks to the new generic disk formating code it's now easy to use other
formats by simply changing the number of sectors and tracks in the include
file. (some people still have 5.25 floppies in drive B which can be used
for this feature).
You can download the doc and a patch for 2.2.12 or alan's 2.2.13pre10 from :
http://www-miaif.lip6.fr/willy/pub/linux-patches/kmsgdump/
I prefer not to include it in this mail, but I can eventually mail it to
people who can't get it.
Within a few days, I hope I'll release the development version for 2.3.18,
but my 2.3 kernel tree is too old an I need to download some patches ...
Perhaps one of the two patches applies well to 2.3 ?
Have fun with this, and please send me your comments or share them with LKML
(linux-kernel@vger.rutgers.edu).
Willy