20:00:24 <bwh> #startmeeting
20:00:24 <MeetBot> Meeting started Wed Feb  5 20:00:24 2025 UTC.  The chair is bwh. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:24 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:58 <bwh> #chair ukleinek
20:00:58 <MeetBot> Current chairs: bwh ukleinek
20:01:06 <bwh> Hi ukleinek
20:01:20 <bwh> carnil said he probably couldn't attend
20:01:33 * ukleinek just typed that
20:01:39 <bwh> waldi: Are you here?
20:01:51 <ukleinek> bwh is always a tad faster ...
20:03:05 <bwh> Let's assume not, and I'll go to the first agenda item
20:03:09 * ukleinek announces he would like to get some feedback for https://salsa.debian.org/kernel-team/linux/-/merge_requests/1337.
20:03:24 <ukleinek> (we can do that, when we get there)
20:03:32 <bwh> Right
20:03:45 <bwh> #topic Bug #1087807: linux-image-6.1.0-27-amd64: Unable to boot: i40e swiotlb buffer is full
20:04:26 <bwh> I have built a test package but still need to upload that and mail the reporters
20:04:38 <ukleinek> great
20:05:04 <bwh> #action bwh will upload the test package and ask reporter to try it
20:05:21 <bwh> #topic Bug #1093243: linux-image-6.1.0-29-amd64 causes mariadb hangs
20:05:47 <bwh> carnil said he was going to make an upload to fix this
20:05:59 * ukleinek nods
20:06:27 <bwh> #topic Bugs #1090717 and #1076372: NVMe data corruption
20:07:29 <ukleinek> Last time we awaited upstream to find a solution IIRC
20:07:34 <bwh> I can see ongoing activity on the upstream bug report, but I'm not sure if it's progressing toward a solution
20:08:15 <ukleinek> Probably waiting is still the right thing to do? (But I didn't look at the upstream discussion)
20:08:20 <bwh> Christoph Hellwig suspects it's somehow IOMMU related
20:09:20 <bwh> Yes I don't think there's much we can do. I checked and our reporter still seems to be engaged upstream
20:09:39 <bwh> #topic Bug #1086028: loupe: FTBFS on mips64el: failed to acquire jobserver token: Bad address (os error 14)
20:10:33 <ukleinek> In one of the three merged bugs the first bad upstream commit was identified IIRC.
20:10:34 <waldi> ups. here
20:10:43 <bwh> Hi waldi!
20:10:49 <ukleinek> o/
20:11:37 <bwh> ukleinek: Where is the bad commit identified?
20:11:58 * ukleinek doesn't find it, so IIRC doesn't seem to be given
20:12:41 <bwh> Do you mean this: https://lore.kernel.org/all/mvmplxraqmd.fsf@suse.de/T/#m570e8102a6378695d8ec25acb35d8b11b2ed13df
20:12:58 <ukleinek> and again you're a tad quicker than me :-)
20:13:05 <ukleinek> #regzbot ^introduced 4bce37a68ff884e821a02a731897a8119e0c37b7
20:13:09 <ukleinek> is the claim there
20:13:54 * ukleinek recognizes the author of that commit
20:13:54 <bwh> But I was in cc for that and I thought it got fixed then...
20:15:42 <ukleinek> they considered a revert, but that doesn't apply cleanly IIUC and a mips guy diagnosed that it's not easy to fix
20:15:48 <bwh> right
20:16:50 <ukleinek> hmm, no activity in the last week in the upstream thread
20:17:44 <bwh> According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093200#50 there seemed to be a regression between kernel versions 6.1.76 and 6.1.99, but the mips/mm change was applied in 6.1.37
20:18:34 <bwh> but I think this is not that reliably reproducible so those versions might be off
20:18:49 <ukleinek> This is a problem that doesn't trigger reliably, right? So 6.1.76 being good might be -- /me starts to be annoyed
20:19:39 <bwh> A couple of messages saying 5.10 was OK, and 5.10 never got a backport of this change
20:19:57 <ukleinek> also an unrelated change around 6.1.76 might have made triggering the problem more likely
20:20:04 <bwh> *nod*
20:20:43 * ukleinek has no experience with mips, so I guess I cannot support upstream without big effort
20:20:52 <bwh> #action bwh will try to revive discussion of mips regression upstream
20:21:03 <waldi> they talk about delay slots, which is quite a mips thing
20:21:04 <bwh> Is there anything else we can do now?
20:21:10 <ukleinek> 👍
20:21:46 <ukleinek> This is relevant on our mips builder, right?
20:21:49 <bwh> waldi: Also sparc has that disease, but thankfully we don't pretned it's a release arch
20:22:09 <waldi> ukleinek: yes. it fails on our buildds
20:22:10 <ukleinek> Should we recommend a kernel downgrade for those?
20:22:15 <bwh> ukleinek: Apparenrly some of them. I thought they were stuck on an old kernel version
20:22:57 <bwh> I suppose we could
20:23:51 * ukleinek volunteers to talk about that in #d-admin
20:24:20 <bwh> #action ukleinek will propose downgrading mips buildd kernels to 5.10
20:24:48 <bwh> Next 2 bugs are merged with this
20:25:04 <bwh> #topic Bug #1071562: nfsd blocks indefinitely in nfsd4_destroy_session
20:28:37 <bwh> So this has been forwarded upstream but I don't see any conclusion there
20:29:30 <bwh> I don't think there's anything useful we can do at this point
20:30:06 <bwh> #topic Bug #1091788: linux-image-6.12.x-amd64: second monitor not recognized with NVidia, but is found booting earlier kernels (6.11.10 and previous)
20:30:47 <ukleinek> was that the one with the proprietary nv driver?
20:30:57 <bwh> It's a different one with the proprietary driver
20:31:05 <bwh> not the one we discussed last week
20:31:19 <ukleinek> right, vbox "only"
20:31:48 <bwh> #action bwh will reassign #1091788 to nvidia driver package
20:31:49 <waldi> what do you mean? proprietary nvidia driver and fails in drm
20:32:19 <bwh> #topic Bug #1093390: linux-image-6.1.0-30-amd64: Audio with snd_pcm_oss choppy with -29 and -30; <= -28 is fine
20:32:49 <ukleinek> Oh, I think I had an action for that one last week (or the week before that)?
20:33:33 <bwh> Yes, you had an action for that 2 weeks ago
20:33:59 <ukleinek> I'll keep that and try again this week
20:34:19 <bwh> #topic Bug #1093124: libhsa-runtime64-1: HSA exception: Queue create failed at hsaKmtCreateQueue with multiple programs
20:35:16 <bwh> carnil asked for bisection here but the reporter doesn't know how to do that
20:35:18 <ukleinek> ..ooOO(the bts is slow)
20:36:04 <ukleinek> #action ukleinek follows up on $1093124 with some bisection hints
20:36:09 <bwh> Thanks
20:36:23 <bwh> #topic Bug #1094206:  linux-image-6.12.10-amd64: does not load amdgpu driver module
20:36:50 <ukleinek> we wondered about that last week already
20:37:29 <bwh> Yes, and carnil was going to ask for a boot log
20:37:41 <ukleinek> there are two reporters now it seems
20:38:16 <bwh> Can someone else take over that action?
20:38:33 <ukleinek> asking for a boot log is easy enought and carnil probably won't object.
20:38:48 <ukleinek> #action ukleinek asks for bootlog in #1094206
20:38:53 <bwh> Thanks
20:39:00 <bwh> #topic Bug #1094766: linux-source-6.1: Revert "drm/amdgpu: rework resume handling for display (v2)"
20:40:08 <bwh> Subject tells us what the fix is
20:40:08 <ukleinek> 6.1.127 is probably a typo
20:40:25 <ukleinek> the revert is already in 6.1.27(?)
20:40:26 <ukleinek> ?
20:40:26 <bwh> no, it's correct
20:40:57 <bwh> It's reverting a change that went into 6.1.120
20:42:02 <ukleinek> so an update to 6.1.$latest should fix it. Do we already have that in the queue?
20:42:02 <bwh> Anyway, I guess carnil will handle this with the next stable update
20:42:15 <ukleinek> \o/, I was quicker this time
20:43:25 <ukleinek> Assuming carnil will be back tomorrow, I will talk to him about an ETA
20:43:37 <bwh> MR 1329 updates to 6.1.128
20:43:53 <ukleinek> hmm, but even if it takes some more time, fast tracking that revert is probably not sensbile
20:44:13 <bwh> and that already has a Closes: for that bug report
20:44:40 <ukleinek> ok, so then we'll just wait
20:44:45 <bwh> OK
20:45:03 <bwh> #topic Bug #1094767: linux-image-6.12.10-amd64: new linux-image-6.12.10 and more makes amdgpu and gnome unusuables
20:45:27 <ukleinek> is that because the amdgpu module isn't loaded?
20:46:18 <ukleinek> (same reporter? I already saw compte.perso.de-alain@bbox.fr today)
20:46:29 <waldi> insmod is the wrong tool, it does not resolve dependencies
20:46:58 <bwh> ukleinek: Yes from comment #87 it looks like a duplicate of  #1094206
20:47:27 <bwh> Or it could just be what waldi says
20:47:44 <ukleinek> I'll handle that together with my action for the former bug
20:48:13 <bwh> Actually, that makes me think that the reporter in #1094206 is also wrongly using insmod
20:48:35 <ukleinek> noted in my todo list
20:48:43 <bwh> But these both involve the module not being auto-loaded when it should, so I think they might be dupes
20:48:47 <waldi> there are more things weird in #1094206. like lspci sees the amdgpu module bound to the video card
20:49:30 <bwh> waldi: No, "kernel modules" means matching kernel modules, "kernel driver in use" says which was bound
20:50:03 <waldi> ups
20:50:04 <waldi> okay
20:50:34 <bwh> #action ukleinek will respond to #1094767 and possibly merge with #1094206
20:50:44 <ukleinek> ack
20:51:07 <bwh> #topic Bug #1094755: linux: dubious CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1
20:52:48 <bwh> According to the upstream documentation, "10 would be a good choice"
20:53:01 <ukleinek> so CONFIG_SND_HDA_POWER_SAVE_DEFAULT was bumped 0 => 1 and 10 is a recommended value
20:53:18 <ukleinek> so #898629 was only about > 0 I guess?
20:53:23 <bwh> and I would be surprised if that made much difference to power consumption, so I guess we should do that?
20:53:40 <ukleinek> sounds reasonable
20:53:59 <bwh> The older bug did spcecify setting it to 1
20:54:24 <bwh> #action bwh will change CONFIG_SND_HDA_POWER_SAVE_DEFAULT to 10
20:54:36 * ukleinek nods
20:54:39 <waldi> do we want to backport that?
20:54:52 <ukleinek> backport what?
20:55:10 <waldi> this change, to stable
20:55:38 <bwh> The bug was opened with normal severity, and without explaining any particular problem with it
20:55:47 <bwh> So I think no, unless that changes
20:56:17 * ukleinek asks jwilk what the trigger for reporting that bug was
20:56:41 <bwh> Thanks
20:57:02 <bwh> #topic Bug  #1095232: linux: Add CONFIG_HSA_AMD_SVM to kernel config
20:57:27 <waldi> i'll take a look
20:57:55 <bwh> #action waldi will respond to bug #1095232
20:58:13 <bwh> #topic Bug 1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled
20:58:32 <waldi> someone wanted to close that
21:00:43 <ukleinek> On 2025-01-15 carnil wanted to look, don't find that in later protocols
21:01:34 <bwh> waldi: I don't see that, but I agree this should be closed
21:01:43 * ukleinek nods in agreement
21:02:00 <bwh> This is a feature request for upstream, and I don't think we need to track those
21:02:26 <bwh> #action bwh will close #1092591
21:02:34 <ukleinek> bwh: thanks
21:02:53 <bwh> #topic Bug #1084908: arch:all linux-libc-dev causes problems to architecture bootstrap
21:03:51 <waldi> handled by me
21:04:33 <bwh> Well, are you likely to make any change?
21:05:03 <bwh> It seems like there are a lot of people interested in cross-builds that support linux-libc-dev being arch:any again
21:05:38 <waldi> which would mean we have arch:any, but still supporting all architectures at the same time. not really better
21:05:42 <bwh> (doko also tried to talk to me about this at FOSDEM and I didn't have anything much to say, except we'd discuss this in the meeting)
21:06:33 <bwh> I don't understand what you think the problem is with arch:any
21:06:47 <bwh> Are you talking about pain from version skew, or something else?
21:07:56 <waldi> not sure what you mean
21:08:30 <bwh> I don't understand what you are saying the problem was with arch:any
21:08:31 <waldi> the problem with arch:any is, that this package will also show up on hurd then
21:08:54 <waldi> okay, not really a problem. but not really a solution either
21:09:02 <bwh> I don't mean literally arch:any
21:09:31 <waldi> but i do. because explicit arch listing is one thing i explicitely listed as a reason for this change
21:09:51 <waldi> so it is either all or any, not a specigic list of arches
21:10:19 <bwh> We need a mapping between Debian arch names and kernel arch names though
21:11:04 <bwh> so there is no avoiding a list of architecture names
21:13:23 <waldi> i still don't see where you try to go. what makes arch:any better?
21:14:00 <bwh> This was already explained to you on that bug report, repeatedly
21:18:00 <ukleinek> I admit I don't understand everything in this bug. Would you consider it helpful when I work on understanding it to provide a 3rd(?) opinion?
21:19:10 <bwh> ukleinek: You're welcome to have a look
21:19:59 <bwh> Honestly I don't have a full understanding or a strong opinion either, but I am see problems being reported and waldi seeming to say that they aren't real problems
21:20:40 <waldi> bwh: did you see any user reports of errors? only helmut for one specific script contained usecase
21:21:36 <bwh> I don't know why you think they aren't users
21:22:09 <waldi> because they modify the linux source
21:22:19 <bwh> Well, I don't think we are going to resolve this today
21:22:24 <waldi> yes
21:22:58 <ukleinek> I add "trying to understand #1084908" to the end of my todo list, so no promises.
21:23:10 <bwh> :-)
21:23:31 <bwh> #topic Issue linux#8: trixie kernel maintenance
21:23:41 <bwh> I think we discussed this some time back, but can't find the record
21:23:56 <bwh> Did anyone talk to the release team about this yet?
21:25:08 <ukleinek> without looking into the protocols I suspect that carnil intended to do that
21:26:25 <bwh> Let me take an action to talk to them if necessary
21:26:52 <bwh> #action bwh will discuss trixie kernel maintenance with carnil and release team
21:27:37 <bwh> #topic Merge request linux#1137: [arm64] drivers/clk/mediatek: Set MT7986 clock driver builtin
21:28:24 <ukleinek> I proposed a change regarding clk modules in that MR
21:29:00 <bwh> You mean, adding drivers/clk/** to kernel-image?
21:29:00 <ukleinek> I think it would make sense, but I would welcome a 2nd pair of eyes on that
21:29:12 <ukleinek> yeah
21:29:23 <bwh> That should probably be done in the generic kernel-image list
21:29:31 <bwh> but yes
21:30:14 <bwh> I think that's independent of this MR though, since this clock driver apparently doesn't work as a module
21:30:31 <bwh> (or, we have something built-in that soft-depends on it)
21:30:32 <ukleinek> I'm not sure about "doesn't work as a module"
21:31:21 <ukleinek> the kernel log in the bug report suggests that userspace (i.e. initramfs) is reached. That should be good enough, shouldn't it?
21:31:39 <waldi> the question is: what blocks and where
21:31:51 <bwh> ukleinek: I see what you mean
21:31:58 <waldi> sysrq something could help to see the blocked tasks
21:33:45 <ukleinek> if you both agree that drivers/clk/** should go into the generic kernel-image list we can do that first and when that change hit the daily installer we can ask the reporter to retest.
21:33:54 <bwh> OK
21:34:24 <ukleinek> #action ukleinek to create a MR that adds drivers/clk/** to the kernel udeb
21:35:10 <bwh> #topic AOB
21:35:38 <bwh> Also, who will chair next week?
21:35:48 <waldi> objections to raise build setup dependencies to trixie? see also https://salsa.debian.org/kernel-team/linux/-/merge_requests/1346
21:36:40 <bwh> Yes, because we will need to backport to bookworm (without -backports) later
21:36:56 <waldi> not from 6.13
21:37:03 <waldi> and this is not used during build
21:37:14 <bwh> Sorry, you're right
21:37:32 <bwh> This might be a problem for ELTS but that's not Debian
21:38:05 <bwh> No objection then to do that on debian/latest
21:38:33 <waldi> i don't think i'm well enough to chair next week. everything is still fishy for me
21:38:42 <bwh> I'm sorry to hear that
21:39:11 <ukleinek> waldi: You were not in Brussels I assume? I didn't see you (but neither did I see bwh)
21:39:19 <waldi> ukleinek: no, i was not
21:39:48 * ukleinek missed quite a few people that he looked forward to meet there
21:40:37 <ukleinek> #action ukleinek will chair next week
21:40:43 <waldi> thx
21:40:44 <bwh> Thank you
21:40:50 <bwh> #endmeeting