From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Tyser Date: Thu, 06 May 2010 18:27:27 -0500 Subject: [U-Boot] Endless loop in cmd_log.c? In-Reply-To: <012501caec88$40387670$c0a96350$@com> References: <1273069733-6194-1-git-send-email-weisserm@arcor.de> <1273069733-6194-2-git-send-email-weisserm@arcor.de> <1273069733-6194-3-git-send-email-weisserm@arcor.de> <1273069733-6194-4-git-send-email-weisserm@arcor.de> <012501caec88$40387670$c0a96350$@com> Message-ID: <1273188447.22784.23.camel@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Dennis, 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. 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? Best, Peter