19:00:46 <bwh> #startmeeting
19:00:46 <MeetBot> Meeting started Wed Jul 22 19:00:46 2026 UTC.  The chair is bwh. Information about MeetBot at https://wiki.debian.org/MeetBot.
19:00:46 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:57 <waldi> hi
19:00:58 <yunseong[m]> Hello everyone!
19:01:48 <bwh> carnil did not expect to be able to attend (at least at the start)
19:01:57 <bwh> Did ukleinek say whether he would be absent?
19:02:43 <waldi> i can't remember
19:02:55 <bwh> Any urgent issues before we start on the bug list?
19:03:10 <waldi> nope
19:03:28 <bwh> #topic Bug #1142158: (C, ) linux-image-7.0.13+deb13-amd64: This appears similar to #1104269 but affects a Radeon RX 9060 XT […]
19:03:58 <bwh> I will downgrade the severity to important
19:04:44 <bwh> Someone should ask whether this is a regression from an earlier kernel version, and also whether 7.1 fixes it (though that is not yet in backports)
19:05:13 <bwh> Does anyone volunteer to do that?
19:05:34 <yunseong[m]> I can do it!
19:05:52 <bwh> #action yunseong[m] will respond to #1142158
19:05:53 <bwh> thanks!
19:06:02 <bwh> #topic Bug #1126671: (S, ) linux-image-6.17.13+deb13-amd64: Disconnect root (path=/) during heavy load on NvME, partial corruption on NTFS.crash soon but not yet
19:06:22 <bwh> I did not have as much spare time as I thought in the last week, so my draft response to this is still not sent
19:06:37 <bwh> I'm happy to keep the action though
19:06:45 <bwh> #topic Bug #1142571: (S, ) linux-modules-7.1.4+deb14-loong64: Unable to boot due to unloadable modules (merged with #1142426)
19:07:33 <bwh> This is caused by a change in binutils and I think I saw that there is a fix available in binutils upstream. So unless there is a workaround possible I think we can leave it with the binutils maintainers
19:08:08 <waldi> yeah
19:08:28 <bwh> #topic Bug #1138755: (i, Uu) Subject: amdgpu: RX 640 hangs right after VCE initialization on kernel 6.12 (i5-11400F, no iGPU) (forwarded: gitlab.freedesktop.org)
19:09:28 <bwh> This has a fix upstream but it is not even in Linus's tree yet (so far as I can see). So I think we should wait for that
19:09:51 <waldi> okay
19:10:01 <bwh> #topic Bug #1139599: (i, u) linux-base-7.0.10+deb14-amd64: amdgpu (ttm?) two Oops, locking the computer (forwarded: amd-gfx)
19:10:23 <bwh> Reporter asked an LLM about it, and I think we can ignore that
19:11:40 <bwh> #topic Bug #1141183: (i, u) src:linux: I/O errors on SATA devices related to IOMMU (forwarded: bugzilla.kernel.org)
19:12:35 <waldi> nothing new. sounds like we can wait a bit longer
19:12:52 <bwh> There is something new since the last meeting. And I didn't notice this was forwarded
19:13:44 <bwh> Ah, last comment upstream from Tj is that there is a system firmware bug
19:14:25 <bwh> unless they mean that that's a separate bug - I'm not sure I'm reading the comment correctly
19:15:05 <bwh> iam_tj[m]: Could you say whether you think #1141183 is still a kernel bug?
19:15:51 <bwh> #topic Bug #1141719: (i, M) linux-image-7.0.13+deb14-amd64: shutdown hang on dell pro max 16 laptop (i915)
19:17:08 <bwh> I'll remove the moreinfo tag from this, as the information has been provided
19:17:26 <bwh> Can anyone respond to this?
19:17:34 <waldi> falcon-sensor, which is known to break systems if they don't run in lockdown mode. or did they fix that?
19:18:20 <bwh> Interesting...
19:18:35 <bwh> probably doesn't break i915 though
19:18:53 <waldi> if they still use the kernel module part, they hook syscalls
19:18:58 <bwh> yes
19:19:00 <waldi> (and patch away the taint flag)
19:19:21 <bwh> They do *what*?!
19:20:13 <bwh> Seems to be BPF in this case. But in the past OOT modules have been blocked by name for doing shit like that
19:20:41 <waldi> thats why the names where random generated and forcr loaded with symbol versions
19:20:55 <waldi> i would assume this one uses BPF, yes
19:21:12 <waldi> s/with/without/
19:21:15 <bwh> The two kinds of malware authors: malware authors and anti-malware vendors
19:21:20 <waldi> yes
19:21:40 <bwh> anyway...
19:21:53 <bwh> #action bwh will try to respond to #1141719
19:22:17 <waldi> i have no idea about that one. needs upstream`
19:22:19 <waldi> ?
19:22:27 <bwh> #topic #1141813: (i, u) nouveau: reproducible NULL pointer dereference in nouveau_fence_sync() when closing a GPU-composited client window (observed with Evince)
19:23:44 <waldi> Assisted-by: Claude:claude-5-sonnet (high)
19:23:50 <bwh> indeed
19:24:11 <bwh> I assume the crash in nouveau_fence_sync() running evince is real, and the rest may be garbage
19:24:42 <bwh> Is it worth trying to reproduce on some other system using nouveau? (I don't have any Nvidia hardware)
19:24:54 <waldi> me neither
19:25:26 <bwh> Well I suppose it can be forwarded upstream then since it is found in 7.1
19:26:21 <bwh> can you ask them to report upstream?
19:26:32 <waldi> yes
19:26:37 <bwh> thanks
19:26:41 <bwh> #topic Bug #1141866: (i, U+u) linux-image-7.1.3+deb14-amd64: no display on AMD Kaveri/CIK APU VGA output (amdgpu DC regression)
19:28:16 <bwh> I'm checking whether this is already queued
19:28:46 <bwh> no it isn't
19:28:54 <bwh> So should we cherry-pick it?
19:29:45 <waldi> is it in 7.2?
19:29:48 <bwh> yes
19:30:01 <waldi> so it's just another few days
19:30:58 <bwh> maybe but I think it may have been skipped because of a wrong Fixes reference
19:31:18 <bwh> #action bwh will request the fix for #1141866 to be included in 7.1-stable
19:31:32 <bwh> #topic Bug #1141969: (i, ) linux-image-7.1.3+deb14-amd64: Cannot shutdown computer
19:31:54 <carnil> hi
19:32:08 <bwh> Hi!
19:33:28 <bwh> I didn't notice previously that someone has a workaround for this
19:34:11 <bwh> So I think we should ask the original reporter whether that workaround (nowatchdog) works for them, and if so I think we can forward this to the watchdog mailing list
19:35:03 <yunseong[m]> Hi carnil
19:35:49 <yunseong[m]> bwh: Can I send the mail?
19:35:58 <bwh> yunseong[m]: of course!
19:36:04 <yunseong[m]> Ok!
19:36:19 <bwh> #action yunseong[m] will respond to original reporter of #1141969
19:36:43 <bwh> #topic Bug #1142004: (i, +u) linux-image-6.12.95+deb13-amd64: i915 probe wedges Xiaomi Mi Pad 2 during power init (forwarded: gitlab.freedesktop.org)
19:36:47 <bwh> yunseong[m]: thank you
19:37:16 <yunseong[m]> Happy to contributing. :)
19:38:13 <bwh> Oh, I mixed up the status summaries for this and the next bug
19:38:13 <yunseong[m]> * I'm happy to contribute. :)
19:38:30 <iam_tj[m]> Re: 1141183 (just got back) - we're still working on it. Could be the kernel is mmkaing a subtle mistake with IOVAs caused by BIOS incosistencies.
19:38:47 <bwh> iam_tj[m]: thanks
19:39:17 <iam_tj[m]> Will update the bug report when we have some firm evidence - currently instrumented functions to figure out exactly what is happening
19:39:40 <bwh> This one (#1142004) did get a response upstream and I think we can leave it there now
19:40:33 <bwh> #topic Bug #1142099: (i, ) /usr/share/bug/linux-image-6.12.95+deb13-amd64-unsigned/include-1cmdline: Kernel 6.12.95 does not start boot sequence without setting acpi=off or recovery mode (logs in this mode)
19:41:40 <bwh> This is a regression in the 6.12 series and I assume is TPM related ("Failed to measure data")
19:42:09 <bwh> although that could be an unrelated warning that's not new
19:42:34 <bwh> Is there a kernel boot parameter to disable the TPM stuff?
19:43:48 <waldi> no
19:44:10 <bwh> hmm
19:44:21 <bwh> I suppose this one will need bisection
19:45:13 <bwh> Can someone send bisection instructions?
19:45:21 <carnil> if I can find time (next weke should be etter) I can take care of it
19:45:23 <waldi> earlyconsole might also give some clue
19:45:32 <bwh> waldi: yes maybe
19:45:47 <carnil> so you an assign a an aciton to me if that is fine for everybody
19:46:01 <bwh> #action carnil will ask for bisection of #1142099
19:46:03 <bwh> thank you!
19:46:20 <bwh> #topic Bug #1142166: (i, ) Regression: suspend and reboot freezes at ACPI platform stage on HP laptop
19:47:56 <bwh> This is a regression from 7.0 to 7.1, so I suppose we can forward it upstream. But it probably needs bisection to work out where the breakage happened
19:49:59 <bwh> Does anyone have any other ideas?
19:50:29 <waldi> no
19:50:49 <carnil> no, sorry
19:51:06 <carnil> bisecion sound sgood and then forward upstream
19:51:21 <bwh> #action bwh will ask for bisection of #1142166
19:51:29 <bwh> #topic Bug #1142179: (i, M) Kernel panic in acpi_idle_enter() with linux-image-7.0.12+kali-amd64
19:51:41 <bwh> This is waiting for the reporter to re-test
19:51:49 <bwh> #topic Bug #1142424: (i, ) linux-image-6.12.95+deb13-amd64: kernel crash with maybe SMAP trigger
19:53:18 <bwh> The "reserved bit violation" sounds to me like page table corruption but I may be misunderstanding
19:53:28 <waldi> yes. and look at the page table entry
19:54:10 <waldi> ah, i looked into that and than considered myself currently unable to understand the page table stuff correctly
19:55:24 <bwh> So, maybe worth doing a memory test? At least if this system does not have ECC?
19:55:31 <iam_tj[m]> I asked the reporter to report this one; there is some additional context. The bug occurs after several hours of running ... I checked logs and typically it was + 54 hours
19:56:05 <iam_tj[m]> I did suggest a memtest86+ but not clear if they did; they 'disappeared' from chat
19:56:22 <Corsac> it's my bug
19:56:51 <Corsac> so far it didn't happen again in 24-36h and now I've upgraded to 96
19:57:33 <Corsac> I might try a memtest86 if it happens again but since it's a headless server which I only have ssh and console access (after grub) I might have some issues running ot
19:57:35 <Corsac> it*
19:57:59 <bwh> yes I can imagine that will be annoying to do
19:58:13 <iam_tj[m]> I'm deep in PTE myself at present so if it recurs I'll dig deeper
19:58:39 <bwh> iam_tj[m]: Can we leave this with you?
19:59:13 <iam_tj[m]> Yes
19:59:35 <bwh> #action iam_tj[m] will handle #1142424 for now
19:59:45 <bwh> thanks
19:59:49 <bwh> #topic Bug #1142429: (i, ) linux-image-7.1.3+deb14-amd64: Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
20:00:37 <bwh> The log in the QR code is again not quite long enough
20:01:12 <iam_tj[m]> Another HP laptop and v7.1 ?
20:01:46 <bwh> Not sure if it's a pattern or HPs are just popular
20:03:06 <bwh> Is it worth searching on the functions in the traceback to see if there are other reports?
20:05:49 <bwh> Anyone volunteer to handle this?
20:06:33 <bwh> OK, this is going unanswered for now
20:06:41 <bwh> #topic Bug #1142440: (i, ) linux-image-amd64: amdgpu Mullins: intermittent hibernation resume hang with page fault in drm_sched_job_arm
20:07:53 <bwh> Seems to be a regression between 6.12.94 and 6.12.95, but with a non-default driver configuration
20:08:11 <bwh> so I think it's reasonable to ask to test with radeon handling the GPU instead of amdgpu
20:08:48 <bwh> #action bwh will respond to #1142440 and ask to test with radeon
20:08:57 <bwh> #topic Bug #1139265: (n, ) linux-image-7.0.10+deb14-amd64: QXL graphics crash, processes stuck in D state, NULL-dereference errors, TTY-subsystem malfunction
20:09:27 <bwh> This was originally reported with the old i440 QEMU VM and Xorg, but it also affects Q35 and Wayland
20:10:31 <bwh> I suppose we can ask to re-test on 7.1, and then forward upstream?
20:10:56 <waldi> sounds like a plan
20:11:00 <waldi> i'll do that
20:11:01 <carnil> ok
20:11:25 <bwh> #action waldi will respond to #1139265 again
20:11:39 <bwh> #topic Bug #1139950: (n, u) amdgpu carrizo: no display signal after modeset (forwarded: stable)
20:12:16 <bwh> This just has a new ping from Thorsten Leemhuis. Shall I add the moreinfo tag?
20:12:39 <carnil> but the ping is for upstream right, or did I got lost something in the discussion?
20:12:55 <carnil> because the reporter did reply, but replied only to the Debian bug, and Thosten forwarded the info to the upstrema thread
20:13:06 <carnil> so I think the ball is on upstream now
20:13:12 * carnil rereads
20:13:13 <bwh> The latest message is addressed to Jaak, the reproter
20:13:43 <carnil> up sorry I mixed up with another bug
20:13:44 <carnil> yes
20:13:59 <carnil> + moreinfo sounds right then
20:14:08 <bwh> OK
20:14:15 <bwh> #topic Bug #1141185: (n, ) linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.
20:14:45 <bwh> The new messages are #27 onward
20:14:58 <bwh> oh, right, it's just one new message actually
20:15:30 <bwh> but this really looks the hardware is busted, so we should close the report
20:16:41 <bwh> #action bwh will close #1141185 as not a kernel bug
20:17:12 <bwh> #topic #1141604: (n, u) linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook (forwarded: regressions)
20:17:43 <bwh> This seems to be progressing upstream (though the reporter keeps not replying-all)
20:18:06 <bwh> So I don't think we need to do anything right now
20:18:28 <carnil> yes right (and sorry this was the one I confused on before)
20:18:42 <bwh> #topic Bug #1141869: (n, ) linux-image-6.12.95+deb13-amd64: USB-C monitor that worked on Debian 12 fails on Debian 13 with "no signal"
20:19:17 <bwh> New report, no answer from us yet
20:20:10 <bwh> I feel like we've seen a few other bug reports about USB-C DP alt mode regressions recently, but I don't remember if any of them exactly match this
20:21:50 <bwh> Does anyone have any ideas what to suggest for debugging this?
20:22:02 <bwh> Should we just ask for bisection?
20:23:12 <bwh> OK, moving on
20:23:15 <carnil> and maybe ask if they can test a recent 7.1.4 as well. But then we need anyway to isolate the change inbeween
20:23:23 <bwh> yes
20:23:33 <carnil> I will (try) to ask that and can take an action
20:23:55 <bwh> #action carnil will respond to #1141869
20:24:00 <bwh> Thanks again
20:24:09 <bwh> #topic Bug #1141885: (n, M) linux: FTBFS on sh4 due to internal compiler error, works with gcc-16
20:24:41 <bwh> This is waiting for cbmuser to confirm that a full build with gcc-16 will actually work
20:24:59 <bwh> I don't think we need to do anything before then
20:25:14 <bwh> #topic Bug #1142102: (n, ) linux-image-7.1.3+deb14-amd64: error on /sys/kernel/debug/dri/0/pstate
20:25:52 <bwh> debugfs is not a stable API, of course
20:26:14 <bwh> so I propose to downgrade this to minor and suggest reporting upstream
20:27:21 <bwh> #action bwh will respond to #1142102
20:27:31 <bwh> #topic Bug #1142264: (n, ) nouveau: “fifo: fault 01 [VIRT_WRITE]” and “gr: DATA_ERROR” and “[gst-plugin-scan[…]] errored”
20:29:01 <bwh> So far as I can work out, the bug being reported is log spam at info level
20:29:09 <bwh> rather than a graphical problem
20:30:01 <bwh> Ask to test a backports kernel and then report upstream if not fixed there?
20:30:56 <bwh> Perhaps we are all too tired to deal with these...
20:30:59 <carnil> the reporter sound familiar for similar reports
20:32:32 <bwh> #topic Bug #1142419: (n, ) 7.1.3 does not resume "i915 0000:00:02.0: [drm] pipe state doesn't match!"
20:33:23 <bwh> carnil: Can this be forwarded upstream now?
20:33:36 <carnil> bwh: yes I will take care of it
20:33:40 <bwh> thanks
20:33:53 <bwh> #action carnil will forward #1142419 upstream
20:34:04 <bwh> #topic Bug #1142442: (n, +) linux: no installer udeb ships reset-gpio, breaking SDIO Wi-Fi (mmc-pwrseq-simple) in d-i on ARM Chromebooks
20:35:36 <bwh> There is a patch for this, but I think that reset-gpio belongs in base-modules and not mmc-modules
20:36:01 <bwh> It seems like we already did that for riscv64 but not in the generic configuration
20:36:23 <bwh> #action bwh will try to fix #1142442 generically
20:36:32 <bwh> #topic Bug #1142489: (n, ) linux-image-7.1.3+deb14-amd64: nouveau 0000:01:00.0: Xorg[1491]: failed to idle channel 4 [Xorg[1491]]
20:38:05 <bwh> Is this another case of "don't use Xorg then"?
20:40:04 <carnil> is this a regression?
20:40:33 <bwh> I don't know. Not clear whether this even happened repeatedly
20:41:27 <carnil> hmm should we ask then if this is reproducible with 7.1.3 and if yes ifi t was a regression from earlier kernel (which?) and then ask to bisect still?
20:41:32 <bwh> yes
20:41:47 <carnil> then let's do that as a start :)
20:42:00 * carnil raises hands
20:42:12 <bwh> #action carnil will respond to #1142489
20:42:26 <bwh> I propose to skip the minor and wishlist bugs
20:42:34 <carnil> agreed
20:42:59 <bwh> #topic Bug #1131809: (S, ) dracut: ppc64el autopkgtest are flaky and take 7 hours per run
20:43:30 <bwh> There was some discussion but I don't see any fixes coming for ppc64el
20:44:01 <bwh> I think I still have an action to look at this, which I will keep (while still hoping bdrung will deal with it first :-))
20:44:35 <bwh> #topic Bug #978644: (n, Uu) Wipe LUKS Disk Encryption Key for Root Disk from RAM during Shutdown to defeat Cold Boot Attacks from Dracut Initramfs (forwarded: www.github.com)
20:45:20 <bwh> The upstream report was closed in 2025 and bts-link seems to have only now marked it fixed-upstream. There were related changes upstream but I don't know if they actually fixed this properly
20:45:47 <bwh> I don't care enough to investigate it myself
20:46:13 <bwh> #topic Bug #1141993: (i, ) firmware-realtek: There is something wrong in the firmware rtl8188eufw.bin provided from "trixie" release
20:46:30 <bwh> I will respond to this but I doubt that I can really help
20:46:40 <bwh> #action bwh will respond to #1141993
20:47:25 <bwh> #topic migration excuses
20:47:44 <bwh> I think this is just linux 7.1.4-1 not being old enough yet
20:47:57 <bwh> #topic New upstream versions
20:48:18 <bwh> Only firmware-free has a new version and I don't believe there are relevant changes
20:48:25 <bwh> #topic Merge requests
20:48:44 <bwh> Anyone want to discuss an MR, or do we all want to close the meeting?
20:49:14 <yunseong[m]> Thank you so much Ben! I hope close the meeting. :)
20:49:42 <bwh> #topic AOB
20:50:06 <bwh> Any non-urgent topics?
20:50:11 <bwh> And who will chair next week?
20:52:15 <bwh> I am *not* doing this 2 weeks in a row
20:52:55 <carnil> sorry got distracted by other things around me, same as delayed me joiing the meeting
20:53:01 <carnil> I can take care of preparing the meeting
20:53:07 <bwh> Thank you very much
20:53:18 <bwh> #action carnil will chair next week
20:53:19 <bwh> #endmeeting