Latest working kernel version: 22.214.171.124
Earliest failing kernel version: 2.6.28-rc4
Distribution: Fedora 10
Hardware Environment: Lenovo ThinkPad X61s
Software Environment: Fedora 10 Preview
I'm using Fedora 10 tree with custom compiled kernel (from kernel.org, no additional patches). In 2.6.28-rc4 i915 DRM is badly broken and it completely breaks X. I will attach screenshots. Additional information:
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 20b5
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f8100000 (64-bit, non-prefetchable) [size=1M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Capabilities:  Message Signalled Interrupts: Mask- 64bit- Count=1/1 Enable-
Capabilities: [d0] Power Management version 3
Fedora X server (1.5.2 + patches)
Fedora Intel driver (2.5.0 + patches)
Steps to reproduce:
Boot 2.6.28-rc4 or 2.6.28-rc4-git5 and try use i915 DRM. Screen is corrupted
Screenshots are on http://atkac.fedorapeople.org/i915-corruption/ (created via xwd, open it via "xwud < screenshot")
Notify-Also : Jesse Barnes <firstname.lastname@example.org>
anyone else confirm this is broken?
I have an i915 mobo, specs and backtraces and other info found in the bugs I posted on freedesktop....
If I have more than 4 gigs of ram, X may display corrupted graphics and will lock quickly.
Didn't have the issue in 2.4.2 on an older kernel.
If I play videos in mplayer w/ GL output while it's rendering subtitles, text becomes corrupt in mplayer, and X will hardlock very quickly. If I SSH in and kill X, I can't restart it as the card is put into a bad state.
Also didn't have the issue in 2.4.2 on an older kernel.
If UXA is off(it is by default), and I have < 4 gigs of ram, _AND_ the option in the bios to set aside memory for the gpu is set to as low as possible(32 vs 128, this is key), and I don't run a compositing 3d window manager, and I don't watch videos with subtitles, and I run the latest git builds of mesa, anholt's kernel patches, libdrm, with divine intervention and angels swarming to caress my pc gently, X is stable.
Anything less and X will lock instantly after getting in.
Notify-Also : Dylan Taft <email@example.com>
Problem still exists in 2.6.28-rc6-git1
Adam, does your corruption look like Dylan's? To me that looks like a render acceleration bug. Try adding Option "ExaNoComposite" "true" to your xorg.conf intel driver section and see if that prevents the corruption. If that prevents the corruption/hangs, this may actually be a 2D driver bug that happens to be triggered by a new DRM (which enables GEM support).
(In reply to comment #7)
> Adam, does your corruption look like Dylan's? To me that looks like a render
> acceleration bug. Try adding Option "ExaNoComposite" "true" to your
> intel driver section and see if that prevents the corruption. If that
> the corruption/hangs, this may actually be a 2D driver bug that happens to be
> triggered by a new DRM (which enables GEM support).
No, ExaNoComposite option doesn't help. Btw I'm not using EXA at all, currently I'm using XAA due different bug.
I think this problem is kernel issue but I don't know how get more debug information. There is nothing interesting in kernel/system/Xorg logs. Let me know if you have any hints.
Please try current Linus' tree, it contains several important DRM fixes.
(In reply to comment #9)
> Please try current Linus' tree, it contains several important DRM fixes.
Still broken in 2.6.28-rc7-git1, I don't see any improvement.
Ok, so what do you see if you use EXA (and out of curiosity what's the other bug you're avoiding by using XAA)?
Adam, any news?
(In reply to comment #11)
> Ok, so what do you see if you use EXA (and out of curiosity what's the other
> bug you're avoiding by using XAA)?
Sorry for late response. If I use EXA everything seems fine. Main problem with EXA is https://bugzilla.redhat.com/show_bug.cgi?id=448369 - it is very slow for some programs. After quick testing EXA is not so bad as written in that bugreport but it is slower than XAA. XAA still isn't working.
Adding Eric, this may be GEM related.
The current XAA userland bits are regularly broken and we're not putting any effort into fixing them since it's a dead end path. If EXA works, I'd call this WONTFIX.
Dylan's (likely unrelated bug due to PAE) is already fixed.
(In reply to comment #15)
> The current XAA userland bits are regularly broken and we're not putting any
> effort into fixing them since it's a dead end path. If EXA works, I'd call
> this WONTFIX.
If XAA is dead you can close this bug. Btw it would be nice to disable XAA in Xorg as well to avoid future problems.