The following behavior was observed in our custom carrier board. When the carrier board is booted with SD card, the device gets stuck in an infinite loop displaying the error shown below. When the SD card is removed, it boots normally. Similarly when the device is shutdown, it gets stuck in an infinite loop displaying same the error message and if the SD card is removed it shuts down. However, if the SD card is inserted after the device boot up, then SD card is detected normally and no strange behavior was observed. This error was observed with different SD cards and it has persisted even after formatting the SD card.
May 6 05:40:25 tegra-ubuntu kernel: [ 47.978710] mmc2: Timeout waiting for hardware interrupt.
May 6 05:40:25 tegra-ubuntu kernel: [ 47.984106] sdhci: =========== REGISTER DUMP (mmc2)===========
May 6 05:40:25 tegra-ubuntu kernel: [ 47.989929] sdhci: Sys addr: 0x00000000 | Version: 0x00000404
May 6 05:40:25 tegra-ubuntu kernel: [ 47.995752] sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000008
May 6 05:40:25 tegra-ubuntu kernel: [ 48.001574] sdhci: Argument: 0x00000000 | Trn mode: 0x00000033
May 6 05:40:25 tegra-ubuntu kernel: [ 48.007396] sdhci: Present: 0x014b0206 | Host ctl: 0x00000012
May 6 05:40:25 tegra-ubuntu kernel: [ 48.013218] sdhci: Power: 0x00000001 | Blk gap: 0x00000000
May 6 05:40:25 tegra-ubuntu kernel: [ 48.019039] sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
May 6 05:40:25 tegra-ubuntu kernel: [ 48.024862] sdhci: Timeout: 0x0000000e | Int stat: 0x00000000
May 6 05:40:25 tegra-ubuntu kernel: [ 48.030690] sdhci: Int enab: 0x02ff000b | Sig enab: 0x02fc000b
May 6 05:40:25 tegra-ubuntu kernel: [ 48.036519] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
May 6 05:40:25 tegra-ubuntu kernel: [ 48.042349] sdhci: Caps: 0x3f6cd08c | Caps_1: 0x18006f73
May 6 05:40:25 tegra-ubuntu kernel: [ 48.048177] sdhci: Cmd: 0x0000123a | Max curr: 0x00000000
May 6 05:40:25 tegra-ubuntu kernel: [ 48.054003] sdhci: Host ctl2: 0x00003000
May 6 05:40:25 tegra-ubuntu kernel: [ 48.057925] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000080000010
May 6 05:40:25 tegra-ubuntu kernel: [ 48.064444] sdhci: ===========================================
May 6 05:40:25 tegra-ubuntu kernel: [ 48.070561] mmcblk1: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
May 6 05:40:25 tegra-ubuntu kernel: [ 48.336448] mmc2: tried to reset card
I looks like a signal error. Does this do the same thing with other SD cards? Be sure no test SD card has any “/boot” content…I don’t think this has any relevance in your case, but boot macros might get in the way if it detects an alternate boot media. What is the exact model of SD card used (and any specs you might know of)?
Also, this is a regular log. If you have the ability to see boot via a serial console, then the log would also show what goes on in boot loader stages before Linux loads…which could be useful.
Yes. This was observed with different SD cards all of them were formatted before use and the cards’ working was verified by normal read/write operations.
What is the exact model of SD card used (and any specs you might know of)?
The following SD cards were used:
Sandisk 4GB micro SDHC class 4
Sandisk 8GB micro SDHC -1 class 4
ADATA 4GB micro SDHC class 4
What can be the probable causes for the signal error?
One other thought…if the SD card was used, then it must be umount’d prior to removing it (and shutdown or reboot is one way of removing). You’d probably need serial console to catch shutdown messages, but if you can, see if there is any kind of failure to unmount message prior to this.
Next, how is the SD card used? Is it ext4, is it swap space, what application might use it?
A signal error could just be incorrect wiring. It could be from one trace being longer or shaped differently from the other. The impedance could be off due to trace width and/or plating thickness in the design. There could be some other trace nearby causing RF interference. It could be a bad component. It could be noise on a power rail. It is hard to say without looking very closely for your particular case. The OEM product design guide typically talks about such issues.
if the SD card was used, then it must be umount'd prior to removing it
We normally do not unmount the SD card manually before shutdown but did not find any problems in it’s auto mounting in the next bootup. But this issue persisted even after unmounting the SD card.
how is the SD card used? Is it ext4, is it swap space, what application might use it?
Currently the SD card is not used by any application. It is intended as a secondary storage. It was formatted to FAT type.
A correct shutdown without errors is considered a correct umount. In some cases where a process is locking the SD card content, and the process cannot be killed before a timer is reached, shutdown is forced anyway…this is an unclean umount of the SD card. This latter does not often occur, but watch the serial console during shutdown and make sure it really is umounted prior to shutdown…if not, then this can have an effect on content (especially if it is VFAT/FAT32 or any non-journal file system type).
On the assumption that your SD card is “/dev/mmc1blk1”, and with the card not mounted, what do you see from:
sudo fsck.vfat /dev/mmcblk1p1
Note: If you don’t have this, then add dosfstools:
sudo apt-get install dosfstools
Any failure which may have occurred at any time (including from some boot far in the past), and not fixed, would persist and perhaps increase corruption each use. If you don’t have the dosfstools package, then your system would have been incapable of repairing the partition prior to auto mount. Once you know the partition is valid it becomes much more reasonable to ask about other issues, e.g., why it wouldn’t boot. Just as speculation, imagine if the booting system detects a file system error and waits for repair prior to completing boot…but if there is no repair tool, it would wait a very long time.