Forgot to mention I compiled kernel 2.36.1....

I mean 2.6.36.1... :)

(In reply to comment #0)
> I noticed in dmesg these lines;
> 
> [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:6]
> fbcon_init: detected unhandled fb_set_par error, error code -22
> [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:6]
> Console: switching to colour frame buffer device 90x36
> [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:6]
> fb0: nouveaufb frame buffer device
> drm: registered panic notifier
> 

Any chance you could run the nvidia binary driver in that box with no outputs connected and no output-related options in xorg.conf? (e.g. make sure you don't have "UseDisplayDevice" or "ConnectedMonitor" lines) Then can you ssh in from another machine and grab a register dump (running this program as root: http://cgit.freedesktop.org/~currojerez/tvdump/) and your Xorg log?

Sorry I only have time to just report this...

i have the same problem with the same motherboard. is the dump still needed? if yes, i might be able to find sometime to do that...

(In reply to comment #5)
> i have the same problem with the same motherboard. is the dump still needed? if
> yes, i might be able to find sometime to do that...

If you still have this problem with recent code, a dump would be highly appreciated. Thanks.

On a fresh F15.RC1 install, I can't get past the login screen due to this bug.

My dmesg output is the same as previously posted.

My motherboard:

dmidecode | grep -i 'Base Board Information' -A4 -B1
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
    Manufacturer: Hewlett-Packard
    Product Name: 0844
    Version: 123
    Serial Number: [omitted]

My graphics card:

lspci | grep 'VGA'
01:00.0 VGA compatible controller: nVidia Corporation NV18GL [Quadro4 380 XGL] (rev a2)

I am considering trying to remove the nouveau driver and replacing it with the proprietary driver. Is there an alternative to this?

(In reply to comment #7)
> On a fresh F15.RC1 install, I can't get past the login screen due to this bug.
> 
> My dmesg output is the same as previously posted.

[...]

> I am considering trying to remove the nouveau driver and replacing it with the
> proprietary driver. Is there an alternative to this?

Please upload dmesg with drm.debug=1 added to your kernel command line. This could help to narrow down the problem.

Created attachment 52967 [details]
dmesg with drm.debug=1 set

I have an HP Pavilion s7700n with GeForce 6150 LE.

I have a HP1730n, ALSO with a GeForce 6150 LE, which has the same problem. However if I specify the resolution manually on the kernel command (video=VGA-1:1280x1024) and X (Option "PreferredMode" "1280x1024"), this does not occur.

Created attachment 62407 [details]
dmesg, kernel 3.4.0 drm.debug=0x06

Here's a better dmesg, however instead of being CTRC 5 and 6; they are 9 and 10 (and so the error is "*ERROR* failed to set mode on [CRTC:10]"). CRTC:9 is the VGA output, and CRTC:10 is the TV output. However, this card (an NV4E - GeForce 6150 LE - integrated onto the motherboard) HAS no TV output (or a DVI output either, which is also detected). So CRTC:10 is connected to a phantom output. Curiously enough, the framebuffer has a physical resolution of CRTC:9 (the VGA), but a virtual resolution of CRTC:10 (the phantom TV output) - so it only fills part of the screen.

Adding "video=VGA-1:1280x1024 video=TV-1:d video=DVI-D-1:d" works around the problem; xorg.conf needs a similar setup to disable the "phantom" output and specific a sane default resolution for the real one, like this:

Section "Monitor"
	Identifier "TV-1"
	Option "Ignore" "True"
EndSection

Section "Monitor"
	Identifier "DVI-D-1"
	Option "Ignore" "True"
EndSection

Section "Monitor"
	Identifier "VGA-1"
	Option "PreferredMode" "1280x1024"
EndSection

Created attachment 62778 [details]
video ROM BOIS

Could you retest this on the latest kernel? Also, after reading all the comments, it's still not really clear to me what the problem is? An annoying print in dmesg? What's the effect of the bug? nouveau will always detect phantom connectors, they're there, just not pinned out on your motherboard/whatever.

Yes, it still does (as of 3b56bba6abaa70d629fccdcf8490e087ea3a1ab4 in mouveau-master) it unles the workaround in Comment 12 (set the resolution an mnaully disable the phantom ports on the kernel command line)  is applied.

There (at least) 2 symptoms - first, the syslog is spammed with "[drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:10] message." Second, the framebuffer conole is set with a phyical resolution of 1280x1024 but a virtual resolution of 720x576 - so as a result is only fills part of the screen, and it can't be changed with fbset (ioctl FBIOPUT_VSCREENINFO: Invalid argument) - and attempting to do so generated more syslog spam

X11 displays normally, however, (it picks a resolution 1024x768  and fills the screen) - though it still spams the syslog.

Created attachment 88024 [details]
EDID (retrieved from sysfs)

Passing drm_kms_helper.edid_firmware=edid/1280x1024.bin to the kernel command line seems to fix the problem as well.

Otput of parse-edid: 

parse-edid: parse-edid version 2.0.0
parse-edid: EDID checksum passed.

	# EDID version 1 revision 3
Section "Monitor"
	# Block type: 2:0 3:fd
	# Block type: 2:0 3:fc
	Identifier "KDS XF-70 "
	VendorName "STC"
	ModelName "KDS XF-70 "
	# Block type: 2:0 3:fd
	HorizSync 30-72
	VertRefresh 50-160
	# Max dot clock (video bandwidth) 110 MHz
	# Block type: 2:0 3:fc
	# Block type: 2:0 3:ff
	# DPMS capabilities: Active off:yes  Suspend:yes  Standby:yes

	Mode 	"1024x768"	# vfreq 75.029Hz, hfreq 60.023kHz
		DotClock	78.750000
		HTimings	1024 1040 1136 1312
		VTimings	768 769 772 800
		Flags	"+HSync" "+VSync"
	EndMode
	# Block type: 2:0 3:fd
	# Block type: 2:0 3:fc
	# Block type: 2:0 3:ff
EndSection

-- 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/11.