Sys_basher is offered free of charge by Polybus Systems corporation under a BSD style open source license.
Polybus offers Intellectual Property including InfiniBand Link Layer and Transport Layer cores. Polybus also provides FPGA and ASIC design services.
Polybus is the leading supplier of InfiniBand cores for use in Xilinx 7 Kintex7/Virtex7 and Altera Stratix V FPGAs as well for ASICs. We offer SDR, DDR and QDR Link Layer and Target Channel Adapter Cores.
If you are looking for FPGA or ASIC design consulting or would like more information about our cores please contact Joshua Rosen email@example.com
, (978) 828-0944.
Sys_basher is a Linux hardware stress tester and diagnostic. It is designed to place a maximum load on a system by running memory, CPU and disk tests on all cores simultaneously. A typical time to run the full test suite on an iCore7 with 32G of RAM is about 5 hours, however you can increase the test time with the -ho switch, for example if you want to run sys_basher for at least 12 hours specify -ho 12.
The purpose of sys_basher is to determine if a system is reliable under load and to diagnose hardware failures. It's a good idea to run sys_basher on a new system before putting the box into service. For overclockers sys_basher is an excellent tool for finding the limits of your box.
When running sys_basher you should do it on a freshly booted system and you should kill all virtual machines. Sys_basher needs to grab as much of the RAM as possible to do the best possible job of RAM testing which is why you want as little else running as possible. Generally you will want to minimize paging, this is done with the -t switch which reserves a certain amount of RAM for the system. For example if you want to reserve 256M for the system do,
sys_basher -t 256
The number 256 is a good choice for reserved memory, however you can use larger or smaller numbers. Any value > 128 will cause sys_basher to lock the memory so there should be no paging while the program is running. If you suspect that you have a problem in the I/O system you might want to maximize paging, in that case it is recommended that you set the -t value to 0.
As of version 2.0.1 sys_basher can identify individual DIMMs depending on the capabilities of the system's BIOS. Most BIOSs will report the physical memory maps of the individual DIMM which allows sys_basher to localize a memory test failure to a specific DIMM. Unfortunately bad BIOSs that report incomplete DIMM information are not uncommon, in those circumstances you can still run sys_basher but you will have to interpret the failure information yourself. The program dmidecode is used to dump the bios information into a binary file that sys_basher uses to determine DIMM positions. The RPM sets up a script that runs dmidecode on boot up and puts the BIOS information into /var/sys_basher/bios.bin. If you installed from source then you will have to run the script, sys_basher_setup by hand as root (dmidecode requires root privileges to get the DMI tables from the BIOS). You do not need to run sys_basher as root, you should run it as a user program.
To run all tests do,
sys_basher -t 256 >& log &
To run just memory tests do,
sys_basher -t 256 -m >& log &
sys_basher -t 256 -m -vv >& log &
If you are trying to diagnose memory problems you may want to use the -vv (very verbose) switch. When the -vv switch thrown sys_basher will run two read passes on every memory tests, if it gets different results on each pass that would indicate that the problem is a read problem rather than an internal storage problem. The most common RAM problems are interface issues, that is to say the DIMM may be incompatible with your motherboard or it can't handle the load when it shares a bus with another DIMM. To determine the type of memory failure you should try the following things,
1) Reduce the number of DIMMs in the system from four to two (make sure that the two DIMMs are on separate buses, see the user guide for you motherboard to determine this).
2) Swap DIMMs around to see if the errors found by sys_basher move with the DIMM
3) Change the clock speed on the DIMMs. This will be BIOS dependent, generally you can control the DIMM parameters in the Overclocking section of the BIOS. BTW even though most BIOSes will use the term "Overclocking" you can reduce clock rates also (i.e. underclock).
To run just disk tests do
sys_basher -d >& log &
Sys_basher generates a set of log and report files as well as a set of comma separated report files that can be loaded into a spreadsheet. The default file names are,
The log file is synced after each test so that information is preserved in case of a system crash. The log file records the CPU and system temperatures and the fan speeds which will help to determine if there is a cooling problem. The sensor information comes from lmsensors. The RPM will install lmsensors, if you installed from source then make sure that you have sensors installed. To get a complete set of sensor readings it's a good idea to run lmsensors setup program, sensors_detect. You must run sensors_detect as root and you should accept all of it's defaults.
sys_basher may be downloaded here, (revision 2.0.2, Jan 2, 2015)
SYS_BASHER(1) User Commands SYS_BASHER(1)
sys_basher - manual page for sys_basher version 2.0.2
sys_basher (c)2006-2015 Polybus Systems Corp., Westford, MA, USA
Sys_basher is a multithreaded hardware exerciser. Sys_basher
tests CPU, memory and disk I/O reliability. It also measures
low level system performance.
Run disk tests
DMI binary file generated by dmidecode --dump-bin filename The
DMI (BIOS) file allows sys_basher to determine which DIMM is bad
The default DMI file is in /var/sys_basher/bios.bin
Dutycycle n Duty cycle in percent, the default is 100 Inserts
Sleeps between tests to reduce the overall CPU duty cycle
Skip the memory tests, just run the disk, fp and memory bandâ
Run floating point tests
Print this help message
-ho #,--hours #
Run for at least # hours.
Run integer tests
-l #,--loops #
Number of iterations.
Run memory bandwidth
Run memory tests
Run all memory tests
a Address = Data tests
b Bank tests
p Fixed pattern tests
r Random data tests
w Walking Ones/Zeros data tests
v Bit reversed address tests
Run for at least # minutes.
-p n0..nx,--path n0..nx
Directory path(s) for the disk tests, upto 32 paths maybe speciâ
fied. The default path is ./
-r name,--report name
Report file name, generate name.rpt and name_xx.csv. Default is
sys_basher.rpt and sys_basher_xx.csv
Force use of swap space. This option is incredibly slow.
Stop on Error, Exits if error found.
Allocate total ram - (n * 1M) for testing. If -totalmem is not
called then the free space is used.
-th #,--threads #
Maximum number of threads. Spawn 1-n threads, the default is the
number of CPUs.
-ts #,--tstart #
Starting thread count, after the initial calibration pass loop
from tstart to threads, the default is 1
Verbose, print detailed results, for memory tests prints address
and data info for the first 16 errors, default is PASS/FAIL
Very Very verbose, for memory tests run a second check pass to
help determine if it's a read or write problem
The default is to run all tests unless at least one individual test
group is selected. Report and log files:
The default report and log names are sys_basher.rpt and
sys_basher.log The the default name can be overridden with the
Running log. Syncs are executed after each test so that this
file can be preserved up to the point of a crash.
Summary report file.
Comma separated report files for each thread count. These files
can be read into a spreadsheet.
RHEL7/CentOS7/SL7 systems have an aggressive OOM killer which
sometimes interferes with sys_basher.
You can disable the OOM killer for sys_basher by running (as
root) sys_basher_disable_oom after starting sys_basher
sys_basher version 2.0.2 January 2015 SYS_BASHER(1)