<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/gpu, branch v2.6.27.25</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/gpu?h=v2.6.27.25</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/gpu?h=v2.6.27.25'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2009-05-08T21:54:33Z</updated>
<entry>
<title>drm/i915: add support for G41 chipset</title>
<updated>2009-05-08T21:54:33Z</updated>
<author>
<name>Zhenyu Wang</name>
<email>zhenyu.z.wang@intel.com</email>
</author>
<published>2008-11-17T05:58:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1beaf51ea30d9bc4c8b40391b230da59500835c2'/>
<id>urn:sha1:1beaf51ea30d9bc4c8b40391b230da59500835c2</id>
<content type='text'>
commit 72021788678523047161e97b3dfed695e802a5fd upstream.

This had been delayed for some time due to failure to work on the one piece
of G41 hardware we had, and lack of success reports from anybody else.
Current hardware appears to be OK.

Signed-off-by: Zhenyu Wang &lt;zhenyu.z.wang@intel.com&gt;
[anholt: hand-applied due to conflicts with IGD patches]
Signed-off-by: Eric Anholt &lt;eric@anholt.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831)</title>
<updated>2008-10-22T21:21:29Z</updated>
<author>
<name>Matthias Hopf</name>
<email>mhopf@suse.de</email>
</author>
<published>2008-10-17T21:18:05Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f8d61d1be61999a76cb207125d3bfb1885cd40eb'/>
<id>urn:sha1:f8d61d1be61999a76cb207125d3bfb1885cd40eb</id>
<content type='text'>
commit 4b40893918203ee1a1f6a114316c2a19c072e9bd upstream

Olaf Kirch noticed that the i915_set_status_page() function of the i915
kernel driver calls ioremap with an address offset that is supplied by
userspace via ioctl. The function zeroes the mapped memory via memset
and tells the hardware about the address. Turns out that access to that
ioctl is not restricted to root so users could probably exploit that to
do nasty things. We haven't tried to write actual exploit code though.

It only affects the Intel G33 series and newer.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>drm/radeon: downgrade debug message from info to debug.</title>
<updated>2008-08-31T22:51:52Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2008-08-31T22:51:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6c7be29810dd85b4fe75588ec536446c1579d492'/>
<id>urn:sha1:6c7be29810dd85b4fe75588ec536446c1579d492</id>
<content type='text'>
If this triggers its bad, however some machines seem to have been
triggering it for ages and we didn't know until we added the debug.

So downgrade the debug now so people don't call this a regression.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'drm-patches' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6</title>
<updated>2008-08-27T21:28:45Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-08-27T21:28:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2caf959966d540c9a2358c6b74f67aa86248e34b'/>
<id>urn:sha1:2caf959966d540c9a2358c6b74f67aa86248e34b</id>
<content type='text'>
* 'drm-patches' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
  drm: don't set the signal blocker on the master process.
  drm: don't call the vblank tasklet with irqs disabled.
  r300: Fix cliprect emit
  drm/radeon: r300_cmdbuf: Always emit INDX_BUFFER immediately after DRAW_INDEX
  radeon: fix some hard lockups on r3/4/500s
</content>
</entry>
<entry>
<title>drm: don't set the signal blocker on the master process.</title>
<updated>2008-08-24T20:35:33Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@linux.ie</email>
</author>
<published>2008-08-24T07:02:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3e5fc80a404a24c858468030b63555cccfb3e79c'/>
<id>urn:sha1:3e5fc80a404a24c858468030b63555cccfb3e79c</id>
<content type='text'>
There is a problem with debugging the X server and gdb crashes in
the xkb startup code.

This avoids the problem by allowing the master process to get signals.
It should be safe as the signal blocker is mainly so that you can
Ctrl-Z a 3D application without locking up the whole box. Ctrl-Z the
X server isn't something many people do.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm: don't call the vblank tasklet with irqs disabled.</title>
<updated>2008-08-24T20:35:21Z</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thomas-at-tungstengraphics-dot-com</email>
</author>
<published>2008-08-24T07:00:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e5b4f19417b75a2d7c1e36934f60a3e836c4337e'/>
<id>urn:sha1:e5b4f19417b75a2d7c1e36934f60a3e836c4337e</id>
<content type='text'>
If a specific tasklet shares data with irq context,
it needs to take a private irq-blocking spinlock within
the tasklet itself.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>r300: Fix cliprect emit</title>
<updated>2008-08-24T20:35:12Z</updated>
<author>
<name>Nicolai Haehnle</name>
<email>nhaehnle@gmail.com</email>
</author>
<published>2008-08-12T23:50:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=649ffc06a62bf487b78440669bdfeb637f1d675b'/>
<id>urn:sha1:649ffc06a62bf487b78440669bdfeb637f1d675b</id>
<content type='text'>
This makes our handling of cliprects sane. drm_clip_rect always has exclusiv
bottom-right corners, but the hardware expects inclusive bottom-right corner
so we adjust this here.

This complements Michel Daenzer's commit 57aea290e1e0a26d1e74df6cff777eb9f03
to Mesa. See also http://bugs.freedesktop.org/show_bug.cgi?id=16123

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/radeon: r300_cmdbuf: Always emit INDX_BUFFER immediately after DRAW_INDEX</title>
<updated>2008-08-24T20:35:05Z</updated>
<author>
<name>Nicolai Haehnle</name>
<email>nhaehnle@gmail.com</email>
</author>
<published>2008-08-12T23:49:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e2898c5fdd91f54c9c84fbf7d32edb8e4dfda574'/>
<id>urn:sha1:e2898c5fdd91f54c9c84fbf7d32edb8e4dfda574</id>
<content type='text'>
DRAW_INDEX writes a vertex count to VAP_VF_CNTL. Docs say that behaviour
is undefined (i.e. lockups happen) when this write is not followed by the
right number of vertex indices.

Thus we used to do the wrong thing when drawing across many cliprects was
necessary, because we emitted a sequence
DRAW_INDEX, DRAW_INDEX, INDX_BUFFER, INDX_BUFFER
instead of
DRAW_INDEX, INDX_BUFFER, DRAW_INDEX, INDX_BUFFER
The latter is what we're doing now and which ought to be correct.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>radeon: fix some hard lockups on r3/4/500s</title>
<updated>2008-08-24T20:34:58Z</updated>
<author>
<name>Jerome Glisse</name>
<email>glisse@freedesktop.org</email>
</author>
<published>2008-08-12T23:46:31Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=54f961a628b737f66710eca0b0d95346645dd33e'/>
<id>urn:sha1:54f961a628b737f66710eca0b0d95346645dd33e</id>
<content type='text'>
This patch should fix hard lockup and convert them in
softlockup (ie you can ssh the box but the gpu is busted
and we are waiting in loop for it to come back to reason).

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>Remove newline from the description of module parameters</title>
<updated>2008-08-01T19:46:41Z</updated>
<author>
<name>Niels de Vos</name>
<email>niels@nixpanic.net</email>
</author>
<published>2008-07-31T07:07:23Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=61a2d07d3fb1ac34d142b9b62d4cd60a0f8c229e'/>
<id>urn:sha1:61a2d07d3fb1ac34d142b9b62d4cd60a0f8c229e</id>
<content type='text'>
Some module parameters with only one line have the '\n' at the end of the
description.  This is not needed nor wanted as after the description the
type (i.e.  int) is followed by a newline.

Some modules contain a multi-line description, these are not affected
by this patch.

Signed-off-by: Niels de Vos &lt;niels.devos@wincor-nixdorf.com&gt;
Acked-by: Randy Dunlap &lt;randy.dunlap@oracle.com&gt;
Cc: John W. Linville &lt;linville@tuxdriver.com&gt;
Cc: Ed L. Cashin &lt;ecashin@coraid.com&gt;
Cc: Dave Airlie &lt;airlied@linux.ie&gt;
Cc: Roland Dreier &lt;rolandd@cisco.com&gt;
Acked-by: Mauro Carvalho Chehab &lt;mchehab@infradead.org&gt;
Cc: Jeff Garzik &lt;jeff@garzik.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
