https://bugzilla.suse.com/show_bug.cgi?id=1192767 https://bugzilla.suse.com/show_bug.cgi?id=1192767#c4 --- Comment #4 from Archie Cobbs <archie.cobbs@gmail.com> ---
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... -- You are receiving this mail because: You are the assignee for the bug.