----- Original Message ----- > From: "Jiri Benc" <jbenc@xxxxxxxxxx> > To: "Don Zickus" <dzickus@xxxxxxxxxx> > Cc: "CKI Project" <cki-project@xxxxxxxxxx>, kernel@xxxxxxxxxxxxxxxxxxxxxxx, "Veronika Kabatova" <vkabatov@xxxxxxxxxx> > 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@xxxxxxxxxx/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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
