----- Original Message -----
From: "Jiri Benc" <jbenc(a)redhat.com>
To: "Don Zickus" <dzickus(a)redhat.com>
Cc: "CKI Project" <cki-project(a)redhat.com>,
kernel(a)lists.fedoraproject.org, "Veronika Kabatova" <vkabatov(a)redhat.com>
Sent: Tuesday, October 20, 2020 9:45:54 AM
Subject: Re: ❌ FAIL: Test report for kernel 5.9.0-42.test.fc33 (ark)
On Mon, 19 Oct 2020 16:12:12 -0400, Don Zickus wrote:
> Sorry about that. I thought things were failing because of ARK infra but
> now they are failing due to libbpf on s390x. Does bpf compile there?
>
[...]
> 00:01:25 LINK resolve_btfids
> 00:04:11 libbpf: non-native ELF endianness is not supported
These are older pipelines that are waiting for
https://lore.kernel.org/bpf/20201008234000.740660-9-andrii@kernel.org/T/#u
to be merged into mainline/ARK. We're also in contact with Jirka Olsa
due to a different bpf issue with resolve_btfids (not s390x-specific).
If you check out the new results, they are due to broken ARK configs.
Thanks for the log. The problem seems to be the cross-compiling.
While eBPF was supposed to be architecture independent byte code, the
authors failed in reaching the goal - eBPF is not endianess neutral.
eBPF byte code compiled on a little endian machine cannot be used on a
big endian machine and vice versa.
Now, libbpf does non-trivial rewriting of eBPF code (you can think of
it as a compiler of sort). And apparently, libbpf compiled and running
on a little endian machine cannot handle big endian eBPF byte code.
I'm not sure what exactly is causing this failure. My guess would be
CONFIG_DEBUG_INFO_BTF. If I'm right, we'll probably have to disable it
on s390x while cross compiling for the time being. Could you try a
cross-compile with CONFIG_DEBUG_INFO_BTF disabled? It's something that
will have to be done only for cross-compiling, we want that config
option enabled on native builds.
On a related note, if this is the cause of the CKI failures, I wonder
why the log snippet you quoted was not the very first thing in the
emails? We talked about the CKI email format before and I think there's
still a lot of room for improvements there. It should be immediately
obvious what went wrong from the email, while currently, it requires a
CKI expert to actually interpret it.
Agreed. We do have this functionality on the list. Unfortunately the
implementation was pushed back due to all the work on the workflow
changes, as we don't have time/people to work on everything at once.
As I side note, I'll be updating the email configs based on Justin's
suggestion later today.
Veronika
Thanks,
Jiri
_______________________________________________
kernel mailing list -- kernel(a)lists.fedoraproject.org
To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org