DragonFlyBSD

I use the core of the March version -> I use the kernel from March

Thanks for this bug report.
The issue looks to be hardware-specific though; I cannot reproduce it at will on any of my machines.

The branch drm_ttm_radeon_4_4_180_v1 on leaf contains the individual changes leading to the Linux 4.4.180 update.

Can you bisect the changes on your hardware ?

• git remote add leaf git://leaf.dragonflybsd.org/~ftigeot/dragonfly.git
• git fetch leaf
• git checkout drm_ttm_radeon_4_4_180_v1
• git checkout 211521498c6a0f6fdedfa4c7210a9b3f57aeef0e
• make kernel && reboot

That last git checkout will give you the state of master just before the drm/radeon 4.4.180 changes
If all goes well with that commit, you will then be able to find out which of the following ones broke opengl on your hardware

I managed to dig up an old Radeon HD5450 which appears to exhibit the bug.

There is no fix yet, but a workaround.
Disabling acceleration in xorg.conf will stop the crashes from happening.

Adding the line Option "NoAccel" "TRUE" in a Device section should do the trick:

Section "Device"
Identifier "Card1"
VendorName "Advanced Micro Devices [AMD] nee ATI"
BoardName "RV370 [Radeon X550]"
Driver "radeon"
Option "NoAccel" "TRUE"
BusID "PCI:1:0:0"
EndSection

The first commit on which the glxgears error occurs (vm_fault: pager read error) is 7dcf36dc33228b5b368783d7b6f7ada00ee671d6 on master (Thu Jun 20, drm/radeon: Upgrade to Linux 3.19.8).

Is there a branch with individual changes?

I have pushed drm_ttm_radeon_3_19_8_bisect_vmfault to leaf and bisected what I could myself.
(It can be necessary to comment out drm/i915 from the tree to build successfully)

The first bad commit in that branch is fca8eb81f38c6d4b27e5fa79e030f0647dee0739
"drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM"

I tried to revert it in master but am still getting weird vm faults+crashes after a while.

You're right. I got the same commit (fca8eb81f38c6d4b27e5fa79e030f0647dee0739) as the first one demonstrating a bug in glxgears.

And you are probably right as well in the fact that this commit is not the cause of failures, it just makes the problem very easy and quickly demonstrated.
The kernels that I tried after March 24 crashed with the same error, but after 3–4 hours of intensive work with graphic applications or mpv and it was impossible to make a normal error report with an easily repeated sequence of actions.

The pager read error appears to always be from this chunk of code in ttm/ttm_bo_vm.c around line 550, in function ttm_bo_vm_fault_dfly():

/*
 * Wait for buffer data in transit, due to a pipelined
 * move.
     /
    if (test_bit(TTM_BO_PRIV_FLAG_MOVING, &bo->priv_flags)) {
        /
     * Here, the behavior differs between Linux and FreeBSD.
     *
     * On Linux, the wait is interruptible (3rd argument to
     * ttm_bo_wait). There must be some mechanism to resume
     * page fault handling, once the signal is processed.
     *
     * On FreeBSD, the wait is uninteruptible. This is not a
     * problem as we can't end up with an unkillable process
     * here, because the wait will eventually time out.
     *
     * An example of this situation is the Xorg process
     * which uses SIGALRM internally. The signal could
     * interrupt the wait, causing the page fault to fail
     * and the process to receive SIGSEGV.
         */
        ret = ttm_bo_wait(bo, false, false);
        if (unlikely(ret != 0)) {
            retval = VM_PAGER_ERROR;
            goto out_unlock;
        }
    }

Thanks for your work.
As I understand it, you have video cards of this type that do not show any glitches.
At a local store I can purchase R7 240, R5 230 or RX 550.

Among the three choices, I'd say get the R7 240.
- R5 230: are rebadged models and variants of your existing chips. they will most likely exhibit the same issue.
- RX550: it's a new generation and equires the amdgpu driver.
A port of the driver is almost working but I can't say when the last issues will finally be ironed out.

- R7 240 => that one is known to work fine and is a different radeon generation than the R5.
Get a variant with a 128bit memory bus if speed is important for you.