12:03:02 <jki> #startmeeting CIP IRC weekly meeting
12:03:02 <collab-meetbot`> Meeting started Thu Aug  4 12:03:02 2022 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:03:02 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:03:02 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:03:18 <jki> #topic AI review
12:03:25 <jki> 1. Resolve/ignore failures of KernelCI on 4.4-cip - alicefm
12:04:10 <alicef> fbezdeka  pr as been merged
12:04:33 <fbezdeka> Build failures should be resolved, there were some test failures now
12:04:47 <alicef> https://github.com/kernelci/kernelci-core/pull/1299
12:05:26 <jki> great news
12:05:40 <jki> who's looking into the test failures right now?
12:05:51 <fbezdeka> Thanks for your support, alicef.
12:06:34 <fbezdeka> One report was a board/lab issue, and some CVEs were found
12:07:49 <alicef> we could probably just skip chromebooks as they are not relevant for cip at the moment
12:08:13 <patersonc[m]> Do you have a link to the nfs issue?
12:08:18 <fbezdeka> Maybe... I'm not sure. It's still a x68_64 defconfig, isn't it?
12:08:49 <jki> if that is true, I would not too quickly drop that target
12:09:03 <alicef> ok
12:09:17 <fbezdeka> nfs: https://storage.staging.kernelci.org/cip/linux-4.4.y-cip/v4.4.302-cip69-517-g92709d8ae585/arm/omap2plus_defconfig/gcc-10/lab-cip/baseline-cip-nfs-beaglebone-black.html
12:11:23 <patersonc[m]> Could have been a lab issue I guess
12:11:31 <patersonc[m]> Or does it alway happen?
12:11:43 <patersonc[m]> s/alway/always/
12:11:45 <iwamatsu> CIP'
12:12:00 <iwamatsu> CIP's BBB log: https://lava.ciplatform.org/scheduler/job/719474
12:12:14 <fbezdeka> Can't tell if it happens every time...
12:12:22 <fbezdeka> reported CVEs for 4.4-cip: https://staging.kernelci.org/test/job/cip/branch/linux-4.4.y-cip/kernel/v4.4.302-cip69-517-g92709d8ae585/plan/smc/
12:13:51 <pave1> Well, if someone wants to translate that to human terms...
12:13:58 <pave1> ...but it is probably WONTFIX anyway :-).
12:14:29 <jki> means we now need filter list for CVE tests??
12:14:33 <alicef> the smc cve are probably same as cip lab smc cve
12:14:54 <alicef> just probably kernelci with a more updated version of smc
12:15:01 <pave1> jki: It is arm64, for start. Plus it claims qemu has spectre problem. So ... someone fix the test :-).
12:15:32 <jki> where are those tests maintained? also in kernelci context?
12:16:00 <jki> and, yes, arm64 should be filtered both from builds and tests on 4.4-cip
12:16:28 <alicef> linaro: https://github.com/Linaro/test-definitions/tree/master/automated/linux/spectre-meltdown-checker-test
12:18:26 <jki> are all CVEs reported by the test already tracked in our https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec?
12:19:06 <jki> means, do we just need to translate the descisions into a filter list, or do we still need an expert review of them
12:20:01 <fbezdeka> If arm64 is out of scope for 4.4-cip, I could try to filter that with another kernelci MR
12:20:31 <jki> fbezdeka: that would be great, TIA
12:21:30 <jki> anything else about this for now?
12:21:37 <uli> 'phy \"4a101000.mdio:00\" not found' in https://storage.staging.kernelci.org/cip/linux-4.4.y-cip/v4.4.302-cip69-517-g92709d8ae585/arm/[...] vs 'net eth0: phy found : id is : 0x7c0f1' in https://lava.ciplatform.org/scheduler/job/719474
12:21:55 <uli> it smells to me like something is broken in that first board.
12:22:00 <uli> or the driver is marginal somehow
12:22:52 <alicef> also lab cip have some similar error net eth0: phy \"4a101000.mdio:01\" not found on slave 1, err -19
12:23:03 <alicef> from https://lava.ciplatform.org/scheduler/job/719474
12:23:25 <uli> it might actually not have the second phy, because that occurs in both logs
12:23:38 <uli> but i don't actually know that board, i just had a look at the log right now
12:23:50 <masami> I checked. CVE-2018-3615 isn't tracked in cip-kernel-sec.
12:26:45 <jki> ok, then I guess someone should also check that
12:27:06 <jki> if our tracking is complete
12:27:30 <masami> CVE-2018-3615 is Intel SGX's problem, arm64 doesn't affect. Intel published micro code for the fix.
12:29:09 <jki> if nothing needs / can to be done on kernel, we don't need to do anything for it, just ignore it
12:30:32 <jki> but let's see what all remains after arm64 is filtered
12:30:37 <jki> next topic?
12:31:09 <jki> 3
12:31:10 <jki> 2
12:31:12 <jki> 1
12:31:16 <jki> 2. Check cip devices on kernelci old pull request - patersonc
12:32:01 <patersonc[m]> No time yet, sorry
12:32:40 <jki> other AIs I missed?
12:32:49 <jki> 3
12:32:52 <jki> 2
12:32:54 <jki> 1
12:32:56 <jki> #topic Kernel maintenance updates
12:33:19 <uli> reviewed 5.10.135
12:33:47 <masami> there was 5 new CVEs and 4 updated CVEs. I think no notable issues.
12:33:53 <pave1> 5.10.135 and 136 reviews.
12:34:00 <pave1> 4.4-rt release.
12:34:20 <iwamatsu> I reviewed 5.10.135
12:34:21 <pave1> I'll still need to look at Xen and write mail about that.
12:36:37 <jki> anything else here?
12:38:13 <jki> 3
12:38:14 <jki> 2
12:38:16 <jki> 1
12:38:19 <jki> #topic Kernel testing
12:39:04 <patersonc[m]> Most work was on the KernelCI MR, and getting the Renesas lava lab back online
12:39:17 <patersonc[m]> I don't know if you have any other topics Alice?
12:40:02 <pave1> I wonder if we want to start compile-testing various defconfigs for 4.4. I'd even include arm64 and other unsupported architectures if it is easy.
12:40:21 <pave1> Avoiding regressions is easy if they are catched soon...
12:41:15 <patersonc[m]> Didn't we just take out a load of arm64 stuff from 4.4?
12:41:31 <pave1> I meant for gitlab.
12:41:47 <jki> what is the point in doing it in gitlab over kernelci?
12:42:36 <pave1> It is what I am currently using.
12:43:07 <alicef> not much as I stated last time currently kernelci is keeping logs of cip tests indefinetly
12:43:35 <pave1> It would be for catching regressions in stuff that is not in ci configs.
12:43:44 <alicef> so that we can look into old builds and such
12:43:45 <pave1> ...like the sound driver jan reported.
12:44:02 <patersonc[m]> It's pretty easy to add more build configs to the gitlab setup if wanted - let me know the list and I can add
12:44:21 <patersonc[m]> Presumably we could add to the kernelci setup as well?
12:44:29 <jki> I agree on having the defconfigs - though that would be been fine with multiv7_defconfig
12:44:38 <alicef> patersonc[m]: that would be nice
12:45:09 <jki> but we should really evolve kernelci to be on-par with out gitlab (and rather go much beyond)
12:45:26 <jki> therefore: same policies
12:45:26 <fbezdeka> I'm confused a bit now: Should I still remove arm64 builds for kernelci (4.4-cip only)?
12:47:51 <jki> IMHO, I would disable that for now - can be reverted at any point when we see new value or feel bored
12:50:20 <jki> I have one more topic related to the BBB:
12:50:27 <jki> I heard that the cip-kernel-config for 5.10 does not boot
12:50:43 <jki> does the BBB run in our CI successfully?
12:52:43 <patersonc[m]> let me check
12:52:48 <iwamatsu> https://lava.ciplatform.org/scheduler/job/720340
12:52:48 <patersonc[m]> It did when we merged it all
12:53:06 <iwamatsu> BBB is booting with 5.10.y
12:53:41 <jki> ah, good data point. need to sort out what isar-cip-core is building / should be building as config
12:53:42 <jki> thanks
12:54:09 <jki> anything else regarding testing?
12:54:49 <jki> 3
12:54:52 <jki> 2
12:54:55 <jki> 1
12:55:00 <jki> #topic AOB
12:56:01 <patersonc[m]> o/
12:56:12 <patersonc[m]> Did anyone see this message on IRC a few days ago? "So are there any, like, facilities running CIP in prod, right now?"
12:56:25 <jki> nope
12:56:27 <jki> pointer?
12:56:46 <patersonc[m]> just looking
12:57:43 <patersonc[m]> Where are the logs stored now?
12:58:14 <patersonc[m]> Anyway, side Q - should more people try and get a persistent IRC connection so we can answer such questions?
12:58:37 <alicef> use a bouncer
12:59:00 <alicef> or matrix bridge?
12:59:35 <patersonc[m]> Found it: https://ircbot.wl.linuxfoundation.org/logs/%23cip/%23cip.2022-08-01.log.html
13:01:20 <jki> can we set up a bot that replies with "please also try the mailing list"?
13:01:35 <patersonc[m]> Matrix bridge works for me
13:01:44 <patersonc[m]> jki: could be an idea
13:01:53 <jki> or would someone still be able to reach that person after so many days?
13:01:55 <patersonc[m]> But we can't have it do that to every message
13:02:12 <jki> yes, we likely need AI :D
13:02:57 <patersonc[m]> Or change the topic to tell people to contact the ML if there is no reply
13:04:13 <alicef> in the topic already there is the mailing list link
13:04:15 <patersonc[m]> pave1: Do you have a list of configs you want adding to the gitlab/kernelci 4.4-cip builds?
13:06:06 <jki> another topic: I'll likely not be able to run the meetings for the upcoming 3 weeks (travels, vacation)
13:06:21 <jki> very likely next week, maybe in two weeks, and definitely not in 3
13:07:07 <pave1> patersonc -- will get that to you.
13:07:15 <patersonc[m]> Thanks
13:07:24 <iwamatsu> Japan will be a traditional holiday next week.
13:07:53 <jki> skip next week?
13:08:17 <pave1> I'm not sure about next weeks, still hope for some holidays.
13:08:28 <iwamatsu> if other member is no problem.
13:08:44 <patersonc[m]> I'm off on the 18th
13:08:58 <patersonc[m]> pave1: Or raise an issue https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/issues and https://github.com/orgs/kernelci/projects/11
13:09:16 <patersonc[m]> pave1: But email is fine
13:09:45 <pave1> patersonc> email is better.
13:10:40 <masami> I may be able to attend next meeting.
13:10:55 <alicef> by the way recently kernelci mailing is changing afair
13:11:08 <jki> in any case, someone would have to take the lead for next week first of all
13:11:49 <alicef> https://groups.io/g/kernelci/topic/92374991#1560
13:12:12 <alicef> we are moving to kernelci@lists.linux.dev
13:15:25 <jki> ok, folks, anything else?
13:15:43 <pave1> masami -- can you take a lead next week? It is as easy as #startmeeting etc...
13:16:02 <masami> pavel: ok. I'll do that.
13:16:46 <pave1> logs from last meeting are quite helpful, you can just paste from them.
13:16:54 <pave1> Thank you!
13:17:14 <jki> great, thanks!
13:17:30 <masami> np
13:18:34 <jki> so, closing in....
13:18:44 <jki> 3
13:18:47 <jki> 2
13:18:50 <jki> 1
13:18:52 <jki> #endmeeting