I am regularly suffering system lock-ups caused by the above error on my custom board based on the Xilinx Zynq 7000 Soc. The error from the kernel is always exactly the same (including all the same hex values): mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0xe00 Has this error been reported before (I couldn't find a match in the mailing list archive), and is the problem likely to be in the kernel driver or in hardware? I have spent some time tracing waveforms and checking signal integrity, pull-up resistors and so on to no avail. The error always occurs when writing to the SD card, and most often when more than one file is being written and the file system cache is flushed (by running the 'sync' command). Usually doing this three of four times, or packing up some zip files, is enough to trigger the error, which then causes all access to the CD card to hang until the system is hard reset. The access pattern is in some sense important, because I also tried the f3 flash test utilities (http://oss.digirati.com.br/f3/) which write a few large files of sequential data and read them back. These all run fine on all the cards I have tested, so they don't trigger the problem. All cards are formatted FAT32. This problem has now been reported with three different card vendors (I am getting the last two sent to me so I can re-test them all here): * Phison 8GB cards (industrial cards using Toshiba flash, multiple samples and firmware versions tested) * Sandisk 16GB Class 4 card * PNY 16GB Class 10 card however I also have cards from Samsung and Kingston which are absolutely fine, and will run my test script for hours without faltering. So the problem is not with all SD cards (however we have stocks of the Phison industrial cards so we do not want to move away from them if we can help it). The Zynq SOC uses the sdhci kernel driver, our board has a microSD card slot connected to sdhci0 with the following device tree fragments (generated by the Xilinx Zynq development tools): sdhci0: sdhci@e0100000 { compatible = "arasan,sdhci-8.9a"; status = "disabled"; clock-names = "clk_xin", "clk_ahb"; clocks = <&clkc 21>, <&clkc 32>; interrupt-parent = <&intc>; interrupts = <0 24 4>; reg = <0xe0100000 0x1000>; }; &sdhci0 { clock-frequency = <50000000>; status = "okay"; }; Changing the clock frequency downwards does not affect the problem, it still occurs in the same way with the same reproducibility. This problem originally showed up in a Xilinx kernel based on 3.18, I have subsequently upgraded the kernel to the Xilinx v2105.4.01 which is based on mainline 4.0.0, with no change in the messages and results. I am about to start on trying to run a stock mainline kernel to see if I can reproduce the problem there (although this generates other issues with drivers for the Xilinx QSPI controller). Richard Richard Ash EA Technology -- 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
