kernel March 2015

kernel@lists.fedoraproject.org

4 participants
4 discussions

Re: [kernel/f21] Make sure acpi brightness_switch is disabled (like forever in Fedora)
by Hans de Goede 29 Jul '15

29 Jul '15

Hi Josh, On 07/28/2014 07:04 PM, Josh Boyer wrote: > commit e6fe382d1d53d4cdf9b544729dc823d4eab0217c > Author: Josh Boyer <jwboyer(a)fedoraproject.org> > Date: Mon Jul 28 13:03:01 2014 -0400 > > Make sure acpi brightness_switch is disabled (like forever in Fedora) > > Upstream reverted the change to turn the ACPI brightness_switch_enabled > parameter off by default. Revert the revert so we go back to the state > Fedora has traditionally been in. Ack, I was planning on doing this myself but you beat me to it, thanks for taking care of this. Note that 3.17 will have this patch: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=… Which fixes the 2 steps being taken for one keypress problem while keeping the acpi brightness_switch behavior enabled, so that people who have an acpi-video controlled backlight and a userspace which does not do backlight control (e.g. windowmaker). So for 3.17 we should IMHO drop the revert-revert and stick with upstream behavior. Alternatively we could apply that patch now instead of the revert-revert. Regards, Hans

3 7

fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg 04 Jun '15

04 Jun '15

The other day I was running the stock fedora kernel on my ip forwarding setup, to see what the performance was, and the performance wasn't very good. system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad port 82580 adapters (12 ports). Traffic is bidirectional 64 byte packets being forwarded and received on each port, basically port to port routing. I am only using 12 flows currently. The driver is igb, and I am using an affinity script that lines up each pair of ports that are forwarding traffic into optimal configurations for cache locality. I am also disabling remote_node_defrag_ratio to stop cross node traffic. With the fedora default kernel from F14 it appears that CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if I stop iptables service. perf showed netfilter being prominent, and removing it gives me much higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a good thing to be able to disable netfilter if you want to? Jesse

5 9

[PATCH 1/2] ARMv7: add patches to fix crash on boot for some devices on multiplatform
by Nicolas Chauvet 26 Mar '15

26 Mar '15

This patch backport the previous commit from pbrobinson in devel to the f21 branch (without the changelog entry) Tested with fedpkg prep to verify that the patches applies --- arm-fix-iommu-exynos.patch | 48 +++++++++++++++++++++++++++++++++++++++ arm-fix-iommu-omap.patch | 48 +++++++++++++++++++++++++++++++++++++++ arm-fix-iommu-rockchip.patch | 51 ++++++++++++++++++++++++++++++++++++++++++ kernel.spec | 9 +++++++ 4 files changed, 156 insertions(+), 0 deletions(-) create mode 100644 arm-fix-iommu-exynos.patch create mode 100644 arm-fix-iommu-omap.patch create mode 100644 arm-fix-iommu-rockchip.patch diff --git a/arm-fix-iommu-exynos.patch b/arm-fix-iommu-exynos.patch new file mode 100644 index 0000000..447716f --- /dev/null +++ b/arm-fix-iommu-exynos.patch @@ -0,0 +1,48 @@ +From: Thierry Reding <treding at nvidia.com> + +The Exynos System MMU driver unconditionally executes code and registers +a struct iommu_ops with the platform bus irrespective of whether it runs +on an Exynos SoC or not. This causes problems in multi-platform kernels +where drivers for other SoCs will no longer be able to register their +own struct iommu_ops or even try to use a struct iommu_ops for an IOMMU +that obviously isn't there. + +The smallest fix I could think of is to check for the existence of any +Exynos System MMU devices in the device tree and skip initialization +otherwise. + +This fixes a problem on Tegra20 where the DRM driver will try to use the +obviously non-existent Exynos System MMU. + +Reported-by: Nicolas Chauvet <kwizart at gmail.com> +Cc: Kukjin Kim <kgene at kernel.org> +Signed-off-by: Thierry Reding <treding at nvidia.com> +--- +Changes in v2: +- drop reference to struct device_node + + drivers/iommu/exynos-iommu.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c +index 7ce52737c7a1..dc14fec4ede1 100644 +--- a/drivers/iommu/exynos-iommu.c ++++ b/drivers/iommu/exynos-iommu.c +@@ -1186,8 +1186,15 @@ static const struct iommu_ops exynos_iommu_ops = { + + static int __init exynos_iommu_init(void) + { ++ struct device_node *np; + int ret; + ++ np = of_find_matching_node(NULL, sysmmu_of_match); ++ if (!np) ++ return 0; ++ ++ of_node_put(np); ++ + lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table", + LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL); + if (!lv2table_kmem_cache) { +-- +2.1.3 diff --git a/arm-fix-iommu-omap.patch b/arm-fix-iommu-omap.patch new file mode 100644 index 0000000..cf864ae --- /dev/null +++ b/arm-fix-iommu-omap.patch @@ -0,0 +1,48 @@ +From: Thierry Reding <treding at nvidia.com> + +The OMAP IOMMU driver unconditionally executes code and registers a +struct iommu_ops with the platform bus irrespective of whether it runs +on an OMAP SoC or not. This causes problems in multi-platform kernels +where drivers for other SoCs will no longer be able to register their +own struct iommu_ops or even try to use a struct iommu_ops for an IOMMU +that obviously isn't there. + +The smallest fix I could think of is to check for the existence of any +OMAP IOMMU devices in the device tree and skip initialization otherwise. + +This fixes a problem on Tegra20 where the DRM driver will try to use the +obviously non-existent OMAP IOMMU. + +Reported-by: Nicolas Chauvet <kwizart at gmail.com> +Cc: Tony Lindgren <tony at atomide.com> +Cc: Suman Anna <s-anna at ti.com> +Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com> +Signed-off-by: Thierry Reding <treding at nvidia.com> +--- +Changes in v2: +- do not fix up module exit function since it's dead code +- drop reference to struct device_node + + drivers/iommu/omap-iommu.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c +index f59f857b702e..a4ba851825c2 100644 +--- a/drivers/iommu/omap-iommu.c ++++ b/drivers/iommu/omap-iommu.c +@@ -1376,6 +1376,13 @@ static int __init omap_iommu_init(void) + struct kmem_cache *p; + const unsigned long flags = SLAB_HWCACHE_ALIGN; + size_t align = 1 << 10; /* L2 pagetable alignement */ ++ struct device_node *np; ++ ++ np = of_find_matching_node(NULL, omap_iommu_of_match); ++ if (!np) ++ return 0; ++ ++ of_node_put(np); + + p = kmem_cache_create("iopte_cache", IOPTE_TABLE_SIZE, align, flags, + iopte_cachep_ctor); +-- +2.1.3 diff --git a/arm-fix-iommu-rockchip.patch b/arm-fix-iommu-rockchip.patch new file mode 100644 index 0000000..def4a0d --- /dev/null +++ b/arm-fix-iommu-rockchip.patch @@ -0,0 +1,51 @@ +From: Thierry Reding <treding at nvidia.com> + +The Rockchip IOMMU driver unconditionally executes code and registers a +struct iommu_ops with the platform bus irrespective of whether it runs +on a Rockchip SoC or not. This causes problems in multi-platform kernels +where drivers for other SoCs will no longer be able to register their +own struct iommu_ops or even try to use a struct iommu_ops for an IOMMU +that obviously isn't there. + +The smallest fix I could think of is to check for the existence of any +Rockchip IOMMU devices in the device tree and skip initialization +otherwise. + +This fixes a problem on Tegra20 where the DRM driver will try to use the +obviously non-existent Rockchip IOMMU. +Reported-by: Nicolas Chauvet <kwizart at gmail.com> +Cc: Heiko Stuebner <heiko at sntech.de> +Cc: Daniel Kurtz <djkurtz at chromium.org> +Reviewed-by: Heiko Stuebner <heiko at sntech.de> +Tested-by: Heiko Stuebner <heiko at sntech.de> +Signed-off-by: Thierry Reding <treding at nvidia.com> +--- +Changes in v2: +- do not fix up module exit function since it's dead code +- drop reference to struct device_node + + drivers/iommu/rockchip-iommu.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c +index 6a8b1ec4a48a..9f74fddcd304 100644 +--- a/drivers/iommu/rockchip-iommu.c ++++ b/drivers/iommu/rockchip-iommu.c +@@ -1015,8 +1015,15 @@ static struct platform_driver rk_iommu_driver = { + + static int __init rk_iommu_init(void) + { ++ struct device_node *np; + int ret; + ++ np = of_find_matching_node(NULL, rk_iommu_dt_ids); ++ if (!np) ++ return 0; ++ ++ of_node_put(np); ++ + ret = bus_set_iommu(&platform_bus_type, &rk_iommu_ops); + if (ret) + return ret; +-- +2.1.3 diff --git a/kernel.spec b/kernel.spec index 2d62fa8..496ca99 100644 --- a/kernel.spec +++ b/kernel.spec @@ -590,6 +590,11 @@ Patch21026: pinctrl-pinctrl-single-must-be-initialized-early.patch Patch21028: arm-i.MX6-Utilite-device-dtb.patch +# IOMMU crash fixes - https://lists.linuxfoundation.org/pipermail/iommu/2015-February/012329.html +Patch21030: arm-fix-iommu-omap.patch +Patch21031: arm-fix-iommu-exynos.patch +Patch21032: arm-fix-iommu-rockchip.patch + Patch21100: arm-highbank-l2-reverts.patch #rhbz 754518 @@ -1246,6 +1251,10 @@ ApplyPatch pinctrl-pinctrl-single-must-be-initialized-early.patch ApplyPatch arm-i.MX6-Utilite-device-dtb.patch +ApplyPatch arm-fix-iommu-omap.patch +ApplyPatch arm-fix-iommu-exynos.patch +ApplyPatch arm-fix-iommu-rockchip.patch + ApplyPatch arm-highbank-l2-reverts.patch # -- 1.7.2.1

3 3

ntfs kernel module
by Jeff Sadowski 03 Mar '15

03 Mar '15

I was wondering why only ntfs-3g method of mounting ntfs partitions is all that is supported? If the ntfs kernel module was build then it would be all that should be needed to boot from an ntfs partition. You could use the read only during the boot up procedure and remount it with ntfs-3g when booted.

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel March 2015