On Sun, 11 May 2014 22:47:03 +0200 Hans de Goede <hdego...@redhat.com> wrote:
> Hi, > > On 05/11/2014 12:31 PM, Siarhei Siamashka wrote: > > On Sun, 11 May 2014 10:36:25 +0200 > > Hans de Goede <hdego...@redhat.com> wrote: > > > >> We've several bug reports indicating that this causes stability issues, > >> so lets just drop it. > > > > I'm afraid that the reporters still have not done their homework > > properly. And suspect that the FAST_MBUS just happens to be the last > > straw to break the camel's back on slightly unstable systems. > > Well at least Oliver has done quite a bit of testing, with dcdc3 set > to 1.3V not only in u-boot but also in the fex file. I don't quite trust the tests, which need tens of hours to run before detecting a problem. The main issue here is that we may have a significant variance in the problem detection time (let's say, something between 10 and 30 hours for example). And if the person running the test is having some expectations (like assuming that lower MBUS clock provides better stability), then this person may stop some of the test runs prematurely and come to biased conclusions. Also we need to confirm that the fex changes have really taken effect. It is possible to grep the dmesg log for "buck3" string after booting up to find the dcdc3 voltage there. > Oliver, can you retest your cubietruck breakage with FAST_MBUS, with > the dcdc voltage traised to 1.425 V in u-boot + Siarhei's fex file > changes he send earlier to day, and see if your FAST_MBUS triggered > regression then goes away? > > > They first should try the updated fex files with dcdc3 set to 1.3V > > https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04662.html > > And also run https://github.com/ssvb/lima-memtester/ before and > > after the dcdc3 change. Not having the sunxi-3.4 kernel is not a good > > excuse! It should not take too long to try it. > > > > The lima-memtester program exposes dram reliability issues at roughly > > ~50MHz lower dram clock speeds than the other exclusively CPU based > > tests. If somebody is even able to notice problems after tens of hours > > of unpacking tarballs, then lima-memtester should expose the same > > problem in a matter of a few minutes (or even a few seconds). > > > > This may be partially explained by the "as soon as mali works noise > > on dcdc3 is much higher" jemk's observation: > > http://irclog.whitequark.org/linux-sunxi/2014-04-17#7155572 > > And partially by the fact that mali is very aggressively accessing > > memory. And this stresses the dram controller a lot. > > > > NAK, until we get better reports from the users. > > So what is your opinion no the 3th patch in this series which drops the > DRAM clk on the cubieboard2 to 432 MHz ? It's all very complicated. We also had a report about some A20 device not being able to run stable with dram clocked at 432MHz. Unless MBUS was also synchronously clocked at 432MHz (using PLL5 instead of PLL6): http://irclog.whitequark.org/linux-sunxi/2013-11-26#5690482 To some extent this conflicts with the two assumptions from your patch series ("432MHz is stable" and "fast MBUS is bad"). I would say that a bit more experiments are still needed. Also the whole patch series tries to address the issues, which are only specific to Cubieboard2 and Cubietruck. My take on this is the following. CubieTech is a commercial company selling these boards. They are interested in having high specs listed on their website (1GHz CPU, 480MHz DDR3). And they are also interested in having their boards running stable at these clock speeds, because they have to deal with the warranty and defective boards replacement. CubieTech is also linux-sunxi community friendly with some of their representatives available here (Huang Benn). So IMHO it's best if we take the settings that CubieTech considers appropriate for their hardware. If something is not quite right, then some corrections may be applied. But then again, IMHO it's best to keep CubieTech in the loop. -- 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.
