[mythtv-users] After upgrade to Ubuntu 20.04, frontend crashes X
Stephen Worthington
stephen_agent at jsw.gen.nz
Tue Sep 22 11:03:26 UTC 2020
On Mon, 21 Sep 2020 23:39:01 -0700, you wrote:
>>>Tried to kill the pid associated with mythfrontend.real; tried both -15,
>>>which didn't work, and and -9 (which did kill it). I didn't try using
>-15
>>>twice.
>
>>Right, so it would be useful to know if 2x "kill -15" works - that
>>tells us that mythfrontend is not actually locked up, it is just that
>> the screen display is not working.
>>You might also like to install a copy of my killm program which does
>>the 2x kill -15 automatically and if mythfrontend.real does not stop
>>then, goes on to do a kill -9 one second later:
>
>>sudo su
>>cd /usr/local/bin
>>wget http://www.jsw.gen.nz/mythtv/killm
>>chown root:root killm
>>chmod u=rwx,go=rx killm
>
>>If you do "killm x" (any non-empty parameter), it will also kill the
>>mythfrontend script to stop it from automatically restarting
>>mythfrontend.real.
>
>>My best guess from the evidence so far is that the GUI is being
>>started in a mode the monitor does not actually support. There is
>>long history of TVs and monitors having bad EDID data and advertising
>>modes they do not actually support. So you should be able to get
>>mythfrontend.real to work well enough for you to change its GUI
>>settings by using an override on the command line to put it in a
>>usable mode.
>
>>https://www.mythtv.org/wiki/Override_settings
>
>>I have never done this, and the documentation is decidedly lacking,
>>but I think you should try using a --geometry option, maybe 1920x1080
>>or 1280x720.
>
>>Another thing to try is to use xrandr from ssh. To make xrandr work
>>from ssh you have to log in as the same user that the desktop is being
>>run from. Then you can use commands like this:
>
>>xrandr -d :0
>
>>to access the :0 display. That command should tell you what mode X is
>>running in and what other modes it will allow you to switch to. And
>>you should be able to select a different mode (with the --mode option)
>>to see if it will switch to that and start working.
>
>
>Thanks again, Stephen. I downloaded your killm utility.
>
>Before running mythfrontend:
>
>rcs at yoda: ~]$ xrandr
>Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 16384 x 16384
>VGA-0 disconnected (normal left inverted right x axis y axis)
>DVI-D-0 disconnected (normal left inverted right x axis y axis)
>HDMI-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y
>axis) 1872mm x 1053mm
> 3840x2160 30.00*+ 30.00 29.97 25.00 23.98
> 1920x1080 60.00 59.94 29.97 23.98 60.00
> 1600x900 60.00
> 1280x1024 60.02
> 1280x800 59.81
> 1280x720 60.00 59.94
> 1152x864 60.00
> 1024x768 60.00
> 800x600 60.32
> 720x480 59.94
> 640x480 59.94 59.93
>DVI-D-1 disconnected (normal left inverted right x axis y axis)
That looks OK - it is using 4k at 30 mode which is likely the default for
the monitor.
>Running mythfrontend --geometry 1920x1080+200+200 (after myth update today)
>does not cause the X display to go black, as it did before; now it simply
>freezes up.
I am not sure why you used the +200+200 offsets. You would not
normally what to offset the screen unless you had a specific reason. I
do not think that should cause any problems, but it would be worth
trying again with +0+0. It would also pay to directly run
mythfrontend.real rather than running it via the mythfrontend script.
I am not sure how well the script passes on command line parameters to
the mythfrontend.real program. However, I think that neither of those
will actually help with the original problem.
A black screen is what normally happens when a screen is being sent a
signal that it can not cope with, typically where it has a clock rate
that is too high. A screen being sent a wrong signal that has a low
enough clock rate will normally create a distorted display, but you
will be able to see things change on screen when you do commands, even
if the distortion makes it impossible to make any sense of the output.
A freeze up where the current text on the screen stops being updated
is a different symptom - it suggests that the software running the
display has locked up or crashed somewhere. If the problem is in the
program that is sending data to the display, killing that program will
normally fix the problem. If the problem is in the display drivers,
as is likely the case here, then once the bug in the display drivers
has been triggered, there is very little that can get back a working
display unless you are able to completely shut down and restart X and
the display drivers.
> Ctrl-Alt-F1 to log back in gives me the gdm login screen,
Ctrl-Alt-F1 should give you a text mode screen with a login prompt,
nothing to do with gdm or the GUI screens. Is that what is happening?
The GUI screen is on Ctrl-Alt-F7 normally, and Ctrl-Alt-Fx where
1<=x<=6 are all text screens. The text screens do have to use the
display drivers, but only a bare minimum of the display driver code.
They do not use any of the X and GUI software such as the display
manager.
>but
>after username/password, I now have the black screen again. After
>Ctrl-Alt-F3 and login via the CLI:
>
>[rcs at yoda: ~]$ sudo su -
> [sudo] password for rcs:
> root at yoda:~#
>killm
> root at yoda:~# exit
>
>Going back to the X screen -> still all black, unresponsive.
It would pay to check here that mythfrontend.real has actually been
killed. If the display drivers have suffered a crash or lockup,
mythfrontend.real may still be running, despite having been sent a
kill -9. This happens when there are system memory areas that have
not been deallocated, so the system can not actually shut down the
program. If that is what has happened, it has become a "zombie"
program and may only be able to be got rid of by a reboot, or maybe if
you were able to completely shut down X and restart it. This command
will show any mythfrontend programs that are running:
ps -e | grep mythfront
Unfortunately, I do not know of a way to shut down and restart X when
using gdm as the display manager. If you switch to lightdm, then
restarting lightdm will normally do a full restart of X and bring up
the GUI login screen:
sudo systemctl restart lightdm
I have never had that command work for gdm though - gdm seems to be
more complicated than lightdm. Switching to lightdm is usually
straightforward if you want to try that. If it is not installed,
install it:
sudo apt install lightdm
The install may ask if you want to select the display manager, if so,
then select lightdm. If it does not ask that, then run:
sudo dpkg-reconfigure gdm3
and when asked select lightdm as the display manager. To switch back
to gdm from lightdm, just do:
sudo dpkg-reconfigure gdm3
and select gdm3 as the display manager.
If it is enabled, Ctrl-Alt-Backspace should also restart X. I know
how to enable it for XFCE4 (Xubuntu), but not for Gnome. Maybe an
Internet search can tell you.
>Now, after logging in via ssh from another machine OR via Ctrl-Alt-Fx from
>the affected machine (same result):
>
>[rcs at yoda: ~]$ xrandr -d :0
> Invalid MIT-MAGIC-COOKIE-1 keyCan't open
>display :0
I have never had that message, but I am guessing that it means that X
is crashed so there is no working display to connect to.
>[rcs at yoda: ~]$ xrandr
> Can't open display
This is as expected. Without a -d option, xrandr does not have a
display it can open. When xrandr is run from a terminal on the GUI,
it can automatically find the display it is running on. When it is
run from a non-GUI terminal such as from ssh or Ctrl-Alt-Fx, there is
no default display and it will always need a -d option to tell it
which X display to connect to.
><scratching my head>
>Thanks again -
>Bob
You can try different geometry settings to see if you get better
results, or try using xrandr to change the mode to a 1920x1080 one:
xrandr -d :0 --output HDMI-0 --mode 1920x1080_60
for example. Finding the exact syntax for each mode is a bit of a
problem. If you add this to your /etc/X11/xorg.conf file:
Section "Screen"
Option "ModeDebug" "true"
EndSection
then X will list all the valid modes in the /var/log/Xorg.0.log file
like this:
[ 48.862] (II) NVIDIA(GPU-0): Validating Mode "1400x1050_60":
[ 48.862] (II) NVIDIA(GPU-0): Mode Source: X Server
[ 48.862] (II) NVIDIA(GPU-0): 1400 x 1050 @ 60 Hz
[ 48.862] (II) NVIDIA(GPU-0): Pixel Clock : 122.00 MHz
[ 48.862] (II) NVIDIA(GPU-0): HRes, HSyncStart : 1400, 1488
[ 48.862] (II) NVIDIA(GPU-0): HSyncEnd, HTotal : 1640, 1880
[ 48.862] (II) NVIDIA(GPU-0): VRes, VSyncStart : 1050, 1052
[ 48.862] (II) NVIDIA(GPU-0): VSyncEnd, VTotal : 1064, 1082
[ 48.862] (II) NVIDIA(GPU-0): Sync Polarity : +H +V
[ 48.862] (II) NVIDIA(GPU-0): Viewport 1400x1050+0+0
[ 48.862] (II) NVIDIA(GPU-0): Horizontal Taps 1
[ 48.862] (II) NVIDIA(GPU-0): Vertical Taps 1
[ 48.862] (II) NVIDIA(GPU-0): Core Formats 0xfff
[ 48.862] (II) NVIDIA(GPU-0): Base Formats 0xfff
[ 48.862] (II) NVIDIA(GPU-0): Distributed Rendering 1
[ 48.862] (II) NVIDIA(GPU-0): Overlay Formats 0xff6
[ 48.862] (II) NVIDIA(GPU-0): Mode "1400x1050_60" is valid.
Only ones with the "Mode "xxxx" is valid." are able to be used. The
others will have a line in the same location telling why they were
rejected. Should the need arise, the information in each of these
text blocks can be directly translated to a Modeline entry for
xorg.conf. The above data would translate to:
Modeline "1400x1050_60" 122.00 1400 1488 1640 1880 1050 1052 1064
1082 +hsync +vsync
If you can get the mode to change using xrandr, you should try
switching to all the valid modes you find in Xorg.0.log that you might
want to use, to see which ones work and which ones do not. If, as I
suspect, there are some modes that X thinks are valid but do not
actually work, and that is what is causing your problem, then you will
need to set up your xorg.conf to exclude the bad modes, or to adjust
their settings so that they are valid. Doing that is a tedious
process, so first just see if some bad modes are in fact the problem.
More information about the mythtv-users
mailing list