19:00:47 <bwh> #startmeeting
19:00:47 <MeetBot> Meeting started Wed Apr 30 19:00:47 2025 UTC.  The chair is bwh. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:47 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:16 <bwh> If anyone else besides ukleinek is attending, please speak up
19:03:09 <bwh> OK, let's go to the first topic
19:03:16 * ukleinek nods
19:03:19 <bwh> #topic Bug #1086638: (i, ) linux-image-6.11.5: usbguard-daemon invalid opcode: 0000, usb's not usable
19:04:04 <bwh> I think we need to ask to re-test on the latest kernel in unstable, and then (if not fixed) forward upstream
19:04:06 <ukleinek> When reading the report I wondered how relevant usbguard is. Is it worth to ask for a test to reproduce without usbguard
19:04:25 <bwh> I think there was a test without usbguard
19:05:06 <ukleinek> ok, then ack, we ask for a test with a recent kernel and depending on the outcome close or forward upstream.
19:05:21 <bwh> In message #34 I think tests #1-6 were done without the usbguard rules
19:05:53 <ukleinek> at least all the rules were removed
19:05:53 <bwh> #action bwh will request re-testing #1086638 with a newer kernel version, then forward upstream
19:06:02 <ukleinek> 👍
19:06:06 <bwh> #topic Bug #1092103: (i, ) Linux 6.12 freeze on small machine
19:06:08 <carnil> hi
19:06:15 <bwh> Hi carnil!
19:06:23 <carnil> sorry for beeing late
19:06:37 <bwh> No problem, you did say not to expect you
19:07:30 <ukleinek> that bug should indeed be easy to reproduce
19:07:54 <bwh> It sounds like it. Are you willing to try that?
19:08:02 <carnil> I could try to do that tomorrow morning
19:08:08 <carnil> okay ukleinek is fine too
19:08:15 * ukleinek could look into it though I don't know much about x86, so I wouldn't mind if someone else looks
19:08:55 <ukleinek> #action ukleinek tries to reproduce #1092103
19:09:08 <bwh> carnil: Please do not work on May 1st
19:09:34 <bwh> #topic Bug #1100153: (i, M) linux: hangs on resume from suspend or hibernation with 6.12-6.13 on ThinkPad X1 Carbon Gen 10
19:09:38 <ukleinek> ok, that is my chance to be quicker, will do it tomorrow! :-)
19:09:41 <carnil> I'm in hamburg :) I'm expected to do some work ;-)
19:10:02 <bwh> Nothing new on this one since yesterday
19:10:15 <ukleinek> yes, tagged moreinfo, next!
19:10:28 <bwh> #topic Bug #1101944: (i, ) linux-image-6.1.0-32-amd64: list_del corruption ... kernel BUG at lib/list_debug.c:62!
19:10:41 <ukleinek> upstream's response wasn't very informative
19:11:16 <bwh> For the first point, the "[cut here]" is misplaced and we actually also want the line before it
19:11:29 * ukleinek also wondered why we didn't have the error message in the log. But apart from that I'm as clueless as before upstream's response
19:12:32 <ukleinek> We could ask the reporter if they can still find the message in their journal
19:12:45 <bwh> I think we can use decode_stacktrace.sh with vmlinux from the debuginfo package, to get line numbers
19:13:02 <bwh> ukleinek: yes
19:13:24 <ukleinek> Matthew Wilcox already decoded the line number?!
19:13:45 <bwh> Not for the backtrace
19:14:24 <bwh> OK, who will take this one?
19:14:26 <ukleinek> #action ukleinek to check backtrace for details (decode-stacktrace) and ask reporter for more kernel log from before the cut line
19:14:31 <bwh> thanks
19:14:47 <bwh> #topic Bug #1102175: (i, ) Repeated lockups in AMDGPU DRM driver
19:15:47 <bwh> It seems like there is a cascade of failures and it's not that clear what is the trigger
19:16:51 <bwh> The PCI device that gets stuck in D3 cold might be part of a USB 4 / Thunderbolt bridge, which would also interact with the amdgpu driver
19:17:15 <bwh> or rather, it would interact with the GPU, and indirectly with the amdgpu driver
19:17:58 <bwh> I'm not sure what we can ask next, or where to forward it
19:18:29 <ukleinek> there are some drm debug messages that can be enabled, but no clue if that would help
19:20:03 <ukleinek> Forward to the dri-devel@l.f.o or amd-gfx@l.f.o?
19:20:56 <ukleinek> If there is a setting that can prevent the card going into D3cold, that could be suggested as a workaround to the reporter
19:21:33 <bwh> The thing is, D3cold means the card has been fully powered off
19:22:14 <bwh> which I would only expect to happen in S3 or deeper system power state
19:22:57 <bwh> A regular driver can put it in D3hot but not D3cold
19:23:22 <ukleinek> could be that the machine goes into S3 when idle. Without knowing about what S3 is, at least gnome puts the machine to sleep after a while.
19:23:30 <bwh> yes
19:24:10 * ukleinek idles in #dri-devel, I can ask there if someone has an idea
19:24:27 <bwh> Are you OK to take this bug then?
19:24:40 * ukleinek looks at his list and nods
19:25:37 <bwh> #action ukleinek will try to make progress on #1102175
19:25:48 <bwh> #topic Bug #1103397: (i, u) linux-image-amd64: Kernel Panic: copy_fpstate_to_sigfrane crashes.
19:26:26 <ukleinek> Let's wait a bit more on upstream
19:26:33 <bwh> OK
19:26:51 <bwh> #topic Bug #1104269: (i, uM) linux-image-6.12.22-amd64: amdgpu flip_done and commit wait timeouts during normal use - causes session lockup
19:27:11 <bwh> No new information since yesterday
19:27:22 <bwh> #topic Bug #991712: (i, U) Intel wifi card "Killer Wi-Fi 6 AX1650 (2x2)" in new Dell XPS 15 doesn't work on bullseye's instaleld kernel
19:27:38 <bwh> Ah, carnil closed it
19:27:47 * ukleinek was about to write that
19:27:58 <bwh> #topic Bug #1104165: (i, u) linux-image-6.12.22-amd64: Freezing with 'amdgpu_dm_plane_helper_prepare_fb bind failed' some time after returning from suspend
19:29:09 <ukleinek> what is guake? Something challenging for the hardware?
19:29:22 <bwh> It looks there's GPU memory leak triggered by some change after resume
19:29:41 <bwh> Quake-style console
19:29:44 <ukleinek> Maybe in the error path of the failed bind
19:30:18 <bwh> right
19:30:30 <bwh> I think this one can be forwarded upstream
19:30:48 <bwh> #action bwh will forward #1104165 upstream
19:31:01 <bwh> #topic Bug #1104327: (i, u) firmware-amd-graphics: after laptop resume, AMD graphics jsut show large patterns on all terminals
19:31:16 <bwh> (It's a driver bug, not a firmware bug)
19:31:41 * ukleinek sometimes wonders if that are just different symptoms of similar problems. amdgpu is quite present in your bug list.
19:32:02 <bwh> It's possible
19:32:33 <ukleinek> s/your/our/
19:33:00 <bwh> I think for this one we need to ask for a kernel log and device info (lspci)
19:33:12 <ukleinek> and reassign to linux
19:33:18 <bwh> I already did that
19:33:24 <ukleinek> ah indeed
19:33:46 <bwh> So who will ask?
19:34:04 <ukleinek> I can add that to my question in #dri-devel
19:34:34 <bwh> Well it probably needs more info from the reporter first, doesn't it?
19:35:45 <ukleinek> not necessarily
19:35:51 <bwh> OK
19:36:24 * ukleinek already asked in #dri-devel
19:36:49 <bwh> #action ukleinek will try to progress #1104327
19:37:01 <bwh> #topic Bug #1035878: (n, +u) rpi400: visual speckling on 'faulty' HDMI port during mouse movement
19:37:41 <bwh> This has a patch from the RPi kernel but it's not upstream
19:37:55 <bwh> So someone will need to help get it applied upstream
19:38:28 <bwh> #action bwh will forward #1035878 and its patch upstream
19:38:36 <ukleinek> bwh: thanks
19:38:50 <bwh> #topic Bug #1100105: (n, M) linux-image-amd64: Issues with Framework audio module
19:39:17 <bwh> We are waiting on the reporter to confirm whether this was faulty hardwae or still reporducible with a replacement
19:39:26 * ukleinek nods
19:39:35 <bwh> #topic Bug #1103277: (n, Mu) linux: CVE-2024-38541 for 6.1 branch
19:40:02 <ukleinek> that patch was taken by the stable team, included in the review round currently.
19:40:05 <bwh> OK
19:40:06 <carnil> the patch was queued and now in the 6.1.136 review
19:40:26 <carnil> which means we have it in the next update
19:40:27 <bwh> Then I guess the moreinfo and wontfix tags are no longer correct?
19:40:29 * ukleinek expects this to resolve itself and carnil already said he will care for the bug colser
19:40:54 <carnil> yes the moreinfo and wontfix can be removed again I think
19:41:11 * ukleinek runs bts tag 1103277 - moreinfo wontfix
19:41:16 <bwh> me too
19:41:18 <carnil> (as side note, I still do think the security scanners are wrong in assessing it as critical issue ;-))
19:41:36 <bwh> #topic Bug #1103830: (n, ) linux-image-6.12.22-amd64: No keyboard or touchpad functionality on a Macbook Pro 14,1
19:41:59 <ukleinek> carnil: blindly believing automatic security scanners is always wrong
19:42:44 <bwh> > [  538.721827] dmar_fault: 73361 callbacks suppressed
19:42:48 <bwh> eek
19:43:25 <bwh> Anyway, this is confirmed to be a regression since bookworm
19:44:05 <ukleinek> so we ask for a bisection, to at least identify the first broken debian package?
19:44:18 <bwh> Yes that might be worth doing
19:44:32 * ukleinek already handled the bug before, will ask that.
19:44:49 <bwh> The changes in applespi since 6.1 are very small...
19:45:35 <bwh> right, pretty sure the problem is somewhere else, maybe to do with the IOMMU
19:45:36 <ukleinek> #action ukleinek to follow up on #1103830
19:46:04 <bwh> It might be worth asking to test with the IOMMU disabled (something like intel_iommu=off)
19:46:28 <bwh> #topic Bug #1104080: (n, ) linux: Please build with CONFIG_KERNEL_GZIP=y instead of CONFIG_KERNEL_XZ=y on sh4
19:47:36 <bwh> cbmuser: Is xz causing out-of-memory, or is there some other problem with it?
19:48:29 <ukleinek> tag + moreinfo?
19:48:46 <bwh> #action bwh will ask for clarfication on #1104080
19:48:58 * ukleinek nods
19:49:00 <bwh> #topic Bug #946791: (n, M) Please enable CONFIG_IOSCHED_BFQ=y
19:50:10 <ukleinek> continue waiting
19:50:14 <bwh> right
19:50:24 <bwh> #topic Bug #1100895: (n, ) nouveau probe of GeForce 840M crashes since 6.1.119-1
19:50:55 <bwh> There's more information here, and I updated the title to summarise that
19:51:32 <bwh> So I think this can be forwarded upstream?
19:52:09 <ukleinek> right
19:52:45 <bwh> #action bwh will forward #1100895 upstream
19:52:57 <bwh> #topic Bug #1102563: (n, M) usbhid error -71
19:53:12 <bwh> Still waiting for the full kernel log
19:53:16 * ukleinek nods
19:53:34 <bwh> #topic Bug #1067006: (n, uR) rpc-statd.service: State 'stop-sigterm' timed out. Killing.
19:53:43 <bwh> (skipping the < normal severity bugs in linux)
19:54:20 <bwh> This still seems to be waiting for a response from upstream
19:55:09 <bwh> I think that's all the bugs we need to discuss
19:55:33 <carnil> The forwarding to upstream is quite fresh, so let's wait to hear an answer from them, we have not modified the systemd units IIRC so it's upstream dependencies so would be good to hear from linux-nfs upstream on the issue
19:55:43 <bwh> right
19:56:08 <bwh> #topic Migration excuses
19:56:46 <bwh> I think we're just waiting for package builds and the 10 day timer
19:57:02 <ukleinek> looks like it, yes
19:57:24 <bwh> #topic New upstream versions
19:57:57 <bwh> It would be nice if someone could work on linux 6.15, but I don't think it's that high a priority
19:58:36 * ukleinek wants to have 6.15 on his NAS, but given my long list I won't promise anything
19:58:42 <bwh> OK
19:58:53 <bwh> #topic Merge requests
19:59:04 <bwh> Did anyone want to discuss any of these?
19:59:49 <bwh> I need ot re-review MRs for initramfs-tools and kernel-handbook
19:59:56 <ukleinek> I will look through the arm specific ones when I'm done with my buglist
20:00:30 <bwh> OK
20:00:37 <bwh> #topic Any other business
20:00:38 <ukleinek> ah, and I intended to look into the CONFIG_HZ_1000 one, but don't remember the details and didn't come around to do that
20:01:42 * ukleinek can chair next time again, knowing that carnil doesn't like chairing the jitsi meetings.
20:02:06 <carnil> as mentioned above I have a bit of free time in the next 3 days so I will likely look at some other bugs to take action on and still aim to look at the important and normal severity bugs to see what can be closed
20:02:22 <ukleinek> carnil: sounds good
20:02:23 <carnil> I can take the chair next week as it would be my turn
20:02:32 <carnil> I just mentioned it would be nice to not have to do always the jitsi one :)
20:03:00 <ukleinek> we just need a 5th guy in the team, then ...
20:03:25 <bwh> Doesn't have to be a guy
20:03:39 <bwh> though, looking at the current team... :-/
20:03:47 * ukleinek didn't want to imply a gender with "guy"
20:04:26 <bwh> So, who will it be next week?
20:05:04 <ukleinek> carnil: Schere!
20:05:11 <carnil> Stein
20:05:15 <carnil> I will do it ;-)
20:05:29 <bwh> #agreed carnil will chair next week
20:05:31 <bwh> #endmeeting