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