From: james.harris.1@nospicedham.gmail.com   
      
   On 07/04/2019 07:24, Rod Pemberton wrote:   
   > On Thu, 4 Apr 2019 22:35:12 +0100   
   > James Harris  wrote:   
   >   
   >> Anyone know how portably to test an x86 PC's memory?   
   >   
   > What do you mean by "portably" here?  Reliable methods?  Multiple   
   > generations of processors?  Universal software sequence?   
   > All-of-the-above?   
      
   Certainly they would need to be reliable methods which covered multiple   
   generations of processors and took account of various types of installed   
   cache memory.   
      
   As for a 'universal software sequence', depending on what you mean, a   
   single approach would be ideal but it may be necessary to have the code   
   select different paths for different hardware. I say that because any   
   one method may not work on all machines.   
      
   For example, Terje suggested writing four times as much RAM as there is   
   cache. The problems I have with that are   
      
   * Why 'four' times?   
   * How to tell how much cache there is on such machines   
   * What if there's not four times as much spare RAM?   
      
   >   
   > Didn't we conclude on a.o.d. that some memory ranges can't be tested due   
   > to memory-mapped devices?  I.e., need to check E820h or create a memory   
   > map first.   
      
   Yes.   
      
   >   
   >> My first query, therefore, is how to ensure that a read of memory   
   >> after issuing WBINVD would get data from RAM rather than anything   
   >> which could still be in an external cache and not yet invalidated.   
   >   
   > If the cache has been flushed to RAM, the cache and RAM contents are   
   > the same.  So, you're asking how to detect if WBINVD is finished? ...   
   > If so, I think wolfgang answered that, i.e., he said WBINVD takes   
   > "forever" to complete.   
      
   It may take "forever" for the instruction to complete but according to   
   the documentation WBINVD may come back once external caches have been   
   told to flush themselves to RAM. As I read it, the instruction doesn't   
   necessarily wait for them to do so.   
      
   >   
   >> The second problem is for running on old i386 systems. They do not   
   >> have a WBINVD instruction.   
   >   
   > WBINVD is also a privileged instruction.   
   >   
   >> No problem, then? I don't think so,   
   >> because IIRC some i386 PCs were made with external caches.   
   >   
   > I've never heard of that.   
   >   
   > The 286/386s did have external FPU's, including the non-Intel Weitek   
   > math coprocessor.   
      
   I remember one Linux developer commenting on problems with 80386-based   
   PCs which had external caches. And although Google is not helping me   
   just now I thought Intel produced some external cache controller ICs   
   which could be used with the 386.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)