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