13:07:24 <iwamatsu__> #startmeeting CIP IRC weekly meeting
13:07:24 <collab-meetbot> Meeting started Thu Feb 13 13:07:24 2025 UTC and is due to finish in 60 minutes.  The chair is iwamatsu__. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:07:24 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:07:24 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
13:07:35 <iwamatsu__> #topic AI review
13:08:21 <iwamatsu__> no AI on mail from jki.
13:08:29 <iwamatsu__> anything missed?
13:08:31 <iwamatsu__> 5
13:08:41 <iwamatsu__> 4
13:08:44 <iwamatsu__> 3
13:08:46 <iwamatsu__> 2
13:08:47 <iwamatsu__> 1
13:08:57 <iwamatsu__> #topic Kernel maintenance updates
13:08:59 <pave1> I was reviewing 6.1.129, now I'm working on autosel.
13:09:06 <uli_> i did 4.4 and 4.19
13:09:06 <masami> This week reported 20 new CVEs and 0 updated CVEs.
13:09:14 <uli_> thanks for the reviews!
13:09:28 <iwamatsu__> I am reviewing 6.1.129.
13:09:36 <pave1> thanks for releases!
13:09:43 <iwamatsu__> uli_: Thanks for release.
13:10:19 <jki> hi - and sorry for the delay
13:10:28 <jki> meeting already started?
13:10:36 <iwamatsu__> We already recieved some patch for 4.19.y
13:10:53 <iwamatsu__> jki: Yes, I takeover.
13:10:57 <jki> thanks!
13:11:03 <iwamatsu__> nop
13:12:29 <iwamatsu__> Do we need an announcement for 4.19.y?
13:12:40 <uli_> didn't i send one?
13:13:46 <iwamatsu__> https://lore.kernel.org/cip-dev/1733593115.596079.1739239912119@webmail.strato.de/T/#u
13:14:00 <iwamatsu__> > This is the first 4.19 release maintained exclusively by CIP.
13:14:23 <uli_> was that too subtle? :)
13:14:25 <iwamatsu__> uli_: I see, OK.
13:15:15 <iwamatsu__> sorry for this noise.
13:15:38 <iwamatsu__> anything else?
13:15:41 <iwamatsu__> 5
13:15:43 <iwamatsu__> 4
13:15:44 <iwamatsu__> 3
13:15:45 <iwamatsu__> 2
13:15:47 <iwamatsu__> 1
13:15:56 <iwamatsu__> #topic Kernel release status
13:16:34 <pave1> I'll do 6.1-cip and 6.1.128-rt. january was a little late so this catches it up.
13:16:55 <iwamatsu__> pave1: thank you.
13:17:06 <iwamatsu__> I am working for linux-5.10.y
13:17:25 <iwamatsu__> linux-4.4.y-cip-rt is late.
13:17:40 <uli_> 4.4 and 4.19 are done
13:17:54 <pave1> aha, ok, let me do 4.4-rt, too.
13:18:18 <iwamatsu__> ok, thank you.
13:18:38 <iwamatsu__> anything else?
13:18:40 <iwamatsu__> 5
13:18:42 <iwamatsu__> 4
13:18:44 <iwamatsu__> 3
13:18:45 <iwamatsu__> 2
13:18:46 <iwamatsu__> 1
13:18:56 <iwamatsu__> #topic Kernel testing
13:19:15 <patersonc> Howdy
13:19:30 <arisut> no updates from me. working on kci-dev bisections and KernelCI blog
13:19:30 <patersonc> I started to look at the device that wasn't booting with 6.6 last week
13:19:48 <patersonc> But then it seems that it's working with 6.6 again now - so I guess something got fixed?
13:20:01 <pave1> scary :-)
13:20:12 <iwamatsu__> same version?
13:20:28 <patersonc> Fixed between rc2 and the final release
13:20:32 <patersonc> I forget the exact version
13:20:52 <pave1> But I guess if it went away we don't need to debug that.
13:21:01 <patersonc> I certainly don't plan to :P
13:21:12 <iwamatsu__> if we want to take a reason, we need to run bisect..., but it is not important.
13:21:20 <patersonc> yep
13:21:38 <patersonc> iwamatsu__ did you get a chance to look into an LTP rootfs for the x86 / MCOM board?
13:22:32 <iwamatsu__> patersonc: OK, I will take a look.
13:22:43 <patersonc> Thanks
13:23:19 <patersonc> I guess nothing else from my side
13:23:24 <jki> I would have an RT testing topic
13:23:46 <jki> does anyone already know this: https://github.com/Linutronix/RTC-Testbench?
13:24:11 <patersonc> I didn't
13:24:32 <jki> I would have the proposal to build up end-to-end RT testing this way, first for x86
13:24:51 <jki> later for other archs/boards supporting XDP RT networking this way
13:25:00 <jki> (and a bit of TSN)
13:25:35 <patersonc> Fun
13:25:36 <jki> would stress both RT workloads (similar to cyclictest, though) AND RT I/O via network
13:25:59 <jki> setup is not totally straightforward, also because it will need two boxes obviously
13:26:08 <jki> but it could be rewarding for our RT testing
13:26:26 <patersonc> Sure
13:26:38 <pave1> If it uncovers somethin, it will be 'fun' to debugg.
13:26:40 <jki> I'm not sure if KernelCI is already prepared to handle something like this as well, so I would start small in our domain first
13:26:42 <iwamatsu__> I am interesting this.
13:27:00 <pave1> but yes, more testing is needed for rt.
13:27:09 <iwamatsu__> +1
13:27:27 <jki> regarding RT testing: have you seen this backport of my colleague? https://lore.kernel.org/stable/20250129153226.818485-1-florian.bezdeka@siemens.com/
13:27:57 <patersonc> w.r.t kernelCI perhaps open an issue in their github about it?
13:27:58 <jki> I was able to trigger that (harmless) warning withing no time by booting a plain debian-rt 6.1 kernel in a VM
13:28:13 <jki> it is not just that our setup is improveable...
13:29:28 <jki> should we open the kernelci issue already now, or better try out first in our lab?
13:30:03 <arisut> https://lore.kernel.org/all/20250211090511.xeFJVnH_@linutronix.de/
13:30:15 <arisut> PREEMPT_RT testing on kernelci
13:31:05 <jki> arisut: thanks for the pointer
13:31:08 <jki> let me read...
13:31:50 <iwamatsu__> anything missed?
13:32:02 <iwamatsu__> 5
13:32:04 <iwamatsu__> 4
13:32:06 <iwamatsu__> 3
13:32:08 <iwamatsu__> 2
13:32:09 <iwamatsu__> 1
13:32:31 <iwamatsu__> #topic AOB
13:32:42 <paulbarker> Hi folks, I have two questions - the first is about the cip-kernel-config repo, from the point-of-view of backporting support for Renesas SoCs
13:32:48 <paulbarker> When a CIP release is tagged in linux-cip, there is no corresponding tag in cip-kernel-config so it can be difficult to match up the two repositories when looking at an old CIP release.
13:32:54 <paulbarker> Is there anything we can do to improve that? My preference would be to move the CIP kernel configs in to the appropriate branches of linux-cip so they are always aligned with the rest of the tree.
13:33:08 <arisut> tldr KernelCI is starting to implement preempt_rt testing but still on the implementation phase
13:33:35 <pave1> we normally don't update configs when kernel changes
13:33:48 <pave1> I see renesas backports will need that.
13:34:13 <jki> we have some kind of lock-stepping in isar-cip-core
13:34:15 <paulbarker> pave1: We need to update the config when we backport a new driver which has a new Kconfig option
13:34:32 <jki> as we have both the configs and the kernel referenced there by versions
13:34:38 <pave1> latest config should work on the corresponding -cip branch.
13:35:01 <pave1> but yes, we should probably use same tags we do on kernel there.
13:36:00 <jki> but how often will that actually happen?
13:36:07 <pave1> (and if change in config breaks something on older -cip kernels, we should be extra careful. Does that happen?)
13:36:29 <jki> is this case a one-off or can it really repeat more often in the future?
13:36:33 <paulbarker> pave1: cip-kernel-config may have newer config symbols enabled which don't exist in Kconfig files in older releases
13:36:45 <pave1> suggestion would be only put tag into configs when it needs to change, after corresponding release.
13:37:19 <pave1> paul: yes, that's expected. But that won't cause any real problems, right?
13:37:38 <pave1> warning at oldconfig time or something... we can live with that.
13:38:02 <pave1> just warn us if you rename a symbol or something...
13:38:37 <paulbarker> Ok, let's think about it, may come back to it next week
13:38:44 <paulbarker> Second question, I have a CVE fix to backport to 4.4 & 4.19, should I be targeting the -cip or -st branches?
13:39:06 <pave1> -st.
13:39:09 <iwamatsu__> -st
13:39:33 <paulbarker> Thanks, I'll try to do the backport tomorrow
13:39:48 <pave1> thank you :-)
13:40:01 <jki> I have some CVE-related thing as well
13:40:04 <iwamatsu__> paulbarker: thank you
13:40:34 <iwamatsu__> jki: please
13:40:38 <jki> learned that my CERT colleagues are happily consuming our CVE yaml files :)
13:41:16 <jki> they just asked (so far) if we could easily also write down the cip-kernel versions that received fixes, not only the commit shas
13:41:34 <jki> no idea how much effort that would be, though
13:41:36 <pave1> git can do that.
13:41:44 <jki> yeah, we know
13:41:59 <jki> but that is another step that downstream has to script then
13:42:19 <jki> (i gave the same answer initially)
13:42:48 <pave1> yes and it may slow things down a bit.
13:42:48 <masami> Added fixed version in yaml files may be easy to users.
13:43:06 <pave1> but it seems like reasonable request.
13:44:11 <masami> I'll create sample yaml file which contains version informaion.
13:44:29 <jki> would that be something to automate in the end?
13:45:06 <masami> yes. it has to be automated.
13:45:18 <jki> masami: thanks in advance!
13:45:30 <masami> jki: np :)
13:45:50 <iwamatsu__> anything else?
13:46:05 <iwamatsu__> 5
13:46:07 <iwamatsu__> 4
13:46:08 <iwamatsu__> 3
13:46:10 <iwamatsu__> 2
13:46:11 <iwamatsu__> 1
13:46:23 <iwamatsu__> #endmeeting