On Tue, 6 May 2014 12:34:45 +0300 Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> 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. And on the Cubietruck with Allwinner A20 I get: cubietruck ~ # ./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 SKIPPED 960 MHz SKIPPED 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 528 MHz ............................................................ OK 480 MHz ............................................................ OK 408 MHz ............................................................ OK 384 MHz ............................................................ OK 360 MHz ............................................................ OK 336 MHz ............................................................ OK 288 MHz ............................................................ OK 264 MHz ............................................................ OK 240 MHz ............................................................ OK 216 MHz ............................................................ OK 204 MHz ............................................................ OK 192 MHz ...................................... FAILED 180 MHz ............................................................ OK 168 MHz ............................................................ OK 156 MHz ............................................................ OK 144 MHz ............................................................ OK 132 MHz ............................................................ OK 120 MHz ............................................................ OK 96 MHz ......................................................... Which means that the test has spotted data corruption issues at 192MHz and deadlocked at 96MHz, even failing to finish. It is interesting to compare the fex files from the Cubieboard2 and the Cubietruck: https://github.com/linux-sunxi/sunxi-boards/blob/c36a1c2186b4/sys_config/a20/cubieboard2.fex https://github.com/linux-sunxi/sunxi-boards/blob/c36a1c2186b4/sys_config/a20/cubietruck.fex The Cubietruck uses "min_freq = 60000000", which means that it can try to go as low as 60MHz. While for the Cubieboard2 we have "min_freq = 400000000", which means that 400MHz is the lowest limit. Just like I suspected since a long time ago and recently reminded in [1], cpufreq is a reliability hazard in its current implementation used by the sunxi-3.4 kernel. This may explain some of the mysterious deadlocks experienced by the users, who are suicidal enough to run their A20 hardware with the 'ondemand', 'interactive' or 'fantasy' cpufreq governors. Unfortunately this also includes innocent bystanders, who are just using sunxi-3.4 defconfigs :-( 1. https://www.mail-archive.com/linux-sunxi%40googlegroups.com/msg03612.html -- 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.
