On 12-05-14 09:54, Siarhei Siamashka wrote:
On Sun, 11 May 2014 22:47:03 +0200
Hans de Goede <[email protected]> wrote:
Hi,
On 05/11/2014 12:31 PM, Siarhei Siamashka wrote:
On Sun, 11 May 2014 10:36:25 +0200
Hans de Goede <[email protected]> wrote:
We've several bug reports indicating that this causes stability issues,
so lets just drop it.
So not just me? jikes ...
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.
FAST_MBUS isn't supposed to fix stability problems though does it? It
offers a performance/speed boost (if stable), or atleast that was my
understanding.
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.
Well not quite a bit, I ran into the problem that my board became very
unstable after enabeling (and boosting the voltage). Otherwise it ran
perfectly fine (cb3 btw)
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,
Tests to see if it is stable? Absolutely. In my case, the board couldn't
even reliably boot and in the rare occasion it did manage to boot, a tar
xJvf job would crash due to errors after a few minutes or had corrupted
results.
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.
That is a fair point, that I may not have properly tripple checked ...
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?
I can in the next week or so; I"ll try to find Siarhei's Fex changes and
run it at 1.425 v
I don't recall if i kept the mbus in sync with the dram clock however.
Olliver
They first should try the updated fex files with dcdc3 set to 1.3V
https://www.mail-archive.com/[email protected]/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.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
