Re: [gentoo-user] Can't get the GUI to stay up for more than a minute or so before crashing

[Michael <confabulate@kintzios.com>]

[-- Attachment #1: Type: text/plain, Size: 7634 bytes --]

On Thursday, 27 June 2024 23:52:25 BST Dale wrote:
> Michael wrote:

> > [snip ...]
> > [    30.345] (II) modeset(0): [DRI2]   DRI driver: nouveau  <== Not nvidia
> > ==
> > 
> > [snip ...]
> > [    30.295] (II) modeset(0): Output DP-1 disconnected
> > [    30.295] (II) modeset(0): Output DP-2 disconnected
> > [    30.295] (II) modeset(0): Output DP-3 disconnected
> > [    30.295] (II) modeset(0): Output DP-4 connected
> > 
> > What does it take to connect the cable on the FIRST port of the video
> > card?
> 
> This reply may be a little odd.  I wrote some then went back and tried
> some stuff and added info to it.  Trying to make it make sense. 

My apologies, I didn't meant to add to your frustration.  Working with a 
headless system is no fun when you expect to run a desktop on this thing!

I was just making a remark on the fact the card detects the monitor as being 
connected to DFP-3 or DFP-5 when using the proprietary nvidia driver, but the 
DP-4 when you used the open source nouveau driver.


> > At first, when it really wouldn't work, I had it on the bottom port.  At
> some point we thought that was the last port, #4 or DP-3 in the logs,
> and not the first port.  I moved it to the top port which is #1, we
> thought.  It's still on that port but that port did work once and
> resulted in "solved" being added to the subject line.  I just double
> checked.  It is plugged in the top port.  Unless the bottom port is #1
> like I originally thought, then it should be on port #1.  I did a search
> and found a image that shows it puts the port number on the metal
> bracket.  I removed the card so I could see the numbers.  The bottom
> port is number 1 like I originally thought.  So, I had it in the right
> port to begin with, which wasn't working either.  I'll put it back on
> what the metal bracket says is port #1, or bottom port.  I booted up,
> started DM, correct resolution but no plasma and background is black. 
> Still not a functional desktop.  Partially works tho.  Time to reboot. 
> On reboot, sddm and KDE are low resolution.  It does have a background
> image and plasma is working.  Keep in mind, all I did is reboot.  I
> didn't change any config file or run any commands.  Reboot again.  This
> time, correct resolution but no plasma.  Again, all I did was reboot. 
> No changes to anything at all.  As you can see, each time I reboot, it
> is like rolling dice.  I suspect if I keep rebooting it will eventually
> do the black screen and power the monitor off. 

It seems to me the card is probing the monitor to find out what settings it 
prefers/will work with.  This probing of the driver scrolls through a number 
of potential Modelines, but if the monitor does not respond in a timely manner 
with its preferred resolution and frequency you get a broken result.

Here are some hypotheses of mine, in absence of more concrete evidence.  The 
old box is slower and the initialisation process takes longer.  In this longer 
processing time the monitor responds with its EDID and what not.  The card 
receives it in a timely fashion and sets the driver accordingly.

With your new box things happen faster on the PC side, but not on the monitor 
side.  Two times out of three the synchronisation between driver and monitor 
fails and you end up with reports of EDID not found and monitor shown as 
disconnected in your Xorg.0.log.

Having the monitor plugged in any port on the card, first or last, should not 
make a difference, but if milli/nano-seconds count then it /might/ make a 
difference, assuming the ports are tried sequentially by the driver.  Hence I 
had suggested stick with the first port.  Some user reports on the interwebs 
mentioned it, so I thought it is worth trying it.

What else worth trying is  to set fixed directives for the "Monitor" section 
in your xorg config file, or capture the EDID table into a file and feed it to 
the driver.  The former ought to work, the latter may not if the EDID itself 
is buggy, but that's a problem to solve later if it even exists.  Either way, 
setting explicit directives for the monitor Modeline(s) and preferred 
resolution/frequency ought to take auto-probing out of the equation.


> I did originally try to use the nouveau drivers.  It kinda worked, once
> at least, but the screen was very slow to respond and the mouse was very
> jerky.  It just wasn't good enough for whatever reason.  I recompiled
> the kernel without those drivers and emerged nvidia.

It's your call which drivers you should try to get it to work with first.

Slow GUI response with the nouveau driver would indicate the kernel 
configuration/firmware loading was not 100% when you trying initially, because 
it works fine when you tried it again with Kubuntu's kernel.

People who use Nvidia prefer the nvidia driver in terms of performance, CUDA, 
etc. so you may want to stick with the nvidia driver initially.  In this case, 
walk through this guide and cross-check you followed all suggestions in there 
to configure your kernel, including disabling the nouveau driver.

https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers

If you intend to have both nouveau and nvidia drivers and switch between them, 
then you can build nouveau as a module and implement the more convoluted 
switching methods suggested in the next guide, but I suggest you leave this 
for later and not confuse the two drivers:

https://wiki.gentoo.org/wiki/Nouveau_%26_nvidia-drivers_switching

Having checked your kernel against the nvidia-driver guide, installed your 
updated kernel & initramfs images you should reboot.  Use 'lspci -k' and scan 
dmesg to make sure nvidia is loaded and there were no hiccups.

You've tried not having an xorg.conf and didn't work, or at least it did not 
work reliably.  Mind you, you also tried with a xorg.conf and this didn't make 
things better.  LOL!  However, I think this was because the "Monitor" section 
was mostly empty:

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    Option         "DPMS"
EndSection

Restart, if you need to, the display-manager until you eventually arrive at a 
fully loaded and functioning desktop.  nvidia-smi should reveal if the driver 
is loaded and working fully.  You can run nvidia-settings, (emerge x11-
drivers/nvidia-drivers with USE="tools") to tweak resolution and frequency for 
your monitor, which will then be stored in your config file:

https://download.nvidia.com/XFree86/Linux-x86_64/1.0-6106/nvidia-settings-user-guide.txt

O, while all is working as desired 'xrandr -q' will provide you with some 
useful information for your xorg.conf:

Identifier - e.g. "DisplayPort-0", or "LG Electronics W2253"

Modeline - e.g. Modeline 1920x1080_60.0  138.50  1920 1968 2000 2080  1080 
1083 1088 1111 +hsync +vsync

and you can set a preferred option in your xorg.conf; e.g.

HorizSync       15.0 - 67.0
VertRefresh     59.0 - 60.0
Modeline        "1920x1080_60.0  138.50  1920 1968 2000 2080  1080 1083 1088 
1111 +hsync +vsync"
Option "PreferredMode" "1920x1080"_60.0"

or some such.

If the above won't do it, you can capture the monitor's EDID while it is 
working - you can use nvidia-settings again:

https://nvidia.custhelp.com/app/answers/detail/a_id/3571/~/managing-a-display-edid-on-linux

There's a more manual way to do this too:

find /sys |grep -i edid

then copy the corresponding file to /lib/firmware/LG/W2253_edid.bin

and add it to your kernel before you recompile it:

https://docs.kernel.org/admin-guide/edid.html#

See if the above helps you to a stable monitor, or post back with xorg.0.log 
results.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]