19:59:19 <ukleinek> #startmeeting
19:59:19 <MeetBot> Meeting started Wed Dec 11 19:59:19 2024 UTC.  The chair is ukleinek. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:19 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:59:26 <ukleinek> #chair bwh
19:59:26 <MeetBot> Current chairs: bwh ukleinek
20:00:50 <ukleinek> bwh: anything before we start with the bug list?
20:01:05 <bwh> No
20:01:15 <ukleinek> #topic #1089521 linux-image-6.12.3-amd64 fails to boot due to Oops: invalid opcode: 0000 error
20:01:33 <ukleinek> That's a new one, list corruption in drm/i915
20:02:23 <bwh> Seems like it should be fixed by https://lore.kernel.org/all/20241211114905.368044-1-stanislaw.gruszka@linux.intel.com/
20:02:26 <ukleinek> ah right, someone pointed out this is a duplicate
20:02:44 <bwh> but then they referred to the same bug number
20:03:22 <ukleinek> oh, indeed, still this reminded me on some other bug
20:03:52 <ukleinek> I guess Nico Orru wanted to say "me too"
20:04:35 <ukleinek> should probably be forwarded upstream
20:04:55 <bwh> I'll note the patch on the bug report. I don't think we need to forward unless someone says the patch doesn't work for them
20:05:29 <ukleinek> ack
20:05:45 <bwh> I'm very behind on tasks so I am not volunteering to walk reporters through testing the patch
20:06:20 <ukleinek> #action ukleinek asks reporters of #1089521 to look at/test https://lore.kernel.org/all/20241211114905.368044-1-stanislaw.gruszka@linux.intel.com/
20:06:42 <ukleinek> #topic 1087807 linux-image-6.1.0-27-amd64: Unable to boot: i40e swiotlb buffer is ful
20:07:05 <bwh> I still have an action to look at this
20:07:12 <ukleinek> ack
20:07:25 <ukleinek> #action bwh cares for #1087807
20:07:53 <ukleinek> #topic #1076372 Corruption of Longsys/Lexar NM790 NVMe drive with Linux 6.5+
20:08:09 <ukleinek> That's one of the bugs we talk about each week.
20:08:39 <bwh> :-/
20:08:44 <ukleinek> carnil asked reporter to forward one of the problems identified there
20:09:31 <bwh> We should probably clone this bug to separate the 2 issues
20:10:18 <ukleinek> I don't have an overview there, maybe carnil can better care there? I'll ask him.
20:10:32 <bwh> OK
20:10:35 <ukleinek> #action ukleinek talks to carnil about #1076372
20:10:56 <ukleinek> # topic #1063754 fat-modules: SD corruption upon opening file on Linux desktop
20:11:00 <ukleinek> #topic #1063754 fat-modules: SD corruption upon opening file on Linux desktop
20:11:23 <ukleinek> That's an old one, IIRC we hope to close it for inactivity?
20:11:27 <bwh> Right, I think I have an action to close this (letting the reporter know they can reopen if necessary)
20:11:49 <ukleinek> There is no action since 2 month, so maybe now is the time.
20:12:10 <ukleinek> #action ukleinek to close 1063754 nicely
20:12:24 <bwh> Thank you
20:12:37 <ukleinek> #topic #1087616 linux-image-6.11.7-amd64: Can't boot (boot freezes after \[or maybe during\] cryptsetup unlocks drive
20:13:17 <ukleinek> The sysrq trick helped, however I'm unsure if this really helps. On a quick glance I think systemd waits in a poll
20:13:44 <bwh> The backtrace shows systemd reading from a tty...
20:14:04 <ukleinek> because the sysrq keycombo was pressed?
20:14:32 <bwh> I don't think so. It's a regular read() system call
20:15:21 <ukleinek> but this is already post exit_to_user_mode
20:15:37 <ukleinek> hmm, not sure
20:15:57 <bwh> The ? lines, are, well, questionable
20:16:10 <bwh> probably left over from the previous system call
20:17:26 <ukleinek> maybe ask in #d-systemd for help?
20:17:35 <bwh> I think we should reassign this over to systemd so they can at least try to figure out why it's reading from the tty
20:17:46 <ukleinek> ok
20:18:01 <ukleinek> #action ukleinek reassigns #1087616 to systemd
20:18:31 <ukleinek> #topic #1021245 linux-image-5.10.0-18-rt-amd64: can't access EFIVARS when using rt version of kernel
20:18:38 <ukleinek> We have that 3x
20:18:53 <bwh> Yes, and someone reminded me of this in Toulouse
20:19:45 <ukleinek> it seems to be like that by design, waldi mentioned a cmdline to fix that and wondered if the Debian kernel should default to that behaviour.
20:20:09 <bwh> Yes, for a proper real-time system the unpredictable latency of EFI run-time services is a problem
20:20:50 <ukleinek> Maybe "don't do it then" is a more sensible approach than refusing to do it?
20:21:01 <bwh> I don't believe the real-time kernels we provide are suitable for production real-time systems so I'm happy with changing the default
20:21:03 <ukleinek> I tend to agree to waldi
20:21:10 <bwh> yes
20:22:09 <ukleinek> #action let efi=runtime be the default, ukleinek asks waldi to support
20:22:43 <ukleinek> #topic #1085178 linux-signed-amd64: Some BPF fentry hooks silently fail
20:22:50 <ukleinek> This is where my preparation stopped.
20:23:31 <ukleinek> ah, seems to be tag + fixed-upstream
20:24:05 <bwh> Well there's a patch but was it ever applied?
20:25:00 <ukleinek> yup, discussion continued just a few days ago. I suggest waiting.
20:25:25 <bwh> Oh, right, I didn't notice the dates
20:25:40 <bwh> I'll mark it forwarded
20:25:55 <ukleinek> #action keep an eye on upstream discussion of #1085178
20:26:39 <ukleinek> #topic #1089158 Kernel Panic on Shutdown/Restart During RAID Resync with mdadm on Debian 12.7
20:28:06 <bwh> This at least seems like it should be hardware-independent
20:29:19 <bwh> and is presumably a regression from 12.6, since I would expect interrupting RAID syncs during installation to be pretty common
20:30:16 <ukleinek> so maybe 6.1.115 was good?
20:30:27 <ukleinek> the bug is about 6.1.119
20:30:46 <bwh> Is it? The found version is 6.1.112-1
20:31:06 <ukleinek> then I looked too quick
20:32:15 <ukleinek> Hmm, Version: 6.1.0-28-amd64 is 6.1.119
20:32:45 <ukleinek> if I did something wrong in the git history interpretation I still don't see it
20:33:05 <bwh> also Debian 12.7 had linux 6.1.106-3, so it's a bit confusing
20:33:35 <ukleinek> no version info in the photo of the oops
20:33:59 <ukleinek> 6.1.0-28 is from bookworm-security
20:34:17 <bwh> OK, I can see 6.1.106-3 and 6.1.112-1 in photos attached to the other report
20:35:03 <bwh> I've added that as a found version
20:35:19 <ukleinek> so was ask the group of reporters to identify a good kernel version?
20:35:39 <bwh> I think we can be a bit smarter than that
20:35:40 <ukleinek> s/was/we/
20:36:47 <ukleinek> bookworm-backports is ok according to the initial mail in #1086175
20:37:17 <bwh> There are only 4 commits to drivers/md between v6.1.94 (as released in Debian 12.6) and v6.1.106
20:38:34 <bwh> so I can look to see if there are any later fixes referencing those
20:39:11 <ukleinek> nothing for 305a517 and a8768a13
20:39:25 <ukleinek> (I used git log a8768a13..next/master --grep a8768a13)
20:39:33 <bwh> yeah, nothing
20:40:14 <ukleinek> also nothing for the other two.
20:41:20 <bwh> I guess this needs to be bisected then
20:41:49 <ukleinek> #action ukleinek asks reporters of #1089158 and its merged bug for bisection
20:41:57 <bwh> I can take an action to do that but probably won't get to it soon
20:42:28 <ukleinek> I'll try to do it, if I fail we can still schedule to someone else
20:42:51 <ukleinek> #topic #1089323 linux-image-6.1.0-28-arm64: systemd can login, sysvinit hangs fatal before login
20:44:11 <bwh> I don't see any kernel bug here
20:44:31 <ukleinek> only the subject points to a real problem
20:45:49 <ukleinek> is lima a staging module?
20:46:24 <bwh> No, they are marked with (C)
20:46:50 <ukleinek> ** Tainted: C (1024) * staging driver was loaded
20:47:03 <bwh> The error messages seems like the usual slightly buggy device tree
20:48:14 <bwh> It's a bad bug report and I don't think it's worth spending time on
20:48:14 <ukleinek> or missing drivers
20:48:49 <ukleinek> so we reply and ask for a more detailed report? Or just nothing?
20:48:50 <bwh> I'll take an action to close and suggest opening a separate bug report on sysvinit if that's actually something they care about
20:49:27 <ukleinek> #action bwh closes #1089323 and asks to report to sysvinit (which seems to be the actual problem)
20:49:49 <ukleinek> #956752 is one of the duplicates
20:50:34 <ukleinek> #topic #1075770 linux-image-6.9.7-amd64: adlp_tc_phy_connect [i915] fills logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
20:51:00 <bwh> It seems like this is progresing upstream
20:51:54 <ukleinek> bts forwarded 1075770 https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12246 ?
20:52:11 <bwh> Yes and there are responses there
20:52:21 <bwh> It is already marked forwarded
20:52:23 <ukleinek> ah, it is already forwarded.
20:52:40 <ukleinek> (I expected a flag in the agenda for that)
20:52:59 <ukleinek> so no action for that one, right?
20:53:05 <bwh> right
20:53:26 <ukleinek> #topic #1089045 linux-image-6.11.10-amd64: kernel task hang when connecting bluetooth](https://bugs.debian.org/1089045
20:54:29 <ukleinek> the kernel log there seems to be only a symptom, not the root cause
20:55:09 <ukleinek> maybe the hang is a wait for a mutex?
20:55:53 <bwh> Well the one commit in net/bluetooth between v6.11.7 and v6.11.10 looks a bit sus
20:56:24 <ukleinek> let them test 6.12?
20:56:47 <bwh> That's an option yes
20:57:42 <bwh> That would at least let us know if we still have a bug to fix at all
20:58:18 <ukleinek> huh: $ git lg v6.11.. --grep=333b4fd11e89
20:58:18 <ukleinek> 55abbd148dfb Bluetooth: hci_core: Fix calling mgmt_device_connected
20:58:18 <ukleinek> 7967dc8f797f Bluetooth: hci_core: Fix calling mgmt_device_connected
20:58:55 <ukleinek> why was it applied twice?
20:59:09 <bwh> uh that's interesting
20:59:52 <bwh> Probably went through 2 different branches (1 for next and 1 for fixes in current cycle)
21:00:35 <ukleinek> yeah, one is in 6.12, the other is only reachable from 6.13-rc1
21:02:03 <ukleinek> hmm, ok, so let's ask them to test 6.12
21:02:19 <bwh> Right
21:02:27 <ukleinek> #action ukleinek asks to reproduce #1089045 on 6.12
21:02:58 <ukleinek> It's > 22:00 CET now, should we skip the rest of the bugs?
21:03:22 <bwh> The same fix on 2 different branches usually merges together successfully, but can result in the patch being applied to stable twice (the second time in a different function). But that didn't happene here.
21:03:26 <bwh> Yes
21:03:46 <ukleinek> #1071562 would be good to solve, this affects Debian build servers IIRC
21:05:21 <bwh> Probably should be severity important?
21:05:36 <ukleinek> ack
21:06:51 <ukleinek> #action ukleinek looks into #1071562, maybe increases severity.
21:07:08 * ukleinek has enough on his plate now and suggests to end the meeting.
21:07:20 <bwh> Yes, please
21:07:25 <ukleinek> #endmeeting