20:00:32 <bwh> #startmeeting
20:00:32 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:37 <yunseong[m]> Hello
20:00:49 <bwh> waldi said he cannot be present today
20:01:14 <ukleinek> o/
20:01:30 <carnil> hi
20:02:12 <bwh> 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 <bwh> OK, ready
20:03:17 <bwh> Anything urgent topics before we get into the bug list?
20:03:30 <ukleinek> nothing on my side
20:04:28 <bwh> #topic Bug #1151598: (S, ) linux-image-amd64 6.12.113-1 kernel regression on ath9k_htc modules
20:04:59 <ukleinek> Message #10 claims this is fixed in a new stable version
20:04:59 <bwh> That needs reassigning
20:05:03 <carnil> I just merged that into the other
20:05:10 <bwh> OK
20:05:28 <carnil> for reference #1151097
20:05:41 <carnil> and have already as well a closer for the 6.12.y upload
20:05:59 <bwh> good, so let's move on
20:06:10 <bwh> #topic Bug #1141183: (i, u) src:linux: I/O errors on SATA devices related to IOMMU
20:07:11 <bwh> 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 <bwh> Actually now I see the original report doesn't have an IOMMU error in the log before the ATA error
20:08:41 <ukleinek> #action ukleinek asks the new reporter in #1141183 if iommu=off helps and to report a separate issue if not
20:08:45 <bwh> right
20:09:23 <bwh> #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 <carnil> reporteer did provide some logs yesterday
20:10:18 <carnil> I have not looked yet at the results, TBH
20:10:26 <ukleinek> looks like a pain to go through
20:10:35 <bwh> yeah
20:11:08 <bwh> I don't know why they tested with 7.2.9 now when there are several newer versions available
20:11:27 <ukleinek> because carnil asked for that?
20:11:31 <bwh> That is true
20:11:52 <carnil> 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 <bwh> Can we forward this upstream now?
20:12:17 <ukleinek> depends on what is in the provided log files
20:13:26 <carnil> 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 <carnil> 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 <bwh> OK, there are a bunch of amdgpu fixes since 7.2.9, so that seems reasonable
20:15:22 <carnil> 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 <bwh> right
20:16:53 <carnil> should I take the action?
20:17:24 <bwh> If you are not too busy. You are very busy, aren't you?
20:17:49 <carnil> #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 <bwh> #topic Bug #1149525: (i, ) linux: RockPro64 conntrack oops with 7.2.x
20:18:04 <carnil> bwh: asking this question is easy enough, I take it
20:19:42 <bwh> I suppose we're just waiting on upstream for this one
20:19:51 <ukleinek> yes, no reply from upstream yet
20:20:19 <ukleinek> if I don't get a reply, I can visit Florian, who lives in my city :-D
20:20:27 <bwh> 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 <bwh> #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 <bwh> Waiting for bug script output
20:21:20 <bwh> #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 <ukleinek> waiting for bisection results
20:21:43 <bwh> right
20:21:54 <bwh> #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 <ukleinek> queued fixes in various stable version
20:22:29 * carnil nods
20:22:53 <bwh> OK so no action needed besides noting the bug closer
20:22:55 <carnil> no action needed apart adding (not forgetting rather) to add an appropriate bug closer
20:23:09 <bwh> #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 <ukleinek> don't forget the bug closer
20:23:49 <ukleinek> "already queued for the next 6.1.y"
20:23:52 <bwh> Fix is queued (presumably in the current review)
20:24:21 <ukleinek> it was sent on Oct 8, so might already be "in"
20:24:46 <ukleinek> ah no, this is not sent by Greg, but a submit to stable
20:24:47 <bwh> it isn't
20:25:08 <carnil> https://lore.kernel.org/stable/20261028170508.836716892@linuxfoundation.org/ ?
20:25:30 <ukleinek> carnil: yes, that's it
20:26:04 <bwh> #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 <bwh> Waiting for reporter to test a patch
20:26:42 * ukleinek nods
20:26:59 <bwh> #topic Bug #1151916: (i, Mu) linux: xhci AMD Renoir [1022:1639] USB hotplug detection broken after boot on 6.12.113
20:27:37 <carnil> reporter started bisecting but needed to restart
20:27:41 <bwh> right
20:27:54 <bwh> #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 <ukleinek> might be worth to point out that bisect log has all the tests from before the error
20:30:18 <ukleinek> tainted O but not P by nvidia modules
20:31:09 <bwh> Yes that's strange
20:31:26 <yunseong[m]> Can I look into it and ask it more to reporter?
20:31:46 <bwh> Anyway - ath11k is doing a 1 MiB allocation with GFP_NOIO which seems like a bad idea
20:32:35 <bwh> I'm not sure how that ends up as a panic
20:33:15 <bwh> Oh right, there is an oops at the end
20:33:28 <bwh> yunseong[m]: Yes please do
20:33:44 <ukleinek> there is a possibility somehow to make malloc fail using some testing stuff. That might help to reproduce
20:34:04 <bwh> #action yunseong[m] will respond to #1152007
20:34:12 <bwh> #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 <bwh> I think we need the full boot log for this
20:36:29 <bwh> We don't have any context for the nvme error log
20:36:41 <bwh> #action bwh will ask for complete boot log for #1152197
20:36:48 <bwh> #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 <ukleinek> would be great to see the crash-log (if any)
20:38:48 <bwh> It doesn't look sound like there is any log
20:39:57 <ukleinek> there might be if the screen wasn't off
20:41:46 <bwh> The patch they found doesn't seem to have been applied
20:42:07 <bwh> Well let's forward this upstream
20:42:51 <bwh> #action bwh will forward #1152341 upstream
20:42:55 <ukleinek> thx
20:43:07 <bwh> #topic Bug #877779: (n, ) linux: modpost uses wrong sizes for mips-octeon kernel
20:43:13 <bwh> That's an old one...
20:44:45 <bwh> I suppose I could have another look at this
20:45:03 <bwh> #action bwh will look at #877779 again
20:45:09 <ukleinek> does it pick wrong compiler flags?
20:45:42 <bwh> I don't remember exactly how this goes wrong
20:46:31 <bwh> 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 <ukleinek> "Upstream generates the offsets with the target
20:46:45 <ukleinek> compiler, so it does not have this problem.
20:46:46 <ukleinek> "
20:47:12 <bwh> 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 <ukleinek> why do we ever need more than the target modpost?
20:48:17 <bwh> Cross-building modules
20:48:20 * ukleinek thinks that shouldn't be discussed life and withdraws the question
20:48:29 <ukleinek> s/life/live/
20:49:27 <bwh> 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 <bwh> #topic Bug #1115110: (n, ) linux-image-6.16.5+deb14-amd64: Unable to Suspend or Shutdown Computer
20:50:08 <bwh> OK, nothing actually new here
20:50:21 <bwh> #topic Bug #1139313: (n, Mu+) linux: Snapdragon X1 SoCs: random crashes when using git
20:50:47 <ukleinek> Agathe Porte bug tracking, we can ignore I guess
20:51:05 <bwh> Nothing for us to do, anyway
20:51:12 <bwh> #topic Bug #1146033: (n, M) linux-image-7.1.8+deb14.1-amd64: cannot shutdown laptop
20:51:37 <bwh> We have a bisect log
20:51:48 <bwh> and the bad commit is a merge :-(
20:52:19 <bwh> Oh, because they used --first-parent
20:52:44 <ukleinek> ah, that also explains why the bisection is that short
20:53:21 <ukleinek> #action ukleinek follows up to #1146033 asking for a bisect of the non-first-parent history
20:53:36 <bwh> carnil: I don't follow your reasoning for saying to use --first-parent
20:54:16 <ukleinek> bwh: that reduces the build cost considerably for each step
20:54:42 <bwh> OK. I don't think I tried doing that before
20:55:06 <carnil> 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 <carnil> and then in a second step narrow down that branch from the merge with a further bisect
20:55:34 <ukleinek> 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 <bwh> OK that makes a lot of sense. TIL and I should remember to try that in future
20:56:03 <bwh> #topic Bug #1149377: (n, uM) linux-image-6.12.111+deb13-amd64: Bluetooth no longer works after kernel upgrade
20:57:01 <ukleinek> waiting for upstream to revert stuff in stable
20:57:04 <bwh> I don't see the reverts in the queue
20:57:21 <carnil> yeah still not :(
20:57:23 * ukleinek also didn't see them when checking earlier today
20:57:50 <ukleinek> well, the intention was announced on Sunday
20:58:14 <bwh> I don't think anyone actually said they would do ti
20:58:49 <bwh> Thorsten and Sasha agreed that there should be a revert but neither said they would send/add patches
20:59:05 <ukleinek> "If it helps, I can send reverts of 980084de4d9b and 6f0624b4427e" was written by Christoph
20:59:10 <bwh> Ah yes
20:59:22 <bwh> OK then let's wait for that
20:59:43 <carnil> +1
20:59:50 <bwh> #topic Bug #1149988: (n, M) linux-image-7.2.9+deb14-amd64: sound does not work in any 7.2 kernels
21:00:05 <bwh> Waiting for bisection
21:00:12 <bwh> #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 <bwh> Waiting for reporter to try what waldi asked for
21:00:57 <bwh> #topic Bug #1150966: (n, u) linux-image-amd64: usb_core hangs after dockstation usb-c disconnect
21:01:47 <bwh> Not new. I have an action for this from last week
21:02:01 <bwh> #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 <bwh> Waiting for reporter to test a patch
21:02:33 <bwh> #topic Bug #1151339: (n, u) linux-image-7.2.11+deb14-amd64 prevents Behringer UMC404HD USB audio interface from working
21:03:19 <carnil> there should be fix landing and backported to relevant stable series
21:03:30 <bwh> right
21:03:40 <carnil> not hecked yet if it is in the curent round of reviews, but would add a bug closer if yes
21:04:12 <carnil> I think it is not yet
21:04:24 <bwh> No mention of Behringer in the queued patches
21:04:35 <bwh> but I think we can leave this with upstream for now
21:04:42 * carnil nods
21:04:45 <bwh> #topic Bug #1151392: (n, Mu) linux-image-6.12.113: EM7430 MBIM transaction timeouts mark modem invalid
21:05:22 <bwh> Waiting for reporter to provide more information
21:05:33 <bwh> #topic Bug #1151553: (n, u+M) linux: fastrpc: Reduce console noise from expected DSP info, reserved memory and session messages
21:06:12 <ukleinek> another bug for Agathe
21:06:33 <bwh> And she will (or has?) opened an MR
21:06:55 <bwh> Oh yes there is an MR already
21:07:09 <bwh> #topic Bug #1151843: (n, ) linux-image-6.1.0-54-amd64: DCF77 Doesn't work after kernel update.
21:07:14 <ukleinek> a MR for us? The forwarded link is somewhere else
21:07:26 <carnil> https://salsa.debian.org/kernel-team/linux/-/merge_requests/2135
21:07:41 <carnil> I marked as forwarded to both the upstream reference and our MR
21:09:14 <bwh> So this one is a regression in 6.1.x and they seem to have found a relevant change
21:09:29 <bwh> #action bwh will respond to #1151843
21:09:42 <bwh> #topic Bug #1151912: (n, ) linux-image-7.2.9+deb13-amd64: No sound for Intel Lunar Lake-M HD Audio Controller
21:10:06 <bwh> Did we already have a similar bug report?
21:11:00 <bwh> Seems to be missing firmware
21:11:05 <ukleinek> 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 <bwh> They have firmware-intel-sound but apparently not firmware-sof-signed
21:12:16 <bwh> Maybe that deserves a Recommends...
21:12:36 <ukleinek> ask for `dmesg | grep firmware` ?
21:13:13 <ukleinek> or better the complete kernel log
21:13:39 <bwh> I think they figured out they need firmware-sof-signed, but that is also insufficient; see #1152302
21:14:17 <bwh> #action bwh will close #1151912
21:14:19 <ukleinek> aah, now I understand the last message, they want to close the report against the kernel
21:14:37 <bwh> #action bwh will consider making firmware-intel-sound recommend firmware-sof-signed
21:14:47 <bwh> #topic Bug #1151632: (w, ) linux: config: consider setting DRIVER_DEFERRED_PROBE_TIMEOUT to -1 (arm64 luks laptops)
21:15:05 <ukleinek> ignore
21:15:06 <bwh> I already started on a reply to this, so:
21:15:14 <bwh> #action bwh will respond to #1151632
21:15:35 <bwh> #topic Bug #1152062: (n, ) dracut-install in armhf does not add mmc kernel modules
21:16:03 <bwh> I think we can leave this with the dracut uploaders for now
21:16:38 * ukleinek nods
21:16:38 <carnil> ack
21:16:41 <bwh> #topic Bug #1151737: (w, ) firmware-nonfree: Please ship all Rockchip firmware
21:17:52 <bwh> This is asking for a file that is not even in a released upstream version...
21:18:14 <ukleinek> "Age 11 days" according to upstream git
21:18:16 <bwh> I  expect I will deal with it when that release happens
21:18:26 <ukleinek> sounds sensible
21:18:30 <bwh> #topic Bug #1150964: (n, uM) nfs-kernel-server: autostart or listeners won't start with nfsdctl reporting "Error: Invalid argument"
21:18:56 <ukleinek> carnil asked to contact upstream about the issue
21:19:01 <bwh> I don't think anything changed here in the last week
21:19:12 <bwh> #topic Bug #1151866: (n, u) nfs-common: host= setting in nfs.conf inadaquate
21:19:39 <carnil> I think this as well needs to go upstream, ideally the reporter ask there
21:19:42 <bwh> right
21:20:01 <carnil> I will ask the reporter to followup on linux-nfs@...
21:20:59 <bwh> #action carnil will ask for #1151866 to be directed upstream
21:21:13 <bwh> #topic Migration excuses
21:22:04 <bwh> Despite what it says there, it looks like they are both waiting for loong64 autopkgtest and iproute2 is also too young
21:22:32 <bwh> I don't see any autopkgtest regressions in the current excuses files
21:22:37 <bwh> So, no action required
21:22:44 <bwh> #topic New upstream versions
21:23:28 <bwh> 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 <carnil> 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 <bwh> I won't give you any action then
21:24:49 <bwh> #topic Merge requests
21:24:52 <carnil> 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 <bwh> Is there anything here we need to discuss?
21:25:08 <ukleinek> !2136 is (I think) a trivial fix, but a 2nd pair of eyes would be appreciated
21:25:23 <ukleinek> https://salsa.debian.org/kernel-team/linux/-/merge_requests/2136
21:25:46 <bwh> I'll look at it
21:25:51 <ukleinek> thx
21:26:27 <bwh> #topic AOB
21:26:37 <carnil> is btw debian/latest after that in releasable state for next experimental upload?
21:26:44 <carnil> or anything pending?
21:27:12 <ukleinek> idk
21:27:34 <carnil> ok I will ask waldi :)
21:28:18 <bwh> Who will chair next week?
21:28:28 <ukleinek> it would be waldi's turn
21:28:49 <ukleinek> #action ukleinek asks waldi to chair next week, with being a fallback himself
21:28:55 <bwh> Thank you
21:28:58 <carnil> thank you!
21:29:01 <bwh> #endmeeting