Kernel 4.15 rebase plans
by Laura Abbott
Hi,
4.15 was released on Sunday. Fedora will be following the same rebase
procedure that we have in the past: After a few stable releases,
typically 4.15.2 or 4.15.3, F27 will be rebased to 4.15 with F26
rebased shortly there after. I would expect this to happen by the
end of February.
Note this was a tricky kernel release because of all the Spectre/
Meltdown work but that should be settled at this point. More testing
is always appreciated though.
Thanks,
Laura
5 years, 9 months
Options for Coffee Lake machines running F27?
by Jason L Tibbitts III
I have a number of machines with i7-8700K CPUs and am relying on the
onboard graphics, which means that 4.14 is right out.
Currently I'm just setting up the rawhide-kernel-nodebug repo and using
that, which is great but I'm not sure what I should do once 4.15 is
released. Will the repo then start following the 4.16 merge window? Or
will it stick with 4.15 releases until F28 branches?
My concern is that the repo will immediately move on to tracking the
4.16 merge window which I don't really want to try to use on a user
desktop. And since F27 probably isn't going to jump straight to 4.15
releases, I won't have a stable release to follow which also has
functioning graphics.
I can of course just build my own packages at that point but it does
take a bit of effort and I'm wondering if I need to plan for it. I'm
certainly not asking for anyone to build kernels for me or alter release
plans or anything like that.
Thanks!
- J<
5 years, 10 months
[PATCH] Fix misnamed CONFIG files
by Don Zickus
A couple of CONFIG file names were misnamed during their creation.
Fix them up.
configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible -> configs/fedora/generic/CONFIG_DEBUG_VM_RB
and
configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug -> configs/fedora/generic/CONFIG_DPM_WATCHDOG
---
.../CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible | 1 -
configs/fedora/generic/CONFIG_DPM_WATCHDOG | 1 +
configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug | 1 -
3 files changed, 1 insertion(+), 2 deletions(-)
delete mode 100644 configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible
create mode 100644 configs/fedora/generic/CONFIG_DPM_WATCHDOG
delete mode 100644 configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug
diff --git a/configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible b/configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible
deleted file mode 100644
index fbc8aaef..00000000
--- a/configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_DEBUG_VM_RB is not set # revisit this if performance isn't horrible
diff --git a/configs/fedora/generic/CONFIG_DPM_WATCHDOG b/configs/fedora/generic/CONFIG_DPM_WATCHDOG
new file mode 100644
index 00000000..c12b35c4
--- /dev/null
+++ b/configs/fedora/generic/CONFIG_DPM_WATCHDOG
@@ -0,0 +1 @@
+# CONFIG_DPM_WATCHDOG is not set # revisit this in debug
diff --git a/configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug b/configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug
deleted file mode 100644
index c12b35c4..00000000
--- a/configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_DPM_WATCHDOG is not set # revisit this in debug
--
2.14.3
5 years, 10 months
CONFIG name typos?
by Don Zickus
Hi Laura, Justin,
I stumbled upon these CONFIG names today. I assume they are wrong?
(full file name in quotes)
configs/fedora/generic/'CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible'
configs/fedora/generic/'CONFIG_DPM_WATCHDOG revisit this in debug'
Cheers,
Don
5 years, 10 months
DOA kernel-4.15.0-0.rc8.git2.1.fc28.x86_64
by Chris Murphy
Two x86_64 UEFI computers (different CPUs and firmware OEMs) won't
boot this kernel.
On one computer, it reboots shortly after I see EFI stub: UEFI secure
boot enabled.
On another computer, I just get a hang with an underscore and it never recovers.
kernel-4.15.0-0.rc8.git1.1.fc28.x86_64 works fine on both.
--
Chris Murphy
5 years, 10 months
Re: Can't capture vmcore?
by Josh Boyer
On Tue, Jan 9, 2018 at 1:51 PM, Maxim Burgerhout <maxim(a)wzzrd.com> wrote:
> I'm getting kernel panics in a VM that functions as a hypervisor, the moment
> I spin up the nested guest (on AMD ThreadRipper / Fedora 27). That is
> annoying, of course, so I try to be a good citizen and file a bug.
>
> For some reason though, I cannot get the core dumped. I get a core fine with
> sysrq, but not with this actual panic. I've followed [1] to set up kdump and
> crash, but everytime I trigger the crash and see my VM reboot, I see an
> empty /var/crash afterwards.
>
> As was able to get the vmcore written to /var/crash on in a RHEL7 guest, I'm
> starting to suspect a bug, but I'm unsure.
>
> Any pointers on how to debug this?
>
> [1] https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
Adding the Fedora kernel list.
Kdump isn't automatically tested in Fedora and while it can work, it
can often be broken as well. There might be someone on the kernel
list that is more familiar with the current state of kdump support in
Fedora, or alternative methods for getting the kernel backtrace.
josh
5 years, 10 months
/proc/sys/net/core/optmem_max on armv7l
by Björn 'besser82' Esser
Hello together,
I just noticed, there is a difference in the default value of
`/proc/sys/net/core/optmem_max` on armv7l:
On all arches it is 20480, but on armv7l it is 10240.
Is there any specific reason for limiting the maximum ancillary buffer
size allowed per socket on this arch?
Cheers,
Björn
5 years, 10 months
[PATCH 0/2] configs: Rename base-{generic,debug} to configs/fedora/
by Don Zickus
This patchset renames the configs/base-{generic,debug} to
configs/fedora/{generic,debug} and updates the scripts to reflect that.
Because the configs rename patch is huge and Laura prefers not to have it
on the list, I am purposely excluding the content of that particular patch.
The script changes are attached for public review.
The code can be reviewed here:
https://pagure.io/fedora-kernel-dzickus.git rh_sync2
Don Zickus (2):
configs: Move base-debug and base-generic to configs/fedora
configs: Update config generation script to use configs/fedora
configs/build_configs.sh | 62 +++++++++++-----------
configs/config_generation | 5 ++
<snipped giant configs rename>
5 years, 10 months
Re: "MODSIGN: Couldn't get UEFI db list" errors are still happening
by Peter Jones
Ccing dhowells and kernel(a)lists.fp.o so they all know what's going on.
On Wed, Dec 27, 2017 at 05:07:45PM +0100, Hans de Goede wrote:
> Hi Peter,
>
> Various users (including me) are still seeing:
> https://bugzilla.redhat.com/show_bug.cgi?id=1497559
> happening.
>
> Do the patches you've attached there need more work,
> or can I add those to the kernel pkg so that they get
> picked up the next build?
I think the status here is that I sent them to dhowells for review and
he got real busy with something else and never got around to reviewing
them. As far as I'm concerned they're still correct.
David, the patches I've pushed are still intended for your MODSIGN
patch series as well.
I've made sure they still work as far as "fedpkg prep" on f26, f27, and
rawhide, and pushed them to dist-git for those branches. So they'll be
in the next build.
> Also where can I find the latest version of these
> patches?
Nothing has changed any.
> Note: I can take care of this, I just need your input
> on if it is ok to take the patches and put them in the
> Fedora kernels.
I already had it staged, modulo a git rebase for newer commits, so I
just went ahead and pushed it. Thanks though.
--
Peter
5 years, 10 months
