Re: [PATCH v4] Makefile.compiler: replace cc-ifversion with compiler-specific macros

From: Nick Desaulniers <ndesaulniers@google.com>
To: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
Cc: Shreeya Patel <shreeya.patel@collabora.com>,
	Michal Marek <michal.lkml@markovi.net>,
	 Masahiro Yamada <masahiroy@kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	clang-built-linux <llvm@lists.linux.dev>,
	 Bill Wendling <morbo@google.com>,
	Nathan Chancellor <nathan@kernel.org>,
	regressions@lists.linux.dev,
	 "gustavo.padovan@collabora.com" <gustavo.padovan@collabora.com>,
	 Guillaume Charles Tucker <guillaume.tucker@collabora.com>,
	denys.f@collabora.com,  kernelci@lists.linux.dev
Subject: Re: [PATCH v4] Makefile.compiler: replace cc-ifversion with compiler-specific macros
Date: Thu, 18 May 2023 14:12:30 -0700	[thread overview]
Message-ID: <CAKwvOd=8LVU+iANkFx18Wm1jg7gYiAXovAmo9t5ZZaVdMULn-Q@mail.gmail.com> (raw)
In-Reply-To: <878rdlk9bi.fsf@rcn-XPS-13-9305.i-did-not-set--mail-host-address--so-tickle-me>

On Thu, May 18, 2023 at 7:23 AM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
>
>
> Hi Nick,
>
> On mié, may 17 2023 at 09:27:41, Nick Desaulniers <ndesaulniers@google.com> wrote:
> > Shreeya mentioned upthread that `qemu_arm-virt-gicv3-uefi` was
> > failing, so I assume others should be able to repro in qemu. I'd guess
> > that LAVA lets you have VMs adjacent to physical hardware.  Having the
> > qemu command line, kernel config, and perhaps the initramfs are going
> > to be the three most useful things for any similar bug report.
>
> Sure, I'm using LAVA because that's the safest way to match exactly the
> same setup from the original test, but anyone can try to reproduce it on
> their own. You can get the job info and setup from any of the related
> LAVA jobs. This one for example:
> https://lava.collabora.dev/scheduler/job/10373216
>
> Trying to reproduce this type of setups is not as straightforward as
> we'd like, specially for people not familiar with KernelCI, but we're
> putting in some effort to improve that so that anyone can pick up a
> regression report and work on it right away.

Yeah makes sense.  Having reports surface the most relevant info for
developers to understand what went wrong where and how to reproduce is
something I'm passionate about.  We've been through this with Intel
0day bot folks; it takes a few iterations until everyone is happy.

>
> By the way, I found a breaking point in the commit right after the one
> that the bisector reported:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5750121ae7382ebac8d47ce6d68012d6cd1d7926

That's a higher risk change (and has my name on the tested-by tag, yikes).

So is that the culprit of the boot failure you're observing?

> but I can't find anything there either that makes the boot hang,
> specifically for configs including kernel/configs/debug.config. I
> wouldn't rule out a problem with the qemu configuration.
>
> Anyway, this is not a critical problem in any way, although it'd be

But you still have a boot failure/regression to track down for that
config, right?

> interesting to find the cause in case we can use the findings to improve
> the test setups.
>
> Cheers,
> Ricardo

-- 
Thanks,
~Nick Desaulniers