After yet another failed nVidia card (fine for gamers that upgrade every few months and wouldn't run them that long), I decided to ditch the whole lot and update to a nice new Intel Haswell board with and use the built-in Intel HD Graphics... well actually it's not quite that simple.

In my case I have an HD 4600, and running an LTS release of Mint (or the corresponding Ubuntu) with this presents a few problems. To complicate things further, I also have a multi-monitor setup.

Getting support

While basic graphics may appear to work (single monitor), check /var/log/Xorg.0.log and you may well find it's using the generic VESA driver. That also won't support multi-monitor. You will need to to update to a a kernel and Xorg version that supports this chipset.

For a kernel I've had the best success with linux-generic-lts-saucy which puts in the 3.11.0 series. You may need to update virtualbox as well if you use it.

Then for X you will need xserver-xorg-lts-raring which will give the necessary support for this chipset.

Multi-monitor config

To setup you can use xrandr doing something like:

xrandr --output HDMI2 --right-of HDMI1

... but that will need doing every time you start X so will need some scripting or other automatic start. Another option is just to create a minimal /etc/xorg.conf which causes X to always do multi-monitor. This is good for a workstation, but possibly best to leave it to the GUI tools for laptops.

There is a very good basic example on the Intel Open Source Technology Center site of a static setup with xorg.conf for multi-monitor with Intel Graphics.

At this point things are basically working, until I fired up mythtv....

Video playing problems

I was getting lots of stalling playing video (if at all) and lines like this being logged:

[drm:ring_stuck] *ERROR* Kicking stuck wait on render ring

After some research I found a workaround from Matthias B on working around this problem on Haswell with a clone setup and it works for me with the multi-monitor setup (see #10). Basically add the following to the Device section:

Option "AccelMethod" "uxa"

At this point I have a fully working

Full example xorg.conf

Section "Monitor"
    Identifier     "Monitor0"
    Option          "Primary" "true"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    Option          "RightOf" "Monitor0"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection "Display"
        Depth       24
    EndSubSection
EndSection

#Section "Module"
#   Load    "glx"
#EndSection

Section "Device"
    Identifier     "Device0"
    Driver  "intel"
    Option  "monitor-HDMI1" "Monitor0"
    Option  "monitor-HDMI2" "Monitor1"
    Option  "AccelMethod"   "uxa"
EndSection

Side effects (ethernet)

The new board has an Realtek 8111GR and with the 3.8.0 kernel it allows the MTU to be set as high as 9200... well that's a bit suspect to start with. The catch here is that when you try transferring packets above above 1504 bytes (1476 payload) they simply vanish without a trace. If MTU is set to 1500 then we get the expected ICMP response when DF is set on packets.

This looks simply like this kernel is not working properly within the limitations of the chipset. The easy workaround for this is to ensure that MTU is left at 1500 (legacy small frames). Personally, I've put back the Intel PCIe card I used with my previous board, and things like MythTV are immediately dramatically more responsive. While the level of improvement is unexpected, it's clear that between the kernel and chipset there is clearly some deficiencies.