Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Mark Brown <broonie@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Anders Roxell <anders.roxell@linaro.org>,
	Muhammad Usama Anjum <usama.anjum@collabora.com>,
	<linux-kselftest@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] selftests: Fix arm64 test installation
Date: Mon, 10 Jul 2023 16:10:14 -0700	[thread overview]
Message-ID: <04724b21-6c7c-8584-fd17-9222051dc99d@nvidia.com> (raw)
In-Reply-To: <ZKyGh8AKRLobQKlX@finisterre.sirena.org.uk>

On 7/10/23 15:30, Mark Brown wrote:
...
> There is a floor on binutils version for the kselftests that's more
> aggressive than that for the kernel itself, though that looks like RHEL
> 8 which has binutils 2.30 which *should* be fine for most things - the
> MTE tests won't build but they do have version detection so should skip,
> I guess you might have trouble with PAC support which doesn't have
> detection in the tests?  It's certainly old enough that I'm surprised to
> hear someone doing development for anything current with it.

This used to be a development machine, but now it is sufficiently old
that it is lightly used--that would explain how I could reserve it on
short notice for this. Maybe I'll adopt it and upgrade to a modern
distro, now that I seem to need an arm64 box.

> 
> I just tried a Debian based GCC 8 container which seems pretty happy
> for arm64, the command was:
> 
> make -j16 O=/tmp/out INSTALL_PATH=/tmp/kselftest \
> 	ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
> 	CROSS_COMPILE_COMPAT=arm-linux-gnueabihf- kselftest-install
> 
> (the compat toolchain isn't used here IIRC).  It does skip the MTE tests
> but otherwise isn't showing any obvious issues in the arm64 tests.
> 

Thank you for providing a snapshot of what it looks like on gcc 8
over there.

OK, so actually, many of the failures were due to the "all" target
getting run too early (recursive make, again, uggh). With the fix below,
there are still a dozen failures in selftests, but only one in the arm64
tree, after all.

...
> That does seem to work around the issue at least with a quick out of
> tree build, including with GCC 8.

Great news! That's really helpful. And in fact, I have discovered two
more things:

1) The "emit_tests" target is there apparently because commit
313a4db7f3387 ("kselftest: arm64: extend toplevel skeleton Makefile")
believed that it was necessary to skip emitting tests if not on the
right native platform. I'm tempted to delete the entire emit_tests
target in both arm64 and riscv selftests (and that also seems to work
just fine) in order to simplify things, perhaps as a follow up step.

For now I'll just post the simpler fix, though.

2) riscv has copied this Makefile subtest technique to its (very small
so far) set of selftests. I have no native system to test any fixes on,
but I'm probably going to post a "blind" fix for that one, too.


thanks,
-- 
John Hubbard
NVIDIA


  reply	other threads:[~2023-07-10 23:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-10 14:04 [PATCH] selftests: Fix arm64 test installation Mark Brown
2023-07-10 20:22 ` John Hubbard
2023-07-10 21:20   ` Mark Brown
2023-07-10 21:31     ` John Hubbard
2023-07-10 22:30       ` Mark Brown
2023-07-10 23:10         ` John Hubbard [this message]
2023-07-11 14:00           ` Mark Brown
2023-07-13 20:02 ` Shuah Khan
2023-07-13 20:16   ` John Hubbard
2023-07-14 17:48     ` Shuah Khan
2023-07-14 18:09       ` Mark Brown
2023-07-14 18:19         ` John Hubbard
2023-07-14 18:26           ` Andrew Morton
2023-07-14 18:32             ` Shuah Khan
2023-07-14 18:36               ` John Hubbard
2023-07-14 19:11                 ` Shuah Khan
2023-07-14 19:39                   ` John Hubbard
2023-07-18 14:54                   ` Mark Brown
2023-07-18 14:56                     ` Shuah Khan
2023-07-18 14:57                       ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04724b21-6c7c-8584-fd17-9222051dc99d@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=anders.roxell@linaro.org \
    --cc=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=usama.anjum@collabora.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox