X-Regressions dot ARRRGH

Last modified: Sat Jan 14 14:09:45 EST 2017

All referenced drivers are 32-bit x86 Linux unless otherwise stated.

      Nvidia download links
      Nvidia driver versions
      Nvidia patching how-to
      Nvidia MTRR fiasco
      Extinction events
            Mesa library
            Utah GLX
      Slackware cross-index for last working versions
Reversion kits
      Nvidia 71.86.15
      Nvidia 96.43.23, S3 ViRGE, S3 Trio3D, SiS 315, and Trident (XAA)
      Nvidia 173.14.39
      Nvidia 304.xxx
Experiences with drivers generically
      Nvidia proprietary driver
Experiences with specific cards / chipsets
      Intel integrated graphics

Nvidia download links

You need all of these because the links don't always get updated.

Nvidia driver versions

(Ignoring 340.xx and everything newer)

The 304 series, which remains in maintenance, is ostensibly the right choice for GeForce 6 series cards, but the following problems cause me to revert to 173.14.39 or 96.43.23.

  1. Support for custom modelines has been unreliable since the version jump from 295 to 304.  As of 304.123, custom modelines are accepted if Option "ModeValidation" "AllowNonEdidModes" is added to Section "Device", but only sometimes will it do the right thing.  With 304.123 drivers, an AGP 6200, and a Dell 2007FP monitor, the 320×200 mode that I use for Chocolate DOOM was corrupted on DVI and horizontally squished on D-sub.  With 304.131, DVI is still corrupted but now the Nvidia driver segfaults on launch of X if D-sub is used.
  2. Support for Athlon and Pentium 2 CPUs was removed:
    NVIDIA OpenGL Driver requires CPUs with SSE to run.
    The current CPU does not support SSE.

173.14.39:  file date 2013-12-02; compatible with Slackware 14.1 or Reversion Kit 3.

2016-10:  With a Pentium 2 CPU, X crashes on launch with an illegal SSE instruction (sfence) at _nv001838X+0x2d in nvidia_drv.so.  Nvidia's README states "Setting the environment variable __GL_FORCE_GENERIC_CPU to a non-zero value will inhibit the use of CPU-specific features such as MMX, SSE, or 3DNOW!.  Use of this option may result in performance loss."  However, this apparently applies only to applications.  Setting this option on the X server did nothing.

96.43.23:  file date 2012-09-04; compatible with Slackware 14.0 or Reversion Kit 2.  96.43 is needed by cards in the GeForce2 MX to GeForce4 range but is usable with 6-series cards.

2016-10:  The Pentium 2 illegal instruction did not occur with 96.43.23.

71.86.15:  file date 2011-07-20; compatible with Reversion Kit 1.  The file date is misleading; apparently Nvidia maintained kernel compatibility for quite some time after they let the X server ABI breakage go to hell.  I had to go all the way back to Slackware 12.2 (2008-12) before the driver would work, which means that the last compatible X server version is either 1.4 or 1.5.

The last kernel for which the 71.86.15 module will build and load without patching is 3.2.x (a longterm branch), and then only with an old environment.  It worked for me with GCC 4.2.4 (what came with Slackware 12.2), but with GCC 4.8.2 under Slackware 14.1 it would say "Unknown symbol init_mm (err 0)" and refuse to load.

List of cards needing the 71.86 drivers:

    NVIDIA chip name                      Device PCI ID
    ----------------------------------    ----------------------------------
    RIVA TNT                              0x0020
    RIVA TNT2/TNT2 Pro                    0x0028
    RIVA TNT2 Ultra                       0x0029
    Vanta/Vanta LT                        0x002C
    RIVA TNT2 Model 64/Model 64 Pro       0x002D
    Aladdin TNT2                          0x00A0
    GeForce 256                           0x0100
    GeForce DDR                           0x0101
    Quadro                                0x0103
    GeForce2 GTS/GeForce2 Pro             0x0150
    GeForce2 Ti                           0x0151
    GeForce2 Ultra                        0x0152
    Quadro2 Pro                           0x0153

And they're serious about it.  The installer for 96.43.23 tests for a supported GPU and bails out with a very specific error if all it finds is a TNT card.

Nvidia patching how-to

How to incorporate a single patch using Nvidia's script

  1. First, remove any leading a/ b/ path prefixes from the patch because it will be applied with –p0.
  2. Do NVIDIA-Linux-... --apply-patch patchfile
  3. It applies the patch and produces a new archive with "custom" in the file name.

How to make manual edits

  1. Extract the sources with NVIDIA-Linux-... –x.
  2. Do the edits.
  3. Build and install by running nvidia-installer in the top directory.

The arch patches, which are contained in tarballs such as nvidia-96xx-dkms.tar.gz available from aur.archlinux.org, apply like follows:

cd usr/src/nv
patch -p1 < whatever/173.14.36-37.patch
patch -p1 < whatever/173.14.37-38.patch
patch -p1 < whatever/linux-3.17.patch
patch -p1 < whatever/linux-3.19.patch
patch -p1 < whatever/linux-4.0.patch

Kernel patches

See the reversion kits.

Nvidia MTRR fiasco

Nvidia 96, 173, and 304 (still, as of version 304.132) want to link with a couple of kernel functions, mtrr_add and mtrr_del, that were hidden (un-exported) by kernel devs in version 4.3.  This breaking change was an attempt to force drivers to migrate to a newer, architecture-agnostic API (commit 2baa891e42d84159b693eadd44f6fe1486285bdc).

The MTRR functions are useful only if PAT is not supported.  Both are used by the Nvidia driver to optimize the performance of the memory cache.  PAT has existed on Intel CPUs since the P3, but the kernel disables it on P3, Core Solo and Core Duo CPUs due to an erratum.

Since the MTRR function is useful only on very old CPUs, the workaround adopted in arch patches is to remove MTRR support from the Nvidia drivers.  This could kill performance on PCs with Core Duo or older CPUs.  While it is just as easy to put back the exports of mtrr_add and mtrr_del, the behavior of these now-hidden functions is not necessarily going to remain compatible with Nvidia.

When tested on an Athlon system where PAT was available, Nvidia 96.43.23 still used MTRR.  This is baffling, since "Changed driver behavior such that PAT (Page Attribute Table) is used where possible instead of MTRRs" supposedly happened in 1.0-7167 (March 11, 2005).

When tested on a P3 system where PAT was disabled by the kernel, Nvidia 304.132 (unpatched) built for kernel 4.7.6 with the MTRR exports added back still failed to use MTRR.  To make it work, it was necessary to add the module parameter nvidia.NVreg_UsePageAttributeTable=0.  Dmesg then showed:

[    5.243598] NVRM: builtin PAT support disabled, falling back to MTRRs.

And /proc/mtrr then showed the write-combining entry added by Nvidia:

reg00: base=0x000000000 (    0MB), size= 1024MB, count=1: write-back
reg01: base=0x060000000 ( 1536MB), size=  256MB, count=1: write-combining

Theoretically, version 304 should migrate to the new API before it reaches end of maintenance.

Extinction events


2012-11:  Nvidia dead-ended their 71.86 and 96.43 legacy drivers.

2014-03:  Nvidia dead-ended their 173.14 legacy drivers.

Here is the text of Support timeframes for Unix legacy GPU releases as of 2014-03-28:

The Linux 340.* legacy driver series is the last to support the G8x, G9x, and GT2xx GPUs, and motherboard chipsets based on them.  Support for new Linux kernels and X servers, as well as fixes for critical bugs, will be included in 340.* legacy releases through the end of 2019.

The Linux 304.* legacy driver series is the last to support the NV4x and G7x GPUs and motherboard chipsets based on them.  Support for new Linux kernels and X servers, as well as fixes for critical bugs, will be included in 304.* legacy releases through the end of 2017.

Support for X.Org xserver version 1.15 was added to the 173.14.* legacy driver series with version 173.14.39.  No further releases from the 173.14.* series are planned.

Support for X.Org xserver version 1.12 was added to the 96.43.* legacy driver series with version 96.43.23.  No further releases from the 96.43.* series are planned.

No further releases from the 71.86.* legacy driver series are planned.

For more information about the GPUs supported by each Legacy GPU driver series, please see:  http://www.nvidia.com/object/IO_32667.html


ATI's Linux drivers never did support Wonder, Mach or Rage series cards.

2006-08:  According to Unofficial Wiki for the AMD Linux Driver, ATI/AMD dropped support for Radeons in the R100 to RS350 range in the 8.28.8 fglrx driver.

2009-04:  Paraphrasing the Unofficial Wiki for the AMD Linux Driver:  ATI/AMD dropped Catalyst support for [a buttload of Radeon and FireGL models] in Catalyst 9-4.  These cards are supported with the legacy ATI 9-3 Catalyst release, but that was dead-ended and requires kernel ≤ 2.6.28 and X server ≤ 1.5 to work.


2000-03:  XFree86 version 4.0 release notes:

Introduction:  "This release isn't quite as complete as we would have liked.  The main missing pieces are a nice configuration tool and support for some of the hardware that 3.3.x supports.  The first point means that configuring the server might be more painful than usual.  The second means that your hardware might not be supported by 4.0, or it might be supported at a lesser level (conversely, some hardware is better supported in 4.0)."

ATI driver status:  "All chips supported in 3.3.6 are supported in 4.0 except for Mach8 and some old Mach32 chips.  The support in 4.0 is, however, unaccelerated for all chips except the Rage 128."

For me, with a Mach64 card, XFree86 version 4.0 was just one big regression.

AFAIK, there was no 3D support prior to 4.0, only 2D acceleration for supported cards.

2012-06:  X11R7.7 release notes:

This release no longer contains the following drivers, due to lack of maintainers with relevant hardware.  Existing driver versions may work with current Xorg servers, but they are not being actively updated to support Xorg driver API & ABI changes.

2012-09:  X server version 1.13 dropped XAA, thereby breaking 2D acceleration in any of the legacy drivers that had not yet been otherwise sabotaged.  Maintained drivers have migrated to EXA, but EXA has been a huge performance regression (comparable to vesa) in every case that I've tested, leaving proprietary drivers and reverting to old X.Org versions as the only acceptable options.

Mesa (is not OpenGL) library

2009-12:  The DRI drivers s3v (S3 ViRGE) and trident were dropped from Mesa 7.7 without a mention in the release notes.

2012-02:  Mesa 8.0 release notes:

"Removed all DRI drivers that did not support DRI2.  Specifically, i810, mach64, mga, r128, savage, sis, tdfx, and unichrome were removed."

"Removed the classic Mesa r300 and r600 drivers, which are superseded by the gallium drivers for this hardware."

Gallium only works with DRI2.

Utah GLX

Utah GLX was a 3D infrastructure developed for XFree86 3 that was eventually dead-ended by the adoption of DRI in XFree86 4.  It included some level of 3D support for the following graphics chipsets:

A branch was created for XFree86 4, but the last status update in 2003 indicated that only the Nvidia and Matrox drivers were running Quake.

As of 2014-08, I have not tested Utah at all.  The README files for the various chipsets are full of scary things.  However, the ATI README offers some advice that may be useful whenever X complains of insufficient GPU memory:  "You must disable font and pixmap caching for the X server, otherwise there won't be any memory for 3D windows."

Disabling pixmap caching:  for XAA, put Option "XaaNoPixmapCache" in section Screen.  For EXA, ?

Disabling font caching:  ?

Slackware cross-index for last working versions

Multiple version numbers separated by a slash indicate original release versus subsequent patches or alternatives that were made available during the original install.

Slackware versionRelease dateXFree86/X.Org versionX server versionMesa versionKernel version(s)

2009-08:  The X.Org fbdev driver quietly disappeared from Slackware version 13.0.  This seems to have been a Slackware move and I've been unable to locate the explanation.
2012-09:  fbdev returned, but it's in the 'extra' directory.

Reversion kits

Reversion Kit 1:  for oldest Nvidia cards with 71.86.15 drivers

Last validation:  2014-03-23 with xz-5.0.5, gmp-5.1.3, mpfr-3.1.2, mpc-1.0.2, gcc-4.8.2, and nasm-2.11.02.

Patches and issues that are specific to Slackware 12.2 or Nvidia 71.86.15:

Dependency chains:

Reversion Kit 2:  for Nvidia 96.43.23, S3 ViRGE, S3 Trio3D, SiS 315, and Trident

Reversion Kit 2 reverts the X server to version 1.12.4, which undeletes XAA and restores server compatibility with Nvidia 96.43.23.  XAA enables the s3virge and sis X.Org drivers to have working 2D acceleration and XVideo but not DRI.  For trident it is just a 2D speedup; XVideo is broken regardless.

2017-01:  Nvidia + MTRR works with kernel 4.9.

Reversion Kit 3:  for Nvidia 173.14.39

Reversion Kit 3 restores ABI and kernel compatibility with the Nvidia legacy driver version 173.14.39.

2016-10:  Nvidia + MTRR works with kernel 4.8.

Reversion Kit 4:  for Nvidia 304.xxx

Nvidia 304.132 still works with Slackware 14.2.  The arch patches are here, but as of version 304.132, the linux-4.6.patch will not apply and is apparently not needed.

Either the Nvidia driver must be patched to disable MTRR or the kernel must be patched to export the two hidden functions.  As described above, even on a system with no PAT support, this driver will not fall back to MTRRs unless PAT is further disabled with module parameter nvidia.NVreg_UsePageAttributeTable=0.

The X server in Slackware 14.2 needs to be started with +iglx to enable GL.

Experiences with drivers generically


Even Nvidia's currently maintained drivers constantly need random patches to make them compatible with the latest kernels.

The Nvidia installer or deinstaller may delete the libEGL.so or libvdpau.so that came from Slackware, breaking apps that depend on those libs.

Recent testing of Nvidia 96 and 173 in the midst of the MTRR fiasco was confounded by failures that were accompanied by syslog messages like this (Xids):

Aug 21 19:34:22 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0100 ffffffff 0000c1ac 01010200 00c3c3c3
Aug 21 19:41:02 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 00000000 000012cc 01f80004 00160005
Aug 21 19:41:03 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 00070395 0000fdd8 03990000 00c3c3c3
Aug 21 19:41:04 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0100 00000000 000035c4 00000000 00c3c3c3
Aug 21 19:41:04 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 00000000 00003c28 01f80004 00160005
Aug 21 19:41:08 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 00000000 00002fe0 01f80004 00160005
Aug 21 19:41:10 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 0007056f 0000fdf8 05730000 00c3c3c3

Nvidia 173 seemed to stabilize after reverting to kernel 4.4.  96 OTOH gave me Xids when trying to use XVideo with both 4.4 and 4.7 kernels.


Relative to the proprietary drivers, Nouveau is a regression, but I can't say if Nouveau itself has had regressions because I never got it to do much successfully.

2012-10:  Slackware 14.0 and kernel 3.6.2 with a GeForce 6800 Ultra Extreme:  DOOM 3 fell on its face.  Back to proprietary drivers.

2013-01:  Slackware 14.0 with an AGP 2× Riva TNT 16 MiB:  got segfaults trying to play video.  Back to Windows XP.

2014-01:  Slackware 14.1 and kernel 3.12.8 with an Asus GeForce2 MX400 32 MiB recently orphaned by the EOL of Nvidia's 96.43.23 fork:  the Nouveau drivers appeared to start up normally with support for DRI2, EXA 2D acceleration, and XVideo, but EDuke32 and PrBoom-Plus both caused Nouveau to spew errors and die as soon as they started.  Low-def videos played, but the video quality was unacceptable.  Xterm visual bell (a simple 2D filling operation) managed not to crash the server but was excruciatingly, inexplicably slow.  BSOD on exit.  Aaaaaaaaaaaaaaaagggghh!

2014-03:  Slackware 14.1 and kernel 3.13.5 with an AGP 2× Nvidia Riva TNT 16 MiB:  Given previous results with the Radeon driver I tried different combinations of kernel modules, but this time there really was no way to get 2D acceleration to work.  XAA is gone now, leaving only EXA which is super slow.

  1. With CONFIG_DRM=y, CONFIG_DRM_NOUVEAU=y, CONFIG_FB=y, CONFIG_FB_NVIDIA=n:  On the good side, it can bring up a 1600×1200 24 bpp mode and it claims to enable DRI2, EXA 2D acceleration, and XVideo.  But it spews PROTECTION_FAULT errors into the log on startup and attempting to do practically anything more challenging than scrolling text in an Xterm causes the X server to crash immediately with a segmentation fault.  Scrolling text is just as slow as with vesa if not worse and icons don't display correctly in some apps.
  2. Adding CONFIG_FB_NVIDIA=y makes it impossible to start nouveau (soft lockup).  The fbdev driver might work with this.
  3. With CONFIG_DRM_NOUVEAU and CONFIG_FB taken out, nouveau detects no device and exits.

2016-09:  I flipped the bozo bit on Nouveau in 2014 and since then have rarely bothered to test it, much less take careful notes of the outcome.  Once in a while I will try it in the vain hope of avoiding the need for a reversion kit, but not once has it worked tolerably well with any Nvidia card, in any PC, with any version of kernel and X server.


2014-01:  2D acceleration broke somehow in the upgrade from Slackware 14.0 to 14.1 (x86_64).  The performance of X11 (scrolling xterms) is now just as slow as with vesa.


Although Intel is to be commended for their commitment to open-source drivers, they always give me trouble.

There currently are four different options for 2D rendering:  SNA, UXA, Glamor, and "none" (option "NoAccel").


2014-02:  In Slackware 14.1, the X.Org trident driver crashes on launch and is completely unusable.  It was working in 14.0.

[   451.398] (II) LoadModule: "trident"
[   451.398] (II) Loading /usr/lib/xorg/modules/drivers/trident_drv.so
[   451.399] (EE) Failed to load /usr/lib/xorg/modules/drivers/trident_drv.so: /usr/lib/xorg/modules/drivers/trident_drv.so: undefined symbol: TRIDENT_Sync
[   451.399] (II) UnloadModule: "trident"
[   451.399] (II) Unloading trident
[   451.399] (EE) Failed to load module "trident" (loader failed, 7)

2016-07:  In Slackware 14.2, the trident driver is usable again.  It defaults to XAA which doesn't exist.  Option "AccelMethod" "exa" starts successfully, but is much slower for scrolling text than no acceleration at all and causes the server to hang on exit.  XVideo is always corrupted.  Use Reversion Kit 2 to get XAA speedup.


2014-06, Slackware 14.1:  The X.Org s3virge driver was screwed by the deletion of XAA in X server version 1.13.

[    57.649] (II) Loading sub module "xaa"
[    57.649] (II) LoadModule: "xaa"
[    57.662] (WW) Warning, couldn't open module xaa
[    57.662] (II) UnloadModule: "xaa"
[    57.662] (II) Unloading xaa
[    57.662] (EE) S3VIRGE: Failed to load module "xaa" (module does not exist, 0)
[    57.663] (II) S3VIRGE(0): Falling back to shadowfb

The s3virge driver has no EXA support at all.  As far as I can tell, the only 3D support for these S3 cards that ever existed in Linux was in Utah GLX.  Mesa had a DRI driver called s3v_dri.so until it disappeared from version 7.7, but I have not located a matching DRM module in any version of the kernel.  ???

Without the remedy of Reversion Kit 2, 2D scrolling is slow (although shadowfb is a lot better than nothing), XVideo is disabled, and the X server hangs on exit.

With or without Reversion Kit 2, 1600×1200 mode doesn't work at any bit depth on 4 MiB cards even though Windows 98 SE can manage it at 16 bpp.  This has nothing to do with memory management; the error is "horizontal timing out of range."  Looks like an old fault in the S3virge driver that will never be fixed.


The X.Org sis driver in Slackware 14.1 tries to use EXA but the server crashes immediately.  sis has DRI support for the 300-series chipsets but not 315.  Use Reversion Kit 2.


Visiontek Nvidia Riva TNT (AGP 2×, 16 MiB)

2014-03:  Nouveau was hopeless.  With Reversion Kit 1 (Nvidia proprietary drivers 71.86.15), everything worked as well as could be expected given the vintage of the card and the system under test (700 MHz Pentium 3 CPU):

  • 1600×1200 24 bpp, no problem.
  • 2D acceleration worked perfectly.
  • XVideo played low-def video without fail albeit with chunky scaling.
  • Though not as smooth as it is on a newer system, PrBoom-Plus was pleasantly playable with OpenGL up to 1024×768.  Higher resolutions triggered an extreme, abnormal slowdown.
  • No Digital Vibrance control in the Nvidia driver :-(

This card gets along very well with a 440BX motherboard and DOS applications.  Its analog output is as clear as it gets and switching VGA modes doesn't require recalibrating the monitor every time.

Asus GeForce2 MX400 (AGP 4×, 32 MiB)

2015-10:  With Reversion Kit 2, kernel 4.2.3 and Nvidia 96.43.23 drivers, it worked.

Quadro2 MXR (AGP 4×, 32 MiB)


2015-10:  With Reversion Kit 2 and kernel 4.2.3, Nvidia 96.43.23 didn't work right.  The screen was all green.  Messing with lots of options only managed to change it from green to red.  Colors were normal in nv and nouveau.

173.14.39 bailed out immediately stating that 96.43.23 is the correct driver.

Dell OEM NV18 GeForce4 MX440 (AGP 8×, 64 MiB)

This anachronistic card rehashes a GeForce 2-derived chipset with AGP 8×, DVI, and S-video while dropping analog VGA.

2016-09, Slackware 14.2, kernel 4.7.4, Reversion Kit 2, Nvidia 96.43.23 with arch patches (MTRR disabled), tested on 440BX PC:

2017-01, kernel 4.9.2, Reversion Kit 2 with MTRR enabled, on KT133A PC:  same thing, same Xids, just slightly better performance.

XFX NV44A GeForce 6200 (AGP 8×, 256 MiB)


2016-08, Slackware 14.2, testing on the QDI P2DI-AL/C motherboard:  So, running Nvidia drivers with GeForce 6-series used to be so easy that it wasn't worth writing them up, but recently I had a bunch of problems with both 304.131 and 173.14.39.  This needs retesting to sort it all out.  They might just hate this motherboard, or maybe the kernel went through a bad time.  The working configuration that I landed on was RK3 with longterm kernel 4.4.19.

As for other drivers:  Nouveau caused a hard lockup that prevented the kernel from booting (same 'ol Nouveau).  fbdev refused to do 1600×1200.  nv and vesa were willing to try if Option "FlatPanel" "false" was set, but it still didn't work (X server chose the correct mode and refresh rate but monitor still reported signal out of range).  nv didn't even work in 1024×768.

EVGA NV44A GeForce 6200 (AGP 8×, 512 MiB)


2016-09, Slackware 14.2, kernel 4.7.6 with MTRR export patch, Nvidia drivers 304.132 with NO patches, testing on a 440BX P3 system:


ATI Radeon 9600SE (RV350) (AGP 8×, 128 MiB)


Gallium:  I am disappoint

As of 2013-08-29, kernel 3.10.10, Slackware 14.0:  It's impossible to get 2D and 3D acceleration working at the same time.  All permutations of drivers have a problem with the screen going black (no signal) until the next reboot about 50% of the time when modesetting occurs.

  1. CONFIG_DRM=y, CONFIG_DRM_RADEON=n:  There is no DRI or GL, but XAA 2D acceleration works great.
  2. CONFIG_DRM_RADEON=y, CONFIG_DRM_RADEON_UMS=n, CONFIG_FB_RADEON=n:  Now there's DRI2 and GL but 2D acceleration is broken.  XAA and EXA claim to be enabled, but 2D is sloooow and Option "MigrationHeuristic" "greedy" does nothing.
  3. CONFIG_FB_RADEON=y makes 2D fast again but it disables DRI and DRI2.
  4. CONFIG_DRM_RADEON_UMS=y causes the screen to go black every time.

With option 2 (DRI2), background or sky textures are missing in EDuke32 and there is flakiness in PrBoom-Plus.  Reverting Mesa to 7.11.2 with DRI drivers only or setting Option "DRI2" "false" in xorg.conf makes no difference.

2014-09-02, kernel 3.16.1, Slackware 14.1:  The modesetting BSOD problem is still there and I can't stand it for long enough to test anything else.

Catalyst 9-3:  Stuck in 2009

2013-09-28:  Per the Wiki, Catalyst 9-3 needs kernel ≤ 2.6.28 and X server ≤ 1.5.

Just downgrading the kernel and X server is a nonstarter.  Kernel is not usable under Slackware 14.0.  Too many things quit with "kernel too old" errors.  So it's back to Slackware 12.2.

Building kernel under Slackware 14.0 with GCC 4.8.1 requires at least four files to be patched.  It's better to bootstrap Slackware 12.2 with a generic kernel and then build the old kernel with the old tools.

The following kernel configs were necessary for Catalyst to install and work correctly:  CONFIG_X86_LOCAL_APIC=y, CONFIG_X86_IO_APIC=y, CONFIG_PCI_MSI=y, CONFIG_AGP=y, CONFIG_DRM=n.  (The first two are prerequisites for CONFIG_PCI_MSI to become available.)

ati-driver-installer-9-3-x86.x86_64.run can be run from a text console just like the Nvidia drivers.  ATI's installation process isn't much different from Nvidia's except that the ATI installer will modify /etc/X11/xorg.conf without even asking.  Back it up!

There was a stubborn problem with startx crashing on launch regardless what was in xorg.conf.  The point of commonality in all of the stack dumps was libvbe.so(VBEExtendedInit+0x8f).  Deleting /usr/lib/xorg/modules/libvbe.so worked around the problem with no obvious collateral damage.

With the Catalyst driver successfully installed, every problem experienced with the Gallium driver went away.  However, now the screen is left in a trashed state when X exits.

PrBoom-Plus played flawlessly on the first try.  EDuke32 was pretty discouragingly messed up at first, but it was a matter of bad defaults:

XVideo (xv) worked fine once the conflicting OpenGL overlay was turned off (a well-known quirk of fglrx), but this was confounded by an unrelated problem:  the old GCC included with Slackware 12.2 produced broken code for ffmpeg 2.0.1 with the effect that every video seemed corrupted.  That problem went away after rebuilding ffmpeg with GCC 4.8.1.  The new compiler produced a new build error in libavdevice/xv.c, which was fixed by reversing the order of the XShm.h and Xvlib.h includes.

In summary, it is a massive pain to revert to Slackware 12.2, but the Gallium driver is still outclassed by the legacy proprietary driver.

ATI 3D Rage Pro Turbo integrated graphics (AGP 2×, 4 MiB)

Supposed to have OpenGL 1.1.

2013-09:  Slackware 14.0, X.Org module mach64, kernel 3.11:  As it was, 1600×1200 @ 16 bpp worked with XAA 2D acceleration, but 3D did not work at any resolution because neither the DRM kernel module nor the Mesa DRI driver was present.

The missing DRM kernel module is out-of-tree (mach64drm).  ArchLinux says it was never stable.  Version mach64-20130130 builds OK with kernel 3.11.

Installing the binary package mach64-dri-7.11.2-5-i686 from ArchLinux without reverting Mesa does not work.  DRI gets enabled but Gallium won't use it.  Reverting Mesa to the Slackware 13.37 package, leaving everything else from Slackware 14.0, does work.  However, because of memory constraints, the usable resolution with 3D enabled is limited to 800×600 @ 16 bpp.  (1282 kB of video RAM is allocated for XAA alone.)

The drivers are stable enough for eduke32 to run, but it locks up immediately if the framerate counter is enabled.  PrBoom-Plus crashes immediately with various different errors as soon as OpenGL is enabled.  Building MesaLib-7.11.2 from source and recompiling all applications did not change anything.

ATI Rage IIC (AGP 2×, 8 MiB)

2014-01:  Slackware 14.1, X.Org module mach64, kernel 3.12.6:  1600×1200 @ 24 bpp was corrupted.  Both 1600×1200 @ 16 bpp and 800×600 @ 24 bpp worked with EXA 2D acceleration, but as expected, there was no DRI/DRI2 support.  Playing video gave a black screen.

[    74.082] (WW) MACH64(0): Direct rendering is not supported for ATI chips earlier than the ATI 3D Rage Pro.

Although the Rage IIC has some kind of hardware 3D, it's not supported by the Mach64 module of X.Org.  This is not a regression; it never worked.  Too bad xv doesn't work either.

ATI Mach64 Graphics Pro Turbo (PCI, 4 MiB)

Way back when, I bought this rather pricey Mach64 card specifically because it had a working Linux driver.  XFree86 3.x gave me 32 bpp accelerated.  Then came XFree86 version 4.

At last check, 2008-06-08:  With the X.Org version included in Slackware 12, the only thing that worked correctly for the Mach64 card was the unaccelerated and intolerably slow generic VESA driver.  This needs a revisit since it ought to work as well as the Rage.


Trident TVGA/ProVidia 9685 (PCI, 4 MiB)

2012-09:  X.Org trident driver in pre-14.0 Slackware-current was broken for 24 bpp (unable to display an uncorrupted desktop).  In addition, the desktop corrupts on powersave.  16 bpp needs further testing.

2014-05:  In Slackware 14.1 the X.Org trident driver is unusable.  With the X.Org vesa driver, 800×600 at 24 bpp works as long as xorg.conf includes DefaultFbBpp 24 to override the default of 32.  1024×768 fails with the monitor reporting an out of range signal regardless what vertical refresh is specified in xorg.conf; the log reports "VBESetVBEMode failed, mode set without customized refresh" for every mode.  The video BIOS lists resolutions up to 1280×1024 16 bpp, but the modules tridentfb and vesafb in kernel 3.14.4 are inexplicably unable to use any mode except 640×480 8 bpp.

Jaton 8297C/V2 Trident 3DImÓge9850 (AGP, 4 MiB)

2012-09:  XVideo was broken in the X.Org trident driver in pre-14.0 Slackware-current.

2016-07:  Slackware 14.2:  XVideo is still broken the same way.  1152×864 24 bpp is usable without acceleration.  By default it tries to use XAA.  EXA can be enabled but it is much slower for scrolling text than no acceleration at all and causes the server to hang on exit.  Install Reversion Kit 2 and get 1152×864 24 bpp with XAA acceleration.

Trident TVGA 9400CXi (VLB, 1 MiB)

The man page for trident (versioned xf86-video-trident 1.3.6) says:


The trident driver supports PCI, AGP and ISA video cards based on the following Trident chips:
ISA/VLBus  8900C, 8900D, 9000, 9200CXr, Cyber9320, 9400CXi, 9440AGi
These cards have been ported but need further testing and may not work.

Guess what?  It doesn't work.

2008-10, Slackware 12.1, kernel 2.6.27:  The trident driver didn't detect the card.  The generic vesa driver worked and fired up a 1024×768×8bpp interlaced mode.  VGA bandwidth as judged by scrolling text in xterms was surprisingly good for an unaccelerated driver.

2014-02, Slackware 14.1, kernel 3.13.2:  Complete and utter failure.  The trident driver did a faceplant:

[   554.592] (II) LoadModule: "trident"
[   554.791] (II) Loading /usr/lib/xorg/modules/drivers/trident_drv.so
[   554.923] (EE) Failed to load /usr/lib/xorg/modules/drivers/trident_drv.so: /usr/lib/xorg/modules/drivers/trident_drv.so: undefined symbol: TRIDENT_Sync
[   554.926] (II) UnloadModule: "trident"
[   554.930] (II) Unloading trident
[   554.933] (EE) Failed to load module "trident" (loader failed, 7)

And even the vesa driver failed to detect the card:

[  1209.209] (II) VESA: driver for VESA chipsets: vesa
[  1209.216] (--) using VT number 7

[  1209.331] (WW) Falling back to old probe method for vesa
[  1209.336] (EE) No devices detected.
[  1209.348] (EE) 
Fatal server error:
[  1209.355] (EE) no screens found(EE) 

TO DO:  Diff old and new vesa driver, find out how they broke it and patch it.  It's a really simple driver.


AOpen PG128Plus S3 Trio3D (86C368) (AGP 2×, 4 MiB)

2014-02:  Slackware 14.1, kernel 3.13.4:  This card uses the s3virge X.Org driver, which was screwed by the deletion of XAA in X server version 1.13.  After installing Reversion Kit 2 it's possible to use 1024×768 24 bpp mode with 2D acceleration.  1600×1200 mode doesn't work at any bit depth.  XVideo claims to be enabled (xvinfo: Adaptor #0: "S3 ViRGE Backend Scaler") but the video is corrupted and too slow regardless.  (As usual, it could be that the PC is just too slow.)

There was a DRI driver s3v_dri.so which disappeared in Mesa 7.7 (between Slackware versions 13.0 and 13.1), but reverting to mesa-7.5-i486-2.txz from Slackware 13.0 sans any matching kernel module did nothing.

S3 ViRGE/GX2 (86C357) (AGP 1×, 4 MiB)

2014-06:  Slackware 14.1, kernel 3.15:  The behavior of this card was the same as that of the Trio3D card above except that Option "NoDDC" was needed in the Device section of xorg.conf to stop it from hanging for 1 minute each time X was started.

Retesting XVideo with an mp4 scaled down small enough not to tax the CPU, it was demonstrated that XVideo does in fact work, but the scaler is of very poor quality.  Scaled-up videos are as jaggy as possible; there's no hint of interpolation or smoothing.

S3 Trio3D integrated graphics (86C366) (AGP 1×?, 4 MiB)

2014-07:  Slackware 14.1 + Reversion Kit 2, kernel 3.15.6:  OK, this actually is worse.  XVideo definitely does not work:

[    44.718] (==) S3VIRGE(0): XVideo not supported.
[    45.805] (II) AIGLX: Screen 0 is not DRI2 capable
[    45.805] (II) AIGLX: Screen 0 is not DRI capable

DDC works without a hang.

UniChrome Pro integrated graphics

Epia EN12000EG with VIA UniChrome Pro integrated AGP 8× graphics

Wikipedia says "UniChrome is an updated S3 ProSavage used in VIA's integrated graphics chipsets," so like Wikipedia I am filing this under S3.

2015-02:  Slackware 14.1, kernel 3.18.6:  Using the openchrome driver for X.Org, 1600×1200 24 bpp mode fires up with EXA 2D acceleration.  There are some errors in the log but otherwise it seems to be good.

XVideo is enabled, as is the XvMC extension that provides MPEG-2 acceleration, but as soon as I try to use it, ffplay spews the following and dies:

X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  148 (XVideo)
  Minor opcode of failed request:  19 ()
  Serial number of failed request:  26
  Current serial number in output stream:  27

As for 3D, the kernel's DRM_VIA module is still there and the X server enables DRI, but the Mesa crew dropped the unichrome driver in 8.0.  Reverting to mesa-7.9.2-i486-1.txz from Slackware 13.37, the Mesa module loads, but then this happens:

[  4438.737] (EE) AIGLX error: Calling driver entry point failed
[  4438.738] (EE) AIGLX: reverting to software rendering

This seems to be one of those unhelpful, nonspecific errors.  After also reverting to xorg-server-1.9.5-i486-3_slack13.37.txz, xf86-input-evdev-2.6.0-i486-1.txz and xf86-video-openchrome-0.2.904-i486-2.txz from Slackware 13.37, XAA 2D is faster than EXA was and 3D now seems to be enabled, but nothing OpenGL actually works.  Either the log fills with nasty errors and the application fails in some horrible way or the application just hangs with a black screen.  The BadAccess failure was unaffected by the reversions.


3dfx Voodoo3 2000 (PCI, 16 MiB)

2013-10:  Slackware 14.0, kernel 3.11.4:  The kernel module DRM_TDFX is still there, in tree and working, but to get the corresponding DRI module, Mesa must be rolled back to version 7.

With Mesa reverted and driver "tdfx" specified in xorg.conf, 2D acceleration works fine for 1600×1200 at either 16 or 24 bpp, but the DRI driver works only at 16 bpp.  It's a moot point, though, because every single GL program either quits with "insufficient resources for operation" or dies with a segfault.  It makes no difference whether I use the Slackware 13.37 package or my own build of Mesa 7.11.2.

Xvideo is enabled (xvinfo says "3dfx Video Overlay"), but the pre-AGP system used for testing is apparently too slow to play video regardless.


Scheda / Mad Dog S315L (SiS 315) (AGP 4×, 64 MiB)

2014-08, Slackware 14.1:  Without Reversion Kit 2, the X.Org sis driver tries to use EXA but the server immediately segfaults and dies.  Adding Option "NoAccel" "1" avoids the crash but then performance sucks.

With the reversion kit, XAA 2D acceleration and XVideo ("SIS 300/315/330 series Video Overlay") both work and perform well.  The removal of the DRI driver from Mesa 8 is moot because sis never supported DRI on this chipset.

With or without the reversion kit, X always leaves the graphics in a trashed state when it exits.

Intel integrated graphics

Clarkdale HD graphics (i5-661)


2012-08, Slackware 13.37:  Segfault in /usr/lib64/libdrm_intel.so.1 every time on launch of PrBoom-Plus.

2012-10:  Slackware 14.0, kernel 3.6.2, CONFIG_DRM_I915=y, CONFIG_DRM_I915_KMS=y:  DOOM 3 runs for a little while but then locks up the GPU.

2013-12:  Slackware 14.0, kernel 3.12.5:  PrBoom-Plus is OK now.  DOOM 3 TBD, audio is cutting out.

2014-01:  Slackware 14.1, kernel 3.12.5:  To avoid getting a black screen in EDuke32, settings.cfg needs r_texcompr "0".

2015-01:  I was forced to disable the HD Graphics on this PC and install an Nvidia card because of code rot affecting Intel's Windows 7 drivers.  A few months ago they started crashing to a black screen and restarting in an infinite loop, presumably as a result of incompatibility with some routine Windows update, and nothing since then has mitigated the problem.  AFAICT Intel has stopped maintenance for this configuration and it will never be fixed.

GMA 950 graphics (EeePC 1000)

2014-01:  Slackware 14.1, kernel 3.12.6, EDuke32 rev. 4262:  EDuke32 works only with the software renderer.  If OpenGL is enabled, settings.cfg needs r_texcompr "0" to avoid getting a black screen and then it crashes during texture loading.

2014-04:  Slackware 14.1, kernel 3.14, EDuke32 rev. 4418:  EDuke32 OpenGL works again with r_texcompr "0".  r_texcompr "1" still causes a black screen.

I am still getting the following log spew every time I run DOSBox:

Apr  6 17:28:42 EeePC kernel: [drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 32768, found 0)
Apr  6 17:28:42 EeePC kernel: ------------[ cut here ]------------
Apr  6 17:28:42 EeePC kernel: WARNING: CPU: 1 PID: 21281 at drivers/gpu/drm/i915/intel_display.c:9530 check_crtc_state+0x6b8/0xdd0()
Apr  6 17:28:42 EeePC kernel: pipe state doesn't match!
Apr  6 17:28:42 EeePC kernel: Modules linked in: snd_seq snd_seq_device snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore
Apr  6 17:28:42 EeePC kernel: CPU: 1 PID: 21281 Comm: X Not tainted 3.14.0-EeePC #1
Apr  6 17:28:42 EeePC kernel: Hardware name: ASUSTeK Computer INC. 1000/1000, BIOS 1003    06/11/2009
Apr  6 17:28:42 EeePC kernel:  0000253a c14fdcde f0e63aa8 c1037aca c16168af f0e63ac0 00005321 c15f02f4
Apr  6 17:28:42 EeePC kernel:  0000253a c12be6b8 c12be6b8 f6014000 f6014648 00000003 f62709b4 c1037b14
Apr  6 17:28:42 EeePC kernel:  00000009 f0e63aa8 c16168af f0e63ac0 c12be6b8 c15f02f4 0000253a c16168af
Apr  6 17:28:42 EeePC kernel: Call Trace:
Apr  6 17:28:42 EeePC kernel:  [] ? dump_stack+0x3e/0x4e
Apr  6 17:28:42 EeePC kernel:  [] ? warn_slowpath_common+0x7a/0x90
Apr  6 17:28:42 EeePC kernel:  [] ? check_crtc_state+0x6b8/0xdd0
Apr  6 17:28:42 EeePC kernel:  [] ? check_crtc_state+0x6b8/0xdd0
Apr  6 17:28:42 EeePC kernel:  [] ? warn_slowpath_fmt+0x34/0x40
Apr  6 17:28:42 EeePC kernel:  [] ? check_crtc_state+0x6b8/0xdd0
Apr  6 17:28:42 EeePC kernel:  [] ? intel_modeset_check_state+0x28e/0x790
Apr  6 17:28:42 EeePC kernel:  [] ? intel_set_mode+0x2b/0x40
Apr  6 17:28:42 EeePC kernel:  [] ? intel_crtc_set_config+0x770/0x950
Apr  6 17:28:42 EeePC kernel:  [] ? drm_mode_set_config_internal+0x47/0xc0
Apr  6 17:28:42 EeePC kernel:  [] ? drm_mode_setcrtc+0xe8/0x5a0
Apr  6 17:28:42 EeePC kernel:  [] ? drm_mode_setplane+0x3e0/0x3e0
Apr  6 17:28:42 EeePC kernel:  [] ? drm_ioctl+0x3be/0x440
Apr  6 17:28:42 EeePC kernel:  [] ? drm_mode_setplane+0x3e0/0x3e0
Apr  6 17:28:42 EeePC kernel:  [] ? do_sync_write+0x5c/0x90
Apr  6 17:28:42 EeePC kernel:  [] ? drm_free_buffer+0x30/0x30
Apr  6 17:28:42 EeePC kernel:  [] ? do_vfs_ioctl+0x317/0x510
Apr  6 17:28:42 EeePC kernel:  [] ? recalc_sigpending+0xb/0x20
Apr  6 17:28:42 EeePC kernel:  [] ? __set_task_blocked+0x2a/0x70
Apr  6 17:28:42 EeePC kernel:  [] ? __sb_end_write+0x2a/0x60
Apr  6 17:28:42 EeePC kernel:  [] ? __set_current_blocked+0x24/0x40
Apr  6 17:28:42 EeePC kernel:  [] ? sigprocmask+0x5f/0xa0
Apr  6 17:28:42 EeePC kernel:  [] ? SyS_ioctl+0x3d/0x70
Apr  6 17:28:42 EeePC kernel:  [] ? syscall_call+0x7/0xb
Apr  6 17:28:42 EeePC kernel: ---[ end trace 3798c13c21cf8e7e ]---

845G graphics

2014-10, Slackware 14.1, kernel 3.17.1, X.Org intel driver:  Experience very similar to GMA 950.  The kernel spews errors into the logs constantly.  EDuke32 needs r_texcompr "0" to avoid a black screen of death but then fails with an out of memory condition while loading textures.  PrBoom-Plus runs but the frame rate at 1600×1200 is too low.  XVideo works on 854×480 videos but does not support 1280×720 or 1920×1080.  2D performance with UXA is good.

Bay Trail-D HD graphics (Pentium J2900)

2015-03, x86_64, Slackware 14.1, kernel 3.18.8, X.Org intel driver:  This time it's 2D or XVideo that's giving me trouble since the whole point of the box was streaming video.

I am focusing on Chrome as the video player.  Chrome's ignore-gpu-blacklist flag triggers the following diagnostic, which might indicate that it is doing nothing useful at all:

[1468:1468:0314/200542:ERROR:gpu_video_decode_accelerator.cc(272)] Not implemented reached in void content::GpuVideoDecodeAccelerator::Initialize(const media::VideoCodecProfile, IPC::Message *)HW video decode acceleration not available.

Support for VAAPI appears to be lacking across the board.

Kernel parametersxorg.confChrome flagsResult
None Defaults (UXA) Defaults (GPU blacklist enabled) Tearing and random hard lockups
None Option "AccelMethod" "sna"
Option "TearFree" "true"
ignore-gpu-blacklist Random hard lockups
None Option "AccelMethod" "sna"
Option "TearFree" "true"
Defaults (GPU blacklist enabled) Random hard lockups
i915.semaphores=1 Option "AccelMethod" "sna"
Option "TearFree" "true"
ignore-gpu-blacklist Random hard lockups
i915.semaphores=1 Option "AccelMethod" "sna"
Option "TearFree" "true"
Defaults (GPU blacklist enabled) Random hard lockups
i915.semaphores=0 Option "AccelMethod" "sna"
Option "TearFree" "true"
ignore-gpu-blacklist Random hard lockups
i915.semaphores=0 Option "AccelMethod" "sna"
Option "TearFree" "true"
Defaults (GPU blacklist enabled) Random hard lockups
None Option "AccelMethod" "glamor" Defaults (GPU blacklist enabled) Random hard lockups
Unclear if option had any effect
None Option "NoAccel" "true" Defaults (GPU blacklist enabled) Jaggy scaling and tearing, but no lockups

So everything except the dumbest, dumbed-down, un-accelerated dumb mode is broken.  Sigh.  To be completely fair, this is new hardware versus a Slackware release that is due for an update, so it should be categorized as code rot rather than regression, but I was not expecting video to still be a problem for anything in the HD Graphics series.

The suggestion to try i915.semaphores came from here.  I did not test SNA without TearFree.

3D got only cursory testing, not enough to discover random lockups.  FWIW, EDuke32 still needs r_texcompr "0" but there were no other immediate 3D failures.


Reversion kits needed (based on troubleshooting already done):

To be tested:

To be retested: