Messages in this thread | | | Date | Wed, 11 Sep 2013 21:07:10 +0200 | From | Mario Kleiner <> | Subject | Re: BUG: sleeping function called from invalid context on 3.10.10-rt7 |
| |
On 11.09.13 20:35, Steven Rostedt wrote: > On Wed, 11 Sep 2013 20:29:07 +0200 > Mario Kleiner <mario.kleiner@tuebingen.mpg.de> wrote: > >> That said, maybe preempt_disable is no longer the optimal choice there >> and there's some better way to achieve good protection against >> interruptions of that bit of code? My knowledge here is a bit rusty, and >> the intel kms drivers and rt stuff has changed quite a bit. > > If you set your code to a higher priority than other tasks (and > interrupts) than it wont be preempted there. Unless of course it blocks > on a lock, but even then, priority inheritance will take place and it > still should be rather quick. (unless the holder of the lock is doing > that strange polling). > > -- Steve >
Right, on a rt kernel. But that creates the problem of not very computer savvy users (psychologists and biologists mostly) somehow having to choose proper priorities for gpu interrupt threads and for the x-server/wayland/..., and not much protection on a non-rt kernel?
preempt_disable() a few years ago looked like a good "plug and play" default solution, because the ->get_crtc_scanoutpos() function was supposed to have a very low and bounded execution time. At the time we wrote the patches for intel/radeon/nouveau, that was the case. Typical execution time (= preempt off time) was like 1-4 usecs, even on very low end hardware.
Seems that at least intel's kms driver does a lot of things now, which can sleep and spin inside that section? I tried to follow the posted stack trace, but got lost somewhere around the i915_read32 code and power management stuff...
-mario
| |