Created attachment 34442 [details] [review] Xorg.0.log After booting with vga connected it now works. DP will not work for me however. Created attachment 34525 [details]
drm.debug=15
just booting with no X startup
Created attachment 34526 [details] [review] Xorg.0.log with nomodeset no kms, just ums Created attachment 34527 [details]
bios
Created attachment 34528 [details] [review] Xorg.0.log nomodeset git patch applied from http://fpaste.org/WgQj/raw/ Created attachment 34531 [details] [review] possible link training fix Does this kms patch help? Try applying this other patch as well: http://marc.info/?l=dri-devel&m=126988624220184&w=2 although it shouldn't be necessary. Created attachment 34535 [details] dmesg dmesg with attachment 34531 [details] [review] applied. With the patch applied the monitor no longer goes into 'power save' mode and appears to think something is being sent to it. However I still get no picture. Created attachment 34585 [details] [review] possible fix Does this drm patch help? We should be turning the DP vid stream on after we do link training. Created attachment 34587 [details] dmesg dmesg after attachment 34585 [details] [review] applied. Still no output. No go. Thanks so much for the continued help! (In reply to comment #9) > Created an attachment (id=34585) [details] > possible fix > > Does this drm patch help? We should be turning the DP vid stream on after we > do link training. > *** Bug 28554 has been marked as a duplicate of this bug. *** boot up to a vga console (don't load the radeon drm or X) so that the DP monitor is still enabled. Then dump the reg state to a file and attach that dump. You can get avivotool here: http://cgit.freedesktop.org/~airlied/radeontool/ and then apply this patch: https://bugs.freedesktop.org/attachment.cgi?id=34810 then dump the regs (as root): avivotool regs all > dp_bios.dump You can also dump the regs as described in the previous comment using fglrx if that's easier. I just need a dump from a working state. *** Bug 28267 has been marked as a duplicate of this bug. *** This is a problem in the link training algo. The timing and ordering may need to be tweaked to make some monitors happy. Created attachment 37606 [details] avivotool regs all (vanilla radeontool package) This is the output of my machine while running fglrx. attachment 34810 [details] [review] *not* applied. will upload output with that patch momentarily. Created attachment 37607 [details]
avivotool regs all (patched radeontool package)
From my properly running machine with fglrx.
radeontool patched with attachement 34810
Building the current X driver on a Fedora 14 system still has this bug. The hack of reverting c7eeda8c3f3514ba95ebf2893fbe124bf526b3df works on the imac27. Anything I could do to help with this bug? Is there any hack I can do to get this working? I'd like to be using the open-source drivers (9 months has been more than enough for me)... You'll have to tweak the link training algo (dp_link_train() in atombios_dp.c) until the monitor accepts the link. Unfortunately, there's not a lot I can do without access to the problematic monitor. Created attachment 41696 [details] [review] enable downspread if the sink supports it First see if this patch helps, if not, try the second patch both with and without this one. Created attachment 41697 [details] [review] retry the training with a higher voltage Try this patch both with and without the previous downspread patch. I've tried the attached patches and no go. I started digging through code and even read part of the dp spec but didn't get very far :( I'll allow ssh access to the machine or possibly figure out a way to get one of these monitors into a dev's hands if that's what it takes... The patches don't help the iMac11,2 (21.5" version) either. Still no picture. http://www.odi.ch/prog/imac/index.php Created attachment 41944 [details] [review] possible fix Maybe the monitor doesn't like the clock... Does this patch help? Tried on the iMac11,2 and seeing no difference. Find the dmesg debug output (with that patch) and a lot more info on the site mentioned in comment 25. I am not even sure if the drivers configures the right pll/encoder/transmitter etc. Been out on vacation. Is it still necessary to test the latest patch? (In reply to comment #28) > Been out on vacation. Is it still necessary to test the latest patch? Worth a shot. Can you try the patches available here: http://people.freedesktop.org/~agd5f/dp_fixes/ Created attachment 42529 [details]
dmesg output with 2011-01-25 patches
Thanks for continuing to look at this! Still no go with those patches for me. See attached dmesg.
Tried patches from comment 30 on the iMac11,2 and still seeing no difference. *** Bug 35179 has been marked as a duplicate of this bug. *** *** Bug 35479 has been marked as a duplicate of this bug. *** Just out of curiosity, why is link training implemented on driver level and not on drm level? I see that nouvau and radeon each have their own implementation. The algorithm does not depend on the card, right? Only the way voltage, patterns etc are set does. Maybe by merging them the problem can be found. (In reply to comment #35) > Just out of curiosity, why is link training implemented on driver level and not > on drm level? I see that nouvau and radeon each have their own implementation. > The algorithm does not depend on the card, right? Only the way voltage, > patterns etc are set does. Maybe by merging them the problem can be found. The link training algo is the same across all chips in theory (it's defined in a VESA spec). However, there are often a lot of asic specific things that need to be handled. It would probably be doable if you could figure out the right set of callbacks and driver adjustable fields to make all the drivers happy. Does the following patch set (against 2.6.39) help? http://people.freedesktop.org/~agd5f/dp_rewrite/ Created attachment 46185 [details]
dmesg with DP rewrite patches
Still doesn't work unfortunately. dmesg attached.
Created attachment 46455 [details] efi iMac12,2 dmesg Same problem with latest iMac12,2 (27") when booting with efi. (I had to patch kernel 2.6.38 because of https://bugzilla.kernel.org/show_bug.cgi?id=23202) The first attachment is booting with efi, the second booting with bios. I removed the timestamps from mesg to ease the diff. EFI : black screen when drm is activated (not before) BIOS : drm and Xorg work, DRI2 activated. Created attachment 46456 [details]
bios iMac12,2 dmesg
and the one booting with bios.
and i forgot to mention my current kernel is 2.6.38 with all ~agd5f/dp_rewrite/ patches applied. Results are much the same with and without those. I think the problem comes from the difference between BIOS run (working): drm:radeon_dp_get_link_status], link status 11 11 80 00 00 00 [drm:radeon_dp_link_train], clock recovery at voltage 0 pre-emphasis 0 [drm:radeon_dp_get_link_status], link status 77 77 81 00 00 00 [drm:radeon_dp_link_train], channel eq at voltage 0 pre-emphasis 0 and EFI run (black screen): [drm:radeon_dp_get_link_status], link status 00 00 00 00 11 11 [drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 0dB [drm:dp_get_adjust_train], requested signal parameters: lane 1 voltage 0.6V pre_emph 0dB [drm:dp_get_adjust_train], requested signal parameters: lane 2 voltage 0.6V pre_emph 0dB [drm:dp_get_adjust_train], requested signal parameters: lane 3 voltage 0.6V pre_emph 0dB [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 0dB [drm:radeon_dp_get_link_status], link status 00 00 00 00 22 22 Though I'm a bit weak on atombios_dp.c, i'm ready to promptly test any patch. Last test was with kernel 2.6.39-rc6. It seems the bios that's found when booting in UEFI mode is wrong. Following that patch and procedure : https://bugs.freedesktop.org/show_bug.cgi?id=26891 solves the issue. When the mode is set, the screen displays weird stuff for a moment. I'll investigate drm messages to see what happens. But I also noticed the line "radeon 0000:01:00.0: Invalid ROM contents" in my dmesg. Although I am not using EFI boot (plain old grub without EFI support), this indicates that the kernel doesn't see a valid video BIOS, right? So I doubt this bug as anything to do with DP link training actually, and bug 26891 is really the cause. I just wanted to note that EFI is out of the picture in my setup. Both laptop and monitor in my case are Dell. Please try the new patches I sent out last night. you can find them here: http://people.freedesktop.org/~agd5f/dp_rewrite/ You may have to apply Jesse's bpc patches first (in the bpc firectory) depending on what kernel you are using. Please don't drag in Mac EFI issues, this bug is about DP link training problems. For Mac's stick to the legacy bios rather than trying to run in EFI mode. Travis, please try this latest patch set. I was finally able to reproduce a problem similar to yours on a new board I got. The problem was actually with the way the spread spectrum interaction with the PPLL was set up. That should be fixed in this patch set. Alex I will try as soon as I get back to the office (early next week). What version should these be applied against or do you have a git repo I should use? Dave's drm-next or drm-fixes trees should work: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary if you use drm-fixes, you'll need to apply Jesse's bpc patches (in the bpc directly in by server) first. I'll just simply use drm-next then when I test. Looks like Dave pushed a new drm-radeon-testing, so you can use that and then you'll only need to apply patches 0019 and 0020. http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing I am happy to report that with kernel 3.0.1 all works well on the iMac 27". I can confirm DisplayPort seems to work for me as well now with Linux 3.1-rc3. It didn't work on previous kernels (I'm not sure if I tested 3.0, but certainly not before 3.0) when using my Dell U2133H monitor. Does kernel 3.1 help? Also, please try this patch: http://lists.freedesktop.org/archives/dri-devel/2011-October/014993.html Alex Thanks for continuing to look at this :) I have converted my amd machine to a server so I'm not using it (or rebooting it for that matter) with an external monitor. However I ran through some updates today and decided to hook it up to provide feedback. I updated to 3.1.0 (gentoo variant) and it continues to fail for me :( After looking at the patch it appears to either be in vanilla 3.1.0 or already included in the gentoo patchset. To summarize, I've tried 3.1.0 with the patch from the link and it doesn't work with my setup. Created attachment 53309 [details] xorg log with the ati driver in fedora16 I have just installed fedora 16 on an "imac11,1", and I still have the same problem. I have attached the xorg log, let me know if there is anything else I could do to help. I checked that the patch pointed by Comment 55 is include in the linux 3.1 shipping with fedora. I am going to try the current linus tree and let you know if that helps. I also decided to try reverting c7eeda8c3f3514ba95ebf2893fbe124bf526b3df and it works. (In reply to comment #57) > Created attachment 53309 [details] > xorg log with the ati driver in fedora16 > > I have just installed fedora 16 on an "imac11,1", and I still have the same > problem. I have attached the xorg log, let me know if there is anything else I > could do to help. > > I checked that the patch pointed by Comment 55 is include in the linux 3.1 > shipping with fedora. > > I am going to try the current linus tree and let you know if that helps. Why are you using UMS? All of the relevant fixes have been in KMS. > Why are you using UMS? All of the relevant fixes have been in KMS.
KMS also failed with the fedora kernel. I will upload the dmesg in a sec.
Created attachment 53481 [details]
dmesg from kernel-3.1.0-7.fc16
Created attachment 53564 [details]
dmesg with linus tree (7f80850d3f9fd8fda23a317044aef3a6bafab06b)
Got the same problem with linus tree and KMS. dmesg attached, let me know if there is anything I should try.
Created attachment 55359 [details]
dmesg from kernel 3.2
I just tried KMS with kernel 3.2 and I still get a black screen :-(
FYI, linux 3.2-rc7 on iMac12,2 (27" 2011 model) has radeon kms running without any glitch, and even with pretty good performance ! I'm EFI-booting with default debian/experimental kernel, so it's not customized nor patched. (In reply to comment #64) > FYI, linux 3.2-rc7 on iMac12,2 (27" 2011 model) has radeon kms running without > any glitch, and even with pretty good performance ! I'm EFI-booting with > default debian/experimental kernel, so it's not customized nor patched. Interesting. I have a iMac11,1. I will try EFI booting it. Created attachment 55818 [details] [review] dmesg trying kms after efi booting EFI booting doesn't look very different from a bios boot. There is initially a fb thanks to efifb, but the screen goes black just after [ 4.071160] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver Created attachment 59612 [details]
dmesg with bios booting and kernel 3.3.0
Results are similar to 3.2 :-(
This is an imac 11,1. Let me know if there any additional debugging I could do.
I don't know exactly what changed, but I just installed fedora 17 and after updating the kernel kms is working! :-) Hi, Has anyone been able to get KMS working on a 27" iMac? I have an iMac 11,1 and I cannot get X to work. Documentation is scarce, so I don't know how to discover what is the problem. When I start X, it doesn't show any errors, but I get a blank screen. Same for when I insert the radeon module with kms on. I suspect that the EDID is not being handled correctly. Does any of you know how I can create an external EDID for a 2560x1440 monitor? My video card is an ATI Radeon HD 4850, by the way. I'd appreciate any help. I'm using linux 3.10, and can post dmesg, Xorg.0.log, etc. I'd also happily live with a non kms setup, but recent X seems to require kms... Thank you, (In reply to comment #69) > I have an iMac 11,1 and I cannot get X to work. Documentation > is scarce, so I don't know how to discover what is the problem. > When I start X, it doesn't show any errors, but I get a blank > screen. Same for when I insert the radeon module with kms on. > I suspect that the EDID is not being handled correctly. Does > any of you know how I can create an external EDID for a 2560x1440 > monitor? My video card is an ATI Radeon HD 4850, by the way. If xrandr --verbose shows the appropriate modes for your display, there is no problem with the EDID. You might try a 3.11 kernel. (In reply to comment #69) > Hi, > > Has anyone been able to get KMS working on a 27" iMac? > > I have an iMac 11,1 and I cannot get X to work. Documentation > is scarce, so I don't know how to discover what is the problem. > When I start X, it doesn't show any errors, but I get a blank > screen. Same for when I insert the radeon module with kms on. > I suspect that the EDID is not being handled correctly. Does > any of you know how I can create an external EDID for a 2560x1440 > monitor? My video card is an ATI Radeon HD 4850, by the way. > > I'd appreciate any help. I'm using linux 3.10, and can post dmesg, > Xorg.0.log, etc. I'd also happily live with a non kms setup, but > recent X seems to require kms... > > Thank you, I works for me on the same hardware if I bios boot it. With an EFI boot I get a black screen like yours. I bought a new screen and it looks like I have the same issue. Hardware is: GPU: Radeon HD5850 (1GB) Screen: Dell U2414H Connection: DisplayPort (GPU) / MiniDisplayPort (Screen) Software is: Fedora 23 (64-bit) Kernel 4.2.8 At Fedora loading my screens got no more signal and enter in sleep mode. If I unplug and replug the DisplayPort cable the screen connection is recovered. The log shows these 2 messages: [drm:radeon_dp_link_train [radeon]] *ERROR* channel eq failed: 5 tries [drm:radeon_dp_link_train [radeon]] *ERROR* channel eq failed I believe I have this issue. The screen turns off after grub. Hardware: 27 inch imac, late 2009 radeon hd 4850 core i7 I'm trying to put the latest fedora 23 on it. I'm not overwhelmingly sure about the details beyond that. I'm relatively new to linux, so if anyone wants me to try anything it would take a bit of hand holding. -- 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/drm/amd/issues/111. |
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.
Created attachment 34441 [details] dmesg I have precision m6500 and I can't get any output to my monitor once radeon loads. Neither the vga out nor the displayport out is working. I'm using xorg-server-1.7.6 ati-6.12.192 libdrm-2.4.19 kernel-2.6.33