19:00:09 <ukleinek> #startmeeting
19:00:09 <MeetBot> Meeting started Wed Sep 17 19:00:09 2025 UTC.  The chair is ukleinek. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:09 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:21 <ukleinek> #char bwh carnil waldi
19:00:27 <ukleinek> #chair bwh carnil waldi
19:00:27 <MeetBot> Current chairs: bwh carnil ukleinek waldi
19:00:39 <waldi> hi
19:00:42 <carnil> hi
19:00:48 <yunseongkim[m]> hi
19:00:57 <ukleinek> great, we have a long bug list, so let's start.
19:01:08 <kathara> hello
19:01:16 <ukleinek> Anything to talk about before going through the list?
19:02:13 <waldi> i had something, but forgot…
19:02:37 <ukleinek> ..ooOO(Haddu Kopf wie Sieb, muddu aufschreiben! :-)
19:02:54 <waldi> easier said than done
19:03:33 <ukleinek> #topic #1111184
19:03:51 <carnil> so the reporter said here he would be not in position of bisecting
19:04:06 <carnil> but we really would love to have that information :-/
19:04:07 <ukleinek> then the bug isn't actionable for us?
19:05:01 <ukleinek> Not sure I understood the excuse. "disk is not be in good"?
19:05:02 <carnil> I would thus propose to really mark it "done" with 6.13.2-1~exp1, maybe tag it unreproducible and keep moreinfo
19:05:30 <ukleinek> sounds sensible
19:05:42 <ukleinek> carnil: would you care?
19:05:47 <carnil> my undeterstanding is that reporter fears the system is not sized enough for compiation times
19:05:51 <carnil> ukleinek: yes I take care
19:05:58 <waldi> why is this considered amdgpu related?
19:06:04 <waldi> module_address_lookup is module loader
19:06:40 <ukleinek> "Modules linked in: amdgpu(+)" means the amdgpu module is currently loading, right?
19:06:47 <bwh> Hi, I am now seated with my laptop
19:06:54 <ukleinek> bwh: welcome!
19:07:06 <carnil> #action carnil takes care to followup on #1111184 fixup of metadata (closing in 6.13.2-1~exp1), tag unreproducible and interact with reporter trying to understand why bisection not possible
19:07:07 <waldi> yes. but inside the module loader, not inside amdgpu code. and radiondrm is also loaded
19:07:12 <bwh> (and a beer, and with pizza on the way)
19:07:14 <carnil> bwh: welcome
19:07:36 <waldi> no idea
19:08:14 <ukleinek> waldi: if amdgpu isn't involved it doesn't change much
19:08:41 <ukleinek> #topic #1102175
19:09:14 <ukleinek> Just popped up due to spam, I already reported that through the respective link
19:09:24 <bwh> OK, so let's move on
19:09:28 <ukleinek> #topic #1106498
19:09:44 <ukleinek> Last action was carnil pinging the moreinfo
19:10:11 <carnil> yes I did that for some older bugreports with moreinfo tagging so we can decide to either close or maybe get the reuqested moreinfo.
19:10:19 <carnil> (thus the list got bit longer as usual)
19:10:44 <bwh> OK, but we can skip those bugs quickly if no info received yet
19:10:54 <ukleinek> The ping is from Saturday, IMHO we should wait a bit longer before closing
19:11:01 <bwh> yes
19:11:05 <carnil> ok
19:11:06 <ukleinek> #topic #1106668
19:11:25 <ukleinek> no relevant new info, reporter ask for some patience
19:11:36 <ukleinek> #topic #1108082
19:12:01 <ukleinek> same as before: carnil pinged, no reporter feedback yet, let's wait a bit longer
19:12:08 <bwh> right
19:12:09 <carnil> ok
19:12:10 <ukleinek> #topic #1108168
19:12:55 <bwh> This is still on me to follow up, sorry
19:12:57 <ukleinek> again spam triggered, but bwh's action from the meeting in July is still open I think
19:13:42 <ukleinek> bwh: so this made it back onto your todo list and we go to the next bug, right?
19:13:48 <bwh> OK
19:13:50 <ukleinek> #topic #1112288
19:14:13 <ukleinek> That one is for us to act again, the reporter provided some logs
19:14:43 <ukleinek> carnil handled the bug before
19:14:52 <bwh> But carnil is a very busy man...
19:15:19 <bwh> I can take an action to look at the logs
19:15:19 <carnil> well no I just aksed that we might be able to chime in by providing the two boot logs :)
19:15:42 <carnil> ack bwh that would be great
19:16:13 <ukleinek> #action bwh compares the boot logs from #1112288 and follows up
19:16:25 <ukleinek> #topic #1112627
19:16:57 <ukleinek> Reporter informed that newest 6.16.x is also broken, but the bisection is still open to do.
19:17:18 <bwh> So let's leave it with them
19:17:27 <ukleinek> We could either just wait or make it explicit again that this is still open
19:17:34 <ukleinek> waiting it is then
19:17:41 <carnil> attention it's not the same one who replied last who is the reporter, but baseline remains: Francesco wanted to find time to do the bisection.
19:17:41 <ukleinek> #topic #1113861
19:18:06 <ukleinek> that one is stuck on upstream
19:18:33 <carnil> no replies on upstream thread so far
19:18:43 <ukleinek> I wonder if that would be easily reproducible for one of us, but not sure that helps a lot.
19:18:54 <bwh> Is it better to report nouveau bugs on the mailing list or in a bug tracker?
19:19:06 <ukleinek> idk
19:19:54 * ukleinek forwarded that question to #dri-devel
19:20:05 <bwh> Thanks
19:20:35 <ukleinek> medium optimistic only that this brings us forward, but I stay open
19:21:20 <carnil> MAINTAINERS file has for DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS
19:21:35 <carnil> so maybe I did mislead the reporter to fill to the wrong place since the entry has
19:21:38 <carnil> B:      https://gitlab.freedesktop.org/drm/nouveau/-/issues
19:22:32 <bwh> Well let's see what the people on #dri-devel  say
19:22:36 <ukleinek> :-\, maybe wait a bit longer and on feedback in #dri-devel or no feedback on the bug on the list, bounce to the bugtracker.
19:22:46 <ukleinek> #topic #1114557
19:23:20 <ukleinek> #action ukleinek to watch #dri-devel for #1113861
19:23:26 <carnil> yes here we are waiting for the second part (i.e. the other device with same id's to report back information)
19:23:40 <carnil> -> wait
19:23:51 <ukleinek> ack
19:23:58 <ukleinek> #topic 1114806
19:24:01 <bwh> I don't think this should be "moreinfo", as the info is requested from another user who prompted the breaking patch
19:24:17 <bwh> That was for #1114557
19:24:33 <bwh> Shall I untag it?
19:24:53 <ukleinek> ah, is moreinfo only for requests from the reporter? Then yes
19:25:00 <carnil> I would say so, if ukleinek agrees
19:25:11 <bwh> That is what I understood it to mean
19:25:16 <ukleinek> fine for me
19:25:46 <bwh> done
19:25:46 <ukleinek> #1114806 should be fixed with 6.16.8, so nothing to do for now
19:26:02 <carnil> \o/ this is pending for the next 6.16.y
19:26:23 <ukleinek> #topic #1114884
19:26:47 <ukleinek> kathara: That's a bug that might be suiteable for you to act if you want
19:27:06 <ukleinek> It's a regression between 6.1.140-1 and 6.1.148-1.
19:27:50 <kathara> okkeii
19:28:13 <ukleinek> We'd need some more details about the exact error message, if need be just a photo, and the reporter could test 6.1.147-1 to further limit the commits that resulted in the bug
19:28:49 <bwh> Since the root filesystem check appears, it should also be possible to use the initramfs rescue options
19:28:55 <ukleinek> kathara: If you feel unsure, feel free to just formulate a reply and send it to me for review
19:29:32 <ukleinek> bwh: do you have a doc link handy for those?
19:29:39 <bwh> man initramfs-tools 7
19:29:51 <kathara> got it. will look into this
19:30:19 <ukleinek> #action kathara will reply to #1114884, ukleinek ready to assist
19:30:31 <ukleinek> kathara: thx!
19:30:35 <ukleinek> #topic #1114912
19:30:42 <ukleinek> that one is new
19:31:57 <ukleinek> This might be easily reproducible, though I don't know how to do GPU passthrough
19:32:24 <carnil> if the reporter feels confident: then it would be great to narrow down first the debian version range of introducing the issue and then bisect the changes. While searching the regression list I have not found a similar report.
19:33:15 <ukleinek> ah right, it's a regression from debian12
19:33:20 <bwh> I'm confused as to how there are log messages listing both vfio-pci and amfgpu as drivers
19:34:22 <ukleinek> two graphic cards maybe?
19:34:24 <bwh> Anyway the oops is in generic vfio  code so it might be worth trying to reproduce with some other PCI device...?
19:34:35 <bwh> ukleinek: No, I mean a single line lists both driver names
19:35:55 <ukleinek> vfio-pci is used on 03:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 HDMI/DP Audio [1002:ab30] according to the pci dev list
19:36:14 <bwh> That actually makes me think that amdgpu could be accessing the device after it has been unbound
19:36:28 <waldi> and the error messages are clearly from amdgpu
19:36:45 <waldi> yes
19:36:54 <bwh> So the generic dev_printk() logs the bound driver "vfio-pci" and amdgpu logs its own name after the device address, which would normally be redundant but is an admission of its crimes here
19:37:02 <ukleinek> ah right, that's a devinfo from the amdgpu driver
19:37:38 <ukleinek> might already be good enough to forward to upstream then?
19:37:41 <waldi> complete log might be useful
19:37:58 <bwh> agreed
19:38:14 <waldi> and forward to upstream. amdgpu seems to be unable to unbind the device
19:38:51 <ukleinek> if unbinding amdgpu already is a problem, that might simplify the reproduction
19:39:08 <bwh> yes
19:39:48 <ukleinek> #action ukleinek asks for full logs and if unbinding already shows a problem. Depending on outcome forwards upstream
19:39:54 <ukleinek> #topic #1114930
19:39:58 <ukleinek> That's also a new one
19:41:47 <waldi> those h2c commands are firmware uploads, aka the device is not in a state the kernel expects it to be
19:41:54 <ukleinek> I suggest to ask the reporter to take this upstream
19:42:11 <ukleinek> Given "The problem disappeared after disabling the power saving mode of the
19:42:14 <ukleinek> Wi-Fi adapter."
19:42:17 <waldi> yes
19:42:43 <bwh> Well that should be a mailing list, so we can forward it, right?
19:43:02 <waldi> linux-wireless@vger.kernel.org
19:43:06 <yunseongkim[m]> I saw the similar on issue in https://github.com/lwfinger/rtw88/issues/116
19:43:16 <yunseongkim[m]> s/on//, s/in/on/
19:43:50 <ukleinek> but that's an oot driver?
19:43:54 <bwh> Seems like a similar symptom but a different problem
19:44:22 <ukleinek> (Also lwfinger won't help us, RIP)
19:44:33 <weepingclown[m]1> my bluetooth actually has similar issues on trixie, maybe I should dig deeper
19:44:37 <bwh> ukleinek: If I remember correctly, Larry Finger was both the in-tree maintainer and maintained OOT drivers based on upstream (i.e. backports)
19:45:01 * ukleinek only knew the OOT part
19:45:10 <bwh> Let me take an action to forward this upstream
19:45:37 <ukleinek> #action bwh forwards #1114930
19:45:54 <ukleinek> #topic #1115002
19:46:12 <ukleinek> IMHO not urgent and pending for 6.16.8
19:46:31 <carnil> I downgrated this to important, as the serious part applies only to 6.17-rcX in my understanding
19:46:39 <carnil> and the bugfix itself is pending as you said
19:46:40 <ukleinek> (The reporter read about that commit on phoronix and thought it a good idea to get it fixed)
19:47:04 <ukleinek> #topic #851404
19:47:08 <carnil> I think it's okay to wait for 6.16.8 and close the bug with it
19:47:18 <ukleinek> ack
19:47:33 <ukleinek> #851404 is another old bug that carnil pinged, without reply so far
19:47:44 <ukleinek> => wait till next week at least
19:47:48 <bwh> right
19:47:50 <carnil> ok
19:47:58 <ukleinek> #topic #919350
19:48:07 <ukleinek> bwh created a MR for that one
19:48:30 <ukleinek> => https://salsa.debian.org/kernel-team/linux/-/merge_requests/1573
19:48:31 <bwh> I suppose I need to rebase that
19:49:05 <ukleinek> Should we backport to 6.12 after merge to d-latest?
19:49:22 <carnil> it has already labels, but we first want it in debian/latest
19:49:48 <KGB> 03linux 05debian/latest 06Ben Hutchings * [update] merge request !1573: hyperv-daemons: Fix and install the sample network info scripts * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/1573
19:49:55 <ukleinek> ah right
19:49:56 <bwh> #action bwh will rebase linux!1573
19:50:18 <ukleinek> #action #988688
19:50:29 <bwh> .#topic ?
19:50:38 <ukleinek> #topic #988688
19:50:45 <ukleinek> bwh: indeed
19:50:55 <ukleinek> yabtcp (yet another bug that carnil pinged)
19:51:10 <carnil> yes because JOnathan said after trixie release he will try to debug :)
19:51:21 <carnil> so it was time to ping :)
19:51:36 <ukleinek> #topic 1014299
19:51:44 <ukleinek> yabtcp
19:51:58 <ukleinek> #topic #1100105
19:52:23 <ukleinek> interesting new info: While 6.6.x was ok so far, 6.6.106 is broken
19:52:43 <ukleinek> So either the reporter was lucky so far with older 6.6.x, or the breaking change was backported
19:52:51 * ukleinek will take a look
19:53:22 <ukleinek> #action ukleinek researches details about involved commits for the new info and take the appropriate action then
19:53:36 <ukleinek> #topic #1107785
19:53:56 <ukleinek> another old bug that got on the list due to spam (also already reported)
19:54:14 <ukleinek> I think we're waiting on upstream for that one
19:54:26 <bwh> I think I may need to prod upstream again about this. But it seems like it is architecturally difficult to solve
19:54:59 * ukleinek nods
19:55:29 <ukleinek> #action bwh to prod upstream about #1107785 again
19:55:34 <ukleinek> #topic #1108889
19:55:56 <ukleinek> That one was reported against a non-existant package and got reassigned to us.
19:56:25 <ukleinek> Before the reassign the reporter wrote that with a newer installer (and so I guess a newer kernel) the problem went away
19:56:31 <ukleinek> So just close?
19:56:33 <waldi> last message was: works now. so close
19:56:46 <carnil> +1
19:56:57 <bwh> I'll do it right now
19:57:05 <ukleinek> #topic #1110193
19:57:42 <ukleinek> here the reporter also wrote that the problem is gone. If nobody feels like finding out what actually fixed it, we can IMHO also just close it.
19:58:24 <carnil> ukleinek: tend to agree, I suspect otherwise we keep that open indefintively
19:58:40 <carnil> reporter is happy, we cannot find out more -> close
19:58:45 <bwh> right
19:59:03 <bwh> #action bwh will close #1110193
19:59:12 <ukleinek> #topic #1111027
19:59:23 <ukleinek> Bug is also reproducible with updated BIOS
20:01:38 <ukleinek> However there is still "> [So Sep 14 01:46:29 2025] Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 04/04/2019
20:01:42 <ukleinek> " in the log?!
20:02:07 <carnil> well that is the newest bios version for that
20:02:12 <carnil> it was on a 2014 version before
20:02:20 <ukleinek> ah, right
20:02:21 <carnil> [Fr Sep  5 21:12:34 2025] Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 06/06/2014
20:02:40 <carnil> but so at least we know BIOS update to the latest available is not helping
20:02:47 <ukleinek> (the date stamps were just too similar for me during scrolling)
20:04:25 <ukleinek> 2a:*	f0 80 66 02 df       	lock andb $0xdf,0x2(%rsi)		<-- trapping instruction
20:04:34 <bwh> Should we suggest they try blacklisting hpwdt, as they mentioned the watchdog driver in the first message?
20:04:57 <bwh> ukleinek: Isn't that just the instruction after the mwait?
20:05:17 <carnil> bwh: message #20 contains that this apparently does not help anymore
20:05:20 <ukleinek> yes it is. I just pasted what decodecode told me
20:05:26 * ukleinek <- x86 clueless
20:05:27 <bwh> carnil: Oh never mind
20:06:39 <bwh> ukleinek: mwait is the modern x86 wfi equivalent (kind of)
20:07:03 <bwh> OK I have no idea what to suggest here
20:07:09 <ukleinek> +1
20:07:27 <carnil> same here :(
20:09:54 <ukleinek> Very little info to forward upstream, right?
20:10:18 <bwh> I don't even know which subsystem to forward to
20:10:31 <ukleinek> x86?
20:10:58 <bwh> Yes maybe
20:11:31 * ukleinek will ask tglx in #linux-rt (where often x86 stuff is discussed for a lack of a more specific channel)
20:11:57 <ukleinek> #action ukleinek reaches out to tglx if he has an idea for #1111027
20:12:02 <carnil> thank you ukleinek
20:12:10 <ukleinek> #topic #1113942
20:12:25 <carnil> I believe this is a duplicate of #1114806
20:12:44 <carnil> (after having seen the narrowed down range of versions and the initial logs)
20:13:16 <bwh> Sounds plausible, let's wait to see if the revert fixes it
20:13:44 <ukleinek> ah, the bug is already updated with that clue, great
20:13:53 * ukleinek suggests to call it a day now
20:14:02 <carnil> jupp, shoult I tag it moreinfo?
20:14:05 <bwh> Yes, I was about to say I need to go and catch a bus
20:14:10 <carnil> s/shoult/should/
20:14:30 <bwh> yes
20:15:08 <carnil> done
20:15:19 <ukleinek> (\o/ I didn't prepare much to many bug annotations)
20:15:27 <ukleinek> #topic AOB
20:15:50 <bwh> Several people here expressed gratitude for Debian and its kernel, so well done everyone
20:16:14 <ukleinek> bwh: sounds good, I wonder about the context
20:16:25 <carnil> oh very nice to hear :)
20:16:27 <ukleinek> ah, on that Rust conference?
20:16:35 <bwh> yes
20:16:51 <bwh> Well I have "Debian" on my badge so...
20:17:14 * ukleinek is ok with bwh getting all the fame
20:17:44 <carnil> we should bwh catch the bus :)
20:18:18 <ukleinek> Who will chair next week?
20:19:14 <carnil> so many voluneers :). If nobody else is available, I will do
20:19:38 <carnil> I will do
20:19:39 <ukleinek> carnil: thanks. You did it last week however and it's jitsi again
20:19:48 <carnil> yes I know thus I'm less happy :)
20:19:55 <carnil> I'm not good at jitsi meetings ;-)
20:19:59 <carnil> but I can improve
20:20:13 <ukleinek> I can do it again, too, I like chairing jitsi meetings better than irc
20:20:38 * ukleinek suspects that both waldi and bwh are gone
20:20:42 <carnil> :) we should have swap'ed then. Let's assign it to me so you do not have to do twice in a row
20:20:42 <ukleinek> #endmeeting