Hide Forgot
Reporting this for John Call <jcall>: 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.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:
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.
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?
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.
.. 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.
(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
(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.
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".
(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...
(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.
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.
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.
(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.
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?
*********** 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.
*********** 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.
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?
(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.
(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.
> 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 :)
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!