On 29/03/16 17:37, Jon Hunter wrote: > Hi Lucas, > > On 22/12/15 18:41, Lucas Stach wrote: >> This implements the UHS tuning sequence in a similar way to the one >> contained in the TRM. It deviates in the way how to check if the tap >> value is passing, by using the common Linux MMC function, which does >> not only check for data CRC errors, but also if the received block >> pattern is correct. >> >> Signed-off-by: Lucas Stach <dev@xxxxxxxxxx> > > I have been investigating a hang that occurs randomly during > system-suspend on Tegra124 Jetson TK1 (I have also reproduced the > problem on Tegra124 Nyan Big as well) with -next. The problem does not > occur on every suspend transition but if I execute 100 transitions I > will typically see it at some point. For example ... > > count=0; while [ $count -lt 100 ]; do rtcwake -d rtc0 -m mem -s 3; echo > Suspend iteration $count; count=`expr $count + 1`; done > > I was able to bisect this problem down to RMK's commit 71fcbda0fcdd > (“mmc: sdhci: fix command response CRC error handling”). However, > looking at RMK's change, I believe that this commit is not the problem > but has exposed a problem with the tegra SDHCI driver. > > When the hang occurs I always see the following when starting the > suspend sequence and after which the system continues to suspend but > never exits suspend: > > mmc0: Timeout waiting for hardware interrupt. > > The above message is a symptom of RMK's commit and I have found that > when I see this, it always occurs during tegra_sdhci_execute_tuning() > because sometimes we get a CRC error. For completeness, when disabling the UHS modes for Tegra, I no longer see the hang during suspend (because the execute_tuning() is not called). Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
