Bug 1026359 - Unstable link speed with e1000e module
Unstable link speed with e1000e module
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: John Greene
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-04 08:53 EST by John Greene
Modified: 2014-05-15 12:33 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-15 12:33:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tuned.log (38.00 KB, text/plain)
2013-11-05 00:30 EST, John Call
no flags Details
messages (331.88 KB, text/plain)
2013-11-05 00:32 EST, John Call
no flags Details

  None (edit)
Description John Greene 2013-11-04 08:53:50 EST
Reporting this for John Call <jcall@redhat.com>: he will be the "reporter"
--John G.

Description of problem:
.. T520 laptop with Fedora 19
e1000e kernel module produce unstable network link speeds? I've observed for several months that my NIC will drop down to 100Mb/s instead of staying at 
1,000Mb/s. This happens at my home office using both a Western Digital 
home wifi router (N750 w/ gigabit ports), and a NetGear 24-port (also 
gigabit). This also happens when I visit the lab which has 
enterprise-class switches -- namely, Cisco 2970 and IBM 8052 (both 
gigabit). I often move virtual machines to/from my laptop. Having a 
100Mb/s connection when moving these large (~20GB) files causes me to 
pull my hair out.

The issue appears to only happen when booting from an off state, or 
resuming from a sleep state. My experience has shown that if I remove 
the module (modprobe -r) and then re-insert it, that the link is stable 
at 1,000Mb/s indefinitely.

Also, I'm unaware of how to debug this issue deeper than inspecting 
the output of `dmesg`. I'd appreciate any advice on how to dig deeper, 
or advice on which list / community would be more appropriate.


 [root@laptop ~]# ethtool -i em1
driver: e1000e
Version: 2.3.2-k
>  > firmware-version: 0.13-3
>  > bus-info: 0000:00:19.0
>  > supports-statistics: yes
>  > supports-test: yes
>  > supports-eeprom-access: yes
>  > supports-register-dump: yes
>  > supports-priv-flags: no
>  >
>  > [root@laptop ~]# ethtool em1
>  > Settings for em1:
>  > Supported ports: [ TP ]
>  > Supported link modes: 10baseT/Half 10baseT/Full
>  > 100baseT/Half 100baseT/Full
>  > 1000baseT/Full
>  > Supported pause frame use: No
>  > Supports auto-negotiation: Yes
>  > Advertised link modes: 10baseT/Half 10baseT/Full
>  > 100baseT/Half 100baseT/Full
>  > Advertised pause frame use: No
>  > Advertised auto-negotiation: Yes
>  > Speed: 100Mb/s
>  > Duplex: Full
>  > Port: Twisted Pair
>  > PHYAD: 2
>  > Transceiver: internal
>  > Auto-negotiation: on
>  > MDI-X: on (auto)
>  > Supports Wake-on: pumbg
>  > Wake-on: g
>  > Current message level: 0x00000007 (7)
>  > drv probe link
>  > Link detected: yes
>  >
>  > [root@laptop ~]# modprobe -r e1000e
>  >
>  > [root@laptop ~]# modprobe e1000e
>  >
>  > [root@laptop ~]# ethtool em1
>  > Settings for em1:
>  > Supported ports: [ TP ]
>  > Supported link modes: 10baseT/Half 10baseT/Full
>  > 100baseT/Half 100baseT/Full
>  > 1000baseT/Full
>  > Supported pause frame use: No
>  > Supports auto-negotiation: Yes
>  > Advertised link modes: 10baseT/Half 10baseT/Full
>  > 100baseT/Half 100baseT/Full
>  > 1000baseT/Full
>  > Advertised pause frame use: No
>  > Advertised auto-negotiation: Yes
>  > Speed: 1000Mb/s
>  > Duplex: Full
>  > Port: Twisted Pair
>  > PHYAD: 2
>  > Transceiver: internal
>  > Auto-negotiation: on
>  > MDI-X: on (auto)
>  > Supports Wake-on: pumbg
>  > Wake-on: g
>  > Current message level: 0x00000007 (7)
>  > drv probe link
>  > Link detected: yes
>  >
>  > [root@laptop ~]#
>  >
>  > [jcall@jcall-laptop ~]$ dmesg | grep e1000e
>  > [ 4.805099] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
>  > [ 4.805102] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
>  > [ 4.810655] e1000e 0000:00:19.0: setting latency timer to 64
>  > [ 4.810725] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) 
> set to dynamic conservative mode
>  > [ 4.810750] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>  > [ 5.014656] e1000e 0000:00:19.0 eth0: registered PHC clock
>  > [ 5.014661] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 
> f0:de:f1:bb:9b:c0
>  > [ 5.014664] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network 
> Connection
>  > [ 5.014715] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 
> 1000FF-0FF
>  > [ 6.283712] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>  > [ 6.384787] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>  > [ 8.994724] e1000e: em1 NIC Link is Up 1000 Mbps Full Duplex, Flow 
> Control: Rx/Tx
>  > [ 59.836479] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
>  > [ 59.836491] e1000e 0000:00:19.0 em1: 10/100 speed: disabling TSO
>  > [ 108.733019] e1000e: em1 NIC Link is Down
>  > [ 111.344737] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
>  > [ 111.344747] e1000e 0000:00:19.0 em1: 10/100 speed: disabling TSO
>  > [ 142.090572] e1000e: em1 NIC Link is Down
>  > [ 144.738411] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
>  > [ 144.738423] e1000e 0000:00:19.0 em1: 10/100 speed: disabling TSO
>  > [ 1683.800846] e1000e: em1 NIC Link is Down
>  > [ 1686.430690] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
>  > [ 1686.430701] e1000e 0000:00:19.0 em1: 10/100 speed: disabling TSO
>  > [ 1930.256194] e1000e: em1 NIC Link is Down
>  > [ 1932.869065] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
>  > [ 1932.869076] e1000e 0000:00:19.0 em1: 10/100 speed: disabling TSO
>  > [ 2112.473811] e1000e: em1 NIC Link is Down
>  > [ 2115.086652] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
....
> Control: Rx/Tx
>  > [38585.601669] e1000e 0000:00:19.0 em1: 10/100 speed: disabling TSO
>  >
>  > <!-- REMOVED THE MODULE -->
>  > [39837.184310] e1000e 0000:00:19.0 em1: removed PHC
>  >
>  > <!-- INSERTED THE MODULE -->
>  > [39849.807558] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
>  > [39849.807562] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
>  > [39849.807700] e1000e 0000:00:19.0: setting latency timer to 64
>  > [39849.807805] e1000e 0000:00:19.0: Interrupt Throttling Rate 
> (ints/sec) set to dynamic conservative mode
>  > [39849.807842] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>  > [39850.008007] e1000e 0000:00:19.0 eth0: registered PHC clock
>  > [39850.008014] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width 
> x1) f0:de:f1:bb:9b:c0
>  > [39850.008018] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network 
> Connection
>  > [39850.008069] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 
> 1000FF-0FF
>  > [39850.168620] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>  > [39850.269431] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>  > [39853.448437] e1000e: em1 NIC Link is Up 1000 Mbps Full Duplex, Flow 
> Control: Rx/Tx
>  >
>  > [jcall@jcall-laptop ~]$ dmesg | tail -1 #TO SHOW THE TIMESTAMP OF THE 
> RUNNING KERNEL
>  > [48690.583326] virbr0: port 2(vnet0) entered forwarding state


> Did the problem go away when booting with 'pcie_aspm=off' added to the
> kernel command line?
> Check your cable is cat 5e or cat 6, not cat5
> 
> If this doesn't help, we can play with tuned, have installed in on my
> box to help if I can.
> 
> Did you ever file a bug for this?  Please forward bz number if so.
> 
> 
> I've added the kernel command line 'pcie_aspm=off", but that did not 
> make the problem go away.  Below is some output confirming the problem 
> is still there...  Also, I am using a Cat6
>   cable (6 feet / 2 meters of length) that was purchased pre-terminated 
> -- in other words, I didn't crimp the ends on myself.  I've also 
> verified that this happens with various other cables (Cat5e / Cat6a) and 
> switches.  Finally, no, I do not have a Bugzilla created for this.  I'm 
> not familiar with the process and would appreciate some some coaching.
> 

> [root@jcall-laptop ~]# rpm -q tuned
> tuned-2.2.2-1.fc19.noarch
> 
> [root@jcall-laptop ~]# tuned-adm list
> Available profiles:
> - balanced
> - latency-performance
> - powersave
> - throughput-performance
> - virtual-guest
> - virtual-host
> Current active profile: _*powersave*_
> 
> [root@jcall-laptop ~]# dmesg | head
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Initializing cgroup subsys cpuacct
> [    0.000000] Linux version 3.11.6-200.fc19.x86_64 
> (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 4.8.1 20130603 
> (Red Hat 4.8.1-1) (GCC) ) #1 SMP Fri Oct 18 22:34:18 UTC 2013
> [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.11.6-200.fc19.x86_64 
> root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 
> vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 
> rd.lvm.lv=fedora/root *pcie_aspm=off*
> [    0.000000] Disabled fast string operations
> [    0.000000] e820: BIOS-provided physical RAM map:
> [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable
> [    0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] 
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] 
> reserved
> 
> [root@jcall-laptop ~]# dmesg | grep "Link is Up" #These events happened 
> while I stepped out to make some purchases.
> [    8.632044] e1000e: em1 NIC Link is Up *1000* Mbps Full Duplex, Flow 
> Control: Rx/Tx
> [   57.795936] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
> [  369.984925] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
> [  672.800251] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
> [  836.111270] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
> [  952.359228] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 
> Control: Rx/Tx
> [  957.957668] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow 


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 John Greene 2013-11-04 09:01:48 EST
John,

Attach the whole dmesg log please.  It looks like your link is staying up for
long periods of time then flapping once.  That kind of suggests that perhaps
some local system event is predicating the link going down.  It might be caused
by the link parter too of course, but its easier to start looking on the local
end.
Comment 2 John Greene 2013-11-04 09:05:52 EST
Given you've eliminated cables, switches and aspm now, I am wondering: at locations where this others may share the router setup and possibly have identical hardware (T520 with same OS even) does anyone else report this problem on same hardware?  That would point away from your particular machine and eliminate your laptop being "bad" a bit.  Have you heard of this problem with co-workers similarly situated?
Comment 3 Christopher Wawak 2013-11-04 11:17:52 EST
I am encountering the same behavior, and I believe I tracked it down to the "powersave" tuned profile. I typically use the "virtual-host" profile while plugged in, but to reproduce, I have switched my laptop to "powersave", and hope to trigger this behavior soon. It typically takes an hour or so before I notice the instability. I'll upload a dmesg once I trigger it.
Comment 4 Christopher Wawak 2013-11-04 11:22:59 EST
.. that didn't take long.

Nov  4 10:42:27 localhost gnome-session[1766]: [3243:3243:1104/104227:ERROR:vsync_provider.cc(70)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0.
Nov  4 10:52:27 localhost gnome-session[1766]: [3243:3243:1104/105227:ERROR:vsync_provider.cc(70)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0.
Nov  4 11:02:28 localhost gnome-session[1766]: [3243:3243:1104/110228:ERROR:vsync_provider.cc(70)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0.
Nov  4 11:12:28 localhost gnome-session[1766]: [3243:3243:1104/111228:ERROR:vsync_provider.cc(70)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0.
Nov  4 11:15:19 localhost systemd-logind[658]: New session 379 of user cwawak.

>>> MARK tuned-adm profile powersave <<<

Nov  4 11:16:14 localhost NetworkManager[770]: <info> (em1): carrier now OFF (device state 100, deferring action for 4 seconds)
Nov  4 11:16:17 localhost kernel: [70964.594522] e1000e: em1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Nov  4 11:16:17 localhost kernel: [70964.594528] e1000e 0000:00:19.0 em1: 10/100 speed: disabling TSO
Nov  4 11:16:17 localhost NetworkManager[770]: <info> (em1): carrier now ON (device state 100)

... and another big hmm, this time from /var/log/tuned/tuned.log:

2013-11-04 11:15:14,318 INFO     tuned.plugins.plugin_cpu: setting new cpu latency 100
2013-11-04 11:16:14,325 INFO     tuned.plugins.plugin_net: wlp3s0: setting 100Mbps
2013-11-04 11:16:14,325 INFO     tuned.plugins.plugin_net: em1: setting 100Mbps
2013-11-04 11:16:44,659 INFO     tuned.plugins.plugin_cpu: setting new cpu latency 1000

This doesn't explain why the link seems to flap, though.
Comment 5 John Greene 2013-11-04 11:33:17 EST
(In reply to Christopher Wawak from comment #3)
> I am encountering the same behavior, and I believe I tracked it down to the
> "powersave" tuned profile. I typically use the "virtual-host" profile while
> plugged in, but to reproduce, I have switched my laptop to "powersave", and
> hope to trigger this behavior soon. It typically takes an hour or so before
> I notice the instability. I'll upload a dmesg once I trigger it.

Christopher: appreciate you sharing..To put a finer edge on this: 
You don't see the problem with the virtual host profile, but do when you switch over to power save?  A good clue if that's true.

John C: does this help your situation?  Have you used this virtual-host profile or were you aware of it?  Give it a try if you haven't, at least it might give your hair a break till we get a better solution..lol
Comment 6 Christopher Wawak 2013-11-04 11:46:59 EST
(In reply to John Greene from comment #5)

> Christopher: appreciate you sharing..To put a finer edge on this: 
> You don't see the problem with the virtual host profile, but do when you
> switch over to power save?  A good clue if that's true.

John, that's correct. Looking from the tuned logs in my last comment, it seems that plugin_net is setting my interface to 100Mbps. Digging through plugin_net (/usr/lib/python2.7/site-packages/tuned/plugin_net.py), I see the following:

                if idle["level"] == 0 and idle["read"] >= self._level_steps and idle["write"] >= self._level_steps:
                        idle["level"] = 1
                        log.info("%s: setting 100Mbps" % device)
                        ethcard(device).set_speed(100)
                elif idle["level"] == 1 and (idle["read"] == 0 or idle["write"] == 0):
                        idle["level"] = 0
                        log.info("%s: setting max speed" % device)
                        ethcard(device).set_max_speed()

So it certainly looks like tuned is setting the interface to 100Mbps, which is a known best practice for saving power. It seems like it's supposed to only tweak at idle, but I've never seen "setting max speed" in my logs, and I don't know what idle means in this setting. I'd be curious to see what John's /var/log/tuned/tuned.log looks like, and I'm going to guess this is what is going on.

In any case, I don't think this is a bug in e1000e, but you might be able to argue that a modification should be made in tuned if the speed changes are disruptive enough. I wonder if there's a way to tweak tuned so it ignores a particular network interface.
Comment 7 Christopher Wawak 2013-11-04 12:26:14 EST
John Call,

Can you do the following:

1. Set tuned to the powersave profile 
(# tuned-adm profile powersave)

2. Let the interface drop to 100.

3. Once it does, can you send us the last few lines of /var/log/tuned/tuned.log?

We're looking for something like "tuned.plugins.plugin_net: em1: setting 100Mbps".
Comment 8 John Call 2013-11-04 17:01:22 EST
(In reply to John Greene from comment #5)
> (In reply to Christopher Wawak from comment #3)
> > I am encountering the same behavior, and I believe I tracked it down to the
> > "powersave" tuned profile. I typically use the "virtual-host" profile while
> > plugged in, but to reproduce, I have switched my laptop to "powersave", and
> > hope to trigger this behavior soon. It typically takes an hour or so before
> > I notice the instability. I'll upload a dmesg once I trigger it.
> 
> Christopher: appreciate you sharing..To put a finer edge on this: 
> You don't see the problem with the virtual host profile, but do when you
> switch over to power save?  A good clue if that's true.
> 
> John C: does this help your situation?  Have you used this virtual-host
> profile or were you aware of it?  Give it a try if you haven't, at least it
> might give your hair a break till we get a better solution..lol

JohnG,

Yes, tuned is a problem for me.  I observed my system drop to 100Mb/s when configured to use "powersave" mode -- my initial complaint.  After setting my tuned mode to "virtual-host" the link automatically re-established at 1,000Mb/s.  I'm using my T520 laptop, FYI.  My preference would be to have full gigabit speed in addition to using the balanced/power-save mode of tuned.

I recognize that some additional requests have been made of me in subsequent comments and will reply later to those specific questions shortly...
Comment 9 John Call 2013-11-04 23:57:39 EST
(In reply to Christopher Wawak from comment #6)
> (In reply to John Greene from comment #5)
> 
> > Christopher: appreciate you sharing..To put a finer edge on this: 
> > You don't see the problem with the virtual host profile, but do when you
> > switch over to power save?  A good clue if that's true.
> 
> John, that's correct. Looking from the tuned logs in my last comment, it
> seems that plugin_net is setting my interface to 100Mbps. Digging through
> plugin_net (/usr/lib/python2.7/site-packages/tuned/plugin_net.py), I see the
> following:
> 
>                 if idle["level"] == 0 and idle["read"] >= self._level_steps
> and idle["write"] >= self._level_steps:
>                         idle["level"] = 1
>                         log.info("%s: setting 100Mbps" % device)
>                         ethcard(device).set_speed(100)
>                 elif idle["level"] == 1 and (idle["read"] == 0 or
> idle["write"] == 0):
>                         idle["level"] = 0
>                         log.info("%s: setting max speed" % device)
>                         ethcard(device).set_max_speed()
> 
> So it certainly looks like tuned is setting the interface to 100Mbps, which
> is a known best practice for saving power. It seems like it's supposed to
> only tweak at idle, but I've never seen "setting max speed" in my logs, and
> I don't know what idle means in this setting. I'd be curious to see what
> John's /var/log/tuned/tuned.log looks like, and I'm going to guess this is
> what is going on.
> 
> In any case, I don't think this is a bug in e1000e, but you might be able to
> argue that a modification should be made in tuned if the speed changes are
> disruptive enough. I wonder if there's a way to tweak tuned so it ignores a
> particular network interface.

Christopher, if the intent was to save power by capping the NIC at 100Mb/s, that's fine -- but I still have issue with the link going up and down all the time (flapping).  Comment #1 shows the link flapping 5 times and each time coming back up at the same speed.  These link up/down events tend to break VPN connections.  I'm not sure if they happen in the middle of large file transfers, but I do know that they impact web browsing and SSH connections.
Comment 10 John Call 2013-11-05 00:30:46 EST
Created attachment 819518 [details]
tuned.log

The tuned log which shows powersave profile (configured prior to boot) which produces an unstable link at 100Mb/s.  The virtual-host profile was enabled, which stabilized the link and increased the speed to 1,000Mb/s.
Comment 11 John Call 2013-11-05 00:32:01 EST
Created attachment 819519 [details]
messages

The output from /var/log/messages which aligns with the times reported in the tuned.log file attached to this bug.
Comment 12 John Call 2013-11-05 00:52:30 EST
(In reply to Christopher Wawak from comment #7)
> John Call,
> 
> Can you do the following:
> 
> 1. Set tuned to the powersave profile 
> (# tuned-adm profile powersave)
> 
> 2. Let the interface drop to 100.
> 
> 3. Once it does, can you send us the last few lines of
> /var/log/tuned/tuned.log?
> 
> We're looking for something like "tuned.plugins.plugin_net: em1: setting
> 100Mbps".

Chris, I've attached the logs.  While I was preparing the logs, I counted 30 link up/down events from boot (powersave profile) until I changed to virtual-host profile.  The tuned log reports only two messages about changing the link speed, but the kernel reports 30 up/down events.

Are you seeing similar instabilities?  I wonder if this is due to the NIC being set at a static 100Mb/s Full duplex configuration, while the switch is configured for automatic negotiation.  I was connected to a WesternDigital wifi router (N750).  I wonder if the amount of link flap or up/down would change if I had been connected to the Cisco or IBM enterprise-class switches.
Comment 13 John Greene 2013-11-05 15:36:36 EST
Took a quick look at your log, need to look a bit more.  I'm thinking out loud a bit here, maybe Chris knows: could the flap issue be caused by  NetworkManager and the driver rate negotiation with the switch, and tuned all banging heads? 

Need to look at that more..Perhaps making the nic unmanaged for testing might be interesting.Thoughts?
Comment 14 Justin M. Forbes 2014-01-03 17:07:57 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.12.6-200.fc19.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.

If you experience different issues, please open a new bug report for those.
Comment 15 Justin M. Forbes 2014-02-24 08:57:48 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 17 John Call 2014-03-04 22:07:40 EST
Thank you for the additional background info, Jeremy!

I'm using tuned-2.3.0-2.fc20.noarch

I disabled dynamic_tuning and set my profile to 'powersave'.  The NIC link and speed are stable.

As an aside, does the "kernel-tools" package need to be marked as a dependency of tuned?  Nasty errors show up in tuned.log about missing "cpupower" and "x86_energy_perf_policy" without that package installed.  See below...

Thanks again!

2014-03-04 14:39:51,016 ERROR    tuned.utils.commands: Executing cpupower error: [Errno 2] No such file or directory
2014-03-04 14:39:51,016 WARNING  tuned.plugins.plugin_cpu: using sysfs fallback, is cpupower installed?
2014-03-04 14:39:51,019 ERROR    tuned.utils.commands: Executing x86_energy_perf_policy error: [Errno 2] No such file or directory
2014-03-04 14:39:51,019 WARNING  tuned.plugins.plugin_cpu: error executing x86_energy_perf_policy tool, ignoring CPU energy performance bias, is the tool installed?
Comment 18 Jaroslav Škarvada 2014-03-05 10:10:36 EST
(In reply to John Call from comment #17)
> Thank you for the additional background info, Jeremy!
> 
> I'm using tuned-2.3.0-2.fc20.noarch
> 
Dynamic tuning is not globally disabled in Fedora.

> I disabled dynamic_tuning and set my profile to 'powersave'.  The NIC link
> and speed are stable.
> 
Or alternatively you can create your own powersave profile which disable the network plugin (which do the dynamic tuning of the network):
# mkdir /etc/tuned/custom-powersave && cat << :EOF > /etc/tuned/custom-powersave/tuned.conf
[main]
include=powersave

[net]
disabled=true
:EOF

# tuned-adm profile custom-powersave

> As an aside, does the "kernel-tools" package need to be marked as a
> dependency of tuned?  Nasty errors show up in tuned.log about missing
> "cpupower" and "x86_energy_perf_policy" without that package installed.  See
> below...

Thanks for spotting this, I created bug 1072981.
Comment 19 Christopher Wawak 2014-03-05 15:17:19 EST
(In reply to Jaroslav Škarvada from comment #18)

> Or alternatively you can create your own powersave profile which disable the
> network plugin (which do the dynamic tuning of the network):
> # mkdir /etc/tuned/custom-powersave && cat << :EOF >
> /etc/tuned/custom-powersave/tuned.conf
> [main]
> include=powersave
> 
> [net]
> disabled=true
> :EOF

Jaroslav, I tried this, and I see the following errors in tuned.log:

2014-03-05 15:10:11,360 INFO     tuned.plugins.plugin_net: devices: set([u'wlp3s0', u'em1'])
2014-03-05 15:10:11,360 WARNING  tuned.plugins.base: Unknown option 'disabled' for plugin 'NetTuningPlugin'.
2014-03-05 15:10:11,360 INFO     tuned.plugins.base: instance net: assigning devices wlp3s0, em1
2014-03-05 15:11:01,670 INFO     tuned.plugins.plugin_net: wlp3s0: setting 100Mbps
2014-03-05 15:11:11,681 INFO     tuned.plugins.plugin_net: em1: setting 100Mbps

So, I'm not sure if the disabled=true is working as inteded for the net plugin.
Comment 20 Jaroslav Škarvada 2014-03-05 15:28:37 EST
> Jaroslav, I tried this, and I see the following errors in tuned.log:
> 
> 2014-03-05 15:10:11,360 INFO     tuned.plugins.plugin_net: devices:
> set([u'wlp3s0', u'em1'])
> 2014-03-05 15:10:11,360 WARNING  tuned.plugins.base: Unknown option
> 'disabled' for plugin 'NetTuningPlugin'.
> 2014-03-05 15:10:11,360 INFO     tuned.plugins.base: instance net: assigning
> devices wlp3s0, em1
> 2014-03-05 15:11:01,670 INFO     tuned.plugins.plugin_net: wlp3s0: setting
> 100Mbps
> 2014-03-05 15:11:11,681 INFO     tuned.plugins.plugin_net: em1: setting
> 100Mbps
> 
> So, I'm not sure if the disabled=true is working as inteded for the net
> plugin.

I am sorry, it should be:
[net]
enabled=false

:)
Comment 21 John Call 2014-05-15 12:33:15 EDT
Closing this bug, as "notabug".  My issue was caused by the dynamic tuning of tuned and was solved by choosing a more appropriate profile (virtual-host) or customizing the existing profiles.

Thanks everybody!

Note You need to log in before you can comment on or make changes to this bug.