7.1 vs 7.3 bug?

[electric_memory_ram]

Updated to 7.3 I note from the changes that hyper-threads are disabled (maybe increasing efficiency / memory stress). But now I notice long delays in starting the program (before the 10s countdown start) on the order of several minutes. Also when switching each test delay in the order of seconds to a minute or so.

Memory stress is now less since the program takes long breaks.


Another issue is that due to the occasional bad shutdown when memtest is in use, or using the flash drive in a system with bad ram the filesystem gets corrupt and I have to run chkdsk or recreate the image. I want logs, but I want memtest not to break itself during normal use. (this applies in general, not specific to 7.3)

[David (PassMark)]

for the delay can you send us a log file, which is written to the USB boot drive.

MemTest86 doesn't write to the disk very often, so file system corruption should be rare, even with random crashes.

[electric_memory_ram]

FYI, spent almost 30 minutes identifying street signs and cars for the CAPCHA to sign up here, only to miss the activation email. You really need a way to resend that without having to contact someone. Also I keep getting signed out before I can come back and post, it's like the timeout is less than 20 minutes.


aMemTest86.log is the log that memtest creates in the partition (call it partition N) you have memtest on and UEFI booted from (in the 'EFI/BOOT' directory of course).

bMemTest86.log is the log memtest creates in the partition N-1 (still in the 'EFI/BOOT' directory, partition otherwise empty)


Partition N got erased when I put 7.3 on.
Partition N-1 contains logs from to 7.1 to 7.3 (same computer).

I'm not sure why it doesn't leave everything it the same partition, off by one error?



Update: first the upload complained that I couldn't go over 4MB, so I compressed the log, now it says I need to keep it under 97.66 KB (that's awfully specific). Do you want to up the limit or should I split the archive?

[electric_memory_ram]

copy /b 1MemTest86.zip+2MemTest86.zip+3MemTest86.zip+4MemT est86.zip MemTest86.zip

To merge the files back together (if you are on windows anyway).

Also the attachment uploader got annoyed that the split files had a .00# extension, so I had to rename them. Also the uploader allows you to select multiple files at once (nice!) but it only actually attaches one of them...


Ugh... now it says I can only attach 3 files per post.

[electric_memory_ram]

Here is the last file part of the split file.


For some reason this forum seems like it's set to be extra annoying.

"upload that file, you are all set, no wait it's too big, compress it, no it's STILL too big, we have multiple size limits. You can't upload that file it has weird extension. No you can only upload 3 files from the 4 file split set."

What's next? "You used too many Js and Qs in your post (like a spammer), please fill out these 10 CAPCHAs, you have 120 seconds..." (strangely enough this is the first time in this thread anyone has actually used a J or a Q... that's unexpected)

[David (PassMark)]

90% of posts to the forum are spam unfortunately. It's Google's CAPCHA, most people just have to check a box. You must have looked like a Robot to Google or had your IP address abused in the past. Yes, the inactivity timeout was a bit short. I have made it longer now.

> 97.66 KB (that's awfully specific).

It is 100,000 bytes in KB.
We did ask for you to EMail us the file.

We didn't what uploads of arbitrary files or we'll end up with a forum full of virus laden executables from the spammers.

We also didn't need a 60,000 line log file. 500 lines should have been enough.

The log showed this the entire boot process was slow, not just 1 step in the process.
My guess is that is it a combination of slow hardware and a very slow USB drive. So slow it might actually be failing, which would also explain the file system corruption.

Try using a new fast USB3.0 flash drive if possible.

[electric_memory_ram]

I'd do one CAPCHA and it would ask me to do another, and another, and a few more, then it didn't like what I picked so I'd have to do one more. Then it would tell me it didn't like something I picked and I would have to fix that and start over with the CAPCHAs.

You said "send us a log file", you didn't say how. I notice (now) your anchor in the html of the link points to a non-existent anchor "#contact".

The hardware is far from slow, it has a i5-3230M (dual core) in it.

What are the required performance characteristics for a flash drive in memtest?

[David (PassMark)]

There isn't any minimum speed requirement for the flash drive.
But a USB3.0 drive in a USB3 port will be faster than USB2.0.

If the drive has hardware faults then this can also results in it being very slow.

[electric_memory_ram]

There isn't any minimum speed requirement for the flash drive.
But a USB3.0 drive in a USB3 port will be faster than USB2.0.

If the drive has hardware faults then this can also results in it being very slow.

I was looking for a minimum even just to say "this drive has x speed, and x speed is way too slow, or x speed is plenty fast enough".

I did find the problem, the last computer tested (omitted from the log) with bad ram had apparently corrupted the FAT for the filesystem on partition N-1 in some subtle way (fsck.vfat wasn't fixing/detecting it) so a quick format resolved it. The drive is now working flawlessly, and the test is working at full speed.

Is there any way to pre-allocate the log in chunks (256k?) so as to minimize writes to the FAT and therefore minimize quirky problems like this?

[David (PassMark)]

There isn't really any such thing as pre-allocation of a file (at least nothing that in anyway improves performance, or reduces writes).
What can be done is to buffer data in RAM then write bigger blocks of data. But this is exactly what you don't want for a debug log. You want a debug log to contain the last thing that happened before the crash / fault / lockup.

There isn't all that much information written to the debug log. MemTest86 typically takes a hour or so to run. The USB write time should be a couple of seconds during that hour (if the drive isn't faulty).

[electric_memory_ram]

No I mean reduce the number of writes to the FAT so that's less likely to be corrupted. If you pad the file in 256KB increments with nulls (changing the size and writing to the FAT) and then overwrite those nulls with log (as lines are added). The file will end with a bunch of nulls but you won't have to touch the FAT again until you get past the end of the pre-allocations of nulls.

As it stands now you have to touch the FAT ever time you write a new line.

I do understand you don't want to buffer a debug log in ram.

[David (PassMark)]

Doing this would end up writing a lot more data to the USB drive (nearly double) and also doing a extra disk seeking. Which would be slower overall. Even if there was a crash right at the moment of the FAT update, it should not lead to massive corruption.

USB drive failure was a common problem then it might make some sense, but it doesn't seem to be. No one else has encountered the problem as far as we know.

Which make me suspect it still might be a hardware failure causing the corruption.

[electric_memory_ram]

Doing this would end up writing a lot more data to the USB drive (nearly double) and also doing a extra disk seeking. Which would be slower overall. Even if there was a crash right at the moment of the FAT update, it should not lead to massive corruption.

USB drive failure was a common problem then it might make some sense, but it doesn't seem to be. No ones else has encountered the problem.

Which make me suspect it still might be a hardware failure causing the corruption.

The corruption has been very rare, the undetected effect of the corruption was what was causing my problem. It's all working fine now.

I don't care about a little more writing to the log file (if it is corrupt I should see that), what I was hoping for was needing to write to the FAT less often (less total written too), that way most corruption would be harmless corruption of the file contents.

Also seeking shouldn't be a problem on flash based media.

[electric_memory_ram]

I found one other mode of corruption. If the test freezes for some reason (usually poor hardware compatibility, misc other reasons) and the computer is shut off or the drive is removed it almost always results in minor FAT corruption. You would think that filesystem would be finished writing (flushed) more often than not and it would only have a small chance of doing this, not almost every time. Clean shutdowns of course don't have this issue (baring anything else going wrong).

[David (PassMark)]

If you are seeing this a lot, maybe try another model flash drive. Some might be better or worse than others in caching data on the stick (just speculation, it isn't something we have tested).