Bug 111110 - Nvidia quadro + nouveau : second terminal wake up but doesn't more display
Summary: Nvidia quadro + nouveau : second terminal wake up but doesn't more display
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: 19.1
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-11 14:49 UTC by Philippe Condé
Modified: 2019-08-12 14:48 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
output of dmesg (80.13 KB, text/plain)
2019-07-11 14:49 UTC, Philippe Condé
Details
Xorg.0.log (48.37 KB, text/plain)
2019-08-11 14:38 UTC, Philippe Condé
Details
journalctl with debug (536.28 KB, text/plain)
2019-08-11 19:53 UTC, Philippe Condé
Details
dmesg output with debug (366.27 KB, text/plain)
2019-08-11 19:55 UTC, Philippe Condé
Details
Xorg.0.log with debug (48.40 KB, text/plain)
2019-08-11 19:57 UTC, Philippe Condé
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Condé 2019-07-11 14:49:30 UTC
Created attachment 144764 [details]
output of dmesg

I have a OpenSUSE tumbleweed system with a nvidia quadro K4200 on which 2 screens are connected 
- one on the DVI port
- the second on the display port 1 (DP1)
the two screens use resolution 1920*1080 and are defined as a  virtual screen of 3480*1080.
I use nouveau as driver; DE is KDE

This worked form years without problem. After installation of snapshot 20190708 I rebooted and the second screen doesn't more display anything.

in journalctl I find this error
Jul 11 08:30:04 hpprol2 kernel: nouveau 0000:0a:00.0: disp: outp 03:0006:0f42: training failed

The second screens wake up on some action (boot, starting xorg, login etc...) but after some seconds display " Display port: no signal"

As requested by OpenSUSE support I installed the last kernel , Mesa et xf86-video-nouveau

rpm -qa Mesa*
Mesa-libGL1-19.1.2-977.1.x86_64
Mesa-KHR-devel-19.1.2-977.1.x86_64
Mesa-libGL-devel-19.1.2-977.1.x86_64
Mesa-gallium-32bit-19.1.2-977.1.x86_64
Mesa-libGL1-32bit-19.1.2-977.1.x86_64
Mesa-libGLESv2-2-19.1.1-223.1.x86_64
Mesa-libva-19.1.1-223.1.x86_64
Mesa-19.1.2-977.1.x86_64
Mesa-dri-19.1.2-977.1.x86_64
Mesa-libglapi0-19.1.1-223.1.x86_64
Mesa-libEGL1-19.1.2-977.1.x86_64
Mesa-gallium-19.1.2-977.1.x86_64
Mesa-demo-x-8.4.0-1.6.x86_64
Mesa-dri-nouveau-19.1.2-977.1.x86_64
Mesa-dri-32bit-19.1.2-977.1.x86_64
Mesa-libEGL1-32bit-19.1.1-223.1.x86_64
Mesa-32bit-19.1.2-977.1.x86_64
Mesa-libEGL-devel-19.1.2-977.1.x86_64
Mesa-libglapi0-32bit-19.1.1-223.1.x86_64

uname -a
Linux hpprol2 5.2.0-2.gfd43abf-default #1 SMP Thu Jul 11 05:19:05 UTC 2019 (fd43abf) x86_64 x86_64 x86_64 GNU/Linux

rpm -qa xf86-video-nouveau
xf86-video-nouveau-1.0.15-40.11.x86_64

The problem remains. I attach here the output of dmesg.

See also https://bugzilla.opensuse.org/show_bug.cgi?id=1141041

Regards
Philippe Condé
Comment 1 Philippe Condé 2019-07-25 06:36:08 UTC
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
Comment 2 Philippe Condé 2019-08-11 14:38:56 UTC
Created attachment 145022 [details]
Xorg.0.log
Comment 3 Philippe Condé 2019-08-11 14:40:46 UTC
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
Comment 4 Philippe Condé 2019-08-11 19:53:59 UTC
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
Comment 5 Philippe Condé 2019-08-11 19:55:21 UTC
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
Comment 6 Ilia Mirkin 2019-08-11 19:56:23 UTC
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.
Comment 7 Philippe Condé 2019-08-11 19:57:01 UTC
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
Comment 8 Philippe Condé 2019-08-12 08:39:24 UTC
(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
Comment 9 Ilia Mirkin 2019-08-12 14:48:22 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.