From: Johan Hovold <johan@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Johan Hovold <johan+linaro@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Bjorn Andersson <andersson@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] serial: qcom-geni: fix hard lockup on buffer flush
Date: Thu, 4 Jul 2024 11:59:01 +0200 [thread overview]
Message-ID: <ZoZyZcVyLvI9t4fH@hovoldconsulting.com> (raw)
In-Reply-To: <ZnrW5EcGKGYzS8qf@hovoldconsulting.com>
On Tue, Jun 25, 2024 at 04:40:36PM +0200, Johan Hovold wrote:
> On Mon, Jun 24, 2024 at 10:39:07AM -0700, Doug Anderson wrote:
> > On Mon, Jun 24, 2024 at 6:31 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> > >
> > > The Qualcomm GENI serial driver does not handle buffer flushing and used
> > > to print garbage characters when the circular buffer was cleared. Since
> > > commit 1788cf6a91d9 ("tty: serial: switch from circ_buf to kfifo") this
> > > instead results in a lockup due to qcom_geni_serial_send_chunk_fifo()
> > > spinning indefinitely in the interrupt handler.
> > >
> > > This is easily triggered by interrupting a command such as dmesg in a
> > > serial console but can also happen when stopping a serial getty on
> > > reboot.
> > >
> > > Fix the immediate issue by printing NUL characters until the current TX
> > > command has been completed.
> > I don't love this, though it's better than a hard lockup. I will note
> > that it doesn't exactly restore the old behavior which would have
> > (most likely) continued to output data that had previously been in the
> > FIFO but that had been cancelled.
>
> Ah, yes, you're right. I went back and compared with 6.9 and the effect
> was indeed (often) that the machine felt sluggish when you hit ctrl-c to
> interrupt something like dmesg and the driver would continue to print up
> to 4k characters after that (e.g. 350 ms at 115200).
>
> The idea here was to fix the lockup regression separately and then have
> the third patch address the buffer flush failure, which could also be
> backported without depending on the kfifo conversion.
>
> But running with this series since yesterday, I realise there are still
> some unresolved interaction with the console code, which can now trigger
> a soft (instead of hard) lockup on reboot...
I've reworked my series to avoid the remaining lockup, which was due to
v1 not handling some cases where cancelling a command left stale data in
the fifo.
I've also reordered the patches to avoid printing NUL characters as an
intermediate fix.
Johan
next prev parent reply other threads:[~2024-07-04 9:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 13:31 [PATCH 0/3] serial: qcom-geni: fix lockups Johan Hovold
2024-06-24 13:31 ` [PATCH 1/3] serial: qcom-geni: fix hard lockup on buffer flush Johan Hovold
2024-06-24 17:39 ` Doug Anderson
2024-06-24 20:45 ` Doug Anderson
2024-06-25 14:53 ` Johan Hovold
2024-06-25 16:27 ` Doug Anderson
2024-06-25 14:40 ` Johan Hovold
2024-07-04 9:59 ` Johan Hovold [this message]
2024-06-24 13:31 ` [PATCH 2/3] serial: qcom-geni: fix soft lockup on sw flow control and suspend Johan Hovold
2024-06-24 21:23 ` Doug Anderson
2024-06-24 21:58 ` Doug Anderson
2024-06-26 7:54 ` Johan Hovold
2024-07-04 10:08 ` Johan Hovold
2024-06-26 7:42 ` Johan Hovold
2024-06-24 13:31 ` [PATCH 3/3] serial: qcom-geni: fix garbage output after buffer flush Johan Hovold
2024-06-24 22:19 ` Doug Anderson
2024-06-26 8:01 ` Johan Hovold
2024-07-03 14:09 ` [PATCH 0/3] serial: qcom-geni: fix lockups Greg Kroah-Hartman
2024-07-03 14:13 ` Johan Hovold
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=ZoZyZcVyLvI9t4fH@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=andersson@kernel.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=johan+linaro@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.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