Bug 84706 - [NV94] HDMI Connected, but TV reports "no signal"
Summary: [NV94] HDMI Connected, but TV reports "no signal"
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-06 08:04 UTC by Jay van Dam
Modified: 2014-11-05 22:09 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
kernel log with nouveau.debug=trace and drm.debug=0xe (347.34 KB, text/plain)
2014-10-06 08:04 UTC, Jay van Dam
no flags Details
kernel log with nouveau.debug=trace (321.17 KB, text/plain)
2014-10-06 08:05 UTC, Jay van Dam
no flags Details
kernel log with drm.debug=0xe (80.87 KB, text/plain)
2014-10-06 08:05 UTC, Jay van Dam
no flags Details
vbios from /sys/kernel/debug/dri/0/vbios.rom (62.50 KB, application/octet-stream)
2014-10-06 08:05 UTC, Jay van Dam
no flags Details
LiveCD kernel log with nouveau.debug=trace and drm.debug=0xe (340.27 KB, text/plain)
2014-10-07 14:28 UTC, Jay van Dam
no flags Details
LiveCD vbios from /sys/kernel/debug/dri/0/vbios.rom (62.50 KB, application/octet-stream)
2014-10-07 14:31 UTC, Jay van Dam
no flags Details
kernel log with nouveau.debug=trace and drm.debug=0xe (390.47 KB, text/plain)
2014-11-03 20:44 UTC, Jay van Dam
no flags Details
Xorg log (78.59 KB, text/plain)
2014-11-03 20:47 UTC, Jay van Dam
no flags Details
xrandr output (1.19 KB, text/plain)
2014-11-03 20:47 UTC, Jay van Dam
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jay van Dam 2014-10-06 08:04:28 UTC
Created attachment 107397 [details]
kernel log with nouveau.debug=trace and drm.debug=0xe

Hardware information: 
CPU: Intel Core2 Quad Q9400 
Graphics card: GeForce 9600 GS (output: 1x VGA, 1x DVI, 1x HDMI)

Version information
Distro: ArchLinux x86_64
Linux Kernel: 3.16.3 (compiled with CONFIG_DRM_NOUVEAU=m)
libdrm: 2.4.58
Mesa: 10.3.0
xf86-video-nouveau: 1.0.11

Issue: 
TV connected via HDMI reports "no signal" when system is booted. During boot the HDMI display output works fine, but when selecting the kernel to load in the bootloader the TV starts reporting "no signal". As the output is already lost before any X

What I tried so far:
- Booting with HDMI cable connected
- Booting with HDMI and VGA cable connected
- Booting with no cables connected, following hotplugging HDMI and VGA
None of above actions resulted in a fix or any other results with the display via the HDMI port, the display of the VGA port always is functional.  

Other findings:
- The NVIDIA proprietary drivers HDMI display output works fine with the TV
- Graphics card is GeForce 9600 GS, according to the CodeNames this should be a NV96 (G96), though when quering the system it reports as G94. This seems to be conflicting. 05:00.0 VGA compatible controller: NVIDIA Corporation G94 [GeForce 9600 GS] (rev a1)
- While having the HDMI and VGA connected, querying the status of all ports report that the HDMI and the VGA are connected::
-- ~: for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
-- DVI-I-1: disconnected
-- HDMI-A-1: connected
-- VGA-1: connected

Similar bugs:
60680 - Same issue (bug marked RESOLVED FIXED)
63139 - Same issue (bug marked RESOLVED INVALID) due to missing response bug reporter
Comment 1 Jay van Dam 2014-10-06 08:05:02 UTC
Created attachment 107398 [details]
kernel log with nouveau.debug=trace
Comment 2 Jay van Dam 2014-10-06 08:05:32 UTC
Created attachment 107399 [details]
kernel log with drm.debug=0xe
Comment 3 Jay van Dam 2014-10-06 08:05:58 UTC
Created attachment 107400 [details]
vbios from /sys/kernel/debug/dri/0/vbios.rom
Comment 4 Ilia Mirkin 2014-10-06 12:25:30 UTC
Marketing names, like "GT 9600" are fairly meaningless. The same names map to a bunch of different chips. The CodeNames page tries to address this a little bit, but comes short. You have a G94 :)

Two things:

(a) Does this magically start working on 3.17? I think it has a few changes which could potentially impact this.
(b) Did this ever work on nouveau? If you don't know, mind checking some old kernels? For example, 3.7 would be good to try. Failing that, maybe 3.2?
Comment 5 Jay van Dam 2014-10-07 14:27:38 UTC
Thank you for explaining about the different chips and pointing out I do have a G94, always the marketing scams... :) 

I tried kernel 3.17, 3.7 and 3.2 but none of them showed any different behavior, all the time the tv shows “no signal”.

As I am using BTRFS as my primary filesystem and kernel 3.2 isn’t working with the latest version of BTRFS, on a separate disk I reinstalled my system with an EXT4 filesystem to try the 3.2 kernel.

The installation of Arch Linux works with a Live CD, I inserted the CD wired up the HDMI port and start installing. Half way the installation I actually realized I was using the HDMI port and the display was still working properly after the bootloader screen. Out of curiousity I checked what graphics driver was loaded and it was in fact the nouveau driver. I've added the kernel log and vbios from the live CD, it couldn't find any differences thought...
Comment 6 Jay van Dam 2014-10-07 14:28:12 UTC
Created attachment 107499 [details]
LiveCD kernel log with nouveau.debug=trace and drm.debug=0xe
Comment 7 Jay van Dam 2014-10-07 14:31:19 UTC
Created attachment 107500 [details]
LiveCD vbios from /sys/kernel/debug/dri/0/vbios.rom
Comment 8 Jay van Dam 2014-10-08 11:30:57 UTC
Just went through both the logs of the LiveCD and normal system and I found the following: 

Normal system kernel log with nouveau.debug=trace and drm.debug=0xe 
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.268401] vesafb: mode is 640x480x32, linelength=2560, pages=0
[    0.268402] vesafb: scrolling: redraw
[    0.268404] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.268418] vesafb: framebuffer at 0xfb000000, mapped to 0xffffc90010e80000, using 1216k, total 1216k
[    0.275997] Console: switching to colour frame buffer device 80x30
[    0.283477] fb0: VESA VGA frame buffer device
[    0.308418] fb: switching to nouveaufb from VESA VGA
[    0.308438] Console: switching to colour dummy device 80x25
[    0.818241] fbcon: nouveaufb (fb0) is primary device
[    0.903002] Console: switching to colour frame buffer device 240x67
[    0.904713] nouveau 0000:05:00.0: fb0: nouveaufb frame buffer device

LiveCD kernel log with nouveau.debug=trace and drm.debug=0xe 
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    2.977742] fbcon: nouveaufb (fb0) is primary device
[    3.048489] Console: switching to colour frame buffer device 240x67
[    3.050679] nouveau 0000:05:00.0: fb0: nouveaufb frame buffer device

Could it be that the kernel framebuffer driver hand-over is not working properly. The handover completes without errors according to the logs, but it seems that only the VGA display output continues to work after handover and the HDMI display output becomes faulty over the hand-over.
Comment 9 Jay van Dam 2014-10-24 12:31:54 UTC
Next to loading old kernels and verify if the problem exists there too (which is the case), is there anything I can do to identify the cause of this problem or assist in identifying the cause of the problem?
Comment 10 Ilia Mirkin 2014-10-24 16:00:20 UTC
Just noticed this:

[    0.269025] vesafb: mode is 640x480x32, linelength=2560, pages=0
[    0.284092] fb0: VESA VGA frame buffer device

Please get rid of all that stuff from your kernel... it can't possibly be helping. (And is, in all likelihood, hurting.)
Comment 11 Jay van Dam 2014-11-03 20:44:52 UTC
Created attachment 108859 [details]
kernel log with nouveau.debug=trace and drm.debug=0xe

Recompiled kernel 3.17.1 without vesa/uvesa
Comment 12 Jay van Dam 2014-11-03 20:47:13 UTC
Created attachment 108860 [details]
Xorg log
Comment 13 Jay van Dam 2014-11-03 20:47:35 UTC
Created attachment 108861 [details]
xrandr output
Comment 14 Jay van Dam 2014-11-03 20:49:32 UTC
Recompiled the kernel without vesa and uvesa, but it does not make a difference.  Added the new kernel log with nouveau.debug=trace and drm.debug=0xe. Also added the Xorg.log and the xrandr output. 

When I went through the kernel log I saw the following lines passing by:
[    0.385140] nouveau D[  DEVICE][0000:05:00.0][0x80000080][ffff880222262600] illegal class 0x9470
[    0.385151] nouveau D[  DEVICE][0000:05:00.0][0x80000080][ffff880222262600] handle 0xd1500000 not found


[    0.392674] nouveau D[   PDISP][0000:05:00.0][0x80008870][ffff8800cb36a120] illegal class 0x947d

[    0.392686] nouveau D[   PDISP][0000:05:00.0][0x80008870][ffff8800cb36a120] handle 0x947d0000 not found

[    0.654992] nouveau D[   PFIFO][0000:05:00.0][0xc000826f][ffff880222d533c0] illegal class 0xa0b5
[    0.655005] nouveau D[   PFIFO][0000:05:00.0][0xc000826f][ffff880222d533c0] handle 0x0000a0b5 not found

The messages "illegal class" and "handle not found" do not seem right. Could this be related?
Comment 15 Ilia Mirkin 2014-11-03 22:29:26 UTC
(In reply to Jay van Dam from comment #14)
> Recompiled the kernel without vesa and uvesa, but it does not make a
> difference.  Added the new kernel log with nouveau.debug=trace and
> drm.debug=0xe. Also added the Xorg.log and the xrandr output. 

Well that's unfortunate. The things you pointed out are actually expected and fine.

The only thing that seems reminscient of a similar issue a bunch of G96's had is with

[    0.848281] nouveau T[   VBIOS][0000:05:00.0] 0xb87a[2]: CONDITION	0x0f
[    0.848283] nouveau T[   VBIOS][0000:05:00.0] 0xb87c[2]: 	[0x0f] (R[0x000008] & 0x000000f0) == 0x00000010
[    0.848285] nouveau T[   VBIOS][0000:05:00.0] 0xb87c[ ]: NOT
[    0.848286] nouveau T[   VBIOS][0000:05:00.0] 0xb87d[2]: IO_CONDITION	0x05
[    0.848288] nouveau T[   VBIOS][0000:05:00.0] 0xb87f[2]: 	[0x05] (0x03d4[0x94] & 0x80) == 0x80
[    0.848292] nouveau T[   VBIOS][0000:05:00.0] 0xb87f[ ]: SUB_DIRECT	0xb8e1
[    0.848293] nouveau T[   VBIOS][0000:05:00.0] 0xb882[ ]: RESUME
[    0.848294] nouveau T[   VBIOS][0000:05:00.0] 0xb883[2]: DONE
[    0.848295] nouveau T[   VBIOS][0000:05:00.0] 0xb7f2[1]: DONE
[    0.848296] nouveau T[   VBIOS][0000:05:00.0] 0xc0c8[0]: DONE
[    0.848541] nouveau D[   PDISP][0000:05:00.0] supervisor 0x00000040 0x00000550
[    0.848555] nouveau T[   VBIOS][0000:05:00.0] 0xb884[0]: CONDITION	0x0f
[    0.848557] nouveau T[   VBIOS][0000:05:00.0] 0xb886[0]: 	[0x0f] (R[0x000008] & 0x000000f0) == 0x00000010
[    0.848560] nouveau T[   VBIOS][0000:05:00.0] 0xb886[ ]: SUB_DIRECT	0xb95c
[    0.848561] nouveau T[   VBIOS][0000:05:00.0] 0xb889[ ]: SUB_DIRECT	0xb961
[    0.848563] nouveau T[   VBIOS][0000:05:00.0] 0xb88c[ ]: NOT
[    0.848564] nouveau T[   VBIOS][0000:05:00.0] 0xb88d[0]: IO_CONDITION	0x05
[    0.848566] nouveau T[   VBIOS][0000:05:00.0] 0xb88f[0]: 	[0x05] (0x03d4[0x94] & 0x80) == 0x80
[    0.848569] nouveau T[   VBIOS][0000:05:00.0] 0xb88f[ ]: SUB_DIRECT	0xb905
[    0.848570] nouveau T[   VBIOS][0000:05:00.0] 0xb892[ ]: RESUME
[    0.848571] nouveau T[   VBIOS][0000:05:00.0] 0xb893[0]: DONE
[    0.881790] [drm:drm_crtc_helper_set_config] Setting connector DPMS state to on
[    0.881791] [drm:drm_crtc_helper_set_config] 	[CONNECTOR:24:HDMI-A-1] set DPMS on

That IO_CONDITION looks oddly familiar. I wonder if we're not evaluating it somehow incorrectly... again. But... we fixed the thing for G96 and it worked fine there (and it also worked fine in 3.7 or 3.6, the issue was a regression there).

Next step is to make an mmiotrace of the blob drivers doing this correctly and comparing. This is a pretty good guide: https://wiki.ubuntu.com/X/MMIOTracing . Send a xz -9'd trace (should be ~50MB before compression) and also your vbios for good measure to mmio.dumps@gmail.com referencing this bug, and make a note here that you've made such a trace. It would be ideal if the trace were started without HDMI plugged in, and then you emitted a mark, plugged in hdmi, and emitted another mark.

The only odd thing about your card is that you have 768MB of VRAM which I'm sure means some sort of weird partition-based layout. But I can't see how that'd affect HDMI setup.
Comment 16 Jay van Dam 2014-11-05 21:54:17 UTC
Just made the trace and about to collect the current vbios from /sys/kernel/debug/dri/0/vbios.rom but there's no such file in the /sys/kernel/debug/dri/0/ directory. Do you want me to include the vbios from when running the nouveau driver as attached to this bug report?

The card I have does indeed have 768MB of VRAM see: http://www.vgamuseum.info/index.php/component/content/article/1249-nvidia-geforce-9600-gs
Comment 17 Ilia Mirkin 2014-11-05 21:55:28 UTC
(In reply to Jay van Dam from comment #16)
> Just made the trace and about to collect the current vbios from
> /sys/kernel/debug/dri/0/vbios.rom but there's no such file in the
> /sys/kernel/debug/dri/0/ directory. Do you want me to include the vbios from
> when running the nouveau driver as attached to this bug report?

Yes, the same file that's already attached. It's small, and having it be along with the trace makes it more likely that it will get noticed.
Comment 18 Jay van Dam 2014-11-05 22:09:42 UTC
Mail is send to mmio.dumps@gmail.com with the MMIO dump. Please let me know if it is correct or when you need more dumps.


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.