Hello,

with the last Mesa from OpenSUSE factory this regression is still present
# rpm -qa Mesa*
Mesa-32bit-19.1.2-225.1.x86_64
Mesa-dri-19.1.2-225.1.x86_64
Mesa-libglapi0-19.1.2-225.1.x86_64
Mesa-demo-x-8.4.0-1.7.x86_64
Mesa-libGLESv2-2-19.1.2-225.1.x86_64
Mesa-libEGL1-19.1.2-225.1.x86_64
Mesa-dri-nouveau-19.1.2-225.1.x86_64
Mesa-libGL1-19.1.2-225.1.x86_64
Mesa-libva-19.1.2-225.1.x86_64
Mesa-libGL1-32bit-19.1.2-225.1.x86_64
Mesa-19.1.2-225.1.x86_64
Mesa-libglapi0-32bit-19.1.2-225.1.x86_64
Mesa-gallium-32bit-19.1.2-225.1.x86_64
Mesa-dri-32bit-19.1.2-225.1.x86_64
Mesa-gallium-19.1.2-225.1.x86_64
Mesa-KHR-devel-19.1.2-225.1.x86_64
Mesa-libEGL-devel-19.1.2-225.1.x86_64
Mesa-libGL-devel-19.1.2-225.1.x86_64
Mesa-libEGL1-32bit-19.1.2-225.1.x86_64

# rpm -qa xf86-video-nouveau
xf86-video-nouveau-1.0.15-40.12.x86_64

# uname -a
Linux hpprol2 5.2.1-1-default #1 SMP Mon Jul 15 05:32:47 UTC 2019 (bf5c01b) x86_64 x86_64 x86_64 GNU/Linux

the same error is present in journalctl.
Jul 25 08:29:02 hpprol2 kernel: nouveau 0000:0a:00.0: disp: outp 03:0006:0f42: training failed

Not sure if Mesa is involved or alone nouveau?

Regards

Created attachment 145022 [details]
Xorg.0.log

Hello I tested with the last available kernel
"Linux hpprol2 5.3.0-rc3-4.g7de292a-default #1 SMP Fri Aug 9 16:17:27 UTC 2019 (7de292a) x86_64 x86_64 x86_64 GNU/Linux
"

This regression is still present.

I have attached the Xorg.0.log. Do you need other information?

Many thanks in advance
Philippe

Created attachment 145027 [details]
journalctl with debug

hello,

I added the parameters "drm.debug=14  log_buf_len=16M" on the boot option
here the output of journalctl -b 0

Created attachment 145028 [details]
dmesg output with debug

hello,

I added the parameters "drm.debug=14  log_buf_len=16M" on the boot option
here the output of dmesg

What was a working kernel, and what's a non-working kernel?

The most effective way to determine the problematic change is to do a git bisect between those two kernels.

Created attachment 145029 [details]
Xorg.0.log with debug

hello,

I added the parameters "drm.debug=14  log_buf_len=16M" on the boot option
here the Xorg.0.log

(In reply to Ilia Mirkin from comment #6)
> What was a working kernel, and what's a non-working kernel?
> 
> The most effective way to determine the problematic change is to do a git
> bisect between those two kernels.

I think that it is not the kernel because when I saw the problem I rebooted the preceding kernel and the problem was then also present.
On july, 10 I installed.a snapshot with a lot of component. looking in the zypper log in see that the kernel:
Old = 5.1.15-1.1
New = 5.1.16-1.2

libdrm-nouveau2 
Old: 2.4.98-1.3 (installed on 2019-06-17) ==> no probelm
New: 2.4.99-1.1  ==> problem is present 

I never did a bisect. I'll try to find some info about this but no sure if I can do it.

Regards
Philippe

Perhaps I don't quite understand the issue then, but display modesets are controlled by the kernel. The error you're seeing is with link training. So it seems likely that a kernel update is responsible.

Could also be a userspace update which makes use of the kernel differently, triggering a pre-existing bug. libdrm_nouveau/mesa and such are not at all involved in this though -- that's just for 2d/3d accelerated rendering.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1186.