Hi Doug,
and sorry about the late feedback on this (was out of office last
week).
On Mon, Jun 10, 2024 at 03:24:18PM -0700, Douglas Anderson wrote:
>
> While trying to reproduce -EBUSY errors that our lab was getting in
> suspend/resume testing, I ended up finding a whole pile of problems
> with the Qualcomm GENI serial driver. I've posted a fix for the -EBUSY
> issue separately [1]. This series is fixing all of the Qualcomm GENI
> problems that I found.
>
> As far as I can tell most of the problems have been in the Qualcomm
> GENI serial driver since inception, but it can be noted that the
> behavior got worse with the new kfifo changes. Previously when the OS
> took data out of the circular queue we'd just spit stale data onto the
> serial port. Now we'll hard lockup. :-P
Thanks for taking a stab at this. This is indeed a known issue that has
been on my ever growing TODO list for over a year now. I worked around a
related regression with:
9aff74cc4e9e ("serial: qcom-geni: fix console shutdown hang")
but noticed that the underlying bug can still easily be triggered, for
example, using software flow control in a serial console.
With 6.10-rc1 I started hitting this hang on every reboot. I was booting
the new x1e80100 so wasn't sure at first what caused it, but after
triggering the hang by interrupting a dmesg command I remembered the
broken serial driver and indeed your (v2) series fixed the regression
which was also present on sc8280xp.
I did run a quick benchmark this morning to see if there was any
significant performance penalty and I am seeing a 26% slow down (e.g.
catting 544 kB takes 68 instead of 54 seconds at 115200).
I've had a feeling that boot was slower with the series applied, but I
haven't verified that (just printing dmesg takes an extra second,
though).
Correctness first, of course, but perhaps something can be done about
that too.
I'll comment on the individual patches as well, but for now:
Tested-by: Johan Hovold <johan+linaro@xxxxxxxxxx>
(I did a quick test with Bluetooth / DMA as well.)
Johan
