I recently upgraded my main workstation to Fedora 16 (x86-64). I have two Dell 2001FP monitors, one connected via DVI-D and one via an HDMI-to-DVI cable. My previous setup was using Fedora 14 with the proprietary nVidia drivers, and that drove both monitors correctly. I also occasionally dual-boot into Windows 7, and both monitors work correctly there as well. With Fedora 16 and the nouveau drivers, the second monitor (on HDMI) seems to be recognized but it never "wakes up". If I disconnect the first monitor, so that the HDMI-driven monitor is the only one on the system, it successfully shows the motherboard boot-time splash graphic, the BIOS POST, and GRUB menu; as soon as the linux boot gets past "initializing ramdisk" (or something like that), the monitor goes to sleep. From these experiments and some hints on the #nouveau channel, it would appear that the kernel nouveau bits are somehow not activating the HDMI output correctly. I did try the 3.2-rc6 kernel from Fedora Rawhide / Koji, and it didn't help this issue. Any other hints would be welcome, and I'm also happy to try to collect more data. I'll be attaching some log files in a moment. Here is the xrandr output: $ DISPLAY=:0.0 xrandr --props Screen 0: minimum 320 x 200, current 3200 x 1200, maximum 8192 x 8192 DVI-I-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm EDID: 00ffffffffffff0010ac08a04c305231 310e010380291f78ee6390a3574b9b25 115054a54b008180a940714f01010101 010101010101483f403062b0324040c0 13006f131100001e000000ff00433036 34363443313152304c20000000fc0044 454c4c203230303146500a20000000fd 00384c1f5010000a202020202020003f dithering: Off supported: Off On Automatic scaling mode: Full supported: None Full Center Full aspect select subconnector: Automatic supported: Automatic DVI-D DVI-A subconnector: DVI-D supported: Unknown DVI-D DVI-A 1600x1200 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 VGA-1 disconnected (normal left inverted right x axis y axis) scaling mode: None supported: None Full Center Full aspect HDMI-1 connected 1600x1200+1600+0 (normal left inverted right x axis y axis) 367mm x 275mm EDID: 00ffffffffffff0010ac08a04c415434 230f010380291f78ee6390a3574b9b25 115054a54b008180a940714f01010101 010101010101483f403062b0324040c0 13006f131100001e000000ff00433036 343635384f3454414c20000000fc0044 454c4c203230303146500a20000000fd 00384c1f5010000a202020202020000c dithering: Off supported: Off On Automatic scaling mode: Full supported: None Full Center Full aspect 1600x1200 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1
Created attachment 54551 [details] logs from boot to root login prompt As mentioned in bug 692035, it can be handy to have extra logging output. This is result of "drm.debug=14" from initial boot until root login prompt.
Created attachment 54552 [details] log from boot to x11 login window This includes the boot-to-root-login log, but also has the logs as I started X.
Created attachment 54553 [details] x server log output
One last data point: both monitors work fine with the proprietary drivers under F16 as well, so the hardware is working correctly. I was really hoping that this is just a trivial bug, but since I do need the second screen, I'll be using the proprietary drivers for now. I'll be happy to test changes (especially if they end up in the fedora update stream; a full custom kernel is a bit more work/research). Thanks!
Can you confirm whether this is still an issue with a more recent kernel (e.g. 3.10)? All the output stuff has gotten quite a bit of rework in the past 2 years.
(In reply to comment #5) > Can you confirm whether this is still an issue with a more recent kernel > (e.g. 3.10)? All the output stuff has gotten quite a bit of rework in the > past 2 years. Sorry it took me a few days, but I can confirm that the problem is still occurring on a fully up-to-date Fedora 18 system. GRUB is visible, but X never comes up. Nothing obvious in the Xorg log. Testing might be slightly complicated by the fact that the only DVI monitor I have available for testing is now a 2560x1440, so the single-link constraint might confusing things -- but the behavior seems to be exactly the same as before, and xorg / nouveau certainly seem to think they found the workable max resolution of 1920x1200. As before, grub still works (displays graphics correctly), so the physical connection seems functional if not optimal. $ uname -a Linux hum.int.foiani.com 3.10.9-100.fc18.x86_64 #1 SMP Wed Aug 21 18:25:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ]$ rpm -qa | egrep -i '(xorg|nouveau)' xorg-x11-drv-vesa-2.3.2-2.fc18.x86_64 xorg-x11-xinit-1.3.2-7.fc18.x86_64 xorg-x11-proto-devel-7.6-24.fc18.noarch xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc18.x86_64 xorg-x11-drv-vmmouse-13.0.0-1.fc18.x86_64 xorg-x11-server-utils-7.5-16.fc18.x86_64 xorg-x11-server-common-1.13.3-3.fc18.x86_64 xorg-x11-fonts-Type1-7.5-6.fc18.noarch xorg-x11-drv-mga-1.6.2-6.fc18.x86_64 xorg-x11-drv-qxl-0.1.0-2.fc18.x86_64 xorg-x11-xkb-utils-7.7-5.fc18.x86_64 xorg-x11-fonts-ISO8859-1-75dpi-7.5-6.fc18.noarch xorg-x11-drv-intel-2.21.12-1.fc18.x86_64 xorg-x11-drv-modesetting-0.6.0-1.fc18.x86_64 xorg-x11-font-utils-7.5-11.fc18.x86_64 xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc18.x86_64 xorg-x11-xauth-1.0.7-2.fc18.x86_64 xorg-x11-drv-vmware-12.0.2-3.20120718gite5ac80d8f.fc18.x86_64 xorg-x11-server-Xorg-1.13.3-3.fc18.x86_64 xorg-x11-drv-fbdev-0.4.3-3.fc18.x86_64 abrt-addon-xorg-2.1.6-3.fc18.x86_64 xorg-x11-utils-7.5-7.fc18.x86_64 xorg-x11-drv-evdev-2.7.3-5.fc18.x86_64 xorg-x11-drv-wacom-0.16.1-2.fc18.x86_64 xorg-x11-fonts-ISO8859-1-100dpi-7.5-6.fc18.noarch xorg-x11-drv-openchrome-0.3.3-1.fc18.x86_64 xorg-x11-drv-synaptics-1.6.4-2.fc18.x86_64 xorg-x11-drv-nouveau-1.0.7-1.fc18.x86_64 $ dmesg | grep -i nouveau [ 1.693009] fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver [ 1.693418] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x096200a1 [ 1.693420] nouveau [ DEVICE][0000:01:00.0] Chipset: G96 (NV96) [ 1.693422] nouveau [ DEVICE][0000:01:00.0] Family : NV50 [ 1.695771] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... [ 1.739080] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid [ 1.739082] nouveau [ VBIOS][0000:01:00.0] using image from PRAMIN [ 1.739162] nouveau [ VBIOS][0000:01:00.0] BIT signature found [ 1.739164] nouveau [ VBIOS][0000:01:00.0] version 62.94.6c.00.36 [ 1.759335] nouveau [ PFB][0000:01:00.0] RAM type: DDR2 [ 1.759338] nouveau [ PFB][0000:01:00.0] RAM size: 512 MiB [ 1.759340] nouveau [ PFB][0000:01:00.0] ZCOMP: 2048 tags [ 1.783396] nouveau [ PTHERM][0000:01:00.0] FAN control: PWM [ 1.783401] nouveau [ PTHERM][0000:01:00.0] fan management: disabled [ 1.783403] nouveau [ PTHERM][0000:01:00.0] internal sensor: yes [ 1.783511] nouveau [ DRM] VRAM: 512 MiB [ 1.783512] nouveau [ DRM] GART: 512 MiB [ 1.783515] nouveau [ DRM] TMDS table version 2.0 [ 1.783516] nouveau [ DRM] DCB version 4.0 [ 1.783517] nouveau [ DRM] DCB outp 00: 02000300 00000028 [ 1.783518] nouveau [ DRM] DCB outp 01: 01000302 00000030 [ 1.783519] nouveau [ DRM] DCB outp 02: 04011310 00000028 [ 1.783520] nouveau [ DRM] DCB outp 03: 02022332 00020010 [ 1.783521] nouveau [ DRM] DCB conn 00: 00001030 [ 1.783522] nouveau [ DRM] DCB conn 01: 00000100 [ 1.783523] nouveau [ DRM] DCB conn 02: 00002261 [ 1.794622] nouveau [ DRM] vid bit 0 has no gpio tag [ 1.794674] nouveau [ DRM] 1 available performance level(s) [ 1.794676] nouveau [ DRM] 3: core 550MHz shader 1400MHz memory 504MHz fanspeed 100% [ 1.794678] nouveau [ DRM] c: core 400MHz shader 800MHz memory 504MHz fanspeed 74% [ 2.057446] nouveau [ DRM] MM: using CRYPT for buffer copies [ 2.107519] nouveau [ DRM] native mode from largest: 1920x1200@60 [ 2.113734] nouveau [ DRM] allocated 1920x1200 fb: 0x70000, bo ffff880418695400 [ 2.113844] fbcon: nouveaufb (fb0) is primary device [ 2.172776] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device [ 2.172777] nouveau 0000:01:00.0: registered panic notifier [ 2.172779] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on minor 0 [ 2.257660] nouveau [ DRM] native mode from largest: 1920x1200@60 [ 9.173797] nouveau [ DRM] native mode from largest: 1920x1200@60 [ 9.246641] nouveau [ DRM] native mode from largest: 1920x1200@60 [ 9.526051] nouveau [ DRM] native mode from largest: 1920x1200@60 [ 9.934743] nouveau [ DRM] native mode from largest: 1920x1200@60 [ 9.963585] nouveau [ DRM] native mode from largest: 1920x1200@60 # DISPLAY=:0.0 XAUTHORITY=/var/run/gdm/auth-for-gdm-ytYnCs/database xrandr --props Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 8192 x 8192 DVI-I-1 disconnected (normal left inverted right x axis y axis) dithering depth: auto supported: auto6 bpc8 bpc dithering mode: auto supported: autooffstatic 2x2dynamic 2x2 scaling mode: Full supported: NoneFullCenterFull aspect color vibrance: 150 range: (0, 200) vibrant hue: 90 range: (0, 180) underscan vborder: 0 range: (0, 128) underscan hborder: 0 range: (0, 128) underscan: off supported: autooffon subconnector: Unknown supported: UnknownDVI-DDVI-A VGA-1 disconnected (normal left inverted right x axis y axis) scaling mode: None supported: NoneFullCenterFull aspect color vibrance: 150 range: (0, 200) vibrant hue: 90 range: (0, 180) HDMI-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 597mm x 336mm EDID: 00ffffffffffff0010ac7e404c363331 2a160103803c2278ea4bb5a7564ba325 0a5054a54b008100b300d100714fa940 8180d1c00101565e00a0a0a029503020 350055502100001a000000ff00474b30 4b443241493133364c0a000000fc0044 454c4c205532373133484d0a000000fd 0031561d711c000a20202020202000ce dithering depth: auto supported: auto6 bpc8 bpc dithering mode: auto supported: autooffstatic 2x2dynamic 2x2 scaling mode: Full supported: NoneFullCenterFull aspect color vibrance: 150 range: (0, 200) vibrant hue: 90 range: (0, 180) underscan vborder: 0 range: (0, 128) underscan hborder: 0 range: (0, 128) underscan: off supported: autooffon 1920x1200 60.0 1600x1200 60.0* 1680x1050 59.9 1280x1024 75.0 60.0 1280x800 59.9 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1
Would you mind trying 3.11-rc6, or apply http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=9a7046d55f319b2dde5d2536cc2adb01ebdbe09e to your kernel? I'm not 100% sure it'll fix things, but it's definitely worth a shot. I can't quite tell if your DCB types would have gotten messed up by this test or not.
(In reply to comment #7) > Would you mind trying 3.11-rc6, or apply > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/ > ?id=9a7046d55f319b2dde5d2536cc2adb01ebdbe09e to your kernel? I'm not 100% > sure it'll fix things, but it's definitely worth a shot. I can't quite tell > if your DCB types would have gotten messed up by this test or not. Well, I tried to... but some combination of UEFI and/or Fedora weirdness is keeping me from booting all the way into 3.11-rc6. I'm downloading the rawhide (f20branch) live media right now, will see if I can boot all the way with it. On the plus side, I did see an error screen with graphical tuxes, and the error was some 2s into the boot. So it's possible that things are working on the nouveau side, and it's just getting confused by Fedora. Ok, live media downloaded, time for a reboot.
(In reply to comment #8) > I'm downloading the rawhide (f20branch) live media right now, will see if I > can boot all the way with it. ... > Ok, live media downloaded, time for a reboot. No luck with the live media. I'm using this build of Fedora 20: http://koji.fedoraproject.org/koji/taskinfo?taskID=5846747 And unfortunately it looks like that includes rc6: kernel-3.11.0-0.rc6.git2.1.fc20.x86_64.rpm To be clear, "no luck" means same basic failure: no live screen with HDMI connection, live screen with dual-link DVI connection. Even with DVI, this particular live media failed to boot all the way into X, but I did get the graphical boot logo at full resolution, and the text console was rendered at full resolution as well. At this point, I'll have to let it go for a while; that card is in my main workstation, and I can't afford to do too many experiments with it. If the current logs still don't give any clues, I might be able to move this card to an older box for testing, but I'll have to put a new card in my workstation first. Sorry I don't have anything more definite for you.
With a bit of luck, this is similar to bug #60680, which will hopefully be bisected soon. By the way, are you connecting to your monitor's HDMI input, or is there a HDMI->DVI adapter in there?
(In reply to comment #10) > With a bit of luck, this is similar to bug #60680, which will hopefully be > bisected soon. Hopefully! > By the way, are you connecting to your monitor's HDMI input, or is there a > HDMI->DVI adapter in there? All the failures are with HDMI-to-DVI adapters of various sorts. (Originally it was a HDMI-to-DVI cable; I seem to have misplaced that cable, so at the moment I'm using HDMI-to-HDMI + adapter + DVI-to-KVM + KVM-to-DVI ... Which is a mess, but since the BIOS / UEFI and grub all seem to work with it, it still looks like xorg / nouveau is doing something odd. Thanks!
Oh, I'm in no way trying to lay the blame away from nouveau :) Just getting the facts straight. I assume this is just an adapter (i.e. round hole/square peg), not a converter. In this case, the card would actually drive the port as a DVI port that just happens to be using a HDMI cable. Which actually makes the problem more likely to be unrelated to the one in the other bug. For completeness, could you upload your vbios (/sys/kernel/debug/dri/0/vbios.rom)?
(In reply to comment #12) > Oh, I'm in no way trying to lay the blame away from nouveau :) Heh. Didn't mean to imply that you were. Mostly I was convincing myself about whether I need another hour or two of swapping cables to try HDMI-to-HDMI connection on same card, in case there's something intrinsically flakey with this card. (It's actually the GS variant, which was OEM'd to HP at the time?) > Just getting > the facts straight. I assume this is just an adapter (i.e. round hole/square > peg), not a converter. In this case, the card would actually drive the port > as a DVI port that just happens to be using a HDMI cable. Which actually > makes the problem more likely to be unrelated to the one in the other bug. Yes, these are all pin-to-pin adapters. (I had to check, because I'm involved with a *different* bug that affects active DisplayPort to dual-link DVI converters -- but that's on a different machine, a little ultra small form factor that only has displayport output from the intel gfx core.) > For completeness, could you upload your vbios > (/sys/kernel/debug/dri/0/vbios.rom)? Will do so. Thanks!
Created attachment 84580 [details] vbios.rom file as requested
I have the same issue. My dual-head setup works very well with 3.5.0 but stopped working when I switched to 3.8.0. I also tried 3.10.0 but the problem persists. I have the same symptom: second monitor does not even turn on, it does not receive any signal, but xrandr and X thinks everything is working correctly (dual-head setup). I am running Kubuntu 13.04.
(In reply to comment #15) > I have the same issue. My dual-head setup works very well with 3.5.0 but > stopped working when I switched to 3.8.0. I also tried 3.10.0 but the > problem persists. > > I have the same symptom: second monitor does not even turn on, it does not > receive any signal, but xrandr and X thinks everything is working correctly > (dual-head setup). > > I am running Kubuntu 13.04. I forgot to add that I have a "NVIDIA NV96" Chipset as per Xorg.0.log.
I was thinking about adding a bug, but i found this. Looks like i could have a small clue or it is just in my case. I have standard HDMI cable, and my screen is black after grub, but monitor have signal all the time. I found that i need to force monitor to check again for signal settings, aka change zoom in/hdmi overscan (in monitor device settings using pilot/buttons on it) or something simular and then all shows up. After every restart or changing monitor input from hdmi to other and again to hdmi it brakes again. I wasn't sure if that wasn't my monitor problem but this bug looks same and its about hdmi output signal. Every log dmesg/xorg/others does not show any problems also. Changing resolution or other settings with xrandr does not affect information showed by monitor info section (all time shows full hd@60Hz) even if xrandr says its set to other. I got: 3.11.5 kernel (same on 3.11.6) xorg 1.14.3 (same on live trunk from today) nouveau 1.0.9 (same on live trunk from today) Hardware: GFX 950 TI Boost aka NVE6
Can you try drm-next? A patch fixing bug #60680 should be there (http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=f87cd8b695d372087685976460fac1ec6ba2fca9) and may resolve your issues as well.
No response in over 6 months, but this reads a lot like the issue I fixed that manifested itself as NV96 HDMI not working (and only that chipset for some reason, even though the issue was affecting the whole nv50 family). Should work fine with recent kernels (3.14+). Feel free to reopen if that's not the case.
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.