Created attachment 31688 [details] Xorg log I obtain a very slow experience when using KMS in latest kernel release, with latest xf86-video-ati, latest libdrm, and latest mesa. Some white screens when initializing graphics modes are also seeing. Attached config, log and dmesg.
Created attachment 31689 [details] Xorg configuration
Created attachment 31690 [details] [review] Kernel logs
You aren't getting KMS due to a race in the way ubuntu loads the drm for kms. X tries to load the drm when it starts, but the drm doesn't finish loading by the time the X driver checks for it so X comes up in non-kms mode, and the drm is still trying to load, but fails because X has already started messing with the hardware. You need to make sure the drm is loaded before starting X.
Firstly, I don't use Ubuntu, I use Gentoo. Secondly, I'm very sure DRM is loaded before X starts. My kernel does it even before starting init.
(In reply to comment #4) > Firstly, I don't use Ubuntu, I use Gentoo. Secondly, I'm very sure DRM is > loaded before X starts. My kernel does it even before starting init. Same issue happens in openSUSE. drm is one thing but you also have to load radeon before starting X. Please try if this help.
Does airlied's drm-radeon-testing branch work any better? http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing
(In reply to comment #5) > Same issue happens in openSUSE. > > drm is one thing but you also have to load radeon before starting X. Please try > if this help. > Every module related to drm, ttm, kms helpers, radeon, and so on... are autoloaded by my kernel at boot time before calling init. The problem is not related to the loading of the module, its the module itself. Please, refer to the attachments for details.
Created attachment 31713 [details] [review] fix vram setup on rs600 This patch should fix your issue.
I must correct something I said: the module radeon and all its dependencies are not loaded before init; my system loads them through udev. When udev is triggered to populate /dev, it talks to the kernel through uevents and when it finishes, all required modules are loaded including radeon and all deps. About the patch to fix vram setup: now the system starts ok, but when udevd starts, I obtain a blackout on my screen and the system freezes. Only power button allows me to shutdown for rebooting.
(In reply to comment #9) > I must correct something I said: the module radeon and all its dependencies are > not loaded before init; my system loads them through udev. When udev is > triggered to populate /dev, it talks to the kernel through uevents and when it > finishes, all required modules are loaded including radeon and all deps. > > About the patch to fix vram setup: now the system starts ok, but when udevd > starts, I obtain a blackout on my screen and the system freezes. Only power > button allows me to shutdown for rebooting. > Do you have fbcon loaded? Can you provide a kernel log with the patch applied?
Created attachment 31770 [details] [review] fixup rs600 gart setup Does this patch help?
(In reply to comment #10) > Do you have fbcon loaded? Can you provide a kernel log with the patch applied? > I have no clue about how to know if fbcon is loaded. A hint? About kernel log. I just can't obtain a kernel log because my system freezes too soon and it does not generate the appropriate log. Is there any known way to force the system to start logging before udev starts? Applying gart patch right now....
gart fix + vram fix = blackout at udev starting.... Let's try only the gart fix....
I experience the same problems; after loading and initializing radeon.ko, screen turns black; starting X server after loading probably locks up whole computer. I use 2.6.32 + drm-radeon-next; dmesg from boot log is at http://www.pastebin.ca/1704782 . I can be reached either by e-mail, or on IRC #radeon, handle 'mmp'
(In reply to comment #13) > gart fix + vram fix = blackout at udev starting.... > > Let's try only the gart fix.... > The gart fix alone won't work.
(In reply to comment #15) > > The gart fix alone won't work. > As you said, it didn't work: X started but slow as before. What else can I do?
Created attachment 31792 [details] [review] fix vram location This patch along with the other two should do the trick.
Created attachment 31793 [details] Rejection applying the patch 31792: fix vram location One hunk is rejected when applying the last patch. I'm attaching the resulting file from the rejection (.rej). Should I modify by hand the line causing the rejection?
(In reply to comment #18) > Created an attachment (id=31793) [details] > Rejection applying the patch 31792: fix vram location > > > One hunk is rejected when applying the last patch. I'm attaching the resulting > file from the rejection (.rej). Should I modify by hand the line causing the > rejection? > You can ignore that part.
Well, things are definitely getting better after applying the three patches. Now X starts, but with some quirks. Fonts are distorted since GDM appears. I achieve logging into my session (fonts distortions continues, totally unreadable). After a few seconds, keyboard and mouse turn unresponsive and the screen slooooowly begins to become white. After a minute or two is practically completely white. I'll attach new logs.
Created attachment 31796 [details] dmesg after applying the three patches
Created attachment 31797 [details] Xorg log after applying the three patches
When I said things are getting better, I was referring to KMS. Seems it is active and Xorg now seems to detect it, but things still need some adjustments to work properly.
Created attachment 31798 [details] [review] force 32 mb gart Can you try this on top of the others?
Created attachment 31799 [details] [review] setup gart like pre-kms If the patch in comment 24 doesn't help, try adding this one.
Well, the results of various experiments: Firstly, (and this is before applying patches 31798 and 31799) the white screen phenomenon not always occur, but fonts corruption and freezing always do. After applying patch 31798 (force 32 mb gart) nothing significantly different happened. Applying patch 31799 (setup gart like pre-kms) on top of all other four, aggravated the problem: more corruption not only in fonts, also in other areas like windows titles and desktop background (plus freeze). Applying patch 31799 without applying 31798 on top of previous three, maintains the same symptoms previous to the last two patches: font corruption and freeze. I also noticed that when applied both patches, GDM shown some rectangles in the background and a corruption similar to those on the fonts but in the form of random horizontal thick noisy bars with many colors.
Any news about this issue?
Hi, I'm affected too by this bug. I have being experiencing black screens from some kernels ago (based on this) in my current distro and after trying the patches presented here I get some mixed results. -> In the first try, I got to the login screen, but with visible corruption (the mouse cursor is a random-dots-square, and the bottom options are also really bad). I can login, X freeze but I can still change to another VT. -> In the second, the mouse pointer is completely disappeared. I can login but the system froze after that. This time I can't change to another VT. -> The third time I got an oops after getting the login screen :( Where's this oops output located? Is of any help to you if I send it? My original bug report is in Ubuntu's launchpad at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/505808
Chase Douglas wrote on 2010-02-18: "I worked with shankao through private emails to bisect to the first commit that causes issues for him. Here's the output of the bisection (note that the tree is the ubuntu-lucid git tree hosted at kernel.ubuntu.com): 1369d982cea341524032a248b1f31832bb8c3eb6 is first bad commit commit 1369d982cea341524032a248b1f31832bb8c3eb6 Author: Alex Deucher <alexdeucher@gmail.com> Date: Thu Dec 3 16:18:19 2009 -0500 drm/radeon/kms: fix vram setup on rs600 commit 722f29434e72188b2d20f9b41f4b5952073ed568 upstream. also fix up rs690 mem width. should fix fdo bug 25408 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andy Whitcroft <apw@canonical.com> :040000 040000 9bf615ab33dfcdcbd7aff53c51389705be954ba7 0f1789164ca98d79a64a7afbbbe843fa5803f02d M drivers -- At first inspection, this commit does modify the driver for the graphics card present in shankao's system, so the bisection does seem to have found the culprit. However, this change comes from the -stable tree upstream. Thus, it is odd that the 2.6.32.2 mainline kernel booted, but not our 2.6.32-10 kernel. The most likely scenario is some odd interaction between one of our patches and this change. I am going to do some further investigating to try to figure out where to go from here."
I've recently tried kernel 2.6.33. I must say that I'm constantly seeing regressions since various kernels behind regarding RS600 support, everytime is getting worse and worse. KMS still blocks graphics with a black screen (so it seems none of these patches have made it to the mainline kernel) and non-KMS is getting slower in time (I'm continuously losing FPS: at some point I had 320 fps, with kernel 2.6.32 I have 220 fps, and now when I've tried kernel 2.6.33 I obtained 190 fps). Please, is anybody working on this? Sometime ago I offered myself to test any new patch, I reaffirm that, I'm willing to help in everything I can.
As additional info I must say I'm using latest libdrm, latest xf86-video-ati and latest mesa from git repositories.
I wonder if this is an msi chipset/bios issue. E.g, For reference: http://marc.info/?l=dri-devel&m=126926011226719&w=2 https://bugzilla.kernel.org/show_bug.cgi?id=15287 Perhaps your system needs a quirk for the graphics bridge. Does booting with pci=nomsi help?
I have just tried the pci=nomsi parameter in the boot options but it still doesn't work :( If there's something else that I can do in order to debug this problem, I'm willing to help.
Created attachment 35157 [details] [review] Fix rs600 gart tlb flush Can you confirm that the attached patch fix the issue for you, here with it rs600 seems to work properly.
(In reply to comment #34) > Created an attachment (id=35157) [details] > Fix rs600 gart tlb flush > > Can you confirm that the attached patch fix the issue for you, here with it > rs600 seems to work properly. Here are the results: I've applied only this last patch to kernel 2.6.33 and obtained a black screen just before gdm start. Then I've tried to apply all the available patches published here at bugzilla and almost all of them failed to apply except 0005-setup_gart_like_pre_kms.patch and yours, but again, obtained the black screen at the same moment. Then I went back to kernel 2.6.32, applied all the patches, and then it worked. I'm using libdrm, mesa and xf86-video-ati from git head. Which kernel are you using? I would like to test your same environment, because after all, KMS is working but I only get 175 fps with glxgears, and 2D acceleration seems quite slow.
Created attachment 35202 [details] Xorg log with KMS working Here my Xorg log if you want to check it
Created attachment 35204 [details] dmesg with KMS working Also you can check my dmesg if you want.
I forgot to mention that using only the last patch on kernel 2.6.32 didn't work either, I tried that before applying all other patches.
Please try the latest 2.6.34 or Dave's drm-linus branch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-linus
Ok, tuxonice variant of kernel 2.6.34-rc5 was already patched (probably the vanilla too) and it worked just fine. Issue with speed persists but it's not so critical for me, at least right now (175 fps). I hope it will be improved in the future. I think we can declare this bug fixed.
Can someone detail exactly which patches are needed to fix this issue? I would like to ensure they are backported into Ubuntu 10.04 LTS. It would be great if they were sent to the stable queue as well. Thanks
(In reply to comment #41) > Can someone detail exactly which patches are needed to fix this issue? I would > like to ensure they are backported into Ubuntu 10.04 LTS. It would be great if > they were sent to the stable queue as well. > > Thanks I think *maybe* your best choice is to substitute in the current kernel of Ubuntu, the file drivers/gpu/drm/radeon/rs600.c with the one that "just works" available in 2.6.34-rc5. Somebody correct me if i'm saying a monstrosity.
(In reply to comment #41) > Can someone detail exactly which patches are needed to fix this issue? I would > like to ensure they are backported into Ubuntu 10.04 LTS. It would be great if > they were sent to the stable queue as well. The patch from comment 34 should be all that's needed for 10.04 as 10.04 uses a 2.6.33 drm for the most part. That patch is in 2.6.34 already and has should hit stable as well: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=30f69f3fb20bd719b5e1bf879339914063d38f47
(In reply to comment #43) > (In reply to comment #41) > > Can someone detail exactly which patches are needed to fix this issue? I would > > like to ensure they are backported into Ubuntu 10.04 LTS. It would be great if > > they were sent to the stable queue as well. > > The patch from comment 34 should be all that's needed for 10.04 as 10.04 uses a > 2.6.33 drm for the most part. That patch is in 2.6.34 already and has should > hit stable as well: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=30f69f3fb20bd719b5e1bf879339914063d38f47 Thanks! I'll make a test kernel for a user who is seeing this issue on Ubuntu so we can verify it is all that is needed.
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.