Home » Support » BurnInTest Linux FAQ

BurnInTest Linux V2.0 FAQ

Last updated: 20/November/2008

Q. I have downloaded BurnInTest for Linux, how do I install it?
When you download BurnInTest, you should see "bitlinux.tar.gz" on your desktop. If you have changed
your default download location, go to the download folder. Most Linux desktop environment should
uncompress ".tar.gz" files through it's Archive Manager when you double-click on the icon and present
you with a window of its contents. Click on "Extract" and select your destination folder that you want to
install BurnInTest for Linux. After which, you should see a folder named "burnintest" in the destination folder.
Your software is now installed and ready to be used.

Note: If you want to use the command line, "tar xvfz bitlinux.tar.gz" should uncompress the archive and leave
you with a folder named "burnintest" in the current working directory.

Q. I have successfully installed BurnInTest, how do I launch the application?
In most cases, double-clicking on the "burnintest" icon in "burnintest" folder will launch BurnInTest application.

Note: In some systems, because BurnInTest searches in the current working directory for certain files,
this approach will not work because the default working directory is your home directory when you double-click
on the application's icon. If your system behaves this way, launch BurnInTest Linux from the command line.

Q. How do I launch BurnInTest Linux from the command line?
Launch the "Terminal" program and change your current working directory to "burnintest" by typing
"cd path_to_burnintest_folder" (There is an easy way to copy path by dragging the burnintest's icon into the terminal).
To be sure you have changed your working directory to "burnintest" folder, issue a "pwd" command on the command line.
This will print the path of the working directory. In this case, "path_to_burnintest_folder" should be the output. There are 32bit and 64bit folders in the burnintest folder, cd to the appropraite one and type ./bit_gui_x32 or ./bit_gui_x64 to launch the GUI version or ./bit_cmd_line_x32 or ./bit_cmd_line_x64 to launch the command line version.

Q. How can i make a live boot CD/USB?
Please see the guide BurnInTest Linux - Live Boot with Slax.

Q. Nothing happens when I double-click on BurninTest icon.
Try launching BurninTest from the command line as that will output start-up error messages on the terminal console. Refer to "Q. How do I launch BurnInTest Linux from the command line?" to see how you can do that.

Using the "ldd" command on the BurnInTest executable will also display any missing libraries required, which will need to be installed before BurnInTest can be run.

Newer versions of KDE (than 3.3) may not have FAM (File Alteration Monitor, libfam) installed, such as in distributions like Kubuntu 7.10. FAM will need to be installed before the GUI version of BurnInTest can be run.

Q. I get "segmentation fault" error when I try and run BurnInTest Linux from the command line before any
tests were started. What should I do next?
BurnInTest Linux logs to a file called "debug.log" when the application starts up to help us identify roughly
where the application crashes. This file is in the same folder as the burnintest executable. Please e-mail this file
to Click to send mail (JavaScript required) so that we can help in resolving this issue. Please also include your system's
profile in the e-mail as there are helpful to us. It could be (but not limited to):

i. Which Linux distribution you are using?
Example: Mandrake, SUSE, Fedora Core 3, etc...

ii. Which kernel version?
Example: 2.6.9, 2.6.11, etc...

iii. What CPU are you using?
Example: Intel, AMD, etc...

iv. Is it 32-bit or 64-bit OS?
v. Is it 32-bit or 64-bit CPU?

Q. I am getting "error while loading shared libraries: libxxx.so.x: cannot open shared object file:
No such file or directory?" error when I launch BurnInTest Linux from the command line, why?
This happens when the loader (/lib/ld-linux) is not able to find the library in the dynamic library search path.
If you get this error, it means certain shared libraries are missing from your system. To be sure the library is
really missing, try to look for the missing library with your system's "Find files/folders" tool or you can do a:
# find / -name 'libxxx.so.x'
from the command line (Note: The single quote around the missing library name is needed.)
Alternatively, you can do:
# ldconfig -p | grep libxxx
to see if the library is in the linker library cache (/etc/ld.so.cache).
Library files are usually in the /usr/lib directory.

If you are running on 64-bit kernel, your system will probably have 2 sets of library, one for 32-bit (/usr/lib)
and one for 64-bit (/usr/lib64). BurnInTest should be linking to the 32-bit libraries (/usr/lib). If the library that
is missing is in /usr/lib64 BUT not in /usr/lib, your system will probably get this error.

The following lists the possible library files that might be missing and the reason why:

OpenGL library files:
- libGL.so.1
- libGLU.so.1

Reason:
1. You have an older version of OpenGL installed
2. You do not have OpenGL installed.

KDE library files:
- libkio.so.4
- libkdeui.so.4
- libkdesu.so.4
- libkwalletclient.so.1
- libkdecore.so.4
- libDCOP.so.4

Reason:
1. You have an older version of KDE installed
2. You do not have KDE 3.2 installed.

X11R6 library files:
- libXext.so.6
- libX11.so.6
- libSM.so.6
- libICE.so.6
- libXrender.so.1
- libXxf86vm.so.1
- libXi.so.6
- libXrandr.so.2
- libXcursor.so.1
- libXinerama.so.1
- libXft.so.2

Reason:
1. You have an older version of X11 installed
2. You do not have X11R6 installed.

Please e-mail us at Click to send mail (JavaScript required) if you encounter such error messages. Building BurnInTest Linux
with an older version of KDE (hence supporting older versions of KDE) is something that we are exploring to
enable BurnInTest Linux to reach a greater audience.

EXPERT ONLY: If there are libraries on your system that the linker is not picking up, a quick "fix" might be to
add the path to the library in /etc/ld.so.conf, then rebuild the linker library cache (see manual for "ldconfig" by
typing "man ldconfig" on the terminal window).

Q. After launching BurnInTest, I am getting an error message saying I do no have
read/write permissions on certain files. What should I do?
Because BurnInTest reads and writes to certain files (for example "savedkey.dat" and "LastUsed.cfg") when
the application starts up, you need to have read/write permission to these files. Make sure you have
read/write permission for these files. Do the same for "burnintest" folder.

Q. How can I change file permissions in Linux to read/write?
To change the permission of a file, you either need to be the owner of the file or you must have administration access
to the file (i.e. the system might prompt you to enter the administration password). Select the file's icon, then right-click and
select "Properties" to display the file's properties window (or CTL+I in Fedora Core 3)..

File properties

Change the permission to the ones displayed above.

To do so via the command line, from the Terminal, type "chmod 755 file_name".

Note: To change ownership of files/folders, use "chown user_name:user_group file_name".
(Type "man chmod" or "man chown" if you need assistance).

Q. Which Linux distributions have been tested which meet the system requirements?
The following distributions have been tested (or reported) that met these requirements (for version 1):

i) Fedora Core 3
ii) Fedora Core 4
iii) SUSE 10.0
iv) Gentoo 2005
v) CentOS 4.2
vi) Siemens Industrial Linux v9.0
vii) Redhat Enterprise ES 4
viii) SLAX 5.0.9 (using live-cd)
viii) Knoppix 4.0.2 (using live-cd)
ix) Fedora Core 5

To aid us in making the software better for you, please e-mail us at Click to send mail (JavaScript required) if
you have tested successfully in another Linux distribution or if you encountered issues with running
BurnInTest for Linux on your system.

Q. Which Linux versions have been tested with the Command Line version of BurnInTest?

CentOS 4.4 (32-bit)
CentOS 4.5 (64-bit)
CentOS 5.0 (64-bit)
Debian 4.0 (32-bit)
Fedora Core 3 (64-bit)
Fedora Core 6 (32-bit)
Redhat EL 4.0 (64-bit)
Redhat EL 5.0 (32-bit)
Ubuntu 6.06 LTS (32-bit)

Q. Which 32bitLive CD/DVD version of Linux have been tested with BurnInTest?

Fedora 9 i686 KDE
CentOS 5.1 i386
Suse 10.0 DVD
Kubuntu 7.10 dvd i386 (Only the command line version runs due to missing FAM library)
SLAX 5.0.9 (live-cd)
Knoppix 4.0.2 (live-cd)

To aid us in making the software better for you, please e-mail us at Click to send mail (JavaScript required) if
you have tested successfully in another Linux distribution live-cd or if you encountered issues with running
BurnInTest for Linux on your system.

A list of Linux distributions that BurnInTest for Linux have been tested successfully can be found here.

Q.Can I run BurnInTest for Linux if I am booting my Linux distribution from a CD/DVD?
Certain Linux distribution provide a live-cd/dvd that allow you to boot from without installing it onto your hard-drive.
If you intend to run it this way, please note the following:

i) See below about running the CD test in a Live CD envirnoment.

ii) Because the file system is mounted temporarily, all files written will be lost if you reboot the machine.
If you want to keep a copy of the logs, please copy it to a network drive or to a USB/FireWire drive.

Q. How do i run the CD test in a Live CD environment?
 Because BurnInTest Linux's CD/DVD test defaults to using "PassMark Test CD/DVD", if you intend to test the CD/DVD
drive that is holding the live-cd/dvd, please choose either the "Data CD read and verify" or the "No CD in Drive" test
method. For a description of what these test means, please refer to the help file. However, if you have 2 CD Drives
and you also have a PassMark Test CD/DVD, you can choose to test "PassMark Test CD/DVD" for the 2nd drive.

Some live cd's (like Slax 6) hide the current mount point of the cd (to something like /mnt/live), in these cases you will need to either manually mount the cd drive so it is mounted at the normal mount point (eg /mnt/hdc). You can also boot most live cds in a mode that will copy the cd to RAM and free up the drive, then you can cycle the cd try after booting to auto mount the cd or do it manually.

Q. Is the Windows version of BurnInTest included when I purchase BurnInTest for Linux?
No, they are 2 separate commercial software products and have to be purchased separately.

Q. Is there a command line (non-GUI) BurnInTest Linux?
Yes, the command line version is including in the BurnInTest Linux download.

Q. My License key does not seem to work.
Both the User Name and Registration Key must be correctly entered before the software turns itself
into the registered version. See this step by step guide for help.

Note: If you are an existing BurnInTest (Windows) user and have downloaded BurnInTest (Linux) for
trial purposes,keys from previous Windows versions will not work in the Linux version.
Purchase BurnInTest for Linux now to receive your new User Name and Registration Key for BurnInTest (Linux).

Q. The test run stops after 15 minutes, why ?
With the shareware version the tests will only run for 15 minutes at a time. After the software has been purchased,
the time is unlimited. Note that you can still get a much longer test run in the shareware version by clicking on the
Go button each 15 minutes After the software has been purchased the test duration can be increased from the,
‘Auto Stop’ field in the ‘Test preferences’ window.

Q. Can I get source codes for BurnInTest Linux?
No. We do not distribute source codes for BurnInTest Linux.

Q. I get "OpenGL is not installed or is not installed correctly" when I try to run 3D Graphics test, why?
Certain Linux distribution does not have Open GL as part of its package. Hence, you will need to download the
appropriate Open GL packages and install it. To get more information on Open GL, visit http://www.opengl.org.

Q. I get "Could not determine type of test CD/DVD" when I try to run CD/DVD test, why?
Please check that you have a PassMark Test CD/DVD in the selected CD drive(s).

Certain Linux distribution provide a live-cd that allow you to boot from without installing it onto your hard-drive.
Because BurnInTest Linux's CD/DVD test defaults to using "PassMark Test CD/DVD", you will get this failure message.
You can still test the CD Drive by choosing either the "Data CD read and verify" or the "No CD in Drive" test method.
For a description of what these test means, please refer to the help file.

However, if you have 2 CD Drives and you also have a PassMark Test CD/DVD, you should not get this error for the
2nd drive if you choose the "PassMark Test CD/DVD" for the 2nd drive.

Q. I get "File system not mounted" when I try to run Disk Test, why?
BurnInTest Linux does not perform mounting of drives/partitions. To run Disk Test on a drive/partition, it needs to be mounted.
To find out what devices are mounted, use "df -ahPT" on the command line. A sample output is shown below: 

[passmark@localhost src]$ df -ahPT
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/sdb2     ext3     20G  7.8G   11G  42% /
none          proc       0     0     0   -  /proc
none         sysfs       0     0     0   -  /sys
none        devpts       0     0     0   -  /dev/pts
usbfs        usbfs       0     0     0   -  /proc/bus/usb
none         tmpfs    506M     0  506M   0% /dev/shm
none   binfmt_misc       0     0     0   -  /proc/sys/fs/binfmt_misc
sunrpc  rpc_pipefs       0     0     0   -  /var/lib/nfs/rpc_pipefs
/dev/hdc   iso9660    701M  701M     0 100% /media/cdrom1
/dev/sdc      vfat    250M  178M   72M  72% /media/WOW___USB

Q. I get "Permission error writing to disk" when I try to run Disk Test, why?
Disk Test attempts to write to and read from the disk's partitions that were configured to run. Hence, we need to have
read/write access to these devices' partions. From the command line, use "cat /etc/mtab" to see what permission you
have on these devices. A sample output is shown below:

[passmark@localhost src]$ cat /etc/mtab
/dev/sdb2 / ext3 rw 0 0
none /proc proc rw 0 0
none /sys sysfs rw 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
usbfs /proc/bus/usb usbfs rw 0 0
none /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
/dev/hdc /media/cdrom1 iso9660 ro,nosuid,nodev,fscontext=system_u:object_r:removable_t...
/dev/sdc /media/WOW___USB vfat rw,nosuid,nodev,sync,noatime,fscontext=system_u:object_r...
/dev/fd0 /media/floppy vfat ro,nosuid,nodev,fscontext=system_u:object_r:removable_t...

It means the device /dev/sdb2 is mounted at "/" with "rw" (read/write permission) and is of file system type ext3.
This appear to be our start-up disk and will appear as "Hard Disc (sdb2) [/]" in Disk Test Preferences. /dev/fd0
is mounted at /media/floppy with "ro" (read only permission) and is of file system type "vfat". This appear to be
our floppy disk and will appear as "Media (floppy)" in Disk Test Preferences. Hence, if we are trying to run
disk test on "Media (floppy)" in this case, we will get this error.

Q. How does BurnInTest Linux determine what devices I have for Disk Test?
BurnInTest Linux checks 2 files to determine the devices that your system has. First, it reads /etc/fstab to determine
what kind of media types your system have and where it could be mounted. An example of /etc/fstab is shown below:

[passmark@localhost src]$ cat /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/tmp              /                       ext3    defaults        1 1
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
/dev/hdd                /media/cdrom            auto    pamconsole,fscontext=system_u...
/dev/hdc                /media/cdrom1           auto    pamconsole,fscontext=system_u...
/dev/fd0                /media/floppy           auto    pamconsole,fscontext=system_u...

From this example, BurnInTest is able to determine that your system have a Hard Disk mounted at "/" and is of
file system type "ext3". It is also able to determine that your system have 2 CDROM drives and a floppy drive.
(Note: This does not mean there is any media in the CDROM and floppy drives)

Next, to determine if your CDROM and floppy drives actually have any media in them, it checks the file /etc/mtab.
A sample of /etc/mtab is shown below:

[passmark@localhost src]$ cat /etc/mtab
/dev/sdb2 / ext3 rw 0 0
none /proc proc rw 0 0
none /sys sysfs rw 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
usbfs /proc/bus/usb usbfs rw 0 0
none /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
/dev/hdc /media/cdrom1 iso9660 ro,nosuid,nodev,fscontext=system_u:object_r:removable_t...
/dev/fd0 /media/floppy vfat ro,nosuid,nodev,fscontext=system_u:object_r:removable_t...

As you can see, we have found a read-only media in the floppy drive and a read-only media in /media/cdrom1.
If you now eject you floppy, /etc/mtab will be become:

[passmark@localhost src]$ cat /etc/mtab
/dev/sdb2 / ext3 rw 0 0
none /proc proc rw 0 0
none /sys sysfs rw 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
usbfs /proc/bus/usb usbfs rw 0 0
none /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
/dev/hdc /media/cdrom1 iso9660 ro,nosuid,nodev,fscontext=system_u:object_r:removable_t...

The entry for /media/floppy is now gone.

Q. Are PassMark USB 2.0 Loop back plugs supported in Linux.
Yes, from version 2 BurnInTest Linux includes a USB test that connects to PassMark USB2 plugs.

Q. Can I test my USB ports without a PassMark USB2 plug? How ?
Yes. The recommended way to test USB ports using BurnInTest Linux is to connect an external USB device
(flash drive or hard disk) via the USB port and test the connectivity with the USB device using the BurnInTest disk test.
Note: Similarly, to test external memory card readers/writers or other removable drives, it is recommended
that the BurnInTest disk test is used.

Q. How does BurnInTest work? Doesn't it just wear my computer out ?
Societies’ reliance on computers means that the cost of hardware failure can be enormous (and embarrassing).
BurnInTest thoroughly exercises PC hardware in the shortest period of time so intermittent or hidden problems
are found before they turn into a disaster. The typical life span of the main moving component in a PC, the
hard drive, is quoted at around 300,000 hours by manufacturers such as Seagate. The use of BurnInTest for a
6 to 12 hour period would thus have a no significant impact on the life of the drive. On the other hand, it would
allow manufacturing faults and intermittent faults to be detected in a controlled manner when the consequences
of failure are minimal.

Q. How long should I run BurnInTest for?
Not an easy question. In our opinion, the chances or finding a problem in the first hour are relatively high,
(the system gets hot, it's the first run across the disk / CD and the first use of some of the drivers).
Then every hour after that, the chance of finding a hardware problem drops significantly. The extra benefit
of doing 12 hours compared to 6 hours is thus probably not great. Other nice technique is temperature cycling.
All major manufacturers of electronic equipment do this, they have large ovens and fridges in which they test equipment.
The expansion and contraction of components and solder joins brings to light many problems. You could do
6 hours On, 6 hours Off, then 6 hours On, to get some limited temperature variation like this. NASA and the Army
load their equipment on to vibration machines, but this may be going too far for home / office use.

Q. Can I use the configuration files from Windows for BurnInTest for Linux?
No. The configuration files are not compatible between them. However, if you accidentally replaced
"LastUsed.cfg" with one belonging to Windows version of BurnInTest, you will get a dialog warning you
of an invalid configuration file and it will be overwritten with a default configuration for BurnInTest Linux.
It is hence not possible to load a configuration file belonging to BurnInTest for Windows.

Q. Can I test my FireWire ports ? How ?
Yes. The recommended way to test FireWire ports using BurnInTest is to connect an external hard disk
via the FireWire port and test the connectivity with the disk drive using the BurnInTest disk test.
Note: Similarly, to test external memory card readers/writers or other removable drives, it is recommended
that the BurnInTest disk test is used.

Q. Are there any precautions I need to be aware of when running BurnInTest Linux?
Yes. If you are running 3D or 2D Graphics Tests, it is advised that you turn off the system's screensaver.
More instructions and precautions for thorough and careful testing can be found here.

Q. My system crashed after X days of running BurnInTest but after a reboot was OK again.
See the general comments below about system crashes.

Q. My system is unstable. What can I do?
See general instructions for tracking down a fault

Q. Which tests require administrator privileges and why?
You need to have administrator privileges to run the following test:

1. Serial Port Test:
Linux character devices are usually root access only. For this test, we might be accessing
/dev/ttyS0 - /dev/ttyS63 depending on your configuration.

2. Parallel Port Test:
Root access is required to access memory location for the parallel ports.
(lp0 @ 0x378, p1 @ 0x278 or lp2 @ 0x3BC)

3. Memory Test:
As we are locking physical memory to prevent caching, root access is needed to call this function.

4. Network Test:
Root access is required to create raw sockets for the address family AF_INET.

Q. How do I know if I am logged in as a System Administrator or root user?.
When you type "echo $UID" on the command line, your user ID will be 0 (i.e. zero) if you are logged in as a root user.
Alternatively, you can use the command "id". An example is shown below:

[passmark@localhost src]$ echo $UID
500
[passmark@localhost src]$ id
uid=500(passmark) gid=500(passmark) groups=500(passmark) context=user_u:system_r...
[passmark@localhost src]$ su
Password:
[root@localhost src]# echo $UID
0
[root@localhost src]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)...

Q. I get the error, "root(admin) access needed to run this test" with the Network test.
If you don't have administrator privileges, you will get this error with the Network test. You need to have
administrator privileges to run this test. Because we are creating Raw socket for this test. Access to Raw Sockets
is granted on a per-transport basis. For the address family AF_INET, only administrators have the access
necessary to create Raw Sockets.

Q. I get the error, "root(admin) access needed to run this test" with the Parallel Port test.
If you don't have administrator privileges, you will get this error with the Parallel Port test. You need to have
administrator privileges to run this test because we are accessing memory locations for the Parallel ports.

Q. I get the error, "root(admin) access needed to run this test" with the Serial Port test.
If you don't have administrator privileges, you will get this error with the Serial Port test. You need to have
administrator privileges to run this test because we are accessing character devices /dev/ttyS0 - /dev/ttyS63
(depending on your configuration). Linux character devices are almost always root access only.

Q. I get the error, "root(admin) access needed to run this test" with the Memory test.
If you don't have administrator privileges, you will get this error with the Memory test. You need to have
administrator privileges to run this test because we are locking memory to prevent caching

Q. I don’t need to do any more tests, how do I uninstall BurnInTest ?
Delete the folder that it was previously installed in or delete the contents of the folder.

Q. I’ve lost my registration key, how can I get it back?
Mail us at Click to send mail (JavaScript required) telling us the name that was used to register the software, your E-Mail address, the name of the product (BurnInTest), and roughly the date when the software was purchased. We will mail your key back out to you.

Here are some general comments about occasional system crashes.
Problems can occur if your computer runs out of system resources because there is some process or driver that doesn't release memory, handles, semaphores, etc.. back to the operating system. After a long period of uptime the operating system runs out of resources and dies a terrible death. What can you do about this? Identify the offending software, if you can, and disable it. This can even be a bug in the operating system however.

Computer can have a Random Crash. What do we mean by this? Many things can bring down a computer. Typical things would be a spike on the power line, a strong burst of Electromagnetic interference (e.g. Mobile phones, electric motors, etc..). If your system is running at its limits due to overclocking or your components are running at the top of their temperature range, small external influences can push your system over the edge, resulting in a terrible death. If you believe in Chaos theory (and most scientists now do), then you also have to believe that computers will just crash unexpected from time to time, how often would depend on the design tolerances built into your hardware. What can you do about this?
- Do as the military do. Buy military specification computer hardware that has higher tolerances.
- Do what NASA does. Run 3 computers at the same time, expecting one to give the wrong answer or crash.
- Do what most big banks do. Run a hot standby system, that can takeover the job of the main computer in a few seconds.
- Do what the Telecommunications industry does. Buy equipment with N+1 redundancy and switch traffic off the faulty hardware. Almost all Telecommunications hardware also has a built in Auto-reboot function. Why? because they know it will eventually fail.

Timing issue. Some software / hardware bugs only show up in very very rare occasions. Classic examples of this are Hardware or Software Interrupts occurring in a critical section of code. What can you do about these types of bugs? Almost nothing as a user. They have plagued software since the first line of code was written they are very difficult problems to find and are almost never picked up during software testing. Problems can occur in Drivers, the operating system, your hardware, everywhere. As everyone is always on a tight deadline, endurance testing often doesn't make it into a software developers test plan.

Mundane program bugs are, of course, also a major cause of failure.

Fault finding
What follows is some hints on how to go about finding the cause of a particular system instability. (i.e. The system locks up, you get the windows blue screen, etc..). We don’t want to try and explain the steps involved in each of these processes, they are just points that may warrant future investigation.

Precautions for thorough and careful testing
For a hardware test to be useful several precautions need to be taken. Failure to take into account these factors may result in tests being misleading or other unwanted results.

Return to FAQ index

Copyright © 2009 PassMark® Software
International | Disclaimer | Refunds | Privacy | Contact Us