mirror of
https://gitlab.freedesktop.org/mesa/drm.git
synced 2026-01-04 04:00:20 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/drm
ae1bb96a7e
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> |
||
|---|---|---|
| bsd-core | ||
| libdrm | ||
| linux-core | ||
| scripts | ||
| shared-core | ||
| tests | ||
| .gitignore | ||
| autogen.sh | ||
| configure.ac | ||
| libdrm.pc.in | ||
| Makefile.am | ||
| README | ||
DRM README file There are two main parts to this package: the DRM client library/interface (libdrm.so) and kernel/hardware-specific device modules (such as i915.ko). Compiling --------- By default, libdrm and the DRM header files will install into /usr/local/. If you want to install this DRM to replace your system copy, say: ./configure --prefix=/usr --exec-prefix=/ Then, make install To build the device-specific kernel modules: cd linux-core/ make cp *.ko /lib/modules/VERSION/kernel/drivers/char/drm/ (where VERSION is your kernel version: uname -f) Or, cd bsd-core/ make copy the kernel modules to the appropriate place Tips & Trouble-shooting ----------------------- 1. You'll need kernel sources. If using Fedora Core 5, for example, you may need to install RPMs such as: kernel-smp-devel-2.6.15-1.2054_FC5.i686.rpm kernel-devel-2.6.15-1.2054_FC5.i686.rpm etc. 2. You may need to make a symlink from /lib/modules/VERSION/build to your kernel sources in /usr/src/kernels/VERSION (where version is `uname -r`): cd /lib/modules/VERSION ln -s /usr/src/kernels/VERSION build 3. If you've build the kernel modules but they won't load because of an error like this: $ /sbin/modprobe drm FATAL: Error inserting drm (/lib/modules/2.6.15-1.2054_FC5smp/kernel/drivers/char/drm/drm.ko): Invalid module format And 'dmesg|tail' says: drm: disagrees about version of symbol struct_module Try recompiling your drm modules without the Module.symvers file. That is rm the /usr/src/kernels/2.6.15-1.2054_FC5-smp-i686/Module.symvers file (or rename it). Then do a 'make clean' before rebuilding your drm modules.