20:00:04 <carnil> #startmeeting
20:00:04 <MeetBot> Meeting started Wed Oct 29 20:00:04 2025 UTC.  The chair is carnil. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:04 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:16 <waldi> hi
20:00:39 <carnil> #chair carnil bwh ukleinek waldi
20:00:39 <MeetBot> Current chairs: bwh carnil ukleinek waldi
20:01:01 <carnil> On request I have added on top two additional agenda items to discuss things before the buglist
20:01:14 <carnil> is there anything else someone wants to bring in?
20:01:23 <waldi> nope
20:01:26 * ukleinek doesn't
20:01:37 <carnil> let'start then, I guess two are enough :)
20:01:42 <carnil> #topic
20:01:53 <carnil> #topic future of iptables-legacy
20:02:00 * ukleinek inserts a "hi" a few lines above
20:02:00 <carnil> waldi: it's your stage
20:02:05 <waldi> yeah
20:02:44 * ukleinek was surprised to learn that yocto still defaults to iptables-legacy (and most people seem to stick to that, because there was a build failure if you explicitly select nft)
20:02:53 <waldi> this is the same as the architecture baseline thing. do we want to support everything until the bitter end or should we do a planned exit
20:03:13 <waldi> and iptables legacy is now hidden behind even another set of settings
20:03:45 <ukleinek> iptables legacy is different from the iptables compatible binaries that do nft behind the curtain, right?
20:04:01 <waldi> iptables-legacy vs iptables-nft
20:04:23 * ukleinek nods and would support to let iptables-legacy die for forky
20:04:28 <waldi> iptables-legacy contains a whole bunch of kernel code
20:05:03 * carnil wonders if https://codesearch.debian.net/search?q=iptables-legacy&literal=0 gives us a wide enough view where work is needed
20:05:07 <bwh> Hi, sorry I'm late
20:05:16 <carnil> hi bwh, no problem!
20:05:27 <carnil> bwh: we are discussing the iptables-legancy item
20:05:55 <ukleinek> huh, I'm surprised that there are explicit calls for iptables-legacy-*
20:05:59 <carnil> there are a lot of things in unstable which refer to iptables-legancy invocations apparently
20:06:23 <bwh> I think it would be reasonable to do an MBF for those
20:07:21 <bwh> But nftables may be so different that upstream will have trouble switching even within this release cycle. I don't know
20:07:26 <waldi> carnil: most look like fallbacks. but direct references to iptables-legacy will break many things already
20:07:32 <ukleinek> I wonder if there are any known incompatibilities that are relevant in practise
20:07:56 <ukleinek> bwh: deprecating iptables-nft would be a bigger challenge
20:08:22 <waldi> bwh: i don't think anyone proposed deprecating iptables(-nft)
20:08:23 <bwh> ukleinek: Right but we don't need to care about that
20:08:41 <ukleinek> there are even several matches in src:linux
20:08:57 <waldi> ukleinek: test code, for the legacy code paths i would assume
20:09:31 <ukleinek> probably right, they are all below tools/testing/selftests/
20:09:52 <bwh> Someone should maybe take an action to find out what actually depends on this, then?
20:09:59 * ukleinek thinks we agree to deprecate iptables-legacy?
20:09:59 <waldi> i will do
20:10:04 <ukleinek> 👍
20:10:23 <waldi> i would propose we start the MBF, drop the legacy binaries ASAP and the kernel support after forky
20:10:51 <bwh> I think may depend on the scale of what needs fixing...
20:11:12 <ukleinek> ack, but declaring that as goal sounds right
20:11:14 <carnil> #action waldi tries to find out what still depends on iptables-legacy (not only as fallback), propose a plan for MBF and dropping legacy binaries ASAP (and kernel support after forky)
20:11:19 <carnil> ^^ waldi fine enough?
20:11:37 <waldi> yep
20:11:45 <carnil> thanks a lot for bringing it on the table
20:12:04 <carnil> next topic is proposed by santiago, not sure if he can join
20:12:13 <carnil> #topic Proposal about maintaining firmware-nonfree in old releases
20:12:16 <santiago> hi (I'm half here)
20:12:26 <santiago> thanks! I don't want to take too much of time of the meeting, so I'll try to be brief
20:12:32 <carnil> I pinged after our last meeting santiago and asked if he can post the proposal on the list.
20:12:39 <carnil> santiago: please go ahead :)
20:12:45 <santiago> security support for firmware-nonfree is difficult because of different reasons (documented in the email I sent): high risk of regressions, lack of information of updates, old kernels not able to load updated files, ...
20:12:53 <santiago> the idea is to introduce per-kernel firmware-nonfree packages, aiming to minimize regressions and to make sure uploaded firmware files can be loaded by target "target" kernel
20:13:00 <santiago> this of course introduces complexity, since it means maintaining an additional package, and not "simply" backporting from newer releases. but the latter is too challenging
20:13:12 <santiago> what does the kernel team think about this idea? does it make sense?
20:13:34 <santiago> and should the hypothetical firmware-nonfree-6.1 source package maintained under the  kernel team umbrella?
20:13:57 <ukleinek> Is it really only about firmware-nonfree?
20:14:08 <bwh> The issue I have with this is that there isn't such a simple relationship between firmware-nonfree and kernel versions
20:14:27 <carnil> santiago: when I first heard the idea I found it might be more complex than the src:linux-X.Y case, because the firmware files all live in /lib/firmware/ and owuld need breaks,replaces relations
20:14:33 <bwh> yes
20:14:48 <santiago> that's true
20:15:10 * ukleinek imagines that tracking the set of firmwares used for a given kernel is difficult, each stable update might result in changes
20:15:25 <bwh> However: just thinking out loud, what we could do is install everything under /lib/firmware/6.1 and then have each kernel package create a symlink from /lib/firmware/<release> to 6.1
20:15:39 <waldi> bwh: can we change the loading path?
20:16:13 * ukleinek removes the line he was about to type that would result in the third one with that thought
20:16:23 <bwh> the kernel already has logic for loading from /lib/firmware/<release> (and it looks there first) so we should just need to create those as symlinks
20:16:37 <waldi> okay
20:17:24 * ukleinek doesn't understand the need for symlinks
20:17:44 <waldi> ukleinek: because we don't want a firmware-nonfree-6.1.2-arm64
20:17:49 <bwh> exactly
20:18:23 <ukleinek> ah, and the firmware loader only checks /lib/firmware/6.1.2-arm64 and not /lib/firmware/6.1
20:18:31 <bwh> yes
20:19:27 <waldi> so it would be possible to create per-version firmware packages. but what would it contain?
20:19:41 <ukleinek> and would firmware-non-free-6.1 contain all firmwares, or only those that got an update since firmware-nonfree/stable?
20:20:36 <bwh> To be decided, but I think it would be simplest to include all the same things that are in firmware-nonfree/bookworm, just with the package name and installation path change
20:21:10 <waldi> and this would then be updated to latest upstream?
20:21:36 <ukleinek> "We will also avoid backporting new upstream versions"
20:21:58 <santiago> sorry people, I need to go now :( (really sorry for just bringing the topic, and without able to contribute further to the meeting)
20:22:14 <ukleinek> santiago: then next week?
20:22:27 <bwh> I can spend some of my LTS time to try this out
20:22:31 <carnil> I think that would not really help, the newest version might contain firmware files which the kernel will not load, right?
20:22:34 <carnil> bwh: ok!
20:23:09 <carnil> bwh: it would be great if you can do that, and then maybe summarize/give an overview in one of the next meetings once you found time to do so?
20:23:17 <santiago> ukleinek, by the time of the kernel team meetings, it's actually easier for me by email
20:23:19 <ukleinek> I think it solves a real problem, so we should consider doing it. My gut feeling would be to only ship updated files to keep the source small
20:23:24 <santiago> gtg now
20:23:25 <santiago> cheers!
20:23:41 <bwh> Longer term, it might be worth doing something like this for non-LTS to reduce the number of different blobs installed, but let's not discuss that now
20:24:39 <carnil> I think we have some ideas, and if bwh can have a look at this on LTS time, then we can now move to the second half of the meeting and go over the bugs (likely not all)
20:24:55 <ukleinek> bwh: I'd expect that if you try it, that you will get a stronger opinion on the actual implementation details
20:25:45 <carnil> do we move to bugs?
20:26:03 * ukleinek nods
20:26:07 <carnil> #topic #1119161: (C, ) sudden memory leak/full wipes out all disk partitions
20:26:54 <bwh> I don't think this is actionable
20:27:01 <carnil> this is a new report; very light on details (and severity might be exagerated). user reports that filesystem got corrupted
20:27:19 <carnil> but there is nothing really to act/look on
20:27:56 <bwh> It doesn't sound like we are going to be able to get any logs from them either
20:28:03 <ukleinek> ..ooOO(win10 is out of support :-)
20:29:05 <bwh> ukleinek: There is extended support in many places! And I'm fairly sure it doesn't self-destruct at end of support (any more often than usual)
20:29:34 * ukleinek is surprised that an OOM problem crashes windows
20:30:04 <carnil> so I think we can write back to the user that there is unfortunately no real actionable information we can help with, and we would close the bug (free to reopen if for instance could provide some previous kernel logs for debugging)
20:30:14 <bwh> OK
20:30:41 <carnil> #action carnil responds to #1119161 that we need more actionable information (logs) to help with and are going to close the bug for the time beeing
20:30:43 <ukleinek> Does a kernel log really help?
20:31:08 <bwh> I suspect not but I don't know what else could help us debug this
20:31:27 <carnil> #topic #1109268: (i, ) ath11k_pci may trigger prompt for nonexistent firmware file during installation
20:31:34 <ukleinek> I think the only thing that would help is getting the HD on one's desk
20:31:45 <iam_tj[m]> We'd need to see the partition table and what signatures each has BEFORE the user tried to recover it
20:31:57 <carnil> this was an action for ukleinek last time, as the hardware works suggested to downgrade to normal/minor
20:32:06 <carnil> ukleinek: still wanting to take care of it?
20:32:23 <bwh> I think I have an action to improve the messages
20:32:24 * ukleinek failed to work on his action items from last week and will catch up
20:32:53 <carnil> #action ukleinek takes care of #1109268 for further investigation (and adjusting bug severity)
20:33:04 <carnil> #topic #1112627: (i, u) linux-image-6.16.3+deb14-amd64: Intel audio no longer works: DMAR: [DMA Write NO_PASID] Request device [00:1b.0] ... non-zero reserved fields in PTE
20:33:41 <carnil> summary: intel_iommu=off helps, audio works in this case, but logs get spammed (this is my understanidng after rereading). Reporter will still try to do a BIOS update.
20:34:14 <carnil> I have no other ideas than suggesting to live with the intel_iommu=off and try after a BIOS update
20:34:32 <ukleinek> sounds reasonable
20:34:37 <carnil> (but this likely means we keep the bug open further?)
20:35:22 <waldi> we can close it. or can we do anything?
20:35:54 <ukleinek> 6.12 is good, is that because the iommu is off there?
20:37:42 <carnil> we have CONFIG_INTEL_IOMMU_DEFAULT_ON_INTGPU_OFF=y as well there already
20:38:15 <bwh> The custom-built 6.12 worked because it had the IOMMU off by default
20:38:32 <bwh> or... no, you are right
20:38:52 <carnil> that is right, but problem is that linux-image-6.12.38+deb13-amd64 was working well for the reporter
20:39:26 <bwh> so, there may be a firmware problem but the driver did avoid it previously
20:39:36 <bwh> Let's send this upstream then
20:40:03 <carnil> bwh: if you have an idea on what to report, would you like to take over the action on this bug?
20:40:04 <ukleinek> let the reporter complete the bisect first? With a consistent .config?
20:40:21 <bwh> #action bwh will forward #1114557 upstream
20:40:31 <bwh> sorry
20:40:47 <bwh> #action bwh will forward #1112627 upstream
20:40:51 <carnil> thank you
20:41:02 <carnil> #topic #1114557: (i, u+) linux-image-6.12.43+deb13-amd64: Jieli touchscreen and stylus no longer supported
20:41:25 <carnil> wait, nothing to do, 4th iteration of patches seem to finalizing. is candiate for stable series as well, so we will pick up the fix later
20:41:32 <ukleinek> no action item apart from keeping it on the radar
20:41:43 <carnil> right
20:41:46 <bwh> OK
20:41:48 <carnil> #topic #1114884: (i, ) linux-image-6.1.0-39-amd64: AMD Ryzen 9 7950X, linux-image-6.1.0-39-amd64 hangs on boot while 6.1.0-37-amd64 works fine
20:42:07 <carnil> this was taken by kathara, ukleinek did you approach her to see if she still wants to take care of it?
20:42:19 * ukleinek blushes
20:42:58 <carnil> oh sorry was not meant this way
20:43:18 <carnil> just asking if we need still to ping kathara. (or she is reading here)
20:43:25 <ukleinek> carnil: you took that wrong, the blame is on my side only
20:43:46 * ukleinek will care for it (discussing the bug with her)
20:44:16 <carnil> #action ukleinek discusses with kathara for #1114884 debugging/triaging
20:44:29 <carnil> #topic #1114912: (i, ) linux-image-amd64: KVM GPU passthrough causes kernel crash and system hang on Debian 13 after VM shutdown
20:44:45 <ukleinek> I think that is another bug that is on my list
20:44:55 <carnil> reporter provided the results for the requested tests. I think it make sense to keep an action here for ukleinek
20:45:03 * ukleinek nods
20:45:15 <carnil> #action ukleinek takes care of further debugging of #1114912
20:45:26 <carnil> #topic #1115581: (i, ) linux-image-6.16.3+deb14-rt-amd64: Boot hang with Creative Sound Blaster AE-7 [1102:0010]
20:45:59 <carnil> so far no reply from the contacts with a sound card with same pci ids. So wait for a reply?
20:46:14 <carnil> or do we have other ideas on what to try next?
20:46:21 <ukleinek> #action ukleinek blushes further, will go through #1115581 and maybe ping again
20:46:53 <carnil> topic #1118437: (i, u) linux-image-6.17.2-amd64: kernel crash in interrupt after receiving an ip packet on veth from xsk from user space
20:47:10 <carnil> there were some iterations of the patch sumission, it has not yet landed in mainline (checked today earlier)
20:47:13 <carnil> -> wait
20:47:21 * ukleinek nods
20:47:27 <carnil> #topic #1118465: (i, u) Regression: linux-image-5.10.0-36-arm64 fails to bring up LAN7800 USB NIC: "NO-CARRIER" and "state DOWN"
20:47:39 <carnil> sad news here, the patch did not work to fix the problem :-/
20:48:09 <bwh> Right, so I should probably add some more debugging
20:48:29 <bwh> I don't think bisection is needed as there was only one commit that changed the usbnet driver
20:49:12 <bwh> #action bwh will try to debug #1118465 properly instead of guessing
20:49:27 <ukleinek> bwh: you could ask for testing two kernel that just differ by that patch to confirm this is really the culprit, #bisect-light
20:49:36 <bwh> yes
20:49:48 <carnil> thank you bwh, Axel will be happy
20:50:01 <carnil> #topic #1118508: (i, M) linux-image-6.12.38+deb13-amd64: Frequent kernel panic during/just after boot on Lenovo P15v Gen1 with external USB hub in Samsung display
20:50:17 <carnil> still same situation: waiting for problem to trigger again and (hopefully) logs from that. No news yet -> action: wait
20:50:26 <carnil> #topic #1118762: (i, ) linux-image-6.16.12+deb14+1-amd64: external monitors disconnect every several seconds
20:50:29 <carnil> this is new
20:51:27 <carnil> I miss here a kernel log to see if there are warnings, errors, hints
20:51:44 <bwh> Right, we need kernel logs at the least
20:51:46 <ukleinek> + is "every several seconds" a constant amount of time?
20:52:20 * ukleinek doesn't know thunderbold, maybe there is some tracing that could be enabled?
20:53:08 <bwh> I think a fair amount of this stuff is firmware-controlled but probably some of it can be traced in the kernel
20:53:20 <carnil> #action carnil will ask Vincent in #1118762 for kernel (full) kernel logs up to when problem triggers; clarification on "disconnection" times
20:53:23 <bwh> and it is the kernel that regressed...
20:53:25 <carnil> what I additonal wonder is:
20:53:29 <carnil> Kernel 6.7.12 is still fine.
20:53:49 <carnil> is there a typo or did he meant really 6.7.12?
20:54:16 <ukleinek> carnil: why do you doubt?
20:54:22 <carnil> there is a relation to #1072063 which explains that
20:55:09 <bwh> so now both monitors are affected and they also only turn on for a few seconds
20:55:38 <ukleinek> so that might be the same issue that "only" shifted the symptoms
20:55:53 <carnil> so 6.7.12 -> 6.16.9 (only one monitor affected), after updating from 6.16.9 -> 6.16.12 both are affected
20:55:59 <bwh> Yes it's possible that they will get fixed together, but let's not assume that
20:56:19 <carnil> so will keep the above action and ask for complete logs first as a start
20:56:42 <ukleinek> Let them try 6.17.2?!
20:56:58 <carnil> ukleinek: right as well
20:57:30 <carnil> so it is almost 22:00, do you still have energy to go through the remaining bugs?
20:57:48 <waldi> not really
20:57:54 <bwh> We have 1 more important
20:58:20 * ukleinek still has to clean the kitchen, so +1 for not stretching the meeting's end
20:58:35 <carnil> let's do the last one then, and for the rest we have a couple of 'wait" and actions from the previous meeting, so they can remain IMHO assigned
20:58:45 <carnil> so last bug
20:58:58 <carnil> #topic #1119137: (i, ) linux-image-6.12.48+deb13-amd64: CPU stall when Debian Trixie runs as guest in VirtualBox environment
20:59:42 <bwh> Can we reassign this to VirtualBox?
21:00:05 <ukleinek> alternatively let them reproduce with kvm
21:00:37 <carnil> the reporter said: I will attempt to
21:00:38 <carnil> create a Trixie VM with QEmu and see whether that works.
21:00:57 <bwh> Well we know the kernel works fine in KVM
21:00:58 <carnil> so I would say we ping the reporte to ask if that has happened. if it is not reproducible then reassign it to virtualbox
21:01:18 <carnil> correct at least in all cases I ever encountered :)
21:01:31 <carnil> how is the VM sized? (if same or buster works?)
21:01:46 <carnil> bwh: so you would want to straight reassign?
21:02:47 <bwh> Since the reporter said they would also test in QEMU, I suppose it is reasonable to wait for that first
21:03:09 <waldi> yeah
21:03:22 <ukleinek> ack
21:03:23 <bwh> Oh, the kernel log has "[    0.000000] [Firmware Bug]: TSC doesn't count with P0 frequency!" right at the top, I wonder how important that is
21:03:47 <ukleinek> oh, and does that happen on the host kernel, too?
21:03:51 <waldi> it is quite
21:04:10 <waldi> without counter, all stale checking is unreliable
21:04:55 <bwh> carnil: The VM seems to be ~32 GiB RAM
21:04:58 <ukleinek> is that something that virtual box gets wrong, or is that a hardware issue?
21:05:06 <bwh> I think that would be VB
21:06:16 <ukleinek> so asking for a test with qemu sounds sensible, if that works, reassign to vbox
21:06:35 <bwh> We should probably reply to say we're waiting to hear how that went, yes
21:06:48 <ukleinek> maybe point out that message in the reply and specifically ask if that happens with qemu/kvm, too
21:06:57 <carnil> ok
21:06:58 <bwh> #action bwh will reply to #1119137 to ask about QEMU results, then likely reassign to virtualbox
21:07:21 <carnil> maybe it be worth reducing the amount ov vcpus as well for the vm to test
21:07:25 <carnil> thank you
21:07:33 <carnil> so let's switch to AOB
21:07:41 <carnil> #topic AOB
21:07:56 <bwh> Is there a plan to upload 6.17 to unstable?
21:07:57 <carnil> I guess the only sensible thing to discuss here is who takes care of the next meeting
21:08:07 <waldi> i assembled the list of source packages for iptables/ebtables/arptables legacy, it contains 23 names
21:08:08 <carnil> bwh: I was importing 6.17.6
21:08:18 <bwh> carnil: Grea
21:08:21 <carnil> and if waldi agrees we could upload that to unstable?
21:08:22 <bwh> +t
21:08:45 <waldi> carnil: sure. i can do that or you. and upload 6.18-rc3 or so to experimental
21:09:27 <carnil> bwh: waldi: let me finish the 6.17.6 import, I can do it but I was asking since you did all the work for 6.17 and might want to do the final switch
21:09:59 <waldi> i won't be available next week
21:10:11 <carnil> ok I take care of 6.17.6 -> unstable
21:10:31 <waldi> okay
21:10:32 <bwh> and I will chair next week
21:10:51 <carnil> #action bwh will chair next weeks meeting
21:11:09 <carnil> okay let's stop here, sorry it was more than we could handle this time
21:11:17 <carnil> #endmeeting