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