19:00:05 <carnil> #startmeeting
19:00:05 <MeetBot> Meeting started Wed Sep 16 19:00:05 2026 UTC.  The chair is carnil. Information about MeetBot at https://wiki.debian.org/MeetBot.
19:00:05 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:13 <bwh> o/
19:00:20 <ukleinek> o/
19:00:20 <waldi> hi
19:00:23 <carnil> #chair bwh carnil ukleinek waldi
19:00:23 <MeetBot> Current chairs: bwh carnil ukleinek waldi
19:00:25 <carnil> hi
19:01:08 <carnil> so, welcome everybody! We start the with the usual question first
19:01:12 <yunseong[m]> hello
19:01:19 <carnil> is there anything you want to discuss before going to the bugs?
19:01:21 <carnil> hi yunseong[m]
19:01:27 <carnil> welcome as well
19:01:40 <waldi> no
19:01:46 <ukleinek> not on my side, too
19:02:27 <carnil> Ok then let's start with the bugs
19:02:43 <carnil> #topic #1144314: (i, u) refcount_t: addition on 0; use-after-free, regression from 260fbcb92bbe ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()")
19:03:14 <carnil> i update the forwarded references, we are now at v3 of patch upstream (which is basically back to the idea of v1 patch), has been tested, we are waiting that the change lands
19:03:43 <carnil> #topic #1145425: (i, M) linux-image-6.12.101+deb13-amd64: amdgpu Navi 23/W6600 flip_done timeout freezes display and requires hard reset
19:03:52 <ukleinek> a colleage recently got a v1 patch in, after the series went to (IIRC) v7 during one year ...
19:04:28 <carnil> 1. waiting for reporter after waldi asked to test newe versions
19:04:39 <bwh> OK
19:04:58 <carnil> (sounds at leas similar to things we had seen and said to be fixed in 7.1.8 and later, but won't necessarily help for 6.12.y :-/)
19:05:09 <carnil> #topic #1146343: (i, uM) amdgpu: RustDesk triggers VCE ring timeout and GPU reset on Polaris RX 480 since 6.12.105
19:05:17 <carnil> ukleinek asked more questions to test. Wait for reporting back.
19:05:36 * ukleinek nods
19:05:39 <carnil> #topic #1146423: (i, Mu) linux-image-7.1.8+deb14.1-amd64: boot error with dual amd gpu rx570 and rx580 setup after kernel package update to 7.1.8
19:05:57 <carnil> has been reported upstream, we need to wait
19:06:09 <carnil> the reporter has provided upstream a AI assisted patch, let's see where that goes
19:06:35 <carnil> #topic #1146519: (i, ) nftables autopkgtest from sid appears to kill arm64 cloud kernels from trixie
19:06:54 <carnil> this is a tough one :(
19:06:56 <carnil> Not easily reproducible outside of production system. Seems arm64 specific, as same issue not triggred on amd64. There is a plausible upstream commit (but likely not backportable), unstable kernel seems fine.
19:07:18 <waldi> no, this was triggered by nftables tests
19:07:20 <carnil> waldi pointed out at commit which should fix that, but it is probably not reasily backportable, was neither marked for stable
19:07:27 <waldi> there are two problems in this report
19:07:37 <carnil> should we split them up?
19:08:48 <carnil> (yes with production systems I meant their debusine workers, and getting killed when running the nftables tests, should have worded that better)
19:09:06 <waldi> those are not production machines. and they can use newer kernels
19:09:25 <carnil> waldi: my understanding was that the one problem is fixed with the change 6.15, correct?
19:09:42 <waldi> i hope so
19:10:07 <waldi> so lets close this bug with the correct version. and clone one for the stack overrun
19:10:15 <carnil> ok!
19:10:19 <carnil> waldi: would you do so?
19:10:24 <waldi> yes
19:11:08 <carnil> #action waldi will close #1146519 with the correct vesion and clone the bug to track the stack overrun issue
19:11:12 <carnil> thank you
19:11:26 <carnil> #topic #1146667: (i, M) linux-image-7.1.12+deb14-armmp: stops at random during boot on cubieboard 1 (armhf)
19:11:35 <carnil> ukleinek asked few questions/suggestions for further debugging. Wait for feedback from reporter
19:11:41 * ukleinek nods
19:11:46 <carnil> #topic #1147171: (i, ) linux-image-7.1.12+deb14-amd64: kernel panic after NVMe I/O errors
19:11:58 <carnil> this is a new report
19:12:27 <ukleinek> didn't have a similar bug some time ago?
19:12:43 <carnil> "new" (it was I think already present for the last meeting), but we have not yet handled it
19:13:26 <ukleinek> #1136401
19:13:47 <ukleinek> maybe it's that that I seem to recall
19:14:03 <bwh> I suppose it's worth asking what the earlier WARN was for
19:15:00 <carnil> in the kernel command line I see nvme_core.default_ps_max_latency_us=0 additionally, is this sensible?
19:15:16 <bwh> I noticed that but don't know what it does
19:15:21 <ukleinek> there is "[   23.487227] warning: `gnome-shell' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211", but that probably doesn't set the WARN taint, does it?
19:15:33 <bwh> no
19:16:21 <ukleinek> "max power saving latency for new devices; use PM QOS to change per device" is the help string for nvme_core.default_ps_max_latency_us
19:16:53 <bwh> I suppose setting it to 0 should disable power saving, but I'm not sure
19:17:35 <carnil> in drivers/nvme/host/pci.c there is:
19:17:37 <carnil> dev_warn(dev->ctrl.device,
19:17:37 <carnil> "Does your device have a faulty power saving mode enabled?\n");
19:17:40 <carnil> dev_warn(dev->ctrl.device,
19:17:43 <carnil> "Try \"nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off\" and report a bug\n");
19:18:26 <bwh> So it seems pretty safe :-)
19:19:01 <waldi> the logs start after the nvme is already dropped from the system
19:19:42 <bwh> I suppose this is recovered from the QR code or efivars
19:20:05 <waldi> yes, so there is nothing more available
19:20:08 <bwh> Code is showing as all-zeroes
19:21:02 <ukleinek> does this all zero happen if a page needs to be swapped in but the swap is gone?
19:21:25 <bwh> I would expect the task to hang instead...
19:21:51 * ukleinek looks in the air shortly and agrees to bwh's expectation
19:22:20 <ukleinek> strange that both journald and init segfault
19:22:56 <bwh> Let's ask what the WARN was and to check for NVME firmware updates
19:23:18 <carnil> ok, then at least we have  start of a plan
19:23:18 <ukleinek> sounds like a good idea
19:23:26 <carnil> bwh: you want to take that?
19:23:30 <bwh> OK
19:23:33 <carnil> (or no resources?)
19:23:34 <carnil> ok
19:23:54 <ukleinek> otherwise Trump might have acted, he is the one with starts of plans :-D
19:24:09 <carnil> #action bwh will ask reporter of #1147171 what the WARN was about and to check for availability of  NVME firmware updates
19:24:33 <carnil> #topic #1147252: (i, u) 6.12.107-1: analog jack stereo walks L/R (Meteor Lake SOF)
19:25:01 <carnil> the reporter claims it is a regression between 6.12.94 and 6.12.107, so sent bisect instruction (and first narrow down more the Debian revisions inbetween)
19:25:12 <carnil> #topic #1147322: (i, ) linux-image-7.1.8+deb13-amd64: Kernel panic when Wi-Fi driver try to restarting / reconfigure the Wi-Fi interface.
19:25:15 <carnil> new report
19:25:25 <carnil> no triage done yet
19:27:11 <ukleinek> what does the reporter mean saying "on restart/reconfiguration"?
19:27:31 <ukleinek> rebinding the driver? restarting network-manager? disabling wifi?
19:27:40 <bwh> Yeah that's unclear
19:28:05 <yunseong[m]> I can take this issue. I will ask it more.
19:28:18 <ukleinek> also seeing the panic would be helpful
19:28:47 <carnil> yunseong[m]: sounds good, thank you
19:28:51 <ukleinek> ..ooOO(There is a reason all this information is dumped to the console)
19:29:08 <bwh> The panic is in the attached file
19:29:32 <carnil> #action yunseong will take care of asking some questions back on 1147322 the problem
19:29:56 <carnil> ugh, that is not understandable ...
19:30:25 <ukleinek> Tainted: [I]=FIRMWARE_WORKAROUND ??
19:30:47 <carnil> yunseong[m]: if the machine works without the OOT module, please as well ask if it is reproducible with not loading them, but I do not know for what those are
19:31:19 <yunseong[m]> Ok, Thank you!
19:31:44 <bwh> ukleinek: There are a few reasons for that but those I can remember are not that serious
19:32:54 <carnil> do we have nough to start tackle it, yunseong[m]?
19:34:00 <carnil> #topic #1110749: (n, u) ee1004: DDR4 SPD cannot be read, decode-dimms fails, “Failed to select page 0 (-6)”
19:34:25 <carnil> this is handled by upstream (Jean Delvare). Jean Delvare said that reported back information confirmed his guess on the problem and proposed a series of short term workarounds. Wait for proper upstream solution?
19:35:14 <bwh> right
19:35:26 <carnil> #topic #1125155: (n, ) /usr/share/bug/linux-image-6.12.57+deb13-amd64/include-pci: amdgpu flip timeout, system freezes
19:35:42 <ukleinek> why does pr_err(FW_BUG "Unable to handle %s in EFI runtime service\n", msg); add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); clear_bit(EFI_RUNTIME_SERVICES,
19:36:08 <ukleinek> why does https://wiki.debian.org/KernelModuleBlacklisting suggest calling depmod?
19:36:18 <carnil> Folloup from a new user, claiming to see the same problem but with 7.1.y kernel. Similar to one of the bugs above, some amdgpu and flip timeout issues were actually adressed in 7.1.8 and later.
19:36:48 <carnil> We do not know here which version the "new user" has, so might be worth to ask if they had at least 7.1.8?
19:37:06 <carnil> OTOH should not take over the report from the original impacted user
19:37:20 <carnil> so maybe we should simply ask to fill first a new bug
19:37:50 <ukleinek> sounds like a good idea
19:37:57 <carnil> ok I will do that
19:38:20 <carnil> #action carnil ask the new user in #1125155 to fill a new separate issue
19:38:31 <carnil> #topic #1145585: (n, RM) linux-image-6.12.101+deb13-amd64: kernel panicked twice with timer cancellation
19:38:57 <carnil> yunseong[m] followed up with the reporter, we are waiting for feedback
19:39:10 <carnil> #1146033: (n, M) linux-image-7.1.8+deb14.1-amd64: cannot shutdown laptop
19:39:24 <carnil> followup from the reporter saying still has the problem with both 7.1.13 and 7.2.3
19:39:43 <carnil> (removed the moreinfo tag already)
19:40:31 <bwh> I still don't see where the S taint bit is set
19:41:10 <carnil> oh right the question from waldi is not yet answered
19:41:46 <waldi> bwh: i think this was "x86/CPU: Running old microcode"
19:42:01 <waldi> right, this was on me to ask for microcode update first
19:42:05 <bwh> Right, which is in early boot and presumably doesn't go through the usual path
19:42:20 <bwh> We should probablyadd {intel,amd64}-microcode to the related packages list
19:42:52 <waldi> yes
19:42:54 <carnil> we had:
19:42:56 <carnil> microcode too old, @waldi will ask for installing the right microcode package and extend the bug scripts to list microcode packages installed
19:43:02 <carnil> in the nodes of the previous meeting
19:43:19 <bwh> This  old CPU hasn't had microcode updates for a while though
19:43:28 <bwh> OK
19:44:22 <carnil> it is probably still at least a try to see if microcode packages ship a newer revision applicable for that CPU
19:44:52 <bwh> yes
19:45:15 <carnil> waldi: still planning to do both 1. asking for microcde update 2. then to expand our bug scripts?
19:45:40 <waldi> yes
19:45:56 <ukleinek> (FTR: There is no dependency that 2 has to wait until after 1)
19:46:28 <carnil> #action waldi will ask the reporter of #1146033 to install the right microcode package and report back if the issue persist
19:46:51 <ukleinek> ..ooOO(microcde sounds like an ancient but minimized desktop environment :-D)
19:47:28 <waldi> like enlightenment?
19:47:57 <carnil> #topic #1147177: (n, ) linux-image-amd64: audio crackling/dropout on Meteor Lake HDA after 6.12.94 -> 6.12.107 upgrade
19:47:59 <ukleinek> CDE was what was running on the SUN workstations back then
19:48:15 <bwh> Same reporter, versions, and SoC as #1147252
19:48:26 <carnil> same reporter as a couple of lines above, same regression range, asked the same question on first narrowin down the Debian revisions and then bisect. Wait.
19:48:48 <carnil> #topic #1147430: (n, ) linux-image-6.12.107+deb13-amd64: Intel Raptor Lake Audio Controller stuck in persistent D3 power state
19:48:52 <carnil> this is a new report
19:49:33 <bwh> Firmware bug
19:49:47 <bwh> or hardware
19:50:06 <bwh> #action bwh will close  #1147430 as not a kernel bug
19:50:12 <carnil> thanks!
19:50:38 <carnil> we are done with src:linux bugs, there is one dracut bug for a CVE
19:50:44 <carnil> #topic
19:50:44 <carnil> #1147447: (i, u) dracut: CVE-2026-15816
19:51:11 <ukleinek> #topic #1147447: (i, u) dracut: CVE-2026-15816
19:51:24 <carnil> I think jmm already as well identified the upstream change to apply/covering the issue, expect bdrung will include the fix in a future update
19:51:48 <bwh> Where's the upstream change?
19:51:49 <carnil> so would leave it with bdrung IMHO
19:51:51 <ukleinek> that only triggers for netboot I guess? So the impact is limited?
19:52:25 <carnil> yes guess so, jmm_ marked as well no-dsa for trixie
19:52:28 <bwh> oh right, it's linked from the security tracker
19:53:24 <carnil> ok I would say let's leave it with dracut primary uploaders
19:53:29 <ukleinek> I agree, no action for us, bdrung should handle it
19:53:29 <bwh> OK
19:53:42 <carnil> #topic Migration excuses
19:54:16 <carnil> dracut migrated already
19:54:32 <carnil> iproute2 is in bluca's hands
19:54:39 <bwh> and iproute2 seems to only be waiting for tests - I don't see any regressions on tracker.d.o
19:54:49 * carnil nods
19:55:06 <carnil> although it is interesting it is taking that long
19:55:13 <carnil> 13 days old (needed 5 days) already
19:55:22 <bwh> yes
19:55:57 <bwh> #action bwh should linkify the migration excuses in find-recent-urgent
19:56:11 <carnil> nice idea :)
19:56:25 <carnil> #topic New upstream versions
19:56:40 <bwh> I'll try to update firmware-nonfree and wireless-regdb soon
19:56:44 <carnil> firmware-free as usual, nothing to do I guess
19:56:45 <carnil> ack
19:56:53 <carnil> linux/7.3~rc2 and later
19:57:15 <waldi> will do linux
19:57:16 <carnil> I will upload tonight or latest tomorrow 7.2.6-1 to unstable, then we can handle 7.3-rcX in debian/latest
19:57:37 <carnil> #topic Merge requests
19:58:07 <carnil> should we take https://salsa.debian.org/kernel-team/linux/-/merge_requests/2089 ?
19:58:52 <carnil> Loic said on IRC that he talked in Hamburg(?) with bwh, so guess that should be fine?
19:59:28 <ukleinek> that sounds like a janitorial procedure that could be automated
19:59:33 <bwh> That wasn't about these specific changes but generally about sending updates for arm64 hw support
20:00:17 * ukleinek seems to recall that he had some scripts or oneliners to find settings not honored in the final configuration
20:02:25 * ukleinek hasn't any todo yet, so he will look into !2089
20:02:31 <carnil> okay maybe let's see they make sense and then merge
20:02:33 <carnil> ok
20:02:44 <carnil> #action ukleinek will look into https://salsa.debian.org/kernel-team/linux/-/merge_requests/2089
20:03:00 * ukleinek was about to type the same, thanks
20:03:12 <carnil> the seond one ready is from bluca !1845 about enabling KEXEC_HANDOVER and LIVEUPDATE
20:03:22 <carnil> not sure if someone has energy to review it
20:03:32 <bwh> One of these days...
20:03:44 <carnil> ok, then let's move to the last topic almost in time
20:03:49 <carnil> #topic AoB
20:04:06 <waldi> noone managed to reply to my meta package mail
20:04:07 <carnil> most important question, who will chair next week?
20:04:16 <bwh> waldi: Sorry :-/
20:04:19 * ukleinek can chair next week
20:04:28 <carnil> waldi: yes :(
20:04:34 <ukleinek> #action ukleinek will chair on 2026-09-23
20:05:09 <carnil> we should take it maybe straight on the next agenda, with a remainder to have  look if feasible till next week?
20:05:30 <bwh> right
20:05:39 <carnil> ukleinek: ^^ can you put it on the agenda?
20:05:52 <ukleinek> noted
20:05:57 <carnil> I guess we are done
20:06:13 * ukleinek is done, too
20:06:15 <carnil> #endmeeting