From: Peter Hurley <peter@hurleysoftware.com>
To: Matthias Schiffer <mschiffer@universe-factory.net>,
Greg KH <gregkh@linuxfoundation.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
jslaby@suse.com, linux-mips@linux-mips.org,
linux-serial@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Nonterministic hang during bootconsole/console handover on ath79
Date: Mon, 21 Mar 2016 19:51:21 -0700 [thread overview]
Message-ID: <56F0B329.30506@hurleysoftware.com> (raw)
In-Reply-To: <56F0975A.7050609@universe-factory.net>
On 03/21/2016 05:52 PM, Matthias Schiffer wrote:
> On 03/22/2016 12:08 AM, Greg KH wrote:
>> On Tue, Mar 22, 2016 at 12:02:57AM +0100, Matthias Schiffer wrote:
>>> Hi,
>>> we're experiencing weird nondeterministic hangs during bootconsole/console
>>> handover on some ath79 systems on OpenWrt. I've seen this issue myself on
>>> kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other
>>> reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like
>>> QCA953x likewise.
>>
>> Can you try 4.4 or ideally, 4.5? There's been a lot of console/tty
>> fixes/changes since the obsolete 3.18 kernel you are using...
>>
>> thanks,
>>
>> greg k-h
>>
>
> With 4.4, I was not able to reproduce this hang, but I have no idea if this
> is caused by an actual bugfix, or just random timing changes hiding the
> bug.
Can you continue testing with 4.4.x and see if it eventually reproduces?
> I suspect the latter might be the case (as I wrote in my first mail,
> even minor differences in kernel images of the same version and the same
> config make the hang more or less probable.) I was not yet able to test
> 4.5, as OpenWrt is a hell of kernel patches...
>
> On 3.18, I also tried other things like disabling the early console
> altogether, which also made the hang go away, but as even much smaller
> changes hid the bug, this doesn't really say much.
FWIW, printk() is not a small change; takes ~500us @ 115200
>
> The basic code path during the console handover seems to be the same in
> 3.18 and 4.4, even though a few functions have been moved; the relevant
> part of the log looks the same:
>
>> [ 0.756298] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
>> [ 0.766754] console [ttyS0] disabled
>> [ 0.790293] serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11, base_baud = 12500000) is a 16550A
>> [ 0.798909] console [ttyS0] enabled
>> [ 0.798909] console [ttyS0] enabled
>> [ 0.805854] bootconsole [early0] disabled
>> [ 0.805854] bootconsole [early0] disabled
>
> So, in propect of an actual bugfix or backport, this boils down to two
> questions, which I hope the serial or MIPS maintainers can answer me:
>
> * Is it sane to have two console drivers using the same serial port? In
> particular, is it sane for the early console to use the serial port after
> serial8250_config_port has reset/configured it, but before the rest of the
> setup of uart_configure_port has run? (this would be the case for the
> message "serial8250.0: ttyS0 at MMIO...")
> * Is it possible to get the serial controller into a state in which
> early_printk might wait for THRE forever?
I think I addressed these questions in my other reply; let me know if not.
Regards,
Peter Hurley
next prev parent reply other threads:[~2016-03-22 2:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-21 23:02 Nonterministic hang during bootconsole/console handover on ath79 Matthias Schiffer
2016-03-21 23:08 ` Greg KH
2016-03-22 0:52 ` Matthias Schiffer
2016-03-22 2:51 ` Peter Hurley [this message]
2016-03-22 2:44 ` Peter Hurley
2016-03-22 13:07 ` Matthias Schiffer
2016-03-22 15:38 ` Peter Hurley
2016-03-23 17:40 ` Matthias Schiffer
2016-03-24 0:44 ` Peter Hurley
2016-03-24 2:09 ` Matthias Schiffer
2016-03-24 3:17 ` Peter Hurley
2016-03-25 12:59 ` Gabor Juhos
2016-03-25 15:24 ` Peter Hurley
2016-03-22 5:40 ` Antony Pavlov
2016-03-22 9:50 ` Matthias Schiffer
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=56F0B329.30506@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-serial@vger.kernel.org \
--cc=mschiffer@universe-factory.net \
--cc=ralf@linux-mips.org \
/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 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).