19:00:00 <carnil> #startmeeting
19:00:00 <MeetBot> Meeting started Wed Oct 14 19:00:00 2026 UTC.  The chair is carnil. Information about MeetBot at https://wiki.debian.org/MeetBot.
19:00:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:05 <yunseong[m]> Hi
19:00:07 <carnil> Hi
19:00:33 <ukleinek> o/
19:00:35 <carnil> #chair bwh carnil ukleinek waldi
19:00:35 <MeetBot> Current chairs: bwh carnil ukleinek waldi
19:00:42 <waldi> hi
19:00:47 <carnil> hi, welcome to today's meeting
19:01:07 <carnil> Is there anything you would like to discuss in advance?
19:01:42 <waldi> i have nothing to discuss
19:01:55 <ukleinek> I asked earlier today about a newer kernel in trixie, is that something to discuss?
19:03:35 <ukleinek> I don't know the statistics, maybe carnil has a better overview about unfixed problems in 6.12?
19:03:35 <carnil> maybe. As you attended the converence and have talked to people you might share your takeaways for this topic with respect to input from upstream for us in Debian?
19:04:48 <ukleinek> I talked to Greg and Ted T'so. IIRC it was Ted who said that the number of CVEs in older stable releases is constantly growing and Greg always preaches about updating
19:05:07 <waldi> number of CVE is no useful metric
19:05:28 <ukleinek> yeah, there is no useful metric, CVEs is at least a hint
19:05:54 <carnil> ukleinek: if you want numbers if I did not do something wrong there would be 727 CVEs assigned which are fixed in mainline and not yet in in 6.12.y
19:06:23 <ukleinek> and compared to that in 6.18?
19:07:34 <carnil> difference between 6.12.y and 6.18.y would be roughly ~360, and unfixed in 6.18.y vs mainline would be ~400
19:07:49 <carnil> but I'm not sure I grabed the numbers correctly, I was not prepared to answer that :)
19:08:03 <carnil> I oculd try to do a cleaner evaluation
19:08:19 <ukleinek> Anyhow: My thought was to provide the next LTS kernel for trixie to give those who care a chance
19:08:29 <ukleinek> carnil: IMHO good enough, thanks
19:09:31 <ukleinek> and assuming we're lucky for trixie and 6.12.x is supported until trixie's EOL, we at least gather some experience about how this could be handled if there is no such longrunning stable release for forky's lifetime
19:09:40 <carnil> we might need to think about it, but it doubles the maintenance as well and it would need to be properly support both for security and point releases
19:09:48 <waldi> do we need even another line of kernels? so we really need to talk about a separate distribution, as this fits in neither
19:10:03 <waldi> because then we also want to update oldstable to the same state
19:11:14 <ukleinek> I'm aware that the maintenance effort increases, but I wonder if going with one kernel per Debian release is feasible in the long run.
19:11:29 <carnil> bwh point of view with respect of his expeirence with maintenace already of two versions in LTS would be interesting to hear, btw, as we have something simliar ther already
19:11:51 <ukleinek> I don't see the need for oldstable now, but that might just be me?
19:12:20 <waldi> you brought it up. if it is not good for stable, it is not good for oldstable
19:12:27 <carnil> ukleinek: well yes, because when there is a new stable release, both oldstable and stable will be maintained for an overlapping time
19:12:53 <carnil> that mans we would need to care as well of this situation for oldstable IMHO
19:12:56 <ukleinek> oldstable has 6.1 and 6.12 in backports. 6.12 is less of an effort (I guess) as this is also the trixie kernel
19:13:41 <ukleinek> carnil: ack, but to start introducing a newer LTS kernel to trixie wouldn't imply the same for bookworm
19:14:42 <ukleinek> I suggest to not hijack the meeting with this discussion, but to keep that in mind and maybe talk about that at a later point?!
19:15:15 <carnil> yes good, with this aspect it would be nice to have a face-face longer kernel-team gathering, but that is as well another topic :)
19:15:20 <carnil> let's start with the bugs?
19:15:25 * ukleinek nods
19:15:35 <carnil> ukleinek: thanks for raising the topic!
19:15:49 <carnil> #topic #1148364: (i, u) riscv64: strnlen() returns a truncated length for very large count, breaking ACPI name resolution (AE_AML_NAME_NOT_FOUND flood at boot) (merged with #1148365) (forwarded: lore.kernel.org)
19:16:00 <carnil> Fixed upstream, included in v7.3-rc7 and will be in the next experimental upload. Queued as well for 7.2.11 (for th next unstable upload).
19:16:07 <carnil> -> nothing to do more here right now
19:16:19 <carnil> (other than uploading both versions)
19:16:22 <ukleinek> sounds good
19:16:40 <carnil> #topic #1149109: (i, M) linux-image-7.1.8+deb13-amd64: amdgpu flip_done timed out and freeze on RX 6600 (regression from 7.1.3)
19:17:00 <carnil> wait as well, I asked to test newer versions, so far no feedback recieved.
19:17:00 <ukleinek> seems the ball is on the reporter's side
19:17:11 <carnil> #topic #1149525: (i, ) linux: RockPro64 conntrack oops with 7.2.x
19:17:28 <carnil> Reporter say here that it is still an issue in 7.2.10.
19:17:42 <carnil> has a "simpler" reproducer, just loading nf_conntrack to trigger the problem
19:18:11 <carnil> I was wondering if this could be related to the other nftrables bug on arm64 which we had, although it is not the very same (at least not the provided trace afaics)
19:18:19 <ukleinek> that rings a bell, but maybe only because we talked about that bug before. There is no other but with oops in conntrack I guess?
19:18:27 <carnil> the other bug would be #1148079
19:19:19 <ukleinek> maybe that's what I recall, but stackoverflow != invalid pointer
19:20:41 <ukleinek> 0x10037 is strange.
19:21:30 <waldi> hmm, what is the "(P)" in "gc_worker+0x130/0x780 [nf_conntrack] (P)"`
19:21:32 <waldi> ?
19:22:33 <carnil> is this proprietary module loaded?
19:23:04 <carnil> but why does it appear there and not in the module list, so maybe it is something else
19:23:08 <waldi> the kernel is untainted according to it
19:23:38 <waldi> and arm64 only knows two other flags to show here:
19:23:39 <waldi> flags.fgraph ? "F" : "",
19:23:39 <waldi> flags.kretprobe ? "K" : "",
19:24:48 <ukleinek> matches my findings, no idea about P
19:25:51 <ukleinek> bdf8eafbf7f56f9fa43a019cdc1a5f057210f01d might be relevant
19:25:52 <waldi> err, fond it
19:25:55 <waldi> KUNWIND_SOURCE_REGS_PC
19:26:15 <waldi> so it just tells where it found the pointer, not proprietary
19:27:41 <ukleinek> #action ukleinek looks at the stacktrace from #1149525 and acts depending on his findings
19:28:17 <carnil> thanks!
19:28:28 <carnil> #topic #1150335: (i, ) linux-image-6.12.111+deb13-amd64: boot hangs with RCU stalls on CPUs 4/6 (HP DL360 G5) unless processor.max_cstate=1
19:28:58 <carnil> New report here. There are logs provided, which I have not yet even looked at.
19:29:43 <carnil> one observation is that the BIOS version is from 2011, not sure if there might be an update available; but the other thing is that the same kernel did work previously without workarounds and now causes as well problems
19:30:06 <ukleinek> "intel-microcode not
19:30:06 <ukleinek> installed
19:30:12 <waldi> dl360 g5 shouldn't be that rare
19:30:21 <ukleinek> " might also worth fixing
19:31:40 <ukleinek> "This is a remotely colocated production server with no out-of-band power
19:31:45 <carnil> in one of the screenshots there are Firmwar Bug's notices and errors
19:31:46 <ukleinek> control." :see-no-evil"
19:34:17 <ukleinek> We could ask the x86 guys in #linux-rt if that bug rings a bell
19:34:48 <carnil> ok
19:35:17 <ukleinek> #action ukleinek asks x86 team if they have an idea about #1150335
19:36:08 <carnil> #topic #1150523: (i, ) linux-image-6.1.0-53-amd64: repeatable early-boot general protection faults in __kmem_cache_alloc_node
19:36:13 <carnil> New report
19:37:55 <ukleinek> What is iLO virtual console? Isn't that something that should work irrespective of the OS?
19:39:47 <ukleinek> memtest?
19:40:06 <waldi> well, it crashes in the matrox 200 driver
19:40:32 <ukleinek> no pci data, but I also wondered if that server has such a graphics card
19:40:38 <waldi> not sure where the nvidia card comes in, as it clearly is not used. reportbug info from the working kernel
19:40:52 <waldi> so we can use the template from ben for that
19:41:39 <carnil> ok let's respond to the reporter to proivde more information through reportbug reporting and use Ben's template
19:41:49 <carnil> waldi: do you want to do that or should I take care of it?
19:42:38 <carnil> okay I ask :)
19:42:44 <yunseong[m]> I searched iLO and is kind of BMC terminal from HP mother board.
19:43:00 <waldi> ilo is a out of band management thingy, yes
19:43:06 <carnil> #action carnil will ask reporter of ##1150523 to provide more information by filling followup with reportbug (use Ben's template)
19:43:18 <carnil> #topic #1150669: (i, ) linux-image-7.2.9+deb14-amd64: Attempted to kill the idle task after scheduling-while-atomic and page fault
19:43:29 <carnil> sorry that we are already running out of time soon
19:43:35 <carnil> this is as well a new report
19:43:50 <ukleinek> carnil: I wonder if iLO really stops working or if it's "only" that the remote side stops reacting
19:44:59 <waldi> anyone knows this "x86/split lock detection" error?
19:45:06 <ukleinek> idk
19:46:38 <waldi> oh, interesting: https://github.com/ValveSoftware/steam-for-linux/issues/8003
19:46:45 <waldi> this is not new
19:48:42 <yunseong[m]> It's unfamiliar for me, but I can look into this issue with asking to reporter.
19:49:14 <carnil> one thing is if the issue is reproducible
19:49:28 <ukleinek> it seems a newer kernel(?) fixes it for the steam people
19:49:29 <carnil> the reporter say at the beginning of one observation
19:49:40 <ukleinek> would be interesting to know the involved kernel versions
19:50:31 <carnil> #action yunseong will look into #1150669 with asking reporter for more information.
19:50:53 <carnil> other ideas for yunseong[m]?
19:51:17 <carnil> otherwise we go to the next topic
19:51:35 <ukleinek> maybe it gives a hint if we knew what CContentUpdateC does
19:51:59 <waldi> this might be related: https://www.sentinelone.com/vulnerability-database/cve-2026-64070/
19:52:57 <waldi> ukleinek: this seems to be steam and it segfaults
19:54:00 <waldi> anyway, also a case for the new template and ask for all the information from reportbug
19:54:18 <carnil> let's move to the next one
19:54:22 * ukleinek nods
19:54:29 <carnil> #topic #1150737: (i, ) linux-image-6.12.111+deb13-amd64: Intermittent system hang when resuming from deep (S3) suspend on Dell OptiPlex 3060
19:55:12 <carnil> another new report. It is not clear to me if it is an experienced regression.
19:55:45 <carnil> bit if it is and given the reporter could clearly identify when the problem exists, I would have suggested to ask if it is a regression fro an earlier version and then ask to bisect.
19:56:51 <carnil> I will do so if nobody has an idea for the problem, then at least we get it rolling for the next meeting
19:56:54 <ukleinek> there are some knobs to debug suspend issues
19:58:30 <ukleinek> First let's ask about reproducibility and a test using the backports kernel
19:59:21 <carnil> #action carnil ask reporter of #1150737 on reproducibility of the issue, possiblity to test newer kernel to reproduce the problem, in case of regression give instructions to bisect
19:59:35 <carnil> #topic #1115110: (n, ) linux-image-6.16.5+deb14-amd64: Unable to Suspend or Shutdown Computer (merged with #1115111)
19:59:59 <carnil> bug reappered on the list because a new reporter followed up on the older bug. I would suggest we ask to fill a new separate issue for the problem.
20:00:18 <carnil> IMHO hard to conclude if it is the same issue
20:01:26 <carnil> okay will do :)
20:01:43 * ukleinek suspects it's a different issue
20:01:58 <carnil> #action carnil ask second user which followed up on #1115110  to fill a new bugreport
20:02:25 <carnil> ukleinek, waldi, yunseong[m] do you still have energy?
20:02:37 <waldi> not really
20:02:41 <ukleinek> nope
20:03:08 <carnil> okay let's skip the rest
20:03:09 <yunseong[m]> Me too ;(
20:03:48 <carnil> let's go straight then to any-other-business and finish the meeting
20:03:52 <carnil> #topic AoB
20:03:59 * ukleinek can chair next week
20:04:03 <carnil> chair for next meeting
20:04:10 <carnil> ukleinek: thanks!
20:04:20 <carnil> #action ukleinek will chair next meeting
20:04:34 <yunseong[m]> Thank you for preparing today's meeting!
20:04:35 <carnil> ukleinek, waldi and yunseong[m] thanks very much for partecipating!
20:04:41 <carnil> #endmeeting