public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Peter Tyser <ptyser@xes-inc.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] logbuff: Prevent an infinite loop for console output
Date: Fri, 07 May 2010 12:34:28 -0500	[thread overview]
Message-ID: <1273253668.22784.57.camel@localhost.localdomain> (raw)
In-Reply-To: <m2vdb0azmr.fsf@ohwell.denx.de>

On Fri, 2010-05-07 at 10:23 +0200, Detlev Zundel wrote:
> Hi Peter,
> 
> > When using 'logbuff' as stdout and the console loglevel is greater
> > than a message's loglevel it is supposed to be both logged, and printed
> > to the console.  The logbuff_printk() function is responsible for both
> > logging and displaying the message.  However, logbuff_printk()
> > previously used printf() to print the message to the console.  The
> > printf() call would eventually end up back in logbuff_printk(), and
> > an infinite loop would occur which would hang a board.
> >
> > Using serial_puts() instead of printf() in logbuff_printk() avoids the
> > recursion and resolves the issue.
> >
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > Reported-by: Dennis Ruffer <daruffer@gmail.com>
> 
> Hm.  What if a board has "stdout" set to "lcd" or "nc" or any other
> device?  Do we really want the text to be output on the serial console
> then?  Doesn't this break the whole "stdout" concept?

Yes, it does break the stdout concept, but I went with the current patch
for 3 reasons:
1. Most anything is better than the current board lockup that occurs
without the change.

2. For most of the boot process serial_puts() is used to output messages
(ie prior to GD_FLG_DEVINIT is set in gd->flags).  Continuing to use the
same output method after GD_FLG_DEVINIT is set makes some degree of
sense.

3. A proper fix would be more involved.  For example, perhaps allowing
the stdout variable to support multiple devices (eg
"stdout=logbuff,lcd") would be a more elegant solution.  In any case, to
use both the logbuff and non-serial port for output would require much
more extensive changes than this 1-line change.  I don't use the
logbuff, so am not so interested in spending the time to fix it.  The
fact that no one else ran into this bug implies no on else is using it
either.

I agree this fix isn't the best, but its better than the bug in my
opinion.  Ideally someone who uses the logbuff could provide a more
elegant fix.  Any takers?

Best,
Peter

  reply	other threads:[~2010-05-07 17:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-07  0:32 [U-Boot] [PATCH] logbuff: Prevent an infinite loop for console output Peter Tyser
2010-05-07  8:23 ` Detlev Zundel
2010-05-07 17:34   ` Peter Tyser [this message]
2010-06-08 21:47     ` Wolfgang Denk
2010-06-08 21:58       ` Peter Tyser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1273253668.22784.57.camel@localhost.localdomain \
    --to=ptyser@xes-inc.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox