Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>

20250409.md

@@ -60,3 +60,190 @@ Chair: @carnil
 |linux|[\#1302](https://salsa.debian.org/kernel-team/linux/-/merge_requests/1302)|⛔|[\[arm64\] udeb: Add onboard\_usb\_dev to usb-modules](https://salsa.debian.org/kernel-team/linux/-/merge_requests/1302)|
 
 ## Minutes
+
+* [\#1088522](https://bugs.debian.org/1088522):
+
+Situation:  RasperryPi, OOT lkrg module, requires config setting enabled, amd64 is enabled.
+
+Surprised that is is not consistent enabled.
+
+Concerns about enabling it, since kconfig help explicitly tells that if concerned about memory, increased size of image.
+
+@benh, @waldi: OOT lkrg module patches symbols to get some auditing to/from it.
+
+Remark: Config is enabled on amd64 because we enabled livepatch on amd64.
+
+Is livepatch for all architctures? Just going for arm64 does not sound right. (ppc64el, s390x, ... major architectures)
+
+@benh: We could ask people ask people (@santiago, @eamanu) working on livepatch implementation.
+
+@ema: livepatch only supported on amd64, but they will need as well the option on arm64 when its ready.
+
+livepatch: is patching arbitrary code and needs know where it is located.
+
+@ema: kprobes as well as arguments to enable the option.
+
+@ukleinek: Is it already techincally possible that depending bootparameter to get all symbols or not?
+
+@benh: possibly there is not not (yet) an option for that. Don't know if there is a mechanism for that.
+
+@ema: technically possible, but there is no bootparameter for that.
+
+@ukleinek: if the boottime parameter would exist, then yes we could go on to enable it on the major architecutres, but not clear now.
+
+@ema: All the other distros have it on.
+
+@enh: Main reason is for debugging and tracing, so enable it on all architectues where we have BTF enabled? 
+
+Agreement: enable it on all architecutes where BTF is enabled. @benh followsup on the MR, @ema will take care.
+
+
+* [\#1101207](https://bugs.debian.org/1101207)
+
+Action: close the bug
+
+* [\#1101944](https://bugs.debian.org/1101944)
+
+@ukleinek: maybe a hardware problem with RAM? Can be.
+
+@ema: could be a memeory problem.
+
+-> Try a memory checker, to see if they have some bad ram.
+
+@benh: we could disaselble the code.
+
+We could look deeper in the code, look into exact failure but first to test hardware
+
+First step memory checks.
+
+@ukleinek: takes action to ask back.
+
+* [\#1102175](https?/bugs.debian.org/1102175)
+
+Kernel is tainted, not the first warning
+
+So we need to get full kernel log
+
+If it is reproducible ask it it on the latest kernel to possible too.
+
+It is 6.12.17. 
+
+so test newer kernel. 6.12.21 6.13.10 from experimental.
+
+@ukleinek: we had similar bug recently.
+
+Action. (@carnil ask for the above informations)
+
+* [\#1102422](https://bugs.debian.org/1102422)
+
+`tpm tpm0: tpm_try_transmit: send(): error -62`
+
+62 is `ETIME 62 Timer expired`
+
+@ukleinek: similar problem on own laptop. kernel parameter, which makes the TPM work, disbled IOMMU to make it work?
+
+  - more information about full kernel log
+
+  - ask if it is a regresson? (maybe it is ....)
+
+  - do noewer kernel work?
+
+  - error reported is quite uncommon. 
+
+  - Reporter uses MrChromebox-4.10, could be a coreboot / firmware bug.
+
+Action: @ema take action to ask for more information.
+
+* [\#1101546](https://bugs.debian.org/1101546)
+
+@waldi: firware possiblly not loaded? 
+
+@benh: suspect BIOS update did reset things harder and made wifi work again
+
+@ema: perhaps windows driver did tune some internal state, so might possible that the BIOS update did reset those.
+
+Action: possible ask for kernel log for working system and nonworking state?
+
+@waldi: the reporter does not have the correct firmware, fails to load every firmware it tries? Linux is not able to load the firwware.
+
+-> We do not have  log for a nonowrking state. 
+
+Linux tries to detect the HW and fails with timeout.
+
+Action: ask to provide full logs of working and non working state, otherwise close. (@waldi)
+
+* [\#1102425](https://bugs.debian.org/1102425)
+
+works with backports kernel, not on bookworm.
+
+User should use first reportbug
+
+Ask for a proper report, if nothing comes back close the bugreport
+
+(maybe close the bug as fixed in bookworm-backports)
+
+@ukleinek takes action.
+
+* [\#1101940](https://bugs.debian.org/1101940)
+
+amdgpu is not only thing broken, we need more logs
+
+should get more information / full.
+
+upstream issue which look similar.
+
+related issues are linked, not not resolution as far we can see.
+
+@benh: amdgpu dkms found bug about the adding of modprobe file, filled upstream
+
+@ukleinek: Okay to wait until next week
+
+@ema: Ask Cordell Bloor, to look at the amdgpu specific, can work for AMD specifically on Debian bugs.
+
+* [\#1102248](https://bugs.debian.org/1102248)
+
+Close the bug, there is nothing to do with with that
+
+-> close the bug.
+
+-> Action: close the bug (@carnil)
+
+# New version 6.15 
+
+@waldi, let's go to 6.14 first. Takes care of updating for experimental.
+
+@benh: preference on 6.14 first so we have a reference package as well.
+
+# Merge reeueqsst
+
+* handbook MR 
+
+@waldi: we should fix the values in the scripts.
+
+* modprobe.d bug report
+
+one problem: implementation either requires debianutils from trixie or `modprobe -c`
+
+considering about `modprobe -c` and filter out things out.
+
+`run-parts` does not properly skip directories which does not exist -> @waldi has to fill a bug
+
+* @ukleinek takes arm64 specific MRs 
+
+  - @ukleinek: [arm64] Enable `ARM_CCA_GUEST` as module important for both flawours? -> so mostly usefull for cloud images but neabled for both.
+
+* Enable `CONFIG_HZ_1000`
+
+@benh posted his statement in the MR.
+
+So just take into consideration just for `debian/latest` not trixie.
+
+Keep it out of trixie
+
+@benh: not saying we should defintively enable them as suggested. They should just be considered as well.
+
+Not urgent, we can see how it moves on.
+
+# AOB
+
+Chair: @benh takes care.