Ubuntu
stress-ng package

stress-ng opcode test question

Asked by dongfu on 2017-08-30

I use stress-ng to stress CPU(Xeon E3, CentOS7). During the test, I found that system clock has been modified to 1970 or 1969 strangely, but this modification has no effect to rtc. For a tough debug, found stress-opcode cause this modification, below is the code

((void (*)(void))(ops_begin + mwc8()))();

And I limit test to opcode only, like this :

./stress-ng --opcode 0 --timeout 3m --log-file log/opcode.log

The test also cause different results, like user logout, gibberish output and so on. Can anyone explain this test, I have read some short description about opcode in cpu.job, but still question how the test code work. For the system time is changed, but the test past, how can I how if the system work correctly or not?

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu stress-ng Edit question
Assignee:
No assignee Edit question
Solved by:
actionparsnip
Solved:
2017-08-30
Last query:
2017-08-30
Last reply:
2017-08-30
Best actionparsnip (andrew-woodhead666) said : #1

This is Ubuntu support only. You are using CentOS so should post on the CentOS forum here:
https://www.centos.org/forums/

There are distribution agnostic forums but this is not one of them.

Colin Ian King (colin-king) said : #2

The stress-ng opcode test generates 16 pages of random binary op-codes and then jumps into this at random points. The test just checks that random or unexpected opcodes won't cause unexpected behaviour (such as CPU lock ups or hangs). I guess I should probably add some BPF protection around the code so it can't call random system calls either.

Colin Ian King (colin-king) said : #3

From the manual:

       --opcode N
              start N workers that fork off children that execute randomly gen‐
              erated executable code. This will generate issues such as illegal
              instructions, bus errors, segmentation faults, traps, floating
              point errors that are handled gracefully by the stressor.

Since this generates "random" op-codes one may wonder if it is possible to make this test repeatable, one force stress-ng to never re-seed and just use the default hard-coded seed using the --no-rand-seed option.

actionparsnip (andrew-woodhead666) said : #4

Please move this to the CentOS forum as this is Ubuntu support only

dongfu (dongfu) said : #5

Thanks actionparsnip, that solved my question.

Colin Ian King (colin-king) said : #6

@activeparnsip, just because this has been reported by a CentOS user does not mean we should dismiss this question. In fact, I have now a fix for this issue:

http://kernel.ubuntu.com/git/cking/stress-ng.git/commit/?id=8fbef13a689b225a1446196a3ea1434485939632
http://kernel.ubuntu.com/git/cking/stress-ng.git/commit/?id=740b5b85c6ab10253765f02c7adc256c5fc18dc2

See bug: #1714044

Thanks for asking the question, it helped me find and fix another bug.

Colin Ian King (colin-king) said : #7

This has now been fixed with stress-ng 0.08.13 in ubuntu artful.

dongfu (dongfu) said : #8

I have tested stress-ng 0.08.13, it still have problem. please check sys/capability.h, it should be linux/capability.h in ubuntu 16.04.

Dong Fu (jackietung) said : #9

These patches have ported to CentOS, and work well. Thanks Colin Ian King.