ChipProgrammer
15/01/2009, 06h38
I presently work at one of the memory manufacturers, writing memory testing programs. One of our production sites wrote to me some while back that MemTest86+ v2.01 was showing DDR2 800 memory in an AMD based system as running at 441 MHz. Knowing that the AMD processor cannot run DDR2-800 memory at such speeds under normal conditions, I had a look at controller.c to find out why this program was showing wrong speeds for AMD. When I fixed the code, I tried to make the corrected controller.c available for inclusion in future versions, but I was not able to contact Chris Brady at the email addresses I could find.
Well, neither Memtest86 nor Memtest86+ have my changes, so I installed Ubuntu 7.04 this week on some systems so I can build the executables. At the same time, I needed to fix some other problems with these programs. One problem is the limitation of 64 GB, yet PAE mode supports 52-bits of address space. The other problem that was of more immediate concern is the testing of E820 type 3 (ACPI data) memory regions, which can cause false errors with some BIOSes.
While I was in the code, I took the liberty of --
fixing some formatting issues in the source itself,
made it build mt86+_loader from the Makefile,
added support for more than the base PCI Bus for Intel Nehalem controllers,
added support for Intel Clarksfield and Auburndale memory controllers,
fixed the CPU family and model values, and the identification of processors based on these updated values,
identified AMD Rev10 and Rev11 processors/memory controllers correctly,
removing the 64 GB limitation, so we can test our servers with 128 GB or more,
and probably more changes than I can remember at the moment.
The full source with my updates can be found here (http://home.att.net/%7Echip.programmer/Memtest86/memtest86.211a.tar.gz). Although I did not upload the executables, or ISO images, I can if needed.
There are still issues that I have not chased down yet. For one, the code does not run on an Intel Eaglelake customer reference board. Something in the transition from 32-bit protected mode to 16-bit real mode (for E820 support) is broken in all versions of Memtest86/+ that I have been able to test. A second issue is the code does not appear to determine the actual front side bus speed versus the expected FSB, which effects the memory clock computations.
Memtest86/+ needs a major overhaul if it wants to be taken seriously. It lacks support for multiple memory controllers, it does not decode addresses to DIMM/side/row/column/bank/DQ, and it does not have multithread support needed to retrieve error registers from all controllers. Some side benefits of multithread support would be an increase in test speed, and increase in coverage because memory would be stressed differently and more frequently.
--
Chip
Well, neither Memtest86 nor Memtest86+ have my changes, so I installed Ubuntu 7.04 this week on some systems so I can build the executables. At the same time, I needed to fix some other problems with these programs. One problem is the limitation of 64 GB, yet PAE mode supports 52-bits of address space. The other problem that was of more immediate concern is the testing of E820 type 3 (ACPI data) memory regions, which can cause false errors with some BIOSes.
While I was in the code, I took the liberty of --
fixing some formatting issues in the source itself,
made it build mt86+_loader from the Makefile,
added support for more than the base PCI Bus for Intel Nehalem controllers,
added support for Intel Clarksfield and Auburndale memory controllers,
fixed the CPU family and model values, and the identification of processors based on these updated values,
identified AMD Rev10 and Rev11 processors/memory controllers correctly,
removing the 64 GB limitation, so we can test our servers with 128 GB or more,
and probably more changes than I can remember at the moment.
The full source with my updates can be found here (http://home.att.net/%7Echip.programmer/Memtest86/memtest86.211a.tar.gz). Although I did not upload the executables, or ISO images, I can if needed.
There are still issues that I have not chased down yet. For one, the code does not run on an Intel Eaglelake customer reference board. Something in the transition from 32-bit protected mode to 16-bit real mode (for E820 support) is broken in all versions of Memtest86/+ that I have been able to test. A second issue is the code does not appear to determine the actual front side bus speed versus the expected FSB, which effects the memory clock computations.
Memtest86/+ needs a major overhaul if it wants to be taken seriously. It lacks support for multiple memory controllers, it does not decode addresses to DIMM/side/row/column/bank/DQ, and it does not have multithread support needed to retrieve error registers from all controllers. Some side benefits of multithread support would be an increase in test speed, and increase in coverage because memory would be stressed differently and more frequently.
--
Chip