Black screen, UI lock up, when starting Xserver,

[John Talbut]

I am trying to reinstall Debian Buster/Testing on a Samsung NC110
netbook after installing a new hard disk. I have got as far as
installing the base system and the packages for xfce. Now when I try to
boot I get past the grub screen, put in the password for the encrypted
disk, the boot appears to proceed normally until the desktop manager
login screen should appear then the screen goes black and the keyboard
becomes unresponsive.

I get the same symptoms using a different desktop manager and I get the
same lock up if I use startx.

The system has worked fine for a long time up to last July (i.e. 2018).

The system is not crashing, lightdm goes into this loop:

systemd[1]: Starting Light Display Manager
lightdm[2822]: Could not enumerate user data directory
/var/lib/lightdm/data: Error opening directory '/var/lib/lightdm/data':
No such file or directory
systemd[1]: Started Light Display Manager
systemd[1]: lightdm.service: Main process exited, code=exited,
status=1/FAILURE
systemd[1]: lightdm.service: Failed with result 'exit-code'.
systemd[1]: lightdm.service: Service RestartSec=100ms expired,
scheduling restart
systemd[1]: lightdm.service: Scheduled restart job, restart counter is
at <>.
systemd[1]: Stopped Light Display Manager

The only errors that show in Xorg.0.log are:

[ 420,876](EE) modeset(0): [DRI2] No driver mapping found for PCI
device 0x8086 / 0x0be1
[ 42.877] (EE) modeset(0): Failed to initialize the DRI2 extension

I.e. the graphic controller is a VGA compatible controller: Intel
Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller
(rev 09)

Questions, for a start:
1. What is supposed to provide the mapping for PCI device 0x8086 / 0x0be1?

2. Is this error likely to be causing the UI to lock up?

John
_______________________________________________
***@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listi

[Adam Jackson]

Post by John Talbut
[ 420,876](EE) modeset(0): [DRI2] No driver mapping found for PCI
device 0x8086 / 0x0be1
[ 42.877] (EE) modeset(0): Failed to initialize the DRI2 extension
I.e. the graphic controller is a VGA compatible controller: Intel
Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller
(rev 09)
1. What is supposed to provide the mapping for PCI device 0x8086 / 0x0be1?

There's a table built into the X server. In this case, you have the
misfortune to own a Cedarview chip, which is of the Poulsbo family of
"not really Intel, actually PowerVR" of devices and thus there is no
open source 3D support. That the code considers this an "error"
condition is perhaps unwarranted.

Post by John Talbut
2. Is this error likely to be causing the UI to lock up?

Probably not, no. The fact that lightdm seems to be restarting makes me
suspect there is some other error in the X log that simply doesn't
begin with (EE). The complete log might be useful. It's possible that
what's really happening is the _session_ is failing to initialize, and
the X server is terminating normally because the last client
disconnected.

A quick thing to check is to run 'X -retro' from a vt. If that brings
up the classic root weave and X pointer, then X is working fine and the
session is to blame. You may need to boot to runlevel 3 to test this,
as otherwise lightdm would win the race.

- ajax
_______________________________________________
***@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscriptio

[John Talbut]

Thanks Adam

If I boot to runlevel 3, log into tty1 as root and run 'X -retro' the UI
locks up.

If I boot to runlevel 3, log into tty2 as a user and run 'X -retro' the
tty stays live and I get some messages:

(EE)
Fatal server error:
(EE) parse_vt_setting: Cannot open /dev/tty0 (Permission denied)
(EE)
(EE)
(EE) Server terminated with error (1). Closing log
file.l/share/xorg/Xorg.0.log" for additional information.

The latter log file also has a couple of lines:
(WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
(WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor

There do not seem to be any other errors.

It is a bit difficult to send whole log files as I do not have an email
client on the machine without the desktop. If there is anything in
particular to check or further tests, let me know.

John

Post by Adam Jackson

Post by John Talbut
[ 420,876](EE) modeset(0): [DRI2] No driver mapping found for PCI
device 0x8086 / 0x0be1
[ 42.877] (EE) modeset(0): Failed to initialize the DRI2 extension
I.e. the graphic controller is a VGA compatible controller: Intel
Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller
(rev 09)
1. What is supposed to provide the mapping for PCI device 0x8086 / 0x0be1?

There's a table built into the X server. In this case, you have the
misfortune to own a Cedarview chip, which is of the Poulsbo family of
"not really Intel, actually PowerVR" of devices and thus there is no
open source 3D support. That the code considers this an "error"
condition is perhaps unwarranted.

Post by John Talbut
2. Is this error likely to be causing the UI to lock up?

Probably not, no. The fact that lightdm seems to be restarting makes me
suspect there is some other error in the X log that simply doesn't
begin with (EE). The complete log might be useful. It's possible that
what's really happening is the _session_ is failing to initialize, and
the X server is terminating normally because the last client
disconnected.
A quick thing to check is to run 'X -retro' from a vt. If that brings
up the classic root weave and X pointer, then X is working fine and the
session is to blame. You may need to boot to runlevel 3 to test this,
as otherwise lightdm would win the race.
- ajax

_______________________________________________
***@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listin

[Adam Jackson]

Post by John Talbut
Thanks Adam
If I boot to runlevel 3, log into tty1 as root and run 'X -retro' the UI
locks up.

When this happens, does VT switch still work? Can you hit control-alt-
backspace to terminate the server? If yes (and the answer to both
should be the same) then the server is "alive" but something about
changing the video mode has gone awry, so that where the server is
drawing is not where the hardware is looking.

This would probably be a kernel bug, probably in the gma500 driver,
which is not a great place to be as the driver is essentially
unmaintained afaik. dri-***@lists.freedesktop.org would be the most
likely place to find help, and they would probably want to see dmesg
from a boot with 'drm.debug=0x7' on the kernel command line for the
details of the attempted modeset, but I wouldn't get my hopes up.

Alternatively, you can try booting with 'nomodeset' on the kernel
command line, which should disable the gma500 driver. X will then use
the vesa driver, which is normally not a great place to be either, but
the gma500 driver's only real advantage over vesa is hotplug support as
neither one has any hardware acceleration.

Post by John Talbut
If I boot to runlevel 3, log into tty2 as a user and run 'X -retro' the

This is just the security checks in the server preventing you from
running it as a regular user (on the theory that, if anyone on the
system could start a display server, you could spoof an existing
session).

Post by John Talbut
It is a bit difficult to send whole log files as I do not have an email
client on the machine without the desktop.

If you can ssh in, you can scp files out...

- ajax
_______________________________________________
***@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xo

[John Talbut]

Post by Adam Jackson

Post by John Talbut
Thanks Adam
If I boot to runlevel 3, log into tty1 as root and run 'X -retro' the UI
locks up.

When this happens, does VT switch still work? Can you hit control-alt-
backspace to terminate the server?

No, if I run 'X -retro' from tty1 as root the screen goes black apart
from a steady underscore top left and the keyboard is unresponsive, or
at least nothing changes on the screen when I press any keys.

Post by Adam Jackson
If yes (and the answer to both
should be the same) then the server is "alive" but something about
changing the video mode has gone awry, so that where the server is
drawing is not where the hardware is looking.
This would probably be a kernel bug, probably in the gma500 driver,
which is not a great place to be as the driver is essentially
likely place to find help, and they would probably want to see dmesg
from a boot with 'drm.debug=0x7' on the kernel command line for the
details of the attempted modeset, but I wouldn't get my hopes up.

Would anything have changed recently with this driver? The computer was
working fine until late July.

Post by Adam Jackson
Alternatively, you can try booting with 'nomodeset' on the kernel
command line, which should disable the gma500 driver. X will then use
the vesa driver, which is normally not a great place to be either, but
the gma500 driver's only real advantage over vesa is hotplug support as
neither one has any hardware acceleration.

Post by John Talbut
If I boot to runlevel 3, log into tty2 as a user and run 'X -retro' the

This is just the security checks in the server preventing you from
running it as a regular user (on the theory that, if anyone on the
system could start a display server, you could spoof an existing
session).

Post by John Talbut
It is a bit difficult to send whole log files as I do not have an email
client on the machine without the desktop.

If you can ssh in, you can scp files out...
- ajax

_______________________________________________
***@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %

[John Talbut]

OK Adam, thanks for the suggestion about ssh, which I have now got working.

So, I boot to runlevel 3, log into tty1 as root and run 'X -retro' the
UI locks up. The keyboard is completely unresponsive.

However, I can see using ssh that the system is still running but I
cannot see any sign of X running. There are no message in journalctl
during the attempt to start X. ps -C Xorg shows nothing.

Xorg.0.log attached.

What should I try next?

John

Post by Adam Jackson

Post by John Talbut
Thanks Adam
If I boot to runlevel 3, log into tty1 as root and run 'X -retro' the UI
locks up.

When this happens, does VT switch still work? Can you hit control-alt-
backspace to terminate the server? If yes (and the answer to both
should be the same) then the server is "alive" but something about
changing the video mode has gone awry, so that where the server is
drawing is not where the hardware is looking.
This would probably be a kernel bug, probably in the gma500 driver,
which is not a great place to be as the driver is essentially
likely place to find help, and they would probably want to see dmesg
from a boot with 'drm.debug=0x7' on the kernel command line for the
details of the attempted modeset, but I wouldn't get my hopes up.
Alternatively, you can try booting with 'nomodeset' on the kernel
command line, which should disable the gma500 driver. X will then use
the vesa driver, which is normally not a great place to be either, but
the gma500 driver's only real advantage over vesa is hotplug support as
neither one has any hardware acceleration.

Post by John Talbut
If I boot to runlevel 3, log into tty2 as a user and run 'X -retro' the

This is just the security checks in the server preventing you from
running it as a regular user (on the theory that, if anyone on the
system could start a display server, you could spoof an existing
session).

Post by John Talbut
It is a bit difficult to send whole log files as I do not have an email
client on the machine without the desktop.

If you can ssh in, you can scp files out...
- ajax

[Adam Jackson]

Post by John Talbut
OK Adam, thanks for the suggestion about ssh, which I have now got working.
So, I boot to runlevel 3, log into tty1 as root and run 'X -retro' the
UI locks up. The keyboard is completely unresponsive.
However, I can see using ssh that the system is still running but I
cannot see any sign of X running. There are no message in journalctl
during the attempt to start X. ps -C Xorg shows nothing.

'ps -C X' might.

Post by John Talbut
Xorg.0.log attached.

This bit of the log is pretty wild:

(II) modeset(0): glamor X acceleration enabled on llvmpipe (LLVM 6.0, 128 bits)

I'm really struggling to think of a world in which that would be a good
thing, fb's almost certainly going to be faster, and as the llvmpipe-
on-gbm support is pretty new I can easily imagine it being buggy. What
happens if you run with this in (or as) your /etc/X11/xorg.conf:

---
Section "Device"
Identifier "modesetting"
Driver "modesetting"
Option "AccelMethod" "none"
EndSection
---

- ajax
_______________________________________________
***@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_

[John Talbut]

So what seems to be happening is that as soon as I start X the screen
goes black and the keyboard becomes unresponsive. This seems to be
happening at a low level in the system but is being triggered by starting X.

I installed an /etc/X11/xorg.conf file as suggested. I then sshd in and
recorded the output of ps aux. I then ran 'X -retro' and got the black
screen and unresponsive keyboard. I again recorded the output of ps aux
and scpd a copy of Xorg.0.log (attached).

I compared the two ps outputs with diff, see attachment.

The significant differences seem to be that:
kworker/1:0-events disappears
tty1 S+ 08:11 0:00 -bash goes to S, ie stops being in the
foreground.
and the lines:
root 986 0.0 0.0 0 0 ? I 09:49 0:00
[kworker/3:1-events]
root 989 0.0 0.0 0 0 ? I 09:49 0:00
[kworker/1:0-kec_query]
root 990 3.9 1.9 512356 40452 tty2 Ssl+ 09:49 0:00
/usr/lib/xorg/Xorg -retro

Which does suggest that Xorg is running in tty2.

John

Post by Adam Jackson

Post by John Talbut
OK Adam, thanks for the suggestion about ssh, which I have now got working.
So, I boot to runlevel 3, log into tty1 as root and run 'X -retro' the
UI locks up. The keyboard is completely unresponsive.
However, I can see using ssh that the system is still running but I
cannot see any sign of X running. There are no message in journalctl
during the attempt to start X. ps -C Xorg shows nothing.

'ps -C X' might.

Post by John Talbut
Xorg.0.log attached.

(II) modeset(0): glamor X acceleration enabled on llvmpipe (LLVM 6.0, 128 bits)
I'm really struggling to think of a world in which that would be a good
thing, fb's almost certainly going to be faster, and as the llvmpipe-
on-gbm support is pretty new I can easily imagine it being buggy. What
---
Section "Device"
Identifier "modesetting"
Driver "modesetting"
Option "AccelMethod" "none"
EndSection
---
- ajax