19:01:49 <bwh> #startmeeting 19:01:49 <MeetBot> Meeting started Wed Aug 28 19:01:49 2024 UTC. The chair is bwh. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:49 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:02:32 <bwh> There were far too many bugs updated this week :-/ 19:02:49 <bwh> linux-image-6.5.0-0.deb12.4-amd64: ext4 file corruption with newer kernels 19:02:57 <bwh> #topic bug #1076372: linux-image-6.5.0-0.deb12.4-amd64: ext4 file corruption with newer kernels 19:03:21 <bwh> No news from the submitter, so maybe we need to ping them? 19:03:39 <carnil> I did reply to that as action of the last meeting, Stefan had not time to perform all the tests 19:04:13 <carnil> (ah no it was the meeting before), but his last reply was that he did not had sufficient time for other tests 19:04:18 <carnil> so yes maybe worth pinging again now 19:04:19 <bwh> right 19:04:34 <bwh> Can you do that? 19:04:38 <carnil> yes 19:05:03 <bwh> #chair carnil waldi 19:05:03 <MeetBot> Current chairs: bwh carnil waldi 19:05:24 <bwh> #action carnil will ping submitter of #1076372 19:05:39 <bwh> #topic Bug #1063754: fat-modules: SD corruption upon opening file on Linux desktop 19:06:03 <bwh> I still have a draft reply to this that I need to finish off, sorry 19:06:34 <bwh> I will move on unless anyone else wants to take over that 19:06:56 <carnil> yes please it's ok 19:07:12 <bwh> #topic Bug #1021245: linux-image-5.10.0-18-rt-amd64: can't access EFIVARS when using rt version of kernel 19:07:15 <carnil> gut feeling: the submitter is slightly upset in his last reply 19:07:43 <bwh> I see carnil merged 2 old reports of this 19:08:05 <waldi> yeah. i thought i acted on that, but seems i did not 19:08:32 <waldi> i think we should override that upstream behaviour. yes, it can break real time 19:08:52 <waldi> but otherwise we have to consider this kernel as not efi capable 19:08:59 <bwh> Does that trigger a warning? If not, should we implement aht? 19:09:03 <bwh> *that 19:09:13 <waldi> warning for what? 19:09:24 <bwh> Use of EFI runtime services on an RT kernel 19:09:41 <bwh> Or would that trigger on every boot, in practice? 19:09:51 <waldi> yes, it will now 19:10:48 <waldi> but in any case, a warning is only good if there is a user action attached to it. there is none here, apart from dropping efi 19:11:45 <bwh> I guess we have to figure who the RT kernels are really for... 19:12:30 <waldi> but even if: all x86 cpus contain interrupt capabilities that the kernel can#t suppres 19:12:49 <waldi> okay. what should we do? 19:12:50 <bwh> Yes I know SMM is also an issue on a lot of systems 19:12:58 <ema> bwh: do you mean figuring out who is using rt kernels and why? 19:14:37 <bwh> ema: Yes, and specifically whether they are for people prototyping hard real-time systems, for getting lower latency for audio-visual production, or for something else 19:14:58 <ema> perhaps we could ask the submitters of RT-related bugs 19:15:02 <bwh> (If people are trying to use Debian in production real-time systems they have gone very, very wrong) 19:15:17 <bwh> +hard 19:16:21 <bwh> So should we maybe try to run a survey? I've never tried that before 19:17:55 <bwh> OK, if no-one wants to do that, I'm happy to leave things unchanged and move on 19:18:01 <ema> the submitter of #1021245 specifically mentions "customers" in 1021245#15, so maybe politely asking (privately perhaps) what they're using the RT kernel for could be an action item 19:18:19 <ema> if we agree I can do that 19:18:34 <bwh> Oh god yeah 19:18:38 <carnil> At least that would be one way to get some information 19:19:15 <carnil> (making a survey is likely out of scope at least for me timewise, and I never did that for instance with limesurvey) 19:19:45 <bwh> ema: I'd be happy for you to do that 19:19:46 <carnil> but other than that the bugs related to RT raised in this week list because I did some triage on older bugs and merged the two 19:19:58 <waldi> #action ema will ping the submitter of #1021245 for more information 19:20:05 <waldi> thx ema 19:20:09 <ema> np 19:20:31 <bwh> #topic Bug #1078696: linux-image-amd64-signed-template: Asus Vivobook X1704V : no keyboard 19:20:40 <carnil> that one is easier 19:21:03 <bwh> Oh that one only changed because I fixed the severity 19:21:12 <carnil> the reporter did provide a patched source, asked to report this upstream, did not got a reply anymore back and on last checking there was nothing on upstream lists 19:21:25 <bwh> #topic Bug #1079394: linux-image-6.10.6-amd64: causes cifs regression, flatpak & ostree signature corruption 19:22:06 <carnil> This is reported upstream now in https://lore.kernel.org/regressions/pv2lcjhveti4sfua95o0u6r4i73r39srra@sonic.net/ 19:22:40 <bwh> I followed this one upstream and it looks like there are fixes available: https://lore.kernel.org/linux-cifs/CAH2r5mtZAGg4kC8ERMog=X8MRoup3Wcp1YC7j+d08pXsifXCCg@mail.gmail.com/ 19:23:23 <bwh> As this involves data loss, the severity should be grave 19:23:45 <bwh> #action bwh will upgrade severity for #1079394 19:23:48 <carnil> isnt that the second issue? 19:24:00 <bwh> Uh possibly 19:24:34 <bwh> but the reply from Forest seems to indicate that the data corruption is not reproducible after those 19:24:34 <carnil> see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079394#42 19:25:01 <carnil> the initial one is affecting 6.10.y reporter was struggling confirming it sitll affects 6.11-rcX becuase of a second issue, which was then tracked as https://linux-regtracking.leemhuis.info/regzbot/regression/lore/37fncjpgsq45becdf2pdju0idf3hj3dtmb@sonic.net/ 19:25:09 <carnil> (which does not affect 6.10.y TTBOMK) 19:25:33 <carnil> ok 19:25:40 <bwh> Right, but with 6.11-rc5 and the 2 extra patches it looks like both issues are gone...? 19:26:04 <bwh> In any case I have upgraded severity so we will see this again next week :-) 19:26:10 <carnil> yes thanks! 19:26:32 <bwh> #topic Bug #1079686: nouveau: fifo: fault 01 [WRITE] at 0000000000068000 engine 03 [IFB] client 08 [HUB/HOST_CPU_NB] 19:27:18 <bwh> This i with 6.10 so I think it can be resubmitted upstream 19:28:02 <bwh> Who will follow this up? 19:28:09 <waldi> it is also not the first warning 19:28:36 <bwh> There's a full log attached 19:28:59 <bwh> and the first WARNING was also from nouveau 19:29:28 <bwh> (well, related to nouveau) 19:29:59 <bwh> OK, I will take an action 19:30:15 <bwh> #action bwh will follow up #1079686 and request it be submitted upstream 19:30:35 <bwh> #topic Bug #1072063: [drm/i915] one of the external monitors randomly blank for 2-3 seconds with 6.8+ Linux kernels (regression) 19:31:41 <bwh> This was resubmitted upstream but I'm not sure it's progressing there 19:32:05 <bwh> The only recent change on the bts was updating the affected versions 19:32:28 <carnil> so I guess do nothing for now? 19:32:29 <bwh> I don't think there's anything we can do about it at the moment, right? 19:32:31 <bwh> right 19:32:47 <bwh> #topic #1079183: linux-image-amd64: Bluetooth is disabled 19:35:38 <bwh> Seems like a init regression in whichever driver is being used 19:36:14 <carnil> it might be still worth asking to test with 6.10.6-1 explicitly 19:36:19 <bwh> OK 19:37:06 <carnil> not that I have any indication in the commits relating to the problem, but just to make sure that it's still present regression wise in 6.10.6 19:37:56 <bwh> Can you do that? 19:38:05 <carnil> if you want you can add it as action to followup on the bugreport to me 19:38:07 <carnil> yes 19:38:41 <bwh> #action carnil will follow up to #1079183 19:38:58 <bwh> #topic Bug #1079536: linux-image-6.9.7+bpo-amd64: debian linux-image-amd64 / 6.9.7+bpo video problems on multiheaded Intel ARC 380 19:40:05 <bwh> Intel ARC is using the xe driver, I think? 19:40:53 <bwh> but I don't see that being built 19:41:40 <bwh> so I'm confused as to how this was working at all 19:41:59 <ema> perhaps we could ask for Xorg.0.log? 19:42:49 <bwh> People still use Xorg? ;-) 19:43:07 <ema> ha, I do :) 19:44:09 <bwh> Can anyone understand how this can work? Or why we didn't enable CONFIG_DRM_XE already? 19:45:22 <bwh> #action bwh will look at enabling CONFIG_DRM_XE 19:45:36 <ema> can it be that the system is using vesa instead? 19:46:27 <bwh> AFAIK firmware graphics interfaces like VESA and EFI GOP only support a single framebuffer 19:46:31 <bwh> so no dual monitor support 19:46:51 <ema> oh, possibly it's i915 and not xe 19:47:25 <carnil> bwdoes it really use XE? 19:47:32 <carnil> it seems quite old already from 2022 19:47:35 <carnil> https://www.intel.com/content/www/us/en/products/sku/227959/intel-arc-a380-graphics/specifications.html 19:47:48 <bwh> That says: Microarchitecture: Xe HPG 19:48:03 <bwh> and I thought i915 was exclusively fro integrated graphics 19:48:24 <bwh> but Intel is not the most consistent with naming 19:49:57 <waldi> the pci id shows up in both xe and i915 19:50:14 <bwh> ugh 19:51:34 <ema> sorry for sounding like an old man but how do you get the equivalent of Xorg.0.log in this brave new world of wayland? 19:51:42 <bwh> #action bwh will also look at whether #1079536 is due to i915 claiming hardware that should be handled by xe 19:52:13 <bwh> #topic Bug #1079741: buildd.debian.org: Keyboard not work on Debian 12/13 over Asus Vivobook Go 14 E1404GAB_E1404GA notebook 19:54:18 <bwh> The bug report leaves something to be desired. 19:54:48 <bwh> But, it seems like i8042 failed and only some special keys that report through a platform driver are working 19:55:39 <bwh> The kernel version isn't mentioned but it says Debian 12/13 so I think we can assumed 6.1 and some recent 6.x are both affected 19:57:03 <bwh> Who will follow this up? 19:58:09 <waldi> give it to me 19:58:20 <carnil> just found https://bugzilla.kernel.org/show_bug.cgi?id=216158 19:58:54 <bwh> #action waldi will follow up #1079741 20:00:19 <bwh> carnil: I see comment 106 trying to hijack the bug to be about the model mentioned on the bts 20:00:55 <bwh> I guess there are a bunch of weird laptops not working with i8042 20:01:32 <bwh> Well, we're already up to 1 hour. Is there anything particularly important remaining on the list that people want to discuss? 20:01:59 <ema> I had an action item from last week, providing benchmarks about arm64 kernels with 64k pages 20:02:09 <ema> Added them to https://salsa.debian.org/kernel-team/linux/-/merge_requests/1169 20:02:41 <ema> see for example https://www.phoronix.com/review/aarch64-64k-kernel-perf/3 which gives plenty of data for the NVIDIA GH200 with 4k and 64k kernels 20:02:50 <bwh> #topic linux MR 1169: [arm64] Add additional kernel with 64k page size 20:04:24 <bwh> OK, well there's something to look at. I don't think we have time to go through those results today 20:04:55 <ema> sure, just wanted to mention that I did my homework :) 20:05:20 <bwh> Thanks for finding those, and I hope we have time to discuss this next time 20:05:46 <bwh> #topic Any other business 20:06:49 <bwh> If no-one speaks I'll move on to who will chair next time 20:06:50 <carnil> not for today :) 20:07:24 <bwh> #topic Next meeting 20:07:29 <carnil> for the chair, I guess it is my turn now again, not fully optimal for prepartion but I can do it 20:07:50 <bwh> and we'll be back on Jitsi, right? 20:08:04 <carnil> correct if we continue to alternate 20:08:38 <bwh> #agreed Next meeting on Jitsi with carnil as chair 20:08:47 <bwh> #endmeeting