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