Created attachment 28004 [details]
Acer TravelMate 66x
00:02.0 VGA compatible controller :
Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
00:02.1 Display controller :
Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
- Distro: Gentoo
+ drm-intel-next from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
(up to 2a2430f4542467502d39660bfd66b0004fd8d6a9
drm/i915: correct self-refresh calculation in "everything off" case)
- KMS enabled
When starting up enlightenment X server freezes (access is still possible via SSH but responsiveness is bad). Note: without extra patches from Anholt's tree no interactive remote shell was possible anymore because of eventd/0 waiting on a i915 DRM mutex.
When doing the same with RENDER extension disabled in Xorg system is usable.
(same kind of freeze when using UMS though I have not tested it with disabled RENDER)
xf86-video-intel-2.7.1 worked more or less properly in UMS mode (freezes rare) but didn't work in KMS mode (freeze in that case). I haven't tested 2.7.1 behavior with RENDER disabled.
In follow-up attachments there is:
- output of intel_gpu_dump for frozen X
- output of intel_reg_dump for frozen X
- kernel log for frozen X
- Xorg.0.log for frozen X
Sidenote, the MCE error mentionned in kernel log corresponds to:
CPU 0 BANK 1 MCG status:
Processor context corrupt
MCA: Data CACHE Level-1 Instruction-Fetch Error
STATUS e200000000000155 MCGSTATUS 0
Probably unrelated as it happens on any system start at exactly the same uptime...
Created attachment 28005 [details]
intel_gpu_dump [frozen state]
Created attachment 28006 [details]
intel_reg_dump [frozen state]
Created attachment 28007 [details]
kernel log up to frozen state
Created attachment 28008 [details]
Xorg log up to frozen state
One applied kernel patch I forgot to mention is attachment #27810 [details] [review] from bug #20115. (Without that one nothing visible on LVDS)
Thank you for your bug report about freezes when using the Render extension with an 855.
I know that Eric Anholt recently discovered that with some 8xx hardware, the Render acceleration code in the driver was unstable and would regularly cause freezes. I think his plan is to remove/disable that code for now.
I'm including him on the CC list for this bug so that he can confirm or deny this.
wish to fix in 2.9
This sounds like a bug that should be fixed with the patch posted by Eric
yesterday. Please see bug #22904 for the patch, and please report there
if the patch fixes your bug. (If it doesn't then we can reopen this
bug as not being a duplicate.)
Thanks for your report!
*** This bug has been marked as a duplicate of bug 22904 ***
(In reply to comment #8)
> This sounds like a bug that should be fixed with the patch posted by Eric
> yesterday. Please see bug #22904 for the patch, and please report there
> if the patch fixes your bug. (If it doesn't then we can reopen this
> bug as not being a duplicate.)
> Thanks for your report!
> *** This bug has been marked as a duplicate of bug 22904 ***
I tried the patch mentionned at the end of bug 22904 [agp/intel: Fix the pre-9xx chipset flush] (applied on top of linux-2.6.31) but X did still freeze on me...
Only mouse pointer was alive on the graphics side.
In follow-up attachments various information that might help understand the freeze (kernel log with dump of task kernel stacks, gpudump, regdump, xorg log).
My steps were: start X + enlightenment, then reenable render engine for enlightenment, soon after which graphics output did freeze. (system was still reachable via network/ssh)
Created attachment 29430 [details]
kernel log (with 'sysrq-t')
Created attachment 29431 [details]
intel_reg_dump (while frozen)
Created attachment 29432 [details]
Created attachment 29433 [details]
intel_gpu_dump (while frozen, bzip2 compressed)
Created attachment 29704 [details] [review]
Set texture vertext data format and type for projective transforms
This appears to hit the projective transform path within the i8xx render code due to a slightly imprecise computation of the transform within e17 (it's so close to affine, but not quite there).
Reviewing that code yielded several mistakes, from not actually setting the texture coordinate type and format to sending four values per texture coordinate instead of three.
This patch is entirely untested, but tries to follow the documentation.
Created attachment 29724 [details]
GPU dump for driver with patch applied (while frozen, bzip2 compressed)
(In reply to comment #14)
> Created an attachment (id=29704) [details]
> Set texture vertext data format and type for projective transforms
> This appears to hit the projective transform path within the i8xx render code
> due to a slightly imprecise computation of the transform within e17 (it's so
> close to affine, but not quite there).
> Reviewing that code yielded several mistakes, from not actually setting the
> texture coordinate type and format to sending four values per texture
> coordinate instead of three.
> This patch is entirely untested, but tries to follow the documentation.
It does not help in my case (though I have no idea if it does anything bad either)
Attached is a gpudump (bz2 compressed) when having patch in attachment #29704 [details] [review] applied on top of git (b4d29452b929a3ef224d3625e4bc66b787c5edb7 - More dumps for Arrandale LVDS) with 2.6.31 kernel and GPU still freezing
Created attachment 29727 [details] [review]
Fallback to software for non-affine transformations
Thanks for testing Keith's patch. We worked with it a bit and fixed on
ebug in it, (examining the transform for is_affine before the
transform is actually initialized), but we also couldn't get it to
Here's another patch instead. This just bypasses the known-buggy
driver code by simply falling back to software for any projective
In my testing on an 865, this patch fixes the hangs when running
enlightenment. It also does mean that enlightenment runs quite a bit
more slowly, but this could be addressed by fixing enlightenment to
not set a projective transformation when not necessary, (for example,
when doing integer translation for moving a window, etc.). It appears
that enlightenment has a rounding bug preventing these
very-close-to-affine transformations from being recognized as affine.
I'm planning to push this change now, (and close this bug
report). Please feel free to reopen the report if you find any further
Fixed in xf86-video-intel master now.
Author: Carl Worth <firstname.lastname@example.org>
Date: Mon Sep 21 13:50:09 2009 -0700
8xx: Fallback for any non-affine transformation.
There are definitely bugs in the 8xx code dealing with non-affine
transformations. Disable that code for now to get things working.
Fixes bug #22947 ([855GM, xf86-video-intel-2.8.0] "Freeze" when RENDER extension is being used)
Created attachment 29728 [details] [review]
Corrected version of Keith's patch
Note this patch simply comments out Carl's workaround and will break i915 - so only use it for testing on i8xx boxes!
Hopefully final update... Keith split the i915 code paths from the i830, making the way clear to apply this patch.
Author: Keith Packard <email@example.com>
Date: Sat Sep 19 17:30:57 2009 -0700
i8xx: Format projective texture coordinates correctly.
Projective texture coordinates must be delivered as TEXCOORDFMT_3D
using TEXCOORDTYPE_HOMOGENOUS. This meant selecting the correct type
in i830_texture_setup, the correct format in i830_emit_composite_state
and sending only 3 coordinates in i830_emit_composite_primitive.
Signed-off-by: Keith Packard <firstname.lastname@example.org>
[ickle: tweaked to fix up a couple of use-before-initialised]
Signed-off-by: Chris Wilson <email@example.com>
Note that the current state of the driver means that code such as enlightenment
should run stably, and should also be plenty fast. Many thanks to Keith and
Chris for helping to eliminate my workaround.
Keith, Carl, Chris,
Thanks for the fix! I've not caught a freeze yet while running on xf86-video-intel GIT (7e7db7ac530b5282b0841585959597b54fcc633b - Add new backlight driver "samsung") for a dozzen minutes now.
And scrolling in Firefox is no more a CPU and time hog :)
In addition some artifacts on text redrawing (usually after tool-tip disappears/moves) seem gone (were white text on black background instead of the opposite plus a few white pixels spread around) - probably an issue with write-through, cacheline & co for software mode that does not show up anymore as render skips that code path.