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