19:00:27 <carnil> #startmeeting
19:00:27 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:36 <carnil> Hello everybody
19:00:38 <waldi> hi
19:01:18 <carnil> #chair waldi bwh ukleinek
19:01:18 <MeetBot> Current chairs: bwh carnil ukleinek waldi
19:01:27 <carnil> So maybe we are two today :)
19:01:45 <carnil> is there anything we should put upfront before moving to the items of the agenda?
19:02:00 <bwh> Hi
19:02:07 <carnil> hi bwh
19:02:14 <waldi> i have nothing to discuss
19:02:47 <carnil> ok let's move straight to the bug list then, I tried to summarize the bugs
19:03:17 <carnil> #topic #1104327: amdgpu: after laptop resume, AMD graphics just shows large patterns on all terminals
19:03:43 <carnil> 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 <carnil> apparently it is a duplicate of several issues already reported upstream with only little activity
19:04:23 <carnil> I think we can 1. remove the moreinfo tag and then just wait that something happens upstream?
19:04:38 <carnil> Or does someone feel to investigate more this amdgpu related issue?
19:04:55 <ukleinek> o/
19:05:00 <bwh> I agree we can remove moreinfo
19:05:45 <carnil> bwh: so removed the moreinfo tag now. Question is if we can do something more for the reporter.
19:06:23 <bwh> I don't think so as no-one here is a GPU driver expert
19:06:33 <bwh> (AFAIK)
19:06:41 <carnil> I'm not :)
19:07:07 <carnil> then let's just wait, we have linked the upstream issue and can check before next meeting if something happened
19:07:27 <carnil> #topic #1106411: linux-image-6.12.27-amd64: kernel NULL pointer dereference in bmc150_accel_core
19:07:34 <ukleinek> +1, it's only 4 days old
19:07:47 <carnil> Asked for more information (full kernel log, and test with 6.1.129-1). Wait until getting response.
19:07:54 <bwh> OK
19:07:57 <carnil> ups, sorry typo, 6.12.29-1
19:07:58 * ukleinek nods
19:08:12 <waldi> ok
19:08:16 <carnil> and have quickly skimming over the upstream changes found nothing related.
19:08:27 <carnil> #topic #1106498: linux-image-6.1.0-37-amd64: Ouput sound disappeared after last update on Lenovo Yoga Laptop
19:08:36 <carnil> Not investigated. Observation from reporter that if doing power-off and on makes audio to be available again.
19:08:42 <carnil> Fails when rebooting the machine.
19:08:51 <ukleinek> sounds like a firmware issue
19:08:54 <carnil> Ideas? Involve linux-sound or alsa-devel? do we need more information?
19:10:27 <ukleinek> "SMBus is busy" smells like a device was busy during reset and failed to release the bus
19:10:34 <waldi> the device is not properly reset. see the smbus errors, which is on the "same" pci device
19:11:10 <bwh> I would suggest to check for a BIOS update
19:11:35 <ukleinek> if there is a proper i2c driver for that smbus bus, a bus reset might work
19:11:39 <bwh> I agree with waldi that this looks like an incomplete reset by the system firmware
19:12:26 <carnil> 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 <ukleinek> 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 <carnil> #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 <carnil> of course :)
19:13:47 <carnil> #topic #1106558: linux-image-6.12.22+bpo-amd64: Wifi module fails to load
19:14:00 <carnil> Logs provided but not full kernel logs. We should ask back again to provide those.
19:14:06 <bwh> carnil: Please include bug numbers in actions because otherwise it will be unclear in the summary
19:14:19 <carnil> Idea: Missmatch of kernel from bpo and firmware as issue?
19:14:34 <carnil> bwh: ups, you are right, sorry
19:15:01 <carnil> #action #1106498: ukleinek will ask the reporter to check for possible BIOS update
19:15:15 <bwh> It could be the outdated firmware package. I didn't read the log yet
19:15:24 <ukleinek> the logs are unusable
19:15:28 <waldi> carnil: and the nick needs to go in front, so meetbot can aggregate
19:15:41 <ukleinek> needs someone asking for the output of dmesg
19:16:10 <carnil> 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 <bwh> The "kernel logs" have no kernel messages at all
19:16:48 <carnil> #action carnil follows up again on #1106558 to make sure reporter can provide for real the kernel logs for further investigation
19:17:47 <carnil> 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 <carnil> next topic if you agree
19:17:57 <ukleinek> ack
19:18:10 <carnil> #topic #1106268: linux-image-6.12.29-amd64: amdgpu DMCUB errors and lockups new in v6.12.29
19:18:30 <carnil> 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 <carnil> so IMHO no action and just wait that the fixes land first in mainline and then in 6.12.y
19:18:48 <ukleinek> ack
19:19:05 <carnil> #topic #1106668: Waking up from suspend to RAM reproducibly leads to a hard freeze
19:19:26 <carnil> This is apprently **not** a regression in 6.1.140 as reporter say it has been present "for a few weeks"
19:19:47 <carnil> Reporter might be able to pingpoint the first Debian revision introducing the behaviour/issue
19:20:31 <ukleinek> the red message is unrelated
19:22:45 <ukleinek> 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 <bwh> Looking at the hardware information, this is a 2017 motherboard so not new and excitingly different
19:25:03 <bwh> 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 <bwh> ukleinek: See Documentation/power/basic-pm-debugging.rst
19:26:39 <carnil> ukleinek: would be very welcome
19:26:49 <bwh> (I actually mean pm_test rather than pm_debug)
19:27:09 <ukleinek> #action ukleinek to research pm debug options and suggest something for #1106668
19:27:34 <carnil> #topic #1100105: linux-image-amd64: Issues with Framework audio module
19:27:41 <carnil> more ideas are needed here as well
19:28:52 <carnil> Seems to work with Fedora's kernel AFIU
19:29:08 <carnil> Ubuntu kernel not tried
19:29:23 <ukleinek> I can follow up there, the guy didn't understand my instructions
19:29:39 <ukleinek> #action ukleinek follows up on #1100105
19:29:49 <bwh> 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 <carnil> 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 <bwh> Ah OK
19:31:46 <carnil> 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 <carnil> btw, thanks ukleinek
19:32:13 <carnil> #topic #1104745: gcc-15 ICE compiling linux kernel 6.14.5 with CONFIG_RANDSTRUCT
19:32:31 <carnil> fwiw, reporter managed to make a minimal reproducer in https://bugs.debian.org/1104745#50
19:33:01 <carnil> AFAIR, bwh assume you will still coordinate for this issue?
19:33:02 <bwh> Oh good
19:33:10 <ukleinek> 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 <bwh> It does use a gcc plugin
19:34:15 <bwh> so, the ICE can be caused by the plugin
19:34:18 <ukleinek> so the plugin might be at fault, too, AFAIU
19:34:57 <bwh> carnil: Yes I still take reponsibility to move this forward if doko stops responding
19:35:09 <waldi> and the plugin is provided by the kernel, so the kernel is responsiblöe
19:35:09 <carnil> ok thanks bwh
19:35:39 <carnil> #action bwh still takes repsonsibility for #1104745 to move this forward
19:35:58 <carnil> anything else to bring in on this?
19:36:11 <ukleinek> !next
19:36:22 <carnil> #topic #1106386: Bluetooth: btusb: Add RTL8851BE device 13d3:3601
19:36:46 <carnil> 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 <ukleinek> carnil: did you check that there is no driver for this device that we just don't enable?
19:37:40 <bwh> I don't see any match for 0x3601 in drivers/bluetooth
19:37:44 <carnil> ukleinek: no did not, I just only spotted the bug in the last hour before the meeting
19:38:02 <ukleinek> ah, there is a kernel patch that seems to work ...
19:38:06 <bwh> So I think this needs someone to write a proper patch
19:38:11 <ukleinek> ack
19:38:33 * ukleinek looks at his todo list and thinks one more works
19:38:46 <ukleinek> #action ukleinek writes a proper patch for #1106386
19:38:53 <bwh> You beat me to it
19:39:30 <ukleinek> bwh: you can if you want
19:39:35 <carnil> ukleinek seems to have lot of time next week ;-)
19:39:50 <ukleinek> medium
19:40:55 <carnil> would be done similar to 181a2631a3144cd79e40ec5c77e7153085310dd3 I guess
19:41:16 <ukleinek> carnil: indeed
19:41:43 <carnil> so either ukleinek or bwh will write a patch :) for now it's ukleinek
19:41:57 <carnil> #topic #1102518: linux-image-6.1.0-32-amd64: Microphone hotkey event stop working - Lenovo laptop
19:42:09 <ukleinek> that one sounds as if it needs a bisect
19:42:16 <carnil> this is one which needs actually some help to start debugging.
19:42:57 <ukleinek> I think it's normal that the key press doesn't show up in evtest
19:43:04 <carnil> 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 <carnil> so there was some confusion and reopened the bug in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102518#40
19:43:49 <bwh> It should not be tagged moreinfo
19:44:03 <bwh> (until someone sends further questions)
19:44:42 <carnil> let's remove it now. I failed to remove it after reporter did followup again
19:44:46 <carnil> done
19:45:34 <bwh> 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 <waldi> lenovo likes to do special keys via acpi
19:46:24 <bwh> Yes. But then the kernel turns them into regular input events
19:46:55 <ukleinek> 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 <bwh> Anyway the reporter says that there was an input event in some version
19:47:33 <ukleinek> (and if it appears in 6.1.129 it also should in later versions)
19:48:25 <ukleinek> 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 <bwh> right
19:49:10 <ukleinek> 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 <carnil> "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 <ukleinek> maybe a cold boot repairs it?
19:51:41 <KGB> 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 <ukleinek> I'd say: Let the reporter confirm that 6.1.129-1 is reliably good and then let him bisect.
19:52:14 <carnil> so we might ask if it make a different if it is cold booted or rebooted from running system?
19:52:17 <carnil> ukleinek: ok
19:52:33 <bwh> carnil: Yes, I think that's also worth doing
19:53:08 <carnil> 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 <carnil> #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 <carnil> 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 <carnil> #topic
19:54:23 <carnil> #1092550: (w, M) procps: Addback/Provide example of sysctl.d/*.conf like the old sysctl.conf under /usr/share/doc/
19:54:40 <carnil> is beeing handled, and think needs just an agreement that it can be put as example in procps?
19:55:04 <bwh> yes
19:55:27 <carnil> ok let's wait on the outcome, assume you can then reassign it back to procps
19:55:40 <carnil> #topic migration excuses
19:56:16 <carnil> 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 <carnil> 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 <bwh> no objection
19:57:08 <carnil> (sorry topic should have been correct)
19:57:16 <bwh> The latest iproute2 had a test regression for systemd, but bluca is apparently handling that on the systemd side
19:57:42 <carnil> ack
19:58:09 <carnil> so time is over, let's move to AoB
19:58:14 <carnil> #topic AoB
19:58:25 <waldi> nothing from me
19:58:29 <ukleinek> I think it's my turn to chair next week?
19:58:37 <bwh> We should probaby reply to "Inquiry About Submitting Chip Support Patches for Debian Kernel
19:58:40 <carnil> ukleinek: it would be a jitsi one ;-)
19:58:49 <bwh> which was sent to the list 10 days ago
19:59:01 <waldi> bwh: ah, yes, there was something
19:59:15 <carnil> 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 <bwh> 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 <waldi> 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 <waldi> i'll answer
20:00:48 <bwh> Thanks
20:00:50 <carnil> waldi: thanks
20:01:02 <ukleinek> #action ukleinek will chair next week and now call it a day
20:01:06 <waldi> #action waldi to answer to "Inquiry About Submitting Chip Support Patches for Debian Kernel"
20:01:20 <carnil> #action waldi follows up on the email on list about ""Inquiry About Submitting Chip Support Patches for Debian Kernel"
20:01:24 <carnil> oh well :)
20:01:33 <waldi> #endmeeting