apollon77
-
Posts
115 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by apollon77
-
-
The question is if this is the goal ... I would like to support a generic usable setting to be used by Armbian ... As soon as I start with using Device specific settings I'm out for the "Armbian default u-boot" ... yes my devices may be more stable ... hm ...
-
Now it's getting weired ...
A cubietruck that had no problems so far (cubietruck5) which seems to work well with 384-u-boot seems to have problems with 432 :-(
The cubietruck freezed after 2-5h with tpm8-normal-432 u-boot ...
I test now with 432-DCDC3 and will post the result ...
For me it seems that depending on whatever some work better with 432 and some better with 384 ... And then it would be problematic to provide an u-boot for all of them :-(
-
Freezes and memory corruption errors are very likely two different types of problems (and both are bad). If DCDC3 voltage is insufficient, then we get freezes. If the clock speed is too high (or too low), then we get memory corruption errors. Yes, the clock speed also affects freezes to a smaller extent.
Hm ... but the results here show freezes more connected to the clock speed then to DCDC3 voltage ...
-
u-boot 432MHz-DCDC3-13v runned 20 loops without any errors or failures.
Now I have installed official u-boot 5.20 and also give this an overnight test to see if it is as stable as with 432er tpm8-u-boot :-)
Tomorrow evening: test 432 u-boot on cubietruck4 (to see if start now works) and cubietruck5 (was stable so far)
-
u-boot 432MHz-DCDC3-13v now runs in his 5th loop without any errors or failures.
So it seems that power option brings no real change: on this cubietruck 432 works and 382 freezes
-
Ok, first results from me on Cubietruck3 fpr 384MHz-DCDC3-13v: To compare to earlier results I started limatester with 100MB.
Don't know if it is "More reliable" ... it runned around 1,5h andfreezed in the 5th loop, but some errors from testing occured:
Sun Feb 19 15:48:22 UTC 2017 This is a simple textured cube demo from the lima driver and a memtester. Both combined in a single program. The mali400 hardware is only used to stress RAM in the background. But this happens to significantly increase chances of exposing memory stability related problems. Kernel driver is version 14 Detected 1 Mali-400 GP Cores. Detected 2 Mali-400 PP Cores. FB: 1920x1080@32bpp at 0x44001000 (0x00FD2000) Using dual buffered direct rendering to FB. memtester version 4.3.0 (32-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffff000 want 100MB (104857600 bytes) got 100MB (104857600 bytes), trying mlock ...locked. Loop 1: Stuck Address : testing 7FAILURE: possible bad address line at offset 0x05319ae0. Skipping to next test... Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : testing 6WRITE FAILURE: 0x55555555 != 0x5555d755 at offset 0x01437f20 (checkerboard). Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok Loop 2: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : testing 26WRITE FAILURE: 0xaaaaaaaa != 0xaaaa55aa at offset 0x015db20c (checkerboard). Bit Spread : ok Bit Flip : testing 72WRITE FAILURE: 0xfffffdff != 0xffff01ff at offset 0x006f92f8 (bitflip). Walking Ones : ok Walking Zeroes : ok Loop 3: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : testing 4WRITE FAILURE: 0x55555555 != 0x5555ee55 at offset 0x017d6b00 (checkerboard). Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok Loop 4: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : testing 3WRITE FAILURE: 0xaaaaaaaa != 0xaaaaf6aa at offset 0x010f42c0 (checkerboard). Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok Loop 5: Stuck Address : testing 13FAILURE: possible bad address line at offset 0x00217340. Skipping to next test... Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : setting 10
-
@tpm8: could you please compile an 384 u-boot with that option ... then I can retest that too
-
Freezing is the symptom what's all about in this thread. I have no serial console and also no monitor on that cubietruck, so I only have the SSH console.
Additionally I use one of the LEDs with "heartbeat" - when it freezes it also stops blinking ...
How do I increase DCDC3 voltage?
With tpm8-u-boot 432MHz cubietruck 3 now do limatester 1000MB since
10h20h -
I used some time the last days to do some tests. Here first results with 5.25 official u-boot from armbian:
- cubietruck1 -> 2 limatester-runs without freeze (but freezed before and was more stable in operation with u-boot 5.25 then with 5.20)
- cubietruck2 -> 2 limatester-runs runs without crash (but freezed before and was much more stable in operation with u-boot 5.20 then with 5.24/5!)
- cubietruck3 -> freeze after 10 mins limatester, multiple tries see above (most start of the "Checkerboard" tests)
- cubietruck4 -> reproducable freeze at limatester-start at "got 100MB, trying mlock ...", multiple tries
- cubietruck5 -> 2 limatester-runs without freeze
Now I focus my tests on "Cubietruck3" for the beginning and tried the tpm8-u-boot-384 there. Result: Freeze in the second limatester loop ... so Interestingly later then the 10 mins before, but freezed still fast.
Now I test the tpm8-u-boot-432 on that "Cubietruck3" and is currently in limatester-loop #4 (also with 1000MB instead of 100MB) and still running. I can test the whole day. I moved the InfluxDB to a Intel-Nuc (also because of 64bit).
Further plan is:
- let it run with 432-u-boot for a while
- try 432-u-boot on "Cubietruck4" and see if limatester starts at least :-)
- test 432-u-boot also on "Cubietruck5" to see if this works too
Ingo F
-
ok, will test with reduced speed first, and I plan to do it on at least 2-3 of my cubietrucks ... just to see if it is really "rare" or not
Then I can decide where I can test the original clock-speed one
So stay tuned ...
-
Status: Prepared new sdcard with armbian 5.25 Legacy 3.4.113, only did apt-getupdate/upgrade afterwards
u-boot 5.25 (original unchanged) time to freeze:
Try 1: approx. 10 secs
Try 2: approx. 30 secs
Try 3: approx. 10mins
Try 4: approx. 10mins
Try 5: approx. 9 mins
@tpm8: can you provide a binary u-boot which is the same base as 5.25 but with the unchanged clock-speed? So that we can make sure that this is really the only difference? Or should I use your November u-boot?
-
I have a sd card here, so preparing that and using it makes sense ...
But I need to do that test then in the one machine where u-boot crashes on mainline and I can not use the new cubietruck because it did not freeze there so far. But with additional sd card I can do it that way forshort perids of time (db values are cached for some hours if db server goes down ... but overnight will not work for now :-) ).
Ingo F
-
Ok, then I will prepare a legacy image on a new ssd card later and switch sd cards for testing :-)
-
@apollon77 - If I understand it correctly, you have never used the lima-memtester stress test, which is specifically designed to quickly identify DRAM problems/misconfigurations. You might want to give it a try, especially considering that you have a nice set of 4 boards.
The 4th just arrived some days agi and is not deep integrated in my home automation stuff where all the others are used, so with that new one I re now able to do dome deeper tests (with the others it was no real option without breaking parts of my home automation ;-) )
I found http://linux-sunxi.org/Hardware_Reliability_Tests... will try it ...
Update: Sorry, I need support ... I use Mainline kernel from Armbian 16.04 (Xenial) default image:
root@cubietruck5:~# ./lima-memtester 100M This is a simple textured cube demo from the lima driver and a memtester. Both combined in a single program. The mali400 hardware is only used to stress RAM in the background. But this happens to significantly increase chances of exposing memory stability related problems. Please remove 'sunxi_no_mali_mem_reserve' option from your kernel command line. Otherwise the mali kernel driver may be non-functional and actually knock down your system with some old linux-sunxi kernels. Aborted
I removed that line and rebuild boot.scr.
Reboot, next try:
root@cubietruck5:~# ./lima-memtester 100M This is a simple textured cube demo from the lima driver and a memtester. Both combined in a single program. The mali400 hardware is only used to stress RAM in the background. But this happens to significantly increase chances of exposing memory stability related problems. Failed to 'modprobe mali'. Aborted
root@cubietruck5:~# modprobe mali modprobe: FATAL: Module mali not found in directory /lib/modules/4.9.7-sunxi
Any idea? Do I need to change more ? Or is it a problem with mainline kernel ?
It is a problem that no monitor is connected?!
PS: Interestingly on one machine I still use armbian wheezy "legacy" ... There the most current u-boot 5.25 is more stable thenthe 5.20!
-
I have 4 cubietrucks bought on different timepoints on eBay from different people ... I had such crashes with the current u-boot on each of them!
So it would be very surpsising to name it "rare" :-)) (Or all affected were send to germany)
And to count the problem on memory would also make sense because it happens more often on the cubietruck where I use influxdb (highly memory based).
I run quite stable with u-boot 5.20 but also here i get freezes after weeks up to 1-2 months. But with all u-boots > 5.20 including 5.25 it crashes in hours or max 1-3days.
My testing status is:
I re-tested u-boot 5.25 with "performance" in /etc/default/cpufrequtils again on sunday. With this I had an auto-reboot (watchdog?) after 55mins and a freeze after 26h. So I now finally installed your u-boot and are monitoring :-) No reboot or freeze so far (but also only 19h so far :-) )
I would let it run till the weekend ... and if no freeze till then I could try "the same" build with the lower RAM-speed and could test it it crashes then earlier to verify your assumption
-
https://docs.armbian.com/User-Guide_Fine-Tuning/-->
How to upgrade from Ubuntu Trusty to Xenial??! Worked for me
-
I had found such infos also in some other forums, but tested around with various settings and still had the same freezes ... but depending on the outcome of the u-boot test I will try perfoemance in the place you said again
-
@tpm8: So uboot written:
root@cubietruck3:~# dd if=u-boot-sunxi-with-spl_20161122.bin of=/dev/mmcblk0 bs=1024 seek=8 530+1 records in 530+1 records out 543026 bytes (543 kB, 530 KiB) copied, 0.124085 s, 4.4 MB/s
rebootet ... time counts now :-)
-
I already tried to use /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and the other path's to play around and also tried "performance", but no difference. still crashes. Do you had success with solving such crashed that way?
I don't know if this file is used at all ?! "schedutil" is currently in there for GOVERNOR, but "ondemand" seems to be used really
-
Alright, then I try tomorrow :-) Hoped for this answer :-)
backup is created
-
@tpm8: What kernel you use? I unse vanilla (so "next" here, means kernel 4.9.7). I read that the "setenv bootm_boot_mode sec" is needed for sunxi-3.4 kernel ... so is your file compatible with my system at all?
-
Hm then I will just install and look at the results (if it boots again and afterwards) ... I have backed up my sd card already, so next (after childrens are in bed) I start ... and then I see how stable it is ... >5.20 crashes normally after 1-10h on this machine.
-
Cool, will try tonight. After booting successfully is there a way to see that the new u-boot was used to boot without looking at the console during boot (because the cubietruck where I can see if it worked with the InfluxDB on it is located in my cellar and no monitor there :-) )
-
I would be interested in how to disable WLAN ... I connected my cubietruck to my Amazon Echo Dot via Bluetooth because wanted to use the Echo Dot as Speaker and now I have distortion and clicks in the output and one idea is that WLAN interferes there ...
I use 5.25 vanilla kernel ... so also the 4.9. Any idea?
Cubietruck freeze after 1-3 days with 5.23 Xenial (uboot problem?)
in Allwinner sunxi
Posted
runs 12h now without errors or freezes, so here the DCDC3 change worked, I will now test the 384-DCDC3 if it is more stable