4 ms·
Common way to detect memory errors in practice (i.e. how it can easily beat you) is by compiling stuff, the bigger the better. When you see the famous Inte
by przemoc 14y ago
Common way to detect memory errors in practice (i.e. how it can easily beat you) is by compiling stuff, the bigger the better. When you see the famous
Internal compiler error
it may be caused by some memory problem.
A few years ago I was doing lot of Linux kernel builds. My desktop computer, which is Athlon 64 X2 4600+ and 2x GeIL PC2-6400 DDR2-800 C4 ULTRA DUAL CHANNEL (2x1GB each; 4GB total), was doing make -j6 (or -j8, don't remember now) of kernel one after another. After many many hours some builds started to failing with mentioned error. Let's say 1 of 4. I had to do it, so I was repeating make (automatically) till it succeeded, but later I fiddled with memtest86+. It was running day and night on all 10 tests (I believe that was test count back then) and something popped up finally (I wasn't checking it constantly) [1]. But you know what? When I switched to showing badram patterns later and the problem reappeared, it was red line without any pattern! I used to see some addresses and such whenever error was detected by memtest (or experience computer halt, etc.), but that time I had seen nothing - it was quite enigmatic. I've checked memtest sources and test 5 was filtered out from showing badram patterns as apparently not being reliable. I changed it (I've just found the changed sources on the disk and diffed it to the original release [2]), recompiled the memtest and run it again. I got badram patterns this time [3].
I needed BadRAM patterns to secure myself from being constantly hit by this memory problem, but I don't remember whether I used them in the end.
I still use this computer. No big compiles, no big problems, but sometimes I get the iffy feeling. :) I had a few BSODs since then and I believe they were caused by this memory problem. Haven't seen its manifestation for a long long time. Maybe my computer was simply overheated back then? Since then I'm much more into checksums than I used to be...
[1] http://i.imgur.com/RMhCOLM.jpg
[2] https://gist.github.com/przemoc/5250861
[3] http://i.imgur.com/jFHZkVA.jpg
- przemoc 14y agoAnother thing I don't really remember is that BadRAM thing. When I fiddled with it [1], memmap [2] was already there, but for some reason I wanted to use BadRAM or maybe I was unaware of it. BadRAM wasn't present for the kernel I was using, so I attempted porting it to my 2.6.32 one. In the end I haven't really tested it, I guess, had to move on with other things. Now I remembered something! Some time later I tried contacting Rick van Rein, thinking that maybe he would be interested in a new version of the patch, or rather he could review it and I would learn something, but I never got the reply from him. I hope my attempt isn't too embarassing, yet can be interesting for someone, so I just published my mail to Rick with the attached patch [3]. Feel free to show me how wrong I was in my poor "refinements" of the original patch! I would be more than happy (even though I'm not into kernel now at all) to get constructively bashed about it. [1] http://rick.vanrein.org/linux/badram/ [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/bad_memory.txt [3] https://gist.github.com/przemoc/5251104