[Note] RAM may be vulnerable to high frequency row hammer bit flips

[userperson]

I see this error (showing that max speed row hammer triggers errors, where a slower test does not). But it doesn't show me any details (memory address, bits in error).

Improvement request: show these details even when showing the 'partial' warning note.

(using version 7.1, just downloaded)

[keith]

The details (error address, bits, etc) of the row hammer errors are logged in the MemTest86.log file under the EFI\BOOT\ directory of the USB drive.

In the Pro version, you can also specify the 'REPORTNUMWARN' parameter in the configuration file to record the row hammer errors that occurred in the first pass (maximum hammer rate) but not the second pass (lower hammer rate).

[userperson]

The details (error address, bits, etc) of the row hammer errors are logged in the MemTest86.log file under the EFI\BOOT\ directory of the USB drive.

In the Pro version, you can also specify the 'REPORTNUMWARN' parameter in the configuration file to record the row hammer errors that occurred in the first pass (maximum hammer rate) but not the second pass (lower hammer rate).

That's nice to know, but I usually run this from a cd (read only), or a read only flash drive. Also note that this can cover up more serious errors.

I stand on my request for improvement, show the details for this error on screen.

Also the other memtest (the one where the author is MIA) has a summary mode that shows bits in error and range and which test failed without needing to show each error. Any chance we can get an option similar to that in this memtest?

[David (PassMark)]

CD drives are nearly dead. Like the floppy drive before it, for which we have already dropped support. If you want the logs then don't use a read only flash drive.

For normal errors the bit count is displayed on the screen. It is only for the row hammer warning we don't display the details. (it is nearly always a random 1 bit error for row hammer in any case).

[userperson]

CD drives are nearly dead. Like the floppy drive before it, for which we have already dropped support. If you want the logs then don't use a read only flash drive.

For normal errors the bit count is displayed on the screen. It is only for the row hammer warning we don't display the details. (it is nearly always a random 1 bit error for row hammer in any case).

The thing that bothers me is that a computer that is out of its mind with bad ram (or might be, who knows, that's why I'm testing it) will be mounting and writing to my filesystem I am using to test it. Right now I have a writeable flash drive which is no-longer bootable, did bad unmounts or ram corrupt it? Also, I have another EFI bootable partition on the drive, memtest decided to write most of it's log to that partition rather than the partition memtest resides on.

Memtest isn't going to write to my CD-R (disc closed), or create a new burn session by accident. My cd will always work unless I damage it.

Can we count the possibility of a bad unmounts, or mounting and writing to the filesystem while under the influence of bad ram as a bug in memtest 7.1? It's not like you can tell me not to use memtest on a pc with bad ram...

[userperson]

It turns out that the boot failure was due to memtest 7.1 filling my other (UEFI) bootable partition with it's log file (froze on a black screen). Both of these partitions have GPT attributes marking them read-only, memtest seems to ignore this GPT attribute... It would be nice for memtest to respect the read-only attribute.

[David (PassMark)]

The most common cause of bad USB flash drives is just the low quality flash memory used with the many cheap drives on the market. i.e. hardware failure & fake drives.

It is not impossible that a really messed up system might corrupt the file allocation table on the USB drive. But it is pretty unlikely. Further the consequences of corruption are nothing to worry about. If the drive is corrupt, just reload it with a clean image (from our download). It only takes a couple of minutes to recover the drive. We would suggest using a dedicated drive for MemTest86 however (the install process blows away any existing content in any case).

[userperson]

The most common cause of bad USB flash drives is just the low quality flash memory used with the many cheap drives on the market. i.e. hardware failure & fake drives.

It is not impossible that a really messed up system might corrupt the file allocation table on the USB drive. But it is pretty unlikely. Further the consequences of corruption are nothing to worry about. If the drive is corrupt, just reload it with a clean image (from our download). It only takes a couple of minutes to recover the drive. We would suggest using a dedicated drive for MemTest86 however (the install process blows away any existing content in any case).

This flash drive is just fine, there is nothing wrong with it physically (I've done quite a few read/write tests on it with zero trouble). Hard for one to reload the flash drive if you don't have a working system....
It's a pain to waste a whole drive for a program that is a few MB.

Any chance memtest will be made to respect GPT read-only attributes, only write to it's own partition, and/or not simply freeze on a black screen if it doesn't have enough space to write it's log file?

[David (PassMark)]

You can purchase blank flash drives for $2.
It isn't worth us spending days of effort to save you $2. Sorry.

[userperson]

You can purchase blank flash drives for $2.
It isn't worth us spending days of effort to save you $2. Sorry.

It's not a cost thing, I just don't want to carry one flash drive for every single bootable software I might need.

What about the out of space for the log file so freeze up bug?

[David (PassMark)]

MemTest86 should be OK if it can't write to the disk (because it is full, or it is read only CD).