William Unruh <unruh@invalid.ca> writes:
> On 2023-07-29, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Does it respond to ping?
>
> No.
[...]
>> If it does not ping then the kernel has crashed, either due to a kernel
>> bug or a hardware fault.
>
> That is sure what it looks like. Weird thing is that the video card is
> still sending out the last image, so it is running.

The video card keeps transmits to the display under its own steam, it
doesn’t need the kernel to tell it to do so.

--
https://www.greenend.org.uk/rjk/

On 7/30/23 00:39, William Unruh wrote:
> On 2023-07-29, J.O. Aho <user@example.net> wrote:
>> On 29/07/2023 11:44, Richard Kettlewell wrote:
>>> William Unruh <unruh@invalid.ca> writes:
>>>> Except in my case, nothing I type does anything, the mouse cursor does
>>>> not move, Teh Alt-ctrl-F keys do nothing, alt-ctrl-det or alt-ctrl-bksp
>>>> do nothing, gkrellm stops updating. Usually when I have run out of
>>>> memory, somethings still work, and the machine slows down drastically as
>>>> it starts to swap. This is just a complete sudden freeze. (Unlike this
>>>> past time, sometimes this has happened while I am working on the
>>>> machine. This time it happened while I was asleep)
>>>
>>> Yes. Normal behavior for running out of RAM is swapping, and for running
>>> out of RAM+swap is to start killing user processes.
>>
>> The problem is that the swapping in and out Xorg and the desktop
>> environment makes things extremely slow and the tradition in Linux is to
>> kill a random process (not sure if it's changed nowadays), the
>> likelihood that the right process is killed is slim and if not the right
>> one is killed, the swapping will not end and the swap will keep the
>> system slow and even if it kills the right process it will in reality
>> take hours before anything happens due of the swap in and out.
>>
>> My experience is that things do not get better even if you disable swap
>> (seldom you really need swap when having 64GB RAM), for some reason it
>> seems to be the disk is as active as during the swap in / out. Could it
>> have to do with zram?
>>
>> Something that makes a difference is setting a hard memory limit on the
>> process, then it will be killed when it tries to use more RAM than the
>> limit.
>>
>> Of course at this point we don't know what the issues is for OP and he
>> don't use plasma5, so I doubt it's plasmashell that is his issue.
>
> Actually I do use Plasma and sddm.
> But as I said there is little indication beforehand that is is swapping
> that is the problem (in the times that it happened to me while I was
> working on the system.-- as I said this last time it occured just before
> bedtime and I discovered it next morning. )

Not sure about your setup, I have nVidia RTX 2060 with the closed source
driver (generally the latest) with a kernel that tend to be the latest
from the distribution together with the latest version of kde/plasma.

Running two Xorg with their own plasma5, one with weather applet and
directory display and the other one with just the directory display.
Fixed image background on both.

The memory leak is quite random when it starts, but latest 2 days after
start of plasmashell it will have begun to eat up a lot of memory, first
slowly and then faster and faster. When using strace it seems
plasmashell is trying to connect somewhere and it gets a timeout, during
the timeout period it manage to queue 3-4 more requests (haven't figured
out where it tries to connect). Usually it's just one of the
plasmashells that hogs a lot of memory, like 30-40GB while the other may
just be around 10GB (which one uses the most is random). When the RAM
run out, then the disk activity starts (remind you that I do not have a
swap) and when the disk activity has begun, the Xorg will be so slow and
if you move the mouse pointer you will see it move a small distance and
then freeze. It will be now impossible to ssh to the machine, if you
have a running ssh connection to the machine you can still write
something, but it will be slow like a 120baud modem. If you already are
root ('su -' before it happen), then you can run 'killall -9
plasmashell' and after a short while the machine will be somewhat usable
again, now you just need to start the plasmashell for each user, this
tend to be a two step process, first "su - username" and run
"DISPLAY=:X.0 plasmashell --replace", then go and switch to that users
VT and then run from konsole "plasmashell --replace", and then repeat
the process with the next user.

There is a bug report on this, I did keep on updating it for each
version of kde/plasma I had installed and from time to time send in more
logs, but the process has been 0%.

There is a known bug in the wallpaper slideshow, but never used that
one, so it's not the one affecting me.

Nowadays I don't use plasma5 at all, I will make a try with plasma6 when
it's in the distros repository, but until then I will keep on using lxqt
and I suggest you do also check for another desktop environment to use
until plasma6 is out for your distro.

--
//Aho

On 7/30/2023 6:36 AM, Richard Kettlewell wrote:
> William Unruh <unruh@invalid.ca> writes:
>> On 2023-07-29, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> Does it respond to ping?
>>
>> No.
> [...]
>>> If it does not ping then the kernel has crashed, either due to a kernel
>>> bug or a hardware fault.
>>
>> That is sure what it looks like. Weird thing is that the video card is
>> still sending out the last image, so it is running.
>
> The video card keeps transmits to the display under its own steam, it
> doesn’t need the kernel to tell it to do so.
>

For a non-tearing display, I would expect double buffering, and some
sort of command issued to aid compositing (Z-axis sorting). That may
require a minimum of some sort of command list to implement compositing.
A command list issued at least, 60 times a second.

And there's more than one level of compositing going on, as a web browser
also composites, even when its "window" is "stable". It is still composing
the same stable image, 60 times a second.

Even when a computer is idle, modern developers have made it busy.
In ways that were never present in the past. There was a time, when
a computer was actually idle -- if you moved a window, it required a
redraw, but at least there was proportionate behavior to user input.
Whereas the modern way of doing things, is just abusive.

Making conclusions about how stuff works on computers now, by
observing failures, is pretty difficult. But there are some
examples available. For example, when the memory consumption
of a browser used to shoot up, I managed to trace that one
day (by noticing a graphical failure-to=update), to a
breakage in the browser "output" being "consumed" by the
window manager. It seemed to indicate, that the browser
process did not recognize an overflow condition and it
did not "throw away" unconsumed content it was sending
to the window manager.

It's not like the old days, where some game would crash,
and various parts of the mechanical aspects of how graphics
and sound worked, presented themselves. The failures now,
are much harder to observe. For example, on an old game
crash, the sound buffer pointer was reused again and again,
so a repetitive sound would come out of the speaker until
the PC was reset.

Paul

On 2023-07-30, J.O. Aho <user@example.net> wrote:
> On 7/30/23 00:39, William Unruh wrote:
>> On 2023-07-29, J.O. Aho <user@example.net> wrote:
>>> On 29/07/2023 11:44, Richard Kettlewell wrote:
>>>> William Unruh <unruh@invalid.ca> writes:
....
>
> Running two Xorg with their own plasma5, one with weather applet and
> directory display and the other one with just the directory display.
> Fixed image background on both.
>
> The memory leak is quite random when it starts, but latest 2 days after
> start of plasmashell it will have begun to eat up a lot of memory, first
> slowly and then faster and faster. When using strace it seems
> plasmashell is trying to connect somewhere and it gets a timeout, during
> the timeout period it manage to queue 3-4 more requests (haven't figured
> out where it tries to connect). Usually it's just one of the
> plasmashells that hogs a lot of memory, like 30-40GB while the other may
> just be around 10GB (which one uses the most is random). When the RAM

How much ram do you have?
Mu plasmashell right now is 2GB VSZ

I run Intel onboard graphics. There is no slowdown beforehand. It just
as if someone threw a switch to shut everything down, except that the
image keeps showing (ie the grephics card is still sending out a
signal).
No disk activity, no slowdown. just stop.

> run out, then the disk activity starts (remind you that I do not have a
> swap) and when the disk activity has begun, the Xorg will be so slow and
> if you move the mouse pointer you will see it move a small distance and
> then freeze. It will be now impossible to ssh to the machine, if you
> have a running ssh connection to the machine you can still write
> something, but it will be slow like a 120baud modem. If you already are
> root ('su -' before it happen), then you can run 'killall -9
> plasmashell' and after a short while the machine will be somewhat usable
> again, now you just need to start the plasmashell for each user, this
> tend to be a two step process, first "su - username" and run
> "DISPLAY=:X.0 plasmashell --replace", then go and switch to that users
> VT and then run from konsole "plasmashell --replace", and then repeat
> the process with the next user.
>

J.O. Aho wrote:
> Nowadays I don't use plasma5 at all, I will make a try with plasma6 when
> it's in the distros repository, but until then I will keep on using lxqt
> and I suggest you do also check for another desktop environment to use
> until plasma6 is out for your distro.

I realize that we are talking about an 'unknown' diagnosis, but it
sounds like it is closely associated w/ the KDE desktop, that
theoretically anyone using plasma5 could spring a memory leak, or, is
there potentially some much more limited concept going on here?

Like some 'specific' KDE 'gear' that if someone didn't have that KDE
app, they wouldn't have a leak?

--
Mike Easter

On 7/30/23 19:59, William Unruh wrote:
> On 2023-07-30, J.O. Aho <user@example.net> wrote:
>> On 7/30/23 00:39, William Unruh wrote:
>>> On 2023-07-29, J.O. Aho <user@example.net> wrote:
>>>> On 29/07/2023 11:44, Richard Kettlewell wrote:
>>>>> William Unruh <unruh@invalid.ca> writes:
> ...
>>
>> Running two Xorg with their own plasma5, one with weather applet and
>> directory display and the other one with just the directory display.
>> Fixed image background on both.
>>
>> The memory leak is quite random when it starts, but latest 2 days after
>> start of plasmashell it will have begun to eat up a lot of memory, first
>> slowly and then faster and faster. When using strace it seems
>> plasmashell is trying to connect somewhere and it gets a timeout, during
>> the timeout period it manage to queue 3-4 more requests (haven't figured
>> out where it tries to connect). Usually it's just one of the
>> plasmashells that hogs a lot of memory, like 30-40GB while the other may
>> just be around 10GB (which one uses the most is random). When the RAM
>
> How much ram do you have?

64GB, I used to have 32, but I ran into the issue and I was hoping that
doubling the amount of RAM should make it less affecting, gosh I was wrong.

> Mu plasmashell right now is 2GB VSZ

I think I usually had it to take ~700MB when it started, if it was up on
2GB I knew it would start to eat more memory, so a "plasmashell
--replace" was the only thing that prevented it from going bad, for a
while, in best case you buy yourself another day.

> I run Intel onboard graphics. There is no slowdown beforehand. It just
> as if someone threw a switch to shut everything down, except that the
> image keeps showing (ie the grephics card is still sending out a
> signal).

You will have a desktop on you screen all the way till you reboot, this
far I never seen the plasmashell process to be auto killed, if it would
then your screen would turn black, but a mouse pointer that you can move
around.

> No disk activity, no slowdown. just stop.

If you had been a hour earlier, I think you would maybe caught the
slowdown, as it's related to the amount of free RAM you have left, when
you don't it's the freeze time.

--
//Aho

On 7/30/23 21:11, Mike Easter wrote:
> J.O. Aho wrote:
>> Nowadays I don't use plasma5 at all, I will make a try with plasma6
>> when it's in the distros repository, but until then I will keep on
>> using lxqt and I suggest you do also check for another desktop
>> environment to use until plasma6 is out for your distro.
>
> I realize that we are talking about an 'unknown' diagnosis, but it
> sounds like it is closely associated w/ the KDE desktop, that
> theoretically anyone using plasma5 could spring a memory leak, or, is
> there potentially some much more limited concept going on here?
>
> Like some 'specific' KDE 'gear' that if someone didn't have that KDE
> app, they wouldn't have a leak?
>

I have had this issue for some years, it's only affected my primary
desktop where I have two X sessions running.

I do not have this issue on our laptops which just runs one X session,
all run the same distro, all of them are up to date, desktop nVidia
graphics, laptop 1 intel, and laptop intel/nVidia. Appletwise they are
configured the same.

If I understood right from William, he has intel on his desktop and runs
one X session.

So we do not know what causes the issue, so KDE/plasma5 has some odd
memory leak that seems to be random, of course it could be a setting
that causes it, but from the xsession-errors log there ain't anything
that would hint on what it could be.

--
//Aho

On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
> On 2023-07-30, J.O. Aho <user@example.net> wrote:
>> On 7/30/23 00:39, William Unruh wrote:
>>> On 2023-07-29, J.O. Aho <user@example.net> wrote:
>>>> On 29/07/2023 11:44, Richard Kettlewell wrote:
>>>>> William Unruh <unruh@invalid.ca> writes:
> ...
>>
>> Running two Xorg with their own plasma5, one with weather applet and
>> directory display and the other one with just the directory display.
>> Fixed image background on both.
>>
>> The memory leak is quite random when it starts, but latest 2 days after
>> start of plasmashell it will have begun to eat up a lot of memory, first
>> slowly and then faster and faster. When using strace it seems
>> plasmashell is trying to connect somewhere and it gets a timeout, during
>> the timeout period it manage to queue 3-4 more requests (haven't figured
>> out where it tries to connect). Usually it's just one of the
>> plasmashells that hogs a lot of memory, like 30-40GB while the other may
>> just be around 10GB (which one uses the most is random). When the RAM
>
> How much ram do you have?
> Mu plasmashell right now is 2GB VSZ

I don't think the VSZ is all that significant.

What is the RSS?

(Right now I have a chromium process whose VSZ and RSS are reported by ps
to be, respectively, 1185776448 and 63232.)

Jim

Jim Diamond <JimDiamond@jdvb.ca> writes:
> On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
>> How much ram do you have?
>> Mu plasmashell right now is 2GB VSZ
>
> I don't think the VSZ is all that significant.

Indeed VSZ tells you very little - for instance it includes a 2MB dead
page in the middle of every shared library, which (in a complex process)
scales up VSZ to something huge, but consumes almost no real resources.

> What is the RSS?

I think the theories about user space memory leaks are a red herring.
The reported behavior is just not consistent with them.

--
https://www.greenend.org.uk/rjk/

On 7/30/23 22:03, J.O. Aho wrote:
> On 7/30/23 19:59, William Unruh wrote:

>> Mu plasmashell right now is 2GB VSZ
>
> I think I usually had it to take ~700MB when it started, if it was up on
> 2GB I knew it would start to eat more memory, so a "plasmashell
> --replace" was the only thing that prevented it from going bad, for a
> while, in best case you buy yourself another day.

Sorry, I missed you looked at VSZ, that one is irrelevant, look at RSS
or calculate from %MEM.

--
//Aho

On 2023-07-30, J.O. Aho <user@example.net> wrote:
> On 7/30/23 19:59, William Unruh wrote:
>> On 2023-07-30, J.O. Aho <user@example.net> wrote:
>>> On 7/30/23 00:39, William Unruh wrote:
>>>> On 2023-07-29, J.O. Aho <user@example.net> wrote:
>>>>> On 29/07/2023 11:44, Richard Kettlewell wrote:
>>>>>> William Unruh <unruh@invalid.ca> writes:
....

>>
>> How much ram do you have?
>
> 64GB, I used to have 32, but I ran into the issue and I was hoping that
> doubling the amount of RAM should make it less affecting, gosh I was wrong.

I have 8 GB. ps says plasmashell right now has VSZ of 1.9GB and %MEM of
3.1% ( which sould be 250MB I guess.

>
>> Mu plasmashell right now is 2GB VSZ
>
> I think I usually had it to take ~700MB when it started, if it was up on
> 2GB I knew it would start to eat more memory, so a "plasmashell
> --replace" was the only thing that prevented it from going bad, for a
> while, in best case you buy yourself another day.
>
>
>> I run Intel onboard graphics. There is no slowdown beforehand. It just
>> as if someone threw a switch to shut everything down, except that the
>> image keeps showing (ie the grephics card is still sending out a
>> signal).
>
> You will have a desktop on you screen all the way till you reboot, this
> far I never seen the plasmashell process to be auto killed, if it would
> then your screen would turn black, but a mouse pointer that you can move
> around.
>
>
>> No disk activity, no slowdown. just stop.
>
> If you had been a hour earlier, I think you would maybe caught the
> slowdown, as it's related to the amount of free RAM you have left, when
> you don't it's the freeze time.

I have about 8GB of swap, so it should slow down when it starts to use
swap.

On 7/31/23 09:49, William Unruh wrote:
> On 2023-07-30, J.O. Aho <user@example.net> wrote:
>> On 7/30/23 19:59, William Unruh wrote:

> ...
>
>>>
>>> How much ram do you have?
>>
>> 64GB, I used to have 32, but I ran into the issue and I was hoping that
>> doubling the amount of RAM should make it less affecting, gosh I was wrong.
>
> I have 8 GB. ps says plasmashell right now has VSZ of 1.9GB and %MEM of
> 3.1% ( which sould be 250MB I guess.

Then your plasmashell is using 250MB at the moment, the VSZ is a in
theory amount of RAM the process would use if it had to load everything
at once, but as you ain't using all the features of plasmahsell this
will not happen.

The RSS amount will include all the memory dependencies may use like
libraries, as most libraries in Linux are shared, then the same shared
library can be reported multiple times (once in each process that uses
it), this applies to the %MEM too.

If your %MEM reaches 25%, then it will use like 2GB mem and the RSS will
also give you something in that region too +/- something as it's more
accurate value than %MEM.

>> If you had been a hour earlier, I think you would maybe caught the
>> slowdown, as it's related to the amount of free RAM you have left, when
>> you don't it's the freeze time.
>
> I have about 8GB of swap, so it should slow down when it starts to use
> swap.

Depends on what has been swapped out, if it's just things that are
seldom used (say hibernated tabs in your browser), then you will not
notice anything until you load a such tab. The issue is when it start
swap in and out data that it's needing, this will lead to that the disk
light will blink really rapidly and everything goes extremely slowly or
seems to have frozen.

"J.O. Aho" <user@example.net> writes:
> Then your plasmashell is using 250MB at the moment, the VSZ is a in
> theory amount of RAM the process would use if it had to load
> everything at once, but as you ain't using all the features of
> plasmahsell this will not happen.

On a 64-bit Linux, VSZ is often way more than the RAM a process could
possibly use. Each shared library has a 2MB PROT_NONE mapping that
contributes to VSZ but can never consume any RAM, and GUI processses
often have huge numbers of shared libraries so this can easily reach
into the hundreds of megabytes.

See https://www.greenend.org.uk/rjk/tech/dataseg.html for discussion.

--
https://www.greenend.org.uk/rjk/

On 2023-07-31 at 04:11 ADT, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Jim Diamond <JimDiamond@jdvb.ca> writes:
>> On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
>>> How much ram do you have?
>>> Mu plasmashell right now is 2GB VSZ
>>
>> I don't think the VSZ is all that significant.
>
> Indeed VSZ tells you very little - for instance it includes a 2MB dead
> page in the middle of every shared library, which (in a complex process)
> scales up VSZ to something huge, but consumes almost no real resources.
>
>> What is the RSS?
>
> I think the theories about user space memory leaks are a red herring.
> The reported behavior is just not consistent with them.
>

I have not followed the thread too closely, but I suspect you are right.

But when I saw someone reporting VSZ, I thought that they should know that
it wasn't meaningful, just in case they keep barking up that tree.

Cheers.
Jim

On 2023-07-31, Jim Diamond <JimDiamond@jdvb.ca> wrote:
> On 2023-07-31 at 04:11 ADT, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Jim Diamond <JimDiamond@jdvb.ca> writes:
>>> On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
>>>> How much ram do you have?
>>>> Mu plasmashell right now is 2GB VSZ
>>>
>>> I don't think the VSZ is all that significant.
>>
>> Indeed VSZ tells you very little - for instance it includes a 2MB dead
>> page in the middle of every shared library, which (in a complex process)
>> scales up VSZ to something huge, but consumes almost no real resources.
>>
>>> What is the RSS?
>>
>> I think the theories about user space memory leaks are a red herring.
>> The reported behavior is just not consistent with them.
>>
>
> I have not followed the thread too closely, but I suspect you are right.
>
> But when I saw someone reporting VSZ, I thought that they should know that
> it wasn't meaningful, just in case they keep barking up that tree.

Yes, thanks for that. VSZ seemed much to large to be reasonable. but I
could not see anything else in the ps aux report that could be the
actual memory used (except %MEM and what it was a percentage of I had no
idea.)

On 7/31/2023 12:47 PM, William Unruh wrote:
> On 2023-07-31, Jim Diamond <JimDiamond@jdvb.ca> wrote:
>> On 2023-07-31 at 04:11 ADT, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> Jim Diamond <JimDiamond@jdvb.ca> writes:
>>>> On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
>>>>> How much ram do you have?
>>>>> Mu plasmashell right now is 2GB VSZ
>>>>
>>>> I don't think the VSZ is all that significant.
>>>
>>> Indeed VSZ tells you very little - for instance it includes a 2MB dead
>>> page in the middle of every shared library, which (in a complex process)
>>> scales up VSZ to something huge, but consumes almost no real resources.
>>>
>>>> What is the RSS?
>>>
>>> I think the theories about user space memory leaks are a red herring.
>>> The reported behavior is just not consistent with them.
>>>
>>
>> I have not followed the thread too closely, but I suspect you are right.
>>
>> But when I saw someone reporting VSZ, I thought that they should know that
>> it wasn't meaningful, just in case they keep barking up that tree.
>
> Yes, thanks for that. VSZ seemed much to large to be reasonable. but I
> could not see anything else in the ps aux report that could be the
> actual memory used (except %MEM and what it was a percentage of I had no
> idea.)
>

Only you know the particulars of your system.

You say you're using Plasma, and "plasma freezes" shows in Google searches.

If you were to note a rising RAM consumption (say, leave top running
when freeze occurs), in the example here, one post mentions
it is possible it's a video card driver issue. The graphics stack
is producing frames, but there is no consumer.

https://bugzilla.redhat.com/show_bug.cgi?id=1399396

In some cases, the NVidia driver has watchdog enabled, the Nouveau
does not. This makes the Nvidia driver capable of doing a VPU recover,
and restoring service before it is too late.

Paul

On 2023-08-01, Paul <nospam@needed.invalid> wrote:
> On 7/31/2023 12:47 PM, William Unruh wrote:
>> On 2023-07-31, Jim Diamond <JimDiamond@jdvb.ca> wrote:
>>> On 2023-07-31 at 04:11 ADT, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> Jim Diamond <JimDiamond@jdvb.ca> writes:
>>>>> On 2023-07-30 at 14:59 ADT, William Unruh <unruh@invalid.ca> wrote:
>>>>>> How much ram do you have?
>>>>>> Mu plasmashell right now is 2GB VSZ
>>>>>
>>>>> I don't think the VSZ is all that significant.
>>>>
>>>> Indeed VSZ tells you very little - for instance it includes a 2MB dead
>>>> page in the middle of every shared library, which (in a complex process)
>>>> scales up VSZ to something huge, but consumes almost no real resources.
>>>>
>>>>> What is the RSS?
>>>>
>>>> I think the theories about user space memory leaks are a red herring.
>>>> The reported behavior is just not consistent with them.
>>>>
>>>
>>> I have not followed the thread too closely, but I suspect you are right.
>>>
>>> But when I saw someone reporting VSZ, I thought that they should know that
>>> it wasn't meaningful, just in case they keep barking up that tree.
>>
>> Yes, thanks for that. VSZ seemed much to large to be reasonable. but I
>> could not see anything else in the ps aux report that could be the
>> actual memory used (except %MEM and what it was a percentage of I had no
>> idea.)
>>
>
> Only you know the particulars of your system.
>
> You say you're using Plasma, and "plasma freezes" shows in Google searches.

As I said it is not just plasma that freezes but the whole system. I
cannot log in via ssh on the network, no keyboard entry works (eb
alt-ctrl-del does not reboot the system), no mouse cursor moves when I
more themouse. In the past ( ie over a year ago) when this happened,
there was no precursor. The system did not slow down. before hand. I
know what swapping feels like, and there was no evidence of that. (I
have as much swap space as I have ram, about 8GB each)

>
> If you were to note a rising RAM consumption (say, leave top running
> when freeze occurs), in the example here, one post mentions

The freeze occurs randomly about once every month or so (or rather I
have had two in the past 2 months and none from last Aug to that time)

> it is possible it's a video card driver issue. The graphics stack
> is producing frames, but there is no consumer.

I have an onboard Intel graphics.
lspci says
00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630]
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1399396
>
> In some cases, the NVidia driver has watchdog enabled, the Nouveau
> does not. This makes the Nvidia driver capable of doing a VPU recover,
> and restoring service before it is too late.