Messages in this thread | | | Date | Sun, 09 May 1999 20:56:56 -0400 | From | Manfred Spraul <> | Subject | Re: New Partition Type |
| |
Hi Riley,
I think we should think about the subsystems which are required for writing the oops: currently the following subsystems are required: (I'm not sure that the list is complete or accurate) 1) syslogd (user mode program, i.e we need the scheduler) 2) the filesystem 3) the buffer cache 4) the device driver 5) the interrupt handler 6) bottom-half handling
OR, if you have a nasty bug, then you can use the serial console, and you only need a small device driver for the oops report. (But you need a second computer).
> 1. Write the oops to a dedicated oops partition.
I have a better idea: copy the code from the swap file implementation: at system startup, a special file is choosen ( cat "/root/report" > /proc/oopsfile somewhere in rc.sysinit), we set the file size to 64 kB, zero any previous contents, read the disk location with bmap(). If we have an oops, then we can bypass the filesystem for the report. During the next startup, rc.sysinit can check that the file is empty. This system has all advantages of a dedicated oops partition, but does not require disk layout changes.
This has the advantage that this would be portable.
> 2. use the swap partition. we must disable swapping before we can write to a swap partition. I think a special file is easier.
> 3. Perform a WARM reboot, which skips the memory test phase of the > POST on most systems. > This option requires that whatever loads the Linux kernel is the > first thing to be run by the bootup process.
It's not very portable, but this can catch oops report during the kernel startup, i.e. before 'init' is started.
------------ 1) I don't know enough about the typical side effects of an oops, so I don't know how many oops reports which are currently lost could be stored if we use a special file. I won't try to write a patch.
2) I currently think about writing an oops report to the parallel port: - you can write to the parallel port without interupts, without bottom-half handlers (at least on the Intel platform) - we can even try to implement a complete console on the parallel port. Obviously, output only ;=). - I think that many linux users have a printer, but few users have a second computer for the console log.
We don't need fancy graphics, so the printer driver should be very simple.
Regards, Manfred
- 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/
| |