Cannot set MTU > 1500 on OVS port with kernel 4.10
by Ian Pilcher
BZ here - https://bugzilla.redhat.com/show_bug.cgi?id=1438069
Wondering, though, if this is expected behavior, and I need to do
something specific to enable larger frames on an OVS bridge with kernel
4.10.
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================
6 years, 11 months
Bug 1431296 conflicts between kernel-core subpackages on upgrade
by Mark Wielaard
Hi,
In case people didn't notice in the somewhat long analysis of the issue in the bug, the workaround is just a simple oneliner:
diff --git a/kernel.spec b/kernel.spec
index cb3dec8..29c198a 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -183,6 +183,9 @@ Summary: The Linux kernel
%define _enable_debug_packages 0
%endif
%define debuginfodir /usr/lib/debug
+# Needed because we override almost everything involving build-ids
+# and debuginfo generation. Currently we rely on the old alldebug setting.
+%global _build_id_links alldebug
# kernel PAE is only built on i686 and ARMv7.
%ifnarch i686 armv7hl
Of course it would be nice if someone could cleanup the various places that the kernel.spec overrides rpm find-debuginfo.sh and debugedit and provides some requirements that would make this all easier for the kernel build. It looks like the current build does a lot redundant extra work that might be prevented if rpm provided better hooks to do automagically what the kernel spec build requires. One thing rpm wants to introduce in the future (already upstream) is parallel processing of debug files. Which the current kernel.spec seems to prevent because it serializes the processing itself already.
I would be happy to review any feedback on why the kernel.spec has the current hacks and suggestions for improvements to make this smoother.
Cheers,
Mark
6 years, 11 months
[PATCH] enable THP on Power (#1434007)
by Dan Horák
---
baseconfig/powerpc/CONFIG_DEV_DAX | 1 +
baseconfig/powerpc/CONFIG_DEV_DAX_PMEM | 1 +
baseconfig/powerpc/CONFIG_NR_DEV_DAX | 1 +
baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE | 2 +-
baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE_MADVISE | 1 +
5 files changed, 5 insertions(+), 1 deletion(-)
create mode 100644 baseconfig/powerpc/CONFIG_DEV_DAX
create mode 100644 baseconfig/powerpc/CONFIG_DEV_DAX_PMEM
create mode 100644 baseconfig/powerpc/CONFIG_NR_DEV_DAX
create mode 100644 baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE_MADVISE
diff --git a/baseconfig/powerpc/CONFIG_DEV_DAX b/baseconfig/powerpc/CONFIG_DEV_DAX
new file mode 100644
index 0000000..77478a2
--- /dev/null
+++ b/baseconfig/powerpc/CONFIG_DEV_DAX
@@ -0,0 +1 @@
+CONFIG_DEV_DAX=m
diff --git a/baseconfig/powerpc/CONFIG_DEV_DAX_PMEM b/baseconfig/powerpc/CONFIG_DEV_DAX_PMEM
new file mode 100644
index 0000000..8c7fd67
--- /dev/null
+++ b/baseconfig/powerpc/CONFIG_DEV_DAX_PMEM
@@ -0,0 +1 @@
+CONFIG_DEV_DAX_PMEM=m
diff --git a/baseconfig/powerpc/CONFIG_NR_DEV_DAX b/baseconfig/powerpc/CONFIG_NR_DEV_DAX
new file mode 100644
index 0000000..3fd0f86
--- /dev/null
+++ b/baseconfig/powerpc/CONFIG_NR_DEV_DAX
@@ -0,0 +1 @@
+CONFIG_NR_DEV_DAX=32768
diff --git a/baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE b/baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE
index 4874a85..75d999c 100644
--- a/baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE
+++ b/baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE
@@ -1 +1 @@
-# CONFIG_TRANSPARENT_HUGEPAGE is not set
+CONFIG_TRANSPARENT_HUGEPAGE=y
diff --git a/baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE_MADVISE b/baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE_MADVISE
new file mode 100644
index 0000000..f9a942f
--- /dev/null
+++ b/baseconfig/powerpc/CONFIG_TRANSPARENT_HUGEPAGE_MADVISE
@@ -0,0 +1 @@
+CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
--
2.9.3
6 years, 11 months
Re: Fedora 26 Alpha status update
by Chris Murphy
I hit something like kparal's but didn't get a screenshot of the vm
console. I've had several additional freezes of the VM but there was
no call trace, just a hang, and since it's before root is mounted rw,
there's nothing in the journal. Interestingly, it never happens when I
connect with virsh console. If it's being watched, it doesn't happen.
And so far on baremetal it hasn't ever happened (I've been running the
4.11 kernels for a couple weeks).
Chris Murphy
6 years, 12 months
Re: Fedora 26 Alpha status update
by Peter Robinson
On Tue, Mar 21, 2017 at 11:39 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> Hi folks! Just wanted to let everyone know where we're at with the F26
> Alpha.
>
> An Alpha RC2 compose request is in, and RC2 should be building at
> present. The main change between RC1 and RC2 is a fix for the problems
> with gnome-initial-setup: it should now work properly if you don't
> create a user during install. There's also an updated selinux-policy
> which should hopefully squish all the AVCs we've been seeing during
> regular install and boot. It should arrive some time this evening US
> time, all being well.
>
> There does still seem to be some kind of kernel issue. Multiple people
> have had a similar experience of booting an F26 VM and seeing boot fail
> due to a kernel GPF. We've seen many different tracebacks, but it could
> still all be basically the same problem. We have the following bug
> reports so far:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1430297 (rwmj)
> https://bugzilla.kernel.org/show_bug.cgi?id=194911 (Thorsten Leemhuis)
https://bugzilla.redhat.com/show_bug.cgi?id=1426796
I would add this one for Power64 to that list then too, while some
users are reporting it works for them I've not had such luck, and in
fact ramdom luck with different kernels/same kernels where sometime it
boots and sometimes not.
> but I've also seen this happen a few times when booting virt-manager
> VMs locally, and we're getting multiple reports from some folks doing a
> test event today that they're seeing something similar.
>
> It'd be good if folks can reply to one of the lists if they're also
> running into something that sounds like this, with some details of your
> experience - does it happen every time, or only sometimes? Do you
> always get the same traceback, or different ones? What kernel versions
> are affected for you? And importantly, does anyone see it on bare metal
> (rather than with a VM)?
>
> Basic plan is to get through all the Alpha testing with RC2 when it
> lands and try to gather as much data as possible about the kernel bug
> (and any other important bugs that emerge) before the go/no-go meeting
> on Thursday.
>
> Thanks folks!
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
6 years, 12 months