Bug 12028
Summary: | i915 DRM is broken in 2.6.28-rc4 | ||
---|---|---|---|
Product: | Drivers | Reporter: | Adam Tkac (vonsch) |
Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
Status: | CLOSED WILL_NOT_FIX | ||
Severity: | normal | CC: | bug-track, eric, hatsmagee, jbarnes, rjw |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.28-rc4 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 11808 |
Description
Adam Tkac
2008-11-14 01:50:33 UTC
Screenshots are on http://atkac.fedorapeople.org/i915-corruption/ (created via xwd, open it via "xwud < screenshot") Notify-Also : Jesse Barnes <jbarnes@virtuousgeek.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. https://bugs.freedesktop.org/show_bug.cgi?id=18082 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. https://bugs.freedesktop.org/show_bug.cgi?id=18402 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 <soundmanok@yahoo.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 > 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). > 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. |