Jump to content

Cubietruck freeze after 1-3 days with 5.23 Xenial (uboot problem?)


apollon77

Recommended Posts

Hey,

 

after making sure that all packages are current (armbianmobitor upload available at http://sprunge.us/Migh)I still have the problem currently that my three cubietruicks freeze after working 1-3 days.

Mostly they are still ping-able, but no "heartbeat led blinking" happens anymore and SSH connect also not possible. The logs simply say nothing.

 

Is there anything knows with uboot 5.23 in case ob unstability?

 

The last uboot I remember that was quite stable was 5.20 ... Can I simply downgrade to that using

sudo apt-get install linux-u-boot-cubietruck-next=5.20

or such?

 

Thanks for an advice...

 

Ingo Fischer

Link to comment
Share on other sites

No, it's not a known problem since stability issues are hard to detect and they are sometimes board revision related - different memory chips.

 

Yes, it's usually related to u-boot, where low level inits are done. Because of such problems, we introduced a patch to u-boot and set RAM speed to more conservative levels. This should help and new build should have those settings. I am not sure if this is already added to 5.23 but for sure it's present in our daily build. Try upgrading from here: http://beta.armbian.com/ (beware that this is untested automated daily build)

 

Use one of those:
 

Legacy kernel:

http://beta.armbian.com/pool/main/l/linux-u-boot-cubietruck-default/

Vanilla kernel:

http://beta.armbian.com/pool/main/l/linux-u-boot-cubietruck-next/

Link to comment
Share on other sites

Thank you for this solution!

 

Download file and install directly with "dpkg -i" ?! Or what is the preferred way to install it?

 

Yes, better this way. Alternatively you could switch repository to beta.armbian.com and do apt-get update / upgrade and switch back and do apt-get update ... it's not recommended that this repository is used in production environment. 

Link to comment
Share on other sites

ok - here is my feedback, unfortunately uboot 5.24 does not fix it for me.

 

Cubietruck, Jessie Legacy kernel (3.4.112-sun7i) Image 5.20 with all updates. Stability tests witch cpufreq-ljt-stress-test and Lima Memtester.

 

uboot 5.23: Kernel crashes after few seconds during load, Error on console:

Unable to handlE kernel NULL pointer dereference at virtual address 000000

uboot 5.24 beta (linux-u-boot-cubietruck_5.24.161109_armhf.deb): Kernel crashes after few seconds during load, Error on console:

Unable to handle kernel paging request at virtual address xxxxxx

Downgrading uboot to 5.17 or 5.20 - everything is rock solid. No problems during complete runs of cpufreq-ljt-stress-test and Lima Memtester.

 

Tobias

Link to comment
Share on other sites

Unfortunately - still no success with u-boot 5.24.161116

Unpacking linux-u-boot-cubietruck-default (5.24.161116) over (5.23) ...
Setting up linux-u-boot-cubietruck-default (5.24.161116) ...
Updating u-boot on device /dev/mmcblk0

I've seen this time two different errors as soon as some load was put on the cubietruck. Sometimes it won't even boot to the prompt.

Unable to handle kernel paging request at virtual address xxxxxx

or 

Console: Internal Error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM

Again, starting LIMA Memtester crashed the cubie immediately.

 

If it is of any use - I've uploaded detailed boot log:

root@cubietruck:~# armbianmonitor -u
/var/log/armhwinfo.log has been uploaded to http://sprunge.us/NDDH

Hope this helps. TIA

Tobias

Link to comment
Share on other sites

Reboot and make sure you got a proper u-boot. I made few tests and I could reproduce an error easily while on latest u-boot I could run limatester stable over the night.

Link to comment
Share on other sites

Crash on the Xenial server (so vanilla = next) with 5.24 after 9h in normal operation (there is mainly an influxdb+redis slave running).

Went back to 5.20 there.

 

On Debian Wheezy (legacy=default) still ok ... will see there.

 

Powering can not be the reason.

Link to comment
Share on other sites

Reboot and make sure you got a proper u-boot. I made few tests and I could reproduce an error easily while on latest u-boot I could run limatester stable over the night.

I've prepared a new SD card from scratch with 5.20 image + all updates  + 5.24 beta u-boot for the test. Several reboots with this clean image but still unstable on my cubietruck. Probably a different hardware revision?

 

On my "production" SD card with u-boot 5.20 (otherwise same packages and same jessie legacy kernel) everything is rock solid. There i can Lima Tester for hours without problems.

 

In order to completely rule out hardware problems I've ordered another (used) cubietruck. As soon as it is delivered I'm able to do more testing.

Link to comment
Share on other sites

If lima-memtester simply crashes, then it sounds more like power supply issue than DRAM instability or some other hardware issue.

I don't think it's power or hardware related, because same configuration works fine with 5.20 u-boot. lima-memtester runs without problems for hours...

 

Maybe I used the wrong words. Calling lima-memtester does not crash itself but immediately freezes / crashes the kernel. The cube is shown on the screen.

 

Anyway I've ordered another cubietruck to completely rule out individual hardware problems.

Link to comment
Share on other sites

I don't think it's power or hardware related, because same configuration works fine with 5.20 u-boot. lima-memtester runs without problems for hours...

 

Maybe I used the wrong words. Calling lima-memtester does not crash itself but immediately freezes / crashes the kernel. The cube is shown on the screen.

 

Anyway I've ordered another cubietruck to completely rule out individual hardware problems.

It would be best if you could compile U-Boot yourself and bisect this problem. You can check http://www.metaltoad.com/blog/beginners-guide-git-bisect-process-elimination or any other tutorial about using git bisect.

 

Just using an older U-Boot release is only a workaround. This is unhealthy in the long run.

Link to comment
Share on other sites

Please check what DRAM chips do you have on your board, and ideally you should run lima-memtester with different DRAM clock speeds to find if lower value works for you.

 

Could you please give me some advise

- how to identify DRAM chips (dmesg? armbianmonitor?)

- how to modify DRAM clock speeds? (do I have to compile an individual kernel for that? boot.cmd parameter?

Link to comment
Share on other sites

Crash on the Xenial server (so vanilla = next) with 5.24 after 9h in normal operation (there is mainly an influxdb+redis slave running).

Went back to 5.20 there.

 

On Debian Wheezy (legacy=default) still ok ... will see there.

 

Powering can not be the reason.

Almost glad that I'm not the only one...

Link to comment
Share on other sites

Could you please give me some advise

- how to identify DRAM chips (dmesg? armbianmonitor?)

You can't get this information in a software way. Just check the markings on the four DRAM chips on the board. For example, the original https://linux-sunxi.org/Cubietruck used GT8UB512M8EN-BG chips and you can find them on the pictures.

 

Could you please give me some advise

- how to modify DRAM clock speeds? (do I have to compile an individual kernel for that? boot.cmd parameter?

It is necessary to recompile U-Boot for this after changing the DRAM clock speed settings in the 'configs/Cubietruck_defconfig' file. You can find some instructions here: https://linux-sunxi.org/Mainline_U-Boot#Compile_U-Boot

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines