Dear stable-team, This patch won't apply (iirc it's been in the stable queue once already). I've forwarded the backport by Anisse Astier to stable a few days ago, message id:
<[email protected]> Yours, Daniel On Mon, Dec 06, 2010 at 12:59:27PM -0800, [email protected] wrote: > > This is a note to let you know that I've just added the patch titled > > intel-gtt: fix gtt_total_entries detection > > to the 2.6.36-stable tree which can be found at: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > The filename of the patch is: > intel-gtt-fix-gtt_total_entries-detection.patch > and it can be found in the queue-2.6.36 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <[email protected]> know about it. > > > From e5e408fc94595aab897f613b6f4e2f5b36870a6f Mon Sep 17 00:00:00 2001 > From: Daniel Vetter <[email protected]> > Date: Sat, 28 Aug 2010 11:04:32 +0200 > Subject: intel-gtt: fix gtt_total_entries detection > > From: Daniel Vetter <[email protected]> > > commit e5e408fc94595aab897f613b6f4e2f5b36870a6f upstream. > > In commit f1befe71 Chris Wilson added some code to clear the full gtt > on g33/pineview instead of just the mappable part. The code looks like > it was copy-pasted from agp/intel-gtt.c, at least an identical piece > of code is still there (in intel_i830_init_gtt_entries). This lead to > a regression in 2.6.35 which was supposedly fixed in commit e7b96f28 > > Now this commit makes absolutely no sense to me. It seems to be > slightly confused about chipset generations - it references docs for > 4th gen but the regression concerns 3rd gen g33. Luckily the the g33 > gmch docs are available with the GMCH Graphics Control pci config > register definitions. The other (bigger problem) is that the new > check in there uses the i830 stolen mem bits (.5M, 1M or 8M of stolen > mem). They are different since the i855GM. > > The most likely case is that it hits the 512M fallback, which was > probably the right thing for the boxes this was tested on. > > So the original approach by Chris Wilson seems to be wrong and the > current code is definitely wrong. There is a third approach by Jesse > Barnes from his RFC patch "Who wants a bigger GTT mapping range?" > where he simply shoves g33 in the same clause like later chipset > generations. > > I've asked him and Jesse confirmed that this should work. So implement > it. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16891$ > Tested-by: Anisse Astier <[email protected]> > Signed-off-by: Anisse Astier <[email protected]> > Signed-off-by: Daniel Vetter <[email protected]> > Signed-off-by: Chris Wilson <[email protected]> > Signed-off-by: Greg Kroah-Hartman <[email protected]> -- Daniel Vetter Mail: [email protected] Mobile: +41 (0)79 365 57 48 _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
