Messages in this thread |  | | Date | Sat, 23 Sep 2000 13:02:38 +0000 | From | Thorsten Kranzkowski <> | Subject | Re: [DOC] Debugging early kernel hangs |
| |
On Sat, Sep 23, 2000 at 09:57:38PM +1100, Keith Owens wrote: > On Sat, 23 Sep 2000 12:42:13 +0200, > Benjamin Herrenschmidt <bh40@calva.net> wrote: > >However, there's still a huge gap between the last progress() message and > >availability of the frame buffer device. The simple console has the > >advantage of outputing existing printk messages. (basically, it's a > >console using prom_printf). > > Something I forgot to mention about debugging using screen writes. If > the problem is caused by incorrect compiler output then even printk can > fail. Not because the C code is wrong but because the generated > assembler is wrong. Writing direct to screen memory is as simple as it > gets and gives the compiler little or no chance to get it wrong.
How about the possibility to use architecture specific backends? E.g. my little Alpha machine has an 8-bit debugging LED port that would be very suited for this. Or you could use a parallel port in a similar manner (for those vga-less server machines...). Other machines may have a LED system display for displaying HEX-digits.
So when you use an 8-bit value and display it as 2 hex-digits (ok that would be 2 assembler insns instead of one..) this kind of devices could be supported equally well.
my 0.02 EUR Thorsten
-- | Thorsten Kranzkowski Internet: dl8bcu@gmx.net | | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] | - 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/
|  |