Created attachment 23255 [details]
Xorg.log with the working debian driver, non-kms
Chipset (lspci output):
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
libdrm: libdrm-2.4.4-42-g4d53413 from git (advertises v2.4.5)
xorg: 1.6-rc from debian unstable
xf86-video-intel-18.104.22.168-307-g81c652e from git (advertises 22.214.171.124) exhibits the problem.
2.6.1-1 from debian experimental works flawless.
linux kernel (and drm): 2.6.29-rc6
When starting X without switching on kernel mode setting, my login screen look strangely tiled. The X cursor is not affected. The rows are about as high as the cursors, save that I could not see the pattern (my login screen is quite uniform). Switching on kernel mode setting or using the intel driver provided by debian resolves the problem. So I think it's not a problem with the kernel drm.
Save the problem with the tiling, everything works: The correct mode is selected and I didn't find anything glaring in the Xorg.log (besides the obvious difference between kms and non-kms).
I'll add the Xorg.log from the non-working driver shortly.
Created attachment 23256 [details]
Xorg.log with the non-working driver from git, non-kms
I've bisected and the breakage is introduced in
Author: Jesse Barnes <email@example.com>
Date: Mon Jan 26 17:14:06 2009 -0800
Support tiled back/depth on 915-class hardware with DRI2.
Oh, and I've forgotten to post my xorg.conf:
Option "AccelMethod" "UXA"
Ah I bet this is in the kernel then; we have a separate function for setting up fence regs on 8xx... but it looks correct. Hm I'll have to look around some more.
> --- Comment #3 from Jesse Barnes <firstname.lastname@example.org> 2009-02-25 09:18:42 PST ---
> Ah I bet this is in the kernel then; we have a separate function for setting up
> fence regs on 8xx... but it looks correct. Hm I'll have to look around some
New observation: I upgraded the kernel to 2.6.29-rc8 and now kms is fully
usable for me (before suspend didn't work). So I naturally played with it
some longer and found out that glxgears is broken in the same way (tiled
output, but at the right place). This does _not_ happen, when I don't
switch on kms on and use the old 2d ddx. Mesa is 7.3-1 from Debian.
So even when using kms, something strange is happening.
I've bisected the kernel and filed a bug report at the kernel bz because it looks more like a kernel regression. See
*** Bug 20721 has been marked as a duplicate of this bug. ***
No, please keep the bug here... easier for me to follow one bug tracking system than two.
Can you add code to dump the fence registers to the i915 driver so we can see how the bits change with this revert? The fence reg programming could well be broken on 8xx but I want to see how...
I've banged my head at the problem and made quite some progress. The attached patch fixes all the bugs in the fence reg programming I've found. Unfortunately glxgears still doesn't work (kms and non-kms), but I gathered some WARN_ON backtraces awaiting analysis. But all 2d ddx stuff works flawless now.
As mentioned in the changelog there seems to be a bug in the userspace driver: It tries to set tiling with a stride value which has one bit too much set. I didn't bother to look into this, because it works when simply returning -EINVAL.
Furthermore I've added similar checks for i915 and i1965 hw like I did for i8xx. Please check whether this is correct (I don't have the hardware to test).
Created attachment 24351 [details] [review]
patch is against v2.6.29
These look like some good fixes Daniel, can you post your patch to email@example.com for review & commit? Thanks a lot for looking into this; I know 8xx has been neglected recently...
*** Bug 20781 has been marked as a duplicate of this bug. ***
this issue has gone against below commits:
Xserver: (server-1.6-branch) 60c161545af80eb78eb790a05bde79409dfdf16e
Kernel: (drm-intel-2.6.29) 0e56a4d653b66d4729f944b23935a00c4472f987
On Thu, Apr 02, 2009 at 11:53:50PM -0700, firstname.lastname@example.org wrote:
> --- Comment #12 from liuhaien <email@example.com> 2009-04-02 23:53:50 PST ---
> this issue has gone against below commits:
> Libdrm: (master)51d6346f9f3c425f49e57d185530c6bcaeb94f5e
> Mesa: (mesa_7_4_branch)7be149cfd131c0b3f7d4337bb83e6fba5f563bf9
> Xserver: (server-1.6-branch) 60c161545af80eb78eb790a05bde79409dfdf16e
> Xf86_video_intel: (2.7)10b5014c42dc055d9559ee112cc7a017e887d813
> Kernel: (drm-intel-2.6.29) 0e56a4d653b66d4729f944b23935a00c4472f987
I just checked out and tested all the latest versions and the glxgears
issue is not fixed. I mentioned in my patch that I haven't yet figured out
what exactly is causing this. Did I miss an additional fix or should I
reopen the bug?
The glxgears problem may be fence related, but it sounds like a separate bug (we may even have a report open about it already).
Liuhaien do you know which bug # the 8xx 3D issue is covered by?
Thanks again for your patch, Daniel... A lot of 8xx users out there thank you. :)
(In reply to comment #14)
> The glxgears problem may be fence related, but it sounds like a separate bug
> (we may even have a report open about it already).
> Liuhaien do you know which bug # the 8xx 3D issue is covered by?
> Thanks again for your patch, Daniel... A lot of 8xx users out there thank you.
bug #18878 #20473 are related to the 3D issue.