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