Messages in this thread | | | Date | Tue, 2 Nov 1999 15:53:57 +0100 | From | Jamie Lokier <> | Subject | Re: Perform minimal RAM test at boot |
| |
Richard B. Johnson wrote: > At one time I was concerned about cache-effects so I wrote a unique word > to every possible page in RAM (4GB), then attempted to read them all back. > The problem is that many/most/all? PCs don't properly decode 4GB so I was > trashing code and stack. The solution was to do as stated. Just ignore the > cache. It works.
Adding a single `wbinvd' instruction at the right place is a simple instruction that would actually work *according to the official docs* :-)
> If you were to read/write every byte/word/whatever in > memory sequentially, it would not work. Only the cache data would be > modified and you would subsequentally read from the cache. Just try > it.
That's right. You've noticed that the cache _usually_ gets very involved in sequential accesses, and _usually_ keeps out of the way in isolated page-striding accesses. However it is not guaranteed to do so, may not do so on some motherboards (L2 cache policy), and most importantly: I believe it does not do so with the latest x86 CPUs.
However, `wbinvd' is specified to work.
> Another thing to consider is that offsets in ix86-land are signed! > Using [EBX] will address 4GB, but [buffer + EBX] will not. If EBX = > 0xffffffff, (-1) it points to 1 byte below 'buffer'. This is something > to remember if you are trying to write 'cute' code. This is also something > to remember if you are relying on 'C' to compute the address. I strongly > suggest you find the RAM in assembly, not 'C'.
Where you expecting buffer+0xffffffff to point to some mysterious address in an alternate universe or something?
This case has nothing to do with signedness, and everything to do with the address being restricted to 32 bits before going through the segment and page mappings. 'C' handles this just fine.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |