I spend some time to make tools/testing/selftest/rcutorture run on PPC,
here are some documention and fixes made while I was trying.
The scripts are able to run and get results on PPC, however please
note there are some stalls even build errors that could be found
by the tests currently.
As I'm certainly not an expert of qemu or bash programming, there
may be something I am missing in those patches. So tests and comments
are welcome ;-)
Regards,
Boqun
Boqun Feng (4):
rcutorture/doc: Add a new way to create initrd using dracut
rcutorture: Use vmlinux as the fallback kernel image
rcutorture: Make -soundhw a x86 specific option
rcutorture: Don't specify the cpu type of QEMU on PPC
.../testing/selftests/rcutorture/bin/functions.sh | 13 ++++++-------
.../selftests/rcutorture/bin/kvm-test-1-run.sh | 13 +++++++------
tools/testing/selftests/rcutorture/doc/initrd.txt | 22 ++++++++++++++++++++++
3 files changed, 35 insertions(+), 13 deletions(-)
--
2.8.0
Using dracut is another way to get an initramfs for kvm based rcu
torture tests, which is more flexible than using the host's initramfs
image, because modules and binaries may be added or removed via dracut
command options. So add an example in the document, in case that there
are some situations where host's initramfs couldn't be used.
Signed-off-by: Boqun Feng <redacted>
---
tools/testing/selftests/rcutorture/doc/initrd.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
@@ -13,6 +13,22 @@ cd initrd cpio -id < /tmp/initrd.img.zcat ------------------------------------------------------------------------+Another way to create an initramfs image is using "dracut"[1], which is+available on many distros, however the initramfs dracut generates is a cpio+archive with another cpio archive in it, so an extra step is needed to create+the initrd directory hierarchy.++Here are the commands to create a initrd directory for rcutorture using+dracut:++------------------------------------------------------------------------+dracut --no-hostonly --no-hostonly-cmdline --module "base bash shutdown" /tmp/initramfs.img+cd tools/testing/selftests/rcutorture+mkdir initrd+cd initrd+/usr/lib/dracut/skipcpio /tmp/initramfs.img | zcat | cpio -id < /tmp/initramfs.img+------------------------------------------------------------------------+ Interestingly enough, if you are running rcutorture, you don't really need userspace in many cases. Running without userspace has the advantage of allowing you to test your kernel independently of the
@@ -89,3 +105,9 @@ while : do sleep 10 done+------------------------------------------------------------------------++References:+[1]: https://dracut.wiki.kernel.org/index.php/Main_Page+[2]: http://blog.elastocloud.org/2015/06/rapid-linux-kernel-devtest-with-qemu.html+[3]: https://www.centos.org/forums/viewtopic.php?t=51621
vmlinux is available for all the architectures, and suitable for running
a KVM guest by QEMU, besides, we used to copy the vmlinux to $resdir
anyway. Therefore it makes sense to use it as the fallback kernel image
for rcutorture KVM tests.
This patch makes identify_boot_image() return vmlinux if
${TORTURE_BOOT_IMAGE} is not set on non-x86 architectures, also fixes
several places that hard-code "bzImage" as $KERNEL.
This also fixes a problem that PPC doesn't have a bzImage file as build
results.
Signed-off-by: Boqun Feng <redacted>
---
tools/testing/selftests/rcutorture/bin/functions.sh | 10 ++++------
tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 5 +++--
2 files changed, 7 insertions(+), 8 deletions(-)
@@ -99,8 +99,9 @@ configfrag_hotplug_cpu () {# identify_boot_image qemu-cmd## Returns the relative path to the kernel build image. This will be-# arch/<arch>/boot/bzImage unless overridden with the TORTURE_BOOT_IMAGE-# environment variable.+# arch/<arch>/boot/bzImage or vmlinux if bzImage is not a target for the+# architecture, unless overridden with the TORTURE_BOOT_IMAGE environment+# variable. identify_boot_image(){iftest-n"$TORTURE_BOOT_IMAGE"then
@@ -96,7 +96,8 @@ if test "$base_resdir" != "$resdir" -a -f $base_resdir/bzImage -a -f $base_resdithen# Rerunning previous test, so use that test's kernel.QEMU="`identify_qemu $base_resdir/vmlinux`"-KERNEL=$base_resdir/bzImage+BOOT_IMAGE="`identify_boot_image $QEMU`"+KERNEL=$base_resdir/${BOOT_IMAGE##*/}# use the last component of ${BOOT_IMAGE}ln-s$base_resdir/Make*.out$resdir# for kvm-recheck.shln-s$base_resdir/.config$resdir# for kvm-recheck.shelifkvm-build.sh$config_template$builddir$T
The option "-soundhw pcspk" gives me a error on PPC as follow:
qemu-system-ppc64: ISA bus not available for pcspk
, which means this option doesn't work on ppc by default. So simply make
this an x86-specific option via identify_qemu_args().
Signed-off-by: Boqun Feng <redacted>
---
tools/testing/selftests/rcutorture/bin/functions.sh | 1 +
tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 8 ++++----
2 files changed, 5 insertions(+), 4 deletions(-)
@@ -8,9 +8,9 @@## Usage: kvm-test-1-run.sh config builddir resdir seconds qemu-args boot_args#-# qemu-args defaults to "-enable-kvm -soundhw pcspk -nographic", along with-# arguments specifying the number of CPUs and other-# options generated from the underlying CPU architecture.+# qemu-args defaults to "-enable-kvm -nographic", along with arguments+# specifying the number of CPUs and other options+# generated from the underlying CPU architecture.# boot_args defaults to value returned by the per_version_boot_params# shell function.#
Do not restrict the cpu type to POWER7 for QEMU as we have POWER8 now.
Signed-off-by: Boqun Feng <redacted>
---
tools/testing/selftests/rcutorture/bin/functions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
The option "-soundhw pcspk" gives me a error on PPC as follow:
qemu-system-ppc64: ISA bus not available for pcspk
, which means this option doesn't work on ppc by default. So simply make
this an x86-specific option via identify_qemu_args().
Signed-off-by: Boqun Feng <redacted>
The emulated system for RCU testing does not need sound hardware at all.
Paul added this option in commit
16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
hardware, saying that '"-soundhw pcspk" makes the script a bit less
dependent on odd audio libraries being installed'. Unfortunately, it
looks like there isn't a "-soundhw none". As far as I can tell,
currently the only way to completely eliminate sound hardware is to pass
"-nodefaults" and then explicitly specify each desired device; while
that would solve the issue, it would likely introduce *more*
hardware-specific command-line options...
I've filed two feature requests on upstream qemu to make this simpler:
https://bugs.launchpad.net/qemu/+bug/1583420 and
https://bugs.launchpad.net/qemu/+bug/1583421 .
Paul, what did you mean by "dependent on odd audio libraries"? Did you
mean in the guest or the host? And either way, is this something that
could potentially be solved another way?
- Josh Triplett
On Thu, May 19, 2016 at 11:42:20AM +0800, Boqun Feng wrote:
I spend some time to make tools/testing/selftest/rcutorture run on PPC,
here are some documention and fixes made while I was trying.
The scripts are able to run and get results on PPC, however please
note there are some stalls even build errors that could be found
by the tests currently.
As I'm certainly not an expert of qemu or bash programming, there
may be something I am missing in those patches. So tests and comments
are welcome ;-)
Regards,
Boqun
Boqun Feng (4):
rcutorture/doc: Add a new way to create initrd using dracut
rcutorture: Use vmlinux as the fallback kernel image
rcutorture: Make -soundhw a x86 specific option
rcutorture: Don't specify the cpu type of QEMU on PPC
All four of these seem reasonable to me:
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
I responded to the -soundhw patch, trying to track down why that option
was needed in the first place, and seeking a solution that doesn't
require adding to the set of target-specific options. But I don't think
that investigation should block your fix.
From: Paul E. McKenney <hidden> Date: 2016-05-19 14:10:19
On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
quoted
The option "-soundhw pcspk" gives me a error on PPC as follow:
qemu-system-ppc64: ISA bus not available for pcspk
, which means this option doesn't work on ppc by default. So simply make
this an x86-specific option via identify_qemu_args().
Signed-off-by: Boqun Feng <redacted>
The emulated system for RCU testing does not need sound hardware at all.
Paul added this option in commit
16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
hardware, saying that '"-soundhw pcspk" makes the script a bit less
dependent on odd audio libraries being installed'. Unfortunately, it
looks like there isn't a "-soundhw none". As far as I can tell,
currently the only way to completely eliminate sound hardware is to pass
"-nodefaults" and then explicitly specify each desired device; while
that would solve the issue, it would likely introduce *more*
hardware-specific command-line options...
I've filed two feature requests on upstream qemu to make this simpler:
https://bugs.launchpad.net/qemu/+bug/1583420 and
https://bugs.launchpad.net/qemu/+bug/1583421 .
Paul, what did you mean by "dependent on odd audio libraries"? Did you
mean in the guest or the host? And either way, is this something that
could potentially be solved another way?
If I remember correctly, Ubuntu 14.04 qemu refused to run the guest
without this option, but I don't recall the exact error message.
I chalked it up to my ignorance of qemu, but I would very much welcome
some way to not have to specify irrelevant hardware. So thank you very
much for filing the bugs!
Thanx, Paul
From: Paul E. McKenney <hidden> Date: 2016-05-19 14:14:03
On Wed, May 18, 2016 at 09:25:17PM -0700, Josh Triplett wrote:
On Thu, May 19, 2016 at 11:42:20AM +0800, Boqun Feng wrote:
quoted
I spend some time to make tools/testing/selftest/rcutorture run on PPC,
here are some documention and fixes made while I was trying.
The scripts are able to run and get results on PPC, however please
note there are some stalls even build errors that could be found
by the tests currently.
As I'm certainly not an expert of qemu or bash programming, there
may be something I am missing in those patches. So tests and comments
are welcome ;-)
Regards,
Boqun
Boqun Feng (4):
rcutorture/doc: Add a new way to create initrd using dracut
rcutorture: Use vmlinux as the fallback kernel image
rcutorture: Make -soundhw a x86 specific option
rcutorture: Don't specify the cpu type of QEMU on PPC
All four of these seem reasonable to me:
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Thank you both! I have queued all four for further review and for
testing.
I responded to the -soundhw patch, trying to track down why that option
was needed in the first place, and seeking a solution that doesn't
require adding to the set of target-specific options. But I don't think
that investigation should block your fix.
Agreed, it should work better now than it did before!
Thanx, Paul
On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
quoted
On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
quoted
The option "-soundhw pcspk" gives me a error on PPC as follow:
qemu-system-ppc64: ISA bus not available for pcspk
, which means this option doesn't work on ppc by default. So simply make
this an x86-specific option via identify_qemu_args().
Signed-off-by: Boqun Feng <redacted>
The emulated system for RCU testing does not need sound hardware at all.
Paul added this option in commit
16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
hardware, saying that '"-soundhw pcspk" makes the script a bit less
dependent on odd audio libraries being installed'. Unfortunately, it
looks like there isn't a "-soundhw none". As far as I can tell,
currently the only way to completely eliminate sound hardware is to pass
"-nodefaults" and then explicitly specify each desired device; while
that would solve the issue, it would likely introduce *more*
hardware-specific command-line options...
I've filed two feature requests on upstream qemu to make this simpler:
https://bugs.launchpad.net/qemu/+bug/1583420 and
https://bugs.launchpad.net/qemu/+bug/1583421 .
Paul, what did you mean by "dependent on odd audio libraries"? Did you
mean in the guest or the host? And either way, is this something that
could potentially be solved another way?
If I remember correctly, Ubuntu 14.04 qemu refused to run the guest
without this option, but I don't recall the exact error message.
I chalked it up to my ignorance of qemu, but I would very much welcome
some way to not have to specify irrelevant hardware. So thank you very
much for filing the bugs!
According to qemu upstream, qemu doesn't enable any sound hardware by
default, so I can't think of any obvious reason why adding "-soundhw
pcspkr" would make the rcutorture VM boot. Did qemu refuse to run at
all, or did the VM start but fail during the boot process?
Could you check if you can currently run without this option? If so,
perhaps we should just drop it for now.
- Josh Triplett
From: Paul E. McKenney <hidden> Date: 2016-05-19 16:23:39
On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
quoted
On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
quoted
On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
quoted
The option "-soundhw pcspk" gives me a error on PPC as follow:
qemu-system-ppc64: ISA bus not available for pcspk
, which means this option doesn't work on ppc by default. So simply make
this an x86-specific option via identify_qemu_args().
Signed-off-by: Boqun Feng <redacted>
The emulated system for RCU testing does not need sound hardware at all.
Paul added this option in commit
16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
hardware, saying that '"-soundhw pcspk" makes the script a bit less
dependent on odd audio libraries being installed'. Unfortunately, it
looks like there isn't a "-soundhw none". As far as I can tell,
currently the only way to completely eliminate sound hardware is to pass
"-nodefaults" and then explicitly specify each desired device; while
that would solve the issue, it would likely introduce *more*
hardware-specific command-line options...
I've filed two feature requests on upstream qemu to make this simpler:
https://bugs.launchpad.net/qemu/+bug/1583420 and
https://bugs.launchpad.net/qemu/+bug/1583421 .
Paul, what did you mean by "dependent on odd audio libraries"? Did you
mean in the guest or the host? And either way, is this something that
could potentially be solved another way?
If I remember correctly, Ubuntu 14.04 qemu refused to run the guest
without this option, but I don't recall the exact error message.
I chalked it up to my ignorance of qemu, but I would very much welcome
some way to not have to specify irrelevant hardware. So thank you very
much for filing the bugs!
According to qemu upstream, qemu doesn't enable any sound hardware by
default, so I can't think of any obvious reason why adding "-soundhw
pcspkr" would make the rcutorture VM boot. Did qemu refuse to run at
all, or did the VM start but fail during the boot process?
Could you check if you can currently run without this option? If so,
perhaps we should just drop it for now.
Will do! As soon as the current test completes.
BTW, am I the only one getting "interesting" failures in the merge
window?
Thanx, Paul
From: Paul E. McKenney <hidden> Date: 2016-05-19 19:38:48
On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote:
On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
quoted
On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
quoted
On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
quoted
On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
quoted
The option "-soundhw pcspk" gives me a error on PPC as follow:
qemu-system-ppc64: ISA bus not available for pcspk
, which means this option doesn't work on ppc by default. So simply make
this an x86-specific option via identify_qemu_args().
Signed-off-by: Boqun Feng <redacted>
The emulated system for RCU testing does not need sound hardware at all.
Paul added this option in commit
16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
hardware, saying that '"-soundhw pcspk" makes the script a bit less
dependent on odd audio libraries being installed'. Unfortunately, it
looks like there isn't a "-soundhw none". As far as I can tell,
currently the only way to completely eliminate sound hardware is to pass
"-nodefaults" and then explicitly specify each desired device; while
that would solve the issue, it would likely introduce *more*
hardware-specific command-line options...
I've filed two feature requests on upstream qemu to make this simpler:
https://bugs.launchpad.net/qemu/+bug/1583420 and
https://bugs.launchpad.net/qemu/+bug/1583421 .
Paul, what did you mean by "dependent on odd audio libraries"? Did you
mean in the guest or the host? And either way, is this something that
could potentially be solved another way?
If I remember correctly, Ubuntu 14.04 qemu refused to run the guest
without this option, but I don't recall the exact error message.
I chalked it up to my ignorance of qemu, but I would very much welcome
some way to not have to specify irrelevant hardware. So thank you very
much for filing the bugs!
According to qemu upstream, qemu doesn't enable any sound hardware by
default, so I can't think of any obvious reason why adding "-soundhw
pcspkr" would make the rcutorture VM boot. Did qemu refuse to run at
all, or did the VM start but fail during the boot process?
Could you check if you can currently run without this option? If so,
perhaps we should just drop it for now.
Will do! As soon as the current test completes.
And it now works just fine without the "-soundhw pcspkr". Search me!
BTW, am I the only one getting "interesting" failures in the merge
window?
I will be chasing these down, but am likely to be off the grid until
Monday morning, Pacific time. Looks like the same failure to awaken
as before, but much higher probability.
Thanx, Paul
On Thu, May 19, 2016 at 12:38:47PM -0700, Paul E. McKenney wrote:
On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote:
quoted
On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
quoted
On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
quoted
On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
quoted
On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
quoted
The option "-soundhw pcspk" gives me a error on PPC as follow:
qemu-system-ppc64: ISA bus not available for pcspk
, which means this option doesn't work on ppc by default. So simply make
this an x86-specific option via identify_qemu_args().
Signed-off-by: Boqun Feng <redacted>
The emulated system for RCU testing does not need sound hardware at all.
Paul added this option in commit
16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
hardware, saying that '"-soundhw pcspk" makes the script a bit less
dependent on odd audio libraries being installed'. Unfortunately, it
looks like there isn't a "-soundhw none". As far as I can tell,
currently the only way to completely eliminate sound hardware is to pass
"-nodefaults" and then explicitly specify each desired device; while
that would solve the issue, it would likely introduce *more*
hardware-specific command-line options...
I've filed two feature requests on upstream qemu to make this simpler:
https://bugs.launchpad.net/qemu/+bug/1583420 and
https://bugs.launchpad.net/qemu/+bug/1583421 .
Paul, what did you mean by "dependent on odd audio libraries"? Did you
mean in the guest or the host? And either way, is this something that
could potentially be solved another way?
If I remember correctly, Ubuntu 14.04 qemu refused to run the guest
without this option, but I don't recall the exact error message.
I chalked it up to my ignorance of qemu, but I would very much welcome
some way to not have to specify irrelevant hardware. So thank you very
much for filing the bugs!
According to qemu upstream, qemu doesn't enable any sound hardware by
default, so I can't think of any obvious reason why adding "-soundhw
pcspkr" would make the rcutorture VM boot. Did qemu refuse to run at
all, or did the VM start but fail during the boot process?
Could you check if you can currently run without this option? If so,
perhaps we should just drop it for now.
Will do! As soon as the current test completes.
And it now works just fine without the "-soundhw pcspkr". Search me!
In that case, can you replace the patch in this series making "-soundhw
pcspkr" target-specific with one removing "-soundhw pcspkr"?
- Josh Triplett
From: Paul E. McKenney <hidden> Date: 2016-05-23 21:21:13
On Thu, May 19, 2016 at 01:24:12PM -0700, Josh Triplett wrote:
On Thu, May 19, 2016 at 12:38:47PM -0700, Paul E. McKenney wrote:
quoted
On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote:
quoted
On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
quoted
On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
quoted
On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
quoted
On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
quoted
The option "-soundhw pcspk" gives me a error on PPC as follow:
qemu-system-ppc64: ISA bus not available for pcspk
, which means this option doesn't work on ppc by default. So simply make
this an x86-specific option via identify_qemu_args().
Signed-off-by: Boqun Feng <redacted>
The emulated system for RCU testing does not need sound hardware at all.
Paul added this option in commit
16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
hardware, saying that '"-soundhw pcspk" makes the script a bit less
dependent on odd audio libraries being installed'. Unfortunately, it
looks like there isn't a "-soundhw none". As far as I can tell,
currently the only way to completely eliminate sound hardware is to pass
"-nodefaults" and then explicitly specify each desired device; while
that would solve the issue, it would likely introduce *more*
hardware-specific command-line options...
I've filed two feature requests on upstream qemu to make this simpler:
https://bugs.launchpad.net/qemu/+bug/1583420 and
https://bugs.launchpad.net/qemu/+bug/1583421 .
Paul, what did you mean by "dependent on odd audio libraries"? Did you
mean in the guest or the host? And either way, is this something that
could potentially be solved another way?
If I remember correctly, Ubuntu 14.04 qemu refused to run the guest
without this option, but I don't recall the exact error message.
I chalked it up to my ignorance of qemu, but I would very much welcome
some way to not have to specify irrelevant hardware. So thank you very
much for filing the bugs!
According to qemu upstream, qemu doesn't enable any sound hardware by
default, so I can't think of any obvious reason why adding "-soundhw
pcspkr" would make the rcutorture VM boot. Did qemu refuse to run at
all, or did the VM start but fail during the boot process?
Could you check if you can currently run without this option? If so,
perhaps we should just drop it for now.
Will do! As soon as the current test completes.
And it now works just fine without the "-soundhw pcspkr". Search me!
In that case, can you replace the patch in this series making "-soundhw
pcspkr" target-specific with one removing "-soundhw pcspkr"?
Fair point! I queued the patch below, and am now testing it.
Thanx, Paul
------------------------------------------------------------------------
commit d6126c701fe19c965cbb54cd5221da0db3287135
Author: Paul E. McKenney [off-list ref]
Date: Mon May 23 14:18:48 2016 -0700
rcutorture: Drop "-soundhw pcspkr" from x86 boot arguments
Because recent testing shows that "-soundhw pcspkr" is no longer required
in the kernel boot arguments, this commit drops this qemu argument.
Reported-by: Josh Triplett [off-list ref]
Signed-off-by: Paul E. McKenney [off-list ref]