Tweet
When running the Burnin software on dual core systems, the application disappears from the desktop. The RAM duty cycle is set to 100 with advanced test mode and CPU at 50. Various other combinations causes the same result. Seems to be linked with the memory test. You have to kill the process from windows task manager. I'm using Burnin 4.0, AMD Opteron dual core processors. Does Burnin support dual cores?
-
-
Yes, BurnInTest supports dual core. It would surprise me if the problem was related to dual core. We have not seen any problems during our testing and we should have seen similar problems on dual CPU systems.
But having said that, I don't know what the cause is.
Which exact version of BurnInTest do you have, from the about window? I assume you are running the 32bit version and not the 64bit version?
How much RAM is installed?
If you have a similar machine available, can you try the test on another machine, just in case it is just something like bad RAM module causing the problem.
How long does it take before the fault occurs (seconds or days)? Is this time constant or does it appear random (if you keep the BurnInTest settings the same)?
-----
David -
We have another server that we ran this on, with the same results. There's about 8 GB of memory 32 bit. The program stops running after a few minutes, sometimes seconds. We ran a few other applications without any problems. This seems to happen only to Burnin.Comment
-
Again, which exact version of BurnInTest do you have, from the about window?
As an experiment can you see if this happens with just the memory test running.
If you have 8GB in a 32bit machine, most of it will never be used. 32bits of address space is equal to 4GB. Then from this 4GB the operating system takes 1GB on servers or 2GB on desktops. Leaving at most 3GB for an application to use and 4GB of RAM wasted.
To use more than the 3GB (2GB on desktops) you need to use a special, very rarely used, programming technique known as AWE.
BurnInTest uses AWE. But out of the 100,000 of other Windows programs on the market we are only aware of a couple of other application that do this, (e.g. SQLServer & Oracle).
So it is possible you have some hardware / system issue in this area. But it is also possible that we have a bug in BurnInTest at or beyond the 8GB level. When we wrote this code it was impossible to test with 8GB becuase motherboards that supported 8GB were not available.
We'll investigate the issue a bit more on our side.
--
DavidComment
-
The build version was out of date. We downloaded and ran the latest, build 1030, and Burnin does not unexpectedly disappear anymore. However, when running the Advanced\Torture memory test with the CPU Math test to 50, Burnin gives an Access Violation error.Comment
-
As an experiment can you see if this happens with just the memory test running.
How long does it take before the fault occurs (seconds or days)? Is this time constant or does it appear random (if you keep the BurnInTest settings the same)?
Can you lost the details of the Access Violation error. There will be a message like,
Access Violation error occured at address 0x0041234 reading 0x0012345.
------
DavidComment
-
With only the memory test running, Burnin is fine. The access violation error pops up within seconds. These are AMD Opteron dual core processors. The exact error is Access violation at 0x4D8351EC (tried to read from 0x4D8351EC), program terminated.Comment
-
Adjusting the Maths test under Preferences, the Floating point tests seems to be the culprit. Unchecking the Floating point results in no access violation error. Re-checking gives the error again.Comment
-
Wow, that's a surprise. I would have put money on the RAM test being the test that provokes the problem. So it is a good thing you eliminated the possibilities down to 1 test.
Having the floating point test causing a crash is a bit of a worry. The floating point test is code that we have been using for a many years now on many different machines. (We also have customers like HP, who use BIT to test their servers). No one has ever reported a fault like this. For it to crash means that it is likely the hardware is at fault.
We'll do a bit of testing on our dual core / dual CPU systems here, but I don't expect to find any problems. So you might need to consider if this is serious enough to consider replacing the CPU and/or contacting AMD.
------
DavidComment
-
It looks like the problem occurs on any 8-way system and not specific to dual core. The problem was duplicated on an 8-socket Intel box. When the number of processors were reduced (numprocs=x) in boot.ini, the error went away.Comment
-
Maths test - 8 or more CPUs
Thanks for the additional feedback. We have reviewed the software, and while we have not been able to reproduce the problem you are seeing, we believe that we have found a function that could potentially cause problems with the Maths test on systems with 8 or more physical CPUs (= #CPU packages x #CPU cores).
We have produced a new build of BurnInTest and believe that this will resolve your issue. BurnInTest V4.0 1031 can be downloaded from:
http://www.passmark.com/ftp/bitpro.exe
Please let me know whether this corrects the problem.
Best regards,
Ian (PassMark)Comment
-
Thanks for the quick response. No errors so far from the new build. The build seemed to have resolved the issue. Thanks.Comment
Comment