kernel December 2022

kernel@lists.fedoraproject.org

11 participants
49 discussions

[OS-BUILD PATCH] redhat: Remove cpupower files
by Prarit Bhargava (via Email Bridge) 09 Dec '22

09 Dec '22

From: Prarit Bhargava <prarit(a)redhat.com> redhat: Remove cpupower files The cpupower.config and cpupower.service files no longer serve a purpose. System level performance control is generally controlled by tuned and other system applications. Remove the cpupower files from the kernel. Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> diff --git a/redhat/Makefile b/redhat/Makefile index blahblah..blahblah 100644 --- a/redhat/Makefile +++ b/redhat/Makefile @@ -626,8 +626,7 @@ sources-rh: $(TARBALL) generate-testpatch-tmp setup-source dist-configs-check @sed -e "s/%%SPECKVERSION%%/$(SPECKVERSION)/" \ -e "s/%%SPECKPATCHLEVEL%%/$(SPECKPATCHLEVEL)/" \ rpminspect.yaml > $(SOURCES)/rpminspect.yaml - @cp cpupower.* \ - keys/rhel*.x509 \ + @cp keys/rhel*.x509 \ kabi/check-kabi \ configs/$(PACKAGE_NAME)-*.config \ configs/partial*.config \ diff --git a/redhat/cpupower.config b/redhat/cpupower.config deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/cpupower.config +++ /dev/null @@ -1,3 +0,0 @@ -# See 'cpupower help' and cpupower(1) for more info -CPUPOWER_START_OPTS="frequency-set -g performance" -CPUPOWER_STOP_OPTS="frequency-set -g ondemand" diff --git a/redhat/cpupower.service b/redhat/cpupower.service deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/cpupower.service +++ /dev/null @@ -1,13 +0,0 @@ -[Unit] -Description=Configure CPU power related settings -After=syslog.target - -[Service] -Type=oneshot -RemainAfterExit=yes -EnvironmentFile=/etc/sysconfig/cpupower -ExecStart=/usr/bin/cpupower $CPUPOWER_START_OPTS -ExecStop=/usr/bin/cpupower $CPUPOWER_STOP_OPTS - -[Install] -WantedBy=multi-user.target diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template index blahblah..blahblah 100755 --- a/redhat/kernel.spec.template +++ b/redhat/kernel.spec.template @@ -840,8 +840,6 @@ Source300: kernel-abi-stablelists-%{kabiversion}.tar.bz2 Source301: kernel-kabi-dw-%{kabiversion}.tar.bz2 # Sources for kernel-tools -Source2000: cpupower.service -Source2001: cpupower.config Source2002: kvm_stat.logrotate # Some people enjoy building customized kernels from the dist-git in Fedora and @@ -2591,9 +2589,6 @@ mv cpupower.lang ../ popd %endif chmod 0755 %{buildroot}%{_libdir}/libcpupower.so* -mkdir -p %{buildroot}%{_unitdir} %{buildroot}%{_sysconfdir}/sysconfig -install -m644 %{SOURCE2000} %{buildroot}%{_unitdir}/cpupower.service -install -m644 %{SOURCE2001} %{buildroot}%{_sysconfdir}/sysconfig/cpupower %endif %ifarch x86_64 mkdir -p %{buildroot}%{_mandir}/man8 @@ -2739,15 +2734,6 @@ popd ### %if %{with_tools} -%post -n kernel-tools -%systemd_post cpupower.service - -%preun -n kernel-tools -%systemd_preun cpupower.service - -%postun -n kernel-tools -%systemd_postun cpupower.service - %post -n kernel-tools-libs /sbin/ldconfig -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2125

2 1

[OS-BUILD PATCHv2] Check for kernel config git-push failures
by Don Zickus (via Email Bridge) 09 Dec '22

09 Dec '22

From: Don Zickus <dzickus(a)redhat.com> Check for kernel config git-push failures An automated nightly job is run to merge the upstream tree and check for new configs to be set. The new configs are automatically added to the redhat/configs/pending-ark directory and pushed. A second script then comes along and walks through those new configs and converts them into automatically generated config MRs for review. Those MRs periodically fail to git-push due to infrastructure issues. The script reports success and the maintainers never realize an MR failed to be created until a pending config audit is performed before the GA release. Let's update the script to check for those failures and report them (by failing the script). The script failure leads to an email to the maintainer who can then re-run the script by hand to regenerate the MRs or fix issues manually. Tested by * committing dummy change to Makefile * git push -o merge_request.create dzickus dummy * committing second dummy change to Makefile * git push -o merge_request.create dzickus dummy (git push succeeds with following warning message) remote: remote: ================================================================ remote: remote: WARNINGS: Error encountered with push options remote: 'merge_request.create' 'merge_request.target=os-build' remote: 'merge_request.remove_source_branch': Validate branches Another remote: open merge request already exists for this source branch: !2164 remote: remote: =============================================================== remote: Ran script changes by hand to verify shell logic. Untested in cronjob. Signed-off-by: Don Zickus <dzickus(a)redhat.com> diff --git a/redhat/scripts/ci/ark-update-configs.sh b/redhat/scripts/ci/ark-update-configs.sh index blahblah..blahblah 100755 --- a/redhat/scripts/ci/ark-update-configs.sh +++ b/redhat/scripts/ci/ark-update-configs.sh @@ -67,6 +67,8 @@ else fi if test -n "$DIST_PUSH"; then + tmpfile=".push-warnings" + echo "Pushing branch $(git branch --show-current) to $(git remote get-url gitlab)" git push gitlab HEAD @@ -76,8 +78,16 @@ if test -n "$DIST_PUSH"; then -o merge_request.create \ -o merge_request.target="$BRANCH" \ -o merge_request.remove_source_branch \ - gitlab "$branch" + gitlab "$branch" 2>&1 | tee -a $tmpfile done + + # GitLab server side warnings do not fail git-push but leave verbose + # WARNING messages. Grep for those and consider it a script + # failure. Make sure all branches are pushed first as follow up + # git-pushes may succeed. + grep -q "remote:[ ]* WARNINGS" $tmpfile && RC=1 || RC=0 + rm $tmpfile + test $RC && exit $RC else printf " To push all the release artifacts, run: -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2165

3 5

Re: Small rant: installer environment size
by Richard W.M. Jones 09 Dec '22

09 Dec '22

On Wed, Dec 07, 2022 at 04:42:05PM -0800, Adam Williamson wrote: > I've moaned about the sheer amount and size of firmware blobs in other > forums before, but 214M compressed is *really* obnoxious. We must be > able to do something to clean this up (further than it's already > cleaned up - this is *after* we dropped low-hanging fruit like > enterprise switch 'firmwares' and garbage like that; most of the > remaining size seems to be huge amounts of probably-very-similar > firmware files for AMD graphics adapters and Intel wireless adapters). > I know some folks were trying to work on this (there was talk that we > could drop quite a lot of files that would only be loaded by older > kernels no longer in Fedora); any news on how far along that effort is? You only need network / wifi firmware blobs (although I'm sure they are in themselves large) and then you can fetch anything else needed for the hardware including graphics, right? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html

2 2

Re: Small rant: installer environment size
by Peter Robinson 09 Dec '22

09 Dec '22

On Thu, Dec 8, 2022 at 4:56 PM Adam Williamson <adamwill(a)fedoraproject.org> wrote: > > On Thu, 2022-12-08 at 12:58 +0000, Peter Robinson wrote: > > > > I've done a few passes, dropping a bunch of older firmware upstream > > that are no longer supported in any stable kernel release, also a > > bunch of de-dupe and linking of files rather than shipping of multiple > > copies of the same firmware. It's improved things a bit, unfortunately > > a lot of the dead firmware was tiny compared to say average modern > > devices like GPUs or WiFI. > > > > The problem with a lot of the firmware, and with the new nvidia "open > > driver" which shoves a lot of stuff into firmware in order to have an > > upstreamable driver apparently the firmwares there are going to be > > 30+Mb each, is that they're needed to bring up graphics/network etc to > > even just install so I don't know how we can get around this and still > > have a device work enough to be able to install the needed firmware > > across the network. > > > > Ideas on how to solve that problem welcome. > > Sorry if this is way off, but - do we need the GPU firmwares to run a > graphical install on the fallback path, just using the framebuffer set > up by the firmware? How crazy would it be to just do that - ship the > installer env with no GPU firmware? That has crossed my mind, and with simpledrm that may be more straight forward now, but TBH it's not something I am skilled enough to deal with, nor have the resources to test, or actually care enough about, but the big GPU firmwares are now all split out so that should be much more straightforward for someone with the resources to investigate.

1 0

Re: Small rant: installer environment size
by Gerd Hoffmann 09 Dec '22

09 Dec '22

On Thu, Dec 08, 2022 at 11:49:16AM -0800, Adam Williamson wrote: > On Thu, 2022-12-08 at 20:23 +0100, drago01 wrote: > > The problem I see here is not the presence of the firmware on the > > image, > > but the fact that it seems to be loaded into memory despite not being > > used. > > This is the direction Daniel was thinking down. I'm waiting for someone > with more expertise to reply, but I suspect the reply is going to be > along the lines of "yes, we *can* do that, but it's somewhat tricky > work that involves thinking about lots of paths that aren't obvious, > and somebody would need to dedicate their time to working on that". Split install.img into install.img + firmware.img? I think we already have support for multiple images (I see requests for updates.img when watching httpd logs while doing network installs), so the split should be easy. The somewhat more tricky part is probably to figure whenever we need the firmware or not. take care, Gerd

1 0

✅ PASS (3/297 SKIPPED): Test report for 6.0.12-300.fc37 (fedora-37)
by cki-project＠redhat.com 08 Dec '22

08 Dec '22

Hi, we tested your kernel and here are the results: Overall result: PASSED Merge: OK Compile: OK Test: OK Tested-by: CKI Project <cki-project(a)redhat.com> Kernel information: Brew / Koji Task ID: 95095340 You can find all the details about the test run at https://datawarehouse.cki-project.org/kcidb/checkouts/62626 One or more kernel tests failed: We also see the following known issues which are not related to your changes: Issue: Storage block - storage fio numa: Performance comparison: min:40535 * 1.15 < max:81259 URL: https://bugzilla.redhat.com/show_bug.cgi?id=2032094 Affected tests: x86_64 - Storage - block - storage fio numa Issue: NFS Connectathon: SELinux prevents rpcbind URL: https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issues/… Affected tests: aarch64 - NFS Connectathon s390x - NFS Connectathon x86_64 - NFS Connectathon Issue: avc: denied { sys_admin } for pid=674004 comm="systemd-gpt-aut" capability=21 scontext=system_u:system_r:systemd_gpt_generator_t:s0 tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability permissive=0 URL: https://bugzilla.redhat.com/show_bug.cgi?id=2083900 Affected tests: aarch64 - Networking MACsec: sanity aarch64 - Networking cki netfilter test aarch64 - ALSA PCM loopback test aarch64 - Storage - SCSI VPD ppc64le - Networking MACsec: sanity ppc64le - Networking cki netfilter test ppc64le - ALSA PCM loopback test x86_64 - Networking MACsec: sanity x86_64 - Networking cki netfilter test x86_64 - ALSA PCM loopback test x86_64 - Storage - SCSI VPD Issue: Networking MACsec: sanity: Cannot find device "dummy0" URL: https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issues/… Affected tests: aarch64 - Networking MACsec: sanity ppc64le - Networking MACsec: sanity x86_64 - Networking MACsec: sanity Issue: xfstests - _check_xfs_filesystem: filesystem on /dev/nvme0n1p4 is inconsistent (r) URL: https://bugzilla.redhat.com/show_bug.cgi?id=1989409 Affected tests: aarch64 - xfstests - btrfs If you find a failure unrelated to your changes, please ask the test maintainer to review it. This will prevent the failures from being incorrectly reported in the future. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________

1 0

Re: Small rant: installer environment size
by drago01 08 Dec '22

08 Dec '22

On Thursday, December 8, 2022, Adam Williamson <adamwill(a)fedoraproject.org> wrote: > On Thu, 2022-12-08 at 12:58 +0000, Peter Robinson wrote: > > > > I've done a few passes, dropping a bunch of older firmware upstream > > that are no longer supported in any stable kernel release, also a > > bunch of de-dupe and linking of files rather than shipping of multiple > > copies of the same firmware. It's improved things a bit, unfortunately > > a lot of the dead firmware was tiny compared to say average modern > > devices like GPUs or WiFI. > > > > The problem with a lot of the firmware, and with the new nvidia "open > > driver" which shoves a lot of stuff into firmware in order to have an > > upstreamable driver apparently the firmwares there are going to be > > 30+Mb each, is that they're needed to bring up graphics/network etc to > > even just install so I don't know how we can get around this and still > > have a device work enough to be able to install the needed firmware > > across the network. > > > > Ideas on how to solve that problem welcome. > > Sorry if this is way off, but - do we need the GPU firmwares to run a > graphical install on the fallback path, just using the framebuffer set > up by the firmware? How crazy would it be to just do that - ship the > installer env with no GPU firmware? That would be very crazy, as you will have a degraded user experience (laggy UI, wrong resolution, ...) to save a couple of megabytes that are a non issue for today's hardware. > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > _______________________________________________ > desktop mailing list -- desktop(a)lists.fedoraproject.org > To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject. > org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/desktop@ > lists.fedoraproject.org > Do not reply to spam, report it: https://pagure.io/fedora- > infrastructure/new_issue >

2 2

Re: Small rant: installer environment size
by Daniel P. Berrangé 08 Dec '22

08 Dec '22

On Wed, Dec 07, 2022 at 04:42:05PM -0800, Adam Williamson wrote: > Hi folks! Today I woke up and found > https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which diverted me > down a bit of an "installer environment size" rabbit hole. snip > Why does this matter? Well, the images being large is moderately > annoying in itself just in terms of transfer times and so on. But more > importantly, AIUI at least, the entire installer environment is loaded > into RAM at startup - it kinda has to be, we don't have anywhere else > to put it. The bigger it is, the more RAM you need to install Fedora. > The size of the installer environment (for which the size of the > network install image is more or less a perfect proxy) is one of the > two key factors in this, the other being how much RAM DNF uses during > package install. Is there something that can be done to optimize the RAM usage, in spite of the large installer env size ? If we're installing off DVD media, it shouldn't be required to pull all of the content into RAM, since it can be fetched on demand from the media. IOW, 99% of the firmware never need leave the ISO, so shouldn't matter if firmware is GBs in size [1] if we never load it off the media. Same for languages, only the one we actually want to use should ever get into RAM. If we're installing off a network source, we need to pull content into RAM, but that doesn't mean we should pull everything in at once upfront. Is it possible to delay pulling in non-NIC firmware until we have a NIC configured, and just rely on the basic generic framebuffer setup by UEFI/BIOS until we get far enugh to pull in video card firmware ? For localization, is it possible to split the localization into per-language bundles, and delay loading off the network until we know what language we want to load, instead of pre-loading all languages ? With regards, Daniel [1] Yes, I know it matters for user media download size in reality -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0

[OS-BUILD PATCHv3 0/2] redhat/configs: aarch64: reorganize tegra configs to common dir
by Mark Salter (via Email Bridge) 08 Dec '22

08 Dec '22

From: Mark Salter on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2172 RHEL needs support for tegra194 and tegra234 SoCs, so move some configs from redhat/configs/fedora to redhat/configs/common where they can be shared. Signed-off-by: Mark Salter <msalter(a)redhat.com> --- redhat/configs/ark/generic/arm/aarch64/CONFIG_ARCH_TEGRA_194_SOC | 1 - redhat/configs/ark/generic/arm/aarch64/CONFIG_ARCH_TEGRA_234_SOC | 1 - redhat/configs/ark/generic/arm/aarch64/CONFIG_ARM_TEGRA186_CPUFREQ | 1 + redhat/configs/ark/generic/arm/aarch64/CONFIG_TEGRA_IVC | 1 - redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARCH_TEGRA_194_SOC => redhat/configs/common/generic/arm/aarch64/CONFIG_ARCH_TEGRA_194_SOC | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARCH_TEGRA_234_SOC => redhat/configs/common/generic/arm/aarch64/CONFIG_ARCH_TEGRA_234_SOC | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_ARM_TEGRA194_CPUFREQ => redhat/configs/common/generic/arm/aarch64/CONFIG_ARM_TEGRA194_CPUFREQ | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_GPIO_TEGRA186 => redhat/configs/common/generic/arm/aarch64/CONFIG_GPIO_TEGRA186 | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_PCIE_TEGRA194_HOST => redhat/configs/common/generic/arm/aarch64/CONFIG_PCIE_TEGRA194_HOST | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_PHY_TEGRA194_P2U => redhat/configs/common/generic/arm/aarch64/CONFIG_PHY_TEGRA194_P2U | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_SERIAL_TEGRA_TCU => redhat/configs/common/generic/arm/aarch64/CONFIG_SERIAL_TEGRA_TCU | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_SERIAL_TEGRA_TCU_CONSOLE => redhat/configs/common/generic/arm/aarch64/CONFIG_SERIAL_TEGRA_TCU_CONSOLE | 0 redhat/configs/common/generic/arm/aarch64/CONFIG_SOC_TEGRA_CBB | 1 + redhat/configs/fedora/generic/arm/aarch64/CONFIG_TEGRA_BPMP_THERMAL => redhat/configs/common/generic/arm/aarch64/CONFIG_TEGRA_BPMP_THERMAL | 0 redhat/configs/fedora/generic/arm/aarch64/CONFIG_TEGRA_HSP_MBOX => redhat/configs/common/generic/arm/aarch64/CONFIG_TEGRA_HSP_MBOX | 0 redhat/configs/fedora/generic/arm/CONFIG_I2C_TEGRA_BPMP => redhat/configs/common/generic/arm/CONFIG_I2C_TEGRA_BPMP | 0 redhat/configs/ark/generic/arm/aarch64/CONFIG_TEGRA_HSP_MBOX => redhat/configs/common/generic/arm/CONFIG_TEGRA_HSP_MBOX | 0 redhat/configs/fedora/generic/arm/CONFIG_TEGRA_IVC => redhat/configs/common/generic/arm/CONFIG_TEGRA_IVC | 0 redhat/configs/fedora/generic/arm/CONFIG_ARM_TEGRA194_CPUFREQ | 1 - redhat/configs/fedora/generic/arm/CONFIG_TEGRA_HSP_MBOX | 1 - redhat/configs/pending-fedora/generic/CONFIG_SOC_TEGRA_CBB | 13 ---------- 21 files changed, 2 insertions(+), 18 deletions(-)

2 3

Re: Small rant: installer environment size
by Florian Weimer 08 Dec '22

08 Dec '22

* Adam Williamson: > 1. /usr/lib/locale/locale-archive , from glibc-all-langpacks - this is > 224M uncompressed. A quick test just compressing the file with xz on my > system shows it compresses to around 11M, though, so that's probably > all it adds up to after compression (the image is an xz-compressed > squashfs) Isn't the compression block-based? I think it would be interesting to measure the image size with the file removed. For the non-live installer, we can *significantly* cut down its size, without degrading localization of the installer itself. > 2. /usr/lib64/libLLVM-15.so, which is 114M on its own, compresses to > 23M. We are, I think, basically stuck with this for mesa-dri-drivers , > but does it have to be so *big*? It has all the targets in it. As it's for JIT, we'd only need one target. Thanks, Florian

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel December 2022