I'm currently using the 2.6.33 mainline Ubuntu kernel as it contains the RV740 initialization fix and in UMS it works just fine (have yet to test some games). As KMS is supposed to be the standard in future distributions, I take the time to report this bug here to assist in fixing it. When I try to boot with KMS I only get a screen (although it seems the correct resolution) displaying various horizontal and vertical bends in all possible colors like some strange moire effect. Changing to a VT is not possible too so the system is basically unusable. But the system itself is still responsive and I can reboot the system with CTRL+ALT+DEL. System overview: - Motherboard: Gigabyte GA-790XTA-UD4 - CPU: AMD Phenom II X4 955 (3.2GHz) - RAM: 2x 2 GiB DDR3 (1.3 GHz) - GPU: PowerColor Radeon HD4770 512MB GDDR5 - Monitor: 30" Dell 3007WFP-HC (2560x1600) - OS: Kubuntu Lucid Alpha 3 + xorg-edgers PPA I will attach some logs of a KMS boot.
Are you using a kms-enabled ddx (xf86-video-ati)? Please attach your xorg log and dmesg.
Created attachment 33928 [details] dmesg from KMS boot
Created attachment 33929 [details] Xorg.0.log from KMS boot
Well, I actually use xorg-xserer-video-radeon: libdrm-radeon1 2.4.19+git20100307.04fd3872-0ubuntu0sarvatt radeontool 1.6.0-1 xserver-xorg-video-radeon 1:6.12.191+git20100306.e7b41f8c-0ubuntu0sarvatt and those lines in Xorg.0.log let me think that everything should be fine: ... (II) [KMS] Kernel modesetting enabled. ... (II) GLX: Initialized DRI2 GL provider for screen 0 ...
Any progress on this one?
Created attachment 34657 [details] Xorg.0.log from KMS boot on 2.6.34-rc3 Just tried kernel 2.6.34-rc3 (not from mainline, self compiled, no source changes). Same result as before. Software is fine, not complaining about anything. But there are some things that I noticed when booting with KMS enabled: - no EDID detection of the monitor (driver does that in UMS) - outputs get swapped finally: (II) RADEON(0): Output DVI-0 using monitor section Dell 3007WFPHC (II) RADEON(0): Output DIN has no monitor section (II) RADEON(0): Output DVI-1 has no monitor section (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): Output DIN disconnected (II) RADEON(0): Output DVI-1 connected (II) RADEON(0): Using exact sizes for initial modes (II) RADEON(0): Output DVI-1 using initial mode 2560x1600 With UMS this results in DVI-0 becoming connected. The log says previously that the driver detected the monitor on DVI-1 which is incorrect so the final swapping corrects the output. With KMS however the initial detection is correct and the output swapping seems to make it wrong.
Created attachment 34960 [details] Diff between KMS and UMS in Xorg.0.log This is a diff between the output in /var/log/Xorg.0.log when booted with KMS vs UMS
Just to confirm that I have exactly the same issue... different motherboard ( 4core1333-FullHD FWiW ) but interestingly the same monitor. The system is 100% responsive but with no graphics, so I can log in to the machine via SSH for example. I guess that the only interesting thing about the monitor is its high resolution ( 2560x1600 ) which requires the use of dual link DVI. The only interesting thing about the motherboard is that it also has a built in Radeon card but it doesn't support dual-link. This doesn't appear to be causing any issues. I attached a diff of the Xorg.0.log above just in case it is useful.
Created attachment 34961 [details] Drm related lines from dmesg for KMS boot Sorry for posting three comments in one hour! It just struck me that actually there is no sort of splash screen with KMS enabled, and the colours described by Ancoron appear very early in the boot ( though seem to be just a blank screen for me with the rc3 kernel. ) Therefore it may be that the problem is when the radeon module is set up initially during kernel boot rather than when X loads. I really don't know the relationship between the "radeon" module and the Xorg drivers, and so this may not be the right place if it is the module - if that is the case a pointer as to where it should be posted would be appreciated. Again though, just in case, the drm related messaged from dmesg during a KMS enabled boot are attached. Without KMS there are only two lines, which I guess is expected.
(In reply to comment #6) > With UMS this results in DVI-0 becoming connected. The log says previously that > the driver detected the monitor on DVI-1 which is incorrect so the final > swapping corrects the output. With KMS however the initial detection is correct > and the output swapping seems to make it wrong. The output order is reversed between UMS and KMS. So the output is correct.
(In reply to comment #6) > Just tried kernel 2.6.34-rc3 (not from mainline, self compiled, no source > changes). > - no EDID detection of the monitor (driver does that in UMS) Can you attach your dmesg from 2.6.34-rc3? I suspect you need this patch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=95beb690170e6ce918fe53c73a0fcc7cf64d704a Finally, can you try 2.6.33 with the new_pll=0 radeon module param? E.g., set it when you load radeon: modprobe radeon modeset=1 new_pll=0 or on the kernel command line: radeon.new_pll=0
Created attachment 34990 [details] dmesg from 2.6.34-rc3 without patch The patch you mentioned doesn't apply to the torvalds rc3 tree (a lot of other changes here).
Created attachment 34991 [details] dmesg from 2.6.34-rc2 (airlied drm) up to commit 95beb690170e6ce918fe53c73a0fcc7cf64d704a Doesn't change anything here.
Created attachment 34992 [details] dmesg from 2.6.33 mainline with new_pll=0 Again, no change in behavior.
Not sure that I made it clear in my comments, but I'm using a completely different card ( HD4350 ) and so the glaring commonality was the monitor. Just to prove it, I've just dug out a different monitor - this one is a Dell IN2010N at 1600x900... lo and behold this monitor works with KMS enabled. So I can't say for sure because I know nothing about the code, but "something to do with dual link DVI" would seem to be the most likely conclusion! One other thing that I've noticed... at 2560x1600 on the 30 inch ( obviously with UMS ) I get really bad screen corruption in pretty much all apps. Scrolling pages seems to result in the bitmap not matching what was on screen previously, and so when you move the mouse over parts of the scrolled window it becomes obvious that what you see isn't what X actually thinks is there. Also, the KMail icon menu just completely corrupts after a ( short ) while, and again moving the mouse over it brings back the icons as they animate for the mouse over action. I realise that this may be a completely different bug, but I mention it because with the 1600x900 monitor and KMS it seems to not be happening...
Please try dumping the registers when using kms and ums using avivotool as root: avivotool regs all > ums.regs avivotool regs all > kms.regs And attach the dumps here. Please specify what versions of xf86-video-ati and kernel you used to make the dumps.
avivotool is part of radeontool: http://cgit.freedesktop.org/~airlied/radeontool
(In reply to comment #15) > Just to prove it, I've just dug out a different monitor - this one is a Dell > IN2010N at 1600x900... lo and behold this monitor works with KMS enabled. So I > can't say for sure because I know nothing about the code, but "something to do > with dual link DVI" would seem to be the most likely conclusion! I didn't get the chance to test that as I don't have any monitor left that has a lower resolution. So combining our experiences it really looks like a DualLink-DVI signal problem. > One other thing that I've noticed... at 2560x1600 on the 30 inch ( obviously > with UMS ) I get really bad screen corruption in pretty much all apps. > Scrolling pages seems to result in the bitmap not matching what was on screen > previously, and so when you move the mouse over parts of the scrolled window it > becomes obvious that what you see isn't what X actually thinks is there. Also, > the KMail icon menu just completely corrupts after a ( short ) while, and again > moving the mouse over it brings back the icons as they animate for the mouse > over action. I realise that this may be a completely different bug, but I > mention it because with the 1600x900 monitor and KMS it seems to not be > happening... Yes, me too (only for those corruptions when scrolling with nearly all applications - firefox, thundebird, kate, mousepad, konsole, gimp, gwenview, etc., but not with e.g. dolphin or amarok). Icons and the like are fine for me (KDE4 and XFCE). But I think that's another thing as this was introduced some time ago (I think from another DRM pull from upstream into Ubuntu Lucid).
Created attachment 35024 [details] registers from 2.6.32 +drm 2.6.33 ubuntu lucid (KMS)
Created attachment 35025 [details] registers from 2.6.32 +drm 2.6.33 ubuntu lucid (UMS)
Created attachment 35026 [details] registers from 2.6.33 mainline (KMS)
Created attachment 35027 [details] registers from 2.6.33 mainline (UMS)
Created attachment 35028 [details] registers from 2.6.34-rc2 airlied (KMS)
Created attachment 35029 [details] registers from 2.6.34-rc2 airlied (UMS)
Created attachment 35030 [details] registers from 2.6.34-rc3 (KMS)
Created attachment 35031 [details] registers from 2.6.34-rc3 (UMS)
Created attachment 35032 [details] Screenshot of the scrolling corruptions I don't really think that this is related to this bug here but just to be sure I'm attaching this screenshot for verification. This scrolling problem do appear with all tested kernels: - 2.6.32+drm2.6.33 (Ubuntu Lucid) - 2.6.33 mainline - 2.6.34-rc2 airlied - 2.6.34-rc3 So I think this is related to the driver and not the drm kernel part.
(In reply to comment #27) > Created an attachment (id=35032) [details] > Screenshot of the scrolling corruptions > > I don't really think that this is related to this bug here but just to be sure > I'm attaching this screenshot for verification. > Not related. Please file a different bug for that.
are you sure you are using the same mode for both ums and kms? The regs seem to indicate that ums is using 1280x800. check xrandr and make sure you are using 2560x1600 for both ums and kms and then dump the regs.
...done: https://bugs.freedesktop.org/show_bug.cgi?id=27650
(In reply to comment #29) > are you sure you are using the same mode for both ums and kms? The regs seem > to indicate that ums is using 1280x800. check xrandr and make sure you are > using 2560x1600 for both ums and kms and then dump the regs. Yes, I'm 100% sure that I'm using 2560x1600 with KMS and UMS: $ xrandr Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 2560 x 1600 DVI-1 disconnected (normal left inverted right x axis y axis) DVI-0 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 646mm x 406mm 2560x1600 59.9* 1280x800 59.9
Can you attach the ums xorg log?
Also, does the monitor work on the other DVI port?
Does the following fix the kms DVI output on the RV740: avivotool regset 0x76b0 0x00011031
Created attachment 35048 [details] Xorg.0.log with UMS (In reply to comment #33) > Also, does the monitor work on the other DVI port? Yes, it does: $ xrandr Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 2560 x 1600 DVI-1 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 646mm x 406mm 2560x1600 59.9* 1280x800 59.9 DVI-0 disconnected (normal left inverted right x axis y axis)
(In reply to comment #34) > Does the following fix the kms DVI output on the RV740: > avivotool regset 0x76b0 0x00011031 Yes it does! :) I'm writing this with KMS right now. Cool. And finally 2560x1600 virtual terminals... [off-topic]...if I only would have that at work... *dream*[/off-topic]
On the off chance I tried the same and it didn't work for me, but then I sort of guessed that it might not because of my different chip ( RV710 ) and also that the registers probably relate to specific outputs or whatever. So, after some guesswork and looking at which registers changed between KMS and UMS and not over time, and looking at the change that Alex suggested for Ancoron, I came up with: avivotool regset 0x7fd0 0x00011001 ( The incorrect/previous value was 0x00010001 ) which fixes the problem for me :). I'm sure that Alex could have told me that since he obviously has an idea of what the registers actually do rather than my "needle in a haystack" approach! So thanks for looking at this Alex - I'm now a happy bunny.
Created attachment 35071 [details] [review] fix This drm patch should fix the issue.
(In reply to comment #38) > Created an attachment (id=35071) [details] > fix > > This drm patch should fix the issue. Yes, indeed it does. :) Wow, those new splash things really look nice. Thanx Alex!
Yep, fixed here too. Thanks again Alex.
Patch sent to Dave.
*** Bug 26787 has been marked as a duplicate of this bug. ***
(In reply to comment #42) > *** Bug 26787 has been marked as a duplicate of this bug. *** Works fine for me. Thanks for fixing this.
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.