19:00:28 <bwh> #startmeeting
19:00:28 <MeetBot> Meeting started Wed Sep 24 19:00:28 2025 UTC.  The chair is bwh. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:28 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:40 <ukleinek> o/
19:00:49 <waldi> hi
19:01:19 <carnil> hi
19:01:58 <bwh> No-one replied to the agenda mail, so let's go straight into the bug list
19:02:10 <bwh> #topic Bug #1111184: (S, uM) linux: Kernel panic on boot with amdgpu driver
19:02:13 <kathara> helloo
19:02:14 <yunseongkim[m]> Hi
19:02:46 <carnil> you summarized it well. We agreed last time to close it with the version. mentioning that we really need to be able to bisect to solve it as well for trixie
19:02:54 * ukleinek nods
19:03:03 <carnil> I added corresponding tags so it sould be kept unarchived until as well fixed in trixie
19:03:08 <bwh> Right, so there is nothing we can do about this without someone else with an affected system doing that
19:03:36 <bwh> #topic #1107953: (i, ) linux: objtool fails after reporting a warning
19:03:36 <carnil> asked what reporter means with "bad disk" maybe it's a understanding on what is needed to do the bisection (and various compilations)
19:03:54 <bdrung> carnil, iam_tj[m], I filed bug #1116251 for it
19:04:08 <bwh> I think we can just close it as the bug is in the proprietary modules, not anything we maintain
19:04:19 <bwh> and they are fixed so no need to reassign
19:04:26 <ukleinek> I don't understand ab in #1107953. Does the last message say the problem is addressed?
19:05:22 <bwh> That was my reading
19:05:42 <ukleinek> ok
19:06:07 <bwh> #action bwh will close #1107953
19:06:17 <bwh> #topic #1111095: (i, ) firmware-amd-graphics: Radeon HD 8280 : gpu lock, black screen and crash.
19:07:06 <bwh> ukleinek: You asked for information here. Has the reporter answered your questions?
19:07:46 <ukleinek> the last message is definitively new and surprising
19:08:13 <ukleinek> 6.1.x now also crashes despite this was a regression bookworm -> trixie originally.
19:08:46 <ukleinek> #action ukleinek continues to care for #1111095
19:08:57 <carnil> can it be hardware dying then? Unless the regression was backported to newer 6.1.y series as well
19:09:18 * ukleinek doesn't grasp all the details now, will check the versions involved and probably ask more questions
19:09:21 <bwh> I did wonder if it could be hardware, yes
19:09:23 <bwh> Thanks
19:09:38 <bwh> #topic Bug #1111455: (i, M) linux-image-6.12.41+deb13-amd64: kernel BUG at fs/netfs/read_collect.c:316 netfs: Can't donate prior to front
19:10:22 <bwh> We are waiting on the reporter, so no action needed?
19:10:25 <ukleinek> ack
19:10:30 <carnil> upstream thread, with no reply so far (including Max Kellermann, which did some fixes already)
19:10:51 <carnil> will keep an eye on it as I'm in the loop as well in upstream thread
19:11:02 <bwh> Thank you
19:11:04 <carnil> but we really need as well an update from reporter
19:11:10 <bwh> #topic Bug #1114557: (i, +u) linux-image-6.12.43+deb13-amd64: Jieli touchscreen and stylus no longer supported
19:11:30 <carnil> #action carnil continues to take care of #1111455
19:11:55 <carnil> there is a proposed patch as you noted already, but did not land yet
19:11:56 <bwh> For #1114557 I think we are just waiting on upstream to accept or reject the patch
19:12:01 <carnil> yes
19:12:20 <bwh> #topic #1114884: (i, M) linux-image-6.1.0-39-amd64: AMD Ryzen 9 7950X, linux-image-6.1.0-39-amd64 hangs on boot while 6.1.0-37-amd64 works fine
19:12:31 <carnil> one side has been tested (our reporter, but needs as well test with the original hw which caused the commit regression)
19:12:46 <carnil> heh you are to fast for me today :)
19:13:19 <bwh> Sorry
19:13:33 <bwh> We just have a lot of bugs...
19:14:03 <carnil> kathara: there was  followup just today, asking how to get 6.1.147-1
19:14:06 <ukleinek> kathara: do you want to continue to care for that bug?
19:14:13 <carnil> kathara: the user can fetch the version from snapshot.debian.org
19:14:33 <ukleinek> kathara: If yes we can discuss separately
19:14:47 <kathara> ukleinek:  yes i will
19:15:12 <ukleinek> #action ukleinek and kathara arrage to reply to the reporter of #1114884
19:15:27 <bwh> #topic Bug #1114912: (i, ) linux-image-amd64: KVM GPU passthrough causes kernel crash and system hang on Debian 13 after VM shutdown
19:15:30 <ukleinek> kathara: thx <3
19:15:52 <bwh> ukleinek: Did the reporter provide the information you asked for here?
19:16:10 * ukleinek wonders why he is not aware of all the replies, either I missed mails or the replies didn't go to him
19:16:26 * ukleinek rolls eyes about "Please find below a summary(by AI)"
19:16:49 <ukleinek> #action ukleinek will go through news about #1114912 and reply
19:16:53 <waldi> but we where right. amdgpu did not properly release the device before vfio got it
19:17:11 <bwh> waldi: Seems like it, yes
19:17:32 <bwh> #topic Bug #1115581: (i, ) linux-image-6.16.3+deb14-rt-amd64: Boot hang with Creative Sound Blaster AE-7 [1102:0010]
19:18:26 <bwh> Right at the bottom there's a call trace with some snd_hda functions in it
19:18:41 <ukleinek> might also be a generic pci problem
19:19:01 <ukleinek> (that is not a bug in the sound driver, but the pci bus (driver))
19:19:03 <bwh> Yes there seem to be multiple problems logged
19:19:54 <ukleinek> some prose about how that problem started would have been nice
19:20:21 <ukleinek> it's an rt kernel, maybe ask to reproduce with the default kernel
19:21:07 <ukleinek> #action ukleinek will ask the reporter of #1115581 to reproduce with a non-rt kernel
19:21:09 <carnil> was going to propose the same about rt kernel, plus when getting fresh log test 6.16.8-1
19:21:27 <ukleinek> carnil: still to slow :-)
19:21:51 <waldi> BadTLP, aka checksum errors. so not correct seated device?
19:22:13 <ukleinek> waldi: will consider that question
19:22:24 <bwh> #topic Bug #1115596: (i, ) linux-image-6.16.7+deb14-amd64: kernel NULL pointer dereference in nouveau when firmware could not have been loaded
19:23:00 <ukleinek> sounds ready to forward upstream
19:23:13 <bwh> Yes I agree
19:24:12 <ukleinek> #action ukleinek forwards #1115596 upstream after a look into the source if he spots the issue
19:24:24 <carnil> wait I think this could be duplicate
19:24:33 <carnil> #1113861
19:24:49 <carnil> we forwarded thtat upstream, with no reply so far and the backtrace is similar
19:25:24 <ukleinek> #action ukleinek forwards #1115596 upstream after a look into the source if he spots the issue and checking if it's related to #1113861
19:25:45 <bwh> carnil: And the initial message on that one has firmware-nvidia-graphics  not installed
19:26:09 <ukleinek> which supports that suspicion, right?
19:26:36 <bwh> yes, and we probably should have noticed that earlier, but oh well
19:27:31 * ukleinek thinks it's ok to miss that
19:27:52 <carnil> so should we merge the both bugs?
19:27:57 <ukleinek> #action ukleinek will merge #1115596 and #1113861 on the way
19:28:47 <carnil> we can followup on https://lore.kernel.org/dri-devel/E79B534D-6630-4AF3-950D-2391CDABCE16.1@smtp-inbound1.duck.com/ with additional new knowledge
19:29:20 <bwh> #topic Bug #1115613: (i, +M) linux: Please enable CONFIG_SOUNDWIRE_AMD=m
19:29:29 <ukleinek> carnil: that is the forward of the latter bug, right
19:29:34 <carnil> ukleinek: yes
19:29:40 * ukleinek nods
19:29:57 <carnil> bwh: maybe I was too strict here, but asked for confirmation that enabling it is enough to add the desired support
19:30:06 <carnil> maybe enabling the module per se on its own is as well already okay
19:30:22 <ukleinek> that's my thought
19:30:48 <bwh> Given that sound usually depends on multiple drivers, I think it's reasonable to ask for a test so we don't close the bug prematurely
19:31:10 <carnil> ok so let's wait for the confiramtion, MR is ready
19:31:11 <bwh> But the MR may be worth merging even before that
19:31:35 <ukleinek> or we close with the MR and rely on the reporter to wail if a problem remains?!
19:32:05 <ukleinek> folks who is unlucky tends to be more reliable when it's about giving feedback
19:32:09 <carnil> a closed bug is better than one waiting indefintively with moreinfo :)
19:32:09 <bwh> That doesn't seem quite right, given we asked to test
19:32:19 <carnil> but let's wait for the test result IMHO
19:32:29 <carnil> reporter promised to do
19:32:37 <bwh> So no action needed right now
19:32:44 * carnil nods
19:32:44 <bwh> #topic Bug #1115715: (i, ) linux: Should warn much more prominently when initrd generation failed
19:32:57 <ukleinek> keeping the bug on the agenda somewho would be great
19:33:40 <bwh> I would like to take this, and first find out how the system gets unbootable
19:34:23 <bwh> Yhe kernel positnst hooks should be ordered so that there is no update to the boot loader config if an initramfs build fails
19:34:49 <ukleinek> sounds like a sensible first step that should be easily doable
19:36:22 <carnil> ack, bwh if you have spare cycles please take it, it is on the right place
19:36:57 <bwh> #action bwh will handle #1115715
19:37:09 <bwh> #topic #1116065: (i, Mu) linux: kernel oops with rsync on MSI X99A (regression since 6.12)
19:37:56 <bwh> If the reporter can't provide the necessary information I think we might just have to close this?
19:38:33 <carnil> I fowarded one additionall reply I got privately again, but it's still not what we want (full log)
19:38:51 <ukleinek> if that was my maschine, I'd do a memory test as first step
19:39:15 <ukleinek> that should be easy to do for the reporter
19:40:38 <bwh> Yes that might be worthwhile
19:40:54 <carnil> ok I can followup with that, and sitll try to get full logs
19:40:57 <iam_tj[m]> Reporter says they ran memtest86+
19:41:10 <ukleinek> good catch
19:42:04 <carnil> and
19:42:11 <iam_tj[m]> I suspect cache leak causing eventual exhaustion - reporter states its with very large data (local storage to remote)
19:42:36 <carnil> reporter say as well that they tested again 6.1.x, and there is no problem triggered
19:43:19 <iam_tj[m]> I would recommend they look for an updated PC UEFI since it shows the data as 2016... likely to be a newer release
19:43:29 <iam_tj[m]> s/data/date/
19:43:43 <ukleinek> carnil already pointed that out
19:43:55 <iam_tj[m]> Ahhh - tunnel vision here :)
19:44:23 <bwh> Shall I take an action to look at this?
19:45:01 <carnil> ok
19:45:11 <bwh> I can't promise to find anything more from this rather limited log though
19:45:30 <ukleinek> maybe the reporter just needs a hint about how to extract a full bootlog?
19:45:33 <bwh> #action bwh will attempt to make sense of log in #1116065
19:45:44 <ukleinek> thx bwh
19:45:49 <bwh> ukleinek: I think they may just be being secretive
19:45:58 <carnil> well I gave hints there as well, asked if the system is not accessible to try a netconsole for instance
19:46:04 <bwh> #topic Bug #1100105: (n, M) linux-image-amd64: Issues with Framework audio module
19:46:59 <ukleinek> I would hope that Richard understood my suggestion and does it though that's not in his latest mails
19:47:23 <bwh> ukleinek: How did you come up with doing a bisect with an unequal split?
19:48:09 <ukleinek> bwh: I don't understand the question. Where the idea is from? It's my genuine idea from similar issues
19:48:54 <ukleinek> that's making is somewhat more likely to have a test case that is decidable (at the cost of an unoptimal split)
19:49:34 <bwh> OK, I wondered if this was a documented technique
19:49:57 <bwh> Not objecting, just curious
19:50:26 <ukleinek> I'm not aware of a documentation for my approach or an alternative source.
19:50:40 <ukleinek> I think it's the first time I shared it
19:50:41 <bwh> Do you think this can be left to the reporter now, or should we do something additional?
19:51:20 <ukleinek> #action ukleinek pings #1100105 about progress and needed help
19:51:28 <bwh> thank you
19:51:38 <bwh> #topic Bug #1111027: (n, u) linux-image-6.12.38+deb13-amd64: HP Gen8: Crashing with 6.12 from trixie, NMI error in IML logs
19:52:13 <bwh> I think we can leave this to the reporter and upstream developers for now...
19:52:16 <ukleinek> I'm very happy with that bug. Tglx provided some input that seems valuable
19:52:43 <ukleinek> ack for letting them sort out the details
19:52:59 <bwh> #topic Bug #1113942: (n, M) linux-image-6.16.3+deb14-amd64: Fails to suspend
19:53:50 <ukleinek> no action needed IMHO
19:53:55 <bwh> agreed
19:53:56 <carnil> bwh: maybe i can follow up directly stating that the version is now available in the archive and to please test it
19:54:02 <bwh> OK
19:54:13 <carnil> I'm still convinced it is the dublicate, so if we can close it that would be great
19:54:39 <carnil> #action carnil follows up on #1113942 to now request explicitly 6.16.8-1 as available in the archive
19:54:42 <bwh> #topic Bug #1114642: (n, M) acpi: ThinkPad X1 Yoga: inconsistent/zero energy-full-design values for internal battery
19:55:54 <bwh> I think we can just keep waiting on the reporter
19:56:15 <carnil> ack
19:56:25 <bwh> #topic #1114695: (n, ) System not booting with Debian 13 Live ISO (GNOME) and after upgrading from Debian 12
19:56:28 <ukleinek> given that 6.16.7 seems to be good, closing might be another option if the reporter doesn't want to do the testing
19:56:50 <ukleinek> what is IBT?
19:57:38 <bwh> Indirect Branch Tracking. It's a control flow integrity thing.
19:58:10 <ukleinek> that's a security feature?
19:58:38 <bwh> yes, that is supported by some x86 CPUs
19:59:10 <bwh> but the last 4 messages are not from the original reporter, so who knows if there is any connection
19:59:44 <ukleinek> John Doe might just be a cloak for the original reporter
20:00:18 <ukleinek> hmm, different timezone though
20:00:21 <carnil> > I have the same device with Intel i5-1235U, but the model is B1402CBA.
20:00:24 <waldi> but it talks about a firmware upgrade and the problem starting after
20:00:28 <carnil> I would say they are two different persons
20:01:00 <waldi> yes. the firmware have the same version ranges however
20:01:57 <bwh> I have no idea what to do with this report
20:01:58 <ukleinek> a firmware issue sounds likely
20:02:55 <bwh> The "John Doe" report though might be related to the firmware not supporting IBT and the kernel failing to disable it around some firmware call
20:03:05 <ukleinek> ask the original reporter if disabling IBT helps them, too?
20:03:43 <bwh> I don't think that makes sense. We have no reason to think these are the same issue
20:04:23 <waldi> we have. mostly identical devices, identical firmware release cycle
20:04:49 <bwh> OK
20:04:59 <waldi> those are the same device, just different sizes
20:05:30 <bwh> OK, sorry
20:05:39 <waldi> i'll talk to them
20:05:52 <bwh> ukleinek: So that does make sense
20:05:57 <waldi> #action waldi to handle #114695
20:05:59 <bwh> waldi: Thank you
20:06:08 <waldi> #action waldi to handle #1114695
20:06:38 <bwh> #topic Bug #1115329: (n, ) Debian kernel linux-image-6.12.30+bpo-armmp-lpae: strange behaviour on udev for Ethernet port
20:07:48 <ukleinek> is this just about different kernel -> different sysfs data -> different ethernet device name?
20:08:27 <waldi> maybe it does not longer match. but the op disables normal rename behaviour
20:09:05 <bwh> ukleinek: I think it is a device tree change
20:09:23 <bwh> but I'm not sure
20:10:57 <ukleinek> what is that 7 and 8? It's not a platform device id, is it?
20:11:00 <bwh> I don't see any DT changes between 6.12.27 and 6.12.30
20:11:16 <bwh> ukleinek: I think it may be
20:11:29 <ukleinek> but dt systems don't use those?!
20:13:14 <bwh> I tempted to say USB paths aren't stable so don't use them
20:13:27 <ukleinek> on my rpi the ID_PATH for eth0 is: ID_PATH=platform-fd580000.ethernet
20:13:49 <bwh> (even though the part that changed seems to be above the USB bus itself)
20:14:13 <ukleinek> I thought those topology identifiers are stable
20:14:29 <ukleinek> (subject to kernel changes, too, though)
20:15:04 <bwh> OK, does anyone want to take an action to investigate this?
20:15:41 * ukleinek feels already full
20:15:49 <bwh> #action bwh will follow up #1115329
20:16:01 <bwh> #topic Bug #1115580: (n, ) linux-image-6.12.43+deb13-amd64: xhci_usb vfio_pci: usb controller fails to reset when passing through to a qemu VM
20:16:45 <carnil> that one "feels" quite similar to the other one we discussed at the beginning in behaviour.
20:16:59 * ukleinek sees some parallels to that earlier bug
20:17:22 <bwh> Which one, #1114912?
20:17:33 <carnil> bwh: yes
20:17:55 <bwh> I don't see it
20:18:16 <ukleinek> both are about pci passing to kvm
20:18:44 <bwh> Yes but the symptoms are very different
20:19:14 <ukleinek> maybe the common thing is just "driver cleanup is hard"
20:19:17 <bwh> With this one the old driver seems to be properly unbinding but the hardware doesn't work after a PCI reset
20:19:25 <bwh> which could well be a hardware/firmware bug
20:19:55 <ukleinek> There is a POE taint
20:20:05 <bwh> zfs
20:20:41 <ukleinek> there is another module spl, is that related to zfs?
20:20:48 <bwh> yes (Solaris porting layer)
20:20:49 <ukleinek> and kvmfs
20:20:58 <ukleinek> *kvmfr*
20:21:12 <bwh> interesting...
20:21:20 <carnil> what is kvmfr?
20:21:27 <carnil> ah okay again too slow, nevermind
20:21:36 <bwh> I don't know but it sounds related to virtualisation
20:21:54 <bwh> So we can ask to test without kvmfr
20:22:58 <carnil> ack sounds sensible, should I?
20:23:02 <ukleinek> https://looking-glass.io/docs/B7-rc1/ivshmem_kvmfr/ is the best hit I find
20:23:11 <bwh> carnil: If you have capacity, yes please
20:23:46 <carnil> #action carnil ask reporter of #1114912 to test without OOT modules (in particular kvmfr)
20:24:07 <ukleinek> testing without zfs might be hairy for them :-)
20:24:16 <bwh> I think I have run out of energy for bugs. Does anyone want to discuss any of the others on the list before we move on?
20:24:26 <iam_tj[m]> I vaguely recall dealing with another similar bug some time ago that involved kvmfr and it was the problem
20:24:41 * ukleinek is tired, too
20:25:09 <carnil> then maybe we should stop with the buglist
20:25:44 <bwh> #topic New upstream versions
20:26:11 <bwh> I see a new firmware-nonfree which I will try to deal with soon
20:26:23 <bwh> I think I also said I would handle iw...?
20:27:45 <bwh> #action bwh will update firmware-nonfree and iw to current upstream
20:27:55 <bwh> #topic Merge requests
20:28:59 <bwh> I need to address waldi's comments on linux!1615
20:29:06 <bwh> Anyone want to discuss any of the others?
20:29:45 <ukleinek> we already discussed !1657, the others seem harder
20:30:06 <ukleinek> or in good hands
20:30:19 <bwh> #topic AOB
20:30:25 <ukleinek> in #debian-ftp pochu and ta discussed issues about signing of linux-6.1_6.1.148-1~deb11u1. Is that relevant for us, or already resolved?
20:30:26 <carnil> ukleinek: that is a different one though :)
20:30:38 <carnil> the discussed one was about soundwire-amd
20:30:56 <ukleinek> ah right, looked too quickly then (to keep up with bwh :-D)
20:30:58 <bwh> ukleinek: That is certainly relevant for me. I am not currently on there
20:31:03 <carnil> ukleinek: ftp-master are ttbomk still working on it to get it resolved
20:31:29 <ukleinek> carnil: so no action item for us?
20:31:40 <carnil> but I have no details so ar, just comments from ta offlist that ansgar did already intially looked
20:31:52 <carnil> ukleinek: nothing we can do likely it's on ftp-master side
20:32:02 <bwh> Can someone please forward me the relevant information (in privmsg or email)?
20:32:38 <carnil> bwh: I can send the part I have
20:32:42 <bwh> Thanks
20:32:51 <carnil> but it's really just a  couple of IRC comments
20:32:55 * ukleinek only has two lines (I think) from #debian-ftp
20:33:15 <ukleinek> 1758275056         pochu: ta: do you know if there was an issue with the signing of linux-6.1_6.1.148-1~deb11u1 on bullseye-security?
20:33:20 <ukleinek> 1758299385            ta: pochu: hmm, no, I haven't noticed anything, but obviously there is something wrong ...
20:33:52 <bwh> #action bwh will send a report to the mailing list about Kangrejos
20:34:02 <ukleinek> bwh: nice
20:34:10 <bwh> Besides that, we just need to select next week's chair?
20:34:29 * ukleinek reminds the other that he will not be present next week
20:34:46 <carnil> I can do the next one, but likely not the week after (we might be not at home at that evening)
20:34:58 <bwh> Thanks carnil
20:35:00 <carnil> so I can do the next one
20:35:07 <ukleinek> I can chair in two weeks
20:35:14 <bwh> #endmeeting