re: Display problems using nouveau - kern/58053

[Paul Goyette <paul%whooppee.com@localhost>]

On Wed, 13 Nov 2024, matthew green wrote:

> i don't have any particular useful thing to say, but i will add that
> while my 730 sees some of the issues you do, it rarely is a problem.
>
> however, i notice that mine is a lesser-version than yours, i think.
>
> >  	nouveau0 at pci1 dev 0 function 0: vendor 10de product 1287 (rev. 0xa1)
> >  	...
> >  	NVIDIA GK208B (b06070b1)
> >  	bios: version 80.28.b8.00.13
> >  	interrupting at msi14 vec 0 (nouveau0)
> >  	nouveau0: fb: 2048 MiB GDDR5
>
> mine is a GK107, with 2GB of DDR3, and bios: version 80.07.df.00.01.
>
> can you check the versions of your other card attempts?  i am also
> successfully using one of these in a different desktop:

I used to have them handy but having recently moved (from Lake County
to Vacaville) I can't find anything.  When my broken back (compression
fracture of T12) heals, I might be able to try a brand new GeForce
GTX1080-Ti, but not for a while.

> nouveau0: NVIDIA GP108 (138000a1)
> nouveau0: bios: version 86.08.0c.00.1a
> nouveau0: interrupting at msi14 vec 0 (nouveau0)
> nouveau0: fb: 2048 MiB GDDR5
>
> (a 1030T.)
>
> actually telling very specifically which cards you have tested would
> be useful here.
>
> both my desktops with the 730 and 1030 are ryzen (5600G and 3950x,
> respectively) and run -current, both recently updated.
>
> i'll send you my kernel config, see if you can figure anything out
> from that.
>
> oh, one idea i just had -- tried using full GENERIC, not MODULAR?
> this shouldn't matter, but maybe it does.

GENERIC fails with all the above symptoms, same as my custom kernel

> > * console messages from kevent (something about attempting to
> >    register an event that is inappropriate for the specified file)
>
> i do not see this one.
>
> > * once I just booted and left it with xdm's login dialog displayed,
> >    and the system crashed spontaneously (no user activity) after a
> >    couple hours
>
> this makes me wonder if there are other issues with the system, like
> bad memory.  have you tried memtest86 or similar?

Got a memtest86 image that works? I haven't been able to boot one
for years.

> > * firefox might spontaneously crash without any clues
>
> i have firefox, and less often, X itself, crash due to some weird
> issue, sometimes related to these below:
>
> > * always get lots of ``DRM: core notified timeout'' messages, and some
> >    occassional ``base-0: timeout'' messages
>
> i get these infrequently -- always at startup, and then almost never.
>
> > * once in a while, ``fifo: fault 01 [WRITE] at 000000000025e000 engine
> >    00 [GR] client 0f [GPC0/PROP_0] reason 02 [PTE] on channel 2
> >    [007fb82000 user]''
> > * Here's one I haven't noticed previously:
> >
> >  	nouveau0: notice: fifo: channel 2: killed
> >  	nouveau0: warn: user: channel 2 killed!
> >  	nouveau0: notice: fifo: runlist 0: scheduled for recovery
> >  	nouveau0: notice: fifo: engine 0: scheduled for recovery
> >  	nouveau0: autoconfiguration error: error: user: failed to idle channel 4 [user]
>
> i see these sometimes, often linked to an app crashing, and sometimes
> you get log data that indicates the app crashed because the kernel
> context for it died in the above type error, and the nouveau drm code
> (in userland) expects a lookup to always succeed.  i spent a bit of
> time trying to see if it could be handled better, but it's not clear
> to me yet.
>
> most of the time, if X crashes, i can usually restart it, possible
> blind or remotely because the display is hosed.  sometimes i have to
> reboot to get it back, but my main desktop lasted many months uptime
> with 2 or3 of the issues happening, with one X crash and restart fine.

One more item...

If I boot up and get an X session going, with xclock window running, and
then I Ctrl-Alt-F1 to go to "console" display, whenn I subsequenty go
back to X via Ctrl-Alt-F5 it takes 5- to 10-seconds before X becomes
responsive.  Until then, no kb events, no mouse tracking, nada.  Any
xterm output generated while viewing console is delayed until the above
delay expires, and xclock does a "catch-up" when the system becomes
ready,  Note that the delay occurs even if I immediately switch back to
the F5 X window.

It seems as though its getting confused on what it should be waiting
for, perhaps passing a garbage [fm]utex pointer into the kernel.  (This
is just CONJECTURE on my part.)  Sometimes the random value is sort-of
valid (even if wrong) while other times it is so far from reality that
some sort of fault occurs.

And one more observation...

Sometimes after the F1/F5 dance it doesn't recover, hanging instead.  In
this case I can usually ssh in from my Windoze laptop and kill the main
firefox process; often but not always this unhangs the X window.

Anyway, I hope to be able to start swapping boards again...


+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint:     | E-mail addresses:    |
| (Retired)           | 1B11 1849 721C 56C8 F63A | paul%whooppee.com@localhost    |
| Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | pgoyette%netbsd.org@localhost  |
| & Network Engineer  |                          | pgoyette99%gmail.com@localhost |
+---------------------+--------------------------+----------------------+