19:00:03 <waldi> #startmeeting
19:00:03 <MeetBot> Meeting started Wed Aug  5 19:00:03 2026 UTC.  The chair is waldi. Information about MeetBot at https://wiki.debian.org/MeetBot.
19:00:03 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:10 <yunseong[m]> Hi
19:00:11 <waldi> welcome to todays meeting
19:00:13 <bwh> Hi
19:00:15 <ukleinek> o/
19:00:18 <waldi> #chair bwh carnil ukleinek
19:00:18 <MeetBot> Current chairs: bwh carnil ukleinek waldi
19:00:36 <waldi> anything we should discuss first?
19:00:47 <carnil> hi
19:00:48 <ukleinek> nothing I'm aware of
19:01:02 <bwh> Nothing urgent from me
19:01:12 <carnil> nothing
19:01:21 <waldi> then we can go straight into our long list of bugs
19:01:33 <waldi> #topic #1126671: (S, M) linux-image-6.17.13+deb13-amd64: Disconnect root (path=/) during heavy load on NvME, partial corruption on NTFS.crash soon but not yet
19:01:48 <waldi> this waits for the submitter
19:02:00 <ukleinek> oh cool
19:02:01 <bwh> right
19:02:19 <waldi> #topic #1141969: (i, M) linux-image-7.1.3+deb14-amd64: Cannot shutdown computer
19:02:42 <waldi> here i got a bit lost
19:03:02 <ukleinek> is it a regression?
19:03:11 <bwh> Yes, from 7.0 to 7.1
19:03:57 <bwh> not fixed in 7.2, but they consider bisection risky
19:05:02 <ukleinek> I wouldn't fear bisecting, but I think it would be unfair to talk them into it.
19:05:17 <bwh> right
19:05:35 <bwh> Since this is reproducible in 7.2 can we take it upstream anyway?
19:05:48 <waldi> and those are two possibly unrelated problems in one report
19:05:56 <waldi> yes
19:05:57 <ukleinek> I wonder if there are kernel messages about the issue
19:06:50 <bwh> waldi: Ah, I missed that this is not the original reporter
19:08:18 <bwh> Now we have 3 reporters, maybe with all different bugs
19:08:19 <ukleinek> there are even three people contributing to that bug
19:09:24 <bwh> I think maybe someone should ping the original reporter
19:09:33 <waldi> and with hardware of vastly different vintage. the submitter from 2022, the others from 2010
19:09:37 <ukleinek> and split the bug in 3?
19:10:02 <ukleinek> is it clear that it's a regression for all from 7.0 even?
19:10:30 <waldi> no. the submitter did not teil when or if it ever worked
19:11:01 <bwh> But probably was for them, as this was "the latest kernel update"
19:11:02 <ukleinek> four reporters even
19:11:11 <bwh> For "simon" it's not clear
19:12:34 <bwh> for Martin Steigerwald and Ole, definitely  reported as a regression from 7.0 to 7.1
19:12:40 <ukleinek> #action ukleinek responds to the original submitter of #1141969 and asks the other contributors to create a separate bug
19:12:57 <carnil> should we simply try to rebootstrap the bug with the original reporter and mention to the other involved to please fill new bugreport if the experience similar issues so we can disentangle bit things?
19:13:01 <carnil> ok
19:13:18 <waldi> #topic #1142099: (i, M) /usr/share/bug/linux-image-6.12.95+deb13-amd64-unsigned/include-1cmdline: Kernel 6.12.95 does not start boot sequence without setting acpi=off or recovery mode (logs in this mode)
19:13:45 <bwh> Still waiting for the reporter
19:13:57 <waldi> #topic #1142863: (i, M) linux-image-6.12.96+deb13-amd64: S3 (deep) suspend powers the machine off instead of suspending
19:14:06 <waldi> also waiting
19:14:20 <waldi> #topic #1143268: (i, Mu) linux-image-6.12.100+deb13-amd64: HID++ devices broken, ghost keyboard events, systemd-modules-load failure
19:15:24 <carnil> this one is very odd, the bisect result does not make sense so maybe the whole problem is a followup problem, we did not have a full kernel log right?
19:15:44 <waldi> no log provided, no hardware information
19:16:01 <carnil> (/me is bit fed up with reports which are lengthly and feels like ai assistent generated)
19:16:09 <bwh> I also got that impression
19:16:11 <ukleinek> nvidia hardware and the reporter talks about the problem being a followup problem to not being able to load the nvidia modules
19:16:55 <ukleinek> ah, but nvidia was ruled out as culprit
19:17:45 <ukleinek> ack, bisection result looks bogous
19:18:31 <bwh> "The system becomes  completely unusable as no keyboard input is recognized, not even at the GRUB level on subsequent boots."
19:18:32 <ukleinek> "this might indicate a build/patch ordering issue in the 6.12.100 stable release" is non-sense
19:18:46 <bwh> I can't work out what's real information and what's slop
19:18:50 <bwh> I vote to close it
19:19:12 <ukleinek> +1
19:19:13 <carnil> +1
19:19:25 <waldi> please do
19:19:27 <bwh> #action bwh will close #1143268 as incoherent slop
19:19:35 <waldi> #topic #1143269: (i, ) linux: Fatal error during GPU init
19:20:01 <waldi> this is also weird and we lack a log that shows what is claimed. slop as well?
19:20:37 <waldi> the xrandr reference makes no sense at all
19:20:42 <bwh> The diagnostic is slop
19:21:20 <bwh> The rest looks plausible but they've bypassed the reportbug script somehow :-/
19:21:55 <ukleinek> does the graphical installer also use the amdgpu driver?
19:22:15 <bwh> I don't think so
19:23:00 <bwh> Let's ask for lspci (+ whatever options we use in the bug script) and kernel log
19:23:08 <ukleinek> let them test the backports kernel?
19:23:09 <yunseong[m]> Is there a way to check whether the sender used the reportbug tool in the debian mailing list?
19:23:45 <ukleinek> yunseong[m]: I don't understand the idea
19:23:50 <bwh> Pretty sure this comes through reportbug, but they reported against "linux" and not the right binary package
19:23:52 <waldi> X-Mailer: reportbug 13.2.0
19:24:09 <bwh> Maybe we should ask the reportbug maintianers to map "linux" to linux-image-$(uname -r), the same as it does for "kernel"
19:24:16 <waldi> so yes, they used reportbug, but neither the correct package nor version
19:24:34 <waldi> can't we provide /usr/share/bugs/linux?
19:25:12 <waldi> anyway, what to do?
19:25:35 <carnil> I guess we should go with:
19:25:36 <carnil> < bwh> Let's ask for lspci (+ whatever options we use in the bug script) and kernel log
19:25:41 <yunseong[m]> ukleinek: Aha, It seems that many bug reports are being generated with AI rather than submitted via reportbug, and therefore do not include the necessary attachments..
19:25:43 <carnil> and then see what happens
19:26:02 <carnil> I can do
19:26:24 <ukleinek> sounds good, thanks. Maybe ask for a test for 7.whateverwecurrentlyhaveinbackports
19:26:32 <carnil> ack
19:27:10 <carnil> #action carnil responds to #1143269 asking for lspci (with options from bug scripts), kernel log, plus testing with newer versions from backports
19:27:17 <waldi> thx
19:27:25 <waldi> #topic #1143500: (i, u) The Lenovo Legion Y9000X 2021 (Realtek ALC287 + Cirrus CS35L41) has no sound output through external speakers, but the headphones work normally
19:27:37 <bwh> #action bwh will look at making "reportbug linux" DTRT
19:28:24 <ukleinek> "I was unable to
19:28:26 <ukleinek> reproduce this bug using the Debian version of Plasma."
19:29:18 <ukleinek> so the problem is in KDE newer than packaged for stable and not the kernel?
19:30:04 <bwh> ukleinek: Not sure which bug you are reading that in?
19:30:30 <bwh> This one seems like legit missing hardware support
19:30:33 <ukleinek> right, not 1143500
19:31:04 <bwh> I suppose we should ask to test a backports kernel
19:32:08 <carnil> ok
19:33:29 <carnil> no volunters
19:33:30 * ukleinek agrees, sounds like it needs a quirk
19:33:30 <carnil> I will ask
19:34:04 <carnil> #action carnil ask reporter of #1143500 if newer kernel from backports properly support the device
19:34:10 <waldi> #topic #1139265: (n, M) linux-image-7.0.10+deb14-amd64: QXL graphics crash, processes stuck in D state, NULL-dereference errors, TTY-subsystem malfunction
19:34:35 <ukleinek> this is the bug I looked at before
19:34:42 <waldi> possible fix found. submitter will test when it landed
19:34:44 <waldi> yes
19:34:45 <bwh> right
19:35:04 <waldi> #topic #1141869: (n, M) linux-image-6.12.95+deb13-amd64: USB-C monitor that worked on Debian 12 fails on Debian 13 with "no signal"
19:35:26 <bwh> The reporter needs help with bisection
19:35:49 <carnil> yes seen the reply today, I can followup
19:36:05 <bwh> I'll remove the moreinfo tag for now
19:36:53 <carnil> yes
19:37:30 <waldi> #topic #1142419: (n, u) 7.1.3 does not resume "i915 0000:00:02.0: [drm] pipe state doesn't match!"
19:37:40 <bwh> Waiting on upstream
19:37:58 <waldi> #topic #1142489: (n, M) linux-image-7.1.3+deb14-amd64: nouveau 0000:01:00.0: Xorg[1491]: failed to idle channel 4 [Xorg[1491]]
19:38:14 <waldi> waiting on submitter
19:38:17 <bwh> right
19:38:23 <waldi> #topic #1142626: (n, M) linux-image-6.12.96+deb13-amd64: Debian 13 kernel has poor disk I/O for Windows guest on QEMU
19:38:51 <waldi> waiting on submitter
19:38:51 <ukleinek> the #1142489 submitter is using xorg and should consider wayland?
19:40:56 <waldi> #topic #1142881: (n, ) linux-image-armmp > 6.1 boot error UUID=... or LABEL=... does not exist but exists
19:41:35 <bwh> This is either a necessary driver missing from the armmp config, or from the initramfs
19:42:33 <ukleinek> #action ukleinek looks into #1142881 and tries to find the missing driver
19:42:43 <bwh> Thank you
19:42:54 <waldi> #topic #1142912: (n, +) linux-image-6.12.96+deb13-amd64: CONFIG_MISC_ALCOR_PCI not set, no driver for Alcor Micro AU6625 card reader
19:43:23 <KGB> 03linux 05debian/latest 06Ben Hutchings * [update] merge request !2039: Add support for Alcor Micro AU6625 PCI-E Flash card reader * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/2039
19:43:57 <bwh> I just tagged that for backporting
19:44:12 <bwh> I can check and merge it later this evening
19:44:17 * ukleinek wonders about (Closes: ...) twice in the MR
19:44:34 <waldi> #topic #1143143: (n, M) RAID10 rebuild high CPU low throughput after upgrade from Bookworm
19:45:10 <waldi> no information, submitter asked to recheck with latest version. nothing to do
19:45:21 * ukleinek nods
19:45:27 <waldi> #topic #1143161: (n, +M) linux-image-6.12.96+deb13-amd64: X does not start on DisplayPort of NVIDIA Quadro 600 with nouveau
19:45:48 <bwh> waldi: Raptor only made one model of computer AFAIK :-)
19:46:23 <waldi> wait on submitter communicating with upstream
19:46:32 <bwh> OK
19:46:38 <waldi> #topic #1143255: (n, M) Bug in kernel 6.12.100
19:46:51 <bwh> Great bug subject
19:47:02 <carnil> asolutely :)
19:47:10 <ukleinek> + "NVIDIA proprietary driver"
19:47:26 <waldi> yes. wasn't there a problem to build the nvidia stuff with 6.12.100?
19:47:41 <bwh> + repro requires proprietary game
19:48:03 <carnil> waldi: yes for nvidia-open-kernel-dkms
19:48:27 <ukleinek> "dear reporter, please provide a license for that game to the kernel team"
19:49:47 <waldi> submitter was asked to provide more information, so wait
19:50:03 <waldi> #topic #1143450: (n, ) linux-image-6.12.94+deb13-amd64: hibernate on toughbook CF-C2 does not power off fully
19:50:31 <waldi> submitter was asked to provide more information, so wait
19:50:41 <waldi> #topic #1143506: (n, ) linux-image-7.1.3+deb13-amd64: fails to complete shutdown after extended uptime, session-2.scope stop timeout
19:51:09 <ukleinek> bug text in X-Debbugs-Cc is a new variant
19:51:52 <bwh> This might be related to (one of) the bugs in the report we wanted to split
19:52:09 <waldi> or to the external modules
19:52:14 <bwh> yes
19:52:31 <bwh> a whole lot of vendor magic
19:53:06 <bwh> Is it worth asking to test without those, or should we suggest reporting to Clevo?
19:53:18 <waldi> did anyone find a reference to that session-2.scope somwhere in a log?
19:54:16 <ukleinek> +1 for testing without clevo OOT modules
19:54:45 <waldi> #action waldi responds to #1143506, asking for test without external modules or report to clevo
19:54:59 <waldi> #topic #1143545: (n, ) kernel: performance regression in 6.12.x series kernel
19:55:38 <ukleinek> we had a disk speed regression already before, right?
19:56:15 <bwh> Yes, #1143143
19:56:31 <carnil> giben the reporter claims to have found the regression introducing commit and fixing commit (not backported to 6.12.y) ask to test and let him ask stable list to backport the commit?
19:56:51 <carnil> s/giben/given/
19:57:00 <ukleinek> and maybe let the reporter of #1143143 test /sys/kernel/mm/lru_gen/enabled=0
19:57:16 <bwh> but I really doubt these are related
19:57:44 <bwh> this is specifically about VM paging
19:58:01 <ukleinek> I wouldn't be surprised and the test is trivial
19:58:16 <bwh> RAID syncing should not have anything to do with that
19:59:02 * ukleinek doesn't understand what the sysfs file does, so I believe you
19:59:50 <carnil> what is surprising
20:00:05 <carnil> the 14aa8b2d5c2e ("mm/mglru: don't sync disk for each  aging cycle")  commit is in v6.1-rc1
20:00:20 <carnil> so how the claim "After upgrading from 6.1 series kernel to 6.12.x series kernel [...]"?
20:00:39 <carnil> ah maybe we enabled MGLRU only later
20:01:02 <ukleinek> 14aa8b2d5c2e is the designated regression introducer
20:01:24 <carnil> v6.1-rc1: 14aa8b2d5c2ebead01b542f62d68029023054774 mm/mglru: don't sync disk for each aging cycle
20:01:43 <bwh> linux (6.4~rc7-1~exp1) experimental; urgency=medium
20:01:43 <bwh> * mm: Enable Multi-Gen LRU implementation (by default) (Closes: #1030617)
20:04:41 <carnil> so I sill think: ask the reporter to confirm he tested the commit to fix the issue, and secondly let him ask stable maintainers to pick the backport? I'm not sure we should take reponsibility for backporting mm/ changes, this should be validated by Andrew Morton and other involved in the change IMHO
20:04:52 <carnil> (and keep us looped in)
20:05:00 <carnil> so we can close the bug once it lands in a stable eries
20:05:07 <carnil> in a new 6.12.y stable series version
20:05:18 <bwh> #action bwh will ask for backport to fix #1143545
20:05:29 <ukleinek> thx
20:05:50 <waldi> #topic AoB
20:05:58 <waldi> anything else we should talk about?
20:06:06 * ukleinek can chair next week
20:06:24 <waldi> #action ukleinek chairs next week
20:06:47 <carnil> thanks
20:06:59 <waldi> thank you all for attending
20:07:02 <waldi> #endmeeting