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
7 years, 10 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
Rawhide 3.19 schedule-ish
by Josh Boyer
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
8 years, 5 months
Re: 3.19 Nouveau changes fedback
by Josh Boyer
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
8 years, 5 months
drawback of transparent_hugepage=always?
by Reindl Harald
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-o...
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/...
____________________________________________________
[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
____________________________________________________
8 years, 6 months
[PATCH] drm/i915: Ignore long hpds on eDP ports
by David Airlie
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
8 years, 6 months
