Enabling vboxsf in Fedora 5.4+ kernels
by Hans de Goede
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
4 years, 3 months
Specfile tweak/fix for the nopatches path in kernel.spec
by Thorsten Leemhuis
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
4 years, 3 months
socket path length
by Damian Ivanov
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
4 years, 3 months
NO_HZ_IDLE on x86_64?
by Peter Robinson
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
4 years, 4 months
5.4 regressions
by Chris Murphy
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
4 years, 4 months
Kernel 5.4 rebase plans
by Jeremy Cline
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
4 years, 4 months
bringing back tools/perf into the kernel.spec file
by Laura Abbott
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
4 years, 4 months
