On 9/19/06, Frantisek Dufka <[EMAIL PROTECTED]> 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 time. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
