Comment # 4 on bug 1192767 from Archie Cobbs

> The purpose of the "meaningless log messages" is to show the CPU configuration of the machine.

Understood - apologies for calling them meaningless.

But to be clear there are two bugs here...

#1 Bogus promotion from INFO to WARN
#2 Broken formatting if there are any per-CPU log messages

Both bugs should be fixed. For #2 I can see where the problem comes from...
when you have 127 CPU's and there are no warnings emitted, it's nicer to have
them listed all on one or two lines. But of course, you don't want to stop any
per-CPU log messages from being emitted, so if they are emitted, they get
emitted "in the middle" of the single, in-progress log line for that node.

Given the simplistic way kernel logging works, to give proper formatting when
there is a possibility of any CPU startup emitting a warning AND have each CPU
listed in "real time", you would be forced to log each CPU on its own line. For
example, that might look like this (if only CPU#3 had a problem):

    x86: Booting SMP configuration:
    .... node  #0 CPU  #1
    .... node  #0 CPU  #2
    .... node  #0 CPU  #3
    core: CPUID marked event: 'cpu cycles' unavailable
    .... node  #0 CPU  #4
    smp: Brought up 1 node, 4 CPUs

Alternatively, if you don't care about "real time" logging (would probably be a
bad idea to give this up) then you could wait until all CPU's are done to log
the results...

    x86: Booting SMP configuration:
    .... node  #0 CPU  #3: core: CPUID marked event: 'cpu cycles' unavailable
    smp: Brought up 1 node, 4 CPUs

This would require some new trickery with the logging infrastructure to allow
configuring an thread-local "log prefix" (in this case, the ".... node  #0 CPU 
#3: " part).

Right now the code is trying to have it both ways and it's not working...