19:00:43 <bwh> #startmeeting
19:00:43 <MeetBot> Meeting started Wed Jul  1 19:00:43 2026 UTC.  The chair is bwh. Information about MeetBot at https://wiki.debian.org/MeetBot.
19:00:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:43 <ukleinek> o/
19:00:46 <carnil> hi
19:01:12 <eamanu> hi o/
19:01:18 <bwh> Hi all
19:02:18 <bwh> Any urgent issues before we get into the bug list?
19:02:25 <ukleinek> Idk
19:02:34 <waldi> no
19:02:40 <carnil> no
19:03:04 <bwh> OK, let's triage bugs
19:03:11 <bwh> #topic #1126671: (S, ) 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:03:26 * ukleinek recognizes that one :-D
19:03:40 <bwh> I really meant to try writing something today and then I had other things to do
19:03:41 <waldi> nothing new
19:04:01 <bwh> So, we will keep our actions
19:04:07 * ukleinek nods
19:04:09 <bwh> #topic #1138242: (S, u) linux-image-6.12.90+deb13.1-riscv64-dbg and linux-image-6.12.90+deb13.1-s390x-dbg have an undeclared file conflict (forwarded: linux-s390, lore.kernel.org, lore.kernel.org, lore.kernel.org, lore.kernel.org, lore.kernel.org)
19:04:50 <bwh> Since most of the patches have been applied to the architecture trees, should we apply them to the package already?
19:05:25 <waldi> i wonder if i should have sent that to stable@. but lets add them to stable, some might not be applicable
19:06:12 <bwh> OK
19:06:17 <carnil> I think we should ask then maybe for backporting those to the relevant stable series which are relevant for us?
19:06:50 <carnil> and then we get the fixes automatically along on rebases?
19:06:54 <ukleinek> do the stable guys do something like that, i.e. backport to 6.12 but not the newer ones?
19:06:56 <bwh> yes
19:07:18 <waldi> okay, then lets do that
19:07:41 <bwh> ukleinek: all fixes for one stable branch should alos be present in newer stable branches (unless e.g. the code was remvoed)
19:08:32 <ukleinek> bwh: sounds sensible, so we cannot skip e.g. 6.18 for the backports.
19:08:48 <bwh> waldi: Can you handle that too?
19:09:04 <waldi> yeah, i'll see to it
19:09:10 <ukleinek> \o/
19:09:22 <carnil> thanks waldi
19:09:31 <bwh> #action waldi will submit vDSO build salt fixes t ostable
19:09:42 <bwh> #topic #1128315: (i, M) Reproducible GPU hang and failed reset in Firefox playing a game
19:10:40 <bwh> We never heard back from Josh on this so maybe we should close it
19:11:19 <ukleinek> #action ukleinek will ping Josh and close #1128315 on continued silence
19:11:40 <bwh> Thanks
19:11:50 <bwh> #topic #1129033: (i, Mu) iwlwifi: WARNING in _iwl_mvm_sec_key_del with hostapd on 6.12.73+deb13-amd64 (AP mode)
19:12:22 <bwh> Oh this is closed
19:12:33 <bwh> but still affects trixie?
19:12:46 <ukleinek> yes
19:13:22 <ukleinek> carnil: thanks for fixing my fixed marking
19:13:37 <bwh> I need to check that find-recent-urgent won't filter it out in future...
19:13:42 <carnil> ukleinek: I missed one bit, should remove 7.0.10 and add a 'trixie' tag
19:13:57 * ukleinek just removed 7.0.10
19:14:17 <carnil> (the later only if we are aiming to get the reporter to further investigate and get a fix in 6.12.y as well)
19:14:28 * ukleinek did it
19:14:30 <bwh> I don't think that a trixie tag is appropriate
19:15:14 <bwh> "trixie" means "this bug applies if other packages come from trixie" not "this bug applies to the version in trixie"
19:15:19 <ukleinek> sigh
19:16:25 <bwh> Anyway we are waiting on the reporter, so no action required now, right?
19:16:37 <ukleinek> ack
19:16:46 <bwh> #topic #1140770: (i, ) [7.0] Panic in mt76/mt7921 hardware monitor
19:17:38 <bwh> Crash log is at the end of the message
19:18:03 <carnil> trixie tag can as well be used to make sure a bug won't be archived until fixed in that release. but yes agree let's not add any release tags
19:18:14 <ukleinek> are spl and zenergy related to zfs?
19:18:17 <bwh> carnil: Oh I see, good point
19:18:20 <bwh> TIL
19:18:37 <waldi> spl is. zenergy not
19:18:42 <bwh> ukleinek: spl yes, but zenergy is a hardware monitor driver for Zen processors
19:20:07 <carnil> I guess it is not sensible to ask to reproduce without the oot modules here?
19:20:07 <bwh> As the crash is in mt7921's hwmon I wondered whether zenergy could be interefering with that. But hwmon is barely a subsystem and I think they are unlikely to interact
19:20:59 <ukleinek> the trappin instrucion is mov    %r12d,(%r8)
19:21:22 <bwh> I actually dug into this and it's filling in a DMA descriptor there
19:21:25 <ukleinek> carnil: without zfs they might not have a rootfs
19:21:55 <bwh> We could ask to try without zenergy, though I doubt it will make a difference
19:23:13 <ukleinek> Is the beginning of the trace cut off? I would have expected a message mentioning e.g. a NULL pointer exeception
19:24:12 <bwh> Yes, seems like it. The r8 pointer is non-null and is canonical so it's not obvious what the exception is
19:24:27 * ukleinek wonders about mt7921_mcu_get_temperature in the back trace
19:24:31 <bwh> Besides that, we could ask whether this happened only once or multiple times, and whether it's a regression
19:25:23 <bwh> ukleinek: As I said this is a hwmon driver in the wifi driver. And that ends up sending a command to the wifi microcontroller through a DMA ring...
19:25:40 <ukleinek> ah, this is dma, but not to send a packet but to read out a register .. exactly
19:25:56 <bwh> So who will ask the questions?
19:26:19 <ukleinek> There is no locking?!
19:26:33 <carnil> I can try to volunteer, but it looks ukleinek has more ideas :)
19:26:43 <ukleinek> ok
19:27:02 <carnil> ok = you take it?
19:27:02 <bwh> #action ukleinek will respond to #1140770
19:27:13 * ukleinek nods
19:27:15 <waldi> can we enlarge the qr log dumps?
19:27:31 <waldi> because this is the second time in a short while, where a few lines at the beginning are missing
19:27:50 <bwh> waldi: You mean, increase the log length? I think I already set it to the maximum length
19:27:57 <waldi> mist
19:28:04 <ukleinek> Nebel?
19:28:10 <bwh> but please do check that
19:28:14 <waldi> will do
19:28:21 <bwh> #topic #1140892: (i, u) thunderbolt: Intel Goshen Ridge CL state regression breaks dock tunneling since 6.12.94
19:28:51 <bwh> The reporter also reproduced this with older versions, so not  a regression. But it may be something the kernel could work around
19:29:15 <carnil> bwh: see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140892#22
19:29:29 <carnil> my undersranding was here that it is a hw problem with the dock?
19:29:42 <bwh> All hardware has bugs and the kernel works around a lot of those
19:29:42 <carnil> but I was hesistating to close until we had it discussed in the meeting
19:30:20 <bwh> So it may still be worth forwarding upstream to see if anyone cares to implement a workaround
19:31:11 <ukleinek> The crucial question is if this is a defect that this individual dock has, or if it's a problem of that product line
19:31:22 <ukleinek> the reporter seems to assume the former?!
19:31:47 <bwh> Oh that is a possibility
19:32:54 <bwh> but I would suspect firmware bug.
19:33:05 <bwh> Oh, it is probably worth checking for a firmware update, too
19:33:16 * ukleinek was about to just write that
19:33:22 <bwh> I believe fwupd can update some docks
19:34:37 <ukleinek> ok, so we need a volunteer again
19:34:53 <bwh> Is anyone familiar enough with fwupd to tell the reporter how to check / update the firmware?
19:34:59 <ukleinek> eamanu: you want to get your hands dirty?
19:35:18 <eamanu> yep :-D
19:35:53 <carnil> fwupdmgr get-updates should show if there are updates pending / available
19:35:56 <ukleinek> ISTR that `fwupdmgr get-devices` is the command to check
19:36:28 <ukleinek> yeah, different infos / advantages in get-updates vs get-devices
19:37:26 <bwh> #action eamanu will ask reporter of #1140892 to check for dock firmware updates
19:37:27 <eamanu> yes I can try
19:37:27 <bwh> OK?
19:37:34 <eamanu> yep
19:37:37 <eamanu> ty
19:37:37 <bwh> Thanks
19:37:42 <ukleinek> \o/, thanks you
19:37:44 <bwh> #topic #1141137: (i, ) [7.0] BUG at fs/iomap/buffered-io.c:1061 with ntfs3
19:38:21 <bwh> I've put ntfs3 in the title of this because the reporter thinks that's at fault, although btrfs also uses iomap
19:38:36 <carnil> the reporter claims there are other reports, I wanted to check if there matching ones today but did not found time
19:39:10 <ukleinek> a full dump would be helpful
19:39:34 <bwh> carnil: They said Cachyos, so there's this: https://discuss.cachyos.org/t/kernel-bug-in-iomap-write-end-triggered-by-ntfs3-buffered-write-linux-7-0-1-cachyos/28546
19:42:58 <waldi> and i say AI
19:43:10 <carnil> https://lore.kernel.org/ntfs3/2020820791.1843094.1777717495048@mail1.libero.it/ is then the mailing list post
19:43:14 <bwh> https://github.com/CachyOS/linux-cachyos/issues/841 has a comment referrring (indirectly )to commit 36ee1313199b7f16bf963c6ac0241861585125d9 as a possible fix
19:43:53 <bwh> That's in 7.1 and not 7.0-stable
19:44:16 <bwh> So we could ask to try with that (if it even applies and isn't part of a longer series)
19:45:13 <ukleinek> the bugon that was triggered is about iomap_inline_data_valid(), so sounds plausible
19:45:18 <carnil> or we ask if he can test the experimental one
19:45:26 <carnil> because after the 7.0.14-1 uload 7.0.y is EOL
19:45:34 <carnil> and we should move to 7.1.y in unstable
19:45:38 <ukleinek> +1 for experimental, assuming this is reproducible
19:45:48 <bwh> oh right, yes that makes more sense
19:46:13 <carnil> I can take an action to ask
19:46:39 <ukleinek> #action carnil asks for a test on a newer kernel for #1141137
19:46:47 <carnil> (and btw, sorry the 7.0.14-1 upload got delayed because d-i should first transit to testing before we can make the final 7.0.y upload)
19:47:51 <bwh> We might need to swap CONFIG_NTFS3_FS for CONFIG_NTFS_FS in 7.1...
19:48:11 <bwh> I lost track of the competing NTFS implementations but I think CONFIG_NTFS_FS is the latest attempt
19:49:06 <ukleinek> latest = bestest?
19:49:11 <waldi> yes
19:49:30 <tarzeau_> ukleinek: the ntfs from the same person that did the better vfat (samsung employed) is really good
19:49:42 <carnil> yes I guess if the paragon people do not wake up a bit more then possibly there will be a new 'preferred' one as per above
19:50:02 <bwh> Oh right, NTFS is based on the *older* one but has had a lot of fixes (see https://lwn.net/Articles/1055062/ )
19:50:22 <bwh> I mean NTFS_FS / fs/ntfs
19:50:59 <bwh> So should be switching already?
19:51:28 <carnil> we can try :)
19:51:51 <carnil> surely someone will comlain, and ask why we do not keep ntfs3 as well ;-)
19:51:55 <bwh> #action bwh will update config to enable ntfs instead of ntfs3
19:52:09 <bwh> #topic #1141183: (i, u) src:linux: I/O errors on SATA devices related to IOMMU
19:52:25 <bwh> Oh
19:52:59 <bwh> #action bwh will respond to #1141137 to ask to re-test with the new old ntfs
19:53:30 <bwh> iam_tj[m]: Are you around to discuss this bug?
19:53:48 <ukleinek> funny disclaimer
19:54:05 <bwh> yes
19:55:21 <bwh> Does anyone else have an idea what to do about this bug?
19:56:26 <bwh> iam_tj[m]: Sorry, it looks like we are leaving this with you for now
19:56:33 <waldi> firmware upgrade required
19:56:33 <bwh> #topic #1135780: (n, ) nouveau: driver caused graphical session to become unresponsive
19:57:52 <bwh> This actually seems to be 2 different bugs - the first was a hang and the second is a null pointer deref
19:58:37 <waldi> the null pointer kills something while holding a lock, the the hang is just an effect?
19:58:38 <bwh> I suppose this can be forwarded to nouveau upstream
19:58:51 <bwh> waldi: The hang message showed "Not tainted"
19:58:53 <ukleinek> ask for a test of 7.1 first?
19:59:26 <waldi> bwh: right
20:00:22 <bwh> ukleinek: I suppose, but I have the impression that this is not so easy to reproduce
20:00:50 <ukleinek> which might explain the reporter latency
20:01:19 <bwh> carnil: What do you think?
20:02:15 <carnil> bwh: only spotted the update yestreday and did make sure to remove the moreinfo tag, but I guess I will ask a couple of questions how easy the reporter cn reprododuce and if they can test 7.1.y directly
20:02:35 <carnil> migth be a frustrating experience for the reporter but I have no better idea to redirect to test 7.1
20:02:47 <bwh> #action carnil will respond to #1135780 again
20:02:49 <bwh> OK
20:02:55 <bwh> #topic #1141185: (n, ) linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.
20:04:28 <bwh> I agree with iam_tj[m] that this looks like bad RAM (or something else in the memory subsystem)
20:05:22 <bwh> So can someone reply to the reporter to ask them to run a memory test?
20:05:44 * ukleinek would read that out of tj's message already
20:05:52 <bwh> It was not sent to the reporter...
20:06:48 <carnil> ah right, so yes let's just followup on iam_tj[m]'s mail including 1141185-submitter@b.d.o
20:07:04 <carnil> to make sure the reporter get the question if not subscribed to the bug
20:07:08 <ukleinek> #action ukleinek will forward tj's to the reporter to make sure they are aware of the request
20:07:47 <bwh> Thank you
20:08:02 <bwh> OK, let's skip the wishlist bugs
20:08:12 * ukleinek inserts "message" to that #action line
20:08:20 <ukleinek> thank you
20:08:49 <bwh> and the dracut bugs, because I don't think there's much to say there
20:09:04 <bwh> #topic Migration excuses
20:09:16 <bwh> dracut is waiting for autopkgtest runs; I don't see any failures
20:09:23 <bwh> or, not any failures that are blockers
20:09:55 <bwh> #topic New upstream versions
20:11:16 <bwh> carnil: Did you upload 7.0.14-1 already?
20:11:40 <carnil> bwh: no as mentioned earlier, d-i folks (kibi) asked to wait
20:11:46 <carnil> until his green light
20:11:51 <carnil> because of the d-i upload
20:12:00 <ukleinek> d-i has "Too young, only 2 of 5 days old
20:12:02 <ukleinek> "
20:12:08 <bwh> Depending on how long that wait is, would it make sense to go straight to 7.1.y then?
20:13:00 <carnil> yes, but we have to wait anyway until d-i migrates to not interfer with their work right?
20:13:04 <bwh> of course
20:13:08 <carnil> ok :)
20:13:48 <carnil> then we are on same page, I do not mind neither if we do 7.0.14-1 quickly superseeded by 7.1.y just to make sure we have uploaded to the archive the last version as well which is prepared in the branch
20:14:36 <carnil> main reason to have 7.0.14 first would be the couple of security fixes to get in
20:14:42 <waldi> i read the mails as if we are free to upload
20:14:42 <bwh> I would prefer to go to 7.1.y, but you will likely be doing it so I will not tell you what to do  :-)
20:15:02 <carnil> in case 7.1.y has problems preveitnng us to let iit migrate  to testing
20:15:46 <bwh> #action bwh will update firmware-nonfree to 20260622 soon
20:16:01 <KGB> 03linux 05debian/latest 06Uwe Kleine-König * [approved] merge request !2004: [sparc64] udeb: scsi-modules: Use the default module list * 14https://salsa.debian.org/kernel-team/linux/-/merge_requests/2004
20:16:13 <bwh> carnil: I will leave you to give yourself an action if you want
20:16:22 <bwh> #topic Merge requests
20:16:29 <carnil> bwh: ack
20:16:41 <bwh> Does anyone want to discuss any of these?
20:16:59 <carnil> #action carnil takes care of either upload 7.0.14-1 first and then 7.1.y or go straight to 7.1.y (+ asks d-i folks about green light to go)
20:17:27 <ukleinek> carnil: I wonder about https://salsa.debian.org/kernel-team/linux/-/merge_requests/2003, doesn't this come via stable?
20:17:31 <carnil> btw about new versions, will someone work on 7.2-rcX?
20:17:56 <waldi> yes
20:18:12 <carnil> ukleinek: yes, but it is not yet queued and depends when bwh will do the upload for bookworm-security if we want to pick it up in advance
20:18:15 <carnil> the issue is serious enough
20:18:45 * ukleinek works on 7.2-rc2, but not 7.2~rc2-1 :-P
20:19:37 <bwh> #topic AOB
20:20:24 <waldi> we talked about 7.1 and 7.2, nothing from me
20:20:29 <bwh> So, who will chair next week?
20:21:10 <waldi> me
20:21:12 * ukleinek won't be able to join next week
20:21:28 <bwh> #action waldi will chair next week
20:21:30 <bwh> waldi: Thanks
20:21:38 <bwh> and thanks all for attending
20:21:44 <carnil> bwh: thanks a lot for preparing the meeting!
20:21:47 <bwh> Sorry it dragged on so long
20:21:49 <ukleinek> bwh: thanks for preparing and leading through the meeting
20:21:51 <bwh> #endmeeting