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.1, June 21, 2014)
sys_basher (c)2006-2014 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.
Usage: sys_basher [OPTIONS]
-d,--disk Run disk tests
-dmi filename 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
-du,--dutycyle Dutycycle n Duty cycle in percent, the default is 100
Inserts Sleeps between tests to reduce the overall CPU duty cycle
-f,--fast Skip the memory tests, just run the disk, fp and memory bandwidth tests.
-fp,--fp Run floating point tests
-h,--help Print this help message
-ho #,--hours # Run for at least # hours.
-i,--int Run integer tests
-l #,--loops # Number of iterations.
-mb,--mbandwidth Run memory bandwidth
-m,--mem [abprwv] Run memory tests
No argument 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
-mi,--minutes # Run for at least # minutes.
-p n0..nx,--path n0..nx Directory path(s) for the disk tests, upto 32 paths maybe specified. 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
-s,--swap Force use of swap space. This option is incredibly slow.
-st,--stop Stop on Error, Exits if error found.
-t,--totalmem # 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
-v,--verbose Verbose, print detailed results, for memory tests prints address and data info for the first 16 errors, default is PASS/FAIL only.
-vv,--vverbose 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_name is sys_basher.
The the default name can be overridden with the -r switch.
report_name.log Running log. Syncs are executed after each test so that this file can be preserved up to the point of a crash.
report_name.rpt Summary report file.
report_name_#_threads.csv Comma separated report files for each thread count. These files can be read into a spreadsheet.