Bug 18503

Created attachment 20256 [details]
photo of the screen corruption

Somehow managed to get a shot of the corruption.

Thanks

Does it work if you disable FBC?

No, the corruption is still there.

Thanks

As I said in bug #18138, with the drm-intel-2.6.28 branch there's no screen corruption with -intel 2.5.1 and xorg 1.5.3.

I'll bisect the kernel to see what change fixed this.

Thanks

Like in bug #18138, I was wrongly using drm driver i830 instead of i915. The bug is still there.

I have two machines with similar hardware, but only one of them shows the kind of screen corruption that Rémi described. The other one works flawlessly.

Both systems use the same kernel image and user space:
xf86-video-intel-2.5.1-r1 (Gentoo)
libdrm-2.4.3 (Gentoo)
xorg-server-1.5.3 (Gentoo)
linux-2.6.28 (kernel.org)

I will attach the X log files from both systems. Maybe the differences help to narrow down the problem.

Created attachment 21901 [details]
Xorg.0.tpx40.log

IBM Thinkpad X40 / 855GME / no screen corruption

Created attachment 21902 [details]
Xorg.0.p1733.log

DFI G5M150-N motherboard / 852GME / major screen corruption

The problem persists with xf86-video-intel-2.5.99.2 and linux-2.6.29-rc1.

Persists with xf86-intel-video-2.6.1 and kernel (gentoo-source-2.6.28-r1)
Some fonts display a bold style and then a normal style randomly, then some fonts blur (as time goes), sometimes very serious (see the screenshot)

Created attachment 22566 [details]
screen corruption on my ASUS Z9100N

(In reply to comment #10)
> Some fonts display a bold style and then a normal style randomly, then some
> fonts blur (as time goes), sometimes very serious (see the screenshot)

This is a different bug. The screen corruption described in this bug affects large areas of the screen and disappears when the screen is redrawn. The fonts, on the other hand, remain corrupted when the screen is redrawn.

[cee1, I'm CCing you because you may want to file a separate report.]

The screen corruption no longer occurs when I disable tiling (Option "Tiling" "false"). But I think that the real problem is only hidden, because sometimes pixmaps become corrupted in a similar way. This corruption is much harder to reproduce, though.

(In reply to comment #12)
> This is a different bug. The screen corruption described in this bug affects
> large areas of the screen and disappears when the screen is redrawn. The fonts,
> on the other hand, remain corrupted when the screen is redrawn.

On second thought, both problems can be related if a more general memory corruption is involved.

After upgrading the driver to revision 38a7683561cee7fffab174c2a166bfd51b51ba27, I have not seen any screen corruption in two days. (I am still using xorg-server-1.5.3 and Linux-2.6.28.7.)

Can the other reporters confirm that the issue is resolved?

On my part, this bug seems to have been fixed in between 2.6.1 and 2.6.2. And bug #18138 seems to have been fixed in the process as well.

I'll try to bisect to figure out which commit(s) fixed it.

Thanks

On my part I can't tell anything as Xorg is crashing with xf86-video-intel-2.6.2 :(

It starts up but screen remains black (e.g. not drawing the standard X background and cursor), then when I start an X application Xorg crashes.

Xorg libraries (please ask if version of other libraries are needed):
x11-base/xorg-server-1.5.3-r2
x11-libs/libdrm-2.4.5
x11-drivers/xf86-video-intel-2.6.2

Kernel:
linux-2.6.29-rc6-git7


Xorg stacktrace (as obtained from gdb when running Xorg under gdb):
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7af16c0 (LWP 2195)]
0xb7f2e424 in __kernel_vsyscall ()
(gdb) backtrace
#0  0xb7f2e424 in __kernel_vsyscall ()
#1  0xb7b1c191 in raise () from /lib/libc.so.6
#2  0xb7b1d978 in abort () from /lib/libc.so.6
#3  0xb7b157b5 in __assert_fail () from /lib/libc.so.6
#4  0xb79ccc2a in drm_intel_fake_bo_exec (bo=0x99473a8, used=536, 
    cliprects=0x0, num_cliprects=0, DR4=-1) at intel_bufmgr_fake.c:1365
#5  0xb79ca63e in drm_intel_bo_exec (bo=0x99473a8, used=536, cliprects=0x0, 
    num_cliprects=0, DR4=-1) at intel_bufmgr.c:143
#6  0xb79ea49f in intel_batch_flush (pScrn=0x99361f8, flushed=0)
    at i830_batchbuffer.c:199
#7  0xb7a12534 in i830_uxa_prepare_access (pixmap=0x9988430, 
    access=UXA_ACCESS_RW) at i830_exa.c:807
#8  0xb7a26c94 in uxa_prepare_access (pDrawable=0x9988430, 
    access=UXA_ACCESS_RW) at uxa.c:155
#9  0xb7a272f1 in uxa_validate_gc (pGC=0x99be4b0, changes=8387583, 
    pDrawable=0x99be060) at uxa.c:247
#10 0x081678b9 in damageValidateGC (pGC=0x99be4b0, changes=8388607, 
    pDrawable=0x99be060) at damage.c:445
#11 0x08095f95 in ValidateGC (pDraw=0x99be060, pGC=0x99be4b0) at gc.c:79
#12 0x08084ff1 in ProcPolyFillRectangle (client=0x99b7f18) at dispatch.c:1788
#13 0x08088114 in Dispatch () at dispatch.c:454
#14 0x0806e95b in main (argc=1, argv=0xbf8476e4, envp=) at main.c:441

(In reply to comment #17)
> On my part I can't tell anything as Xorg is crashing with
> xf86-video-intel-2.6.2 :(

Crash fixed with xf86-video-intel-2.6.3.

For a few tenth of minutes runtime I have not seen any corruption yet so it looks pretty good so I can disappearance of corruption mentioned in comment #15 and comment #16

Created attachment 23563 [details]
Screeshot (photo) of scrambled tiles

With 2.6.3 driver, after rebooting I got scrambled display as visible on attached picture (I would have expected blue-sky background with gkrellm in top-right corner and enlightenment panel in bottom/middle) - rebooting a few times did not change anything.

Disabling tiling in Xorg config (option "tiling" "no") got me back to the expected display content.

So I assume the good results I got yesterday were due to 2.6.1 properly configuring tiling and 2.6.3 just reusing the tiling configuration.
After reboot with immediate use of 2.6.3 it fails.

I'm adding myself here because I have reproducible scenarii for artifacts
with EXA/855GM with and without tiling (kernel 2.6.29, video-intel-2.6.99-902). 

comment #16 by reporter says this is fixed.

Unfortunately, no. There is no longer corruption of the screen but single letters in fonts in both console and Firefox 3. I don't have a single reproduction sequence, however, that's why the silence. Furthermore, I'm switching to a Mac, so I might not available for testing in a few weeks.

(In reply to comment #22)
> Unfortunately, no. There is no longer corruption of the screen but single
> letters in fonts in both console and Firefox 3.

Sounds like bug #21790, update your kernel to the latest intel-drm-next branch and it should be fixed.

Closing