LKML Archive on
help / color / mirror / Atom feed
From: John Ogness <>
To: Julien Grall <>
Cc: Sebastian Andrzej Siewior <>,
	Thomas Gleixner <>,
	LKML <>,
	linux-rt-users <>,
	Steven Rostedt <>,
	Dave P Martin <>
Subject: Re: [ANNOUNCE] v5.0.3-rt1
Date: Mon, 25 Mar 2019 09:13:08 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Julien Grall's message of "Fri, 22 Mar 2019 18:52:48 +0000")

On 2019-03-22, Julien Grall <> wrote:
> Apologies for a possible stupid question.

It's an important question because the behavior of console printing has
changed. (Or, rather, is in the process of being changed. Depending on
complaints/approval, it may change some more.)

> On 20/03/2019 17:15, Sebastian Andrzej Siewior wrote:
>>    - Applied John Ogness' prinkt rework. One visible change is the
>>      output during boot. Under the hood and for RT: By default, output
>>      that is created at KERN_WARN[0] or higher is printed immediately if the
>>      console supports "atomic" print (currently the 8250 driver does).
>>      This output is printed immediately (and visible) even from IRQ-off
>>      or preempt-disabled regions which wasn't the case earlier. This will
>>      raise the latency at run-time *but* there should be no WARNING,
>>      ERROR or PANIC messages at run-time on a fully working system.
>>      Messages with lower severity are printed "later" by a kthread.
> Using 5.0.3-rt1, I get some warning message completely mangled with
> the rest of the output (e.g systemd message) but also between
> them. Some excerpt of a 500 lines lockdep warning (AFAICT the printk
> is not related to the printk code):
> [   52.294547] 005: ... which became HARDIRQ-irq-unsafe at:
> [   52.294553] 005: ...
> [   52.294554] 005:   lock_acquire+0xf8/0x318
> [  OK  ] Reached target
> t_spin_lock+0x48/0x70  lock_acquire+0xf8/0x318
> [0;1;39mRemote File Systems.[   52.294570] 005:   iommu_dma_map_msi_msg+0x5c/0x1
> [   52.296824] 005: CPU: 5 PID: 2108 Comm: ip Not tainted 5.0.3-rt1-00007-g42ede
> 9a0fed6 #4312] 005:  __sys_sendmsg+0x68/0xb8
> I understand the new series add support for "atomic" print. So I am
> wondering whether this issue is related to it? Is there any advice to
> prevent the mangling?

The atomic print allows important messages to be print immediately
(regardless of the context of the printer). This means that if any other
context was already printing, it will be interrupted. This cannot be
synchronized without causing significant scheduling delays.

The atomic messages always do the interrupting and will continue to the
end of the line. So it should be possible to piece the non-atomic
messages back together. However, I am a bit confused by your output. Is
it possible that I could see the full boot log?

The main goal of the atomic messages is so that you never lose any
important messages. To help readability, perhaps the atomic messages
should begin with a '\n' as well?

John Ogness

  reply	other threads:[~2019-03-25  8:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20 17:15 Sebastian Andrzej Siewior
2019-03-22 18:52 ` Julien Grall
2019-03-25  8:13   ` John Ogness [this message]
2019-03-25 10:18     ` Julien Grall
2019-03-25 10:34       ` John Ogness
2019-03-26 10:26         ` Julien Grall
2019-03-26 16:04           ` John Ogness
2019-03-27 18:33 ` [PATCH 1/4] printk: An all-in-one commit to fix build failures Sebastian Andrzej Siewior
2019-03-27 18:33   ` [PATCH 2/4] powerpc/stackprotector: work around stack-guard init from atomic Sebastian Andrzej Siewior
2019-05-10 21:46     ` Steven Rostedt
2019-03-27 18:33   ` [PATCH 3/4] powerpc/pseries/iommu: Use a locallock instead local_irq_save() Sebastian Andrzej Siewior
2019-03-27 18:33   ` [PATCH 4/4] powerpc: reshuffle TIF bits Sebastian Andrzej Siewior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [ANNOUNCE] v5.0.3-rt1' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).