From: David Woodhouse <dwmw2@infradead.org>
To: David Howells <dhowells@redhat.com>, linux-kernel@vger.kernel.org
Cc: jack@suse.cz, will.deacon@arm.com, rostedt@goodmis.org, pmladek@suse.cz
Subject: Re: [PATCH] printk: Don't discard earlier unprinted messages to make space
Date: Thu, 22 Oct 2015 11:28:47 +0100 [thread overview]
Message-ID: <1445509727.4113.52.camel@infradead.org> (raw)
In-Reply-To: <20151022101650.25995.95155.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
On Thu, 2015-10-22 at 11:16 +0100, David Howells wrote:
> printk() currently discards earlier messages to make space for new messages
> arriving. This has the distinct downside that if the kernel starts
> churning out messages because of some initial incident, the report of the
> initial incident is likely to be lost under a blizzard of:
>
> ** NNN printk messages dropped **
>
> messages from console_unlock().
>
> The first message generated (typically an oops) is usually the most
> important - the one you want to solve first - so we really want to see
> that.
But wait... didn't I watch you muttering on IRC about the actual bug
you were trying to catch here... and didn't you have a *serial* console
hooked up?
What broke such that serial console stopped giving you *every* message?
Serial console was always *synchronous*.
We could do stuff like...
printk("Going to do foo...\n");
outb(foo, baz);
printk("Did foo and the machine didn't catch fire! Now bar\n");
outb(bar, baz);
printk("Done\n");
And with a serial console I could know *precisely* the point at which
the machine locked up.
And I could enable the silly debugging levels on things like JFFS2 and
be sure that with a serial console I could catch *every* printk
reliably — which led to a number of cases where people would reproduce
a bug with a serial console and debugging, mail me a huge log file, and
get a patch back in reply.
We *need* to have a mode where serial console is actually *reliable*,
and we can know that the message has been sent out the port before the
printk() call returns.
What happened to it? And how do we fix it?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]
next prev parent reply other threads:[~2015-10-22 10:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-22 10:16 [PATCH] printk: Don't discard earlier unprinted messages to make space David Howells
2015-10-22 10:28 ` David Woodhouse [this message]
2015-10-22 12:18 ` Jan Kara
2015-10-22 12:36 ` David Woodhouse
2015-10-22 12:30 ` Petr Mladek
2015-10-22 13:19 ` David Howells
2015-10-22 13:23 ` David Woodhouse
2015-10-23 8:49 ` Petr Mladek
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1445509727.4113.52.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=dhowells@redhat.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.cz \
--cc=rostedt@goodmis.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.