I have also seen black squares twice in chromium-browser, which traditionally has meant OpenGL/GPU memory corruption. Typically, if you immediately exit the app that displays a black square, you can continue without problems.

3.20 freezes and restarts itself approximately once per hour, whereas 3.18 only crashed if you hit a known bug.

In one day, 3.20 has forced me to restart the computer twice.
16.04/i915

The video tearing is clearly related to the mouse cursor.
It is unclear if that is also the cause of GPU memory corruption.

This bug is reproducible - YES!!

Have an external display to the right
Have a maximized gnome terminal server window on it
  it can be the first thing you do after login
hover the mouse cursor close to the lower left corner about half an inch away
  mouse cursor/video corruption result
  my display is 2560x1600

- computer halts almost immediately
  MacBook Pro 13" 2015

- no log output, no nada, network down, game over. Only way out is power off

mouse cursor was always crazy in this area 3.16 3.18 3.20.1/15.10 16.04
Right now I am on 3.18.4/16.04

This bug outlines the mouse cursor area and apps
https://bugzilla.gnome.org/show_bug.cgi?id=765280

I have 
gsettings get org.gnome.desktop.interface cursor-size
96

Two externals via standard DisplayPort

I would expect this to happen for any modern Intel gpu

Is there some remedy or suggestion around this?

Hangs occur every few hours and it causes log corruption and data loss.

back in 3.18.2/15.10 this did not happen

This all sounds like driver issues to me. Do you have full system logs you can attach here?

It does not output anything to the log. The computer halts but maintains static video display. I looked at it many times.

I believe it has to do with the mouse cursor over multiple displays, and there is a backtrace for that in 
https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1573096

I could just now make it halt on Wayland/Weston
GNOME/X displays the tearing, but I could not make it crash.
GNOME on Wayland has it

This would indicate it is Wayland rather than GNOME or i915

historically:
It does appear in 16.04/libwayland-server0 1.10.0-1/3.18.4-3.20.1
It did not appear in 15.10/libwayland-server0 1.8.1-1/3.18.2

The wayland support is a fast moving target so it's possible this is fixed gnome 3.20. Can you try with that version?

I was on 3.20.1, and the problem was present.

Because 3.20 had so short uptime and many GPU challenges, i downgraded back to 3.18. The problem is with 3.18, too, but it is only serious thing that is broken.

Can you attach a log here after it happens with 3.20 ?

Yes. However, I can reproduce the halt, but not the exit that produces the stack trace.

on it.

Anyone with an i915 gpu and an external display should be able to reproduce this, at least the halt

Make that a MacBook Pro 13" 2015
Only that machine shows the intermittent redraw of content in the wrong location when the mouse shape is changed or on crossing a display boundary.

It did both for 3.18 and 3.20

It only happens when there is an external display connected

It happens very quickly when rapidly mouse over a terminal window causing shape changes

Having a window edge on the border between two displays easily causes an animation mode, where mouse pointer and windows are continuously redrawn with various about 1" offsets, mouse cursors in multiple locations and different shapes and windows by the right edge of a display being drawn at the left edge, probably mistaken for being on the external display. You can leave the computer flickering likeso by itself.

Display flicker caused by the mouse cursor happens when the cursor is about 1/2" into the external display, not at the display border.

So apparently there are some calculations that do not produce static values, instead cyclically move windows and the cursor around which may affect the shape of the mouse cursor. The top bar, for example, seems to be drawn relative to the mouse cursor as opposed to the top of the display.

It seems it hangs less if the external display is to the left as opposed to to the right or above

Older hardware does none of this.

to make it crash less:
- do not have windows edges within 1" of a display border
- do not have an external display above or to the right of the internal display

Because the computer halts, there is no clever output.

So I have been up for 1 hour now

I limit myself to have a single external display to the left, with no windows in the 1" rightmost area of the external display. There is some special redraw when the mouse cursor is there.

I believe this bug lies in the mutter compositor which is responsible for drawing the mouse cursor
- failure to take in account what display the mouse cursor is on
- while mouse cursor changes, intermittently redrawing all displays incorrectly, most often with the content for the top of the display slightly below the mouse cursor's vertical position
- further miscalculations causes a limited number of phantom mouse cursors and windows, that can be configured to a static state of flashing phantom images
- when the mouse cursor exits the internal display, during the redraw instant at that magic 1" from the edge location, windows on the internal display may be redrawn relative to the external display the mouse cursor is on with some X-wise offset

When something fails in all this, the main cpu halts and have to be powered off
- for unhappy configurations, like external displays placed above, or an external display to the right with a window border at its left edge, the cpu may halt within seconds

Secondly there is some free/alloc problem with the mouse cursor, which may or may not be b/c of the external displays
- I believe this to be a separate problem
- This causes GNOME Shell to exit and should be easier to investigate

Older similar Intel hardware does not suffer from any of this

If a second external display to the left of the first one, the cpu halted when the mouse cursor was in that displays 1" area

and I had another computer on ssh doing
dmesg --follow --time-format iso --color --nopager

it show some drm underruns, but they do not happen concurrently with halt.

i5-5287U CPU @ 2.90GHz

Because weston crashed, too, one has to wait for:
wayland later than 1.10.0

GNOME on X has GPU acceleration troubles with Chromium

KDE/X shows much less of the phantom images but more importantly does not crash.

(In reply to jackieb from comment #17)
> Because weston crashed, too, one has to wait for:
> wayland later than 1.10.0
> 
> GNOME on X has GPU acceleration troubles with Chromium
> 
> KDE/X shows much less of the phantom images but more importantly does not
> crash.

This makes very little sense. Please keep things as factual as possible. If you can't attach your system log (including kernel and userland logs) around one of these occurrences there's nothing we can do.

This halt was caused by i915 driver that needed kernel command line parameter i915.enable_rc6=0 to disable its power-down mode

Because it was a halt, no logs could be retrieved