[dm-devel] Serial console is causing system lock-up

[Petr Mladek]

On Tue 2019-03-12 14:19:56, John Ogness wrote:
> On 2019-03-12, Mikulas Patocka <mpatocka at redhat.com> wrote:
> >>> But it doesn't turn SMP system into UP.
> >> 
> >> In this example it turned it into a brick.
> >> 
> >> The problems I see are:
> >> 
> >> 1. The current loglevels used in the kernel are not sufficient to
> >>    distinguish between emergency and informational messages. Addressing
> >>    this issue may require things like using a new printk flag and
> >>    manually marking the printks that we(?) decide are critical. I was
> 
> Perhaps it would be nice if an administrator could additionally "mark"
> what _they_ consider critical, i.e. they are aware of and accept the
> consequences of a synchronous printk for certain messages. When I look
> at things like dynamic_printk and ftrace, I see mechanisms that provide
> excellent runtime tuning without much complexity.
> 
> We could extend dynamic_printk to include all printk messages and also
> support the emergency classification. We could have something like
> ftrace-events, where certain _events_ (i.e a group of printk messages)
> could be classified as an emergency (for example, a WARN_ON event, a
> watchdog event, a general stacktrace event, etc.).
> 
> These are just ideas that I'm bouncing around my brain. But as you said,
> only the administrator can know what is important. So perhaps we need to
> provide the administrator an interface to specify that.

Interesting idea. But I am very sceptical about it. I can't imagine
that anyone would like to configure 100k messages or so.

It is even worse than kernel configuration. And the trend is
to avoid config options where possible. It is because it is
almost impossible to understand all existing options and
make qualified decisions. And it is hard to expect that
users would be able to make a better decision than a developer
who implemented the code behind the option.

Our discussion is a nice example. Even we have troubles to
understand all consequences of different approaches. Even
if we reach a conclusion and document it. Then nobody
would want to read several pages long tutorial how to
configure printk ;-)

Best Regards,
Petr