On Wed, Oct 02, 2024 at 06:25:43PM +0200, Sebastian Andrzej Siewior wrote: > On 2024-06-28 14:57:59 [+0200], To intel-gfx@xxxxxxxxxxxxxxxxxxxxx wrote: > Hi, > > > The following patches are from the PREEMPT_RT queue. It is mostly about > > disabling interrupts/preemption which leads to problems. Unfortunately > > DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because it acquires locks > > from within trace points. Making the lock a raw_spinlock_t led to higher > > latencies during video playback > > https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@xxxxxxxxxxxxx/ > > > > and I'm not sure if I hit the worse case here. > > I tested it on a SandyBridge with built-in i915 by using X, OpenGL and > > playing videos without noticing any warnings. However, some code paths > > were not entered. > > I carry them for some time now and most issues were reported by other > > people and they reported that things work for them since. > > These patches were not picked. Did I forget something or was this just > overseen? This looks quite poorly justified. Eg. you seem to be now leaving interrupts enabled (and even preemption enabled I guess) when we're racing against the raster beam. On first blush that seems like a recipe for failure. First step would be to set CONFIG_DRM_I915_DEBUG_VBLANK_EVADE=y, run a bunch of tests that stress the display stuff (eg. kms_atomic_transitions and other stuff from igt, and also some real workloads) and probably throw in a bunch of other load/perturbance at the system to make life hard. After the system has been sufficiently hammered one can compare sys/kernel/debug/dri/0/crtc-*/i915_update_info against a baseline. Bonus points for doing it on a potato. -- Ville Syrjälä Intel
