Version 5.x versus Version 2.2 question

[Comark Corp]

Hello,

We are currently using version 5.0 of burnintest, and use it for qualifying all new product as well as field returns. Problem is, we have a customer who is using version 2.2 build 1002 for their certification tests. Twice now, we have had systems come back where the customer's testing using v2.2 has caused the system to lock up/freeze within 75 to 90 minutes. Almost always at about 75 minutes for some reason or other, and I can reproduce the problem at our factory. We get the system back and run version 5.0 for 12+ hours with no problems. I know 2.2 is very old, could this be a software issue with version 2.2? If so, is there an free upgrade to a newer build that our customer could download where this bug was fixed?

FWIW, these are Nagasaki PICMG boards with i845 chipsets and Intel P4 2.8GHz/533 FSB processors, and have 512MB of memory. OS is Win2000 SP4.

Thanks.

[David (PassMark)]

There is a release history for BurnInTest here,
http://www.passmark.com/products/bit_history.htm
Version 2.2 came out in Feb 2001. So it is really old now.

We have changed a thousand things between V2 and V5 but if I had to pick one thing in V2 that would cause a lock up, I would pick the use of DirectX 3.

In V3.1 of BurnInTest we switched from DirectX 3 to DirectX 8. I don't think there would be a single video card manufacturer testing their video card drivers with Direct X 3 now. But this is just a guess. And there is no way we are going back to V2 software to test what is is really happening.

Upgrade information is available here,
http://www.passmark.com/support/upgrade/index.php
http://www.passmark.com/sales/upgrade/index.php

[Comark Corp]

There is a release history for BurnInTest here,
http://www.passmark.com/products/bit_history.htm
Version 2.2 came out in Feb 2001. So it is really old now.

We have changed a thousand things between V2 and V5 but if I had to pick one thing in V2 that would cause a lock up, I would pick the use of DirectX 3.

In V3.1 of BurnInTest we switched from DirectX 3 to DirectX 8. I don't think there would be a single video card manufacturer testing their video card drivers with Direct X 3 now. But this is just a guess. And there is no way we are going back to V2 software to test what is is really happening.

Thank you.

Using the info you gave me above for clues, I have done some additional testing and narrowing down, and have found that if I remove all of the tests except for the hard drive test, and set the hard drive duty cycle to 100% it will fail in only a few minutes at most with v2.2. I also noticed odd tearing and video anomolies in the hard drive test window.

At this point, I can substitute another PICMG motherboard into the system with the same exact board revision, BIOS revision, CMOS setup, and the the test will run flawlessly. Here's where it gets interesting - If I disable hardware acceleration on the "bad" board, the hard drive test runs without any problems! Would this still indicate a DirectX 3 issue? In other words, does V2.2 use DirectX 3 for just it's video tests, or all of its tests?

For our customer's sake, as there has been more than one system with this issue, I just need to know whether this is a hardware issue (as only some motherboards exhibit the anomoly) or whether the fault lies within BurnInTest V2.2 or DirectX 3.

Bottom line I suppose, would be that if it is a hardware issue, then I question why the latest version of BurnInTest does not find any problems with the system.

Thanks again for your time.

[David (PassMark)]

DirectX is only used for the 3D test (and the 2D video RAM test, in later versions of the software). But it might be that DirectX is initialized when BurnInTest starts up. I would need to go back and check the V2 code.

I can't come to any satisfactory conclusion based on the information you have provided.

If it was a simple hardware fault related to the hard drive or IDE interface, it should fail in a similar manner with V2 and V5. So it would not seem to be a (simple) hardware fault.

If it was a device driver bug or software fault, changing the motherboard for an identical unit should have no effect at all. So it would not seem to be a (simple) software fault either.

If it isn't software and isn't hardware, then there isn't much left to blame.

Given the confusing set of facts, I would attempt to do some additional testing to collect more data. Maybe you have wrongly attributed what was a random failure to a setting change that you made. Or maybe the problem is temperature related and swapping the motherboard fixed the problem only temporarily until the board heated up. Or maybe the problem is something very subtle. Maybe it is not the disk activity itself that is causing the crash, but the pattern of disk activity, or the EMI give off by a particaular pattern of disk activity. And the V2 pattern of activity is different from V5.

I short I don't have a good answer. Other than to say it appears inconclusive based on what we know and more testing might help.