On Fri, 8 Dec 2023 at 00:49, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Thu, Dec 7, 2023 at 6:49 AM Kalle Valo <kvalo@xxxxxxxxxx> wrote: > > > > > Recently during our Android build test on the Dragonboard 845c board, > > > with the Android Common Kernel android11-5.4-lts and android12-5.4-lts branches, > > > > > > we found there are some ufshcd related changes printed, > > > and the serial console gets stuck, no response for input, > > > and the Android boot is stuck at the animation window. > > > > > > The problem is reported here > > > https://issuetracker.google.com/issues/314366682 > > > You could check there for more log details. > > > > > > And with some bisection, I found it's related to this commit, > > > when I revert this commit, the problem is gone. > > > > > > So replied here, not sure if you have any idea about it, > > > or any suggestions on what we should do next to resolve the problem? > > > > FWIW we don't support Android kernels, only kernel.org releases. > > Right. If the problem also reproduces on mainline Linux then that > would be interesting to know. I think db845c is at least somewhat well > supported by mainline so it should be possible to test it there. I checked with the ACK android-mainline branch, which is based on the mainline Linux, this commit is there, but the problem is not seen. > If I had to guess, I'd think that probably the CE interrupts are > firing nonstop for you and not getting handled. Then those constant > interrupts are (presumably) causing the UFS controller to timeout. If > this is true, the question is: why? Maybe you could use ftrace to > confirm this by adding some traces to > ath10k_snoc_per_engine_handler()? There's a way to get ftrace buffers > dumped on panic (or, if you use kdb, it has a command for it). Thanks for the suggestions, I will check internally on how to debug that. > If this reproduces on mainline and it's not obvious how to fix this, I > don't object to a revert. As per the description of the original > patch, the problem being fixed was fairly rare and I didn't have a way > to reproduce it. The fix seemed safe to me and we've been using it on > Chromebooks based on sc7180, but if it had to get reverted it wouldn't > be the end of the world. > > -Doug -- Best Regards, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android@xxxxxxxxxxxxxxxx http://lists.linaro.org/mailman/listinfo/linaro-android
