> 2. When dealing with an oops, use direct disk reads/writes with
> no interrupts or the like. At this point, performance becomes
> irrelevant, BUT we must ensure that any previous logged data
> that hasn't yet been written to disk gets written out as well.
I don't think that you'll be able to do that:
You might be able to write such a driver for plain IDE,
but you'll fail for SCSI: the sym53c8xx driver: 300 kB,
the contoller has it's own assembly language and must
be programmed; the aic7xxx.c: > 370 kB, and I'm sure
you'll have similar problems.
And as IDE (ATAPI) advances, you'll run into similar problems
for IDE. I've heard that a new ATAPI standard support 2 outstanding
commands (one to the master, on to the slave) at the same time.
You could try to (after the system detected an oops/panic):
- move some 16 bit code into the memory < 1 MB.
- move kernel ring buffer of the system log to < 1 MB.
- force a switch to real mode.
- write the report with the BIOS disk interface.
IMHO, you should use a system similar to LILO:
a sector map is created in advance , and then you don't need to
create a new partition.
Very few Linux users expect a hard crash when they
-> they won't think about a special partition.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com Please read the FAQ at http://www.tux.org/lkml/