On Tuesday 19 September 2006 00:03, you wrote: [...]
> An interesting observation is that you need to gradually increase the size > of tested memory block. You need to start with testing 20MB first, then you > can try 25MB and so on up to 43MB. If you try to allocate and test a large > block of memory too early, memtester will just get killed. > > As for the failures, only the last two hex digits of faulty address always > contain 'a5' and it is a bit strange. I expected that offset within a page > would remain the same (I changed malloc to mmap in order to always allocate > memory buffer at a page boundary ) and unless pages have size equal to 256 > bytes, it is inconsistent. A small update. As I checked manual [1], a minimal page size for arm926ej-s cpu is in fact 1KB (tiny page). So inconsistency is now resolved. I have patched memtester to gradually allocate memory starting from 20MB to the size specified in a command line, so it is possible to check larger blocks without any extra tricks, you can download this modified memtester here: http://ufo2000.xcomufo.com/files/memtester-n770.tar.gz If you are going to try it (and it may be a really good idea), it should be run as root. The first argument is the size of memory block to be tested (in megabytes), the second optional argument is the number of passes. Here is a result of running it on my device: Nokia770-26:/media/mmc1# ./memtester 40 1 memtester version 4.0.5 (32-bit) Copyright (C) 2005 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffff000 want 40MB (41943040 bytes) got 40MB (41943040 bytes), virtual address=0x40128000, trying mlock ...locked. Loop 1/1: Stuck Address : testing 0FAILURE: possible bad address line at offset 0x009899a5 (page offset 1a5). Skipping to next test... Random Value : FAILURE: 0x3f770c1e != 0x3f770000 at offset 0x004899a5 (page offset 1a5). FAILURE: 0xc50dee8d != 0xc50d0000 at offset 0x004899a5 (page offset 1a5). Compare XOR : FAILURE: 0x0e119ff2 != 0x0e100000 at offset 0x004899a5 (page offset 1a5). Compare SUB : FAILURE: 0x7d558974 != 0x5ca00000 at offset 0x004899a5 (page offset 1a5). Compare MUL : Compare DIV : ok FAILURE: 0x7febf0e8 != 0x7feb0000 at offset 0x004899a5 (page offset 1a5). Compare OR : FAILURE: 0x7b69b068 != 0x7b690000 at offset 0x004899a5 (page offset 1a5). Compare AND : Sequential Increment: ok Solid Bits : testing 1FAILURE: 0xffffffff != 0xffff0000 at offset 0x004899a5 (page offset 1a5). Block Sequential : testing 1FAILURE: 0x01010101 != 0x01010000 at offset 0x004899a5 (page offset 1a5). Checkerboard : testing 0FAILURE: 0xaaaaaaaa != 0xaaaa0000 at offset 0x004899a5 (page offset 1a5). Bit Spread : testing 0FAILURE: 0xfffffffa != 0xffff0000 at offset 0x004899a5 (page offset 1a5). Bit Flip : testing 0FAILURE: 0x00000001 != 0x00000000 at offset 0x004899a5 (page offset 1a5). Walking Ones : testing 0FAILURE: 0xfffffffe != 0xffff0000 at offset 0x004899a5 (page offset 1a5). Walking Zeroes : testing 0FAILURE: 0x00000001 != 0x00000000 at offset 0x004899a5 (page offset 1a5). So faulty address is always reported to have offset 1a5 within a page on every run. Now the next thing to do is to identify physical address for use with BadRAM kernel patch. > I also wanted to detect physical address of a faulty memory region. I tried > to open '/dev/mem', read it one page at a time and compare its content with > the data from a faulty page. Unfortunately this does not work on Nokia 770 > and segfaults on reading from '/dev/mem'. The same code works fine on > desktop x86 pc and has no problems identifying physical address for any > page. Test programs were always run as root. I would really like to hear something from Nokia regarding this problem. There may be a few other devices with faulty memory considering some browser crash reports, reboots and instability for some people, a possible example can be seen here (though the reporter did not run the memory test as adviced): https://garage.maemo.org/tracker/index.php?func=detail&aid=84&group_id=54&atid=269 That's not a tragedy and software solution can probably resolve this problem. As you know, bad blocks are common for flash and jffs2 file system handles this issue. RAM can be probably treated in a similar way by using something like BadRAM kernel patch [2] [1] http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf [2] http://rick.vanrein.org/linux/badram/ _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
