Age | Commit message (Collapse) | Author |
|
- logic was wrong. rs400/rs480 should clear the RADEON_BUS_MASTER_DIS bit
- should fix kernel bug 11798
|
|
rs400 is just like rs480. I mixed up the internal
chipset names for rs600 and rs400.
|
|
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.
|
|
|
|
|
|
|
|
Don't count on ioctl returning -errno; use errno directly.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
|
|
|
|
|
|
libdrm_intel needs symbols from libdrm, so link against it.
|
|
Bug #18035. Fixes deadlock in glean texCube testcase.
|
|
|
|
|
|
Allocate memory from different pools. This allows the OS to track memory
allocations for us, much like the linux memory debugging. This will ease
tracking down memory leaks since the OS can track the number of allocations
from each pool and help to point us in the right direction. Also replace
drm_alloc and friends with static __inline__ versions while we are here.
|
|
linux_for_each_safe would not handle lists with a single entry.
|
|
|
|
When using bufmgr_fake without DRM, the X server idles the ring whenever it
wants to wait for something to complete (brutal, but effective). In this
case, bufmgr_fake must treat the pending fence as having passed. However, it
wasn't recording the fences as it emitted them, nor cleaning buffers as they
passed.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
We want to be able to use the bufmgr from multiple threads for GL, and thus
we need to protect the internal structures.
The pthread-stubs package is used so that programs not linked against
pthreads get weak symbols to stubs and don't eat most of the cost.
|
|
http://bugs.freedesktop.org/show_bug.cgi?id=17705
|
|
|
|
That's what I get for committing at 3 AM.
|
|
|
|
|
|
|
|
See bug 17908
|
|
|
|
This is already handled for us.
Suggested by John Baldwin
|
|
We don't explicitly check for error here and M_WAITOK will just put the
process to sleep waiting on resources to become available.
Suggested by John Baldwin
|
|
|
|
d_mmap gets called twice and we are only able to associate the file_priv
during the first call. The second call will return EBADF and we need to
assume that the call was succesful. d_mmap will not tolerate having an
error returned for the second call.
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=17705
|
|
The gltestperf demo in some cases took over seven seconds to make it through
one batchbuffer on a GM965.
Bug #17004.
|
|
I'd swapped the operands, so if we weren't in lockstep with the hardware we
said the sequence was always passed. Additionally, a race was available that
we might have failed at recovering from. Instead, I've replaced the logic
with new stuff that should be more robust and not rely on all the parties in
userland following the same IRQ_EMIT() == 1 protocol. Also, in a radical
departure from past efforts, include a long comment describing the failure
modes and how we're working around them.
Thanks to haihao for catching the original issue.
|
|
|
|
|
|
|
|
This just doesn't look right..
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
Reported by jcristau.
|
|
Thanks to airlied for catching this.
|
|
This avoids duplicating the effort in 3 places. Also, added emit/wait fence
callbacks back in bufmgr_fake since we need it for non-drm 2d. Sigh.
|
|
In the process, work around the glaring bugs of the kernel irq wait function.
|
|
dri_bufmgr.h is replaced by intel_bufmgr.h, and several functions are renamed,
though the structures and many functions remain dri_bufmgr_* and dri_bo_*
|
|
|
|
The driver is in control of the show, so when you try and unload a module
the driver detach routine is called first. It is what drives the whole
unload process and so lots of panics occur if dev->driver is already
free.
|