Description of problem: I have a MacPro5,1 with a Radeon 5770 card (for a picture see http://www.amazon.com/gp/product/B003Z6QH6M) with two miniDP and one DVI ports. When connecting three (Dell U2412M) monitors, two via miniDP-to-DP cables, the third using the DVI cable that shipped with the monitor, I only ever get two monitors to receive a video signal. By default, when the kernel switches to graphical mode during boot, it is "DisplayPort-1" (the second miniDP) that goes into powersave. All three monitors get recognized by X11, which "thinks" it has all three of them side by side. Fiddling with the Gnome display settings and/or xrandr, I can wake up DisplayPort-1, but only at the expense of having either DisplayPort-0 or DVI-0 go into power-save instead. Version-Release number of selected component (if applicable): kernel version 3.4.9-1.fc16.x86_64 How reproducible: Boot F16 on a machine with a Radeon 5770 as described above (I have the MacPro version of the card). Actual results: When the booting kernel switches to graphics mode (KMS ?), observe the second miniDP monitor go to sleep. Expected results: All three monitors should receive video signal. Additional info: I'll be attaching my Xorg.0.log file, and output from lsmod, lspci, xrandr, and dmesg, with the latter containing potentially relevant entries such as: [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed Any idea and pointers on whether this is a known upstream issue would also be much appreciated! Thanks, --Gabriel
Created attachment 608526 [details] Xorg log
Created attachment 608527 [details] output of lspci
Created attachment 608528 [details] output of lsmod
Created attachment 608529 [details] output of xrandr
Created attachment 608530 [details] output of dmesg
The patch referenced here: https://bugs.freedesktop.org/show_bug.cgi?id=54471 seems to fix the issue. Any chance at having this backported to F16's kernels ?
(In reply to comment #6) > The patch referenced here: > https://bugs.freedesktop.org/show_bug.cgi?id=54471 > seems to fix the issue. > > Any chance at having this backported to F16's kernels ? I won't speak for Dave, but I doubt we'd backport that to the 3.4 kernel at this time. We're going to rebase it to 3.5 at some point in the not too distant future and that might be doable but probably unlikely if it requires a lot of rework.
BTW, the patch mentioned in comment #6 above didn't (yet) make it into F18; I just tried the alpha release LiveCD, and that version of the kernel (3.6.0-0.rc2.git2.1.fc18, I believe) still has this problem. I'll probably switch to F18 on my main machine soon after its release in November, so having this fixed there is probably more bang per buck for everyone, myself included :)
I built the most recent F18/rawhide kernel-3.6.0-0.rc6.git0.2 on F16, and all three monitors light up, so things are headed in the right direction. However, scrolling (and vertical refresh in general, e.g. in firefox, xterm, etc) are now painfully slow). Given the upcoming radeon test day this Wednesday, is there any chance there will be an updated liveCD image with this kernel available for testing ? I'd like to hold off filing a "scrolling is slow with 3.6.0-0.rc6.git0.2" bug until I get a chance to observe that within the full F18 alpha environment, rather than on a hacked F16 system :) Thx, --Gabriel
(In reply to comment #9) > I built the most recent F18/rawhide kernel-3.6.0-0.rc6.git0.2 on F16, and > all three monitors light up, so things are headed in the right direction. > > However, scrolling (and vertical refresh in general, e.g. in firefox, xterm, > etc) are now painfully slow). You rebuilt a kernel with all of the debug options enabled. That's known to impact graphics performance. > Given the upcoming radeon test day this Wednesday, is there any chance there > will be an updated liveCD image with this kernel available for testing ? I'd > like to hold off filing a "scrolling is slow with 3.6.0-0.rc6.git0.2" bug > until I get a chance to observe that within the full F18 alpha environment, > rather than on a hacked F16 system :) Don't bother filing a bug. We know it's slow when the debug options are enabled. They won't remain enabled for Beta or final release.
I did rebuild the 3.6.0-0.rc6.git0 kernel again, without debugging, and indeed it works flawlessly. I'm closing this, since I was the only one complaining, and it's fixed, so thanks everyone for your help !
I noticed 3.6.2-1.fc16 was released recently for F16, but it doesn't seem to contain commit f3dd8508d459a2d0d0bc426144b92f1696d4fe86 and/or 985f61f7ee647ad570c05eab0b74915da2ac8e19, which fixed the problem for me (when using the 3.6.0-0.rc6.git0.2 kernel rebuilt on F16). Since we're now using 3.6.* on F16, is there a chance this fix could be included there as well ?
I also tried the current F18 kernel (3.6.2-2), and the fix doesn't seem to have made it in there either. Reopening...
Tried rawhide kernel 3.7.0-0.rc4.git3.1, which works ! Running a 'git log' on mainline 3.6.* and 3.7.* shows the patch SHOULD be available in both, so the question becomes: Is the Fedora 16..18 3.6.X kernel purposely turning off a bunch of things that are available in mainline ? If so, is the patch I'm interested in (commits f3dd8508d459a2d0d0bc426144b92f1696d4fe86 and 985f61f7ee647ad570c05eab0b74915da2ac8e19) part of the "on purpose" bit, or just collateral damage ? More importantly, are there any plans on allowing it to make it into F18, eventually ? If so, how about F16 as well ? :) Thanks much, --G
(In reply to comment #14) > Tried rawhide kernel 3.7.0-0.rc4.git3.1, which works ! > > Running a 'git log' on mainline 3.6.* and 3.7.* shows the patch SHOULD be > available in both, so the question becomes: Is the Fedora 16..18 3.6.X kernel > purposely turning off a bunch of things that are available in mainline ? No. > If so, is the patch I'm interested in (commits > f3dd8508d459a2d0d0bc426144b92f1696d4fe86 and That one isn't in 3.6.x. It's in 3.7-rc1. [jwboyer@zod linux]$ git describe --contains f3dd8508d459a2d0d0bc426144b92f1696d4fe86 v3.7-rc1~118^2~3^2~22 > 985f61f7ee647ad570c05eab0b74915da2ac8e19) part of the "on purpose" bit, or > just collateral damage ? That commit went into 3.6, but was later reverted with: commit 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c Author: Alex Deucher <alexander.deucher> Date: Mon Sep 17 17:26:24 2012 -0400 Revert "drm/radeon: rework pll selection (v3)" This reverts commit 985f61f7ee647ad570c05eab0b74915da2ac8e19. This commit fixed certain cases, but ended up regressing others due to limitations in the current KMS API. A proper fix is too invasive for 3.6. Push it back to 3.7. Reported-by: Andres Freund <andres> Signed-off-by: Alex Deucher <alexander.deucher> > More importantly, are there any plans on allowing it to make it into F18, > eventually ? If so, how about F16 as well ? :) Upstream deemed it too invasive to backport to 3.6. When F18 (and other branches) rebase to 3.7 it should be fixed.
This works perfectly fine now on F18 with 3.7.9-205.fc18.x86_64. I'd close the bug, but can't decide between ERRATA and CURRENTRELEASE :) Thanks, --Gabriel