Hello, On Sat, 30 Mar 2019 16:15:14 +0100 (CET) Stefan Wahren <stefan.wahren@xxxxxxxx> wrote: > Hi Michal, > > > Michal Suchánek <msuchanek@xxxxxxx> hat am 28. März 2019 um 21:43 geschrieben: > > > > > > On Fri, 22 Mar 2019 18:10:11 +0100 (CET) > > Stefan Wahren <stefan.wahren@xxxxxxxx> wrote: > > > > > Hi Michal, > > > > > > > Michal Suchánek <msuchanek@xxxxxxx> hat am 22. März 2019 um 17:06 geschrieben: > > > > > > > > > > > > On Fri, 22 Mar 2019 15:45:13 +0100 > > > > Stefan Wahren <stefan.wahren@xxxxxxxx> wrote: > > > > > > > > > Hi Michal, > > > > > > > > > > Am 21.03.19 um 21:03 schrieb Michal Suchánek: > > > > > > > > > > could you please retry with mainline kernel 5.0? > > > > > > > > I can try that. What I have is pretty much 5.0 anyway so I don't expect > > > > much difference: > > > > > > > > > > as long as the issue lies in the sdhost driver code. There also has been a lot of fixes by Lukas Wunner to the DMA engine driver. I prefer a well defined source base. > > > > > > > > > > > I suspect that one of the locking fixes that went into mainline > > > > recently prevents recovering from the error but I did not try > > > > reverting them yet. > > > So I suspect we have two different issues here: mmc1: Card stuck in programming state! mmcblk0 card_busy_detect this is an issue to which particular card models are more suspectible and the workaround is to reset the controller which we already do. It typically happens under some IO load. 90% of the time I get this when doing system upgrade when system is installed on a particular orange card. The other which is even harder to reproduce is sdhost-bcm2835 3f202000.sdhost: timeout waiting for hardware interrupt. It typically happens shortly after imaging the card for me. > > could you please try this patch: > > http://lists.infradead.org/pipermail/linux-rpi-kernel/2019-March/008627.html I can try that but the question is what symptom is it supposed to cure and what is the rationale for the change. Thanks Michal
