20:27:01 <ukleinek> #startmeeting
20:27:01 <MeetBot> Meeting started Wed Feb 12 20:27:01 2025 UTC.  The chair is ukleinek. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:27:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:27:12 <ukleinek> #chair bwh waldi carnil
20:27:12 <MeetBot> Current chairs: bwh carnil ukleinek waldi
20:27:30 <ukleinek> #topic #1087807
20:27:56 <bwh> Sorry, still (slowly) working on this
20:28:04 <ukleinek> Last week's status was that bwh intended to prepare a test package
20:28:08 <carnil> bwh: maybe there is no need
20:28:10 <bwh> I uploaded binary packages and will try to get the mail sent out tonight
20:28:17 <bwh> carnil: Oh?
20:28:22 <carnil> if you look at the mpt3sas bug related as well to xen, there is now some pogress upstream
20:28:30 <carnil> concretely:
20:28:37 <carnil> https://lore.kernel.org/regressions/Z6d-l2nCO1mB4_wx@eldamar.lan/T/#u https://lore.kernel.org/all/9dd91f6e-1c66-4961-994e-dbda87d69dad@oracle.com/ https://lore.kernel.org/all/20250211120432.29493-1-jgross@suse.com/
20:28:54 <carnil> there is identified which commit breaks:
20:28:56 <bwh> Oh OK
20:29:05 <carnil> b1e6e80a1b42 ("xen/swiotlb: add alignment check for dma buffers")
20:29:18 <carnil> at least for the mp3sas case but as well for megaraid_sas
20:29:25 <carnil> so your bug might be related as well
20:29:37 <bwh> It is exactly what I suspected
20:30:26 <carnil> https://lore.kernel.org/all/20250211120432.29493-1-jgross@suse.com/ is the current patchset (but not merged into mainline)
20:30:27 <bwh> I should still ask reporters of the other maybe-related bugs to test
20:30:58 <ukleinek> I guess we expect the fix to go in soonish?
20:31:22 <carnil> for some values of "soonish"
20:31:39 <ukleinek> So what is the action? Wait? Push upstream?
20:31:44 <carnil> but I'm pretty sure it will flow back to 6.1.y as it has the respective Fixes
20:32:07 <carnil> I think push upstream is not helpful, it is already mooving and the most recent action is from yestrday
20:32:30 <carnil> but monitor it and see that it goes not lost for 6.1.y series
20:33:05 <carnil> it might make sense to have our users test as well the patches from https://lore.kernel.org/all/20250211120432.29493-1-jgross@suse.com/
20:33:07 <ukleinek> and still ask the reporters of the bug to test before upstream moves?
20:33:10 <waldi> the commits are not Cc: stable@
20:33:42 <ukleinek> In practise Fixes: is enough to let the stable team pick up commits, but with Cc: stable it would be more reliable
20:33:54 <carnil> waldi: but they have correct Fixes tags, which should make sure that greg's script pick it up as well
20:34:10 <waldi> right
20:35:12 <ukleinek> Are the packages that bwh prepared suitable for testing after the insights of upstream?
20:35:23 <ukleinek> Or do they need adaption?
20:35:55 <bwh> I don't know - I reverted precisely the commit that bug #1088159 identified as bad
20:36:45 <ukleinek> Sounds as if it would at least be suiteable to confirm that all reporters are cared for when they test that, even if upstream does fix it differently in the end, right?
20:37:09 <ukleinek> So I suggest we keep the plan that we ask them for that test
20:37:21 <bwh> OK
20:37:51 <ukleinek> bwh: that means you follow up with them?
20:37:55 <bwh> yes
20:37:57 <carnil> either test the revert, or test a kernel with the two upstream fixes
20:38:05 <ukleinek> #topic #1090717 + #1076372
20:38:10 <carnil> ok!
20:38:53 <ukleinek> These are the NVMe bugs we talk about since weeks
20:39:18 <ukleinek> I didn't check for their progress, did someone else follow the discussions?
20:40:16 <carnil> the most recent message in the thread is this:
20:40:17 <carnil> https://lore.kernel.org/regressions/210e7b28-de05-44bc-9604-83a79ae131b0@leemhuis.info/T/#mfdd68ebb581655d47b500326890e38dc14f2c540
20:40:26 <carnil> Quoting stefan:
20:40:27 <bwh> I can see a lot of discussion of exactly what the trigger conditions are, and a workaround of disabling IOMMU, but no progress on a fix
20:40:27 <carnil> after Matthias was so kind (more than me) to make a video (!) for the
20:40:27 <carnil> ASRock support, and after I once again referred to this thread and the
20:40:27 <carnil> many users who have the same problem, ASRock is able to reproduce the
20:40:28 <carnil> issues.
20:41:02 <carnil> but as bwh say, no fix yet in sight
20:41:19 <ukleinek> So we suggest disabling the iommu to our users?
20:42:03 <bwh> I think the reporter has already seen that. I'm not sure where else we would suggest that
20:42:25 <ukleinek> There are two bugs, does it apply to both?
20:42:57 <bwh> I don't know
20:43:08 <bwh> There is only 1 upstream bug report
20:44:09 <ukleinek> ah right, we wanted to wait for upstream's resolution and then maybe escalate the other one if not resolved by the first fix.
20:44:20 <carnil> we did ask the reporter to spearate the reports for the two types, but maybe this in the end was wrong to do
20:44:58 <ukleinek> Given that the first isn't resolved yet, we still wait for the second. ack?
20:45:27 <ukleinek> and for the first there is also nothing to do, given the reporter is aware of the iommu workaround
20:45:52 <bwh> I think that's right
20:45:59 <ukleinek> We might highlight the iommu workaround in the 2nd bug as something worth trying
20:46:48 * ukleinek progresses to the next bug then
20:46:51 <ukleinek> #topic #1086028 + #1093200 + #1087809
20:46:59 * ukleinek prods zwiebelbot
20:47:10 <ukleinek> that's the build failures for mips
20:47:38 <ukleinek> Our last week's plan to downgrade the buildds was screwed by #1055021
20:47:50 <bwh> Last week I took an action to try to revive the upstream discussion. I have not yet done that
20:49:02 * ukleinek assumes bwh keeps that action and that's all we have to say about that
20:49:12 <ukleinek> #topic #1088159
20:49:23 <ukleinek> #1088159
20:49:39 <bwh> I think we effectively covered this one?
20:49:50 <bwh> With the other Xne-related regression
20:49:53 <ukleinek> ah right, that's a duplicate of the Xen one
20:50:05 <ukleinek> #topic #1094767
20:50:49 <waldi> there is one possible source of this file in debian: https://sources.debian.org/src/lxc-ci/0.0~git20250113.158dfe2-1/bin/kernel-setup/?hl=92#L92
20:50:54 <ukleinek> This was debugged to a module blacklist of amdgpu module. It's unclear what created that blacklist
20:51:19 <waldi> used in distrobuilder-images. so some weird container images
20:52:07 <ukleinek> So we ask the reporters if they have that and if yes reassign the bugs?
20:52:25 <waldi> no, just close them
20:52:42 <bwh> Ugh, I can see loads of different recipes on GH that do this
20:53:00 <ukleinek> close and let possibly other users run into that?
20:53:09 <bwh> In Debian, only lxc-ci
20:54:10 <ukleinek> If people follow some GH recipe they hopefully understand enough of it to remember that when they suffer from a similar problem
20:54:15 <bwh> I have to wonder why lxc-ci is downloading a load of out-of-tree drivers
20:54:49 <waldi> should we extend our bug scripts to collect modprobe config files?
20:54:56 <bwh> Maybe yes
20:55:28 <waldi> #action waldi to extend bug scripts to collect /etc/modprobe.d
20:56:06 <bwh> OK, it seems like the dodgy script in lxc-ci does not end up in any binary package in Debian
20:56:08 <ukleinek> just something like: find /etc/modprobe.d /and/the/other/dirs -type f | xargs sed '/#.*//; /^$/d' or similar
20:57:04 <waldi> yeah
20:57:09 <bwh> We don't have to code this in the meeting...
20:57:16 <ukleinek> ack
20:57:28 <ukleinek> #topic #1095647
20:57:33 <waldi> done
20:57:44 <waldi> !1356
20:57:58 <ukleinek> #topic #1093124
20:58:23 <ukleinek> The reporter identified the breaking upstream commit. I intend to follow up with a regression report for upstream.
20:58:46 <ukleinek> #action ukleinek to report upstream about #1093124
20:59:21 <ukleinek> That's it with the severity >= important bugs. Let's skim over the MR list now
20:59:48 <ukleinek> #topic https://salsa.debian.org/kernel-team/linux/-/merge_requests/1352
21:00:41 <ukleinek> I don't understand that one, loong64 ftbfs
21:01:26 <ukleinek> but the MR (IIRC) does a change for all archs
21:01:31 <bwh> Oh right, I think something weird is happening with the selection between the different compression options
21:01:31 <waldi> missing build-dep zstd, part of !1131. because it selects zstd on loong64 instead of gzip
21:01:52 <bwh> My question would be why CONFIG_KERNEL_XZ is not available there?
21:01:59 <waldi> we should just switch all to zstd, which is faster them xz, but not much larger
21:02:08 <waldi> because xz is not supported
21:02:31 <waldi> anyway, i have to go
21:02:53 <ukleinek> #action ukleinek to switch all archs to zstd
21:03:10 <bwh> Well, is zstd supported everywhere?
21:03:18 * ukleinek will research that
21:03:21 <waldi> ukleinek: please let me do it. i already made the work
21:03:43 <ukleinek> #action waldi to care for compression selection
21:04:00 * ukleinek might have misinterpreted "i have to go"
21:04:06 <bwh> I'm happy with switching everything to zstd if that works
21:04:28 <ukleinek> #topic https://salsa.debian.org/kernel-team/linux/-/merge_requests/1350
21:04:32 <bwh> Otherwise, I would propose that explicitly enabling whatever works for loong64 in its config
21:05:04 <ukleinek> That's the one that put all clock modules into the kernel image udeb. Is there agreement that this is the right thing to do?
21:05:33 <bwh> I think so
21:05:44 * carnil trusts ukleinek on it
21:06:01 <ukleinek> If yes, the author of #1337 should be pointed to this once the daily installer images contain this change
21:06:15 <ukleinek> #action ukleinek to merge !1350
21:06:59 <ukleinek> These MRs were the ones I considered important to talk about. Given the time, should we continue or call it a day?
21:07:27 <ukleinek> I think the firmware-nonfree MRs are easy and don't need discussion?
21:07:31 <bwh> Let's stop there
21:07:32 <carnil> I'm fine to stop :)
21:07:38 <ukleinek> ok
21:07:44 <bwh> I didn't look yet, but I hope they are simple
21:07:45 <ukleinek> Who chairs next week?
21:09:00 <ukleinek> Is it waldi's turn?
21:09:08 <ukleinek> (is he already gone?)
21:10:07 <ukleinek> #action ukleinek coordinates to find a chair for next week and volunteers to do it again if he fails
21:10:11 <ukleinek> #endmeeting