kernel December 2014

kernel@lists.fedoraproject.org

4 participants
7 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

Rawhide 3.19 schedule-ish
by Josh Boyer 05 Jan '15

05 Jan '15

Hi All, The 3.19 merge window has been open for a bit over a week now. As you've (maybe) noticed, rawhide continues to be on the 3.18 kernel. Last week the kernel team was travelling and handling a merge window while travelling is recipe for disaster (and/or insanity). That means that this would be the week to start landing merge window builds. However, most of us will be on PTO for the end of December, which would leave rawhide in a somewhat untidy state. Even getting to -rc1 and then disappearing for an extended time doesn't seem all that pleasant. For now, we'll leave rawhide tracking the 3.18.y releases and pick up the 3.19-rcX kernels when we return. I will send a call for testing once we start rebasing again. Until then, a special present to you will be a bit of (maybe unwanted) stability. If you have any questions/comments, please let us know. josh

2 2

Re: 3.19 Nouveau changes fedback
by Josh Boyer 25 Dec '14

25 Dec '14

On Dec 25, 2014 12:42 AM, "Bruno Wolff III" <bruno(a)wolff.to> wrote: > > The Nouveau changes in 3.19 fixed one problem I was having (that I didn't > have when I tested the nVidia driver for comparison), but it doesn't fix > some resolution limitations I have. > > When playing GOG's homm3 via wine I need to use 800x600 to use the full > screen. When I boot using nouveau the display is 1680x1050 in the desktop. > (When I booted with the nVidia driver the display used a different > resolution.) When I go to the display settings most of the common 4:3 > resolutions are supposed to be available, but when I try them the screen > ends scrambled. This makes 800x600 unusable. As a work around I used > scaling via xrandr to make make the screen work as 800x600. When combined > with screen emulation in wine, this almost worked. I had a problem with > a hang in multiplayer hotseat when using nouveau, but not nVidia. However > this last problem is now fixed in 3.19. > > For the resolution issue should I be filing bugs for Fedora against > xorg-x11-drv-nouveau or would I be better off going upstream? Either works but upstream is usually better in most cases. Particularly right now since you're testing something that isn't available in Fedora yet. Thanks for testing. josh

2 1

drawback of transparent_hugepage=always?
by Reindl Harald 11 Dec '14

11 Dec '14

Google around brings no clear statement is there any drawback of boot with "transparent_hugepage=always" which seems not to be the default currently - as far as i understand it should recude the overhead of memory management (especially in virtual guests) and seems to have been the default for some time http://oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-… at least talks about "You can check the current setting using the following command, which is displaying the default value of "enabled=[always]" https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/ht… ____________________________________________________ [root@testserver:~]$ cat /sys/kernel/mm/transparent_hugepage/enabled always [madvise] never [root@testserver:~]$ grep Huge /proc/meminfo AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB ____________________________________________________ [root@testserver:~]$ cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never [root@testserver:~]$ grep Huge /proc/meminfo AnonHugePages: 194560 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB ____________________________________________________

2 2

stable 3.17.6
by poma 07 Dec '14

07 Dec '14

in less than a day https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.17.6 Date: Sun Dec 7 11:48:01 2014 -0800 one and only commit ... This reverts commit ... which was commit ... which was reverted in commit ... :) https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.17.5 Date: Sat Dec 6 15:57:59 2014 -0800 Regarding 3.18, Fedora 21 will follow .2 cadence, as usual? https://www.kernel.org

1 0

[PATCH] drm/i915: Ignore long hpds on eDP ports
by David Airlie 01 Dec '14

01 Dec '14

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Turning vdd on/off can generate a long hpd pulse on eDP ports. In order to handle hpd we would need to turn on vdd to perform aux transfers. This would lead to an endless cycle of "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..." So ignore long hpd pulses on eDP ports. eDP panels should be physically tied to the machine anyway so they should not actually disappear and thus don't need long hpd handling. Short hpds are still needed for link re-train and whatnot so we can't just turn off the hpd interrupt entirely for eDP ports. Perhaps we could turn it off whenever the panel is disabled, but just ignoring the long hpd seems sufficient. Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: stable(a)vger.kernel.org Reviewed-by: Dave Airlie <airlied(a)redhat.com> Reviewed-by: Todd Previte <tprevite(a)gmail.com> Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- drivers/gpu/drm/i915/intel_dp.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 4b3c096..1b7375e 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4084,6 +4084,18 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd) if (intel_dig_port->base.type != INTEL_OUTPUT_EDP) intel_dig_port->base.type = INTEL_OUTPUT_DISPLAYPORT; + if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) { + /* + * vdd off can generate a long pulse on eDP which + * would require vdd on to handle it, and thus we + * would end up in an endless cycle of + * "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..." + */ + DRM_DEBUG_KMS("ignoring long hpd on eDP port %c\n", + port_name(intel_dig_port->port)); + return false; + } + DRM_DEBUG_KMS("got hpd irq on port %d - %s\n", intel_dig_port->port, long_hpd ? "long" : "short"); -- 1.9.3

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel December 2014