Messages in this thread | | | From | BROWN Nick <> | Subject | RE: Oops assist... | Date | Fri, 7 May 1999 09:40:00 +0200 |
| |
>[AV]In other words, goodbye non-standard bootloaders (e.g. LOADLIN).
>[SD]I'd suggest a submenu in the kernel config, allowing options like (off the >[SD]top of my head): >[SD] i) write oops data to console / serial / parallel >[SD] ii) broadcast oops data to network (UDP? raw ethernet frames?) >[SD] iii) write to (reserved?) hard disk area via BIOS >[SD] iv) write to IDE hard disk area >[SD] v) save to nvram >[SD] vi) store in RAM area conserved across reboot >[SD] vii) store in VGA card framebuffer conserved across reboot
The tradeoff here appears to be: - it's hard to do stuff reliably after an Oops has occurred, for obvious reasons - it's non-portable to define what should happen at reboot time
(i) should be to the serial port, I think. The console is about to be wiped clean by the BIOS at reboot time, and there could be anything on the parallel port.
(ii) should ideally be something which an SNMP-based network monitor could make sense of.
I think (iii) could be feasible if there were a specialised dump partition (the preferred dump location for VMS is a preassigned dump file, for example), which could perhaps be part of the swap partition, but needn't be - a lot of people don't have huge swap partitions anyway. Most people aren't interested in dumps, but for sites with big servers, a dedicated partition for dumps would be part of prudent OS installation planning.
--------------------------------------------------------------- |\ | o _ |/ Life's like a jigsaw | \| | |_ |\ You get the straight bits But there's something missing in the middle
Nick Brown, Strasbourg, France (Nick(dot)Brown(at)coe(dot)int) ---------------------------------------------------------------
__________________________________________________________
email address updates : @coe.int replaces @coe.fr for more information, http://dct.coe.int/info/emfci001.htm __________________________________________________________
- 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/
| |