Occasional boot problems

[warped-rudi]

From time to time I get the problem that the kernel cannot access the sd card when trying to mount the root file system. It happens mostly (but not always) when the Hummingboard is powered on for the first time after having been off for a few hours. A second attempt to boot usually works. I have not seen this on the Cubox-i, only on the Hummingboard with recent kernels. SD card is Sandisk Ultra 8GB.

[rabeeh]

Which HummingBoard is that? Which I.mx6 variant?

[linux4kix]

Make sure caam secvio is disabled.

On Sun, Oct 25, 2015, 9:34 AM Rabeeh Khoury notifications@github.com
wrote:

Which HummingBoard is that? Which I.mx6 variant?

—
Reply to this email directly or view it on GitHub
#28 (comment).

[warped-rudi]

@rabeeh: I guess it's the first release (i2ex). Got it about a year ago...
@linux4kix: The option is disabled.

[samnazarko]

Seeing similar things, again with SanDisk Ultra 8GB.

User reports thee lines at boot, followed by a hang:

Timed out waiting for device dev-mmcblk0-p1.device
Dependency failed for /boot
Dependency failed for Local File Systems

Have tried: rootwait, rootdelay=30, even ignoring the warnings with rootflags=nofail rd.fstab=0 noquiet loglevel=7 . Unfortunately cannot replicate myself. I can tell you that we see 'mcblk0' brought up after systemd has failed the boot.. with loglevel=7 I see the mount has failed, then I see that the SD has been detected and 'mmcblk0p1 and mmcblk0p2' appear.

Interestingly our installer which initially boots to /dev/ram0 (initramfs based partitioning tool) does not have this probem. Probably because installer takes 25-30 seconds to boot before it tries to touch the SD. Only seeing this since move from 3.14.37 to 4.x

[warped-rudi]

Here's a log that shows the problem. As usual, a second boot attempt right after this incident went fine.

mmc0: new ultra high speed DDR50 SDHC card at address aaaa
mmcblk0: mmc0:aaaa SL08G 7.40 GiB
mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
caam 2100000.caam: Instantiated RNG4 SH0
end_request: I/O error, dev mmcblk0, sector 0
mmcblk0: error -84 transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 2
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 0
mmcblk0: error -84 transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 2
Buffer I/O error on device mmcblk0, logical block 0
ldm_validate_partition_table(): Disk read failed.
mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 0
mmcblk0: error -84 transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 2
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: unable to read partition table

[vzapolskiy]

Hi @warped-rudi

I've encountered the same problem recently (not just with SanDisk DDR50 cards, also with Toshiba DDR50 SD cards) and it seems that one workaround from Freescale helps, its internal Freescale id is ENGR00324668.

Seems that the transition from Freescale to NXP ruined https://github.com/imx repositories, fortunately the change still can be found around, e.g. https://github.com/xbianonpi/xbian-package-kernel/blob/master/patches/imx6/ef3bce5feb2ed36c9f4483287454d35ae330dbe3.patch

Try to port it and retest, hope it helps.

[warped-rudi]

@vzapolskiy

This patch is already present in our source tree.

[jnettlet]

Should be fixed with the latest kernel https://github.com/SolidRun/linux-fslc