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: > > On Sun, 11 Nov 2018 21:23:52 +0100 > > Stefan Wahren <stefan.wahren@xxxxxxxx> wrote: > > > >> This patch series fixes several issues which has been discovered after > >> submission. > >> > >> Changes in V2: > >> - add my own signed-off-by to patches #1 and #2 > >> > >> Michal Suchanek (1): > >> mmc: bcm2835: reset host on timeout > >> > >> Phil Elwell (1): > >> mmc: bcm2835: Recover from MMC_SEND_EXT_CSD > >> > >> Stefan Wahren (5): > >> mmc: bcm2835: Release DMA channel on driver unload > >> mmc: bcm2835: Avoid possible races on data requests > >> mmc: bcm2835: Terminate timeout work synchronously > >> mmc: bcm2835: Refactor dma_map_sg handling > >> mmc: bcm2835: Properly handle dmaengine_prep_slave_sg > >> > >> drivers/mmc/host/bcm2835.c | 58 ++++++++++++++++++++++++++++++---------------- > >> 1 file changed, 38 insertions(+), 20 deletions(-) > >> > > Hello, > > > > thanks for the patches. > > > > I tried to replace the bcm2835 sdhost driver in my 4.4 kernel with the > > upstream driver + these updates but the 16GB orange EVO card still > > locks up the mmc controller. It seems it locks up much less but is > > certainly not solid. > > 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: 660fc733bd7436f4fa1a351376493e635514ed64 mmc: bcm2835: Add new driver for the sdhost controller. bf3240bada0211b4a555d75f027181c8432b2d20 mmc: bcm2835: Fix possible NULL ptr dereference in c00a231ba053a9b0be8d512957b99395b92bc620 mmc: bcm2835: fix potential null pointer dereferences 2c9e89a1d602c12a4f2bd4c7a57a3315247e3f21 mmc: bcm2835: constify mmc_host_ops structures 118032be389009b07ecb5a03ffe219a89d421def mmc: bcm2835: Don't overwrite max frequency unconditionally f6000a4eb34e6462bc0dd39809c1bb99f9633269 mmc: bcm2835: reset host on timeout 07d405769afea5718529fc9e341f0b13b3189b6f mmc: bcm2835: Recover from MMC_SEND_EXT_CSD 5eae252db3856e62c778832d4d59f6efc5b0aaf9 mmc: bcm2835: Release DMA channel on driver unload af19b7ce76ba220f358c82b0a5e7d68909a23aa5 mmc: bcm2835: Avoid possible races on data requests 37fefadee8bb665ae337a15aa635dabff9f66ade mmc: bcm2835: Terminate timeout work synchronously 6dc6f2619017109e45550accc120f823fdc31c3e mmc: bcm2835: Refactor dma_map_sg handling 2f5da678351f0d504966fab113968202aa5713fb mmc: bcm2835: Properly handle dmaengine_prep_slave_sg 8c9620b1cc9b69e82fa8d4081d646d0016b602e7 mmc: bcm2835: Fix DMA channel leak on probe error e5c1e63c932379b89d7404d4e5fde1bf8abff951 mmc: bcm2835: Drop DMA channel error pointer check What I had before was some previous draft of 660fc733bd7436f4fa1a351376493e635514ed64 + f6000a4eb34e6462bc0dd39809c1bb99f9633269 which would eventually recover on the error but the errors were more frequent with my card. > > Maybe this is related: > > http://lists.infradead.org/pipermail/linux-rpi-kernel/2019-February/008542.html 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. It takes quite a while to reimage, boot different kernel, run system update (which now invariably crashes/locks up with any kernel). Thanks Michal
