Hi Siarhei, Thanks for you great work (again), I had to throw out djpeg/cjpeg version check to make it work, here's my version.
root@debian:~/cpuburn-arm# echo `djpeg -v </dev/null 2>&1` Independent JPEG Group's DJPEG, version 8d 15-Jan-2012 Copyright (C) 2012, Thomas G. Lane, Guido Vollbeding Empty input file root@debian:~/cpuburn-arm# echo `cjpeg -v </dev/null 2>&1` Independent JPEG Group's CJPEG, version 8d 15-Jan-2012 Copyright (C) 2012, Thomas G. Lane, Guido Vollbeding Empty input file Here's the result from my cubieboard. Creating './whitenoise-1920x1080.jpg' ... done CPU stress test, which is doing JPEG decoding by libjpeg-turbo at different cpufreq operating points. Testing CPU 0 1488 MHz SKIPPED 1440 MHz SKIPPED 1392 MHz SKIPPED 1344 MHz SKIPPED 1296 MHz SKIPPED 1248 MHz SKIPPED 1200 MHz SKIPPED 1152 MHz SKIPPED 1104 MHz SKIPPED 1056 MHz SKIPPED 1008 MHz ............................................................ OK 960 MHz ............................................................ OK 912 MHz ............................................................ OK 864 MHz ............................................................ OK 816 MHz ............................................................ OK 768 MHz ............................................................ OK 744 MHz ............................................................ OK 720 MHz ............................................................ OK 696 MHz ............................................................ OK 672 MHz ............................................................ OK 648 MHz ............................................................ OK 600 MHz ............................................................ OK 576 MHz ............................................................ OK 528 MHz ............................................................ OK 480 MHz ............................................................ OK 432 MHz ............................................................ OK 408 MHz ............................................................ OK 384 MHz ............................................................ OK 360 MHz ............................................................ OK 336 MHz ............................................................ OK 300 MHz ............................................................ OK 288 MHz SKIPPED 264 MHz SKIPPED 240 MHz SKIPPED 216 MHz SKIPPED 204 MHz SKIPPED 192 MHz SKIPPED 180 MHz SKIPPED 168 MHz SKIPPED 156 MHz SKIPPED 144 MHz SKIPPED 132 MHz SKIPPED 120 MHz SKIPPED 108 MHz SKIPPED 96 MHz SKIPPED 84 MHz SKIPPED 72 MHz SKIPPED 60 MHz SKIPPED 48 MHz SKIPPED 30 MHz SKIPPED Overall result : PASSED I still have some cubieboards to test if you need. Here's a libjpeg-turbo package for debian wheezy/armhf user if they would like to test. https://drive.google.com/file/d/0B_3w0fkIKW4xTjVYSkVRVF9QOHc/edit?usp=sharing https://drive.google.com/file/d/0B_3w0fkIKW4xajBTQ1ZRaWIwUWM/edit?usp=sharing Clement On May 6, 2014, at 11:34 AM, Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > On Sun, 4 May 2014 11:36:10 +0300 > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > >> Hello, >> >> Yesterday I have been trying to debug what's causing the XFCE desktop >> background artefacts on my A10-Lime, which look like this: >> >> http://people.freedesktop.org/~siamashka/files/20140504/a10-l2-cache-fail-artefacts-in-xfce.png >> >> And narrowed them down to ARM Cortex-A8 L2 cache failures, which >> are reproducible when doing JPEG decoding: >> >> $ djpeg -v >> libjpeg-turbo version 1.3.0 (build 20130811) >> >> $ wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg >> >> $ djpeg A10-LIME.jpg | md5sum >> 691497bd2e5d36976c1ea3150de89df6 - >> >> $ djpeg A10-LIME.jpg | md5sum >> 6a874af750f92e1e3c019f2df7edf3f7 - >> >> $ djpeg A10-LIME.jpg | md5sum >> 297b98ba10233cbbcea2566e1c4fd7c7 - >> >> Please note that the md5sum of the decoded JPEG file is different for >> each run. >> >> There are other ways to reproduce it (the FFmpeg test suite can detect >> this problem too), but the djpeg test is very simple and fast to do. >> In the case if somebody does not have the djpeg tool from libjpeg-turbo >> in their distro, I have a static djpeg binary here for extra >> convenience: >> http://people.freedesktop.org/~siamashka/files/20140504/djpeg-static >> It has been built using: >> >> http://people.freedesktop.org/~siamashka/files/20140504/build-static-djpeg.sh >> >> On my collection of just three Allwinner A10 based devices, I get the >> following results with the libjpeg-turbo djpeg test (and the default >> CPU core voltage): >> A10-Lime - fails at 1008MHz (960MHz is fine) >> Mele A2000 - fails at 1152MHz (1104MHz is fine) >> Cubieboard1 - fails at 1152MHz (1104MHz is fine) >> >> Why is it likely related to the L2 cache? Because this problem goes >> away if we disable the L2 cache by adding something like >> mrc p15, 0, r10, c1, c0, 1 >> bic r10, r10, #(1 << 1) >> mcr p15, 0, r10, c1, c0, 1 >> to the code around >> >> https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-v3.4.86-r0/arch/arm/mm/proc-v7.S#L248 >> >> It is also interesting that sun4i and sun5i have different L2 cache >> latency parameters configured there. I have tried increasing the >> latencies in the L2 Cache Auxiliary Control Register, but these >> changes did not seem to affect anything. It looks like the only >> important factors are the CPU clock speed and the CPU core >> voltage (increasing it to 1.45V from 1.4V also fixes the problem >> on my A10-Lime). >> >> Anyway, with the sample size of just 3 devices, 33% of them appear to >> be unable to run stable at 1GHz and 1.4V core voltage. I wonder, how >> common is this problem in general? Are there any other Allwinner A10 >> devices failing the libjpeg-turbo djpeg test at 1GHz? >> >> Also it would make sense to run reliability tests for all the cpufreq >> operating points, because any frequency+voltage pair can be a weak link. > > Implemented an automated script for running tests at different > operating points: > https://github.com/ssvb/cpuburn-arm/blob/master/cpufreq-ljt-stress-test > > Only 1008MHz appears to be really problematic on my A10-Lime device. An > example of running it: > > lime ~ # ./cpufreq-ljt-stress-test > CPU stress test, which is doing JPEG decoding by libjpeg-turbo > at different cpufreq operating points. > > Testing CPU 0 > 1488 MHz SKIPPED > 1440 MHz SKIPPED > 1392 MHz SKIPPED > 1344 MHz SKIPPED > 1296 MHz SKIPPED > 1248 MHz SKIPPED > 1200 MHz SKIPPED > 1152 MHz SKIPPED > 1104 MHz SKIPPED > 1056 MHz SKIPPED > 1008 MHz . FAILED > 960 MHz ............................................................ OK > 912 MHz ............................................................ OK > 864 MHz ............................................................ OK > 816 MHz ............................................................ OK > 768 MHz ............................................................ OK > 744 MHz ............................................................ OK > 720 MHz ............................................................ OK > 696 MHz ............................................................ OK > 672 MHz ............................................................ OK > 648 MHz ............................................................ OK > 600 MHz ............................................................ OK > 576 MHz ............................................................ OK > 528 MHz ............................................................ OK > 480 MHz ............................................................ OK > 432 MHz ............................................................ OK > 408 MHz ............................................................ OK > 384 MHz ............................................................ OK > 360 MHz ............................................................ OK > 336 MHz ............................................................ OK > 300 MHz ............................................................ OK > 288 MHz ............................................................ OK > 264 MHz ............................................................ OK > 240 MHz ............................................................ OK > 216 MHz ............................................................ OK > 204 MHz ............................................................ OK > 192 MHz ............................................................ OK > 180 MHz ............................................................ OK > 168 MHz ............................................................ OK > 156 MHz ............................................................ OK > 144 MHz ............................................................ OK > 132 MHz ............................................................ OK > 120 MHz ............................................................ OK > 108 MHz ............................................................ OK > 96 MHz ............................................................ OK > 84 MHz ............................................................ OK > 72 MHz ............................................................ OK > 60 MHz ............................................................ OK > 48 MHz SKIPPED > 30 MHz SKIPPED > > Overall result : FAILED > > -- > Best regards, > Siarhei Siamashka > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
