Hi Niklas, On Saturday, October 28, 2017, Niklas Söderlund wrote: > > All was fine until that patch you submitted (52ad9a8e854c) that now adds > > a wait_for_completion() in the SDHI callback. > > This is a interesting finding, I did some bisecting a while back to try > and understand why a known problematic SD card started to have more > issues then last time I tested it. That investigation also ended up > pointing to 52ad9a8e854c. > > > > > Now I get the "BUG: scheduling while atomic". > > > > The R-Car driver uses a threaded irq to call the callbacks, not a > > tasklet. > > > > So I hacked my code to also call the callbacks from a threaded irq like > > rcar-dma.c. > > And....that works (no more scheduling while atomic). > > Can you post that hack or just send it to me privately if it's to > hackish for a mailinglist :-) I'm still interested in my problematic SD > card and would just like to see what happens with your hack applied. I hacked my RZ/A DMA driver, not the SDCARD driver. I assume you are using R-Car, so that driver already uses a threaded IRQ handler (not a tasklet). But, what I did not try yet was rewriting the patch for SDHI (52ad9a8e854c) so that instead of using wait_for_completion() in the callback, it creates a kernel thread to do the waiting. In that case, the DMA tasklet would complete immediately and my DMA driver could remain using tasklets instead of threaded irqs. I am worried about the scheduling latencies of using a kernel thread for the SDHI callback, but, I guess that's no different than using a threaded irq handler. However...I'm wondering if I'm missing something obvious here and doing extra work for nothing. Chris
