https://bugzilla.suse.com/show_bug.cgi?id=1192767 https://bugzilla.suse.com/show_bug.cgi?id=1192767#c5 --- Comment #5 from Borislav Petkov <bpetkov@suse.com> --- (In reply to Archie Cobbs from comment #4)

#1 Bogus promotion from INFO to WARN

That is probably a bug...

#2 Broken formatting if there are any per-CPU log messages

... but I can't call this a bug frankly.

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.

Pretty much.

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.

The reason it was done this way is to save dmesg space. Imagine you had 9K CPUs. Because there are boxes like that. That's 9K lines of dmesg log ring buffer wasted. Or on a slow serial line. 9K seconds only for the cores if it takes a second to issue a line.

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...

I don't care if the logging is interleaved by some message during a logical thread's initialization. dmesg message format is not an ABI but a best-effort thing, roughly speaking. #1 I understand - you're not the only one who's looking at warning-level messages - people do care about them. But our booting is already very fragile so fixing stuff only for the formatting's sake is not worth the effort and complexity. HTH. -- You are receiving this mail because: You are the assignee for the bug.