On Fri, Jul 18, 2025 at 11:31:05PM +0300, Vitaliy Makkoveev wrote:
> The resurrection my old diff. No reason for X to stuck in kernel lock
> while polling.
> 
> The `event_lock' mutex(9) is already protects `event_list' checked by
> filt_drmread(), so use it to protect the `drmread_filtops' too.
> 
> The filt_drmkms() doesn't touch any data and could be easily converted
> to always return 1, so the lock is only required for `drm_filtops'.
> Introduce the new `note_mtx' mutex(9) for that purpose.
> 
> I have no radeondrm(4), so tested with inteldrm(4) only. Previous time I
> had successful reports from people with radeondrm(4) too.

I'm not sure of the best way to test this or what any problems would
look like.

In general I'm concerned about unlocking drm due to rcu.

on t500 with rv635 radeondrm and this patch

7747 tests into 44335 on piglit

drm:pid11671:radeon_ring_test_lockup *ERROR* ring 0 stalled for more than 10170msec
drm:pid11671:radeon_fence_check_lockup *WARNING* GPU lockup (current fence id 0x0000000000088108 last fence id 0x0000000000088114 on ring 0)
..
[drm] *ERROR* radeon: fence wait failed (-11).
[drm] *ERROR* radeon: failed testing IB on GFX ring (-11).

and windows in X stop updating, cursor still moves, and can switch vt

on reboot
WARNING bo->pin_count failed at /usr/src/sys/dev/pci/drm/ttm/ttm_bo.c:252

Without the patch I also see the ring stalls around the same place.
But the entire screen is black, which doesn't change on switching vt.