srikanth007m / stressapptest Goto Github PK

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Hi 

would like to know which version of linus OS should i install on the machine to 
run this stress test will 64 bit version work fine with this latest version of 
stress test 

thanks

What steps will reproduce the problem?
1. Run stressapptest
2. Sometimes crashes or runs very slowly
3. Memory is being swapped to disk, or system has OOMed

What is the expected output? What do you see instead?
stressapptest should avoid swapping or OOM somehow, or report an explicit error.

What steps will reproduce the problem?
1.stressapptest -s 28800

What do you see instead?
The screen will show bellow message:
Show pausing worker threads in preparation for power spike (28200 seconds 
remaining)
Resuming worker threads to cause a power spike(28185 seconds remaining)

Why it will show these messages?
It cannot finish and keep running.

What version of the product are you using? On what operating system?
1.0.6 64bit binary

What steps will reproduce the problem?
1. I have tried various options for running the Disk tests like below but the 
stats is not printing the disk and data check performance numbers after the 
test runs.

./stressapptest -d /dev/sdb -s 10 -v 20 --destructive

./stressapptest -d /dev/sdb -s 10 -v 20 --destructive --findfiles
./stressapptest -d /dev/sda1 --write-block-size 4096 -v 20 -s 10 --destructive 
--cache-size 54mb --write-threshold 200000
./stressapptest -d /dev/sda1 --write-block-size 4096 -v 20 -s 10 --destructive 
--cache-size 64mb --write-threshold 200000 --findfiles
./stressapptest -d /dev/sda1 --write-block-size 4096 -s 10 --destructive 
--cache-size 64mb --write-threshold 200000
./stressapptest -f /mnt/sda1/file2 -f /mnt/sda2/file1
./stressapptest -f /mnt/sda1/file2 -f /mnt/sda2/file1 --filesize 20m 
--read-block-size 1024
./stressapptest -d /dev/sda1 -d /dev/sda2
./stressapptest -d /dev/sda
./stressapptest -d /mnt/sda1 --read-block-size 1024
./stressapptest -d /dev/sda1 --read-block-size 1024
./stressapptest -d /dev/sda1 --read-block-size 1024 --verbose 20
./stressapptest -d /dev/sda1 --read-block-size 1024 -v 20
./stressapptest -d /dev/sda1 -f /mnt/sda1/file3 --read-block-size 1024 -v 20
./stressapptest -d /dev/sda1 -f /mnt/sda1/file3 --write-block-size 4096 -v 20 
-s 10
./stressapptest -d /dev/sda1 -f /mnt/sda1/file3 --write-block-size 4096 -v 20 
-s 10 --destructive --cache-size 54mb
./stressapptest -d /dev/sda1 -f /mnt/sda1/file3 --write-block-size 4096 -v 20 
-s 10 --destructive --cache-size 54mb --write-threshold 200000 use
./stressapptest -d /dev/sda1 -f /mnt/sda1/file3 --write-block-size 4096 -v 20 
-s 10 --destructive --cache-size 54mb --write-threshold 200000 usec
./stressapptest -d /dev/sda1 -f /mnt/sda1/file3 --write-block-size 4096 -v 20 
-s 10 --destructive --cache-size 54mb --write-threshold 200000




What is the expected output? What do you see instead?
The disk stats & data check should print some number 

Stats: Found 0 hardware incidents
Stats: Completed: 72356.00M in 10.00s 7235.11MB/s, with 0 hardware incidents, 0 
errors
Stats: Memory Copy: 72356.00M at 7235.34MB/s
Stats: File Copy: 0.00M at 0.00MB/s
Stats: Net Copy: 0.00M at 0.00MB/s
Stats: Data Check: 0.00M at 0.00MB/s
Stats: Invert Data: 0.00M at 0.00MB/s
Stats: Disk: 0.00M at 0.00MB/s


What version of the product are you using? On what operating system?
stressapptest-1.0.6_autoconf on ubuntu 
Linux host2 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 05:14:15 UTC 2010 
x86_64 GNU/Linux
Ubuntu 10.04.1 LTS

Please provide any additional information below.

Please let me know how can we get the disk and data check numbers. I have tried 
a lot of options in the 1.0.6 build.

What steps will reproduce the problem?
Run stressapptest on CentOS5.2 text mode.


What is the expected output? What do you see instead?
Assertion failed at sattypes.h:106
Assertion failed at logger.cc:74
Assertion failed at sattypes.h:106

What version of the product are you using? On what operating system?
stressapptest-1.0.1_autoconf.tar.gz
CentOS5.2 

Please provide any additional information below.
CentOS5.2 can only install stressapptest-1.0.1, it will show make error when we 
using stressapptest-1.0.6 version.

please do not hardcode optimization flags by default.  configure.ac currently 
does:
CXXFLAGS="$CXXFLAGS -O3 -funroll-all-loops  -funroll-loops ..."

could that at least be put behind a configure flag ?  like 
--disable-default-optimizations ?

AC_ARG_ENABLE([default-optimizations],
    AS_HELP_STRING([--disable-default-optimizations], [Disable default optimization flag overrides])])
AS_IF([test x"$enable_default_optimizations" != xno], [
    CXXFLAGS="$CXXFLAGS -O3 -funroll-all-loops -funroll-loops"
])

the current cpuid logic clobbers %ebx.  this is OK if the code is not PIC, but 
if you're building PIEs, it'll fail because %ebx is the PIC register and gcc 
doesn't let you clobber it.

simple fix:
  int ax, bx, cx, dx;
  __asm__ __volatile__ (
      "mov %%ebx, %%edi;"
      "cpuid;"
      "mov %%ebx, %%esi;"
      "mov %%edi, %%ebx;"
      :"=a" (ax), "=S" (bx), "=c" (cx), "=d" (dx) : "a"(1) :"edi");

it's a few more insns on x86_64 or i386/non-pic, so if you want, you could do 
something like:
#if defined(STRESSAPPTEST_CPU_I686) && defined(__PIC__)
 ... do pic version here ...
#else
 ... do non-pic version here ...
#endif

What steps will reproduce the problem?
1. run with network loopback
2. get some errors
3. just reported as regular memory errors

What is the expected output? What do you see instead?
Should comment that they could be network errors, similar to disk loopback.

What steps will reproduce the problem?
1. Provision a new ubuntu server
2. apt-get update
3. install stressaptest
4. run stressapptest

What is the expected output? What do you see instead?

I expected performance benchmarks.  Instead I saw the following:

alan@dev1:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 9.04
Release:        9.04
Codename:       jaunty
alan@dev1:~$ stressapptest
Log: Commandline - stressapptest
Stats: SAT revision 1.0.0_autoconf, 64 bit binary
Log: root @ dev1 on Thu Oct 15 17:52:53 PDT 2009 from open source release
Log: 1 nodes, 8 cpus.
Log: Defaulting to 8 copy threads
Log: Total 7894 MB. Free 7441 MB. Hugepages 0 MB. Targeting 7308 MB (92%)
Process Error: Unsupported system, no error reporting available
Log: Command line option '-A' bypasses this error.
Process Error: Sat::Initialize() failed

Status: FAIL - test encountered procedural errors

Process Error: Fatal issue encountered. See above logs for details.
alan@dev1:~$ uname -a
Linux dev1 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009
x86_64 GNU/Linux
alan@dev1:~$


What version of the product are you using? On what operating system?

I am using version " revision 1.0.0_autoconf, 64 bit binary" on an Ubuntu
LInux OS.

Please provide any additional information below.

Pretty straightforward.  I installed g++, did ./configure, make, make
install, then run and got the FAIL error.

What steps will reproduce the problem?
1.stressapptest -A  -d /dev/sdb
2.Process Error: Unable to seek to sector 4840934 in

What is the expected output? What do you see instead?
Should not error. off64_t should be used for 32bit binary compatibility.

the configure.ac handling of target/host is incorrect.  you should delete these 
lines:
 AC_CANONICAL_BUILD
 AC_CANONICAL_TARGET
the "host" in autoconf terms is where the code will be run, not the "target".

then change $target_cpu to $host_cpu in the few places it gets used.

further, the code currently runs `uname` to figure out the os.  please use 
$host_os instead as autoconf will set that up for you.

the Makefile.am should read:
dist_man_MANS = stressapptest.1
otherwise, the man page doesn't get installed to the right place

then just omit COPYING altogether as automake will import it correctly by 
default.  you can verify by running `make distcheck`.

What steps will reproduce the problem?
1. typing "stressapptest" as root under commandline

The output is:

Log: Commandline - stressapptest
Stats: SAT revision 1.0.0_autoconf, 32 bit binary
Log: root @ [...] on Mon Oct 19 20:03:44 CEST 2009 from open source release
Log: 1 nodes, 1 cpus.
Log: Defaulting to 1 copy threads
Log: Total 1010 MB. Free 373 MB. Hugepages 0 MB. Targeting 859 MB (84%)
Log: Flooring memory allocation to multiple of 4: 856MB
Process Error: Unsupported system, no error reporting available
Log: Command line option '-A' bypasses this error.
Process Error: Sat::Initialize() failed

Status: FAIL - test encountered procedural errors

Process Error: Fatal issue encountered. See above logs for details.



What version of the product are you using? On what operating system?

Debian Lenny

Hi,

the current version of stressapptest fails to build on several architectures 
due to an arch check that looks for x86_64, i686, powerpc and armv7a.

We've tracked this issue in Debian's BTS at:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598756
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599016

For the build status see:

  https://buildd.debian.org/status/package.php?p=stressapptest

Would be nice if the configure script wouldn't have those strict tests and 
instead allows compilation on systems other than i386, amd64 and powerpc again. 
:)

thanks && regards,
-mika-

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

the current os.cc code does:
        shmaddr = mmap64(NULL, length, PROT_READ | PROT_WRITE,
                         MAP_SHARED | MAP_NORESERVE | MAP_LOCKED | MAP_POPULATE,
                         shm_object, NULL);

the last arg is an off_t, not a pointer, so that should be 0, not NULL

otherwise, building on recent glibc/linux yields an ugly warning:
os.cc:473:44: warning: passing NULL to non-pointer argument 6 of ‘void* 
mmap64(void*, size_t, int, int, int, __off64_t)’ [-Wconversion-null]

What steps will reproduce the problem?
1.first do ./configure, sucessfully done
2.then I try to make, got this error
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
the version I used is stressapptest-1.0.3-autoconf, the OS is Redhat9.0

Please provide any additional information below.

What steps will reproduce the problem?
1.../configure --build=x86 --target=armv7a-none-linux-gnueabi 
--host=arm-none-linux-gnueabi --program-prefix=arm-none-linux-gnueabi- 
--with-static --prefix=/people/pradeepb/test
2.make install

What is the expected output? What do you see instead?
I did not expect to see any warnings about the machine type. However, i see 
os.h:160:4: warning: #warning "Unsupported CPU type: Unable to force cache 
flushes."

What version of the product are you using? On what operating system?
1_0_7; Linux/Ubuntu

Please provide any additional information below.

What steps will reproduce the problem?
1. Run stressapptest
2. Sometimes crashes or runs very slowly
3. Memory is being swapped to disk, or system has OOMed

What is the expected output? What do you see instead?
stressapptest should avoid swapping or OOM somehow, or report an explicit error.

What steps will reproduce the problem?
1.Run with '-W' warm copy on a machine with SSE2
2.No SSE2 workload is run
3.Generic C implementation is run instead

What is the expected output? What do you see instead?
SSE2 workload should be run, if CPU supports it

os layer should detect cpu type and feature set.

the code does this:
  if test "$with_static" == "yes"

that should be one = as that is the only one in POSIX

Dear all,

Excuse me, I got the unexpected result when I run the stressapptest with 
setting executing time to be 3600s(1hr).

The information is described as below,

What steps will reproduce the problem?
1. adb push stressapptest /data/stressapptest
2. adb shell and execute /data/stressapptest -s 3600 -i 4 -C 4 -W 
--stop_on_errors -M 200 &
   This happens when executing time set to 3600(1hr)

What is the expected output? What do you see instead?

I got the wrong result that max_runtime_sec equals to 0 and hence the 
throughput got infinite value.

The result is as below,
Stats: Completed: 4050572.00M in 0.00s infMB/s, with 0 hardware incidents, 0 
errors
Stats: Memory Copy: 1425572.00M at -2049.71MB/s
Stats: File Copy: 0.00M at 0.00MB/s
Stats: Net Copy: 0.00M at 0.00MB/s
Stats: Data Check: 0.00M at 0.00MB/s
Stats: Invert Data: 2625000.00M at -3774.27MB/s
Stats: Disk: 0.00M at 0.00MB/s

Status: PASS - please verify no corrected errors

What version of the product are you using? On what operating system?
-> SAT revision 1.0.4_autoconf, 32 bit binary

Thanks!

BR,
Joseph Hung

What steps will reproduce the problem?
(1) stressapptest -s 20 -C 4 --cc_test --stop_on_errors -i 4 -W -M 4096 -f 
/file.1
or
(2) stressapptest -s 20 -C 4 --cc_test --stop_on_errors -i 4 -W -M 4096 -d 
or
(3) stressapptest -s 20 -C 4 --cc_test --stop_on_errors -i 4 -W -M 4096 -d /

What is the expected output? What do you see instead?
(1)
Expect: File Copy: ***value***M at ***value***MB/s
Actual: Process Error: Failed to create file file.1!!
            File Copy: 0.00M at 0.00MB/s
(2)
Expect: Disk: ***value***M at ***value***MB/s
Actual: Disk: 0.00M at 0.00MB/s

(3)
Expect: Disk: ***value***M at ***value***MB/s
Actual: Process Error: Fatal issue encountered. See above logs for details.
            Disk: 0.00M at 0.00MB/s

What version of the product are you using? On what operating system?
stressapptest revision 1.0.6_autoconf, 64 bit binary

Please provide any additional information below.
I am trying to get the speed of the primary hard drive, in other words the 
speed of the drive the os is running on. I do not care if this is by using -d 
or by using -f but I would prefer to use stressapptest as I am already using it 
for some other tests. I am able to get -f info for USB drives I have in the 
system, but not the primary SSD drive. Attached you will find the output of the 
terminal window where I have attempted to get the SSD information.

What steps will reproduce the problem?
  1. On system that is lacking static version of librt and/or libaio
  2. ./configure


What is the expected output? What do you see instead?
  Error message is "checking if pthreads is supported... configure: error:
Cannot find a proper pthread library".  But pthread library is installed
and there are no problems there.

config.log shows the real problem:
  configure:6039: checking if pthreads is supported
  configure:6066: gcc -o conftest -g -O2   conftest.c  -static -lrt
-pthread -laio >&5
  /usr/bin/ld: cannot find -lrt
  collect2: ld returned 1 exit status

i.e. librt.a is missing.

After installing static librt, I get same problem with libaio.  Gives
misleading pthread message again.  Problem is that default libaio is shared
library.

What version of the product are you using? On what operating system?

  stressapptest-1.0.3_autoconf

  Fedora 12.


Please provide any additional information below.

On Fedora 12, to get a static version of librt.a, you need to install the
"glibc-static" package.  For static version of libaio, you need to install
the "libaio-devel" package.

Question: does conftest.c really need to be compiled with the -static flag?

Dear Sir

  I using 1.0.3 to running some testing , but i meat a problem, Does this stress-tool support multiple hdds ? i don't knonw how to run multiple diskst testing at the same time, maybe someone can tell me how to do , thanks a lot...

the 3rd arg to shmat() is an integer, not a pointer.  the current os.cc file 
does:
      shmaddr = shmat(shmid, NULL, NULL);

which triggers a warning on recent Linux/glibc systems:
os.cc:416:44: warning: passing NULL to non-pointer argument 3 of ‘void* 
shmat(int, const void*, int)’ [-Wconversion-null]

simply change the 3rd arg to 0

We noticed a failure while running SAT under Linux back to back. test_loop.sh 
shows how it can reproduce. The failure mode is that one of the 
SAT applications will fail because of an allocation failure. We looked into 
this and found that there are a couple of scenarios that will cause the memory 
not to be freed to the OS at process exit time frame.


1. libc refuses to free the memory back to the OS on free(). memalign() isn't 
guaranteed to work with free(). However, glibc claims it does. posix_memalign() 
is suppose to work with free(), but in our tests strace showed that glibc 
refused to give back the virtual memory space to the OS.

Once the above behavior occurs the following can happen which cause the memory 
not to be released to the OS.

a. Someone reading certain /proc files of SAT's can take a reference on the 
OS's mm structure. This can lead to a delayed free of the mm's memory.

b. There can be a thread deep in a run queue that is signalled to die but 
hasn't yet.  The memory won't be given back to the OS until this last reference 
to the mm is dropped.

My proposal is to perform the explicit mmap()/munmap() in SAT so that external 
reference counts on the mm within Linux won't cause the memory to be tied up. A 
patch is attached to do just that.

What steps will reproduce the problem?
1. stressapptest -f stresstest -f stresstest

What is the expected output? What do you see instead?

It should start only one thread per file/device and possibly complain 
about concurrent usage of the same file. The File/device should be opened 
exclusively.

What version of the product are you using? On what operating system?

Stats: SAT revision 1.0.1_autoconf, 64 bit binary
Debian Lenny

What steps will reproduce the problem?

1. ./configure


make[2]: Entering directory `/tmp/stressapptest-1.0.0_autoconf/src'
g++ -DHAVE_CONFIG_H -I. -g -O2 -DCHECKOPTS -Wreturn-type -Wunused
-Wuninitialized -Wall -O3 -funroll-all-loops  -funroll-loops


-O2 or -O3 ?  :)

What steps will reproduce the problem?
1.run stressapptest with the command "stressapptest -s 3600"
2.
3.

What is the expected output? What do you see instead?
We expect the result should be 62000 on all machines, but the fact is that some 
machines get the result less than 40000, some machines get the result which is 
62000.
And it could be reproduced always.

What version of the product are you using? On what operating system?
Stats: SAT revision 1.0.4_autoconf, 64 bit binary
os version is CentOS 4.3, and kernel 2.6.32

Please provide any additional information below.
The machines which run fail had run pass when be changed to REDHAT 6.5.

Hello,

What steps will reproduce the problem?

1. install: 

sudo apt-get install stressapptest

2. run: 

ubuntu@wandboard:~$ stressapptest -s 1000 -M auto-detect -m 4 -C 4 -W -l
Log: Commandline - stressapptest -s 1000 -M auto-detect -m 4 -C 4 -W -l
Stats: SAT revision 1.0.6_autoconf, 32 bit binary
Log: buildd @ kishi01 on Sun Dec  1 04:07:20 UTC 2013 from open source release
Log: 1 nodes, 4 cpus.
Log: Total 2016 MB. Free 1628 MB. Hugepages 0 MB. Targeting 1713 MB (84%)
Log: Flooring memory allocation to multiple of 4: 1712MB
Log: Prefer POSIX shared memory allocation.
Log: You may need to run 'sudo mount -o remount,size=100% /dev/shm.'
Log: Using posix shared memory object 0x3 mapped as needed.
Stats: Starting SAT, 1712M, 1000 seconds
Process Error: PrepareTestMem mmap64(52100000, 100000) failed. error: unknown 
failure.
Assertion failed at os.cc:659
Process Error: PrepareTestMem mmap64(30e00000, 100000) failed. error: unknown 
failure.
Assertion failed at os.cc:659
Assertion failed at os.cc:659
Process Error: PrepareTestMem mmap64(37700000, 100000) failed. error: unknown 
failure.
Assertion failed at logger.cc:74
Assertion failed at os.cc:659
ubuntu@wandboard:~$

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?

verion: 

stressapptest --help
Stats: SAT revision 1.0.6_autoconf, 32 bit binary
Log: buildd @ kishi01 on Sun Dec  1 04:07:20 UTC 2013 from open source release

OS:

Ubuntu 14.04.2 LTS (GNU/Linux 3.10.53-1.1.0_ga-wandboard armv7l)

Any suggestions?

Thanks

What steps will reproduce the problem?
1.  Download latest version of cppcheck from sourceforge (1.57 was used)
2.  run cppcheck --enable=all .

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
stressapptest-1.0.4_autoconf / Scientific Linux 6.x

Please provide any additional information below.
Multiple issues/warnings are listed but only the error is being entered for 
tracking

From DmitriyM:

Process Error: while initializing empty_ list

Some digging revealed that FineLockPEQueue::PutEmpty returns false
as it can't unlock FineLockPEQueue::pagelocks_ mutexes ->
Sat::InitializePages fails. Mutexes are never locked as
FineLockPEQueue::GetRandomWithPredicateTag (which locks them) is
actually never called.

What steps will reproduce the problem?
Execute following command
1. aclocal
2. automake --gnu
3. autoconf
4. ./configure./configure --build=x86 --target=armv7a-none-linux-gnueabi 
--host=arm-none-linux-gnueabi

What is the expected output? What do you see instead?
Expected: configuration to be completed successfully.
Instead: checking for pthread_barrier... configure: error: in 
`/stressapptest-1.0.6_autoconf':
configure: error: cannot run test program while cross compiling
See `config.log' for more details.


What version of the product are you using? On what operating system?
stressapptest-1.0.6

Please provide any additional information below.
Instead of AC_TRY_RUN perform AC_COMPILE_CHECK to check pthread_barrier.
During cross compilation, perform compilation check instead of run check for 
pthread_barrier.

What steps will reproduce the problem?
1. Install googlestress app 1.0.6 autoconf rpm
2. Run script to start CPU and DIMM stress for specific time
3.

What is the expected output? What do you see instead?

There shouldn't has error message on DIMM
What version of the product are you using? On what operating system?
Intel Avoton C2750 8C CPU
8G Micron 1600MHZ SODIMM *2
Centos6.3
Please provide any additional information below.
Please see the test result on attach.

What steps will reproduce the problem?
1.make CXXFLAGS=-static


What is the expected output? What do you see instead?
g++  -static  -pthread -laio -o stressapptest main.o os.o os_factory.o 
pattern.o queue.o sat.o sat_factory.o worker.o finelock_queue.o error_diag.o 
disk_blocks.o adler32memcpy.o logger.o   
worker.o: In function `DiskThread::Work()':
worker.cc:(.text+0x1aac): undefined reference to `io_setup'
worker.cc:(.text+0x1b49): undefined reference to `io_destroy'
worker.o: In function `DiskThread::AsyncDiskIO(DiskThread::IoOp, int, void*, 
long long, long long, long long)':
worker.cc:(.text+0x29de): undefined reference to `io_submit'
worker.cc:(.text+0x2b6e): undefined reference to `io_getevents'
worker.cc:(.text+0x2d0c): undefined reference to `io_cancel'
worker.cc:(.text+0x2d1f): undefined reference to `io_destroy'
worker.cc:(.text+0x2d49): undefined reference to `io_setup'
collect2: ld returned 1 exit status


What version of the product are you using? On what operating system?
stressapptest-1.0.2_autoconf, OS is 2.6.18-1.2798.fc6(GNU/Linux)

Please provide any additional information below.

[root@pc-87-12-odi-pod2-br-pc1 stressapptest-1.0.2_autoconf]# ls -l 
/usr/lib64/libaio.*
-rw-r--r-- 1 root root 57470 Apr 19 23:40 /usr/lib64/libaio.a
lrwxrwxrwx 1 root root    15 Apr 19 23:40 /usr/lib64/libaio.so -> 
libaio.so.1.0.1
lrwxrwxrwx 1 root root    15 Apr 19 23:40 /usr/lib64/libaio.so.1 -> 
libaio.so.1.0.1
-rwxr-xr-x 1 root root 19775 Apr 19 23:40 /usr/lib64/libaio.so.1.0.1
[root@pc-87-12-odi-pod2-br-pc1 stressapptest-1.0.2_autoconf]# 
[root@pc-87-12-odi-pod2-br-pc1 stressapptest-1.0.2_autoconf]# 
[root@pc-87-12-odi-pod2-br-pc1 stressapptest-1.0.2_autoconf]# find / -name 
librt.a
/usr/lib/librt.a
/usr/lib64/librt.a

Machines with cpu problems or ecc events often generate machine checks. 
Publicly available MCE decode should be printed by stressapptest.

What steps will reproduce the problem?
1. ./configure --host=mips64
2. Compiler used is mips-wrs-linux-gnu-mips64_octeon-glibc_small-g++
3. Finally, we get linking error

What is the expected output? What do you see instead?
Linking should be successful. Instead of that we get below linking error
mips-wrs-linux-gnu-mips64_octeon-glibc_small-c++  -DCHECKOPTS -Wreturn-type 
-Wunused -Wuninitialized -Wall -O3 -DNDEBUG  -pthread -o stressapptest main.o 
os.o os_factory.o pattern.o queue.o sat.o sat_factory.o worker.o 
finelock_queue.o error_diag.o disk_blocks.o adler32memcpy.o logger.o
/home/gur16663/gur16663_etpa/common/platform/octeon/kits/windriver/WR-3.0/toolch
ain/x86-linux2/bin/../lib/gcc/mips-wrs-linux-gnu/4.3.2/../../../../mips-wrs-linu
x-gnu/bin/ld: cannot find -lstdc++


What version of the product are you using? On what operating system?
stressapptest-1.0.1_autoconf

Please provide any additional information below.
We want to run stresapptest on cavium network's mips cpu.

What steps will reproduce the problem?
1.Commandline - stressapptest -f /mnt/1 --filesize 1024000 -s 216000 -l 
stress_60hr_sys5_8T

What is the expected output? What do you see instead?
1. stressapptest can not complete and system does not hang up
2. The screen show "Pausing worker threads in preparation for power spike(35400 
  seconds remaining)"

What version of the product are you using? On what operating system?
1. Stressapptest : SAT revision 1.0.5_autoconf, 64 bit binary
2. OS : CentOS6.4

Please provide any additional information below.

What steps will reproduce the problem?
1. aclocal
2. automake --gnu
3. autoconf
4. ./configure./configure --build=x86 --target=armv7a-none-linux-gnueabi 
--host=arm-none-linux-gnueabi

What is the expected output? What do you see instead?
Expected: configuration to be completed successfully.
Instead: checking for pthread_barrier... configure: error: in 
`/stressapptest-1.0.6_autoconf':
configure: error: cannot run test program while cross compiling
See `config.log' for more details.

What version of the product are you using? On what operating system?
stressapptest-1.0.6

Please provide any additional information below.
Instead of AC_TRY_RUN perform AC_COMPILE_CHECK to check pthread_barrier.
During cross compilation, perform compilation check instead of run check for 
pthread_barrier.

Download, and
1. ./configure - ok
2. make - error:

Making install in src
g++ -DHAVE_CONFIG_H -I.      -g -O2 -DCHECKOPTS -Wreturn-type -Wunused -
Wuninitialized -Wall -O3 -funroll-all-loops  -funroll-loops -DNDEBUG -MT 
main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cc
In file included from main.cc:17:
sattypes.h: In function `std::string ErrorString(int)':
sattypes.h:144: error: invalid conversion from `int' to `const char*'
sattypes.h:144: error:   initializing argument 1 of 
`std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, 
const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, 
_Alloc = std::allocator<char>]'
In file included from sat.h:31,
                 from main.cc:18:
worker.h:29:27: linux/aio_abi.h: No such file or directory
In file included from sat.h:31,
                 from main.cc:18:
worker.h: At global scope:
worker.h:730: error: `aio_context_t' does not name a type
*** Error code 1

Stop in ~/my/stressapptest-1.0.0_autoconf/src.
*** Error code 1

Stop in ~/my/stressapptest-1.0.0_autoconf.