linux v5.0(1006) 64bit RAM test does nothing and fails

[Linus]

Hi,

I'm running the BurnInTest v5.0 (1006) linux 64bit version on a custom yocto live-stick and when I try running the 'Memory (RAM)' tests they don't seem to start and at the end it reports 0 cycles, 0 operations and 1 error. So far I've tried this on a HP probook i5 laptop and another workstation with the same results.

When doing these tests on an older yocto-version with BurnInTest v4.0 the memory-tests works as expected but I have no idea where to start looking for possible causes of this error.

Any ideas?

Kind regards, Linus

[Richard (PassMark)]

Are you running with administrator privileges. It is required to have administrator privileges to run the memory test because BurnInTest Linux will lock memory to prevent caching.

What is the error at the end?

If the error is reproducible, you can start BurnInTest in debug mode (with -d command line option) and send in the log.

[Linus]

Yes, it's run within a bash-script that is run as sudo. The script is just setting QT_QPA_FONTDIR and vblank_mode then starts the bit_gui_x64.

While the test is running the memory says 0 cycles, 0 operations and 1 errors. As soon as I stop the test, it says 0 cycles, 0 operations, 0 errors and the 'Last error description' is blank.

I've attached the debug.log

[Linus]

Based on the fact that the issue persists on multiple different computers I would guess the issue is software-related somehow. If I use the older version v4.0 on the same computers the memory-test works fine.

When installing BurnInTest v5.0, I noticed there are a couple more dependencies than mentioned on your website. Could this be case with the memory-test? Is there some significant change in the software/code between v4.0 and v5.0 relating to the memory-test that has some new dependencies that I'm not aware of?

My yocto-livestick is rather minimal so I would not be surprised if I'm missing some libraries but I did run

ldd bit_gui_x64

and it didn't report any missing dependencies.

Please tell me if there is something you want me to do to aid in the troubleshooting.

I'll try running the exact same version of BurnInTest v5.0 on a clean Ubuntu Desktop installation and see how it behaves which might narrow it down a bit.

Kind regards, Linus

[Linus]

Update: Running BurnInTest v5.0 on Ubuntu Desktop 22 after installing the required dependencies works as intended. RAM Memory test running as expected. This makes me lean even more towards software-related issue/missing dependency.

[Richard (PassMark)]

Thank you for the additional details and updates.

The memory testing is through a separate executable, memtest, located in the same directory. On a machine where BurnInTest Linux fails to run the memory testing. Can you run "ldd memtest" to see which libraires are missing?

There was an error noted in the debug log but it seems the error message was truncated (or the error message string was corrupt/bank). The error occurred around when BurnInTest would launch the memtest binary. (Does the BITErrorClassification.txt file exists in the directory?)

Aug 14 06:29:00 2023 - 42964 Memory test  Error -

Apologies, while the debug log contains some debug information, the trace activity log (when set to level 2) should contain more information on which step in the process the memory test got to before failing. If possible, please rerun the with trace activity set to 2 and post log.

[Linus]

Thank you for your answer, it lead me to find some other issues which I had to solve.

When you said memory testing is through a separate executable I found a fault in my yocto recipe that handles the installation of the burnintest that not all files in the bitlinux.tar.gz where included, namely the memtest, gpuramtest, BITErrorClassification.txt etc. I've now fixed all that but I'm afraid it didn't really solve the RAM memory test issue.

Instead of reporting 1 error during the test and then resetting when the test finished, it now reports no errors while the test is running but fails and reports 'No operations during test period' at the end.

I ran "ldd" with all the executable files I found in the directory but found no issues. I also did the trace level 2 log. It won't let me attach .trace-files so all the files are in the attached zip-archive.

[Richard (PassMark)]

Is there a Memtest.log in the folder as well, if so, can you provide it?

[Linus]

Not that I recall but I'll check again tomorrow and see if can produce one for you.

[Linus]

I'm afraid I get no memtest.log. Is there something else I need to do to make it create this file? I do get the BIT_log.log and BIT_log.trace but that's all.
I'm attaching a screenshot of the settings under the Logging tab.

(Even when running on Ubuntu, where the RAM memory test is working, I get no memtest.log file.)

[Linus]

I just discovered a minor difference in response when trying to execute ./memtest :

On the Ubuntu machine
Running:

./memtest

as normal user or as sudo results in:

Not enough command line arguments - exiting

On the yocto machine
Running:

./memtest

as normal user results in:

bash: ./memtest: cannot execute: required file not found

and running as sudo results in:

sudo: unable to execute ./memtest: No such file or directory

even though memtest is in the current working directory and is executable (chmod 755)

[Richard (PassMark)]

If the file exists, but returning No such file or directory, the possibly a necessary runtime component of the is missing. We haven't heavily used/tested on Yocto, so not quite sure. Possibly interpreter problem? What does it return when you run the command?

file memtest

Then check the interpreter exists e.g. "ls -l /lib64/ld-linux-*". If it points to another file, check that file exists as well.

[Linus]

Found the problem and solution!

Explanation:
Yocto is using /lib/ instead of /lib64/ so the yocto recipe that installs the burnintest sets the interpreter for the executable files using "patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 bit_gui_x64" during installation. This was done to both bit_gui_x64 and bit_cmd_line_x64 since version 4.0 of burnintest.

When running "file memtest" I realized it was referring to /lib64/ instead of /lib/. This applied to all the *new* executables added in v5.0 (advnet_endpoint, gpuramtest and memtest).

Solution:
Since v5.0 now has separate executables for advnet_endpoint, gpuramtest and memtest I had to edit the recipe to set the interpreter for these files as well.

I've only tried the RAM memory test so far and it works. I assume the other executables didn't work either but will be working now.

Thank you very much for your splendid support which led to this solution!