| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
The docs state bits 4-11 represent bits 32-39 of a 40-bit address
|
|
doesn't fix anything but just making it consistent
|
|
|
|
The i915_vblank_swap() function schedules an automatic buffer swap
upon receipt of the vertical sync interrupt. Such an operation is
lengthy so it can't be allowed to happen in normal interrupt context,
thus the DRM implements this by scheduling the work in a kernel
softirq-scheduled tasklet. In order for the buffer swap to work
safely, the DRM's central lock must be taken, via a call to
drm_lock_take() located in drivers/char/drm/drm_irq.c within the
function drm_locked_tasklet_func(). The lock-taking logic uses a
non-interrupt-blocking spinlock to implement the manipulations needed
to take the lock. This semantic would be safe if all attempts to use
the spinlock only happen from process context. However this buffer
swap happens from softirq context which is really a form of interrupt
context. Thus we have an unsafe situation, in that
drm_locked_tasklet_func() can block on a spinlock already taken by a
thread in process context which will never get scheduled again because
of the blocked softirq tasklet. This wedges the kernel hard.
To trigger this bug, run a dual-head cloned mode configuration which
uses the i915 drm, then execute an opengl application which
synchronizes buffer swaps against the vertical sync interrupt. In my
testing, a lockup always results after running anywhere from 5 minutes
to an hour and a half. I believe dual-head is needed to really
trigger the problem because then the vertical sync interrupt handling
is no longer predictable (due to being interrupt-sourced from two
different heads running at different speeds). This raises the
probability of the tasklet trying to run while the userspace DRI is
doing things to the GPU (and manipulating the DRM lock).
The fix is to change the relevant spinlock semantics to be the
interrupt-blocking form. After this change I am no longer able to
trigger the lockup; the longest test run so far was 20 hours (test
stopped after that point).
Note: I have examined the places where this spinlock is being
employed; all are reasonably short bounded sequences and should be
suitable for interrupts being blocked without impacting overall kernel
interrupt response latency.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
|
|
|
|
If we ever want to be able to use the 3D engine we have no choice. It
appears that the tiling setup (required for 3D on G8x) is in the page tables.
The immediate benefit of this change however is that it's now not possible
for a client to use the GPU to render over the top of important engine setup
tables, which also live in VRAM.
G8x VRAM size is limited to 512MiB at the moment, as we use a 1-1 mapping
of real vram pages to their offset within the start of a channel's VRAM
DMA object and only populate a single PDE for VRAM use.
|
|
Conflicts:
linux-core/drm_compat.c
linux-core/drm_compat.h
linux-core/drm_ttm.c
shared-core/i915_dma.c
Bump driver minor to 13 due to introduction of new
relocation type.
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
Disable page saving for GPU read-only TTMs.
|
|
NO_EVICT buffers.
|
|
|
|
|
|
|
|
(Alan Hourihane)
|
|
|
|
|
|
|
|
If the master fd goes away before the aiglx fd, we try and get a lock
that actually doesn't exist.
|
|
they are not pipe A specific. Remove pipe B code.
|
|
Also adjust i915 irq handling as it follows the 16bit'ism's
of the i8xx series.
|
|
Also, power cycle PGRAPH when resetting AGP -- it seems to fix problems encountered by p0g on nv25
|
|
if we are unloading the module, there is no master so therefore no lock
|
|
|
|
into modesetting-101
|
|
|
|
|
|
My 965GM gets interrupts stuck when using the old PIPE_VBLANK interrupt.
Switch to the PIPE_EVENT interrupt mechanism, and set the PIPE*STAT
registers to use START_VBLANK on 965 and VBLANK on previous chips.
|
|
|
|
|
|
Will hopefully work a bit better than previous code, which depended on
knowing the channel's most recent PUT value. Some chips always return
0 on reading these regs, and currently userspace is the only other entity
which knows the value.
|
|
Not only was this entirely pointless, it actually causes my NV30GL to
die randomly when channels are destroyed.
|
|
just flip the framebuffer in when required.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
modprobe can be run with dropped capabilities we still want the kernel bos
to work.
|
|
|
|
fix bo handle
|
|
|
|
|
|
|
