Re: Serial console is causing system lock-up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue 2019-03-12 14:19:56, John Ogness wrote:
> On 2019-03-12, Mikulas Patocka <mpatocka@xxxxxxxxxx> 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



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux