We've had problems with the X server deadlocking unpredictably on a VIA VT3122 when XVideo is in use, traced to a bug in via_dmablit.c (a patch will be attached shortly). The problem is that we can occasionally use all available blitq entries on the DMA engine in use for XVideo. If this happens, and there's enough other load on the system to let the hardware complete all 8 blits before via_dmablit_workqueue runs, we hit a situation where blitq->num_free is zero, but blitq->cur is equal to blitq->serviced. The result is that via_dmablit_workqueue does not free up any blitq entries, while the X driver busyloops trying to get a blitq entry.
Created attachment 10665 [details] [review] A patch to fix the deadlock By limiting the number of blitq entries that can be used to one fewer than the total in the list, we ensure that via_dmablit_workqueue can always free up blitq slots, as blitq->cur can never equal blitq->serviced.
Commited and pushed. Good catch. I know this one has caused you trouble for a while. The blit queue should really be a linked list, and will hopefully se a change some day. Perhaps based on the new memory manager. Out of interest... Do you manage to fill the blit queue with video blits only? /Thomas
In the trouble case, we've got one video and 7 pixmaps being sent to the driver. AFAICT, when we die, we've got several video frames sent to the driver in quick succession by Xine, plus the pixmaps. The result is pain without this patch, and a brief period of high CPU load with it (as the X driver spins waiting for the hardware to catch up).
As a side note, we're happy to test any reworking people do of the blit queue. I can set up my test case quite quickly, and leave it running until it breaks (or provides other useful debug information).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.