kernel December 2019

kernel@lists.fedoraproject.org

13 participants
11 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 29 Jan '20

29 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

Specfile tweak/fix for the nopatches path in kernel.spec
by Thorsten Leemhuis 03 Jan '20

03 Jan '20

Hi Fedora kernel maintainers! Could you please consider applying below small tweak to kernel.spec (all branches, ideally) the next time you change it? A change like this would be helpful for the Kernel vanilla repositories, as "git am" afaics will endlessly wait for input from STDIN right now if "%{patches}" is empty – which is the case currently if one sets "nopatches 1" in the spec file :-/ tia! Ciao, Thorsten diff --git a/kernel.spec b/kernel.spec index e98df4a..ef4f76e 100644 --- a/kernel.spec +++ b/kernel.spec @@ -1536,9 +1536,11 @@ ApplyPatch %{stable_patch_01} %endif # Note: Even in the "nopatches" path some patches (build tweaks and compile -# fixes) will always get applied; see patch defition above for details +# fixes) might get applied; see patch defition above for details +%if 0%{?patches} git am %{patches} +%endif # END OF PATCH APPLICATIONS

2 2

socket path length
by Damian Ivanov 03 Jan '20

03 Jan '20

Hello everyone and Happy holidays! Some applications (like gnome-boxes) rely on socket path https://gitlab.gnome.org/GNOME/gnome-boxes/issues/267 A lot of flatpaks as well (filled report here https://github.com/flatpak/flatpak/issues/3336 ) If an organizations username structure is firstname.lastname(a)organization.org for example my username (more than one first name, not to mentioned that in some regions middle-name's are used as well) would be 42 characters which exceeds the limit (17) mentioned in the gnome BR. I could not find any information if having the socket length limited is still something that is required nowadays as it seems this is mostly for compatibility reasons? Do you think that this us something that could/should/would be changed nowadays as a config option? Thanks in advance! Best Regards, Damian

3 11

NO_HZ_IDLE on x86_64?
by Peter Robinson 19 Dec '19

19 Dec '19

Hey All. In digging through some pieces around CPU_IDLE I noticed that NO_HZ_IDLE is explicitly disabled on x86_64 but not on all other architectures. Doing a "git log --follow configs/fedora/generic/x86/x86_64/CONFIG_NO_HZ_IDLE" it goes all the way back to 2016 when we changed the way the configs were handled. The upstream kernel's opinion [1] on it is "Most of the time you want to say Y here." so I'm wondering if there's a reason why we're difference on x86_64 or is it just lost in the winds of time? Peter PS was digging around CPU_IDLE_GOV_TEO for those curious. [1] https://cateee.net/lkddb/web-lkddb/NO_HZ_IDLE.html

5 9

CONFIG_SFI is still set in rawhide and stabilization kernels
by Hans de Goede 10 Dec '19

10 Dec '19

Hi All, I thought that we were going to disable CONFIG_SFI since there is no hardware out there using it? Regard,s Hans

1 0

5.4 regressions
by Chris Murphy 10 Dec '19

10 Dec '19

I've seen both of these on skylake with kernel 5.4.2, and the GPU hang has reports of kabylake also affected. I imagine those are pretty common hardware. Both bug reports include upstream reference. WARNING: CPU: 2 PID: 1 at kernel/trace/trace.c:8106 create_trace_option_files+0x1ef/0x220 https://bugzilla.redhat.com/show_bug.cgi?id=1781288 [drm:gen8_reset_engines [i915]] *ERROR* rcs0 reset request timed out https://bugzilla.redhat.com/show_bug.cgi?id=1780800 The second is pretty bad in that it appears as a total lockup, locally. Usually I've been able to ssh into the system, but I'd guess most users will just force a power off and start over. -- Chris Murphy

1 0

Kernel 5.4 rebase plans
by Jeremy Cline 09 Dec '19

09 Dec '19

Hi folks, This week is the test week for 5.4 so next week, assuming all goes well, we'll be rebasing Fedora 31 to 5.4. You should expect to see 5.4 in updates testing for Fedora 31 sometime next week (I make no promises as to exactly when as I, like many other folks, will be on vacation). Fedora 30 should follow shortly afterwards. - Jeremy

1 0

[Test Day] Kernel 5.4 test week starts today!
by Sumantro Mukherjee 09 Dec '19

09 Dec '19

Hey All, I would like to invite all of you to participate in the Kernel 5.4 Test week which is happening from 2019-12-09 to 2019-12-16. It's fairly simple, head over to the wiki [0] and read in details about the test week and simply run the test case mentioned in[1] and enter your results. Do let me know if you have any questions [0] https://fedoraproject.org/wiki/Test_Day:2019-12-09_Kernel_5.4_Test_Week [1] http://testdays.fedorainfracloud.org/events/74 Thanks -- -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>

1 0

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

04 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel December 2019