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