19:00:46 #startmeeting 19:00:46 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:57 hi 19:00:58 Hello everyone! 19:01:48 carnil did not expect to be able to attend (at least at the start) 19:01:57 Did ukleinek say whether he would be absent? 19:02:43 i can't remember 19:02:55 Any urgent issues before we start on the bug list? 19:03:10 nope 19:03:28 #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 I will downgrade the severity to important 19:04:44 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 Does anyone volunteer to do that? 19:05:34 I can do it! 19:05:52 #action yunseong[m] will respond to #1142158 19:05:53 thanks! 19:06:02 #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 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 I'm happy to keep the action though 19:06:45 #topic Bug #1142571: (S, ) linux-modules-7.1.4+deb14-loong64: Unable to boot due to unloadable modules (merged with #1142426) 19:07:33 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 yeah 19:08:28 #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 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 okay 19:10:01 #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 Reporter asked an LLM about it, and I think we can ignore that 19:11:40 #topic Bug #1141183: (i, u) src:linux: I/O errors on SATA devices related to IOMMU (forwarded: bugzilla.kernel.org) 19:12:35 nothing new. sounds like we can wait a bit longer 19:12:52 There is something new since the last meeting. And I didn't notice this was forwarded 19:13:44 Ah, last comment upstream from Tj is that there is a system firmware bug 19:14:25 unless they mean that that's a separate bug - I'm not sure I'm reading the comment correctly 19:15:05 iam_tj[m]: Could you say whether you think #1141183 is still a kernel bug? 19:15:51 #topic Bug #1141719: (i, M) linux-image-7.0.13+deb14-amd64: shutdown hang on dell pro max 16 laptop (i915) 19:17:08 I'll remove the moreinfo tag from this, as the information has been provided 19:17:26 Can anyone respond to this? 19:17:34 falcon-sensor, which is known to break systems if they don't run in lockdown mode. or did they fix that? 19:18:20 Interesting... 19:18:35 probably doesn't break i915 though 19:18:53 if they still use the kernel module part, they hook syscalls 19:18:58 yes 19:19:00 (and patch away the taint flag) 19:19:21 They do *what*?! 19:20:13 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 thats why the names where random generated and forcr loaded with symbol versions 19:20:55 i would assume this one uses BPF, yes 19:21:12 s/with/without/ 19:21:15 The two kinds of malware authors: malware authors and anti-malware vendors 19:21:20 yes 19:21:40 anyway... 19:21:53 #action bwh will try to respond to #1141719 19:22:17 i have no idea about that one. needs upstream` 19:22:19 ? 19:22:27 #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 Assisted-by: Claude:claude-5-sonnet (high) 19:23:50 indeed 19:24:11 I assume the crash in nouveau_fence_sync() running evince is real, and the rest may be garbage 19:24:42 Is it worth trying to reproduce on some other system using nouveau? (I don't have any Nvidia hardware) 19:24:54 me neither 19:25:26 Well I suppose it can be forwarded upstream then since it is found in 7.1 19:26:21 can you ask them to report upstream? 19:26:32 yes 19:26:37 thanks 19:26:41 #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 I'm checking whether this is already queued 19:28:46 no it isn't 19:28:54 So should we cherry-pick it? 19:29:45 is it in 7.2? 19:29:48 yes 19:30:01 so it's just another few days 19:30:58 maybe but I think it may have been skipped because of a wrong Fixes reference 19:31:18 #action bwh will request the fix for #1141866 to be included in 7.1-stable 19:31:32 #topic Bug #1141969: (i, ) linux-image-7.1.3+deb14-amd64: Cannot shutdown computer 19:31:54 hi 19:32:08 Hi! 19:33:28 I didn't notice previously that someone has a workaround for this 19:34:11 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 Hi carnil 19:35:49 bwh: Can I send the mail? 19:35:58 yunseong[m]: of course! 19:36:04 Ok! 19:36:19 #action yunseong[m] will respond to original reporter of #1141969 19:36:43 #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 yunseong[m]: thank you 19:37:16 Happy to contributing. :) 19:38:13 Oh, I mixed up the status summaries for this and the next bug 19:38:13 * I'm happy to contribute. :) 19:38:30 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 iam_tj[m]: thanks 19:39:17 Will update the bug report when we have some firm evidence - currently instrumented functions to figure out exactly what is happening 19:39:40 This one (#1142004) did get a response upstream and I think we can leave it there now 19:40:33 #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 This is a regression in the 6.12 series and I assume is TPM related ("Failed to measure data") 19:42:09 although that could be an unrelated warning that's not new 19:42:34 Is there a kernel boot parameter to disable the TPM stuff? 19:43:48 no 19:44:10 hmm 19:44:21 I suppose this one will need bisection 19:45:13 Can someone send bisection instructions? 19:45:21 if I can find time (next weke should be etter) I can take care of it 19:45:23 earlyconsole might also give some clue 19:45:32 waldi: yes maybe 19:45:47 so you an assign a an aciton to me if that is fine for everybody 19:46:01 #action carnil will ask for bisection of #1142099 19:46:03 thank you! 19:46:20 #topic Bug #1142166: (i, ) Regression: suspend and reboot freezes at ACPI platform stage on HP laptop 19:47:56 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 Does anyone have any other ideas? 19:50:29 no 19:50:49 no, sorry 19:51:06 bisecion sound sgood and then forward upstream 19:51:21 #action bwh will ask for bisection of #1142166 19:51:29 #topic Bug #1142179: (i, M) Kernel panic in acpi_idle_enter() with linux-image-7.0.12+kali-amd64 19:51:41 This is waiting for the reporter to re-test 19:51:49 #topic Bug #1142424: (i, ) linux-image-6.12.95+deb13-amd64: kernel crash with maybe SMAP trigger 19:53:18 The "reserved bit violation" sounds to me like page table corruption but I may be misunderstanding 19:53:28 yes. and look at the page table entry 19:54:10 ah, i looked into that and than considered myself currently unable to understand the page table stuff correctly 19:55:24 So, maybe worth doing a memory test? At least if this system does not have ECC? 19:55:31 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 I did suggest a memtest86+ but not clear if they did; they 'disappeared' from chat 19:56:22 it's my bug 19:56:51 so far it didn't happen again in 24-36h and now I've upgraded to 96 19:57:33 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 it* 19:57:59 yes I can imagine that will be annoying to do 19:58:13 I'm deep in PTE myself at present so if it recurs I'll dig deeper 19:58:39 iam_tj[m]: Can we leave this with you? 19:59:13 Yes 19:59:35 #action iam_tj[m] will handle #1142424 for now 19:59:45 thanks 19:59:49 #topic Bug #1142429: (i, ) linux-image-7.1.3+deb14-amd64: Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 20:00:37 The log in the QR code is again not quite long enough 20:01:12 Another HP laptop and v7.1 ? 20:01:46 Not sure if it's a pattern or HPs are just popular 20:03:06 Is it worth searching on the functions in the traceback to see if there are other reports? 20:05:49 Anyone volunteer to handle this? 20:06:33 OK, this is going unanswered for now 20:06:41 #topic Bug #1142440: (i, ) linux-image-amd64: amdgpu Mullins: intermittent hibernation resume hang with page fault in drm_sched_job_arm 20:07:53 Seems to be a regression between 6.12.94 and 6.12.95, but with a non-default driver configuration 20:08:11 so I think it's reasonable to ask to test with radeon handling the GPU instead of amdgpu 20:08:48 #action bwh will respond to #1142440 and ask to test with radeon 20:08:57 #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 This was originally reported with the old i440 QEMU VM and Xorg, but it also affects Q35 and Wayland 20:10:31 I suppose we can ask to re-test on 7.1, and then forward upstream? 20:10:56 sounds like a plan 20:11:00 i'll do that 20:11:01 ok 20:11:25 #action waldi will respond to #1139265 again 20:11:39 #topic Bug #1139950: (n, u) amdgpu carrizo: no display signal after modeset (forwarded: stable) 20:12:16 This just has a new ping from Thorsten Leemhuis. Shall I add the moreinfo tag? 20:12:39 but the ping is for upstream right, or did I got lost something in the discussion? 20:12:55 because the reporter did reply, but replied only to the Debian bug, and Thosten forwarded the info to the upstrema thread 20:13:06 so I think the ball is on upstream now 20:13:12 * carnil rereads 20:13:13 The latest message is addressed to Jaak, the reproter 20:13:43 up sorry I mixed up with another bug 20:13:44 yes 20:13:59 + moreinfo sounds right then 20:14:08 OK 20:14:15 #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 The new messages are #27 onward 20:14:58 oh, right, it's just one new message actually 20:15:30 but this really looks the hardware is busted, so we should close the report 20:16:41 #action bwh will close #1141185 as not a kernel bug 20:17:12 #topic #1141604: (n, u) linux-image-6.12.94+deb13-amd64: does not detect ScreenPad on ASUS VivoBook (forwarded: regressions) 20:17:43 This seems to be progressing upstream (though the reporter keeps not replying-all) 20:18:06 So I don't think we need to do anything right now 20:18:28 yes right (and sorry this was the one I confused on before) 20:18:42 #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 New report, no answer from us yet 20:20:10 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 Does anyone have any ideas what to suggest for debugging this? 20:22:02 Should we just ask for bisection? 20:23:12 OK, moving on 20:23:15 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 yes 20:23:33 I will (try) to ask that and can take an action 20:23:55 #action carnil will respond to #1141869 20:24:00 Thanks again 20:24:09 #topic Bug #1141885: (n, M) linux: FTBFS on sh4 due to internal compiler error, works with gcc-16 20:24:41 This is waiting for cbmuser to confirm that a full build with gcc-16 will actually work 20:24:59 I don't think we need to do anything before then 20:25:14 #topic Bug #1142102: (n, ) linux-image-7.1.3+deb14-amd64: error on /sys/kernel/debug/dri/0/pstate 20:25:52 debugfs is not a stable API, of course 20:26:14 so I propose to downgrade this to minor and suggest reporting upstream 20:27:21 #action bwh will respond to #1142102 20:27:31 #topic Bug #1142264: (n, ) nouveau: “fifo: fault 01 [VIRT_WRITE]” and “gr: DATA_ERROR” and “[gst-plugin-scan[…]] errored” 20:29:01 So far as I can work out, the bug being reported is log spam at info level 20:29:09 rather than a graphical problem 20:30:01 Ask to test a backports kernel and then report upstream if not fixed there? 20:30:56 Perhaps we are all too tired to deal with these... 20:30:59 the reporter sound familiar for similar reports 20:32:32 #topic Bug #1142419: (n, ) 7.1.3 does not resume "i915 0000:00:02.0: [drm] pipe state doesn't match!" 20:33:23 carnil: Can this be forwarded upstream now? 20:33:36 bwh: yes I will take care of it 20:33:40 thanks 20:33:53 #action carnil will forward #1142419 upstream 20:34:04 #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 There is a patch for this, but I think that reset-gpio belongs in base-modules and not mmc-modules 20:36:01 It seems like we already did that for riscv64 but not in the generic configuration 20:36:23 #action bwh will try to fix #1142442 generically 20:36:32 #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 Is this another case of "don't use Xorg then"? 20:40:04 is this a regression? 20:40:33 I don't know. Not clear whether this even happened repeatedly 20:41:27 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 yes 20:41:47 then let's do that as a start :) 20:42:00 * carnil raises hands 20:42:12 #action carnil will respond to #1142489 20:42:26 I propose to skip the minor and wishlist bugs 20:42:34 agreed 20:42:59 #topic Bug #1131809: (S, ) dracut: ppc64el autopkgtest are flaky and take 7 hours per run 20:43:30 There was some discussion but I don't see any fixes coming for ppc64el 20:44:01 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 #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 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 I don't care enough to investigate it myself 20:46:13 #topic Bug #1141993: (i, ) firmware-realtek: There is something wrong in the firmware rtl8188eufw.bin provided from "trixie" release 20:46:30 I will respond to this but I doubt that I can really help 20:46:40 #action bwh will respond to #1141993 20:47:25 #topic migration excuses 20:47:44 I think this is just linux 7.1.4-1 not being old enough yet 20:47:57 #topic New upstream versions 20:48:18 Only firmware-free has a new version and I don't believe there are relevant changes 20:48:25 #topic Merge requests 20:48:44 Anyone want to discuss an MR, or do we all want to close the meeting? 20:49:14 Thank you so much Ben! I hope close the meeting. :) 20:49:42 #topic AOB 20:50:06 Any non-urgent topics? 20:50:11 And who will chair next week? 20:52:15 I am *not* doing this 2 weeks in a row 20:52:55 sorry got distracted by other things around me, same as delayed me joiing the meeting 20:53:01 I can take care of preparing the meeting 20:53:07 Thank you very much 20:53:18 #action carnil will chair next week 20:53:19 #endmeeting