Bug 72952

Created attachment 91095 [details]
dmesg.log when booting with drm.debug=4

I believe the core part is:
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:17:DVI-D-1]
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:17:DVI-D-1] disconnected
without any error message.

Each time I plug or unplug the HDMI cable, I get this log:
[drm:drm_helper_hpd_irq_event], [CONNECTOR:17:DVI-D-1] status updated from disconnected to disconnected
[drm:drm_helper_hpd_irq_event], [CONNECTOR:19:DVI-D-2] status updated from disconnected to disconnected

Created attachment 91099 [details]
xrandr --verbose output with 1280x1024 external monitor

Something crazy: I put the machine into suspend mode, then resumed.
Voilà, both DVI-D-1+2 are reported connected.

However, applying
xrandr --output DVI-D-1 --auto
causes the laptop's screen to turn black with still no signal on the HDMI plug. From there, all I could to was switch the machine off.

Turning VGA-1 on or using variations such as
xrandr --verbose --output DVI-D-1 --same-as LVDS-1
xrandr --verbose --output DVI-D-1 --auto
xrandr: cannot find crtc for output DVI-D-1
xrandr --verbose --output DVI-D-2 --auto
xrandr: cannot find crtc for output DVI-D-2
avoided the black screen but never got a signal out of HDMI.

Yesterday, I had avoided suspend mode, because the colors went wrong after resume. However, they turned normal after Ctrl-Alt-F1 -> F7.

Created attachment 91105 [details]
dmesg.log when booting with drm.debug=4, incl. suspend/resume cycle

Perhaps a dmesg.log including a suspend/resume cycle is more revealing?
I'm not sure whether I was entirely clear. I never observed a HDMI signal on the monitor, but the weird behaviour at resume proves that at least the EDID signals transit through the cable, some time. Perhaps that's 2 bugs?
 - No immediate EDID at boot time;
 - no HDMI out, even past resume where EDID happened

No HDMI either when booting Ubuntu 13.04 on the same machine from a live DVD.

Alas, using the live DVD, I couldn't check the behaviour described in comment #2 past a suspend&resume cycle, because the machine hung shortly after resume.

I think this issue might be the same one as bug #60680. Can you try the patch at https://bugs.freedesktop.org/attachment.cgi?id=92319 and see if it helps? If it doesn't, can you upload your vbios (/sys/kernel/debug/dri/0/vbios.rom) as well as a dmesg booting with nouveau.debug=VBIOS=trace,PDISP=debug -- that might show some clues.

Erm, sorry, that patch link was wrong. Can you give drm-next a shot? (Or try 3.14-rc1 when that comes out?)

I'm sure you meant attachment #92185 [details] [review] not the log file, but I'm sorry I've never recompiled a kernel or driver yet, despite decades of UNIX. One thing that worked well in the past with the Intel driver was when Keith put an intel_drv.so online for us users to try out. Is your nouveau_drv.so online (for SuSE 13.1/64) somewhere?

(In reply to comment #7)
> I'm sure you meant attachment #92185 [details] [review] [review] not the log file,

Indeed. Although a different approach was finally merged, that the original bug reporter (and several others with the same issue) confirmed also fixed the problem.

> but I'm sorry I've never recompiled a kernel or driver yet, despite decades
> of UNIX. One thing that worked well in the past with the Intel driver was
> when Keith put an intel_drv.so online for us users to try out. Is your
> nouveau_drv.so online (for SuSE 13.1/64) somewhere?

Unfortunately this is for a kernel module. If I were really clever, I could figure out exactly how your kernel was built (and exactly what version), which compiler, which settings, etc, and build a module that worked for you. But I'm not that clever, or perhaps too lazy -- take your pick. Here's a guide for building your own kernel on SUSE:

https://www.suse.com/communities/conversations/compiling-de-linux-kernel-suse-way/

I have no clue whether these instructions are in the least valid. You can also just wait for 3.14-rc1 to come out and perhaps a fresh kernel will be installable from

http://en.opensuse.org/openSUSE:Kernel_of_the_day

(These are all things I found with a quick Google search -- I have no knowledge of SUSE beyond the fact that its auto-configurer tool... YaST iirc... that overwrote all of my careful config modifications wildly annoyed me back in ~1999 or so and I decided to never touch it again.)

-- 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/xorg/driver/xf86-video-nouveau/issues/80.