> If a kernel hangs early in the boot process (before the console has
> been initialized) then printk is no use because you never see the
> output. There is a technique for using the video display to indicate
> boot progress so you can localize the problem. Reporting "my kernel
> hangs during
Hi!
> > >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
On Mon, 25 Sep 2000, Russell King wrote:
> James Sutherland writes:
> > On Sat, 23 Sep 2000, Russell King wrote:
> > > And I'll try to make the point a second time that everything does not have
> > > a character-based screen to write to.
> >
> > So what? For platforms which have a nice easy way
James Sutherland writes:
> On Sat, 23 Sep 2000, Russell King wrote:
> > And I'll try to make the point a second time that everything does not have
> > a character-based screen to write to.
>
> So what? For platforms which have a nice easy way to stick ASCII on
> screen, use this. For other
James Sutherland writes:
On Sat, 23 Sep 2000, Russell King wrote:
And I'll try to make the point a second time that everything does not have
a character-based screen to write to.
So what? For platforms which have a nice easy way to stick ASCII on
screen, use this. For other platforms,
On Mon, 25 Sep 2000, Russell King wrote:
James Sutherland writes:
On Sat, 23 Sep 2000, Russell King wrote:
And I'll try to make the point a second time that everything does not have
a character-based screen to write to.
So what? For platforms which have a nice easy way to stick
Hi!
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
On Sat, 23 Sep 2000, Russell King wrote:
> Keith Owens writes:
> > 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
On Sat, 23 Sep 2000, Russell King wrote:
Keith Owens writes:
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
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
On Sat, Sep 23, 2000 at 09:57:38PM +1100, Keith Owens wrote:
> On Sat, 23 Sep 2000 12:42:13 +0200,
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> >However, there's still a huge gap between the last progress() message and
> >availability of the frame buffer device. The simple console has
On Sat, 23 Sep 2000 13:02:38 +,
Thorsten Kranzkowski <[EMAIL PROTECTED]> wrote:
>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.
You can define VIDEO_CHAR() to do whatever
Keith Owens writes:
> 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
On Sat, 23 Sep 2000 12:42:13 +0200,
Benjamin Herrenschmidt <[EMAIL PROTECTED]> 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
>2.4 and 2.2 PPC have progress() for writing progress messages to the
>screen. They're setup in a per-board very early in the boot so we can see
>what's going on as soon as the MMU is turned on and lets us get around.
>
>Ben, can you just make your changes talk through that? I used to use it
2.4 and 2.2 PPC have progress() for writing progress messages to the
screen. They're setup in a per-board very early in the boot so we can see
what's going on as soon as the MMU is turned on and lets us get around.
Ben, can you just make your changes talk through that? I used to use it
with
On Sat, 23 Sep 2000 12:42:13 +0200,
Benjamin Herrenschmidt [EMAIL PROTECTED] 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
Keith Owens writes:
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
On Sat, 23 Sep 2000 13:02:38 +,
Thorsten Kranzkowski [EMAIL PROTECTED] wrote:
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.
You can define VIDEO_CHAR() to do whatever makes
On Sat, Sep 23, 2000 at 09:57:38PM +1100, Keith Owens wrote:
On Sat, 23 Sep 2000 12:42:13 +0200,
Benjamin Herrenschmidt [EMAIL PROTECTED] 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
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
>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
On Fri, 22 Sep 2000, Keith Owens wrote:
> On Thu, 21 Sep 2000 18:54:33 -0400 (EDT),
> Byron Stanoszek <[EMAIL PROTECTED]> wrote:
> >On Fri, 22 Sep 2000, Keith Owens wrote:
> >> The idea is to write characters direct to the video screen during
> >> booting using a macro called VIDEO_CHAR.
> >
>
Keith Owens writes:
> If a kernel hangs early in the boot process (before the console has
> been initialized) then printk is no use because you never see the
> output. There is a technique for using the video display to indicate
> boot progress so you can localize the problem. Reporting "my
Keith Owens writes:
If a kernel hangs early in the boot process (before the console has
been initialized) then printk is no use because you never see the
output. There is a technique for using the video display to indicate
boot progress so you can localize the problem. Reporting "my kernel
On Fri, 22 Sep 2000, Keith Owens wrote:
On Thu, 21 Sep 2000 18:54:33 -0400 (EDT),
Byron Stanoszek [EMAIL PROTECTED] wrote:
On Fri, 22 Sep 2000, Keith Owens wrote:
The idea is to write characters direct to the video screen during
booting using a macro called VIDEO_CHAR.
Why not just
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
On Thu, 21 Sep 2000 18:54:33 -0400 (EDT),
Byron Stanoszek <[EMAIL PROTECTED]> wrote:
>On Fri, 22 Sep 2000, Keith Owens wrote:
>> The idea is to write characters direct to the video screen during
>> booting using a macro called VIDEO_CHAR.
>
>Why not just redirect printk() to output a string of
On Fri, 22 Sep 2000, Keith Owens wrote:
> If a kernel hangs early in the boot process (before the console has
> been initialized) then printk is no use because you never see the
> output. There is a technique for using the video display to indicate
> boot progress so you can localize the
If a kernel hangs early in the boot process (before the console has
been initialized) then printk is no use because you never see the
output. There is a technique for using the video display to indicate
boot progress so you can localize the problem. Reporting "my kernel
hangs during boot at
If a kernel hangs early in the boot process (before the console has
been initialized) then printk is no use because you never see the
output. There is a technique for using the video display to indicate
boot progress so you can localize the problem. Reporting "my kernel
hangs during boot at
On Fri, 22 Sep 2000, Keith Owens wrote:
If a kernel hangs early in the boot process (before the console has
been initialized) then printk is no use because you never see the
output. There is a technique for using the video display to indicate
boot progress so you can localize the problem.
On Thu, 21 Sep 2000 18:54:33 -0400 (EDT),
Byron Stanoszek [EMAIL PROTECTED] wrote:
On Fri, 22 Sep 2000, Keith Owens wrote:
The idea is to write characters direct to the video screen during
booting using a macro called VIDEO_CHAR.
Why not just redirect printk() to output a string of characters
33 matches
Mail list logo
