On 11/10/21 4:03 AM, Petr Mladek wrote:
On Tue 2021-11-09 10:15:12, Guenter Roeck wrote:
On 11/9/21 7:53 AM, Petr Mladek wrote:
The commit 48021f98130880dd74 ("printk: handle blank console arguments
passed in.") prevented crash caused by empty console= parameter value.
Unfortunately, this value is widely used on Chromebooks to disable
the console output. The above commit caused performance regression
because the messages were pushed on slow console even though nobody
was watching it.
We actually had to revert this patch on Chromebooks, so we'll have to revert
it again from stable releases after it gets there.
What patch was or need to get reverted on Chromebooks, please?
1. commit 48021f98130880dd74 ("printk: handle blank console
arguments passed in.")
or
2. commit commit 3cffa06aeef7ece30f6b5ac0e ("printk/console: Allow
to disable console output by using console="" or console=null")
Both.
I know that the 1st patch caused problems on Chromebook. The 2nd one
was supposed to fix the problem.
The 2nd patch is being backported here? Do you still see the problems
with it, please?
Yes.
The problem is two-fold:
First, it is used in Chromebooks to disable the default console in production
images; that default console may be set in a devicetree file, and this patch
doesn't really disable it. In other words, Chromebooks use "console=" to
implement "mute_console" as suggested below, and this patch does not address
that use case.
I guess that you are talking about the 1st patch.
The 2nd patch should make it working basically the same way as when reverting
the 1st patch. The difference is that it prefers the fake ttynull
console driver instead of none. It should be better because it will
provide a kind of null console for stdin/stdou/stderr of the init
process. But it still should result into a none-driver when ttynull
driver is not available.
Yes, that was what we initially assumed as well - only, as the patch
states, it doesn't work as needed for Chromebooks if another console
is registered by other means.
Or do you use another extra patch for Chromebooks, please?
Not that I know of. We just rely on the old behavior.
Second, the patch causes some unexplained problems with dm-verity, which
inexplicably fails on some Chromebooks when the patch is in place.
We never tracked down the root cause because the patch doesn't work
for us anyway.
Interesting. I wonder what console was really registered when it complained.
It was with a Chromebook using devicetree, where the console is primarily
passed via devicetree and not as boot parameter. I don't recall the exact
model(s).
Guenter
