20:00:01 #startmeeting 20:00:01 Meeting started Wed Feb 11 20:00:01 2026 UTC. The chair is carnil. Information about MeetBot at https://wiki.debian.org/MeetBot. 20:00:01 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:06 o/ 20:00:07 hi all 20:00:26 #chair bwh carnil ukleinek 20:00:26 Current chairs: bwh carnil ukleinek 20:01:27 I have assembled the recent bugs in the agenda as usual, is htere anything we need to talk beforehand going to the bug list? 20:01:43 nothing from my side 20:02:11 Hello 20:02:19 hi Ben 20:02:44 Nothing urgent from me 20:02:48 okay then let's move to the buglist 20:03:06 #topic #1126671: (S, ) linux-image-6.17.13+deb13-amd64: Disconect root (path=/) during heavy load on NvME, partial corruption on NTFS.crash soon but not yet 20:03:36 agree that's a wait for reporter 20:03:41 I had an action last time here to followup, which I did but only recently. Gave instructions to gather more information via netconsole, so I think we now have to wait 20:03:55 #topic #1127597: (S, uM) linux-image-6.12.48+deb13-amd64: GRE6 decap fails (merged with #1127599) 20:04:33 I believe this one is now in good hands. Tj did with reporters a debugging session isolating the breaking commit, there is an upstream thread as well and Greg plans to queue the fix for the next round of updates 20:04:49 sounds good 20:05:38 Yay, an API change that causes silent breakage 20:05:46 action for me at least: decide on when to release the next update again via a DSA to fix this regression (but likely at least move as well to 6.12.70 and 6.1.163 + fixes). I have not checked if this affects as well 5.10.249-1? 20:06:10 I think it may... 20:06:29 it is bit frustrating that on each update you can expect at least a regression with some major impact :( but I think we have to deal with it. TEsting all possible scenarios is impossible. 20:06:44 Yes same breakign commit is in 5.10.249 20:07:06 okay, should we add this as found version for 5.10.249-1 in the BTS? 20:07:17 re "API change that causes silent breakage": Well, only affects incomplete backports, that's not user visible 20:07:29 carnil: Yes but the BTS never sees that 20:07:41 ukleinek: It is in a static inline function exposed to OOT modules 20:08:00 ..ooOO(yeah, but OOT modules) 20:08:32 There is no stable kernel API for OOT modules, *but* API changes are supposed to be made in such a way that unconverted modules fail to build 20:09:00 for example that function could have been renamed when the meaning of its return value was changed 20:09:10 bwh: yeah, no promise is to be made, but with a bit of thought the procedure can be improved. 20:09:34 (and that would also make such incomplete backports less likely) 20:11:02 anyway, the API change happened a while back upstream, so the damage is done 20:11:13 as we have seen ;-) 20:11:35 okay to move to the next item, I think this is in hands now on the various fronts 20:11:57 I just have added founds versions on 6.1.162-1 (I though I did already but apparently not) and 5.10.249-1 20:12:42 I interpret the silence as yes 20:12:48 #topic #948243: (i, ) linux-image-5.4.0-1-amd64: Fails to boot into graphical mode on Radeon RX 5700 XT, amdgpu: [powerplay] failed send message 20:12:57 * ukleinek doesn't say anything to not change carnil's interpretation 20:13:08 this is actually an old bug but only recently someone pinged the bug. 20:13:30 I'm uncertain: is the problem really related or should we rather ask the second reporter to fill a new bug? 20:13:51 I think they should make a new bug report if they are seeing the bug, and the original report should be closed 20:13:55 This is about an external amdgpu driver? 20:14:22 What makes you think that? 20:14:54 The gitlab.fd.o has: AMD official driver version: amdgpu-dkms 1:6.16.13.30300000-2278356.24.04 20:15:53 so for reference we are talking about the mention of https://gitlab.freedesktop.org/drm/amd/-/issues/3659#note_3324746 20:15:59 right 20:16:53 we could offer reaching out to us if Quazgar needs help for bisection 20:16:59 yes and reportbug shows amdgpu(OE) 20:18:02 so we have one reporter who didn't respond and another who's using the OOT driver, so I don't think we need any open bug reports...? 20:18:16 The version suggests that the dkms package contains a backport from mainline 6.16.13? 20:18:28 so ignore the followup or respond that we think that they are unrelated problems 20:19:21 the latter 20:19:34 If you want to respond, say it's probably unrelated and also amdgpu-dkms does not come from us => not our bug 20:19:47 I will respond something along the above lines 20:20:11 #action carnil gives feedback on unrelated problem for #948243 followup 20:20:18 #topic #1113861: (i, uM) linux-image-6.12.41+deb13-amd64: Most Flatpaks don't launch, cause kernel oops in nouveau module 20:20:25 and if they want a newer amdgpu and amdgpu-dkms is just the driver from a newer mainline version, they could try a backport kernel 20:20:39 as reminder this was folowed up by another reporter which was able to reproduce the problem without flatpak 20:21:08 Nothing changed since last week. I think someone took an action then 20:21:12 waldi took last time an action, I guess it fine to keep that, but I can ask him off-meeting later if someone else should look into it 20:21:16 so nothing to do for now 20:21:21 * ukleinek nods 20:21:53 bwh: yes waldi aimed to look into the details, I think we can keep this if he finds time in the next weeks for it 20:22:05 #topic #1126090: (i, u) linux-image-6.12.57+deb12-amd64: Firewire-ohci module crashes 20:22:24 two news: upstream responded and asked/gave some instructions for further debugging 20:22:29 wait on reporter 20:22:33 and Tj suggested to install latest firmware first 20:22:42 so in both cases we can wait for the repoter to followup 20:22:55 #topic #1126149: (i, u) linux: usb enumeration fails with error -32 for Krom Kreator keyboard 20:23:21 The tentative patch was without success, so removed the patch tag again. 20:23:39 In meanwhile I wonder if this could indicate some HW issues as the keyboard works on other hardware 20:24:00 I'm out of ideas and am usure the information is in a stage where we can forward something 20:24:07 These USB messages usually mean flaky hardware. (Cable, device or controller) 20:24:08 any ideas on how to proceed on this? 20:25:06 hmm, it does work on the same hardware in windows and the bios 20:25:53 unplugging all other usb devices, and using (or not using) a hub might help (but not enlighten us so much) 20:26:19 Just grepping for -32 in the log of quirks.c shows some other quirk flags that may be useful 20:26:42 I'm trying to remember if there's a way to add quirks without rebuilding the kernel... 20:27:49 ..ooOO(Vicboom18 doesn't know about reply-to-all in their MUA) 20:27:52 usbhid has: 20:27:53 parm: quirks:Add/modify USB HID quirks by specifying quirks=vendorID:productID:quirks where vendorID, productID, and quirks are all in 0x-prefixed hex (array of charp) 20:28:14 and there's usbcore.quirks for USB-level quirks 20:28:14 would that help? 20:28:42 ukleinek: yes the reporter wrote me always privately, that was tedious 20:29:55 carnil: I think a USB-level quirk is required since I don't think the HID driver is even looking at the device 20:29:59 bwh: so we might ask the reporter to test further used from the grepping of commit logs in quirks.c to see if any has a positive effect? 20:30:06 ah right 20:30:14 Right. I can take an action to do that 20:30:21 bwh: thank you! 20:30:57 #action bwh will suggest trying other USB quirks to fix #1126149 20:31:04 bwh: if you need a form-letter link, I always use https://people.kernel.org/tglx/notes-about-netiquette :-D 20:31:12 ah good you were faster :) 20:31:33 #topic #1127635: (i, ) linux-image-6.18.9+deb14-powerpc64: fails to boot on IBM 8204-E8A (POWER6 p550) LPAR, NULL deref in PCI MSI setup 20:31:57 as I understand this is powerpc specific, should we involve the porters? 20:32:29 it hangs in the initramfs I think? 20:32:29 yes 20:33:10 the kernel log contains a null pointer exception 20:33:38 #action ukleinek looks into #1127635, falling back to forwarding to the powerpc porters 20:33:48 thanks ukleinek 20:33:59 #topic #1127659: (i, u) linux-image-6.12.69+deb13-rt-amd64: chrony 4.6.1 cannot configure extpps for PHC refclocks due to new permission check 20:34:31 bwh commented today, upstream might not want to consider reverting it as it is a security fix (afaik no CVE was yet assigned from kernel CNA) 20:34:44 so the fix should probably go in all affected suites into chrony 20:35:00 questions: 20:35:02 That was my thinking - previously write-like ioctl()s did not require write permission 20:35:17 - is the fix easily backportable to older versions? 20:35:22 should we revert for a while? 20:35:40 - should we reassign the bug to chrony (updating metadata) and help getting that in 20:35:41 I didn't check, but I assume it's just s/O_RDONLY/O_RDWR/ 20:35:52 It's a bit more extensive than that 20:36:16 because it actually becomes conditional 20:36:31 ukleinek: I would rather prefer not if upstream does not plan as well to revert temporarily in stable series branches, but that is a bit my exagerated view on following the stable series 20:37:34 I see it as a service to our users to not break chrony until it is fixed in a point release. 20:37:35 but I wonder if upstream might consider reverting it temporarily as well with considering the report from Jan Luebbe 20:37:59 ukleinek: Well, in principle we can fix it through -updates 20:38:15 ukleinek: there is as well stable updates which can issue updates before a point release, my thinking was: if it can go in point relesee, ask for srm as well to issue a SUA for it 20:38:27 We should discuss with SRM, I think 20:39:04 according to https://lore.kernel.org/all/CAHk-=wheQNiW_WtHGO7bKkT7Uib-p+ai2JP9M+z+FYcZ6CAxYA@mail.gmail.com/ that commit should be reverted 20:40:14 I know but security fixes have always been an exception 20:40:15 +1 for SRM and keeping an eye on upstream 20:41:28 I will take an action to keep an eye on how this evolves, try to have a look at backporting the crhony fix to trixie, possibly already bookworm, and approach SRM for discussion, will take bit of time though 20:41:34 ... and a bug for chrony. (Don't care if we reassign, or clone and reassign) 20:41:42 s/I will/I can/ if there are no objections 20:42:07 * ukleinek never objects if someone else volunteers to do the things we agreed on :-D 20:42:30 * ukleinek also doesn't object the s/// 20:42:49 #action carnil takes care of following #1127659 (keep an eye on upstream decision on the report, consider backports for chrony and approach SRM for bugfixes in trixie and bookworm) 20:43:07 time moves fast :( 20:43:16 carnil: FWIW the upstream patch does not apply cleanly even to trixie's chrony 20:43:16 #topic 1120831: (n, u+) linux: failed command: READ FPDMA QUEUED after boot 20:43:25 bwh: arg :( 20:43:32 bad 20:44:05 so this will require maybe non-negligible work on backporting? 20:44:34 #topic #1120831: (n, u+) linux: failed command: READ FPDMA QUEUED after boot 20:44:57 carnil: I think Jan might be able to help with the backport 20:45:28 What the reporter is saying doesn't make a lot of sense... 20:45:49 there is some confusion on #1120831, the fix has defintively not yet landed, so I wonder how the problem get fixed for the reporter 20:46:06 are the udev rules not included in the initramfs? 20:46:09 I think there is some unpredictable factor that triggers the bug. Pretty sure it's not "rebuilding the initramfs" 20:46:25 Oh, yeah they are. So that *would* explain it 20:46:33 if so I think the user might have build initramfs with the udev added but removed it later from system, and now get incosistent reporting back 20:47:18 I intent to keep the bug open until the upstream fix really lands and then close it with that update 20:47:21 right 20:47:27 * ukleinek nods 20:47:45 but so we can followup to the reporter explaining that the udev rule is likely in the rebuild initramfs and he can check with lsinitramfs 20:48:01 #topic #1121192: (n, M) kworker: Events_unbound, kworker processes, continually using CPU. 20:48:10 bwh: asked some questions -> wait? 20:48:14 yes 20:48:18 * ukleinek nods again 20:48:27 #topic #1126499: (n, u) linux-image-6.17.13+deb14-amd64: ovpn NULL pointer dereference and lockup under heavy load 20:48:52 we are still waiting the fix to land in mainline. Asked the reporter to make an explicit test with the prooposed patch so a Tested-by can be added 20:49:00 -> wait 20:49:11 #topic #1126911: (n, ) linux-image-6.12.63+deb13-amd64: wacom_serial4 doesn't work. Probe fails with error -1. 20:49:13 maybe offer a .deb? 20:49:23 I don't think you explicitly asked them to test the patch...? 20:50:23 bwh: oh well yes I was meaning it as Jon is included in the conversation but you are right I should ask more explicitly 20:50:29 will do so it is clear 20:50:30 sorry 20:50:47 ..ooOO(No need to be sorry) 20:51:07 on #1126911, ben can we keep the action on you? 20:51:11 yes 20:51:52 #action bwh will ask questions on #1126911 (comment from previous meeting: Driver strange as .probe() returns -1 instead of an error code.) 20:52:08 #topic #1126957: (n, u) kernel panic when repeatedly trying to mount an nfsv4 share with mtls and failing 20:52:22 this is a new report, ktls is involved 20:53:19 I aimed late last week to build a test environment as I will be intersted in using ktls in future, but I failed, so from me no insight in this yet. 20:53:37 You failed to make it work, or you failed to make it crash? 20:53:41 carnil: is it clear to you how to reproduce? You failed because ENOTIME, or you tried and didn't see the failure? 20:53:49 bwh: no I failed to find time to make a proper test setup 20:54:17 There is an autopkgtest test case in ktls-utils 20:54:54 ukleinek, bwh for clarity: I failed because in the end ENOTIME 20:55:03 OK 20:55:20 As the person who has seen this wroking, let me take the action 20:55:25 so if someone wants to already progress on it, just take an action. I'm still intersted into looking at least later in ktls setups. 20:55:31 bwh: perfect :) 20:55:39 #action bwh will try to reproduce #1126957 and update the bug 20:55:57 ..ooOO(bwh has seen this wracking?) 20:56:11 are you okay if we do the last 3 linux bugs or do you want to skip given the time? 20:56:23 ok for me 20:56:28 OK 20:56:40 #topic #1127588: (n, ) linux-image-6.18.9+deb14-amd64: Cannot hibernate after some time of work 20:57:19 new report, have not looked at the details 20:57:36 (altough is is relatively brief/short on those) 20:57:38 So I think it's reasonable that hibernation fails because there is not much swap available. But since swap didn't fill up before, then I think there's a memory leak. 20:57:53 2704661 pages is a lot? 20:59:10 ~10 GiB? Yes it's quite a lot! 21:00:21 Does that mean hibernate needs these 10 GiB more space than the available swap? 21:00:36 I think that's what it means 21:00:37 Release is forky/sid and "APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable')" ... is that... usual? 21:01:01 iam_tj[m]: that's the default if you have no pining and no default release 21:01:05 ukleinek: Yes, that is what it means. It's not uncommon 21:01:44 I suppose we should ask for information from /proc/slabs and /proc/meminfo to get some idea of where the memory is going 21:01:49 ask for more xz and zstd? If there is a memory leak it will eventually crash?! 21:02:16 This would need some idea of the existing and terminated processes, uptime, and so on. There's not much free RAM either that suggests the system is/has been heavily taxed 21:02:18 bwh: ah, if you can decode these, that's even better 21:03:38 iam_tj[m]: Right, an obvious question would be whether those memory consuming programs have actually released any memory 21:04:18 #action bwh will respond to #1127588 requesting info about memory usage 21:04:24 bwh: exactly what I was thinking 21:04:24 thanks 21:04:44 #topic #1127612: (n, u) linux-image-6.12.69+deb13-amd64: hp_bioscfg mm/page_alloc.c:4802 warning 21:05:21 another regression from 6.12.63->6.12.69, I intent to help the reporter identifying the breaking commit 21:05:26 and then check/report upstream 21:05:50 sounds good 21:05:51 alghough I think there is one commit mentioning hp_bioscfg 21:06:12 so the first step would be to check to revert that commit 21:06:14 The most recent commit is to make the driver auto-load 21:06:33 So, most likely this driver was always broken but didn't load 21:06:58 so the obvious test is to load it on 6.12.63 and/or blacklist on 6.12.69 21:07:05 right 21:07:57 #action ukleinek suggests a few tests for #1127612 21:08:19 thanks ukleinek 21:08:30 #topic #1126710: (w, ) linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set 21:08:41 I think I have an action to write the text for this? 21:08:50 action is/was on bwh only question: should we clone the bug and reassign it as well for release-notes? 21:08:54 bwh: yes 21:09:22 I can take care of the cloning as well 21:09:56 * ukleinek wanted to suggest a patch doing s/Depricated/Deprecated/ but it's only the reporter who got that wrong :-) 21:10:06 #action bwh keeps the action to write the text for NEWS and release notes to address #1126710 (XFS V4 support removal) 21:10:20 ukleinek: I'm full confident it will be right with bwh beeing a native speaker :) 21:10:39 ok we are done with the linux bugs 21:11:11 I propose to skip now, there is one firmware-nonfree bug about asking to support updates from *-backports 21:11:12 * ukleinek looks up "to bee" 21:11:49 #topic Migration excuses 21:12:28 when I looked up today the tracke there was as well a genext2fs autopkgtest regression mentioned for linux 21:14:21 It's a weird one 21:14:32 maybe should look at that tomorrow, because it would be good to have 6.18.9-1 migrating to testing 21:14:34 the runs from today are green?! 21:15:09 ukleinek: so it yet just the tracker not having updated the status, and the tests might be flaky? 21:15:36 https://ci.debian.net/packages/g/genext2fs/testing/amd64/ 21:16:04 TIL this pages needs a login 21:16:20 That's a recent change to reduce load from scrapers 21:16:31 that's what I thought 21:16:51 ukleinek: https://lists.debian.org/debian-devel-announce/2026/02/msg00001.html 21:17:13 So we ignore the genext2fs failure and assume it will pass very soon? 21:17:39 ok then linux should migrate tomorrow or the day after, the signed packages need one more day 21:17:44 ok 21:18:18 #topic new usptream versions 21:18:40 a small note on nfs-utils: have not done the update as upstream has released a new version but not tagged in git, have asked back 21:19:13 I just started on the wireless-regdb update 21:19:31 and fireware-free isn't relevant as usual? 21:19:37 bwh: thanks, IIRC that has the signing key from you embedded and needs to be done by you anyway righ? :) 21:19:48 #topic Merge requests 21:19:55 anything on MR's to discuss specifically? 21:20:11 ukleinek: I should probably double-check that there isn't anything new that's free, but no I think it's not relevant 21:20:15 * ukleinek looked over a few arm64 ones, but not all yet. Intend to continue next week 21:20:32 ukleinek: that is great, thank you 21:20:41 No I still have an action to test out simpledrm and figure out a safe upgrade path 21:21:14 bwh: if you additionally have some spare cycles and can review my https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/36 that would be great as well. But if you have not that is fine. 21:21:50 #topic AoB 21:22:07 * ukleinek already announced last week that he can take the chair for next week 21:22:23 #action ukleinek will chair next week team meeting 21:22:46 perfect, I think we are done, and sorry it got that late, we overrun by almost 25min :-/ 21:22:50 did not expect that 21:23:04 Well, I think we had more and trickier bugs 21:23:05 #endmeeting