19:01:05 #startmeeting 19:01:05 Meeting started Wed Sep 30 19:01:05 2026 UTC. The chair is bwh. Information about MeetBot at https://wiki.debian.org/MeetBot. 19:01:05 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:09 o/ 19:01:11 hi 19:01:57 Is waldi present? 19:01:57 hi 19:02:12 Welcome! 19:02:26 Any urgent issues before we get into the bug list? 19:02:36 not from my side 19:02:37 idk 19:02:50 not from my side 19:03:04 #topic Bug #1115581: (i, ) linux-image-6.16.3+deb14-rt-amd64: Boot hang with Creative Sound Blaster AE-7 [1102:0010] (forwarded: bugzilla.kernel.org) 19:04:00 I just noticed that this is about -rt. Maybe not relevant at that stage any more, but in general testing on non-rt is a good idea for such things. 19:04:01 There's a link to a GH repo full of slop but the actual fix is a single patch adding a bunch of MMIO register reads after register writes 19:04:54 Not sure what was the last upstream version tested 19:05:07 https://github.com/AffSeda/Creative_AE7_Linux/blob/main/patches/workaround-flush-every-hda-write.patch ? 19:05:13 yes 19:06:03 -#define snd_hdac_reg_writel(bus, addr, val) writel(val, addr) 19:06:04 +#define snd_hdac_reg_writel(bus, addr, val) do { void __iomem *__a = (addr); writel(val, __a); (void)readl(__a); } while (0) /* AE-7/ASM1083 */ 19:06:08 uah 19:06:16 ... but if it helps ... 19:06:22 yes, every write was changed into write+read 19:07:02 The README says tested on 7.2.6. So, might make sense to forward this upstream? 19:07:51 Isn't Connor McAdams upstream? 19:08:36 I assume so but the last message didn't cc him 19:09:48 #action bwh will forward the latest update to #1115581 upstream 19:09:56 bwh: thanks 19:09:56 #topic Bug #1142440: (i, ) linux-image-amd64: amdgpu Mullins: intermittent hibernation resume hang with page fault in drm_sched_job_arm 19:10:23 Reporter responded to a part of @ukleinek's questions 19:10:41 they tested 6.12.$latest, but not sid/forky, so not yet actionable 19:10:47 ah, I see 19:11:26 OK I will add back the moreinfo tag 19:11:34 * ukleinek nods 19:11:50 #topic Bug #1145111: (i, u+) linux: kernel NULL pointer dereference when running libqb, rustc or snapd testsuite 19:12:13 [1790794633] carnil: aurel32: re the apparmor issue got a reply from upstream on IRC: 19:12:16 [1790794635] carnil: [19:48] < jjohansen> carnil I will try to get to it today 19:12:17 jjohansen sid that he will try to look at it tonight 19:12:52 OK, so we continue to leave this with upstream 19:13:04 #topic Bug #1149109: (i, ) linux-image-7.1.8+deb13-amd64: amdgpu flip_done timed out and freeze on RX 6600 (regression from 7.1.3) 19:13:45 There seem to be a few duplicates of this 19:13:47 I guess for those amdgpu specific issues to just ask the reporter to report an upstream issue? 19:14:01 yes, some claimed to be fixed in 7.2.8 19:14:22 For the next one, alpernebbi added a reference to a possible fix 19:14:29 but then they are different from those :-/ 19:14:34 oh 19:14:55 anyhow, asking for a test on testing/unstable is a good idea 19:15:38 I can ask to please test with 7.2.8-1 in unstable 19:16:10 and we have TAINT_OOT_MODULE 19:16:10 (and if it is still present there to make an new upstream issue, if you agree) 19:16:21 * ukleinek nods 19:16:24 carnil: OK 19:16:41 Setting dangerous option gpu_recovery - tainting kernel 19:17:41 oh right, so additionally ask to on the motivation to use it? 19:18:22 Sounds like a failed attempt to work around the bug. But indeed it should probably be turned off when re-testing 19:20:24 #action carnil will ask to test whether #1149109 is fixed in 7.2 and without the gpu_recovery module option 19:20:36 #topic Bug #1149355: (i, ) amdgpu flip_done timed out with Radeon 9060 XT 19:21:37 So this is a very similar one, also we already saw this reporter in other bug report 19:21:49 is vbox suspicious here? 19:22:20 vbox is always weird 19:22:42 Yeah but we have 3 similar bug reports which don't all have vbox, so... 19:23:48 The potential fix is queued and should go into 7.2.9 19:24:01 so we wait 19:24:28 carnil: Perhaps it would make sense to wait for 7.2.9 for the other one as well? 19:24:38 yes right 19:24:43 7.2.9 should come out on friday 19:25:37 Who will take this one? 19:25:57 bwh: to ask to test the patch? 19:26:21 ..ooOO(Or waiting? :-) 19:26:24 yes or to test 7.2.9-1 when available 19:26:48 yes ok assign it to me then I can handle both as similar issues 19:27:21 I will ask if they have tim to test the patch with our test-patches script which should make it easy enough from them to rebuild the kernel with only the patch on top 19:27:36 #action carnil will ask to test whether #1149355 is fixed by the linked patch 19:27:41 Thank you! 19:27:53 #topic Bug #1149525: (i, ) linux-image-7.2.6+deb14-arm64: 7.2.6 and 7.2.8 both fail gc_worker+0x130/0x780, address 0x10037 on rockpro64 19:30:34 regression from 7.1, for reproduction the nf rules are probably needed 19:30:55 yes probably 19:31:15 maybe worth asking for bisection? Or what was the bug waldi cloned from the issue from Helmut, might they be linked? 19:31:40 #action ukleinek replies to #1149525 coordinating nf rules, bisection and upstream reporting 19:32:09 #topic Bug #993068: (n, ) SD don't detect by 0bda:0129 RTS5129 Card Reader with kernel 5.10 19:32:53 ukleinek asked to test on 7.2. I'll add the moreinto tag and I don't think we need to do anything more now 19:33:13 * ukleinek was about to fix the missing moreinfo 19:33:21 #topic Bug #1110749: (n, u) ee1004: DDR4 SPD cannot be read, decode-dimms fails, “Failed to select page 0 (-6)” 19:34:02 "It doesn't help in the sense that I still don't know how to programmatically read SPD-EEPROM of the modules installed on my system." ?? 19:34:23 the netfilter stack exhaustion can be reproduced via the nftables autopkgtest 19:34:53 ukleinek: Which was addressed by Jean Delvare already: "Long term, we need the hardware vendor to provide technical information about the board so that we can implement SMBus multiplexing support in the i2c-i801 driver […]" 19:35:09 helmut: #1149525 doesn't look like a stack exhaustion 19:35:33 ukleinek: helmut did not talk about #1149525 19:35:35 bwh: I wonder if the reporter wants something else?! 19:36:31 ukleinek: then I am confused why carnil highlighted me. I'll shut up again and we may sort it out post meeting 19:37:48 it's unclear to me if there is still something to do for us in #1110749, and if yes what 19:38:03 They would like SPD EEPROM access to work on their system, but it's not clear to me that it worked previously 19:38:21 there is no indication it ever worked 19:38:37 and the machine still boots?! 19:38:53 nothing depends on the spd thingies 19:39:09 Well the system firmware does, but Linux doesn't 19:39:10 only the firmware needs to read them and setup memory stuff accordingly 19:39:20 The error message is new and I think Jean Delvare has the informaiton needed to blocklist this system, so I don't think we need to do anything 19:39:35 ack 19:39:36 #topic Bug #1146033: (n, ) linux-image-7.1.8+deb14.1-amd64: cannot shutdown laptop 19:40:14 intel-microcode was not the solution. What can we suggest now? 19:40:14 no luck = still old microcode + issue? 19:40:55 That's not how I read it 19:41:10 no luck = still message about old microcode + issue? 19:41:50 I read it as the issue is still there and not the message about old microcode 19:42:07 In any case they now have the latest version of microcode we provide 19:42:13 (which could mean that it wasn't properly applied, or the microcode package doesn't help on that machine) 19:42:44 It is a rather old CPU 19:42:50 ISTR we had some ideas about that bug during the last meeting 19:43:39 regression 7.0 -> 7.1, does reboot work? 19:44:33 #action ukleinek follows up on #1146033 asking for a bisection and if reboot works. 19:44:39 Thanks 19:44:49 #topic Bug #1148804: (n, ) linux-modules-7.2.6+deb14-amd64（7.2.6-1）Nouveau: failed to boot - NVIDIA Corporation GA103M [GeForce RTX 3080 Ti Laptop GPU] 19:45:29 Missing system information. I'll ask for that 19:45:44 #action bwh will ask for missing system info for #1148804 19:45:55 #topic Bug #1149377: (n, M) linux-image-6.12.111+deb13-amd64: Bluetooth no longer works after kernel upgrade 19:46:14 Regression on the 6.12 branch 19:46:43 carnil asked for bisection, so we can wait for that 19:47:04 #topic Bug #1149499: (n, M) Fwd: linux-image-6.12.111+deb13-amd64: HID: asus: built-in keyboard unresponsive at login screen, "Asus failed to request functions: -75" (regression vs 6.12.107) 19:47:14 failed to load firmware, maybe compare that to the working kernel log 19:47:36 (I was to sloow, that was still for #1149377) 19:47:40 Oh huh 19:48:07 #topic Bug #1149377: (n, M) linux-image-6.12.111+deb13-amd64: Bluetooth no longer works after kernel upgrade 19:48:31 Did someone change firmware filename generation in stable?! 19:48:41 also a firmware loading failure for ath9k 19:49:14 error is -2 = ENOENT 19:50:55 It doesn't explain why rebooting into the old kernel fixes it 19:50:56 Weird 19:51:15 oh I found something 19:51:44 f05baf6e0680 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") this is new in v6.12.109 19:51:55 the timestamp suggests this is after the initrd, so broken initramfs isn't an explanation 19:52:17 and afaics the firmware to load is Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found 19:52:24 did that had some side effects here? 19:52:36 That firmware was added post-trixie 19:53:39 That's probably it - the adapter actually had working firmware on-board but now the driver tries and fails to load it from disk 19:54:27 sounds plausible 19:55:14 Let's revert that for now, then? 19:55:21 https://lore.kernel.org/regressions/9ac1c05b-e9f2-49e9-af63-9cd0e42115fc@gmail.com/ 19:55:46 https://lore.kernel.org/regressions/daily-reply-0016-re-btusb-rtl8761cuv-regression@kernel.org/ 19:55:48 Or should we add that blob to firmware-realtek? 19:56:13 afaiu so sasha has queued the fix up for the next 6.12.y upload 19:56:18 Oh OK 19:56:21 let me see if it is in 6.12.112-rc1 19:58:07 given the time: check that maybe at a later point in time? 19:58:15 right 19:58:58 #action bwh will check whether #1149377 is fixed by another kernel fix or needs new firmware too 19:59:13 that's sounds like the right plan, thx 19:59:20 #topic Bug #1149499: (n, M) Fwd: linux-image-6.12.111+deb13-amd64: HID: asus: built-in keyboard unresponsive at login screen, "Asus failed to request functions: -75" (regression vs 6.12.107) 19:59:31 this sounds like 19:59:32 ab7bd22eeca0 (HID: asus: simplify RGB init sequence, 2026-08-26) 19:59:46 yes carnil already mentioned that 20:00:02 and asked to test a fix, so I don't think we need to do anything more now 20:00:17 #topic Bug #1148341: (m, ) linux: enable memory compaction on Alpha 20:00:17 ups 20:00:29 This is now pending 20:00:44 #topic Bug #1148724: (w, ) linux: please enable CONFIG_BMI323_I2C (BOSC0200 accelerometers on 2-in-1s) 20:00:48 Also pending 20:00:54 #topic Bug #1148923: (w, +) linux-image: Add backport for SystemBase Multi I/O cards (tty/serial/8250) 20:01:30 should go via stable, shouldn't it? 20:01:49 probably, and in any case should go to our 6.12 branch as well 20:02:00 Since this was sent for 6.1 I'll take it 20:02:38 #action bwh will try to get the patch for #1148923 into the right branches 20:02:52 #topic Bug #1148952: (w, +) linux: enable opt-in Kexec Handover and Live Update Orchestrator 20:03:42 We have an MR which I really should look at, but I beleive I have an action for that already 20:04:52 #topic #1149146: (w, +) linux-image-7.2.7+deb14-amd64: Please enable CONFIG_RTW89_8852CU (enable Valve Steam Frame wireless dongle) 20:05:00 This is pending 20:05:13 #topic Migration excuses 20:05:42 There's an autopkgtest regression for linux, which I think is due to a warning message about pahole version skew 20:06:06 yes 20:06:33 Someone mentioned that earlier I think? 20:07:50 Does it make sense to filter out that warning, so it doesn't breka the test? 20:08:54 lets disable stderr completely. there are other warnings 20:09:16 why did the kernel build use a newer pahole than the test? I would have understood it the other way around?! 20:09:48 the warning is only about different versiobn 20:10:01 ah, maybe because the test runs in testing? 20:10:08 waldi: Disagree, we don't want to see warnings and should only ignore them if we know they're not relevant 20:10:31 s/don't/do/ 20:10:33 bwh: warnings are not errors 20:10:39 ukleinek: yes 20:11:24 * ukleinek is with bwh, we want to see warnings and let some known warnings not trigger a migration issue 20:11:29 and yet we try to build warning-free... 20:12:13 #action bwh will investigate whether we should suppress the pahole version skew warning in linux-kbuild autopkgtest 20:12:26 #topic New upstream versions 20:12:59 7.3-rc5 is already in d/latest 20:13:03 Right. I suppose I need to look at the new ktls-utils 20:13:28 #action bwh will try to update ktls-utils to 1.5.0 20:13:35 #topic Merge requests 20:13:56 is the daily installer using the sid or forky kernel? There is a user in #d-arm waiting for one of the MRs we recently merged 20:14:15 I think it's sid? 20:14:48 I would like you all to review the text in kernel-team!15 20:15:43 I also recently read which might have some better explanation for why we don't want LLM-generated text 20:16:06 Do we need to discuss any MRs now? 20:17:18 I will assume you all want to be done with the meeting, so 20:17:25 #topic Any other business 20:17:46 * ukleinek won't attend next week's meeting 20:18:32 waldi: Were you willing to chair next week? 20:18:36 possibly I will need to skip it as well next week 20:18:50 (but not yet sure) 20:19:14 bwh: yes 20:19:29 #action waldi will chair next week 20:19:32 #endmeeting