19:00:27 #startmeeting 19:00:27 Meeting started Wed May 28 19:00:27 2025 UTC. The chair is carnil. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:36 Hello everybody 19:00:38 hi 19:01:18 #chair waldi bwh ukleinek 19:01:18 Current chairs: bwh carnil ukleinek waldi 19:01:27 So maybe we are two today :) 19:01:45 is there anything we should put upfront before moving to the items of the agenda? 19:02:00 Hi 19:02:07 hi bwh 19:02:14 i have nothing to discuss 19:02:47 ok let's move straight to the bug list then, I tried to summarize the bugs 19:03:17 #topic #1104327: amdgpu: after laptop resume, AMD graphics just shows large patterns on all terminals 19:03:43 Uwe did followup there asking for more information, full log got provided and the issue is forwarded upstream to https://gitlab.freedesktop.org/drm/amd/-/issues/4252 19:04:02 apparently it is a duplicate of several issues already reported upstream with only little activity 19:04:23 I think we can 1. remove the moreinfo tag and then just wait that something happens upstream? 19:04:38 Or does someone feel to investigate more this amdgpu related issue? 19:04:55 o/ 19:05:00 I agree we can remove moreinfo 19:05:45 bwh: so removed the moreinfo tag now. Question is if we can do something more for the reporter. 19:06:23 I don't think so as no-one here is a GPU driver expert 19:06:33 (AFAIK) 19:06:41 I'm not :) 19:07:07 then let's just wait, we have linked the upstream issue and can check before next meeting if something happened 19:07:27 #topic #1106411: linux-image-6.12.27-amd64: kernel NULL pointer dereference in bmc150_accel_core 19:07:34 +1, it's only 4 days old 19:07:47 Asked for more information (full kernel log, and test with 6.1.129-1). Wait until getting response. 19:07:54 OK 19:07:57 ups, sorry typo, 6.12.29-1 19:07:58 * ukleinek nods 19:08:12 ok 19:08:16 and have quickly skimming over the upstream changes found nothing related. 19:08:27 #topic #1106498: linux-image-6.1.0-37-amd64: Ouput sound disappeared after last update on Lenovo Yoga Laptop 19:08:36 Not investigated. Observation from reporter that if doing power-off and on makes audio to be available again. 19:08:42 Fails when rebooting the machine. 19:08:51 sounds like a firmware issue 19:08:54 Ideas? Involve linux-sound or alsa-devel? do we need more information? 19:10:27 "SMBus is busy" smells like a device was busy during reset and failed to release the bus 19:10:34 the device is not properly reset. see the smbus errors, which is on the "same" pci device 19:11:10 I would suggest to check for a BIOS update 19:11:35 if there is a proper i2c driver for that smbus bus, a bus reset might work 19:11:39 I agree with waldi that this looks like an incomplete reset by the system firmware 19:12:26 does someone of you want to take an action to ask the reporter to verify if there is a BIOS update available? Otherwise I can do. 19:12:29 when forwarding the issue, I'd Cc both alsa-devel (and/or linux-sound) and linux-i2c 19:12:45 * ukleinek takes the action 19:13:08 #action ukleinek will ask the reporter to check for possible BIOS update 19:13:23 * ukleinek takes the freedom to do a bit more :-) 19:13:31 of course :) 19:13:47 #topic #1106558: linux-image-6.12.22+bpo-amd64: Wifi module fails to load 19:14:00 Logs provided but not full kernel logs. We should ask back again to provide those. 19:14:06 carnil: Please include bug numbers in actions because otherwise it will be unclear in the summary 19:14:19 Idea: Missmatch of kernel from bpo and firmware as issue? 19:14:34 bwh: ups, you are right, sorry 19:15:01 #action #1106498: ukleinek will ask the reporter to check for possible BIOS update 19:15:15 It could be the outdated firmware package. I didn't read the log yet 19:15:24 the logs are unusable 19:15:28 carnil: and the nick needs to go in front, so meetbot can aggregate 19:15:41 needs someone asking for the output of dmesg 19:16:10 ukleinek: I asked initially for the logs, and noticed today that the update, so will just ask again to provide the full kernel log 19:16:14 The "kernel logs" have no kernel messages at all 19:16:48 #action carnil follows up again on #1106558 to make sure reporter can provide for real the kernel logs for further investigation 19:17:47 I suspect still what wrote above as idea, that there might be a missmatch, but full kernel logs will hopefully enlight us 19:17:53 next topic if you agree 19:17:57 ack 19:18:10 #topic #1106268: linux-image-6.12.29-amd64: amdgpu DMCUB errors and lockups new in v6.12.29 19:18:30 This is handled upstream in https://gitlab.freedesktop.org/drm/amd/-/issues/4238 and there is apparently a pending revert https://lore.kernel.org/amd-gfx/20250521201057.76093-1-aurabindo.pillai@amd.com/ 19:18:44 so IMHO no action and just wait that the fixes land first in mainline and then in 6.12.y 19:18:48 ack 19:19:05 #topic #1106668: Waking up from suspend to RAM reproducibly leads to a hard freeze 19:19:26 This is apprently **not** a regression in 6.1.140 as reporter say it has been present "for a few weeks" 19:19:47 Reporter might be able to pingpoint the first Debian revision introducing the behaviour/issue 19:20:31 the red message is unrelated 19:22:45 there are some options to debug suspend issues. Something to not suspend the console (but then you need to read from the UART which is unusual on x86) 19:24:18 Looking at the hardware information, this is a 2017 motherboard so not new and excitingly different 19:25:03 I guess we can ask to try some of the pm_debug options to narrow down what is going wrong 19:25:44 * ukleinek doesn't know these options offhand, but would find them for sure. If nobody wants to take the action, I can. 19:26:27 ukleinek: See Documentation/power/basic-pm-debugging.rst 19:26:39 ukleinek: would be very welcome 19:26:49 (I actually mean pm_test rather than pm_debug) 19:27:09 #action ukleinek to research pm debug options and suggest something for #1106668 19:27:34 #topic #1100105: linux-image-amd64: Issues with Framework audio module 19:27:41 more ideas are needed here as well 19:28:52 Seems to work with Fedora's kernel AFIU 19:29:08 Ubuntu kernel not tried 19:29:23 I can follow up there, the guy didn't understand my instructions 19:29:39 #action ukleinek follows up on #1100105 19:29:49 Do we know which version Fedora is on? Can we ask to test our package from experimental, or has that already been done? 19:30:38 it mentions in earlier message that this occured as well on kernel 6.14, but maybe should retest it with what is now in experimental 19:31:24 Ah OK 19:31:46 Let's see what comes out from the followup from ukleinek to the reporter I would say 19:31:55 * ukleinek nods 19:31:57 btw, thanks ukleinek 19:32:13 #topic #1104745: gcc-15 ICE compiling linux kernel 6.14.5 with CONFIG_RANDSTRUCT 19:32:31 fwiw, reporter managed to make a minimal reproducer in https://bugs.debian.org/1104745#50 19:33:01 AFAIR, bwh assume you will still coordinate for this issue? 19:33:02 Oh good 19:33:10 does randstruct need a gcc plugin? Is it clear that this is a kernel issue? ICE sounds more like a compiler issue? 19:33:57 It does use a gcc plugin 19:34:15 so, the ICE can be caused by the plugin 19:34:18 so the plugin might be at fault, too, AFAIU 19:34:57 carnil: Yes I still take reponsibility to move this forward if doko stops responding 19:35:09 and the plugin is provided by the kernel, so the kernel is responsiblöe 19:35:09 ok thanks bwh 19:35:39 #action bwh still takes repsonsibility for #1104745 to move this forward 19:35:58 anything else to bring in on this? 19:36:11 !next 19:36:22 #topic #1106386: Bluetooth: btusb: Add RTL8851BE device 13d3:3601 19:36:46 this sounds to me like missing support for one particular device and we simply should ask the reporter to report it upstream (and close our bug)? 19:37:13 carnil: did you check that there is no driver for this device that we just don't enable? 19:37:40 I don't see any match for 0x3601 in drivers/bluetooth 19:37:44 ukleinek: no did not, I just only spotted the bug in the last hour before the meeting 19:38:02 ah, there is a kernel patch that seems to work ... 19:38:06 So I think this needs someone to write a proper patch 19:38:11 ack 19:38:33 * ukleinek looks at his todo list and thinks one more works 19:38:46 #action ukleinek writes a proper patch for #1106386 19:38:53 You beat me to it 19:39:30 bwh: you can if you want 19:39:35 ukleinek seems to have lot of time next week ;-) 19:39:50 medium 19:40:55 would be done similar to 181a2631a3144cd79e40ec5c77e7153085310dd3 I guess 19:41:16 carnil: indeed 19:41:43 so either ukleinek or bwh will write a patch :) for now it's ukleinek 19:41:57 #topic #1102518: linux-image-6.1.0-32-amd64: Microphone hotkey event stop working - Lenovo laptop 19:42:09 that one sounds as if it needs a bisect 19:42:16 this is one which needs actually some help to start debugging. 19:42:57 I think it's normal that the key press doesn't show up in evtest 19:43:04 ukleinek: yes possible, but from what I remember it is not yet even clear where the isuse got introduced, it got claimed initially it is fixed in one specific version, then apparently not 19:43:25 so there was some confusion and reopened the bug in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102518#40 19:43:49 It should not be tagged moreinfo 19:44:03 (until someone sends further questions) 19:44:42 let's remove it now. I failed to remove it after reporter did followup again 19:44:46 done 19:45:34 ukleinek: I think it's not normal because the firmware can't generally mute the mic itself (what if it's on a Bluetooth headset?) 19:46:11 lenovo likes to do special keys via acpi 19:46:24 Yes. But then the kernel turns them into regular input events 19:46:55 bwh: ah, maybe then the answer is "it depends". If the mute button is generic it should show up, if it only handles the internal mic it probably doesn't 19:47:27 Anyway the reporter says that there was an input event in some version 19:47:33 (and if it appears in 6.1.129 it also should in later versions) 19:48:25 so we let him bisect between 6.1.129 and 6.1.135? And/or ask for a test with the trixie kernel 19:48:43 right 19:49:10 and it would be beneficial to know that 6.1.129-1 is really "good", otherwise it's maybe another firmware issue 19:50:50 "but" my undestanding is that it's not really clear if 6.1.129-1 is good. It was "after reinstalling", thus first asked for bisect the changes between 6.1.128 and 6.1.129, there seems to be some random component in the behaviour as well :-/ 19:51:23 maybe a cold boot repairs it? 19:51:41 03firmware-nonfree 05pipeline 06Ben Hutchings 871401 * [1 hour, 29 minutes and 39 seconds] running (extract-source: success; build: success; lintian: pending; piuparts: pending; missing-breaks: pending) 19:52:06 I'd say: Let the reporter confirm that 6.1.129-1 is reliably good and then let him bisect. 19:52:14 so we might ask if it make a different if it is cold booted or rebooted from running system? 19:52:17 ukleinek: ok 19:52:33 carnil: Yes, I think that's also worth doing 19:53:08 since I tried to handle that already let me take this as action, will maybe need some help later again 19:53:18 * ukleinek nods, thx 19:53:41 #action carnil follows up to #1102518 asking to confirm if 6.1.129-1 is really good and if cold boot vs reboots shows the difference 19:54:08 so we are almost out of time will skip the last two bugs for src:linux though #1106227 would be new t olook at 19:54:23 #topic 19:54:23 #1092550: (w, M) procps: Addback/Provide example of sysctl.d/*.conf like the old sysctl.conf under /usr/share/doc/ 19:54:40 is beeing handled, and think needs just an agreement that it can be put as example in procps? 19:55:04 yes 19:55:27 ok let's wait on the outcome, assume you can then reassign it back to procps 19:55:40 #topic migration excuses 19:56:16 linux/6.12.29-1 is blocked due to the loop regression affecting live images, plan to do an upload based on 6.12.30 (since the next rounds will be big) 19:56:46 linux/6.15 for experimental, if nobody objects will do an experimental upload or do you want to include more of the hook and ABI related changes first? 19:57:06 no objection 19:57:08 (sorry topic should have been correct) 19:57:16 The latest iproute2 had a test regression for systemd, but bluca is apparently handling that on the systemd side 19:57:42 ack 19:58:09 so time is over, let's move to AoB 19:58:14 #topic AoB 19:58:25 nothing from me 19:58:29 I think it's my turn to chair next week? 19:58:37 We should probaby reply to "Inquiry About Submitting Chip Support Patches for Debian Kernel 19:58:40 ukleinek: it would be a jitsi one ;-) 19:58:49 which was sent to the list 10 days ago 19:59:01 bwh: ah, yes, there was something 19:59:15 bwh: ah right, I lost track of it after seeing it 20:00:05 * ukleinek still intends to look into https://salsa.debian.org/kernel-team/linux/-/merge_requests/1337 20:00:19 I think the answer just needs to explain the policy of only applying patches that are already in a subsystem maintainer tree 20:00:20 i would reject the request, but provide guidance on providing something patched 20:00:25 * ukleinek eyes his todo list and doesn't promise to get to all that until next week 20:00:43 i'll answer 20:00:48 Thanks 20:00:50 waldi: thanks 20:01:02 #action ukleinek will chair next week and now call it a day 20:01:06 #action waldi to answer to "Inquiry About Submitting Chip Support Patches for Debian Kernel" 20:01:20 #action waldi follows up on the email on list about ""Inquiry About Submitting Chip Support Patches for Debian Kernel" 20:01:24 oh well :) 20:01:33 #endmeeting