Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,835 of 4,675    |
|    James Harris to Terje Mathisen    |
|    Re: x86 memory testing - dealing with ca    |
|    05 Apr 19 19:37:57    |
      From: james.harris.1@nospicedham.gmail.com              On 05/04/2019 08:04, Terje Mathisen wrote:       > James Harris wrote:       >> Anyone know how portably to test an x86 PC's memory? I found it more       >> challenging than it first appears because of the potential presence of       >> external caches.       >>       >> The basic idea is to follow a simple process of       >>       >> 1. Write all ones, flush caches and read back.       >> 2. Write all zeroes, flush caches and read back, leaving RAM zeroed.       >       > You have of course considered Rowhammer and similar attacks? I.e. the       > actual pattern of access has been shown to cause errors in otherwise       > perfectly OK memory chips. Your basic all-1 / all-0 tests will       > _never_trigger these kinds of issues.              Have to say I haven't looked at any of that, yet. The idea is just to       see if the basic idea is feasible ATM. If I got to the point of how to       test memory properly I'd take a look at what memtest86 does... and try       to find the faster of the tests because it seems as though it can be       quite slow.              I do have a DIMM which has a fault - which makes it excellent as a test       case. Curiously, when the DIMM was in use the computer did not detect       the fault on boot. Nor did memtest86 detect it with most of its tests.       IIRC it first showed up in memtest86's random test ... which, again,       makes it a very good test case.              Incidentally, before I found that the DIMM was faulty and replaced it I       kept getting odd errors in mysql databases. But errors could have been       introduced in other files which I have not noticed.              >>       >> Part of the trouble is in the definition of the instruction to flush the       >> caches.       >       > The dead simple approach is to just write at least 4 times as much RAM       > as your maximum cache size, in that case you can be pretty sure it has       > all been written by the time you get back to verify.       > :-)              Any particular reason for 4? And what about reading to overfill the       cache, rather than writing?                     --       James Harris              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca