Benjamin Herrenschmidt wrote:
>
> >Hmm, good idea, but how does this work on, say, non-x86 architectures
> >which don't have a VGA text frame buffer, or whose VGA text frame buffer
> >is not mapped in, or whose VGA text frame buffer is not initialised.
> >
> >You will still end up with those "my kernel hangs during boot" messages.
> >
> >A lot of the problems with debugging early kernel hangs is that you
> >don't have a display set up, or you don't have enough of the memory
> >subsystem initialised (eg, before pci_init) to be able to access
> >devices (eg, before paging_init).
>
> [.../...]
>
> I've implemented a similar mecanism on the PPC 2.2.x kernel. It's not in
> the main tree since it requires a couple of lines of change to printk.c
> in order to handle correctly the removal of the last console.
>
> Basically, I setup a "struct console" during very-early boot (almost at
> the firmware level) that can basically display text on screen (using the
> firmware pre-inited fb) using a very basic engine, and is setup by
> default as the printk console.
>
> Then, in the main VT code, I unregister this boot console just before
> registering the VT one.
>
> It's a bit hackish and so is not meant to be merged in the main tree, but
> it's useful when I release test kernels for new Apple hardware, to have
> printk work from the very beginning of boot.
I don't see what is hackish about it. It is right to vector the console
output and update the vector as you boot. When you shut down you do the
same in reverse order, and that way you catch problems that otherwise
would go completely unnoticed.
Similarly, the panic function should be vectored. On entry to panic,
set the panic vector to a simpler panic function and that way a
recursive panic will not turn into an uninformative hang. And likewise,
the notifier call chain for panic should be processed one call at a time
with the call chain pointer updated in a static variable so that if/when
there is a panic inside the notify chain the panic handler still makes
forward progress.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:29 EST