12:00:39 <jki> #startmeeting CIP IRC weekly meeting
12:00:39 <collab-meetbot> Meeting started Thu Feb 26 12:00:39 2026 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:39 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:39 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
12:00:44 <jki> #topic AI review
12:00:45 <iwamatsu> Hello
12:01:05 <jki> none recorded, but actually /me wants to enhance the wiki a bit regarding backporting
12:01:13 <jki> let me add that for next week
12:01:26 <jki> anything else?
12:01:30 <jki> 5
12:01:32 <jki> 4
12:01:33 <pave1> Is that the "criteria for accepting backports"?
12:01:38 <jki> yep
12:01:42 <pave1> +1
12:01:59 <jki> 3
12:02:01 <jki> 2
12:02:03 <jki> 1
12:02:05 <jki> #topic Kernel maintenance updates
12:02:14 <uli> i'm working on 4.4
12:02:16 <masami> This week reported 0 new CVEs and 26 updated CVEs.
12:02:52 <pave1> I am doing reviews, mostly 6.12.70 at the moment. It looks like new big batch is near.
12:02:53 <jki> upstream LTS is ~4 years again
12:02:55 <iwamatsu> I reviewed 6.12.71 and 72.
12:04:16 <jki> anything to add?
12:04:27 <jki> 5
12:04:29 <jki> 4
12:04:31 <jki> 3
12:04:32 <jki> 2
12:04:34 <jki> 1
12:04:36 <jki> #topic Kernel release status
12:04:43 <jki> all on green
12:04:56 <jki> any issues ahead?
12:05:19 <jki> 5
12:05:21 <pave1> Nothing I can see.
12:05:23 <jki> 4
12:05:24 <uli> +1
12:05:25 <jki> 3
12:05:27 <jki> 2
12:05:29 <jki> 1
12:05:31 <jki> #topic Kernel testing
12:06:08 <patersonc> No updates from me
12:06:26 <pave1> Qemu is failing on 6.18/6.19: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/2347904507
12:06:30 <arisut> same
12:07:52 <pave1> 6.19 is also showing failure on bbb. I guess I could click "retry", but...
12:09:42 <patersonc> The qemu jobs looks like the kernel doesn't support the mounting method: not syncing: VFS: Unable to mount root fs on "/dev/vda" or unknown-block
12:11:04 <iwamatsu> https://lava.ciplatform.org/scheduler/device_type/qemu?dt_length=25&dt_search=linux-6.18.y#dt_
12:11:10 <iwamatsu> It seems to work fine on amd64. There may be a difference in the configuration. I'll check.
12:11:56 <patersonc> Okay with x86 qemu: https://lava.ciplatform.org/scheduler/job/1399832
12:13:47 <patersonc> qemu arm with 6.18 in kernelci is working okay: https://lava.collabora.dev/scheduler/job/21448942
12:13:54 <patersonc> Could it be an issue with CIP's config?
12:14:17 <pave1> I guess so. Missing CONFIG_VIRTIO=y
12:14:17 <pave1> CONFIG_VIRTIO_PCI=y        # if using PCI transport (most common on x86)
12:14:18 <pave1> CONFIG_VIRTIO_BLK=y?
12:14:39 <jki> oops, seems like I roamed out
12:15:31 <jki> still there?
12:15:37 <patersonc> yep
12:15:44 <jki> still topic testing, right?
12:16:10 <jki> last for me was "6.19 is also showing failure on bbb. I guess I could click "retry", but..."
12:16:12 <pave1> Yep. Can probably move on.
12:16:25 <jki> #topic AOB
12:16:28 <patersonc> I used the same binaries/job description from the kernel CI setup in lab-cip and it's worked: https://lava.ciplatform.org/scheduler/job/1404497
12:16:28 <patersonc> So yes, maybe a CIP config issue
12:16:43 <patersonc> Will someone take an action to look into the qemu-arm CIP configs?
12:17:27 <iwamatsu> I will fix it to cip-kernel-config.
12:17:40 <jki> thanks in advance!
12:17:40 <patersonc> Thanks
12:18:00 <patersonc> AOB: What do we want to do with https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/-/merge_requests/159/?
12:18:23 <jki> my comment should not delay it
12:18:50 <jki> it was more a general question
12:19:00 <patersonc> Ah okay
12:19:19 <jki> because we should then have PROVE_LOCKING for all
12:19:30 <jki> (and maybe a few more)
12:19:52 <pave1> I am with Jan here.  It makes sense to drop PROVE_LOCKING for performance testing, but maybe we should have some runs with debug options enabled...
12:20:03 <pave1> ...because a lot of problems are invisible without those.
12:20:04 <jki> very valuable test, it helped a lot in fixing that weired "PREEMPT_RT on hyperv" issue we had
12:20:36 <patersonc> Can we create a "debug" config fragment to append to the merged configs then?
12:21:01 <jki> in cip-kernel-config? I guess so
12:21:07 <pave1> Something like that would make sense.
12:21:12 <patersonc> For CI we can either build with both debug enabled and disabled, or just one of them
12:21:14 <jki> but you still need to modek it in kernelci pipelines
12:21:21 <jki> or our own ones
12:21:50 <pave1> I believe we need both debug enabled and disabled runs:
12:22:03 <jki> yes
12:22:04 <pave1> rt needs to be tested with debug disabled.
12:22:16 <jki> with both as well
12:22:16 <pave1> we need some debug enabled builds to ... well... catch bugs.
12:22:47 <jki> some issues you only see with RT on (+debug), some only with it off
12:23:09 <pave1> yes, ideally we would test everything with debugging on and off.
12:23:22 <patersonc> Okay
12:23:37 <patersonc> Once we have the configs sorted we'll work out how to get it working in kernelci
12:24:08 <jki> do we already have config snippets in cip-kernel-config?
12:24:26 <jki> where should those be dropped? central or next to the defconfigs
12:24:50 <jki> in isar-cip-core, we have one snippet for all version to enable preempt-rt
12:25:43 <iwamatsu> It is not in cip-kernel-config.
12:25:50 <jki> nope, not yet
12:25:54 <jki> for rt
12:25:58 <jki> but it could...
12:26:01 <patersonc> RT fragments would also be good :)
12:26:03 <iwamatsu> yes
12:26:25 <jki> I mean, I can start with an MR for RT in a central place
12:26:30 <jki> then add debug
12:26:40 <jki> and let you meditate over that ;)
12:28:28 <jki> anything to add?
12:29:28 <jki> 5
12:29:30 <jki> 4
12:29:32 <jki> 3
12:29:34 <jki> 2
12:29:36 <jki> 1
12:29:37 <jki> #endmeeting