After upgrading from Ubuntu 8.10 to 9.04 I noticed that I get a lot of lockups (mostly random) with 3D applications (never had one with Ubuntu 8.10). At a first I thought it was a mesa regression, updated from 7.2 to 7.4, however I noticed the same lockups after downgrading to 7.2 (and with mesa master and radeon-rewrite, btw). Some lockups disappeared after upgrading to libdrm 2.4.9 (from Ubuntu's 2.4.5), e.g. the sauerbraten lockup I got instantly after starting the game changed to random lockups after some minutes of play. Other still occours (torcs instantly lockups as soon as the race starts). After some testing I noticed that the problem is the new drm module available since kernel 2.6.30-rc1 (and backported to Ubuntu's 2.6.28). For testing I used the game torcs: kernels working fine don't lockups, buggy kernels lockups instantly as soon as the race starts. I tried the following kernels: buggy kernels: Ubuntu's 2.6.28 (with its backported drm radeon module); 2.6.30-rc1 through 2.6.30-rc6 (installed from KernelMainlineBuilds PPA [0]) working kernels: Ubuntu's 2.6.28, after updating drm.ko and radeon.ko from git drm [1] 2.6.27 through 2.6.29.3 Evidently something bad happened between 2.6.29 and 2.6.30-rc1. I have a RV530 (M56P) on a MacBook Pro (with 32 bit Ubuntu): 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M56P [Radeon Mobility X1600] [1002:71c5] A question: is the drm module in [1] getting updated with that of latest kernels? Apparently not. [0] https://wiki.ubuntu.com/KernelMainlineBuilds [1] http://cgit.freedesktop.org/mesa/drm/
(In reply to comment #0) > A question: is the drm module in [1] getting updated with that of latest > kernels? Apparently not. No, the kernel drm module there isn't updated anymore. You should be getting only libdrm from there. Unfortunately I don't know what have been changed radeon drm in 2.6.30. Dave Airlie should know, but he's on vacation now.
(In reply to comment #1) > Unfortunately I don't know what have been changed radeon drm in 2.6.30. git whatchanged -p v2.6.29..v2.6.30-rc1 drivers/gpu/drm/radeon shows quite a few potential culprits, so I'm afraid git bisect is the most promising avenue at this point. Maybe you could try bisecting some drm specific tree to avoid getting tangled up in other changes in mainline.
I started bisecting mainline kernel and noticed a big merge from drm-next ( http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next ) that may have introduced the lockups. Indeed bisecting drm-next give the following commit: 4247ca942a16745da3d09c58996b276d02655a72 is first bad commit commit 4247ca942a16745da3d09c58996b276d02655a72 Author: Dave Airlie <airlied@redhat.com> Date: Fri Feb 20 13:28:34 2009 +1000 drm/radeon: align ring writes to 16 dwords boundaries. On some radeon GPUs this appears to introduce another level of stability around interacting with the ring. Its pretty much what fglrx appears to do. Signed-off-by: Dave Airlie <airlied@redhat.com>(In reply to comment #1) > No, the kernel drm module there isn't updated anymore. You should be getting > only libdrm from there. What about completely removing the obsolete modules from there then? It only confuses users that may want an updated module.
Created attachment 26351 [details] [review] attempt to change ring alignment rules Can you try this patch on top of the broken kernel? I'm just guessing at what it might be.
(In reply to comment #4) > Created an attachment (id=26351) [details] > attempt to change ring alignment rules > > Can you try this patch on top of the broken kernel? > > I'm just guessing at what it might be. The patch fixed the issue indeed.
Patch applied to 2.6.30 final, closing.
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.