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
Created attachment 107398 [details] kernel log with nouveau.debug=trace
Created attachment 107399 [details] kernel log with drm.debug=0xe
Created attachment 107400 [details] vbios from /sys/kernel/debug/dri/0/vbios.rom
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?
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...
Created attachment 107499 [details] LiveCD kernel log with nouveau.debug=trace and drm.debug=0xe
Created attachment 107500 [details] LiveCD vbios from /sys/kernel/debug/dri/0/vbios.rom
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.
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?
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.)
Created attachment 108859 [details] kernel log with nouveau.debug=trace and drm.debug=0xe Recompiled kernel 3.17.1 without vesa/uvesa
Created attachment 108860 [details] Xorg log
Created attachment 108861 [details] xrandr output
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?
(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.
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
(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.
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.
-- 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/135.
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.