Installed from Armbian_5.14_Odroidc2_Ubuntu_xenial_3.14.72. Tested in two different Odroid C2's. One with EMMC, the other with SD CARD and fully updated.

 

Procedure:

fallocate -l 2G /root/2GB.file
cp /root/2GB.file /.

After that all sort of erratic behavior from the board and eventually it crashes. In /var/log/kern.log:

Aug 19 14:28:01 localhost kernel: [  669.078129] INFO: rcu_preempt detected stalls on CPUs/tasks: { 3} (detected by 2, t=33627 jiffies, g=296, c=295, q=84431)
Aug 19 14:28:01 localhost kernel: [  669.083412] Task dump for CPU 3:
Aug 19 14:28:01 localhost kernel: [  669.083418] kthread_hdcp    R  running task        0    65      2 0x00000002
Aug 19 14:28:01 localhost kernel: [  669.083425] Call trace:
Aug 19 14:28:01 localhost kernel: [  669.083438] [<ffffffc00108570c>] __switch_to+0x74/0x90
Aug 19 14:28:01 localhost kernel: [  669.083446] [<ffffffc001820418>] __schedule+0x3e8/0x790
Aug 19 14:28:01 localhost kernel: [  669.083451] [<ffffffc0018207f0>] schedule+0x30/0x88

Installed Hardkernel's Xenial minimal image (fully updated) for testing, and this problem doesn't exist.

 

Regards

Nuno

 

I compiled kernel from latest sources and this can't be reproduced. It does not crash.

 

Will be pushed to repository ASAP.

I compiled kernel from latest sources and this can't be reproduced. It does not crash.

 

Will be pushed to repository ASAP.

 

Was able to compile from source and the problem is gone. Keep up the good work!!

Did a little more testing and found that it isn't resolved and that the cause for this problem is related to the "setenv nographics "1". If set to 0 there's no problem. Can anyone test? Thanks

Did a little more testing and found that it isn't resolved and that the cause for this problem is related to the "setenv nographics "1". If set to 0 there's no problem. Can anyone test? Thanks

Found the same problem regarding the odroid c2 in arch and hardkernel:

http://forum.odroid.com/viewtopic.php?f=136&t=21520

https://archlinuxarm.org/forum/viewtopic.php?f=67&t=10420

Hi nbj,

 

I had the same issue with my headless Odroid C2. 100% reproducable by writing large files to the USB harddisk attached using dd if0/dev/zero of=/media/data/test bs=1M count = 2000

The Arch people proposed a solution which works fine for me.

 

In boot.ini, after the line

if test "${nographics}" = "1"; then fdt rm /reserved-memory; fdt rm /aocec; fi

add

if test "${nographics}" = "1"; then fdt rm /meson-fb; fdt rm /amhdmitx; fdt rm /picdec; fdt rm /ppmgr; fi
if test "${nographics}" = "1"; then fdt rm /meson-vout; fdt rm /mesonstream; fdt rm /meson-fb; fi
if test "${nographics}" = "1"; then fdt rm /deinterlace; fdt rm /codec_mm; fi

and reboot.

 

Now handling large amounts of data works w/o problem.

 

Cheers,

smn

In boot.ini, after the line

if test "${nographics}" = "1"; then fdt rm /reserved-memory; fdt rm /aocec; fi

add

if test "${nographics}" = "1"; then fdt rm /meson-fb; fdt rm /amhdmitx; fdt rm /picdec; fdt rm /ppmgr; fi
if test "${nographics}" = "1"; then fdt rm /meson-vout; fdt rm /mesonstream; fdt rm /meson-fb; fi
if test "${nographics}" = "1"; then fdt rm /deinterlace; fdt rm /codec_mm; fi

and reboot.

 

 

Tried this out the other day.  It runs good.  Feels nice getting that 300MB RAM back on a headless machine.  Thanks much for the info on the fix.