ropers wrote: > 2009/6/26 Jussi Peltola <pe...@pelzi.net>: >> memtest86+: it can prove it's broken, but if it doesn't >> find problems it doesn't guarantee there are none.
This is correct. > I've said this before, but I've yet to see faulty RAM whose problems > memtest86+ will not detect during a 24hr burn-in test. Sure, I've seen > faulty RAM that memtest86+ said was ok during a single-pass test, but > if you let memtest86+ run for 24 hours it'll probably find just about > any error. > > Of course, depending on your circumstances it may be more economical > to just chuck the suspect RAM instead of wasting 24 hours. And > granted, YMMV. But if anyone has ever seen any faulty RAM whose > problems a 24hr burn-in test with memtest86+ could not detect, I'd be > very interested in hearing that. How about this... Some years ago, Walmart had some Athlon-based "$200 PCs", they used SDRAM, 100MHz, IIRC. For giggles one day, I stuck some oddball SDRAM modules in one of them, and not too surprisingly, the thing failed to boot. In addition to being blatantly the wrong speed (66MHz), it was some really odd junk that didn't work in much of anything that used normal SDRAM of any speed. I didn't expect it to work, it confirmed my expectations; any OS that was loaded on the disk refused to boot very far before barfing all over itself with this RAM installed. Having enjoyed that part (yeah, I'm oddly amused), I figured running memtest86 would be an interesting test. Well, I'm somewhat disturbed to say that memtest86 had no problem "testing" all that junk^Woddball RAM, and told me it was all perfect. It may have been..but it certainly didn't work in that machine, and yet, it passed every diagnostic memtest86 threw at it for hours. I don't recall how long I left it cooking, but I know it was more than 24 hours, and I think it was for a few days before I needed that bit of shelf space and shut down the test. You can argue that memtest86 was correct that the memory itself was good, but since no other OS seemed to be able to make that RAM work in that machine, I don't think it is a very convincing argument -- that machine's memory subsystem was clearly broke, the diagnosis easy to confirm (swap RAM, system works, swap back, system won't boot). Yes, I think this qualifies as a memtest86 bug, as it missed something very basic, and maybe it's been fixed by now, but it still proves the point: passing diagnostics only means the diagnostics didn't find anything, it doesn't mean things are good. (years before that, I saw a great demonstration warning of this: one of the machines I sold and support had a very good internal diagnostic that included a looping RAM test, BUT if you installed the DIP (the old, traditional IC style RAM) with pin 1 not properly plugged into the socket, the system would pass the internal diagnostics very well as long as you wished to run them. You see, this machine's diagnostics tested RAM in 64k pages. Pin #1 on a 256kbit RAM chip happened to be used to pick which of the four(1) 64k pages were selected on the RAM chip, so the diagnostics happened to just test the same 64k bits of that chip four times, and said, "no problems found", even though the OS or apps would crash rather soon after booting. Fortunately, my then young eyes were good enough to spot the pin bent under the socket.) memtest86 is a very impressive memory diagnostic program, it does good things and does them well, but passing memtest86, as with any diagnostic, just means "no problem FOUND". Nick. (1) those thinking, "hey, one pin can't select more than TWO pages of RAM" need not try to correct me, I'm right, you don't understand how this stuff works. :) Hint: the chips had only 16 pins, including power, data, address, ground...and yet had an org of 256k X 1bit)
