-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/20/2011 01:24 AM, Nicolas Kalkhof wrote: > Hi Ian, > > ok I've definately nailed the issue down to the "i915_enable_rc6" parameter > in i915_drv.c > Someone disabled this parameter and that causes the depthbuffer issue. I've > enabled the switch by setting i915_enable_rc6=1; and the problem dissapeared. > > glxinfo | grep "OpenGL renderer" shows: > OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile > > lspci -vn | grep VGA yields: > 00:02.0 0300: 8086:0126 (rev 09) (prog-if 00 [VGA controller]) > > My CPU is a SNB I72620M with a 3000 graphics. No other GPU present. > > Stupid question: Can I file a bug report on https://bugs.freedesktop.org or > on https://bugzilla.kernel.org/
bugzilla.kernel.org is the right place. Please include all of the information from this e-mail and the image showing the corruption. > -----Ursprüngliche Nachricht----- > Von: "Ian Romanick" <i...@freedesktop.org> > Gesendet: Jul 19, 2011 11:08:14 PM > An: "Nicolas Kalkhof" <nkalk...@web.de> > Betreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games > > On 07/19/2011 01:21 PM, Nicolas Kalkhof wrote: >>>> Hi all, >>>> >>>> ok I've nailed the issue down to 3.0.0-rc7 and 3.0.0-rc7-git1. I suspect >>>> that the changes made in >>>> drivers/gpu/drm/i915/i915_dma.c are the cause of the problem. >>>> >>>> http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.0%2Fsnapshots%2Fpatch-3.0-rc7-git1.bz2;z=14 >>>> >>>> Any Clues? > > Okay, so that's the commit below, which changes some error clean-up > paths. That is also odd. What *exact* GPU do you have? Specificially, > what's the output of > > glxinfo | grep "OpenGL renderer" > > and > > lspci -vn | grep VGA > > Does this appear in all games or just certain games? If it's just in > certain games, which ones? > > commit a7b85d2aa63ed09cd5a4a640772b3272f5ac7caa > Author: Keith Packard <kei...@keithp.com> > Date: Sun Jul 10 13:12:17 2011 -0700 > > drm/i915: Clean up i915_driver_load failure path > > i915_driver_load adds a write-combining MTRR region for the GTT > aperture to improve memory speeds through the aperture. If > i915_driver_load fails after this, it would not have cleaned up the > MTRR. This shouldn't cause any problems, except for consuming an MTRR > register. Still, it's best to clean up completely in the failure path, > which is easily done by calling mtrr_del if the mtrr was successfully > allocated. > > i915_driver_load calls i915_gem_load which register > i915_gem_inactive_shrink. If i915_driver_load fails after calling > i915_gem_load, the shrinker will be left registered. When called, it > will access freed memory and crash. The fix is to unregister the > shrinker in the > failure path using code duplicated from i915_driver_unload. > > i915_driver_load also has some incorrect gotos in the error cleanup > paths: > > * After failing to initialize the GTT (which cannot happen, btw, > intel_gtt_get returns a fixed (non-NULL) value), it tries to > free the uninitialized WC IO mapping. Fixed this by changing the > target from out_iomapfree to out_rmmap > > Signed-off-by: Keith Packard <kei...@keithp.com> > Tested-by: Lin Ming <ming.m....@intel.com> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4m6yAACgkQX1gOwKyEAw/6MQCgjs/YWI3rpwN8XsgHy/rwuq5P c84AnjsjBjudlE9QZBuLFhuZgW+giw+/ =eJ0i -----END PGP SIGNATURE----- _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
