Bug 42490 - NUTMEG DP to VGA bridge not working
NUTMEG DP to VGA bridge not working
Status: NEW
Product: DRI
Classification: Unclassified
Component: DRM/Radeon
unspecified
x86-64 (AMD64) All
: medium normal
Assigned To: Default DRI bug account
:
: 47064 51652 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-01 16:16 UTC by Mandeep Singh Baines
Modified: 2013-09-08 17:50 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg log of radeon errors (179 bytes, application/x-desktop)
2011-11-01 16:16 UTC, Mandeep Singh Baines
no flags Details
vga bios (4.90 KB, text/plain)
2011-11-01 16:16 UTC, Mandeep Singh Baines
no flags Details
possible fix (1.29 KB, patch)
2012-04-27 14:18 UTC, Alex Deucher
no flags Details | Splinter Review
dmesg with proposed patch and drm.debug=4 (127.13 KB, text/plain)
2012-04-28 03:41 UTC, Niels Ole Salscheider
no flags Details
dmesg with proposed patch and drm.debug=4 (205.32 KB, text/plain)
2012-04-29 01:38 UTC, diego.abelenda
no flags Details
vbios (60.50 KB, application/octet-stream)
2012-04-29 02:14 UTC, Niels Ole Salscheider
no flags Details
possible fix (1.93 KB, patch)
2012-04-29 05:30 UTC, Alex Deucher
no flags Details | Splinter Review
dmesg with second patch and drm.debug=4 (234.05 KB, text/plain)
2012-04-29 07:45 UTC, diego.abelenda
no flags Details
dmesg booting with monitor unplugged and letting X enabling it (2nd patch applied) (134.12 KB, text/plain)
2012-04-29 08:14 UTC, diego.abelenda
no flags Details
dmesg booting with 2 monitors plugged drm.debug=4 (4.33 KB, text/plain)
2012-09-07 19:19 UTC, diego.abelenda
no flags Details
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 (39.51 KB, text/plain)
2012-09-07 21:07 UTC, diego.abelenda
no flags Details
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 (32.24 KB, text/plain)
2012-09-07 21:11 UTC, diego.abelenda
no flags Details
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 (85.00 KB, text/plain)
2012-09-07 21:28 UTC, diego.abelenda
no flags Details
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 (X with NoAccel) (41.15 KB, text/plain)
2012-09-08 08:59 UTC, diego.abelenda
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mandeep Singh Baines 2011-11-01 16:16:01 UTC
Created attachment 53026 [details]
dmesg log of radeon errors

I have an ASRock A75M motherboard with an A8-3850.

Booting a 3.1 kernel (also tried 3.06), my screen goes blank with modesetting enabled. If I disable modesetting, I am able to boot fine but then X won't work because the X11 driver requires modesetting.
Comment 1 Mandeep Singh Baines 2011-11-01 16:16:33 UTC
Created attachment 53027 [details]
vga bios
Comment 2 Mandeep Singh Baines 2011-11-01 16:17:43 UTC
Nov 01 12:06:55 [kernel] [    1.445489] [drm] Initialized drm 1.1.0 20060810
Nov 01 12:06:55 [kernel] [    1.445828] [drm] radeon defaulting to kernel modesetting.
Nov 01 12:06:55 [kernel] [    1.445934] [drm] radeon kernel modesetting enabled.
Nov 01 12:06:55 [kernel] [    1.446077] radeon 0000:00:01.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Nov 01 12:06:55 [kernel] [    1.446675] [drm] initializing kernel modesetting (SUMO 0x1002:0x9640 0x1849:0x9640).
Nov 01 12:06:55 [kernel] [    1.446922] [drm] register mmio base: 0xFEF00000
Nov 01 12:06:55 [kernel] [    1.447024] [drm] register mmio size: 262144
Nov 01 12:06:55 [kernel] [    1.447234] ATOM BIOS: General
Nov 01 12:06:55 [kernel] [    1.447361] radeon 0000:00:01.0: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M used)
Nov 01 12:06:55 [kernel] [    1.447538] radeon 0000:00:01.0: GTT: 512M 0x0000000010000000 - 0x000000002FFFFFFF
Nov 01 12:06:55 [kernel] [    1.447719] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining
Nov 01 12:06:55 [kernel] [    1.447886] [drm] Detected VRAM RAM=256M, BAR=256M
Nov 01 12:06:55 [kernel] [    1.447974] [drm] RAM width 32bits DDR
Nov 01 12:06:55 [kernel] [    1.448195] [TTM] Zone  kernel: Available graphics memory: 3950106 kiB.
Nov 01 12:06:55 [kernel] [    1.448289] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
Nov 01 12:06:55 [kernel] [    1.448379] [TTM] Initializing pool allocator.
Nov 01 12:06:55 [kernel] [    1.448493] [drm] radeon: 256M of VRAM memory ready
Nov 01 12:06:55 [kernel] [    1.448584] [drm] radeon: 512M of GTT memory ready.
Nov 01 12:06:55 [kernel] [    1.448685] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Nov 01 12:06:55 [kernel] [    1.448775] [drm] Driver supports precise vblank timestamp query.
Nov 01 12:06:55 [kernel] [    1.448897] radeon 0000:00:01.0: radeon: using MSI.
Nov 01 12:06:55 [kernel] [    1.449013] [drm] radeon: irq initialized.
Nov 01 12:06:55 [kernel] [    1.449104] [drm] GART: num cpu pages 131072, num gpu pages 131072
Nov 01 12:06:55 [kernel] [    1.450154] [drm] Loading SUMO Microcode
Nov 01 12:06:55 [kernel] [    1.458789] radeon 0000:00:01.0: WB enabled
Nov 01 12:06:55 [kernel] [    1.474954] [drm] ring test succeeded in 2 usecs
Nov 01 12:06:55 [kernel] [    1.475122] [drm] radeon: ib pool ready.
Nov 01 12:06:55 [kernel] [    1.475276] [drm] ib test succeeded in 0 usecs
Nov 01 12:06:55 [kernel] [    1.477539] [drm] Radeon Display Connectors
Nov 01 12:06:55 [kernel] [    1.477645] [drm] Connector 0:
Nov 01 12:06:55 [kernel] [    1.477746] [drm]   HDMI-A
Nov 01 12:06:55 [kernel] [    1.477846] [drm]   HPD2
Nov 01 12:06:55 [kernel] [    1.477947] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
Nov 01 12:06:55 [kernel] [    1.478122] [drm]   Encoders:
Nov 01 12:06:55 [kernel] [    1.478223] [drm]     DFP1: INTERNAL_UNIPHY2
Nov 01 12:06:55 [kernel] [    1.478325] [drm] Connector 1:
Nov 01 12:06:55 [kernel] [    1.478426] [drm]   VGA
Nov 01 12:06:55 [kernel] [    1.478525] [drm]   HPD1
Nov 01 12:06:55 [kernel] [    1.478626] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
Nov 01 12:06:55 [kernel] [    1.478779] [drm]   Encoders:
Nov 01 12:06:55 [kernel] [    1.478865] [drm]     CRT1: INTERNAL_UNIPHY2
Nov 01 12:06:55 [kernel] [    1.478953] [drm]     CRT1: NUTMEG
Nov 01 12:06:55 [kernel] [    1.956032] [drm] Radeon display connector HDMI-A-1: No monitor connected or invalid EDID
Nov 01 12:06:55 [kernel] [    2.104068] Refined TSC clocksource calibration: 2894.735 MHz.
Nov 01 12:06:55 [kernel] [    2.104443] Switching to clocksource tsc
Nov 01 12:06:55 [kernel] [    2.436028] [drm] Radeon display connector VGA-1: No monitor connected or invalid EDID
Nov 01 12:06:55 [kernel] [    2.441565] [drm] Internal thermal controller without fan control
Nov 01 12:06:55 [kernel] [    2.442002] [drm] radeon: power management initialized
Nov 01 12:06:55 [kernel] [    3.072510] [drm] fb mappable at 0xC0141000
Nov 01 12:06:55 [kernel] [    3.072601] [drm] vram apper at 0xC0000000
Nov 01 12:06:55 [kernel] [    3.072689] [drm] size 3145728
Nov 01 12:06:55 [kernel] [    3.072775] [drm] fb depth is 24

Nov 01 12:06:55 [kernel] [    3.072862] [drm]    pitch is 4096
Nov 01 12:06:55 [kernel] [    3.073325] fbcon: radeondrmfb (fb0) is primary device
Nov 01 12:06:55 [kernel] [    8.100031] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
Nov 01 12:06:55 [kernel] [    8.110377] [drm:radeon_dp_get_link_status] *ERROR* displayport link status failed
Nov 01 12:06:55 [kernel] [    8.110381] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
Nov 01 12:06:55 [kernel] [    8.129433] Console: switching to colour frame buffer device 128x48
Nov 01 12:06:55 [kernel] [    8.135688] fb0: radeondrmfb frame buffer device
Nov 01 12:06:55 [kernel] [    8.135690] drm: registered panic notifier
Nov 01 12:06:55 [kernel] [    8.135695] [drm] Initialized radeon 2.10.0 20080528 for 0000:00:01.0 on minor 0
Comment 3 Alex Deucher 2011-11-02 05:49:06 UTC
Please attach your xorg log.  Which connector(s) are you using?
Comment 4 Mandeep Singh Baines 2011-11-02 14:27:56 UTC
The problem is happening right at boot. With DRM_RADEON_KMS enabled in my kernel config, the screen goes black immediately after exiting the bootloader. The machines is not wedged because <ctrl-alt-delete> still works.

If recompile with DRM_RADEON_KMS=n, the screen goes black (for longer than I'm used to) but then I see the kernel printks and then a login prompt. When I try to run X with xf86-video-ati I get an error message telling me that SUMO requires KMS. So I'm currently working around by running with the VESA X drivers.

This is a brand new machine which I just brought up yesterday. Windows seems to work fine so I don't think its a hardware issue.

The motherboard comes with a VGA and an HDMI connector. I'm currently using the VGA connector.
Comment 5 Mandeep Singh Baines 2011-11-02 14:37:02 UTC
I probably should have assigned this to Product:DRI instead Product:xorg since the problem I'm seeing is in the kernel driver and not in the xorg driver.
Comment 6 Alex Deucher 2011-11-02 14:51:58 UTC
The DP to VGA bridge chips on a llano APUs are problematic in a lot of cases.  You might try a newer kernel or use a digital port (HDMI, DP, DVI) in the meantime.
Comment 7 Mandeep Singh Baines 2011-11-02 19:15:33 UTC
I've tried 3.0.6, 3.1 and the drm-core-next branch from: git://people.freedesktop.org/~airlied/linux

Is there a radeon linux kernel tree I could test? I'm also happy to test any patches against any tree.

I've ordered an HDMI-DVI cable so I'll give that a shot in a few days.
Comment 8 Alex Deucher 2011-11-03 07:17:19 UTC
(In reply to comment #7)
> I've tried 3.0.6, 3.1 and the drm-core-next branch from:
> git://people.freedesktop.org/~airlied/linux
> 
> Is there a radeon linux kernel tree I could test? I'm also happy to test any
> patches against any tree.

You can try drm-fixes-staging, but I doubt you'll see any change.  I'll be sure to update this bug as I make progress with the NUTMEG chip.
Comment 9 Mandeep Singh Baines 2011-11-03 19:15:58 UTC
Tested with drm-fixes-staging. Same behavior.
Comment 10 Mandeep Singh Baines 2011-11-05 19:58:01 UTC
Woot! HDMI works fine.
Comment 11 Alex Deucher 2012-03-12 06:43:07 UTC
*** Bug 47064 has been marked as a duplicate of this bug. ***
Comment 12 Jeff Cook 2012-04-14 20:00:52 UTC
Seeing this here on an Acer Aspire am3470g-uw10p with Radeon HD 6530D. The vga output dies as soon as radeon with KMS is loaded. In process of acquiring HDMI cable to test with HDMI output.

I have tried with 3.3.1 and 3.3.2 and same problem. Using xorg 1.12.1, xf86-video-ati 6.14.4, ati-dri/mesa 8.0.2 on brand new Arch Linux. Also tried Ubuntu 11.10 Live CD and same results.

Adding vga=775 radeon.modeset=0 to kernel boot line gives me a usable console interface and Xorg will actually start that way, but Xorg display is highly corrupted with bands of bright green and red lines.

Ubuntu 12.04 beta 2 gives same result except that it can successfully start a non-corrupted (but incorrect resolution) Xorg server with the kernel boot line above.

I have an identical snippet in my dmesg as the one posted by Mandeep Baines above.

This bug is marked fixed for Ubuntu in Launchpad ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/825777 ) but it doesn't work with a fully up-to-date Arch Linux. I haven't had occasion to try the specific Ubuntu kernel build (3.0.0-17.30) cited as resolving the problem (and it seems to be based on one positive result) and I don't seem to see a patch that would be applicable to a mainline kernel.

lspci:
VGA compatible controller: Advanced Micro Devices [AMD] nee ATI BeaverCreek [Radeon HD 6530D]
Comment 13 Jeff Cook 2012-04-15 21:38:56 UTC
So it turns out the monitor didn't have an HDMI input.

The only way I could get it working without an HDMI-DVI cable was to downgrade to Xorg 1.11 and install Catalyst. I'm looking forward to the arrival of an HDMI-capable monitor at that station so I can test the open-source driver more thoroughly (get some quite annoying crashes with Catalyst).
Comment 14 Alex Deucher 2012-04-27 14:18:03 UTC
Created attachment 60707 [details] [review]
possible fix

This patch fixes things for me.
Comment 15 diego.abelenda 2012-04-28 00:39:38 UTC
Doesn't change anything for me.
I tried patching a kernel 3.3.2 and a 3.4.0_rc4 ... should I try with a next-drm or drm-fixes-staging ?
Comment 16 Niels Ole Salscheider 2012-04-28 03:40:51 UTC
This does not fix the problem for me, either...
Comment 17 Niels Ole Salscheider 2012-04-28 03:41:32 UTC
Created attachment 60730 [details]
dmesg with proposed patch and drm.debug=4
Comment 18 Alex Deucher 2012-04-28 16:01:00 UTC
(In reply to comment #16)
> This does not fix the problem for me, either...

(In reply to comment #17)
> Created attachment 60730 [details]
> dmesg with proposed patch and drm.debug=4

Your system doesn't use a NUTMEG chip.  It uses TRAVIS for both VGA and LVDS.  Please attach a copy of your vbios:

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
Comment 19 diego.abelenda 2012-04-29 01:38:38 UTC
Created attachment 60758 [details]
dmesg with proposed patch and drm.debug=4

Mine is and the patch doesn't correct the problem.

(please ignore the nouveau stuff this is because I want a dual screen so I put a second card in the machine if not for this problem with the VGA I wouldn't have it)
Comment 20 Dave Airlie 2012-04-29 01:41:58 UTC
At least here, I now can boot, however I can't get through a dpms as link training fails.

so one step forward.
Comment 21 Niels Ole Salscheider 2012-04-29 02:14:01 UTC
Created attachment 60760 [details]
vbios
Comment 22 Alex Deucher 2012-04-29 05:27:18 UTC
(In reply to comment #19)
> Created attachment 60758 [details]
> dmesg with proposed patch and drm.debug=4
> 
> Mine is and the patch doesn't correct the problem.

Does it work if you boot without VGA attached and then enable it later?  How about if you disable VGA with xrandr and then re-enable it?  E.g.:
xrandr --output VGA-0 --off
xrandr --output VGA-0 --auto
Comment 23 Alex Deucher 2012-04-29 05:30:24 UTC
Created attachment 60765 [details] [review]
possible fix

Please try this patch in addition to the one in attachment 60707 [details] [review].
Comment 24 diego.abelenda 2012-04-29 07:45:28 UTC
Created attachment 60773 [details]
dmesg with second patch and drm.debug=4

without the second patch doing

xrandr --output VGA-0 --off
xrandr --output VGA-0 --auto

logs errors in dmesg

[drm:radeon_dp_link_train_cr] *ERROR* clock recovery reached max voltage
[drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed

---

with the second patch I have exactly the same error...
Comment 25 diego.abelenda 2012-04-29 08:14:49 UTC
Created attachment 60774 [details]
dmesg booting with monitor unplugged and letting X enabling it (2nd patch applied)

oh sorry the previous log was with monitor connected since boot... with the patch and booting with the monitor unplugged and then plugging it and letting X enable it, it works !
Comment 26 diego.abelenda 2012-04-29 08:34:56 UTC
Oh fun. Seeing how the driver seems to mess up things (with your previous comment) with the connectors when booting with both plugged, I tried to boot without the nvidia card and both monitors plugged and the unplugging the VGA monitor during the boot (before X starts) and both screens when off, the VGA one with "no connection" and the DVI with "no signal".

Once X is started both monitors are detected correctly.

Is it somehow linked to the mirror mode the EFI does ?

Well at least I have a hook to get my dual screen working. Just unplug the VGA boot and plug it during boot.
Comment 27 Florian Mickler 2012-04-30 02:54:28 UTC
A patch referencing this bug report has been merged in Linux v3.4-rc5:

commit 700698e7c303f5095107c62a81872c2c3dad1702
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Apr 27 17:18:59 2012 -0400

    drm/radeon/kms: need to set up ss on DP bridges as well
Comment 28 Jerome Glisse 2012-05-07 12:57:34 UTC
Does people here have better luck with the patch mentioned previously:

drm/radeon/kms: need to set up ss on DP bridges as well
Comment 29 diego.abelenda 2012-05-07 23:54:17 UTC
Well considering the commit pointed is exactly the patch proposed in comment 14 ( https://bugs.freedesktop.org/attachment.cgi?id=60707 ) it is pretty clear that it doesn't do anything for me.

That's why I didn't react at all when the inclusion was advertised.
Comment 30 lukenshiro 2012-09-05 18:31:11 UTC
I have a similar problem: right after boot, my screen works (displays kernel messages) until maybe drm module is loaded (I guess by udev), then it becomes immediately blank and monitor is blinking, and then works again some time after fbcon and radeon modules are manually loaded in boot scripts (before starting X).
It depends on modeset=1; if I use modeset=0 this behaviour doesn't appear, bua X cannot run without KMS.

I have an AMD A4-3300 APU and using a (vanilla) linux kernel 3.5.3 (on Slackware64)

The real problem is that some time (a couple of minutes or so) after video adapter is in idle mode (e.g. if I am not using the PC), monitor blinks (as in low power mode) screen is blank and system is no longer recoverable (unless I use e.g. ssh just to power it off).
I don't know if the two problems are really related or not. Voltage problems?

I have these messages in dmesg, too, when it happens:
"""
[ 2405.888198] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 0, devices 00000001, active_devices 00000001
[ 2405.892352] [drm:radeon_dp_get_link_status], link status 44 44 01 00 44 44
[ 2405.892360] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB
[ 2405.892365] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 3.5dB
[ 2405.893921] [drm:radeon_dp_get_link_status], link status 44 44 01 00 48 44
[ 2405.893926] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 6dB
[ 2405.893931] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 6dB
[ 2405.895508] [drm:radeon_dp_get_link_status], link status 44 44 01 00 4c 44
[ 2405.895514] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.4V pre_emph 9.5dB
[ 2405.895518] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V pre_emph 9.5dB
[ 2405.897079] [drm:radeon_dp_get_link_status], link status 44 44 01 00 41 44
[ 2405.897085] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 0dB
[ 2405.897089] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 0dB
[ 2405.898632] [drm:radeon_dp_get_link_status], link status 44 44 01 00 45 44
[ 2405.898634] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 3.5dB
[ 2405.898636] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 3.5dB
[ 2405.900152] [drm:radeon_dp_get_link_status], link status 44 44 01 00 49 44
[ 2405.900155] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 6dB
[ 2405.900156] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 6dB
[ 2405.901674] [drm:radeon_dp_get_link_status], link status 44 44 01 00 42 44
[ 2405.901676] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.8V pre_emph 0dB
[ 2405.901677] [drm:dp_get_adjust_train], using signal parameters: voltage 0.8V pre_emph 0dB
[ 2405.903194] [drm:radeon_dp_get_link_status], link status 44 44 01 00 46 44
[ 2405.903196] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.8V pre_emph 3.5dB
[ 2405.903197] [drm:dp_get_adjust_train], using signal parameters: voltage 0.8V pre_emph 3.5dB
[ 2405.904715] [drm:radeon_dp_get_link_status], link status 44 44 01 00 43 44
[ 2405.904717] [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 1.2V pre_emph 0dB
[ 2405.904718] [drm:dp_get_adjust_train], using signal parameters: voltage 1.2V pre_emph 0dB
[ 2405.906235] [drm:radeon_dp_get_link_status], link status 44 44 01 00 43 44
[ 2405.906238] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery reached max voltage
[ 2405.906240] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
"""
Comment 31 Alex Deucher 2012-09-05 18:34:56 UTC
Please try my 3.6 fixes tree (should show up in 3.6.0rc4+ and eventually stable kernels).
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6
Comment 32 diego.abelenda 2012-09-07 19:19:10 UTC
Created attachment 66808 [details]
dmesg booting with 2 monitors plugged drm.debug=4

This drm-fixes-3.6 branch just gives me two black screens when I have them both plugged during the boot. And when X starts I get a 100% processor usage from the X process and nothing displayed. The Xorg.0.log shows nothing out of the ordinary. But I think there is something really wrong because my X server never starts accepting connection from my login manager.

When I boot with only the DVI screen plugged, no problem it boots fine.
After having booted with only the DVI plugging the VGA one works just like before.

When X puts my screens into DPMS off and I try to wake them up, the VGA goes back on correctly with this branch whereas it didn't with vanilla kernel.

So there are some good points and some bad points.

Attached is dmesg | grep -e drm -e radeon when both screens are connected, after X is "started".
Comment 33 Alex Deucher 2012-09-07 19:35:20 UTC
You might try this patch on top of my 3.6 fixees tree:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.7-wip&id=46b417b3eee694451b5bca8a7863e9174611a2e9
Comment 34 diego.abelenda 2012-09-07 21:07:16 UTC
Created attachment 66817 [details]
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4

With the additional patch, I get the DVI screen displaying things when both a plugged-in but the VGA one now says there is no signal (instead of staying black). So the behavior is somewhat similar to the vanilla kernel in that regard.

Booting with the VGA unplugged and plugging it later gives the same behavior as without that patch (i.e. better than the vanilla kernel).

Attached is the dmesg | grep -e drm -e radeon when the 2 screens are plugged and the VGA says no signal.
Comment 35 diego.abelenda 2012-09-07 21:08:26 UTC
Comment on attachment 66817 [details]
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4

Sorry wrong auto-detect of the type...
Comment 36 diego.abelenda 2012-09-07 21:11:53 UTC
Created attachment 66819 [details]
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4

Sorry... I appended the new log to the last one instead of overwriting it...
Now there is only the new dmesg information.
Comment 37 diego.abelenda 2012-09-07 21:28:26 UTC
Created attachment 66822 [details]
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4

Ok.... I need sleep...
This time is the right dmesg. With both screens plugged during the boot and the patch, but mysteriously this time the DVI screen stayed black and the VGA had no link. And X started to take 100% CPU. So exactly the same behavior as without the patch.

I tried rebooting and then both screens lit up and were black. X using 100% CPU.

the new attachment shows dmesg | grep -e drm -e radeon   after both attempts.
Comment 38 Alex Deucher 2012-09-07 21:52:32 UTC
You're getting a GPU hang for some reason which may be causing the modeset failure.  Can you try with acceleration disabled to take the out of the equation?  Try adding:
Option "NoAccel" "TRUE"
to the device section of your xorg.conf
Comment 39 diego.abelenda 2012-09-08 08:59:02 UTC
Created attachment 66828 [details]
dmesg booting with 2 monitors plugged patch applyed on top of drm-fixes-3.6 drm.debug=4 (X with NoAccel)

I tested a few things and found out that with the patch over drm-fixes-3.6 I generally get the DVI screen working but the VGA has no signal if it is plugged during the boot. The generally is there because sometimes I just get a black screen on the DVI and then X causes a GPU Hangup (The NoAccel suppresses the Hangup). This situation is rare and If the GPU hangup pressing the reset switch (instead of letting the machine off during some time and doing a cold boot) causes it to happen more often.

A "quick" way to do it is booting without the patch starting X without NoAccel and then pressing the reset button and booting with the patch.

Seems the firmware doesn't reset the state of the card properly during POST or something. Last night the problem happened "by itself", so it might happen without trying to provoke it. This morning I tried rebooting a few times but didn't get it to happen without provoking it.

The attachment is dmesg | grep -e drm -e radeon   when the DVI screen stays black (VGA saying no signal) and without hangup (provoking it on the previous boot). The last part is X turning the screens off and trying to wake them up. The situation didn't change.
Comment 40 Alex Deucher 2012-09-08 15:46:24 UTC
Does your OEM have a newer bios available for your board?  It might be worth trying a newer (or maybe older) bios image.
Comment 41 diego.abelenda 2012-09-08 18:15:14 UTC
Oh yes there was and now even without the patch my machine displays something on the DVI screen when both screens are plugged and the GPU doesn't hang anymore even without NoAccel (but only from a cold boot, if I reboot/reset I get a black screen and the GPU hangup). So part of the problem was really a firmware issue.
  
With the patch I can't seem to provoke the GPU hangup anymore.
  
But my VGA screen continues to be stubbornly off when booting with both screens plugged. Continues to work if I plug my VGA screen after booting.
  
So now I can start X safely without NoAccel that's one good thing.
  
BTW my motherboad is an Asus F1A75-M now my firmware is the latest version (2004) upgraded from 1903.
  
Oh BTW I am booting in uEFI mode using grub-2.00 I don't know if this might change something.
Comment 42 diego.abelenda 2012-09-09 07:33:54 UTC
I take back what I said before...
I just did a *very* cold boot (the machine was not connected to the electricity network during the night). I got the black DVI screen and GPU hangup with the patch. So the firmware change didn't do anything in facts...
Comment 43 lukenshiro 2012-09-13 12:21:04 UTC
Sorry for the delay.
The 2nd problem I've reported in comment #30 (when video adapter is in idle, screen blanks and becomes inoperable, error in clock recovery) seems to be resolved here using linux 3.6.0-rc4. BTW I've just one monitor on VGA port.

The 1st problem (at boot, for about 30-40 seconds screen is blanking and monitor LED is blinking; after that, messages appear again in console, before starting X [init 3 mode]) seems to be still present, though.
I will test last drm-fixes-3.6 patches ASAP.

Thank you.
Comment 44 lukenshiro 2012-09-14 07:59:36 UTC
Sorry, I've managed to resolve my first problem (screen blanking after boot for about 30-40 seconds): it is not related to drm, but it depends on fbcon loaded as a module (instead of it being compiled statically).

As explained in /usr/src/linux/Documentation/fb/fbcon.txt if fbcon is compiled as a module (CONFIG_FRAMEBUFFER_CONSOLE=m) it can produce blanking and/or garbage on display if it is not loaded immediately.
If "Framebuffer Console support" is compiled statically (CONFIG_FRAMEBUFFER_CONSOLE=y) there is no blanking here.
"Works for me"
HTH.
Comment 45 diego.abelenda 2012-09-30 15:46:46 UTC
*** Bug 51652 has been marked as a duplicate of this bug. ***
Comment 46 rmccorkell 2013-09-07 20:51:41 UTC
I can confirm that this bug is still present in Linux 3.8.0, using X Server 7.7 and driver 7.1.0. As graphics are initialized screen just goes black.