Rootfs booting issue

I’m trying to boot Apalis iMX6Q SOM, image loading on to eMMC. Booting is getting interrupted post kernel boot. I have attached the boot logs for the analysis. Kindly support on the issue.

Glimpse of the error message.

ALSA device list:
  #0: imx6q-apalis-sgtl5000
  #1: imx-spdif
  #2: imx-hdmi-soc
**EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
EXT4-fs (mmcblk0p2): write access will be enabled during recovery**
usb 2-1.2: new full-speed USB device number 3 using ci_hdrc
ftdi_sio 2-1.2:1.0: FTDI USB Serial Device converter detected
usb 2-1.2: Detected FT-X
**EXT4-fs (mmcblk0p2): recovery complete**
usb 2-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
**[mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400e00][1]**
random: crng init done
usb 2-1.1: new high-speed USB device number 4 using ci_hdrc
usb 2-1.1: config 1 has an invalid interface number: 8 but max is 4
usb 2-1.1: config 1 has an invalid interface number: 10 but max is 4
usb 2-1.1: config 1 has no interface number 1
usb 2-1.1: config 1 has no interface number 4
INFO: task swapper/0:1 blocked for more than 10 seconds.
      Not tainted 4.9.166-2.8.6+gd899927 #2
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
swapper/0       D    0     1      0 0x00000000
Backtrace: 
[<8083677c>] (__schedule) from [<80836cf8>] (schedule+0x44/0xa4)
 r10:e26de798 r9:e26de400 r8:8083752c r7:7fffffff r6:00000000 r5:e57aae40
 r4:ffffe000
[<80836cb4>] (schedule) from [<80839c74>] (schedule_timeout+0x1cc/0x274)
 r5:e57aae40 r4:7fffffff
[<80839aa8>] (schedule_timeout) from [<80836744>] (io_schedule_timeout+0x7c/0xb4)
 r8:8083752c r7:7fffffff r6:00000000 r5:e57aae40 r4:e57aa980
[<808366c8>] (io_schedule_timeout) from [<80837544>] (bit_wait_io+0x18/0x64)
 r7:80c02b50 r6:e205db04 r5:00000002 r4:00000002
[<8083752c>] (bit_wait_io) from [<80837188>] (__wait_on_bit+0x68/0xc0)
 r5:00000002 r4:e205daf8
[<80837120>] (__wait_on_bit) from [<808372dc>] (out_of_line_wait_on_bit+0x74/0x7c)
 r9:e26de400 r8:e212a014 r7:00000002 r6:8083752c r5:e002f840 r4:00000002
[<80837268>] (out_of_line_wait_on_bit) from [<8023baac>] (__wait_on_buffer+0x38/0x3c)
 r7:e2109000 r6:00000000 r5:e212a000 r4:e002f840
[<8023ba74>] (__wait_on_buffer) from [<802ccb78>] (jbd2_write_superblock+0x148/0x1c4)
 r5:e212a000 r4:e002f840
[<802cca30>] (jbd2_write_superblock) from [<802ccd14>] (jbd2_mark_journal_empty+0xb8/0xe8)
 r7:00028800 r6:e2109000 r5:e212a014 r4:e212a000
[<802ccc5c>] (jbd2_mark_journal_empty) from [<802cd1c8>] (jbd2_journal_flush+0xf8/0x1b0)
 r7:e212a07c r6:e212a07c r5:e212a000 r4:00000000
[<802cd0d0>] (jbd2_journal_flush) from [<80297364>] (ext4_mark_recovery_complete.constprop.13+0x44/0x90)
 r9:e26de400 r8:e26de000 r7:00000000 r6:00000000 r5:e26de000 r4:e212a000
[<80297320>] (ext4_mark_recovery_complete.constprop.13) from [<8029d10c>] (ext4_fill_super+0x2704/0x3880)
 r5:0000001d r4:e26a5380
[<8029aa08>] (ext4_fill_super) from [<8020db44>] (mount_bdev+0x164/0x190)
 r10:00008001 r9:00000000 r8:00008001 r7:e00aa26c r6:00000081 r5:e26de000
 r4:e00aa200
[<8020d9e0>] (mount_bdev) from [<80295800>] (ext4_mount+0x20/0x28)
 r9:00000060 r8:00000000 r7:80c129dc r6:80c129dc r5:e269f340 r4:802957e0
[<802957e0>] (ext4_mount) from [<8020e5a8>] (mount_fs+0x1c/0xb0)
[<8020e58c>] (mount_fs) from [<8022b9ac>] (vfs_kern_mount.part.2+0x50/0xf8)
 r6:00008001 r5:e269f340 r4:e263aa00
[<8022b95c>] (vfs_kern_mount.part.2) from [<8022df6c>] (do_mount+0x164/0xc6c)
 r9:00000060 r8:e269f300 r7:e269f340 r6:80c129dc r5:00000000 r4:00008001
[<8022de08>] (do_mount) from [<8022edf0>] (SyS_mount+0x5c/0xc8)
 r10:80a0a88c r9:80a0a890 r8:00008001 r7:80a0a890 r6:00000000 r5:e269f300
 r4:e269f340
[<8022ed94>] (SyS_mount) from [<80b01298>] (mount_block_root+0x11c/0x280)
 r8:00008001 r7:80b4785c r6:e6444420 r5:e26a1000 r4:e26a1000
[<80b0117c>] (mount_block_root) from [<80b01610>] (mount_root+0x128/0x130)
 r10:80b4783c r9:80b00604 r8:80b47838 r7:80c46680 r6:80c466a4 r5:80c0663c
 r4:0b300002
[<80b014e8>] (mount_root) from [<80b0179c>] (prepare_namespace+0x184/0x1cc)
 r9:80b00604 r8:80b47838 r7:80c46680 r6:80c46680 r5:80c466a4 r4:80b4785c
[<80b01618>] (prepare_namespace) from [<80b00ef0>] (kernel_init_freeable+0x1f8/0x208)
 r6:80c46680 r5:00000009 r4:80ae70d4
[<80b00cf8>] (kernel_init_freeable) from [<80835f6c>] (kernel_init+0x10/0x118)
 r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:80835f5c
 r4:00000000
[<80835f5c>] (kernel_init) from [<80107c30>] (ret_from_fork+0x14/0x24)
 r5:80835f5c r4:00000000

attachment

Hi @Harshith,

Welcome to the Toradex community!

Could you please provide below information,

  • Did you try by reflashing the full image?
  • Are you modifying anything on Kernel/DTB?
  • Please attach full dmesg.

Hi @Harshith ,

Which carrier board are you using?
Is it possible to share Kernel and DTB binaries, so I can try to boot from the same?
Also please mention your branch and commit ID for the kernel.

I will test at my end and let you know.

Hello Team,

Please find the answers

Did you try by reflashing the full image?

  • I hope reflashing could bring back the board to working, but we were suppose to identify the root cause before reflash.

Are you modifying anything on Kernel/DTB?

  • No modifications on kernel/DTB

Hello Team,

Please find the answers

Did you try by reflashing the full image?

  • I hope reflashing could bring back the board to working, but we were suppose to identify the root cause before reflash.

Are you modifying anything on Kernel/DTB?

  • No modifications on kernel/DTB

Please attach full dmesg.

  • Boot process in not onto root terminal, so could not get the full trace of dmesg.

Did you ever solve this? Could you reveal what exact hardware (module and carrier board) and software versions of things you are talking about? Thanks!