home bbs files messages ]

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