Screen goes mad - ascii

Geoff 42 · 2017-12-20 15:07:45

I was using my ascii laptop when the screen suddenly went mad!

I think I had open :- rxvt, palemoon, emacs & claws. I was looking at a man page in the rxvt window and had pressed the space bar a few times to get to the right place and then pressed return and the whole screen went mad. The windows appeared to be moving rapidly, possibly sideways. If I left it, it would eventually stop, but when I moved the mouse it started again. However, I was able to close a couple of windows, which I think may have been emacs and palemoon. After that the screen went back to normal and I was able to carry on.

I found the following information in syslog and dmesg :-

Dec 19 16:37:34 gold kernel: [ 5678.028125] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

My laptop is an Asus Zenbook UX305 running ascii & lxde.

I duck-duck-went and found the following on the Arch forum :-

https://bbs.archlinux.org/viewtopic.php?id=198157

where they suggest changing the acceleration method back to UXA instead of SNA, with a file called 20-intel.conf

Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "AccelMethod"  "uxa"
    #Option      "AccelMethod"  "sna"
EndSection

and putting it in /etc/X11/xorg.conf.d/. I do not have this directory but have found /usr/share/X11/xorg.conf.d
and have therefore put it there. Is this the right location?

Geoff

Last edited by Geoff 42 (2017-12-24 16:41:07)

fsmithred · 2017-12-20 17:57:23

You should put your own configs in /etc/X11/xorg.conf.d so they won't be overwritten on upgrades. Quote from 'man xorg.conf' (I don't know why they list the dir twice. They do that in a few places.)

Finally, configuration files will also be searched for in directories reserved for system use. These are to
separate configuration files from the vendor or 3rd party packages from those of local administration. These
files are found in the following directories:
/usr/share/X11/xorg.conf.d
/usr/share/X11/xorg.conf.d

Geoff 42 · 2017-12-20 19:03:46

Thank you for that. I can confirm that it does find the file in either /usr/share/X11/xorg.conf.d/ or /etc/X11/xorg.conf.d/. The advice about overwrites on upgrades is well made.

The bad news, however, is that the file stops X from coming up, so I had to move it out of the way. I have not yet had a chance to track down the problem yet.

Geoff

rduke · 2017-12-21 13:08:23

I have the same laptop and the same problem appeared after upgrade to ascii. Since it appears to be a bug in the intel video driver, I tried booting an older kernel and the problem has not yet shown up (though I have only been running it a couple of hours).
I simply booted the kernel I was using for jessie, which is still in the grub menu. In my case that is "4.9.0-0.bpo.4-amd64", from jessie backports.

Geoff 42 · 2017-12-21 16:57:11

I have been running ascii since 2015 on my Zenbook, as far as I can tell! and I have only had the screen problem once and that was a couple of days ago.

The advice on the Arch wiki is from 2015, so a bit old. When I put the above file in place, to set the AccelMethod to "uxa" and reboot, at the expected time it switches to tty7, but a couple of system messages flash up, but no X. If I typed <ctl><alt><f1> it switches to tty1 with the login prompt, but after a few seconds a couple of system messages flash up, making it difficult to log in. Typing <ctl><alt><f1> again would get me to the login prompt, but it proved too hard for me to actually log in. The other ttys, from tty1 to tty6 all behaved similarly. I had to break in with the power switch and log in in recovery mode and move the config file out of the way and then it would boot up ok.

Xorg.0.log mentions :-

[    11.770] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) 
...
[    11.799] (II) Loading sub module "glamoregl"
[    11.799] (II) LoadModule: "glamoregl"
[    11.800] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[    11.811] (II) Module glamoregl: vendor="X.Org Foundation"
[    11.811] 	compiled for 1.19.2, module version = 1.0.0
[    11.811] 	ABI class: X.Org ANSI C Emulation, version 0.4
[    11.811] (II) glamor: OpenGL accelerated X.org driver based.
[    11.847] (II) glamor: EGL version 1.4 (DRI2):
[    11.859] (II) modeset(0): glamor initialized

Then as I was editing in emacs, I pressed <enter>, which moved about 10 lines down and the screen started to flicker again, but then recovered. dmesg again reports, at about the right time :-

[ 3238.966087] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

I am not able to reproduce this reliably.

Geoff

fsmithred · 2017-12-21 17:25:15

If I typed <ctl><alt><f1> it switches to tty1 with the login prompt, but after a few seconds a couple of system messages flash up, making it difficult to log in. Typing <ctl><alt><f1> again would get me to the login prompt, but it proved too hard for me to actually log in.

If you haven't typed anything yet, presssing ENTER will give you another login prompt. Then, do not look at the screen while you are typing. Just log in normally. (give it a couple seconds to prompt you for the password.)

Alternatively, you could turn off those messages by editing /etc/sysctl.conf:

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

Geoff 42 · 2017-12-22 15:39:00

The problem with trying to change the acceleration method is really that it is a work-around that doesn't actually work, in that it stops X from starting normally. The fix for that is to not do it ;-)

The real problem is with an instability with the graphics.

On both occasions when I have triggered it, I typed a <return> which led to a chunk of text moving vertically, which triggered the instability. In one case in emacs the chunk of text was moved down and in the other typing <return> to man, caused the chunk of text to move up.

I can imagine that the graphics driver does an optimisation and tells the graphics card to move an area of the display, rather than re-drawing it. The Arch forum article mentioned changing the acceleration method. I was looking at Xorg.0.log, to see what acceleration was being used and saw that it mentions

glamor: OpenGL accelerated X.org driver based

This problem has ony occured in the last few days, so it may have been
introduced in a recent upgrade. The kernel was updated on 17 Dec 2017

Preparing to unpack .../26-linux-image-4.9.0-4-amd64_4.9.65-3_amd64.deb ...
Unpacking linux-image-4.9.0-4-amd64 (4.9.65-3) over (4.9.51-1) ...

Grub is also offering 4.9.0-3-amd64, so I could boot that. It seems to date back to 19th Sept. What is the most helpful thing to do to track down this odd behaviour?

Geoff

Geoff 42 · 2017-12-24 16:40:46

I have had a look at Debian bugs and there seem to be several reports of problems with the graphics.
People seem to find that the problem is the result of upgrading from kernel 4.9.0-3 to 4.9.0-4.

A few of the bug reports are :-
837451
859639
878221
884001
884061
884116
884638

Some of the later reports suggest that the problem may be fixed in kernel 4.13 from backports.

https://bugs.debian.org/cgi-bin/bugrepo … bug=884638

I'm currently on the wrong machine, so will have to go to my ascii machine to investigate.

Geoff

Geoff 42 · 2017-12-24 17:27:09

Running "apt-cache search linux-image" shows the range of kernels available, which includes linux-image-4.13.0-0.bpo.1-amd64.
I was able to select this in Synaptic and it did not want to pull in anything else. It installed with no problem and it leaves a couple of older kernels (4.9.0-3 and 4.9.0-4) which can also be booted up. The new kernel boots up with no problem. It is too early to tell if it fixes the graphics problem, but it is no worse!

Geoff

The officially official Devuan Forum!

#1 2017-12-20 15:07:45

Screen goes mad - ascii

#2 2017-12-20 17:57:23

Re: Screen goes mad - ascii

#3 2017-12-20 19:03:46

Re: Screen goes mad - ascii

#4 2017-12-21 13:08:23

Re: Screen goes mad - ascii

#5 2017-12-21 16:57:11

Re: Screen goes mad - ascii

#6 2017-12-21 17:25:15

Re: Screen goes mad - ascii

#7 2017-12-22 15:39:00

Re: Screen goes mad - ascii

#8 2017-12-24 16:40:46

Re: Screen goes mad - ascii

#9 2017-12-24 17:27:09

Re: Screen goes mad - ascii

Board footer