| 2016-04-12 16:54:09 |
Jeff Lane |
bug |
|
|
added bug |
| 2016-04-12 16:56:07 |
Jeff Lane |
description |
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose on an LPAR:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2016-04-12 18:31:58 |
Jeff Lane |
tags |
apport-bug s390x xenial |
apport-bug blocks-hwcert-server s390x xenial |
|
| 2016-04-13 15:11:52 |
Jeff Lane |
attachment added |
|
zvm-stress-ng-mmap-strace-log.tgz https://bugs.launchpad.net/ubuntu/+source/stress-ng/+bug/1569468/+attachment/4635680/+files/zvm-stress-ng-mmap-strace-log.tgz |
|
| 2016-04-13 15:22:02 |
Jeff Lane |
attachment added |
|
lpar-stress-ng-mmap-strace-log.tgz https://bugs.launchpad.net/ubuntu/+source/stress-ng/+bug/1569468/+attachment/4635697/+files/lpar-stress-ng-mmap-strace-log.tgz |
|
| 2016-04-14 08:30:57 |
Colin Ian King |
stress-ng (Ubuntu): importance |
Undecided |
High |
|
| 2016-04-14 08:30:59 |
Colin Ian King |
stress-ng (Ubuntu): assignee |
|
Colin Ian King (colin-king) |
|
| 2016-04-14 09:58:56 |
Colin Ian King |
stress-ng (Ubuntu): status |
New |
Fix Committed |
|
| 2016-04-22 10:28:28 |
Colin Ian King |
description |
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose on an LPAR:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
[SRU, Xenial]
Requesting a micro release sync to pull in a fix to this bug plus a few minor buglets found when testing on Ubuntu Userspace on Windows.
When running stress-ng on zVM and LPAR we are hitting SIGBUS errors because we have a sparsely allocated mmap'd backing file which due to over commit and a full file system causes pages not to be mapped in and causes memory accesses on unbacked pages to trigger a SIGBUS.
[REPRODUCER + FIX]
Run stress-ng --mmap 64 --maximize on a filesystem that is very nearly full and the SIGBUS triggers and the stressor exits early with SIGBUS. With the fix, the SIGBUS is caught and the stressor can continue without premature early exit.
[REGRESSION POTENTIAL]
I am requesting syncing with 0.05.24 micro release as this contains the fix plus a few SIGSEGV stack trapping fixes. stress-ng is a universe leaf project and the fixes touch just a few of the stress tests. These have been regression checked on various architectures and the code passes static analysis on cppcheck, CoverityScan and clang's scan-build, so regression potential is minimal.
Changelog:
Makefile: bump version
stress-mmap: handle SIGBUS signals (LP: #1569468)
stress-mmapmany: sanity check sysconf return
stress-mmapmany: detect SEGV deaths
stress-mlock: detect SEGV deaths
stress-brk: detect SEGV deaths
stress-bigheap: detect SEGV deaths
stress-memfd: detect SEGV deaths
stress-mmapmany: allocate mappings on heap rather than stack
stress-mlock: allocate mappings on heap rather than stack
stress-cpu: move sieve buffer to static to reduce stack size
stress-sem*: differentiate between which semaphore init that failed
stress-remap-file-pages: abort if remap fails
stress-fiemap: remove \n from pr_fail_err messages
--------------------------------------------------------------------------
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose on an LPAR:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2016-04-22 10:28:53 |
Colin Ian King |
description |
[SRU, Xenial]
Requesting a micro release sync to pull in a fix to this bug plus a few minor buglets found when testing on Ubuntu Userspace on Windows.
When running stress-ng on zVM and LPAR we are hitting SIGBUS errors because we have a sparsely allocated mmap'd backing file which due to over commit and a full file system causes pages not to be mapped in and causes memory accesses on unbacked pages to trigger a SIGBUS.
[REPRODUCER + FIX]
Run stress-ng --mmap 64 --maximize on a filesystem that is very nearly full and the SIGBUS triggers and the stressor exits early with SIGBUS. With the fix, the SIGBUS is caught and the stressor can continue without premature early exit.
[REGRESSION POTENTIAL]
I am requesting syncing with 0.05.24 micro release as this contains the fix plus a few SIGSEGV stack trapping fixes. stress-ng is a universe leaf project and the fixes touch just a few of the stress tests. These have been regression checked on various architectures and the code passes static analysis on cppcheck, CoverityScan and clang's scan-build, so regression potential is minimal.
Changelog:
Makefile: bump version
stress-mmap: handle SIGBUS signals (LP: #1569468)
stress-mmapmany: sanity check sysconf return
stress-mmapmany: detect SEGV deaths
stress-mlock: detect SEGV deaths
stress-brk: detect SEGV deaths
stress-bigheap: detect SEGV deaths
stress-memfd: detect SEGV deaths
stress-mmapmany: allocate mappings on heap rather than stack
stress-mlock: allocate mappings on heap rather than stack
stress-cpu: move sieve buffer to static to reduce stack size
stress-sem*: differentiate between which semaphore init that failed
stress-remap-file-pages: abort if remap fails
stress-fiemap: remove \n from pr_fail_err messages
--------------------------------------------------------------------------
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose on an LPAR:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
[SRU, Xenial]
Requesting a micro release sync with stress-ng 0.05.24 to pull in a fix to this bug plus a few minor buglets found when testing on Ubuntu Userspace on Windows.
When running stress-ng on zVM and LPAR we are hitting SIGBUS errors because we have a sparsely allocated mmap'd backing file which due to over commit and a full file system causes pages not to be mapped in and causes memory accesses on unbacked pages to trigger a SIGBUS.
[REPRODUCER + FIX]
Run stress-ng --mmap 64 --maximize on a filesystem that is very nearly full and the SIGBUS triggers and the stressor exits early with SIGBUS. With the fix, the SIGBUS is caught and the stressor can continue without premature early exit.
[REGRESSION POTENTIAL]
I am requesting syncing with 0.05.24 micro release as this contains the fix plus a few SIGSEGV stack trapping fixes. stress-ng is a universe leaf project and the fixes touch just a few of the stress tests. These have been regression checked on various architectures and the code passes static analysis on cppcheck, CoverityScan and clang's scan-build, so regression potential is minimal.
Changelog:
Makefile: bump version
stress-mmap: handle SIGBUS signals (LP: #1569468)
stress-mmapmany: sanity check sysconf return
stress-mmapmany: detect SEGV deaths
stress-mlock: detect SEGV deaths
stress-brk: detect SEGV deaths
stress-bigheap: detect SEGV deaths
stress-memfd: detect SEGV deaths
stress-mmapmany: allocate mappings on heap rather than stack
stress-mlock: allocate mappings on heap rather than stack
stress-cpu: move sieve buffer to static to reduce stack size
stress-sem*: differentiate between which semaphore init that failed
stress-remap-file-pages: abort if remap fails
stress-fiemap: remove \n from pr_fail_err messages
--------------------------------------------------------------------------
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose on an LPAR:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2016-04-22 10:32:33 |
Colin Ian King |
description |
[SRU, Xenial]
Requesting a micro release sync with stress-ng 0.05.24 to pull in a fix to this bug plus a few minor buglets found when testing on Ubuntu Userspace on Windows.
When running stress-ng on zVM and LPAR we are hitting SIGBUS errors because we have a sparsely allocated mmap'd backing file which due to over commit and a full file system causes pages not to be mapped in and causes memory accesses on unbacked pages to trigger a SIGBUS.
[REPRODUCER + FIX]
Run stress-ng --mmap 64 --maximize on a filesystem that is very nearly full and the SIGBUS triggers and the stressor exits early with SIGBUS. With the fix, the SIGBUS is caught and the stressor can continue without premature early exit.
[REGRESSION POTENTIAL]
I am requesting syncing with 0.05.24 micro release as this contains the fix plus a few SIGSEGV stack trapping fixes. stress-ng is a universe leaf project and the fixes touch just a few of the stress tests. These have been regression checked on various architectures and the code passes static analysis on cppcheck, CoverityScan and clang's scan-build, so regression potential is minimal.
Changelog:
Makefile: bump version
stress-mmap: handle SIGBUS signals (LP: #1569468)
stress-mmapmany: sanity check sysconf return
stress-mmapmany: detect SEGV deaths
stress-mlock: detect SEGV deaths
stress-brk: detect SEGV deaths
stress-bigheap: detect SEGV deaths
stress-memfd: detect SEGV deaths
stress-mmapmany: allocate mappings on heap rather than stack
stress-mlock: allocate mappings on heap rather than stack
stress-cpu: move sieve buffer to static to reduce stack size
stress-sem*: differentiate between which semaphore init that failed
stress-remap-file-pages: abort if remap fails
stress-fiemap: remove \n from pr_fail_err messages
--------------------------------------------------------------------------
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose on an LPAR:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
[SRU, Xenial]
When running stress-ng on zVM and LPAR we are hitting SIGBUS errors because we have a sparsely allocated mmap'd backing file which due to over commit and a full file system causes pages not to be mapped in and causes memory accesses on unbacked pages to trigger a SIGBUS.
[REPRODUCER + FIX]
Run stress-ng --mmap 64 --maximize on a filesystem that is very nearly full and the SIGBUS triggers and the stressor exits early with SIGBUS. With the fix, the SIGBUS is caught and the stressor can continue without premature early exit.
[REGRESSION POTENTIAL]
I am requesting syncing with 0.05.24 micro release as this contains the fix plus a few SIGSEGV stack trapping fixes. stress-ng is a universe leaf project and the fixes touch just a few of the stress tests. These have been regression checked on various architectures and the code passes static analysis on cppcheck, CoverityScan and clang's scan-build, so regression potential is minimal.
Changelog:
Makefile: bump version
stress-mmap: handle SIGBUS signals (LP: #1569468)
--------------------------------------------------------------------------
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose on an LPAR:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2016-04-22 10:41:08 |
Colin Ian King |
description |
[SRU, Xenial]
When running stress-ng on zVM and LPAR we are hitting SIGBUS errors because we have a sparsely allocated mmap'd backing file which due to over commit and a full file system causes pages not to be mapped in and causes memory accesses on unbacked pages to trigger a SIGBUS.
[REPRODUCER + FIX]
Run stress-ng --mmap 64 --maximize on a filesystem that is very nearly full and the SIGBUS triggers and the stressor exits early with SIGBUS. With the fix, the SIGBUS is caught and the stressor can continue without premature early exit.
[REGRESSION POTENTIAL]
I am requesting syncing with 0.05.24 micro release as this contains the fix plus a few SIGSEGV stack trapping fixes. stress-ng is a universe leaf project and the fixes touch just a few of the stress tests. These have been regression checked on various architectures and the code passes static analysis on cppcheck, CoverityScan and clang's scan-build, so regression potential is minimal.
Changelog:
Makefile: bump version
stress-mmap: handle SIGBUS signals (LP: #1569468)
--------------------------------------------------------------------------
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose on an LPAR:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
[SRU, Xenial]
When running stress-ng on zVM and LPAR we are hitting SIGBUS errors because we have a sparsely allocated mmap'd backing file which due to over commit and a full file system causes pages not to be mapped in and causes memory accesses on unbacked pages to trigger a SIGBUS.
[REPRODUCER + FIX]
Run stress-ng --mmap 64 --maximize on a filesystem that is very nearly full and the SIGBUS triggers and the stressor exits early with SIGBUS. With the fix, the SIGBUS is caught and the stressor can continue without premature early exit.
[REGRESSION POTENTIAL]
I am requesting syncing with 0.05.24 micro release as this contains the fix plus a few SIGSEGV stack trapping fixes. stress-ng is a universe leaf project and the fixes touch just a few of the stress tests. These have been regression checked on various architectures and the code passes static analysis on cppcheck, CoverityScan and clang's scan-build, so regression potential is minimal.
--------------------------------------------------------------------------
Running stress-ng on s390 in all three modes. This seems to work ok in z/KVM, however, on zVM and LPAR as of a few days ago on Xenial the mmap stressor has started failing.
I tried to get detailed logs but either don't know the correct switches or they simply aren't there.
Here is the output when I used --log-file and --verbose on an LPAR:
root@s1lp10-jefflane:~# less stress-ng-mmap-fail.log
stress-ng: debug: [179421] 4 processors online, 4 processors configured
stress-ng: info: [179421] dispatching hogs: 4 mmap
stress-ng: debug: [179421] cache allocate: reducing cache level from L3 (too high) to L2
stress-ng: info: [179421] cache allocate: default cache size: 2048K
stress-ng: debug: [179421] starting stressors
stress-ng: debug: [179422] stress-ng-mmap: started [179422] (instance 0)
stress-ng: debug: [179423] stress-ng-mmap: started [179423] (instance 1)
stress-ng: debug: [179424] stress-ng-mmap: started [179424] (instance 2)
stress-ng: debug: [179421] 4 stressors spawned
stress-ng: debug: [179425] stress-ng-mmap: started [179425] (instance 3)
stress-ng: debug: [179424] stress-ng-mmap: exited [179424] (instance 2)
stress-ng: debug: [179422] stress-ng-mmap: exited [179422] (instance 0)
stress-ng: debug: [179421] process [179422] terminated
stress-ng: debug: [179421] process 179423 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179423] terminated
stress-ng: debug: [179421] process [179424] terminated
stress-ng: debug: [179421] process 179425 (stress-ng-mmap) terminated on signal: 7 (Bus error)
stress-ng: debug: [179421] process [179425] terminated
stress-ng: info: [179421] unsuccessful run completed in 300.68s (5 mins, 0.68 secs)
That is the only info I have for the failure, unfortunately.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: stress-ng 0.05.23-1
ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
Uname: Linux 4.4.0-18-generic s390x
ApportVersion: 2.20.1-0ubuntu1
Architecture: s390x
Date: Tue Apr 12 12:47:49 2016
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: stress-ng
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2016-04-22 11:20:09 |
Colin Ian King |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-04-22 11:21:44 |
Colin Ian King |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-04-22 11:21:44 |
Colin Ian King |
bug task added |
|
stress-ng (Ubuntu Xenial) |
|
| 2016-04-22 11:21:52 |
Colin Ian King |
stress-ng (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2016-04-22 11:21:54 |
Colin Ian King |
stress-ng (Ubuntu Xenial): assignee |
|
Colin Ian King (colin-king) |
|
| 2016-04-22 11:21:57 |
Colin Ian King |
stress-ng (Ubuntu Xenial): status |
New |
In Progress |
|
| 2016-04-26 08:55:33 |
Martin Pitt |
stress-ng (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2016-04-26 08:55:36 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2016-04-26 08:55:40 |
Martin Pitt |
tags |
apport-bug blocks-hwcert-server s390x xenial |
apport-bug blocks-hwcert-server s390x verification-needed xenial |
|
| 2016-04-26 22:51:10 |
Launchpad Janitor |
stress-ng (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2016-04-28 14:39:47 |
Colin Ian King |
tags |
apport-bug blocks-hwcert-server s390x verification-needed xenial |
apport-bug blocks-hwcert-server s390x verification-done xenial |
|
| 2016-05-04 16:59:09 |
Launchpad Janitor |
stress-ng (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-05-04 16:59:14 |
Chris J Arges |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
