Messages in this thread | | | From | Benjamin Herrenschmidt <> | Subject | Re: [DOC] Debugging early kernel hangs | Date | Fri, 22 Sep 2000 19:37:32 +0200 |
| |
>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 wanted to clean it up, but I didn't figure out a way to make this work without hacking slighlty printk.c and vt.c (mostly for correctly handling the takeover of the boot console by the VT subsystem). It could have been simpler if I implemented a struct consw instead of the (simpler) struct console, but the resulting code would have been way too bloated (mostly re-implementing an fb-based console ;)
Ben. - 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/
| |