Bug 31780 - DRM/Nouveau Blank Screen with 8500 GT
Summary: DRM/Nouveau Blank Screen with 8500 GT
Status: RESOLVED FIXED
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: 2010-11-19 15:40 UTC by Kevin Winchester
Modified: 2014-12-09 18:56 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Boot log with drm.debug=1 (32.65 KB, text/plain)
2010-11-19 15:49 UTC, Kevin Winchester
no flags Details
VBIOS (64.00 KB, application/octet-stream)
2010-11-19 16:56 UTC, Kevin Winchester
no flags Details
Boot log without radeon driver (32.19 KB, text/plain)
2010-11-27 09:26 UTC, Kevin Winchester
no flags Details
dmesg log with drm.debug=15 (155.80 KB, text/plain)
2010-11-27 16:33 UTC, Kevin Winchester
no flags Details

Description Kevin Winchester 2010-11-19 15:40:52 UTC
I have been attempting to run the Nouveau driver on an 8500 GT card I recently obtained, and all I get is a blank screen when I boot as soon as KMS kicks in.

I attach logs next, but anything else that I can do to help I can attempt.
Comment 1 Kevin Winchester 2010-11-19 15:49:27 UTC
Created attachment 40425 [details]
Boot log with drm.debug=1

A couple of notes:

- I also have a Radeon 9200 AGP card in the box, for which KMS works great, so luckily I still get a working system even though the nouveau driver fails.  Thus the log shows that card's processing as well.

- With the mainline Linus kernel, I was seeing slightly different message telling me that TMDS table version 2.0 was not yet supported.  The attached log is with latest nouveau kernel git and no longer has that message.  But the end result is still the same - a screen that does not switch to the KMS framebuffer mode.
Comment 2 Kevin Winchester 2010-11-19 16:56:45 UTC
Created attachment 40426 [details]
VBIOS

VBIOS dump from:

    /sys/kernel/debug/dri/1/vbios.rom
Comment 3 Pekka Paalanen 2010-11-27 06:33:00 UTC
What do you expect to get?

You have radeondrmfb on fb0, where the fbcon is, and nouveaufb on fb1, where no fbcon is. Therefore there is nothing to show on nouveaufb. If you expect the fbcon to cloned on both cards, I don't think that is implemented, but you should be able to assign some VCs to fb0 and some to fb1 by using fbcon=map:<numbers> kernel argument. In theory, at least.

Or do you mean that not even X can use nouveau?
Comment 4 Kevin Winchester 2010-11-27 08:46:50 UTC
I see - perhaps nouveau fb is working properly after all.  I will try removing support for radeon from the kernel configuration and see if the fbcon comes up on the nvidia card.

As to X, it does not work if I use the nouveau driver (nv works, have not tried the nvidia binary), but that is with the Arch Linux driver:

xf86-video-nouveau 0.0.16_git20100819-1

which is likely out of date by now.

If I can get the framebuffer stuff to work, I'll try compiling from source to see if X can be made to work as well.

Thanks for the help!
Comment 5 Kevin Winchester 2010-11-27 09:26:27 UTC
Created attachment 40602 [details]
Boot log without radeon driver

I guess there is still something not working about the nouveau fb.  This is an attachment of a boot log without the radeon driver configured.  The nvidia card is assigned as fb0, but the screen goes blank and stays blank.  I was able to log in blindly and request a proper shutdown, so the bootup succeeded (as is mainly confirmed in the log), but there was no video output.

Looking at the logging messages from drm, I can't see where any output is configured, so perhaps the nouveau driver cannot detect the outputs properly.

Is there anything I can do to debug this?  I'll set the drm.debug level higher and see if that is any more revealing (this log was without any drm.debug parameter set).
Comment 6 Kevin Winchester 2010-11-27 09:51:47 UTC
I set the drm.debug level to 0xe and it doesn't seem to have resulted in any more input.  Am I doing something wrong there?
Comment 7 Maarten Maathuis 2010-11-27 10:22:55 UTC
Don't know if accepts that notation, people usually do drm.debug=15 in their grub.
Comment 8 Maarten Maathuis 2010-11-27 10:24:15 UTC
That should be 14 ofcource if you want 0xe.
Comment 9 Kevin Winchester 2010-11-27 16:16:25 UTC
I tried drm.debug=15 and didn't seem to see any additional information in the logs.  Is there a kernel config option I need to enable to make this work?
Comment 10 Kevin Winchester 2010-11-27 16:33:03 UTC
Created attachment 40610 [details]
dmesg log with drm.debug=15

Here is another log, with drm.debug=15 this time.  The debugging seemed to work when I used a "debug" kernel parameter in addition to the "drm.debug=15".  This log also has the radeon driver loading and taking control of the fbcon, but since this doesn't seem to be the real issue, that is likely fine.

Looking at the log, I think I see the problem in the nouveau driver.  It apparently decides that my monitor is connected to the VGA-2 connector, when in fact I have my monitor plugged into the DVI connector on the card, would be DVI-I-2.  The detected mode of 1440x900 is correct for my LCD monitor, so apparently the detection of the monitor is working properly - it is just that apparently the driver thinks it is querying the monitor through the VGA connector.

Any settings I can try to make this work, or any code changes that might make it work?
Comment 11 Kevin Winchester 2010-12-01 16:20:42 UTC
I can confirm even more soundly now that the nouveau driver is mixing up the DVI and VGA outputs of my video card.  I now have one monitor hooked up to each output, using identical monitors.  When the nouveau fbcon comes on at boot time, the VGA-connected monitor seems to work correctly.  And then when I start X with the nouveau driver selected, the VGA-connected monitor shows a proper desktop, and the DVI-connected monitor stays blank (even though my xorg.conf specifies that both monitors should be used - which works when the nv driver is used).

The way I know that something is wrong is that the xrandr utility believes that both monitors are connected and enabled, and the DVI connection should be the primary display and to the left of the VGA connection.  However, my VGA-connected monitor is actually the primary, and it is on the left side of the virtual screen, instead of the right.

This fits with the earlier boot log where the KMS driver seemed to be getting confused between the two outputs.

Is there anything I can do to help debug this, or change the way the driver detects the outputs?
Comment 12 Pierre Moreau 2014-12-09 18:10:06 UTC
Moving to Nouveau.

Could you please retest with a recent kernel?
I should receive an 8500 GT in a few days, so I'll be able to test anyway.
Comment 13 Kevin Winchester 2014-12-09 18:56:37 UTC
Not sure if you noticed, this bug was from 4 years ago.

It has been fixed for quite a while now, but I thank you for following up.


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.