Re: Unstable Kernel behavior on an ARM based board

[Embedded Engineer <embed786@gmail.com>]

On Sat, Mar 2, 2019 at 5:39 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> I think you're lucky it got that far:

Indeed, I think the same because on subsequent reboots, the system
always gets stuck at following:

[    6.080364] VFS: Mounted root (ext4 filesystem) on device 179:1.
[    6.091900] devtmpfs: mounted
[    6.095711] Freeing unused kernel memory: 1024K (c0800000 - c0900000)
Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
[    6.443184] init: plymouth-upstart-bridge main process (89)
terminated with status 1
[    6.452397] init: plymouth-upstart-bridge main process ended, respawning
[    6.460580] tegra-mc 70019000.memory-controller: sdmmcwab: write
@0x00000000: EMEM address decode error (EMEM decode error)
[    6.515303] init: plymouth-upstart-bridge main process (100)
terminated with status 1
[    6.515387] init: plymouth-upstart-bridge main process ended, respawning
[    6.536591] tegra-mc 70019000.memory-controller: sdmmcwab: write
@0x00000000: EMEM address decode error (EMEM decode error)
[    6.564351] init: ureadahead main process (92) terminated with status 5
[    6.571400] init: plymouth-upstart-bridge main process (106)
terminated with status 1
[    6.581434] init: plymouth-upstart-bridge main process ended, respawning
[    6.609268] init: plymouth-upstart-bridge main process (109)
terminated with status 1
[    6.622510] init: plymouth-upstart-bridge main process ended, respawning
[    6.646083] init: plymouth-upstart-bridge main process (112)
terminated with status 1
[    6.656656] init: plymouth-upstart-bridge main process ended, respawning
[    6.670629] mmc0: ADMA error


> IMHO, this points to RAM timing or wiring issues.  I don't know much
> about Tegra, but could it be a too-old u-boot (it reports that it's
> 2014, but apparently extlinux support was only merged in 2017...)?
> As you've said that these are a new board design, it could also be a
> design error with the RAM wiring.

I had the same thoughts at first, but my team insisted that they have
verified RAM using vendor provided memory characterization and test
tool. Although the RAM tests passed only at 204 MHz and below
frequencies, so currently we are using RAM at 204 MHz. As testing, I
also tested 1.5 GB of RAM using Linux stress tool (when the board
somehow managed to get to bash) and it didn't return any error. This
made us believe that RAM is not the root cause, may be you can comment
better on how authentic the results of 'stress' tool are.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel