lkml.org 
[lkml]   [1999]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New Partition Type
Hi Manfred.

> 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

For it to be useful, we would need to omit 2, 3, 5 and 6 from that
list on an oops, as they can't be guaranteed to be safe to use. We
would therefore be writing direct to the raw disk.

The way I see this working would be to use a partition occupying
exactly one cylinder of the primary hard drive, with this partition
being treated as a circular buffer for syslog. The first sector of
this cylinder would contain details of where the beginning and end of
the currently logged text was in the said buffer, and the rest of the
cylinder would contain the text.

Let's put that into context: Both my 6G and 8G drives declare their
CHS as 255 heads, 63 sectors per track, and that maps to near enough 8
megs per cylinder. That should be plenty for a dedicated log
partition.

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

It also has the problem that the file (a) may be fragmented, and (b)
may not be all on one logical cylinder, both of which complicate the
code considerably.

> This has the advantage that this would be portable.

Not necessarily - it will probably require dedicated code for the
relevant type of disk, EIDE or SCSI or whatever future types develop.

>> 2. use the swap partition.

> we must disable swapping before we can write to a swap partition.

If we have an OOPS that's serious enough that we're worried about
kernel corruption, then the swap partition MUST be assumed to be
disabled as the very act of swapping is dangerous...

> I think a special file is easier.

Not from a code point of view - the easiest way is if we can guarantee
that an entire logical cylinder is ours to play with...

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

Precicely...

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

Basically, the result of an OOPS can be anything from "program
aborted" to "kernel overwritten with garbage". However, there are
certain sanity checks we can do to determine a rough level of
severity, and react accordingly.

We have to make certain assumptions initially though, and these have
to be "worst case" assumptions that still leave us in a position to
actually do something. If we initially assume that the entire kernel
has been overwritten, then there's nothing we can do as none of our
code is around to do anything anyway...

> 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 ;=).

Both fair enough...

> - I think that many linux users have a printer, but few users
> have a second computer for the console log.

If all we're logging are oops, then that's fair enough, but I'd hate
to try sending the entire syslog to a printer - I for one couldnae
afford the paper...

> We don't need fancy graphics, so the printer driver should be very
> simple.

True...

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html




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

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.150 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site