Created attachment 30652 [details] dmesg output after loading nouveau with KMS enabled I build the nouveau-kernel as recommended here: http://nouveau.freedesktop.org/wiki/InstallDRM (Tried both master and master-compat) Steps to reproduce (I'm on gentoo) 1) I boot this kernel and login as root (VT) 2) modprobe -r nouveau 3) modprobe nouveau modeset=1 4) See a black screen shortly, then see the old VT, but now you cannot see new inputs Login with ssh still works or you can use the VT blindly
Is fbcon builtin or loaded (if it's a module)?
(In reply to comment #1) > Is fbcon builtin or loaded (if it's a module)? > builtin. I know the fbcon thing from the ati-kms ( I have a second system with r600 ati and the kms works for me...)
Now I compiled fbcon as module, git today, branch master. I booted the new kernel, unload nouveau, modprobe fbcon, modprobe nouveau modeset=1 The problem still holds. More precisely I see my frozen VT, but today I recognized the Cursor is blinking (this is not a different to fbcon builtin, I just recognized it today). But I don't know if this makes any differences. greetings
(In reply to comment #3) > Now I compiled fbcon as module, git today, branch master. > I booted the new kernel, unload nouveau, modprobe fbcon, modprobe nouveau > modeset=1 > > The problem still holds. > > More precisely I see my frozen VT, but today I recognized the Cursor is > blinking (this is not a different to fbcon builtin, I just recognized it > today). But I don't know if this makes any differences. > > greetings > From your logs: > [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 141 Doesn't sound like nouveau's fault, your monitor probably reports a broken EDID. To workaround it you can manually set the framebuffer resolution in the kernel command line, like: > video=VGA-1:1024x768e (The trailing "e" forces the output to be enabled)
Created attachment 30875 [details] forced kernel command line option > Doesn't sound like nouveau's fault, your monitor probably reports a broken > EDID. To workaround it you can manually set the framebuffer resolution in the > kernel command line, like: > > video=VGA-1:1024x768e > (The trailing "e" forces the output to be enabled) Tried this, but the problem still exists! But the message > > [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 141 disappear (see new dmesg log) New ideas?
Reopen because forcing the video output is not a solution. And thus the wrong EDID is not the problem (?)
checked out new git today. behavior changed: After loading KMS I get a simple black screen instead of a frozen screen.
Tried an other monitor (MD6155AH) today. Does work! But: Tried forcing the resolution with the command line option (video=VGA-1:1024x768e) with this monitor. Does not work (same problem, black screen)! The monitor tells me it has no connection any more. Tried other resolutions with the old monitor (LT1772ie, which is technical the same like an Acerview 76ie) The resolution 800x600e does work! This seems to be the resolution the kernel boots with (so there is no resolution switch?). Maybe it is not possible to switch the resolutions if it is forced by kernel command line? If necessary I can upload the new dmesg outputs of the different cases.
Created attachment 31015 [details] get-edid | parse-edid output get-edid | parse-edid output from the "read-edid" toolkit
Created attachment 31016 [details] forced 1024x768 but drm debug=4 New dmesg with command line option video=VGA-1:1024x768e but first modprobe -r nouveau, modprobe drm debug=4, then modprobe nouveau modeset=1
Created attachment 31018 [details] [review] set_crtc_info_for_cmdline_modes.patch Does the attached patch help?
(In reply to comment #11) > Created an attachment (id=31018) [details] > set_crtc_info_for_cmdline_modes.patch > > Does the attached patch help? > Yes, this patch works! (I only test the situation with the command line video=VGA-1:1024x768e ) Thanks.
The patch is already in Linus' kernel tree and it will eventually flow back to nouveau, so I'm marking this bug as closed.
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.