20:00:05 <waldi> #startmeeting
20:00:05 <MeetBot> Meeting started Wed Jan 28 20:00:05 2026 UTC.  The chair is waldi. Information about MeetBot at https://wiki.debian.org/MeetBot.
20:00:05 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:12 <carnil> \o
20:00:13 <carnil> hi
20:00:19 <waldi> #chair bwh carnil ukleinek
20:00:19 <MeetBot> Current chairs: bwh carnil ukleinek waldi
20:00:21 <ukleinek> o/
20:00:22 <bwh> Hi
20:00:32 <waldi> welcome to todays meeting
20:00:43 <waldi> anything we should discuss first?
20:01:23 <waldi> i did not manage to talk to the installer people about kernel-wedge and so on
20:01:32 <bwh> Do we want to discuss meeting at FOSDEM?
20:01:59 <waldi> i wont come, family managed to nmi
20:02:14 <ukleinek> ok, then it's only bwh and me
20:02:24 <bwh> Then we can discuss that 1:1
20:02:29 <ukleinek> +1
20:03:28 <waldi> if we have nothing else to discuss, let's look at some glorious bugs
20:03:37 <carnil> jupp
20:03:40 <waldi> #topic #1124400
20:04:04 <waldi> here we don't need to do anything, just wait for dracut upstream
20:04:18 <bwh> Is there a URL we can add as forwarded to?
20:04:33 <bwh> Oh, yes there is, so I'll do that
20:04:42 <carnil> should be https://github.com/dracut-ng/dracut-ng/issues/2071
20:05:11 <waldi> #topic #1123750
20:05:28 <bwh> I'
20:05:31 <waldi> also applied to stable, so will show up with the next update
20:05:33 <bwh> I've just marked that pending
20:05:53 <waldi> #topic #1124463
20:05:54 <carnil> I think that is released upstream, but note there were I think two more commits queued by Greg (today?)
20:06:17 <bwh> carnil: Correct but I think they are independent fixes
20:06:33 <carnil> we have more poeple here reporting this, mostly a one time occurence, there is a patch proposed upstream which Sundip wants to submit:
20:06:33 <bwh> sort of
20:06:46 <carnil> https://lore.kernel.org/all/CADVatmNzTyUAr8UBvm6pHFsKz8xZpqUXh5NQR641JXsCWaPg8g@mail.gmail.com/
20:07:15 <carnil> bwh: ack
20:07:32 <carnil> s/Sundip/Sudip/
20:07:48 <carnil> waldi: so I think we have to wait on some progress here
20:08:01 <carnil> but bad thing is that people are mostly not able to reproduce after seeing the issue
20:08:59 <bwh> Then we should tag it as unreproducible, shouldn't we?
20:09:59 <bwh> I've now done that
20:10:08 <waldi> good
20:10:09 <waldi> #topic #1125001
20:10:13 <carnil> okay
20:10:40 <ukleinek> #action ukleinek will look into src for #1124463
20:10:46 <bwh> I only see a contentless mail from the submitter since last week
20:10:57 <ukleinek> I suppose that is a ping
20:11:19 <carnil> yes a ping to upstream
20:11:29 <waldi> nothing to do for us
20:11:33 <ukleinek> upstream as in debian-loongarch?
20:11:42 <carnil> I asked earlier that they properly submit the patches upstream, since we won't pick them otherwise
20:12:57 <ukleinek> Binbin Zhou (from the vendor) was only Cc:d in #19, but not the pings
20:13:29 <carnil> ah then the ping was probably wrong, or just an intent to make a wider audience
20:14:11 <waldi> #topic #1125405
20:14:54 <ukleinek> patch under discussion it seems
20:14:55 <carnil> I can keep the action here, there is problem identified (and bisected/confirmed) and a upstream thread with patch (but not landed yet in mainline)
20:15:00 <bwh> I just added the patch tag to this
20:15:55 <bwh> but we have to wait for mainline to agree on the correct patch
20:15:57 <ukleinek> carnil: thanks for providing images
20:16:40 <waldi> #topic #1125980
20:17:13 <waldi> the submitter was asked if they could try to bisect upstream
20:17:49 <waldi> so nothing to do right now
20:18:08 * ukleinek nods
20:18:37 <waldi> #topic #1126015
20:19:18 <ukleinek> bwh understood the issue
20:19:24 <waldi> and patch is waiting
20:19:36 <waldi> #topic #1126090
20:20:00 <waldi> seems like this one is broken since 3.16
20:20:18 <bwh> That's a long time ago
20:20:28 <carnil> should we remove the moreinfo here since reporter followed up, even if information is bit scarce?
20:21:08 <bwh> OK
20:21:27 <ukleinek> forward upstream?
20:21:38 <bwh> Yes I think this should be forwarded upstream
20:22:15 <carnil> I think I should be able to perform that task, can do
20:22:32 <waldi> #action carnil to forward #1126090
20:22:39 <carnil> (we have a full kernel log as well in the previous message, that should help to make the proper report)
20:23:07 <ukleinek> 66fa12c571d35e3cd62574c65f1785a460105397 removed the raw1394 stuff
20:23:45 <bwh> Yes the whole firewire stack was rewritten then
20:24:08 <ukleinek> v2.6.37-rc1~131^2 from Sun Oct 10 00:12:20 2010 +0200
20:24:19 <bwh> I seem to remember some headaches for video team
20:25:10 <ukleinek> #action ukleinek looks into the stacktrace of #1126090
20:25:22 <waldi> #topic #1126149
20:26:00 <waldi> patch that enables a quirk available for testing
20:26:01 <ukleinek> 32 = EPIPE!?
20:26:59 <ukleinek> reporter has the action
20:27:12 <bwh> right
20:27:32 <waldi> #topic #1126433
20:27:44 <carnil> yes, I mean I'm not sure htis is the correct solution, but there is a similar reported issue which got fixed this way. If the reporter confirms I plan to forward it to upstream
20:28:10 <waldi> this one is new, but a bit sparse, no log at all
20:28:37 <ukleinek> if plugging in an usb device doesn't result in lsusb changing and nothing in dmesg, the device is broken?!
20:29:12 <ukleinek> (or the usb bus)
20:29:26 <bwh> It's possible there was some USB core change that affected this specific device
20:29:44 <bwh> anyway, I agree we should have a log from the broken kernel
20:30:01 <bwh> I can ask for that
20:30:19 <waldi> #action bwh to ask for log in #1126433
20:30:36 <waldi> #topic #1111011
20:30:40 <waldi> the binary bug…
20:31:35 <waldi> submitter was asked to test with 6.18
20:31:56 <ukleinek> ..ooOO(0b1111011 = 123, bad password)
20:31:58 <waldi> my 2 cents: where do you still find 100BASE-TX networks?
20:31:58 <bwh> right, and we are still waiting for that, so no action from us
20:32:23 * carnil nods
20:32:28 <waldi> i would never assume a reasonable current device would run stable with that
20:32:30 <ukleinek> ah, I imagined this to be a wifi device
20:32:57 <waldi> anyway
20:32:58 <waldi> #topic #1124756
20:33:33 <bwh> ukleinek: Realtek makes both 100s of subtly different Wi-Fi controllers, *and* 100s of subtly different Ethernet controllers
20:33:50 <ukleinek> that's strange, as Werner Sembach pointed out the two affected machines are very different
20:34:27 <ukleinek> bwh: "100s of subtly different controllers" is the only common thing? :-D
20:35:09 <ukleinek> reporter missed to answer my questions about the freeze
20:35:23 <bwh> So maybe the trigger for the hang is some user-space application, not a driver big
20:35:26 <bwh> *bug
20:35:37 <ukleinek> #action ukleinek hints reporter of #1124756 that there are still open questions
20:35:41 <waldi> but a device from last year runs stable on the oldstable kernel
20:36:00 <waldi> more likely missing a lot of stuff
20:36:22 <waldi> #topic #1125155
20:36:42 <waldi> there was a log provided
20:36:43 <ukleinek> 🙄
20:37:25 <carnil> ah good, removing the moreinfo tag
20:38:30 <carnil> we had a couple of amdgpu related such issues, I can with the full log try to map/match against the older ones
20:38:34 <carnil> but other ideas more than welcome
20:38:55 <carnil> user should as well at least update to 6.12.63-1
20:39:30 <bwh> I have no better ideas
20:39:34 <iam_tj[m]> I've been doing very low level debug work with amdgpu recently for a couple of firmware related issues; I'll take a look
20:40:13 <ukleinek> there are two messages `[drm] Initialized amdgpu 3.61.0` for two different pci devices. is that expected?
20:40:17 <ukleinek> iam_tj[m]: \o/
20:41:25 <iam_tj[m]> It looks like it make be a Crossfire setup; 0f:00.0 reports no CRTCs
20:41:35 <iam_tj[m]> s/make/may/
20:41:55 <waldi> #action iam to take a look at #1125155
20:42:41 <waldi> #topic #1126156
20:42:52 <ukleinek> what is recovery mode?
20:43:02 <bwh> iam_tj[m]: 0f:00.0 is an on-board device and 03:00.0 is a dGPU
20:44:02 <iam_tj[m]> bwh:  yes, just spotted that, possibly an APU
20:44:22 <bwh> ukleinek: Presumably the (recovery) option in the GRUB menu
20:44:48 <waldi> something that does not load some graphics stuff i would assume
20:45:06 <ukleinek> blacklisting the i915 might give insights
20:45:32 <bwh> It won't disable loading graphics, but it will not start the display manager
20:45:37 <waldi> (boah, the lspci output on current systems is soooo long)
20:45:54 <bwh> so, just fbcon and not a compositor actually using the GPU
20:46:17 <ukleinek> `blacklist microcode` in modprobe.conf, is that a sane idea?
20:46:49 <bwh> The microcode loader is built-in so who cares
20:47:08 <ukleinek> ok
20:47:47 <ukleinek> also testing kernels between linux-image-6.1.0-41-amd64 and linux-image-6.12.57+deb13-amd64 would be helpful
20:47:58 <bwh> yes I was about to say that
20:48:43 * ukleinek doesn't want to take more action with fosdem upcomming and my slides not being complete yet
20:48:52 <bwh> #action bwh will ask reporter of 1126156 to bisect
20:49:07 <ukleinek> thx
20:49:22 <waldi> #topic #1126280
20:50:22 <bwh> Just noticed the submitter's domain
20:50:23 <waldi> need the whole reportbug treatment
20:50:29 <carnil> are we lacking more detailed information on their application to actually do something here?
20:50:30 <waldi> yes, me too
20:50:34 <carnil> is it not better suited to upstream?
20:50:54 <bwh> yes I think this belongs on linux-rt-users (I think that's the list)
20:51:00 <ukleinek> ack
20:51:02 <waldi> sadly i can't longer look, but i have a hunch
20:51:17 <bwh> #action bwh will redirect 1126280 to linux-rt-users
20:51:22 <waldi> thx
20:51:30 <waldi> #topic #1126410
20:52:11 <ukleinek> ah, I promised to look into that, but failed up to now, I can keep the action
20:52:32 <waldi> #action ukleinek to look at #1126410
20:52:46 * ukleinek ctrl-u's what he just typed
20:53:01 <ukleinek> (as waldi did the same an was quicker)
20:53:08 <waldi> #topic #1126499
20:53:36 <waldi> new bug
20:53:43 <waldi> smells like a race condition
20:53:57 <carnil> briefly looked at this today to see if there is a upstream issue about it, found nothing so far, but was really just a brief loock
20:54:04 <waldi> test 6.18, forward upstream?
20:54:12 <bwh> right
20:54:16 <carnil> yes sound sensible
20:54:23 <ukleinek> yeah, I would expect that uptream understoods that quickly
20:54:29 * carnil raised hand if there is no other volunteer
20:54:48 <waldi> #topic carnil to handle #1126499
20:54:53 <waldi> #action carnil to handle #1126499
20:55:01 <waldi> #topic #1126431
20:55:06 <waldi> this is clear i think
20:55:08 <bwh> just marked this pending
20:55:12 <waldi> thx
20:55:14 <waldi> #topic AoB
20:55:25 <waldi> this brings us to the end. anything else?
20:56:03 * ukleinek shakes head
20:56:12 <ukleinek> (apart from needed a chair for next week)
20:56:12 <bwh> Re firmware-nonfree, I have pinged kathara and in any case will make an update by Sunday at the latest
20:56:14 <carnil> re linux vs dractut and unstable upload: as release-team blocked linux migration rightfully until dracut migrates to testing I have not done the promised 6.18.7-1 upload, so likely wait now for 6.18.8 instead
20:56:33 <waldi> okay
20:56:57 <waldi> and i completely forgot about SIGPIPE, again. it's such a weird error
20:57:06 <waldi> who wants to chair next week=?
20:57:07 <ukleinek> does newer linux need dracut > 109-5?
20:57:12 <bwh> I think it's my turn again
20:57:30 <waldi> #action bwh to chair next week
20:57:35 <waldi> thank you all for coming
20:57:43 <ukleinek> thank you for chairing
20:57:47 <waldi> #endmeeting