Re: [kernel/f21] Make sure acpi brightness_switch is disabled (like forever in Fedora)
by Hans de Goede
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/?...
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
8 years, 7 months
fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg
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
8 years, 9 months
[PATCH 1/2] ARMv7: add patches to fix crash on boot for some devices on multiplatform
by Nicolas Chauvet
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
8 years, 12 months
ntfs kernel module
by Jeff Sadowski
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.
9 years