20:00:01 <carnil> #startmeeting
20:00:01 <MeetBot> Meeting started Wed Mar 11 20:00:01 2026 UTC.  The chair is carnil. Information about MeetBot at https://wiki.debian.org/MeetBot.
20:00:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:18 <carnil> #chair bwh ukleinek waldi
20:00:18 <MeetBot> Current chairs: bwh carnil ukleinek waldi
20:00:22 <carnil> Hi
20:00:44 <ukleinek> o/
20:00:54 <bwh> Hi
20:01:01 <carnil> welcome to todays meeting, are there any topics you wish to discuss before we move to the regular bug discussion?
20:01:18 <carnil> (btw, I aim to have a bit shorter meeting if possible)
20:01:26 <ukleinek> +1
20:01:30 <bwh> Nothing urgent
20:01:44 <carnil> ok let's jump into the bug list then
20:01:45 <ukleinek> waldi said to not being able to attend
20:01:57 <carnil> ah right, thanks I did forgot
20:02:10 <carnil> #topic #1126671: linux-image-6.17.13+deb13-amd64: Disconect root (path=/) during heavy load on NvME, partial corruption on NTFS.crash soon but not yet
20:02:34 <carnil> from last meeting, @waldi will take a look, I think we can wait for further action here otherwise? Or anyone has ideas around it?
20:02:44 <bwh> Let's wait for him then
20:03:06 <carnil> #topic 1126128: linux-image-6.17.13+deb14-amd64: Oops at boot time about parport_register_dev_model (merged with #1124075, #1124463)
20:03:16 <carnil> Recurring, but hard to reproduce problem, for all reporters "one time", upstream proposed a patch, but needs someone to be able to reproduce and test the problem.
20:03:31 <carnil> the problem here is really, for all reporters this was a one-time occurence and never showed up again later
20:03:44 <carnil> so no idea how we can further be of help here
20:03:54 <ukleinek> or someone needs to spend some time on the backtrace?
20:03:58 <bwh> Does QEMU emulate a parallel port? I would expect so
20:04:38 <bwh> I could take an action to try reproducing in a VM
20:04:44 <carnil> ack
20:04:51 <ukleinek> #action ukleinek will try to decode the backtrace of #1126128
20:05:02 <bwh> #action bwh will try to reproduce #1126128 in QEMU
20:05:07 <carnil> perfect :)
20:05:34 <carnil> #topic #1127635: linux-image-6.18.9+deb14-powerpc64: fails to boot on IBM 8204-E8A (POWER6 p550) LPAR, NULL deref in PCI MSI setup)
20:05:43 <carnil> this got bisected, ukleinek reported upstream, so wait
20:05:55 <carnil> (unfortunately the affected machine will not be anymore in hands of the reporter afaiu)
20:06:02 * ukleinek nods
20:06:21 * ukleinek really liked the reporter, they bisected without our support
20:06:34 <carnil> #topic #1128632: linux-image-6.12.73+deb13-amd64: boot failures, ACPI errors, and sleep issues on ASUS Sabertooth Z77 (i7-3770K)
20:06:57 <carnil> ukleinek: asked question to test without properietary driver, so we need to wait for the followup -> no action
20:07:03 * ukleinek nods
20:07:04 <bwh> right
20:07:12 <carnil> #topic #1129033: iwlwifi: WARNING in _iwl_mvm_sec_key_del with hostapd on 6.12.73+deb13-amd64 (AP mode)
20:07:17 <ukleinek> ditto
20:07:26 <carnil> ukleinek: asked to test with newer kernel, no answer -> wait
20:07:28 <carnil> yep
20:07:37 <bwh> OK
20:07:44 <carnil> #topic 1130025: linux: kernel oops/page fault in __d_lookup/__d_lookup_rcu under docker/runc workload
20:08:14 <carnil> this time it was me to ask questions: the reporter has a reproducing case, so it was intuitive to me to ask if he an bisect and  to test with newer kernels
20:08:29 <carnil> but got no reply so far, but maybe any of you has some more ideas on what to look for?
20:08:35 * ukleinek nods again
20:08:43 <carnil> (otherwise we wait here as well)
20:08:59 <bwh> The first BUG in the log that was sent already has the D taint flag, so it wasn't the very first
20:09:12 <bwh> Might it be worth asking for that?
20:09:47 <carnil> yes right, I take an action to ask for a full log
20:09:54 <ukleinek> "Hardware name: QEMU Standard PC" might make it easily reproducible for us, too
20:10:15 <ukleinek> R13: fefefefefefefeff
20:10:26 <ukleinek> is this a poison constant?
20:10:40 <carnil> #action carnil ask reporter of #1130025 for a full boot log so we get the first backtraces
20:10:59 <bwh> ukleinek: I don't think so... might be the result of some soft-SIMD string thing
20:11:46 <ukleinek> > Mar 07 12:37:58 lgh kernel: Code: 00 00 00 41 54 41 ba 00 10 00 00 bf 9c ff ff ff 48 8d 35 9c e4 01 00 55 b8 0b 01 00 00 53 48 81 ec 00 10 00 00 48 89 e2 0f 05 <85> c0 7e 7d 0f b6 14 24 80 fa 5b 74 74 80 fa 2f 0f 8>
20:11:57 <ukleinek> also looks strange, trash at the end?
20:12:34 <bwh> I think they've pasted from journalctl output
20:12:53 <bwh> so truncated lines end with a '>'
20:13:03 <ukleinek> there are other lines similarily truncated and just had that idea, too
20:13:04 <carnil> yes because this shows up as well at other long lines
20:14:21 <bwh> Is that all for this bug?
20:14:23 <carnil> but I think having a full log first would be a good start
20:14:28 <carnil> so let's move on
20:14:44 <carnil> #topic #1127588: linux-image-6.18.9+deb14-amd64: Cannot hibernate after some time of work
20:14:55 <carnil> there is no fresh information here
20:15:06 <carnil> (just showed up because of submitter update)
20:15:09 <bwh> I think someone (probably me) already has an action to respond to this
20:15:15 <carnil> but I looked up if we had an action
20:15:28 <carnil> -> From 20260211 meeting: ACTION: bwh will respond to #1127588 requesting info about memory usage
20:15:30 <bwh> right
20:15:33 <carnil> so I guess you keep the action :)
20:15:56 <carnil> #topic #1128834: linux-image-6.1.0-43-amd64: NFS client regression in 6.1.162: large rsize/wsize (1MB) causes EIO
20:16:24 <carnil> I had an action here assigned to me to contact upstream, I'm sorry did not manage to do, but I will try on weekend
20:16:33 <carnil> so I keep the action if that's fine for you
20:16:45 * ukleinek nods
20:16:48 <bwh> OK. And we have some interesting input from the other reporter
20:17:03 <carnil> #topic #1128861: linux: when serving NFS, client attempts to lock served files fail with "No locks available"
20:17:33 <carnil> I have a question: do I understand https://bugs.debian.org/1128861#78  correctly that this is actually the correct behaviour?
20:19:11 <ukleinek> "I think that the current behaviour is correct"
20:19:13 <carnil> Neil Brown at least states this, OTOH it can be considered a regression, and proposed a changes but "But I wouldn't encourage him to."
20:19:34 <bwh> "Don't break user-space unless you think you know better than Linus"
20:20:00 <ukleinek> ..ooOO(that quote is not in the bug log)
20:20:12 <carnil> no :)
20:20:14 <bwh> No I'm paraphrasing
20:20:30 <carnil> so wait, on what upstream people decide to do?
20:21:37 <bwh> We should probably wait a bit
20:21:49 * ukleinek at least doesn't see competence on his side to act here
20:22:00 <bwh> but then we should either escalate this or try to fix the regression for trixie only
20:22:15 <carnil> ok
20:22:28 <ukleinek> escalate to where? NeilBrown is already upstream, isn't he?
20:24:04 <bwh> well he is one of the upstream maintainers
20:24:31 <ukleinek> and you still see a need/sense to escalate?
20:25:24 <carnil> well maybe we just should make sure the discussion between the linux-nfs people does not stall
20:25:33 <ukleinek> #next
20:25:40 <carnil> so ping the thread after a while if things stalls
20:25:41 <carnil> right
20:25:47 <carnil> #topic #1129061: linux-image-loong64: loongson_edac driver is not included as a module in loong64 config
20:26:09 <carnil> we discussed that last week already, the change is basically ok and we can enable it, but reporter acked to test and report back that things works as expected
20:26:14 <carnil> so we can wait for that I believe
20:26:17 <bwh> right
20:26:31 <ukleinek> if someone finds the time a MR can already be prepared
20:26:37 <carnil> #topic #1129757: nft: Error: Could not process rule: File exists
20:27:09 <carnil> this is a regression and offending commit should be reverted on next updates to stable series, still asked reporter if can confirm the problem goes away by reverting (not sure we will get a reply though)
20:27:19 <carnil> -> wait and monitor inclusion in next updates
20:27:44 <carnil> #topic #1130114: Please enable usbio module in linux kernel >= 6.18
20:28:20 <carnil> new report, asking for enabling usbio module. The reporter did test with enabled module, but apparently is is not very good quality. Maybe we should still enable the module already for debian/latest?
20:28:45 <bwh> Seems better than nothing. Some work may be needed in libcamera
20:28:54 <ukleinek> sounds fine to me. A bad driver is better than none, and if it's too bad, it can be blacklisted
20:29:08 <bwh> #action bwh will enable modules per #1130114
20:29:28 <carnil> #topic #1130138: linux-image-6.19.6+deb14: RCU stall in unmap_page_range during process exit (regression from 6.18)
20:29:43 <carnil> this is a new report and a regression from 6.18.15 -> 6.19.6
20:30:14 <ukleinek> we had a zoom related issue some time ago, that's different though, right?
20:30:25 <carnil> proprietary userspace (zoom) is involved to exibit the issue
20:30:34 <bwh> ukleinek: Yes that was to do with video capture
20:32:24 <carnil> is it worth asking for bisecting between 6.18.15 and 6.19.6? 6.19.7 should be released soon as well, so maybe rather let the user test that?
20:32:41 <bwh> I have Zoom installed on another user account so I could try to reproduce this, but I suspect it's more complex than just "running Zoom"
20:33:09 <ukleinek> might be worth a try if the effort is low
20:33:15 <carnil> ack
20:33:35 <ukleinek> if the reporter could bisect that would be great
20:33:53 <bwh> #action bwh will try reproduce #1130138 with Zoom
20:34:01 <iam_tj[m]> I've been seeing this on arm64 whilst bringing up kernel on Qualcomm SDM850 based laptop. Saw RCU stalls and BAD PAGE errors (for CMA/DMA); got sent a fix today. Wonder if it is related to this?  f4355d6bb39fc8e53d77
20:34:28 <ukleinek> might be worth to ask if the problem relates to some action with zoom (startup? start of presentation? or something like that)
20:35:12 <bwh> iam_tj[m]: Oh that's interesting, but I don't think CMA is common on x86 is it?
20:35:40 <carnil> iam_tj[m]: hmm, that commit has Fixes: 9bda131c6093 ("mm: cma: add cma_alloc_frozen{_compound}()") and afaict that commit was not backported to 6.19.y (yet)
20:36:52 <iam_tj[m]> carnil:  possibly not a direct fix, but there has been quite a lot of changes to the page/folio handling so wondering if the batch fo changes might be related to the bug
20:37:14 <carnil> ok!
20:37:58 <iam_tj[m]> I'll keep a eye on the bug; the device may still be having RCU issues; dealing with CPU stalls and watchdog NMIs realted to it
20:38:08 <iam_tj[m]> (my device)
20:38:16 <ukleinek> do we wait for bwh's reproduction test, or should we ask already now for a bisection?
20:40:09 <carnil> I would say we can wait for bwh's reproduction test to see if we need help of the reporter to bisect?
20:40:18 <ukleinek> ok
20:40:33 <carnil> #topic
20:40:33 <carnil> #1130097: (i, ) firmware-iwlwifi: intel-ibt-0040-2120.sfi is symlinked to wrong file
20:40:40 <carnil> #topic #1130097: (i, ) firmware-iwlwifi: intel-ibt-0040-2120.sfi is symlinked to wrong file
20:40:52 <carnil> bwh: ^^ on you?
20:41:04 <bwh> #action bwh will forward #1130097 upstream
20:41:17 <carnil> ok done with the buglists
20:41:22 <ukleinek> sounds like a trivial patch
20:41:36 <carnil> #topic Migration excuses
20:41:43 <bwh> ukleinek: If the reporter is correct!
20:42:20 <carnil> linux: we have a couple of OOT modules having regressions zfs-linux, nvidia related ones, but I wonder if we should let these ignore (we did in past) and let linux/6.19.6-1 migrate to testing?
20:42:39 <ukleinek> bwh: right, but it sounds plausible, as they claim that it worked after changing the symlink target
20:44:26 * ukleinek shrugs
20:45:08 <carnil> ukleinek: about the firmware-nonfree bug or about the linux migration to testing?
20:45:20 <ukleinek> about migration
20:47:19 <bwh> Let's be nice to the module packagers and give them a bit longer to fix
20:47:23 <carnil> okay maybe we can wait a bit to see what happens with the OOT modules
20:47:27 <carnil> ack
20:47:31 <ukleinek> if the zfs-linux and nvidia maintainers are aware, let's give them some time
20:48:22 <carnil> the nvidia one should be awaere, there is as well yet the open bug
20:48:36 <carnil> and for zfs-linux I just realized that #1125351 is fixed in unstable
20:48:44 <carnil> so let's wait accordingly a bit
20:48:50 <ukleinek> sounds good
20:49:25 <carnil> for nfs-utils: missingbuild is not anymore true, and AFAICS autopkgtest neither, and it is just now too young yet to migrate -> wait
20:49:38 <bwh> and dracut migrated today
20:49:48 <carnil> +1
20:49:53 <carnil> #topic New upstream versions
20:50:02 <ukleinek> ..ooOO(carnil migrated, too?)
20:50:03 <bwh> I uploaded firmware-nonfree just before the meeting
20:50:14 <ukleinek> 🥳
20:50:18 <carnil> :) perfect
20:50:44 <carnil> I assume nobody has energy right now for 7.0-rcX right? the way would at least be free now in debian/latest if someone wants
20:50:47 * carnil not
20:51:04 <bwh> I don't
20:51:48 * ukleinek never did that before, so would be a big task that I probably don't find the time for next week either.
20:52:00 <carnil> if ukleinek say no as well then let's postpone it
20:52:10 <carnil> #topic Merge requests
20:52:18 <carnil> any MRs which need discussion in the meeting?
20:53:22 <ukleinek> there seem to be a few simple and non-controversial MRs. I will take a look
20:53:31 <carnil> thank you ukleinek
20:54:06 <carnil> #topic AoB?
20:54:18 <ukleinek> KEXEC_HANDOVER and LIVEUPDATE feels big, but I would tend to enable them if it's clear they have no influence when it's not tried to be used
20:55:00 <bwh> Nothing from me
20:55:05 <carnil> afair waldi won't be around and neither ukleinek, so if we want a meeting it's on bwh and me
20:55:14 <carnil> ukleinek: should we wait for 7.1 for that? https://salsa.debian.org/kernel-team/linux/-/merge_requests/1845#note_733161
20:55:17 <ukleinek> I'm here next week
20:55:36 <ukleinek> re !1845: yes, seems like it, also just found that
20:55:40 <bwh> It'll be my turn though
20:55:41 <carnil> you see I got thing wrong then
20:56:00 <carnil> bwh: thank you
20:56:13 <carnil> #action bwh will chair next weeks meeting
20:56:13 <ukleinek> bwh: I can do it next week again as I'm not here in 2 weeks
20:56:25 <carnil> oh still discussion :)
20:56:41 <bwh> I don't mind
20:56:56 <ukleinek> you don't mind me chairing or you keeping it?
20:57:45 <bwh> I'll do it
20:57:50 <carnil> thanks
20:57:53 <ukleinek> ok, thanks
20:58:07 <carnil> so we are at meetings end, thanks all for joining (it was in the end not a short meeting)
20:58:12 <carnil> #endmeeting