19:00:01 <carnil> #startmeeting 19:00:01 <MeetBot> Meeting started Wed Oct 1 19:00:01 2025 UTC. The chair is carnil. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:09 <yunseongkim[m]> Hi 19:00:14 <carnil> #chair bwh ukleinek waldi 19:00:14 <MeetBot> Current chairs: bwh carnil ukleinek waldi 19:00:15 <waldi> hi 19:00:21 <carnil> hi all! 19:00:42 <kathara> helloo 19:00:52 <carnil> before we start with the agenda, is there anything else to be discussed beforehand and put on top of the list? 19:01:13 <bwh> Hello 19:01:37 <bwh> I don't have anything 19:01:42 <waldi> me neither 19:01:44 <carnil> ack 19:01:48 <carnil> so let's start 19:01:54 <carnil> #topic Build time and limits in Salsa CI 19:02:10 <carnil> I think we have a problem. Hoped that maybe santiago might be able to join the meeting tonight. 19:02:18 <waldi> yes we do 19:02:23 <carnil> our build time seems to hit now the time limit of 3h 19:02:31 <bwh> On which branch(es)? 19:02:41 <carnil> on debian/latest at least 19:02:53 <waldi> gcc 15 looks slower 19:02:59 <carnil> I have not seen the problem on trixie and bookworm 19:03:08 <waldi> and ccache seems to be completely ineffective in the CI case 19:03:32 <bwh> Would it make sense to revert to gcc-14 temporarily and report this as a bug? 19:03:47 <carnil> for ccache there is https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/492 but I'm not sure if we are hit about the same 19:04:11 <waldi> and for some reason this thing currently uses mmdebstrap inside an existing system, re-downloading all 19:05:00 <bwh> Is there a way to see what is currently in the cache? 19:05:04 <waldi> no 19:05:14 <waldi> apart from the normal stats 19:05:26 <waldi> everything is hashed, so you can just see that it does not match 19:06:11 <waldi> but ccache can't do mark and sweep expiration, to see if it might overflow with data 19:07:40 <waldi> no idea right now. i have to talk to salsa people again, they still have to so a shared runner migration 19:08:45 <bwh> So gcc 15 is a problem, and I suspect there are new drivers that should be disabled in the cloud config 19:08:53 <carnil> bwh: if you think it would help then yes we can revert my proposal to go for gcc-15 on the debian/latest branch, but I'm not sure this is the only problem here. 19:09:08 <waldi> please see if it fixes something first 19:09:40 <carnil> so an action, revert gcc-15 switch first 19:10:04 <carnil> #action carnil reverts switch to gcc-15 for debian/latest branch 19:10:09 <waldi> no? 19:10:10 <bwh> Broken caching would hurt the usual case but we still have to get the worst case (no usable cache) under 3h 19:10:18 <carnil> no? 19:11:03 <bwh> Shall I take an action to actually test the difference? 19:11:33 <carnil> ok that sounds better, do you agree waldi? 19:12:19 <waldi> i'll see what i can find 19:12:56 <bwh> #action bwh will test performance difference of building with gcc 14 vs 15, and open bug if significantly worse with 15 19:13:10 <waldi> okay, 14 vs 15 seems to be no difference 19:13:20 <bwh> #action bwh will look for more drivers to disable in cloud configs 19:13:29 <waldi> i have 14 builds with 169 minutes 19:14:15 <waldi> so the difference now is: someone merged the source and build steps 19:14:26 <carnil> and might the problem be actually with the switch to the new pipelines and using sbuild+unshare otherwise? 19:14:53 <waldi> well, we can test that easily 19:15:42 <bwh> It definitely doesn't help, but the source build doesn't seem to take very long 19:16:29 <carnil> waldi: my understanding was, we cannot revert https://salsa.debian.org/kernel-team/linux/-/commit/167b300f2f9f95426b0d86670ceec15ce84405a6 to test, because once salsaci people switched the pipelines, ours were not working anymore at all 19:17:00 <waldi> carnil: no idea. i will transplant my simplified one and see what it gives us 19:17:19 <bwh> So long as the required Docker images exist I would expect we can still test with a copy of the old version 19:18:20 <bwh> waldi: Can you give yourself an appropriate action? 19:18:39 <waldi> #action waldi to test pipeline and slow runtimes 19:19:01 <carnil> so thank you very much to both, I think we have a couple of actions now that we can move on to the next item 19:19:18 <waldi> yes 19:19:20 <carnil> #topic Disabling bcachefs 19:19:25 <carnil> this is an 'easier' one. 19:19:37 <waldi> yes 19:19:43 <carnil> for debian/latest I just have to adapt what bwh has commented and add a hint to the now existing dkms module in NEWS file 19:19:58 <carnil> the question is if we just want to leave status quo for trixie 19:20:27 <carnil> I'm undre the impression it make no sense to really keep it enabled in trixie, no tools were available when trixie was released 19:20:40 <bwh> I wish we hadn't included it in trixie, but I Think we should not remove remove drivers during a stable release unless they are completely busted 19:20:43 <waldi> and there wont be any fixes. so lets drop it as well as unsupported 19:20:58 <waldi> bwh: well, is it still security supported? 19:21:01 <carnil> so the amount of people really potentially using it should go to zero. 19:21:31 <bwh> waldi: No, but we could say the same for many other components unfortunately 19:22:51 <carnil> bwh: I agree with you that we should not have included it in trixie and removed it in time, it's my fault not having it on the radar once the release did approach (because I was confident when enabling it, and did not noticed that the tools went away in meanwhile). 19:23:28 <bwh> carnil: I don't blame you at all 19:23:29 <carnil> we have disabled for instance broken drivers like ntfs in past in stable releases, and in this case still my impresion is that the usage will be almost not present and with a corresonding NEWS entry "safe enough" to remove 19:23:36 <waldi> the same as we remove packages from stable, we should not be shy to remove stuff we can not support any longer 19:23:51 <carnil> but that is the point of that discussion to see if we agree or rather would want to keep it enabled 19:24:56 <carnil> from my sec-team experience, we have already triggered some removals in packages because not beeing supportable in stable releases (one of the recent one was guix, which worked quite without much hassle/flux) 19:25:46 <carnil> but maybe we should just take the action now to remove it from debian/latest and once that is done make up our minds for or not to remove it from trixie as well 19:26:27 <bwh> If we want to remove it from trixie we should definitely talk to the release team and maybe put in a very visible warning for some versions before actually removing it 19:29:19 <bwh> Next topic? 19:29:37 <carnil> ok. One other alterantive is to keep it and since we rebase 6.12.y go with whatever get applied as fixes. 19:29:42 <carnil> yes let's move to next topic 19:29:48 <carnil> bug list 19:29:57 <carnil> #topic #1106411: (i, u) linux-image-6.12.27-amd64: kernel NULL pointer dereference in bmc150_accel_core (merged with #1102522, #1112643) 19:30:21 <carnil> I'm following the upstrema discussion. Still there is no fix. I just pinged today the upstream thread to see if things can be moved on. 19:30:43 <bwh> So I see 19:30:44 <carnil> for almost all affected people which trigger the issue the easy workaround is, since it is not usable, to just mask iio-proxy 19:31:03 <carnil> so I would say we wait bit longer to see what lands in mainline and make sure it get backported to stable 19:31:28 <bwh> I was wondering if we could just pick that fix already 19:32:02 <carnil> I would prefer not until it is really blessed and on it's way to mainline 19:32:22 <carnil> (but my opinion only here) 19:33:04 <bwh> I'll try to have a look at what the patch is doing and review it myself, and then open an MR if it seems safe 19:33:05 <carnil> I proposed to get actual affected people test patches so they can add Tested-by and get more confidence 19:33:10 <bwh> right 19:34:14 <carnil> so okay to wait, I'm not really confident aobut picking the https://lore.kernel.org/linux-iio/20250613124648.14141-1-marek.vasut+bmc150@mailbox.org/ patch as long there is so much discussion around it 19:34:19 <carnil> ? 19:34:56 <bwh> I'm OK to wait but I might open the MR after looking over all that 19:35:04 <carnil> ok! 19:36:15 <carnil> can I add an action for you for this second pair of eyes review and possibly open the MR? 19:36:22 <bwh> No :-) 19:36:29 <carnil> ok no :) 19:36:33 <carnil> then we move to the next topic 19:36:49 <carnil> time is progressing but it was good to take time for the two first items 19:36:58 <carnil> #topic #1111095: (i, ) firmware-amd-graphics: Radeon HD 8280 : gpu lock, black screen and crash. 19:37:19 <carnil> reporter is on monologue, but has a followup: without any firmware installed things get more "stable" 19:37:33 <carnil> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111095#62 19:37:55 <Santiago[m]> carnil: sorry, I've just seen your message (I'm on the phone right now, but can chime in if useful) 19:38:53 <bwh> The bug was opened against firmware-amd-graphics and now they are talking about removing firmware-intel-graphics?? 19:39:25 <carnil> bwh: we did reassing it later to src:linux 19:39:32 <carnil> ah wait 19:39:36 <carnil> sorry misread 19:40:21 <carnil> you are right there is not firmware-amd-graphics in the reporter's last list 19:40:46 <waldi> but the log from 6.1 clearly shows radeon loading firmware 19:41:29 <carnil> firmware-amd-graphics: /usr/lib/firmware/radeon/BONAIRE_vce.bin 19:43:47 <bwh> I think if they also removed firmware-amd-graphics then radeon would abort probing (thanks to our patch) and so they would be using a generic video driver 19:44:26 <waldi> the 6.12.43 log does not show firmware loading for some reason 19:44:44 <waldi> or did the message for it vanish? 19:45:13 <carnil> should we get confirmation on installed state for firmware-amd-graphics, get full kernel log there, retest with current 6.12.48-1 without and with firmware-amd-graphics and let us get all the log s for comparison? 19:45:23 <waldi> yes 19:46:14 <carnil> #action carnil ask reporter of #1111095 to confirm installed state of firmware-amd-graphics and provide full kernel logs (with updated 6.12.48-1) with both firmware installed and not 19:46:22 <bwh> waldi: We used to add a log message for successful firmware loading and we no longer do 19:46:45 <carnil> let's do that and see next week were we are 19:46:52 <bwh> yes 19:46:55 <carnil> #topic #1112288: (i, u) amdgpu: GPU hang with 6.12 & 6.16sid, 6.16 liquorix works. 19:46:56 <waldi> bwh: ah, so it got missing 19:47:27 <bwh> waldi: I intentionally minimised the patch 19:48:08 <carnil> some fresh information here. liquorix people pointed out where the single patches are in their branches. But this needs someone to go trough if motivation is available and see which patches are not backported upstream to 6.16.y and 6.12.y if we can identify the fixing patches 19:48:22 <carnil> I personally won't spend energy into that 19:48:23 <bwh> Right, which looks like it could be a big job 19:48:39 <bwh> At least we know where to look for individual patches now 19:49:14 <carnil> for reference of the meeting logs: it is in https://github.com/zen-kernel/zen-kernel/commits/6.16/fixes/ 19:49:36 <bwh> carnil: That should be a #link I think 19:49:41 <waldi> #info liquorix patches are at https://github.com/zen-kernel/zen-kernel/commits/6.16/fixes/ 19:50:00 <waldi> #link https://github.com/zen-kernel/zen-kernel/commits/6.16/fixes/ 19:50:01 <waldi> okay 19:50:09 <carnil> I guess we won't take actions here right now, move to the next 19:50:15 <bwh> right 19:50:19 <carnil> #topic #1112627: (i, Mu) linux-image-6.16.3+deb14-amd64: Intel audio no longer works: DMAR: [DMA Write NO_PASID] Request device [00:1b.0] ... non-zero reserved fields in PTE 19:50:24 <carnil> waiting for bisect results, no action 19:50:31 <carnil> #topic #1114557: (i, u+) linux-image-6.12.43+deb13-amd64: Jieli touchscreen and stylus no longer supported 19:50:49 <carnil> on it yet, tested patches, waiting for mainline and backporting to stable 19:50:59 <carnil> #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:51:20 <carnil> kathara: was on it to assist. Waiting for confirmation on 6.1.147-1. Then bisection to narrow down braking commit needed. For now nothing to do. 19:51:37 <bwh> OK 19:51:47 <carnil> #topic #1114912: (i, ) linux-image-amd64: KVM GPU passthrough causes kernel crash and system hang on Debian 13 after VM shutdown 19:52:17 <carnil> there appears to be workaround (see last message), but no solution worked out sofar. Should it be reported upstream? 19:52:40 <bwh> Yes I think so 19:53:25 <carnil> bwh would you take an action for it? 19:53:41 <bwh> #action bwh will forward #1114912 upstream 19:53:49 <carnil> thanks :) 19:54:00 <carnil> #topic #1115613: (i, +M) linux: Please enable CONFIG_SOUNDWIRE_AMD=m 19:54:28 <carnil> waiting. Reporter confirmed that it is indeed not enough to only enable that module, will do more test/work and then report back -> no action 19:54:33 <waldi> there are quite some modules missing it seems 19:55:07 <carnil> waldi: I would expect reporter can provide us a tested list of required modules which we then can enable 19:55:14 <waldi> i hope so 19:55:51 <carnil> #topic #1116065: (i, Mu) linux: kernel oops with rsync on MSI X99A with ntfs3 19:56:23 <bwh> Only one driver can actually bind to the PCI device, so while lspci on Ubuntu gives us a list of other drivers we probably should enable, they won't be relevant to this specific device 19:56:44 <waldi> they might be helper modules 19:56:47 <carnil> this is not an easy one. The isue at least according to reporter seems to narrow down when rsyncing where NTFS filesystem is involved, but only when using the ntfs3 driver, and when on a SSD. For me there is still quite an unclear picture of the problem 19:57:29 <carnil> ah you are back to the SOUNDWIRE_AMD one, sorry was too fast 19:57:31 <bwh> Maybe there is a race that is harder to hit with an HDD 19:59:15 <waldi> yeah. use after free. the address is valid for kernel 20:00:45 <waldi> wait, instruction pointee? 20:00:47 <bwh> carnil: I agree that the earlier upstream bug report looks quite similar. Maybe a regression of that bug 20:02:01 <bwh> waldi: Use-after-free and an indirect jump. Fun for all the exploit writers 20:02:22 <waldi> and yes, it looks pretty similar 20:02:28 <carnil> it might now be worth to report it to the ntfs3 list (while checkng it does not seem still too active, but at least it can be a next step) 20:02:30 <waldi> indirect jumps are the best 20:02:49 <bwh> carnil: Yes this should go upstream 20:03:07 <carnil> #action carnil forwards information from #1116065 to ntfs3 driver upstream 20:03:27 <carnil> do you have still capactiy for a couple of more bugs, or should we switch to AOB? 20:03:39 <bwh> Let's do the last 2 "important" 20:03:54 <carnil> agree, and then stop 20:03:58 <carnil> #topic #1116554: (i, ) linux-image-6.12.43+deb12-amd64: hard freeze during normal operation with stacktraces in the syslog 20:04:16 <carnil> New report, traces and logs are provided by reporter. 20:04:43 <carnil> maybe not easily reproducible, mich might make bisection bit harder 20:05:02 <carnil> but it is not a direct regression 20:05:14 <bwh> I see a hang in a USB-C-related work item 20:05:18 <carnil> reporter has issues as well with earlier versions 20:06:33 <bwh> Maybe worth checking whether they're using a USB-C dock and if there's an update firmware available for that 20:06:57 <waldi> and it would be useful to see who holds this mutex 20:07:33 <bwh> Does that get logged? 20:08:12 <bwh> I suppose not as the "hung task" is not specific to mutexes 20:08:14 <waldi> no, it is not easy to see. a task dump can help 20:08:18 <waldi> no 20:08:19 <bwh> right 20:09:12 <waldi> ww don't even know which ucsi backend is used 20:10:15 <waldi> so a complete log, and echo t > /proc/sysrq-trigger (was it t?) 20:10:46 <bwh> yes 20:10:56 <bwh> Can you ask for that? 20:11:19 <waldi> #action waldi to handle #1116554, full log, task info via sysrq 20:11:25 <carnil> thank you waldi 20:11:36 <carnil> #topic #1116643: (i, ) UBSAN: shift-out-of-bounds in .../drivers/gpu/drm/display/drm_dp_mst_topology.c (shift exponent -1) 20:11:40 <carnil> this is as well a new report 20:12:12 <bwh> New to us, anyway 20:12:39 <carnil> but maybe we have already enough information to forward it 20:12:59 <bwh> Yes, though it's probably worth searching to avoid a duplicate report 20:13:12 <carnil> yes right 20:13:52 <carnil> I can give it a try, but will put it down to the priority list TBH 20:13:58 <bwh> #action bwh will look for upstream bug for #1116643 and ask reporter to forward if there is none 20:14:06 <carnil> ok better :) 20:14:18 <carnil> then I would say switch to 20:14:23 <carnil> #topic AOB? 20:14:47 <waldi> nothing from me 20:14:48 <carnil> who can chair next week? IIRC ukleinek offered that he can take it. But he is not around today to confirm 20:14:58 <waldi> i can do that 20:15:16 <carnil> #action waldi will chair next weeks team meeting 20:15:27 <carnil> so I would propose to close now 20:15:35 <bwh> OK 20:15:43 <carnil> thanks for all for partecipating today 20:15:44 <bwh> Thanks for chairing 20:15:47 <carnil> #endmeeting