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