From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Endless loop in cmd_log.c?
Date: Fri, 07 May 2010 10:18:55 +0200 [thread overview]
Message-ID: <m2zl0cazv4.fsf@ohwell.denx.de> (raw)
In-Reply-To: <1273188447.22784.23.camel@localhost.localdomain> (Peter Tyser's message of "Thu, 06 May 2010 18:27:27 -0500")
Hi Peter,
> On Wed, 2010-05-05 at 12:22 -0700, Dennis Ruffer wrote:
>> I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our ARM
>> systems and I seem to have run into an endless loop. With loglevel=5 so we
>> still see our console output, the printf at the end of logbuff_printk
>> appears to create an endless loop.
>>
>> I had to replace that line with serial_puts(msg);
>>
>> Have I missed some other solution or do the systems that use this never set
>> logbuffer higher than default_message_loglevel?
>
> I see the same issue you describe when enabling CONFIG_LOGBUFFER. It
> looks like only a few boards have CONFIG_LOGBUFFER enabled, and many of
> them also have CONFIG_SYS_CONSOLE_IS_IN_ENV defined. When
> CONFIG_SYS_CONSOLE_IS_IN_ENV is defined I believe the behavior is
> changed so that the the stdout/stderr/stdin values are read from the
> environment, with a default fallback of 'serial'.
>
> My guess is most of the boards with CONFIG_LOGBUFFER defined have their
> 'stdout' value set to 'serial', so they don't actually utilize the
> logbuffer, and thus don't run into the issue you found.
The log buffer was originally implemented to pass the results of the
POST tests to a Linux kernel so the user space application can access
the test results. In this combination the boards using it would usually
have stdout on serial (as you describe) and have POST log into the
logbuffer. The POST results were not considered to be important enough
to be printed on the serial console however - if needed, one can inspect
the logbuffer with "log show".
> In any case, I think its a bug and your suggested workaround sounds good
> to me. Have any interest in submitting a patch to fix it?
Yes, this sound like a bug, I agree.
Cheers
Detlev
--
Modern methods of production have given us the possibility of ease and
security for all; we have chosen, instead, to have overwork for some
and starvation for others.
-- Bertrand Russell
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
next prev parent reply other threads:[~2010-05-07 8:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 14:28 [U-Boot] [PATCH V2 0/3] Add support for MB86R0x SoCs Matthias Weisser
2010-05-05 14:28 ` [U-Boot] [PATCH V2 1/3] arm: " Matthias Weisser
2010-05-05 14:28 ` [U-Boot] [PATCH V2 2/3] video: add support for display controller in " Matthias Weisser
2010-05-05 14:28 ` [U-Boot] [PATCH V2 3/3] arm: Add support for jadecpu board based on MB86R01 SoC Matthias Weisser
2010-05-05 19:22 ` [U-Boot] Endless loop in cmd_log.c? Dennis Ruffer
2010-05-06 23:27 ` Peter Tyser
2010-05-07 0:04 ` Dennis Ruffer
2010-05-07 0:15 ` Peter Tyser
2010-05-07 8:18 ` Detlev Zundel [this message]
2010-05-05 21:34 ` Dennis Ruffer
2010-05-06 4:20 ` Dennis Ruffer
2010-05-06 16:03 ` Dennis Ruffer
2010-05-06 16:21 ` Peter Tyser
2010-05-06 17:51 ` Dennis Ruffer
2010-05-06 18:05 ` Peter Tyser
2010-06-12 9:36 ` [U-Boot] [PATCH V2 3/3] arm: Add support for jadecpu board based on MB86R01 SoC Anatolij Gustschin
2010-06-12 9:28 ` [U-Boot] [PATCH V2 2/3] video: add support for display controller in MB86R0x SoCs Anatolij Gustschin
2010-06-12 9:19 ` [U-Boot] [PATCH V2 1/3] arm: Add support for " Anatolij Gustschin
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=m2zl0cazv4.fsf@ohwell.denx.de \
--to=dzu@denx.de \
--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