Created attachment 132484 [details]
dmesg of Linux 2017-07-06 drm-tip with drm.debug=0x1e log_buf_len=1M
Rendering of heavy web pages like pages with many gif images (https://www.theverge.com/tech) maps, just heavy web-sites, frequently lead to state that looks like GPU hang - while tablet is accessible via ssh, rendering on display just stop for a few minutes (or sometimes until web browser is terminated) however /sys/class/drm/card0/error return "No error state collected". Killing web browser process could bring system to life faster, however this is possible only remotely which is not an option for tablet (hence critical severity).
Enable GPU rendering in Chrome/Opera/Chromium settings. (Also reproducible with disabled GPU rendering.)
Scroll down to "MOSSBERG: THE DISAPPEARING COMPUTER" animation, wait few seconds.
Disable GPU rendering in Chrome/Opera/Chromium settings. (Also reproducible with enabled GPU rendering, but less frequently, so keep it disabled for this particular page.)
Slowly scroll this page up and down, few seconds later rendering will stuck.
Dell Vanue 8 Pro 5855 with x5-Z8500 CPU.
Ubuntu Gnome 17.04 x86_64
Linux 4.12.0rc7 and Intel drm-tip kernel (cod/tip/drm-tip/2017-07-06, cefc82aab8bb8ec201e922cf23d227c47845094c)
Mesa 17.1.2, libdrm 2.4.80
Issue is reproducible with both of modesetting DDX and intel DDX.
Display is rotated in System Settings.
I reproduced this issue with Opera web-browser (45, 46, 47).
I find that this issue is reproducible only with HD/2GB RAM version of Dell 5855, and does not reproducible with FHD/4GB RAM version of Dell 5855.
I also was able to reproduce this issue with Linux 4.12.2.
Issue is still reproducible on Linux 4.13rc3 with Mesa git (17.3~git170731230100.df61a05~z~padoka0) and Intel DDX git (2.99.917+git1708011513.2100efa~x~padoka0).
If your working-set size does hit swap, then you are in for a terrible time. For the borderline case, https://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=shrinker should hopefully help.
vmstat is a good guide to see if the system is stuck on [swap] io.
But ultimately if the working-set is larger than RAM, the only recourse is to reduce it.
Thank you for looking into this
> If your working-set size does hit swap, then you are in for a terrible time. For the borderline case, https://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=shrinker should hopefully help.
In this round of testing (with "shrinker" kernel and upstream 4.13rc6) I noticed that now animation playback is struggle few times before it completely stuck (earlier it always happened on first playback). Unfortunately I didn't find noticeable difference between "shrinker" kernel and upstream 4.13rc6.
Later, while I tested 4.13rc7, I also find that if I switch to another tab in the beginning of playback, and give system enough time to push data from RAM to swap, then I can switch back, let browser playback animation, and does not get freeze anymore - does it give hint where root cause can be?
Thanks, I am looking for this I appreciated