kernel November 2019

kernel@lists.fedoraproject.org

12 participants
12 discussions

Erase i686 from the kernel package's repository?
by Paul Bolle 22 Apr '21

22 Apr '21

Hi Justin, Fedora 31's release is imminent. This means that some time ago Fedora passed the point where (F31 and later) i686 releases were still possible, doesn't it? If so, could we please clean the kernel package's repository of all the things that are only relevant for i686? Because that would make my plans for the config generation [1] just a bit easier. Thanks, Paul Bolle [1] See https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.or…

4 16

Enabling vboxsf in Fedora 5.4+ kernels
by Hans de Goede 28 Jan '20

28 Jan '20

Hi all, So vboxsf has finally landed upstream. I gave up getting it merged directly under fs/vboxsf since despite some fs-devel folks saying that it was as good as it is going to get (given the limitations of the API exposed by the host) it seems that the fs subsys maintainers did not have the time to take a look at it. So I've send it to GKH for merging under drivers/staging instead and somewhat to my surprise (not complaining) he send it in for this cycle. Since this upstream now; and despite being in staging has alread seen multiple reviews, I would like to get this enabled for the Fedora 5.4 kernels so that shared-folders will just work for users running Fedora as a VirtualBox guest. So unless there are any objections I'm going to flip the configs/fedora/generic/CONFIG_VBOXSF_FS file to m and enable this in rawhide soon. Regards, Hans

5 7

bringing back tools/perf into the kernel.spec file
by Laura Abbott 03 Dec '19

03 Dec '19

Hi, Continuing on the theme of bringing things into Fedora, one other task I'm currently looking at is bringing the tools building back into the kernel.spec file for testing purposes only. Fedora split the kernel-tools and userspace packages out into a separate repository at least two years ago. From my perspective, this has been a success since we've been able to avoid issues with tools breaking kernel builds and let the userspace tools build in a more standard way since we don't need to do all the weird hacks to build the kernel. This change has encountered some resistance downstream since their workflow involves more process and splitting out into a separate repository could potentially have more impact. I'm still working to resolve this but as an intermediate step I'd like to bring back the build commands into the kernel.spec file. We'd still keep building the tools in a separate repository but this would at least let us work towards the goal of having a common tree. If we decide to go with the split downstream, we will remove it again. If we decide to not go with the split downstream, I expect Fedora will want to follow and we'll need to bring the code back in anyway. I don't know exactly when I'll be getting to this but this is just a heads up that this work will be coming. Thanks, Laura

1 1

cleaning out some scripts from the kernel dist-git
by Laura Abbott 03 Dec '19

03 Dec '19

The kernel dist-git has a number of scripts in the script directory. Some are used for regular work (stable-update.sh, rawhide-rc.sh, rawhide-snapshot.sh) but some of them haven't been used in a long time. I'd like to delete the following: - check-patchlist.sh - check-TODO.sh - combine.sh - grab-logs.sh - newpatch.sh Does anyone have an issue with removing these scripts? Thanks, Laura

2 2

[PATCH] Upstream fix for Raven Ridge
by Luya Tshimbalanga 30 Nov '19

30 Nov '19

Hello team, Upstream provided several bug fix related to AMD APU Raven Ridge which hangs when using some applications like radeontop to read its interface [1]. Test model was 2018 HP Envy x360 Ryzen 2500U (device id 15dd): drm/amdgpu: disable gfxoff when using register read interface ------------------------------------------------------------------------------------------ https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.4&id=c57040… Original Raven Ridge (15d8) becomes unstable when using gfxoff. The test model Ryzen 2500U with id 15dd and above is unaffected drm/amdgpu: disable gfxoff on original raven ----------------------------------------------------------------- https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.4&id=941a0a… Revert "drm/amd/display: enable S/G for RAVEN chip" ---------------------------------------------------------------------------- https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.4&id=a0184d… It will be nice to backport for the current kernel 5.3. Thanks in advance. Reference: --------------- [1]https://bugzilla.kernel.org/show_bug.cgi?id=205497 -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer

2 3

Building custom kernel using rpmbuild method fails with config conflicts between kernel-local and x86_64.config
by stan 25 Nov '19

25 Nov '19

I use the src.rpm from rawhide kernels to build a kernel custom configured for my hardware in F31, and with a local patch, using the old rpmbuild method. For rc5 this worked, when I tried rc7 it didn't. And rc8 is failing with the same error. The error message is this: scripts/gen_compile_commands.py: updating Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-aarch64.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl-lpae.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-i686.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-ppc64le.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-s390x.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-x86_64.config ... Found misconfigured config items, please set them to an appropriate value /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-x86_64.config.orig:4359:warning: override: PSTORE_LZ4HC_COMPRESS_DEFAULT changes choice state So, kernel-local is not overriding the default kernel configuration. I think it should; so whatever is checking the configuration consistency has a bug, I think. Here is where it happens in the build process: + ./process_configs.sh -w -n -c kernel 5.4.0 error: Bad exit status from /var/tmp/rpm-tmp.sEsDIh (%prep) extra tokens at the end of %else directive in line 618: %else # released_kernel extra tokens at the end of %endif directive in line 627: %endif # released_kernel Macro expanded in comment on line 701: %{rpmversion}-%{distro_build}.tar.bz2 Macro expanded in comment on line 702: %{rpmversion}-%{distro_build}.tar.bz2 Macro expanded in comment on line 710: %{rpmversion}-redhat.patch Bad exit status from /var/tmp/rpm-tmp.sEsDIh (%prep) Should I open a bugzilla for this? Thanks.

3 6

Even though I have nobuild set for architectures, rpmbuild is processing their configs. Is this correct?
by stan 25 Nov '19

25 Nov '19

I build a custom local kernel using the rawhide kernel src.rpm here on F31. I change the spec file to build only for my arch, x86_64, and not to build cross headers. But I notice that the config files for all the nobuild archs are still processed. This seems like an error to me. Is it? In the kernel.spec file. %define nobuildarches i386 i686 ppc64 s390x %{arm} %{power64} aarch64 ppc64le Output from rpmbuild -bb kernel.spec. Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-aarch64.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl-lpae.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-i686.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-ppc64le.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-s390x.config ... done

2 2

I see this statement a lot in the kernel spec file. What is its interpretation? %if 0%{?fedora}
by stan 25 Nov '19

25 Nov '19

As the subject says, I see the %if 0%{?fedora} statement in the spec file, and I thought I knew what it meant, but the latest additions to the spec file have caused me to question that. My interpretation is that without the 0, it is checking whether it is running on fedora. With the zero, it is ignoring the branch and either skipping the guarded statements or taking the else. Is this correct?

2 2

Updated kernel to 5.3.11, now /dev/null does not return any data
by Juha Nikkanen 15 Nov '19

15 Nov '19

Ladies and gentlemen, I have curious problem after booting into 5.3.11. I can't read a stream of zeroes from /dev/null anymore: $ dd if=/dev/null of=zero.dat bs=2048 count=1 0+0 records in 0+0 records out 0 bytes copied, 0.00036764 s, 0.0 kB/s and: $ file /dev/null /dev/null: character special (1/3) $ ls -l /dev/null crw-rw-rw-. 1 root root 1, 3 Nov 14 20:28 /dev/null No matter if I try this as a root or as a ordinary user. Results are exactly same. I did not test this with kernels 5.3.7 and 5.3.8, I jumped to 5.3.11 from 5.3.6 and I think 5.3.6 did provide a stream of zero data. No strace gives anything special, just ordinary read() after dup2() and read returns zero length for 2048 requested. Now is this a problem of kernel or is it within dd and how it opens a /dev/null or how it flags read() function? Sincerely, Juha

2 1

Some more upcoming Fedora kernel changes
by Laura Abbott 12 Nov '19

12 Nov '19

Hi, I'm looking to bring in another piece of downstream work into Fedora sometime next week. The short summary is that Fedora will be bringing in some files to build against a RHEL buildroot but Fedora will still be the same. The longer answer: The goal with this work is bring Fedora and RHEL closer together and reduce work between the kernels. What we'd like to happen is that if we build against a Fedora buildroot we bring in the Fedora kernel configuration options and if we're building against a RHEL buildroot we bring in the RHEL kernel configuration. What this will do is let us test and verify configuration options easily in both RHEL and Fedora configuration without having to do redundant work. As a step towards this goal, I'll be bringing in some changes to the build scripts and moving some files around. You'll see a number of empty files brought in for the RHEL side just as a place holder. Part of this work also involves bringing in a few certificates for RHEL secureboot signing on powerpc and s390x. A big part of this goal is to let Fedora do most of its work from a src-git tree. The reason I'm working to bring parts of these commits in now is so when it comes time to start using the src-git tree the diff doesn't look so scary. Small changes help make sure things aren't getting broken (I've already found a few things that need to be fixed during the course of this work) My goal is to still keep Fedora stable and let Fedora be Fedora. I expect to keep tweaking the scripts to make the process easier. If you have feedback, feel free to let me know. You can see the tree with some other changes at https://pagure.io/fedora-kernel-labbott/tree/ark_sync_nov8 Thanks, Laura

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel November 2019