How to Optimize Intel Graphics Performance on Fedora KDE Linux Laptop

For several years I’ve struggled with poor Intel integrated graphics performance on my Dell Precision Mobile 7510 (Intel HD 530 primary and Quadro M2000M discrete via Bumblebee) on Fedora Linux. After starting to experience hard full system locks on video playback requiring a hard power off a few times a week, I have dug into the settings yet another time and finally had a breakthrough.
The symptoms I was experiencing were:

  • High baseline idle CPU consumption in Chrome/Chromium and IntelliJ/PyCharm
  • Extremely high CPU consumption on video playback in Chrome/Chromium and scrolling
  • Extremely high CPU consumption working in IntelliJ/PyCharm with huge typing, scrolling, rendering lag
  • Obvious resultant high fan speed/noise
  • Obvious resultant poor battery life
  • Extremely low framerate on two 4K 60Hz Samsung monitors connected via a Thunderbolt hub with simple window rendering, browsing and video
  • Extreme tearing of high resolution video or full-screen 1080p upscaled to 4K video in VLC and Chrome/Chromium

Below is the final configuration that I came up with that resolved all of my issues. While the exact configuration is specific to Fedora and my system, with minor modifications it can be easily applied to all other Linux flavors. Similarly this likely should also apply to other Dell Precision Mobile 5000- and 7000-series laptops as well as the XPS and Inspiron lines. I have also verified this to be working on at least one Intel NUC.

All recommendations are provided AS IS with no warranties or guarantees of any kind. You accept all responsibility for any and all consequences of your following of the instructions below.

Continue reading “How to Optimize Intel Graphics Performance on Fedora KDE Linux Laptop”

PSA: Default Configuration IPMI Vulnerability on Supermicro Boards

I’m using Supermicro boards (X11SBA-F) for virtually all of my servers, including the firewall. These boards come with IPMI enabled. The IPMI default configuration vulnerability I’m going to describe here rears its ugly head in dual-homed machines and machines plugged directly to WAN, putting them specifically in great danger.

Continue reading “PSA: Default Configuration IPMI Vulnerability on Supermicro Boards”

PSA: X11SBA-F rev 1.01 secondary LAN port timeouts

Hopefully this post will save someone time, money and aggravation. If you’re considering buying Supermicro X11SBA-F/LN4F you need to be aware that at the very least some boards (and possibly all) with a hardware revision 1.01 have serious and seemingly non-correctable issues with a secondary PCI-E bridge that feeds secondary LANs. DO NOT BUY X11SBA rev 1.01 if you need secondary NICs and always make sure the hardware revision is at least rev 1.02.

X11SBA series are very nice low-cost ridiculously low-power feature-packed boards that allow you to get 3 firewalls/domain controllers/PBX appliances for under $1000 total (if you shop around), with growth capability that should last you a decade (assuming you’re using Linux/BSD and not Windows, of course). One of the key features in addition to multi-core is that -F model comes with 2 GbE NICs, while -LN4F features for 4 GbE NICs.

Here’s the problem: the NIC #2 on -F and NICs #2, #3 and #4 on -LN4F sit on top of a separate PCI-E bridge than the 1st NIC. And that secondary bridge seems to have hardware problems for X11SBA hardware rev 1.01 causing transfer failures and requiring LAN PHY reset.

The problem manifests itself in the following way. LAN comes up, responds to pings and passes traffic happily. As the load increases you suddenly lose all connectivity. On FreeBSD 10/11 this failure looks like this:

igb1: Watchdog timeout -- resetting
igb1: Queue(846295657) tdh = -1249464976, hw tdt = 589450809
igb1: TX(846295657) desc avail = 0,Next TX to Clean = 0
igb1: link state changed to DOWN
igb1: link state changed to UP
igb1: Watchdog timeout -- resetting
igb1: Queue(846295657) tdh = -1249464976, hw tdt = 589450809
igb1: TX(846295657) desc avail = 0,Next TX to Clean = 0
igb1: link state changed to DOWN
igb1: link state changed to UP

This issue will be easily reproducible by using iperf as follows:

$ iperf -c <your reliable iperf server> -d -t600 -l1m -e -i1

[  5] local <client IP> port 60094 connected with <server IP> port 5001
[  4] local <server IP> port 5001 connected with <client IP> port 58122
[ ID] Interval        Transfer    Bandwidth       Write/Err  Rtry    Cwnd
[  5] 0.00-1.00 sec   112 MBytes   940 Mbits/sec  112/0         0   1377K
[  4] 0.00-1.00 sec  31.6 MBytes   265 Mbits/sec  3662    3659:1:1:1:0:0:0:0
[  5] 1.00-2.00 sec   104 MBytes   872 Mbits/sec  104/0        78    858K
[  4] 1.00-2.00 sec  32.4 MBytes   271 Mbits/sec  4160    4157:0:2:0:0:0:0:1
...
[  5] 49.00-50.00 sec  41.0 MBytes   344 Mbits/sec  41/0         0    718K
[  5] 50.00-51.00 sec  39.7 MBytes   333 Mbits/sec  40/0         1      1K
[  4] 50.00-51.00 sec  86.4 MBytes   724 Mbits/sec  3617    3611:3:2:0:0:0:0:1
[  5] 51.00-52.00 sec   445 KBytes  3.65 Mbits/sec  1/1         1      1K
[  4] 51.00-52.00 sec  0.00 Bytes  0.00 bits/sec  0    0:0:0:0:0:0:0:0
[  5] 52.00-53.00 sec  0.00 Bytes  0.00 bits/sec  0/2         1      1K

What To Do to Fix X11SBA

What will NOT work to fix the issue:

  • Disabling ACPI
  • Disabling MSI-X
  • Disabling MSI
  • Increasing mbuf or whatever network stack memory buffers are called on your OS
  • Disabling PCI-E power management (ASPM)
  • Tuning sysctl
  • Updating BIOS
  • Updating LAN EEPROM
  • Messing with BIOS settings, power management etc.

If any of the manipulations above solve your problem, you’re not experiencing the hardware issue I’m describing and it’s likely software, settings or both.

If you are having the hardware problem there is nothing you will be able to do short of RMAing your X11SBA with Supermicro asking them to provide you with a board revision 1.02 or higher or returning your board to the retailer. If you are requesting an RMA, make sure to describe the problem in exhaustive detail and/or provide them a link to this article. It took me two RMAs to get my problem solved – the first time the tech only tested for “ping OK” and declared the board functional after updating LAN EEPROM.

Links:

  1. pfSense forum describing the watchdoggate in detail.
  2. Watchdoggate described from the Linux side of the playground.