20:00:32 #startmeeting 20:00:32 Meeting started Wed Oct 28 20:00:32 2026 UTC. The chair is bwh. Information about MeetBot at https://wiki.debian.org/MeetBot. 20:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:37 Hello 20:00:49 waldi said he cannot be present today 20:01:14 o/ 20:01:30 hi 20:02:12 Hello all. I'm just going to plug my laptop in 20:02:40 * ukleinek runs `bts tag 1151598 + upstream fixed-upstream` in the meantime 20:03:05 OK, ready 20:03:17 Anything urgent topics before we get into the bug list? 20:03:30 nothing on my side 20:04:28 #topic Bug #1151598: (S, ) linux-image-amd64 6.12.113-1 kernel regression on ath9k_htc modules 20:04:59 Message #10 claims this is fixed in a new stable version 20:04:59 That needs reassigning 20:05:03 I just merged that into the other 20:05:10 OK 20:05:28 for reference #1151097 20:05:41 and have already as well a closer for the 6.12.y upload 20:05:59 good, so let's move on 20:06:10 #topic Bug #1141183: (i, u) src:linux: I/O errors on SATA devices related to IOMMU 20:07:11 There's another person reporting but they don't mention anything about the IOMMU so I doubt it is the same bug 20:08:41 Actually now I see the original report doesn't have an IOMMU error in the log before the ATA error 20:08:41 #action ukleinek asks the new reporter in #1141183 if iommu=off helps and to report a separate issue if not 20:08:45 right 20:09:23 #topic Bug #1149109: (i, ) linux-image-7.1.8+deb13-amd64: amdgpu flip_done timed out and freeze on RX 6600 (regression from 7.1.3) 20:10:03 reporteer did provide some logs yesterday 20:10:18 I have not looked yet at the results, TBH 20:10:26 looks like a pain to go through 20:10:35 yeah 20:11:08 I don't know why they tested with 7.2.9 now when there are several newer versions available 20:11:27 because carnil asked for that? 20:11:31 That is true 20:11:52 yeah I asked the question on 7th october, but only replied now with testing, should maybe write next time "or the newest available version when starting testing" 20:12:00 Can we forward this upstream now? 20:12:17 depends on what is in the provided log files 20:13:26 I think one next step would be to ask to test 7.2.13-1 (or whatever is newest when testing) and if it reporduces there still to forward it to the amdgpu upstream issue tracker (and provide us the reference to track it accordingly)? 20:13:59 * ukleinek nods 20:14:59 if we do not have other ideas or someone in the mood to wade trough the attachments I can take this, even if the reporter might feel disappointed 20:14:59 OK, there are a bunch of amdgpu fixes since 7.2.9, so that seems reasonable 20:15:22 but given there were a lot of changes again up to 7.2.13 I think it would be better to test that first before asking to report upstream 20:15:30 right 20:16:53 should I take the action? 20:17:24 If you are not too busy. You are very busy, aren't you? 20:17:49 #action carnil follows up to the now provided information in #1149109, ask to test 7.2.13 and then report upstream if still reproducible via amdgpu issue tracker 20:18:01 #topic Bug #1149525: (i, ) linux: RockPro64 conntrack oops with 7.2.x 20:18:04 bwh: asking this question is easy enough, I take it 20:19:42 I suppose we're just waiting on upstream for this one 20:19:51 yes, no reply from upstream yet 20:20:19 if I don't get a reply, I can visit Florian, who lives in my city :-D 20:20:27 I fear this may end up as "it's fixed now, no need to investigate" but there's just something masking the bug 20:20:39 #topic Bug #1150523: (i, M) linux-image-6.1.0-53-amd64: repeatable early-boot general protection faults in __kmem_cache_alloc_node 20:21:09 Waiting for bug script output 20:21:20 #topic Bug #1150737: (i, M) linux-image-6.12.111+deb13-amd64: Intermittent system hang when resuming from deep (S3) suspend on Dell OptiPlex 3060 20:21:38 waiting for bisection results 20:21:43 right 20:21:54 #topic Bug #1151281: (i, u) linux-image-6.12.113+deb13-amd64: kswapd NULL pointer dereference in list_lru_add() (workingset_update_node), system freeze 20:22:10 queued fixes in various stable version 20:22:29 * carnil nods 20:22:53 OK so no action needed besides noting the bug closer 20:22:55 no action needed apart adding (not forgetting rather) to add an appropriate bug closer 20:23:09 #topic Bug #1151377: (i, ) linux: lpfc boot hang since 6.1.178 - use-after-free of mboxq in lpfc_sli4_driver_resource_setup() backport 20:23:09 don't forget the bug closer 20:23:49 "already queued for the next 6.1.y" 20:23:52 Fix is queued (presumably in the current review) 20:24:21 it was sent on Oct 8, so might already be "in" 20:24:46 ah no, this is not sent by Greg, but a submit to stable 20:24:47 it isn't 20:25:08 https://lore.kernel.org/stable/20261028170508.836716892@linuxfoundation.org/ ? 20:25:30 carnil: yes, that's it 20:26:04 #topic Bug #1151860: (i, Mu) linux-image-7.2.9+deb13-amd64: Regression in Realtek RTL8761BU (0bda:a728) Bluetooth LE scanning — request upstream fix backport 20:26:27 Waiting for reporter to test a patch 20:26:42 * ukleinek nods 20:26:59 #topic Bug #1151916: (i, Mu) linux: xhci AMD Renoir [1022:1639] USB hotplug detection broken after boot on 6.12.113 20:27:37 reporter started bisecting but needed to restart 20:27:41 right 20:27:54 #topic Bug #1152007: (i, ) linux-image-7.2.9+deb13-amd64: kernel panic on resume (s2idle) in ath11k after order-8 allocation failure in ath11k_dp_alloc 20:27:59 might be worth to point out that bisect log has all the tests from before the error 20:30:18 tainted O but not P by nvidia modules 20:31:09 Yes that's strange 20:31:26 Can I look into it and ask it more to reporter? 20:31:46 Anyway - ath11k is doing a 1 MiB allocation with GFP_NOIO which seems like a bad idea 20:32:35 I'm not sure how that ends up as a panic 20:33:15 Oh right, there is an oops at the end 20:33:28 yunseong[m]: Yes please do 20:33:44 there is a possibility somehow to make malloc fail using some testing stuff. That might help to reproduce 20:34:04 #action yunseong[m] will respond to #1152007 20:34:12 #topic Bug #1152197: (i, ) linux-image-6.12.113+deb13-amd64: Intel VMD 8086:7d0b: NVMe completion-polled timeout delays boot ~30 seconds 20:35:52 I think we need the full boot log for this 20:36:29 We don't have any context for the nvme error log 20:36:41 #action bwh will ask for complete boot log for #1152197 20:36:48 #topic Bug #1152341: (i, ) linux-image-6.12.113+deb13-amd64 and 7.2.6: Linux suspend causes unexpected reboot with Intel `igc` Ethernet driver 20:38:30 would be great to see the crash-log (if any) 20:38:48 It doesn't look sound like there is any log 20:39:57 there might be if the screen wasn't off 20:41:46 The patch they found doesn't seem to have been applied 20:42:07 Well let's forward this upstream 20:42:51 #action bwh will forward #1152341 upstream 20:42:55 thx 20:43:07 #topic Bug #877779: (n, ) linux: modpost uses wrong sizes for mips-octeon kernel 20:43:13 That's an old one... 20:44:45 I suppose I could have another look at this 20:45:03 #action bwh will look at #877779 again 20:45:09 does it pick wrong compiler flags? 20:45:42 I don't remember exactly how this goes wrong 20:46:31 We build 4 different versions of modpost to cover big/little-endian, 32- and 64-bit longs, but we don't handle pointers or weird alignment rules properly 20:46:45 "Upstream generates the offsets with the target 20:46:45 compiler, so it does not have this problem. 20:46:46 " 20:47:12 I think the weird alignment rules aren't a problem for any release architecture now that we dropped i386, but pointers still are 20:47:39 why do we ever need more than the target modpost? 20:48:17 Cross-building modules 20:48:20 * ukleinek thinks that shouldn't be discussed life and withdraws the question 20:48:29 s/life/live/ 20:49:27 plus for some architectures (though no release architectures) we still have both 32- and 64-bit kernel flavours so even a "native" module build needs multiple modpost versions 20:49:41 #topic Bug #1115110: (n, ) linux-image-6.16.5+deb14-amd64: Unable to Suspend or Shutdown Computer 20:50:08 OK, nothing actually new here 20:50:21 #topic Bug #1139313: (n, Mu+) linux: Snapdragon X1 SoCs: random crashes when using git 20:50:47 Agathe Porte bug tracking, we can ignore I guess 20:51:05 Nothing for us to do, anyway 20:51:12 #topic Bug #1146033: (n, M) linux-image-7.1.8+deb14.1-amd64: cannot shutdown laptop 20:51:37 We have a bisect log 20:51:48 and the bad commit is a merge :-( 20:52:19 Oh, because they used --first-parent 20:52:44 ah, that also explains why the bisection is that short 20:53:21 #action ukleinek follows up to #1146033 asking for a bisect of the non-first-parent history 20:53:36 carnil: I don't follow your reasoning for saying to use --first-parent 20:54:16 bwh: that reduces the build cost considerably for each step 20:54:42 OK. I don't think I tried doing that before 20:55:06 bwh: my idea was, given reporter had to bisect beween two major version to first get to which merge possibly during the merge window is causing the regression 20:55:30 and then in a second step narrow down that branch from the merge with a further bisect 20:55:34 bwh: the issue is that v7.0..v7.1 contains commits that base on v7.0 and on v6.19-rc1 (or even older). If jumping between them you have to rebuild a lot 20:55:55 OK that makes a lot of sense. TIL and I should remember to try that in future 20:56:03 #topic Bug #1149377: (n, uM) linux-image-6.12.111+deb13-amd64: Bluetooth no longer works after kernel upgrade 20:57:01 waiting for upstream to revert stuff in stable 20:57:04 I don't see the reverts in the queue 20:57:21 yeah still not :( 20:57:23 * ukleinek also didn't see them when checking earlier today 20:57:50 well, the intention was announced on Sunday 20:58:14 I don't think anyone actually said they would do ti 20:58:49 Thorsten and Sasha agreed that there should be a revert but neither said they would send/add patches 20:59:05 "If it helps, I can send reverts of 980084de4d9b and 6f0624b4427e" was written by Christoph 20:59:10 Ah yes 20:59:22 OK then let's wait for that 20:59:43 +1 20:59:50 #topic Bug #1149988: (n, M) linux-image-7.2.9+deb14-amd64: sound does not work in any 7.2 kernels 21:00:05 Waiting for bisection 21:00:12 #topic Bug #1150950: (n, M) linux-image-7.2.10+deb14-amd64: ACPI BIOS ERROR hard blocks wlan interface at boot -cannot be unblocked through software 21:00:49 Waiting for reporter to try what waldi asked for 21:00:57 #topic Bug #1150966: (n, u) linux-image-amd64: usb_core hangs after dockstation usb-c disconnect 21:01:47 Not new. I have an action for this from last week 21:02:01 #topic Bug #1151225: (n, Mu) linux: ThinkPad L14 Gen 2 AMD (20X6): ~10s delay on resume from s2idle; disappears with iommu=pt 21:02:18 Waiting for reporter to test a patch 21:02:33 #topic Bug #1151339: (n, u) linux-image-7.2.11+deb14-amd64 prevents Behringer UMC404HD USB audio interface from working 21:03:19 there should be fix landing and backported to relevant stable series 21:03:30 right 21:03:40 not hecked yet if it is in the curent round of reviews, but would add a bug closer if yes 21:04:12 I think it is not yet 21:04:24 No mention of Behringer in the queued patches 21:04:35 but I think we can leave this with upstream for now 21:04:42 * carnil nods 21:04:45 #topic Bug #1151392: (n, Mu) linux-image-6.12.113: EM7430 MBIM transaction timeouts mark modem invalid 21:05:22 Waiting for reporter to provide more information 21:05:33 #topic Bug #1151553: (n, u+M) linux: fastrpc: Reduce console noise from expected DSP info, reserved memory and session messages 21:06:12 another bug for Agathe 21:06:33 And she will (or has?) opened an MR 21:06:55 Oh yes there is an MR already 21:07:09 #topic Bug #1151843: (n, ) linux-image-6.1.0-54-amd64: DCF77 Doesn't work after kernel update. 21:07:14 a MR for us? The forwarded link is somewhere else 21:07:26 https://salsa.debian.org/kernel-team/linux/-/merge_requests/2135 21:07:41 I marked as forwarded to both the upstream reference and our MR 21:09:14 So this one is a regression in 6.1.x and they seem to have found a relevant change 21:09:29 #action bwh will respond to #1151843 21:09:42 #topic Bug #1151912: (n, ) linux-image-7.2.9+deb13-amd64: No sound for Intel Lunar Lake-M HD Audio Controller 21:10:06 Did we already have a similar bug report? 21:11:00 Seems to be missing firmware 21:11:05 does "I'm currently using the kernel and firmware-intel-sound from Trixie backports." mean that trixie backports is fine while 7.2.9 is not? 21:11:52 They have firmware-intel-sound but apparently not firmware-sof-signed 21:12:16 Maybe that deserves a Recommends... 21:12:36 ask for `dmesg | grep firmware` ? 21:13:13 or better the complete kernel log 21:13:39 I think they figured out they need firmware-sof-signed, but that is also insufficient; see #1152302 21:14:17 #action bwh will close #1151912 21:14:19 aah, now I understand the last message, they want to close the report against the kernel 21:14:37 #action bwh will consider making firmware-intel-sound recommend firmware-sof-signed 21:14:47 #topic Bug #1151632: (w, ) linux: config: consider setting DRIVER_DEFERRED_PROBE_TIMEOUT to -1 (arm64 luks laptops) 21:15:05 ignore 21:15:06 I already started on a reply to this, so: 21:15:14 #action bwh will respond to #1151632 21:15:35 #topic Bug #1152062: (n, ) dracut-install in armhf does not add mmc kernel modules 21:16:03 I think we can leave this with the dracut uploaders for now 21:16:38 * ukleinek nods 21:16:38 ack 21:16:41 #topic Bug #1151737: (w, ) firmware-nonfree: Please ship all Rockchip firmware 21:17:52 This is asking for a file that is not even in a released upstream version... 21:18:14 "Age 11 days" according to upstream git 21:18:16 I expect I will deal with it when that release happens 21:18:26 sounds sensible 21:18:30 #topic Bug #1150964: (n, uM) nfs-kernel-server: autostart or listeners won't start with nfsdctl reporting "Error: Invalid argument" 21:18:56 carnil asked to contact upstream about the issue 21:19:01 I don't think anything changed here in the last week 21:19:12 #topic Bug #1151866: (n, u) nfs-common: host= setting in nfs.conf inadaquate 21:19:39 I think this as well needs to go upstream, ideally the reporter ask there 21:19:42 right 21:20:01 I will ask the reporter to followup on linux-nfs@... 21:20:59 #action carnil will ask for #1151866 to be directed upstream 21:21:13 #topic Migration excuses 21:22:04 Despite what it says there, it looks like they are both waiting for loong64 autopkgtest and iproute2 is also too young 21:22:32 I don't see any autopkgtest regressions in the current excuses files 21:22:37 So, no action required 21:22:44 #topic New upstream versions 21:23:28 I still have firmware-nonfree, ktls-utils, kup on my radar. I would be happy for someone else to look at ktls-utils though. 21:24:24 I'm interested in the NFS topic, so ktls-utils was on my future radar, but I cannot promise I manage for next week, so if someone is faster it is okay :) 21:24:43 I won't give you any action then 21:24:49 #topic Merge requests 21:24:52 no 21:24:56 * ukleinek has no particular interest in ktls-utils, but if he finds the time he might look, too 21:25:06 Is there anything here we need to discuss? 21:25:08 !2136 is (I think) a trivial fix, but a 2nd pair of eyes would be appreciated 21:25:23 https://salsa.debian.org/kernel-team/linux/-/merge_requests/2136 21:25:46 I'll look at it 21:25:51 thx 21:26:27 #topic AOB 21:26:37 is btw debian/latest after that in releasable state for next experimental upload? 21:26:44 or anything pending? 21:27:12 idk 21:27:34 ok I will ask waldi :) 21:28:18 Who will chair next week? 21:28:28 it would be waldi's turn 21:28:49 #action ukleinek asks waldi to chair next week, with being a fallback himself 21:28:55 Thank you 21:28:58 thank you! 21:29:01 #endmeeting