[Bug 1192767] Kernel boot logging gets mixed up when bringing up CPUs on SMP system
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1192767 https://bugzilla.suse.com/show_bug.cgi?id=1192767#c9 --- Comment #9 from Petr Mladek <pmladek@suse.com> --- (In reply to Archie Cobbs from comment #4)
But to be clear there are two bugs here...
#1 Bogus promotion from INFO to WARN
This "bug" can be fixed by using pr_cont(KERN_INFO "...") instead of plain pr_cont("..."). This notation has been supported by commit 4bcc595ccd80decb424509 ("printk: reinstate KERN_CONT for printing continuation lines") since kernel 4.9. But I do not see it used anywhere: $> git grep pr_cont\( | wc -l 1977 $> git grep pr_cont\(KERN_ | wc -l 0 Why? My guess is that it is because: + pr_cont() mostly works + it would be an extra work to keep loglevel of all the related pr_cont() pieces in sync + nobody cared enough to fix location where it did not work + many people do not know about the notation We might make it easier to use it by introducing pr_cont_<level>() wrappers. But will people use them? I do not know. There were some ideas to support continuous lines another way. For example, create an API that would use some local buffer on stack and explicitely flush it when the string is complete. But nobody cared enough to implement it. Also it would be more complicated to use and error prone. And any local buffering might cause that the message will never reach the main log buffer when something gets wrong. From my point of view. It is an aesthetic issue that it not worth fixing. The fix might do more harm than good.
#2 Broken formatting if there are any per-CPU log messages
One possibility would be to print each CPU on a separate line. But it would look ugly on systems with many CPUs. Also it would create problems with slow consoles (softlockups, lost messages). Another possibility would be to use a local buffer and print the line when it is complete. But it would make it harder to debug when something went wrong in the middle. Interleaving with other messages helps to find correlation with between various events/problems on the system. It is even the case here. The interleaving helps to understand that "Disabled fast string operations" is printed for each initialized CPU.
Both bugs should be fixed.
Any solution has its drawbacks. IMHO, the current code is a good compromise as long as the list of CPU IDs is interleaved only rarely. That said. It would be easy to make the loglevel consistent here. But there will be another 2000 pr_cont() calls that might cause the same problem. And there is no simple generic solution. -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply@suse.com