I had a quick look at your log file and do have some comments:
=> That is a rather old U-Boot version especially if paired with the latest mainline Linux kernel. I would recommend using a later U-Boot e.g. from our BSP 2.7b4 (to be announced stable as well shortly).
Model: Toradex Apalis T30 2GB V1.0E, Serial# 02650923
=> That is a sample module released 2014-07-01. We since did quite some hardware improvements (incl. eMMC and gigabit Ethernet related). I would recommend using a current module version for your testing:
=> Unfortunately due to some ext4 issue in downstream we are still using ext3 in our Apalis T30 BSPs. However if using the mainline Linux kernel using ext4 would be very much recommended. We recently migrated to ext4 on our later modules (e.g. Apalis TK1) where you may find resp. changes required:
[0.000000] Linux version 4.14.11-dirty (root@kamil-VirtualBox) (gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-2)) #2 SMP PREEMPT Thu Jan 4 09:24:14 CET 2018
=> GCC 5 is also rather outdated especially if paired with the latest mainline Linux kernel. I would recommend using a later stable Linaro GCC 6 or even GCC 7 tool chain:
[0.000000] Kernel command line: core_edp_mv=1300 usb_high_speed=1 ip=off root=/dev/mmcblk2p2 rw,noatime rootfstype=ext3 rootwait igb_mac=00:14:2d:28:73:2b consoleblank=0 no_console_suspend=1 console=tty1 console=ttyS0,115200n8 debug_uartport=lsport,0 vmalloc=256M mem=2035M@2048M fbmem=12M@4083M video=tegrafb0:1024x768R-16@60
=> The rw,noatime is not really correct and rather problematic. An updated U-Boot as recommended above will already fix this in its default environment:
=> Of course the rootfstype=ext3 should also be changed to ext4 if migrating.
[4.876322] mcp251x spi1.1: Cannot initialize MCP2515. Wrong wiring?
[4.882728] mcp251x spi1.1: Probe failed, err=19
=> I believe I do have a fix ready for that somewhere but yet have to submit it. Not important if you are not using CAN I guess.
[6.582348] EXT4-fs (mmcblk2p2): mounting ext3 file system using the ext4 subsystem
=> That is really sub-optimal as we found out during stress testing in our temperature chambers. However I can’t remember on top of my head right now whether the errors we saw looked exactly like what you are seeing now.
[ 680.880178] mmc2: Card stuck being busy! mmc_poll_for_busy
[ 680.885663] mmc2: Error -110 starting bkops
=> I vaguely remember already having mentioned once to you before that bkops aka hpi is quite broken on those SKHynix resp. Hynix eMMC parts as assembled on those earlier samples. However if using later module versions as suggested above this should no longer be an issue. Otherwise you really do need disabling this by e.g. adding the following to the resp. eMMC sdhci device tree node:
status = "okay";
compatible = "mmc-card";
reg = <0>;
With that I guess you do already have something to chew on for now. Let us know how it goes and we are happy to assist you further. Good luck!