[maemo-developers] [maemo-developers] defective memory? (was: problem with dspmp3sink)

From: Siarhei Siamashka siarhei.siamashka at gmail.com
Date: Tue Sep 19 15:42:13 EEST 2006
On 9/19/06, Frantisek Dufka <dufkaf at seznam.cz> wrote:

> Just few ideas:
> software - bug is swapping/pagefault code?, bad ram timings?, too high
> CPU clock?

That's an interesting idea, It seems to be worth trying to downclock
the device and check if it improves stability. Does anybody know how
to do this?

> hardware - high power requirements - does it happen more when brightness
> is high or mem tester is run in ssh over wi-fi?

I run all my tests from ssh run over wi-fi. Will try some other
combinations later.

> Just tried with no application running, 20MB run fine, 30MB run very
> slow so it was probably swapping to card a lot. Turned off swap and
> could go only to 25MB.

The test locks memory immediately after allocation (man mlock), so it
should not swap pages out of RAM, and that's why it requires to be run
as root. As for memory limits, I tried to explain in one of the
prevoious posts, initially the tester can't allocate more than ~20MB
of memory. But the next time you launch memtester, it can allocate
25MB, so increasing memory allocation size in small steps allows it to
allocate up to 40MB in the end with swap turned off! Probably the
system sees that more memory is required and begins to stop some of
the unneeded services to free memory (that's just only a guess,  did
not do much experiments here yet). It can't do that fast, so if you
request 40MB too early, it will fail. Did you run memtester with my
last patch? It contains this gradually increasing allocation size
trick automatically, so you don't need to run memtester many times and
can specify 40MB at once. Of course you should not run any other
application at the same time :)

> Test went fine, no errors. Done over bluetooth
> connection with full brightess on, battery almost full. Will try when
> battery is low (over wi-fi at home).

In my tests this error is also not always reproducible. If I could
identify physical address of a bad page (the system should have
properly working /dev/mem for this), I could collect some statistics.
For example I could check if its physical location is always the same
and whether supposedly successful tests did actually allocate this
part of memory.

Surely it would be much better if memtester could access (almost) all
the physical memory at once. Otherwise it can't provide reliable and
trustworthy results. Probably boot time memtester similar to memtest86
that runs before the system loads can do this work best, but I wonder
if it is easy to access framebuffer to print some results from it. One
more (weird) idea is to try adding some syscall for allocation of
physical memory at any address (moving its original content to some
other place if it is occupied), so it would be able to access and test
(almost) all the physical memory while running the system at the same

More information about the maemo-developers mailing list