19:04:33 <bwh> #startmeeting
19:04:33 <MeetBot> Meeting started Wed Jun 25 19:04:33 2025 UTC.  The chair is bwh. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:04:33 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:04:41 <ukleinek> bwh: o/ welcome
19:04:53 <carnil> hi
19:05:46 <bwh> #topic #1088522: nouveau: Unable to boot with 3 monitors on Nvidia GPU
19:06:12 <ukleinek> iam_tj[m] handled that before
19:07:16 <bwh> Unless they are here now, I think someone else needs to take responsibility for following up this time
19:07:23 <carnil> the reply /followup was just from yesterday afaics so maybe we can wait?
19:07:31 <carnil> ok
19:08:35 * ukleinek can take the action to prod iam_tj[m] and take over if needed.
19:08:50 <bwh> Sounds good
19:09:21 <ukleinek> #action ukleinek asks iam_tj[m] if they continue to care for #1088522
19:09:38 <bwh> #topic #1100153: linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10
19:10:20 <bwh> I think the new information is not that useful to us so I propose to continue waiting for the originalreporter
19:10:55 <ukleinek> we could ask the newcomer to do the debugging we asked?
19:11:04 <ukleinek> for
19:12:04 <bwh> We could do. They will have different user-space but I guess that probably doesn't matter here
19:12:24 <ukleinek> #action ukleinek follows up on #1100153 to ask for testing
19:12:33 <carnil> but I'm confused the new reporter is not using Debian right?
19:12:35 <bwh> Thank you
19:12:44 <bwh> #topic #1103397: Kernel Panic: copy_fpstate_to_sigframe crashes
19:12:47 <carnil> and the original reporter claimed it might bee a Debian specific patch
19:13:07 <bwh> This is (I hope) now on its way to being fixed in stable
19:13:41 <ukleinek> carnil: I thought the thesis is that it broke between v6.10 and v6.11-rc4
19:15:22 <bwh> #topic
19:15:29 <bwh> #topic #1106668: Waking up from suspend to RAM reproducibly leads to a hard freeze
19:16:01 <bwh> I think we are still expecting more info here, so no need to take action?
19:16:08 <ukleinek> ack
19:16:29 <bwh> #topic #1107521: linux-image-6.12.27+bpo-amd64: ath12k_pci errors and eventual kernel panic starting with linux-image-6.12.27+bpo-amd64
19:17:27 <bwh> It looks like this is fixed in 6.15 but we need to identify the fix
19:17:29 <ukleinek> the guy needs some assistance, I'll do it as I communicated with the reporter before
19:17:34 <carnil> It might be helpful here now to bisect the changes in the nwer upstream versions to identify the fixing commit and ask it to be backported to 6.12.y?
19:18:07 <ukleinek> #action ukleinek to give some assistance to bisect/report upstream for #1107521
19:18:39 <bwh> #topic #1108082: linux-image-6.12.32-amd64: Crash
19:19:09 <bwh> The system is apparently locking up and we have logs but they don't show an oops or lockup
19:19:18 <ukleinek> while looking before the meeting I had the impression there are quite a few logs, but none with the hint about the reason
19:19:27 * ukleinek nods
19:19:33 <bwh> So I think someone will need to walk the reporter through setting up netconsole
19:19:46 <ukleinek> sysrq?
19:20:20 <bwh> The problem seems to be triggered in a graphical session
19:20:44 <ukleinek> it might already be a hint if the reboot sysrq works
19:21:25 <ukleinek> and sysrq-t might make it into the logs
19:21:30 <bwh> That would be a hint but doesn't seem like it owuld be that useful
19:22:12 <ukleinek> yes, it doesn't help to pinpoint the problem, that's true
19:22:24 <carnil> I had some previous interactions with other reporters asking to set up a netconsole, in the hope we might get some more information on the crashes I can guide the reporter to set something up and then we hopefully have more information on next meeting.
19:22:49 <ukleinek> so agree, netconsole (or serial?) might help
19:22:50 <bwh> carnil: That would be very helpful
19:23:27 <carnil> ack, you can assign then that to me
19:23:31 <ukleinek> hmm, "normal" people probably don't have the hardware to work with serial
19:23:33 <bwh> Do you have template emails for this? I feel like we should have some shared templates for different diagnostics we can ask people to do
19:23:56 <bwh> ukleinek: Yeah serial is unlikely on a desktop
19:24:28 <bwh> #action carnil will ask reporter of #1108082 to capture kernel messages with netconsole
19:24:30 <carnil> I have not but let me try to do the next answer in a form which we can try to have as template. I like your idea.
19:25:20 <ukleinek> +1 for templates
19:26:18 <bwh> OK, let's create a directory in kernel-team and put some text files there that can be pasted into mails
19:26:38 <ukleinek> ack
19:26:45 <carnil> ack, let's try that out
19:26:54 <ukleinek> (or even just linked to)
19:28:09 <bwh> #agreed Create directory in kernel-team for template texts for asking bug reporters to do some diagnostic/debugging task
19:28:22 <bwh> #topic #1108168: linux-image-6.12.32-amd64: black screen, then crash in nouveau when rebooting
19:29:29 <carnil> I see there are two problems here, one was the black screen which apparently was a broken hardware, the other seems to be a longstanding issue of nouveau crash when rebooting. Correct?
19:30:05 <bwh> I think you are probably right
19:30:18 <bwh> It's a WARNING rather than BUG from nouveau, but still shouldn't happen
19:31:17 <bwh> The WARNING could be reported upstream
19:32:05 <ukleinek> that's pm_runtime_get_sync() failing
19:32:48 <ukleinek> +1 for reporting it upstream
19:33:14 <bwh> Shall I request that then?
19:33:33 <ukleinek> request = ask reporter to forward?
19:34:00 <bwh> Yes because it will be on fd.o bug tracking
19:34:11 * ukleinek nods
19:34:32 <bwh> #action bwh will ask reporter of #1108168 to report nouveau WARNINGs upstream
19:34:39 <ukleinek> thx
19:34:46 <bwh> #topic #1107142: linux-image-6.12.27-amd64: mpt3sas LSI SAS2008 [1000:0072] probe failure - BAR 1 reservation error
19:36:17 <ukleinek> is that workaround a reason to report upstream or to not report upstream?
19:36:27 <bwh> I think it's a reason to report upstream
19:37:46 <bwh> I don't really understand what's going wrong but this ought to work by default
19:37:48 * ukleinek has no clue about pci
19:37:59 <bwh> I used to but it's been a while
19:38:23 <ukleinek> #action ukleinek involves upstream on #1107142
19:38:46 <bwh> #topic #1107511: linux-image-6.1.0-37-amd64: Resume from supsend-to-disk fails
19:38:50 <carnil> okay I was going to propose to take an action but I appear to be slow I will take something else down the list :)
19:39:12 <ukleinek> carnil: you could fix the typo in the bug title :-)
19:39:24 <carnil> this is pending for the next upload to bookworm (either bookworm-pu or bookworm-security)
19:39:31 <bwh> right
19:39:52 <bwh> #topic #1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
19:39:59 <ukleinek> I was really surprised to learn that the bts doesn't know about versions in security (and -pu)
19:40:32 <bwh> Doesn't it?
19:40:44 <ukleinek> carnil: is the explicit "found 6.1.140-1" helpful?
19:40:53 <carnil> that is a very longstanding issue, no BTS cannot handle the versions
19:40:58 <bwh> OK
19:41:09 <carnil> ukleinek: I think so because we confirmed it is present as well in 6.1.140-1, at least it does not harm :)
19:41:28 <bwh> So for the DVD-RAM issue, ukleinek seems to have identified a deadlock that has been there for a long time
19:41:44 <carnil> bwh: #433335, #544726
19:42:02 <carnil> (but sorry we are mixing up things now, let's keep on topic)
19:42:17 <ukleinek> bwh: ack, and upstream didn't care yet. That driver was already removed once due to bit-rotting but restored later on user request
19:42:59 <bwh> Is this pktcdvd (or something like that)?
19:43:39 <bwh> That does look basically unmaintained
19:44:00 <ukleinek> yes, that's pktcdvd
19:44:22 <carnil> PKTCDVD DRIVER status: Orphan
19:44:27 <bwh> Maybe we should stop building it then?
19:45:08 <ukleinek> does this help the user? blkid won't block any more, but does this make DVD-RAMs unusable then?
19:46:16 <ukleinek> This is a module, the reporter could test blacklisting that
19:46:24 <bwh> I think you can stil read DVD-RAM with sr
19:46:34 <bwh> but I'm not totally sure
19:47:33 <carnil> at least the sr module has
19:47:35 <carnil> Modified by Jens Axboe <axboe@suse.de> - support DVD-RAM
19:47:47 <ukleinek> #action ukleinek explains that this driver is orphaned upstream and asks to test with the module blacklisted
19:47:59 <ukleinek> #action ukleinek explains that this driver is orphaned upstream and asks to test with the module blacklisted (bug #1107479)
19:48:10 <bwh> Thanks
19:48:15 <carnil> disabling the module in debian/latest might be a good thing and so we have it out for forky
19:48:21 <bwh> right
19:48:46 <bwh> #action bwh will open MR to disable orphaned pktcdvd driver
19:48:47 <carnil> I will propose a MR for that, given it has as well a comment that it will be dropped "in the near future" whatever that means :)
19:48:52 <carnil> ok
19:49:01 <ukleinek> I assume it will hang for everyone, so maybe also disable for trixie?
19:49:43 <bwh> If it's unusable then yes let's backport to trixie and even bookworm. But we can discuss that on the MR
19:49:43 <ukleinek> we can discuss this next week when we hopefully have input from the reporter
19:49:57 <bwh> #topic #1107579: linux-image-6.1.0-37-amd64 hangs on resume from hibernate
19:50:38 <bwh> ukleinek: You handled this before, so can you reply to clear up the confusion about versions?
19:51:18 <ukleinek> #action ukleinek tries to unconfuse the reporter of #1107579
19:51:36 <bwh> Thanks
19:51:57 <bwh> #topic #1108069: linux-image-6.12.32-amd64: Builtin recognized microphone Asus X507UA does not record
19:52:10 <carnil> I prepared a tenative patch before the meeting adding a quirk, https://lore.kernel.org/linux-sound/aFxETAn3YKNZqpXL@eldamar.lan/T/#u
19:52:19 <bwh> nice
19:52:45 <bwh> So this should be tagged moreinfo now?
19:52:50 <carnil> ah yes
19:53:09 <bwh> tagged
19:53:15 <ukleinek> maybe with a description for the reporter what we expect?
19:53:58 <carnil> ukleinek: I did ask the reporter if he can test the patch, was assuming he knows how to, as did test in the report as well selfcompiled kernels inbetween
19:54:07 <bwh> That makes sense
19:54:15 <bwh> #topic #1100105: linux-image-amd64: Issues with Framework audio module
19:54:16 <ukleinek> carnil: great, I didn't say anything
19:54:51 <ukleinek> again my part to follow up
19:55:14 <ukleinek> #action ukleinek follows up on #1100105 with further debug directions
19:55:15 <bwh> OK
19:55:27 <bwh> #topic #1108037: linux-perf: perf report --demangle only works on some(?) symbols
19:56:13 <bwh> Should I take this one as I've mostly taken care of perf?
19:56:22 <carnil> would be great if you have time
19:56:38 <bwh> #action bwh will investigate and follow up #1108037
19:56:48 <bwh> #topic #1108294: kernel 6.12 breaks cgroup awareness of openjdk 21
19:57:30 <bwh> It looks like we need to make some config changes to keep cgroupfs compatible with OpenJDK
19:57:43 <ukleinek> sounds unfortunate but sensible
19:57:46 <carnil> I'm not sure here the regression is serious enough vs. enabling upstream legacy cgroup v1 support
19:58:31 <bwh> I saw the _V1 in the config symbols but I didn't look into how tied they are to the full v1 API
19:58:46 <carnil> the change upstream was around 6.11-rc1 if I researched it correctly and we get only now one report about that.
19:58:56 <bwh> According to the bug report OpenJDK will just crash in a container because it doesn't know what its memory limit is
19:59:05 <bwh> and won't try to GC before hitting it
19:59:15 <carnil> e93d4166b40a ("mm: memcg: put cgroup v1-specific code under a config option")
20:00:00 <ukleinek> was it deprecated in deb12 already?
20:00:43 <bwh> I feel like v1 has been deprecated for quite a long time
20:00:59 <carnil> the above commit was in 6.11-rc1, so no in bookworm we have CONFIG_MEMCG=y
20:01:25 <carnil> but v1 was already I think not in use by systemd right back then
20:01:26 <ukleinek> if we reenable cgroupsv1, it would be great if using it would result in a printk once per boot to make people aware
20:01:59 <ukleinek> (maybe)
20:02:23 <bwh> But then we should also patch Debian's OpenJDK to not provoke that warning...
20:02:43 <ukleinek> by making it use cgroups v2?
20:02:47 <ukleinek> :-)
20:03:07 <ukleinek> IMHO it's ok if OpenJDK triggers the warning
20:03:09 <bwh> Yes, if I understand correctly the latest OpenJDK does not need that
20:03:43 <ukleinek> "openjdk 25 has been fixed, AFAICT."
20:04:31 <bwh> 22 has the file src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
20:05:33 <ukleinek> trixie has both openjdk-21-jre and openjdk-25-jre. Isn't it a matter of just upgrade to 25 then?
20:05:39 <bwh> Let me take an action to investigate the options here and try talking to the OpenJDK maintainers
20:05:58 <ukleinek> good idea to involve the openjdk maintainers
20:06:01 <bwh> ukleinek: Sadly Write Once Run Anywhere did not mean backward compatibility
20:06:36 <bwh> #action bwh will investigate options for fixing #1108294 in Linux config and/or OpenJDK backports
20:06:52 <carnil> jmm_: ^^ this might be of interst as well for you (having dealt with all the openjdk DSAs)
20:06:54 <ukleinek> ok, I don't know, "just" might be wrong here
20:07:32 <bwh> We have something like 10 different versions in unstable; not sure how many in trixie
20:07:47 <bwh> #topic #1108250: firmware-intel-graphics: i915 timeout errors after firmware upgrade
20:08:08 <carnil> some versions are only in unstable to bootstrap the next version, the release notes should have updated information which one is the supported version
20:08:17 <carnil> (supported = getting as well security updates)
20:08:19 <bwh> carnil: Aha
20:09:17 <ukleinek> huh, firmware upgrade breaks i915. I wouldn't be surprised if upstream is already aware of that.
20:09:28 <bwh> I should reply to this and say yes we need that information. Unless someone else wants to
20:10:21 <bwh> #action bwh will reply to #1108250
20:10:30 <bwh> #topic #1108204: initramfs-tools: update-initramfs trigger does not update the initramfs in some cases
20:11:06 * ukleinek didn't find anything related on lore.k.o
20:11:06 <bwh> I believe I understand this but will give Benjamin Drung a chance to reply before going ahead with a revert
20:12:19 <bwh> #topic Migration excuses
20:13:07 <bwh> I lost track of whether there was an unblock request for 6.12.33-1
20:13:17 <carnil> I have a question here to you bwh, are you fine with your ABI name rules to configuration changes as they landed? We got not issues related to that Ithink (or did I miss something)? If you are ok then I would like to ask release team to have 6.12.33-1 migrated
20:13:48 <bwh> I meant to check whether test-patches correctly handles that suffix
20:13:53 <bwh> and I have not yet done so
20:14:12 <ukleinek> there is 6.12.34 upstream
20:14:40 <bwh> #action bwh will test that debian/bin/test-patches correctly handles kernel version strings with +debNN
20:15:10 <bwh> #topic New upstream versions
20:15:13 <carnil> ukleinek: I know (cf. https://salsa.debian.org/kernel-team/linux/-/merge_requests/1557) but we want 6.12.33-1 first in testing, and then ask release team when we should stop with aimed uploads. I would still like to have 6.12.35-1 in if that is possible.
20:16:03 <carnil> (and both 6.12.34 + 6.12.35 upcoming will be rather big, beeing after the merge window closing)
20:16:18 <bwh> right
20:16:53 <bwh> ethtool has a new upstream version, which could go to experimental
20:16:55 <carnil> so if release team and d-i folks say "stop" we stop and postone it to trixie-pu or trixie-security
20:17:07 <bwh> right
20:17:09 <ukleinek> looking at https://salsa.debian.org/kernel-team/linux/-/merge_requests/?sort=created_date&state=merged&label_name%5B%5D=Backport%206.12&not%5Blabel_name%5D%5B%5D=Backport%206.12%20done&first_page_size=20 there are three MRs we might want to get into trixie, too
20:17:23 <carnil> bwh: ethtool I could handle the experimental upload if you are ok
20:17:41 <bwh> Yes of course
20:18:33 <bwh> Does anyone have time to work on 6.16?
20:18:57 * carnil not, still focusing more on the stable series
20:19:20 * ukleinek has a full list and doesn't know what is needed. "Just" update and sort out the config changes?
20:19:40 <bwh> Right - config update, rebase/drop patches
20:20:01 <bwh> It sounds like we all have plenty of higher-priority work to do though
20:20:08 <ukleinek> ok, might be fun. I'll add that to the bottom of my todo list
20:20:27 <bwh> #topic Merge requests
20:21:10 <bwh> Does anyone have an MR they particularly want to discuss?
20:21:44 <carnil> #action carnil updates ethtool 6.15 (new upstream version) for experimental
20:22:11 <bwh> I'll take that as a no, because this meeting has gone on too long already
20:22:13 <bwh> # AOB
20:22:19 <carnil> bwh: none in particular
20:22:28 <ukleinek> ema explained about #1554, I didn't try to understand it yet, but I always have the impression these trusted cloud things are only window dressing
20:23:37 <bwh> Who will chair next week?
20:24:28 <carnil> since waldi is not around right now to ask, I think technically it would be my turn. But we have an event in kindergarden in the eveing, it should not last that long, but means I have not bit of time for preparation in short adavance before the meeting
20:24:44 <carnil> if you are fine with that then I can chair it, otherwise I prefer if someone else can take it
20:24:55 <ukleinek> the pattern seems to be that it's me every other week
20:25:22 * ukleinek does it
20:25:32 <bwh> Thnak you!
20:25:38 <carnil> thanks ukleinek
20:25:52 <bwh> And thanks all for bearing with a rather long list of bugs
20:25:55 <bwh> #endmeeting