lkml.org 
[lkml]   [2000]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.066 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site