Created attachment 28004 [details] xorg.conf System details: - Hardware: Acer TravelMate 66x 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) - Distro: Gentoo - x11-base/xorg-server-1.6.2-r1 - x11-drivers/xf86-video-intel-2.8.0 - x11-libs/libdrm-2.4.12 - media-libs/mesa-7.5-r2 - Kernel: - 2.6.31-rc4 + 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 - xorg.conf Sidenote, the MCE error mentionned in kernel log corresponds to: CPU 0 BANK 1 MCG status: MCi status: Error overflow Uncorrected error 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)
Hi Bruno, 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. -Carl
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! -Carl *** 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! > > -Carl > > > *** 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] Xorg log
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 Bruno, 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 work. Here's another patch instead. This just bypasses the known-buggy driver code by simply falling back to software for any projective transformation matrix. 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 problems. Thanks again, -Carl
Fixed in xf86-video-intel master now. -Carl commit 505025053d66d415e1c23ac858b9238fa8541d37 Author: Carl Worth <cworth@cworth.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. commit 2cc1f3cb6034dddd65b3781b0cde7dff4ac1e803 Author: Keith Packard <keithp@keithp.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 <keithp@keithp.com> [ickle: tweaked to fix up a couple of use-before-initialised] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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. -Carl
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.