Hi!
I was recently playing with a bug in radeon drm code (it looks much as
a deadlock to me). As a side effect I reread most of docs at the dri
site. There is an interesting note in DRM design guide:
"If the direct-rendering client holds the hardware lock and receives a
SIGKILL signal, deadlock may result. If the SIGKILL is detected and the
hardware lock is immediately taken from the client, the typical PC-class
graphics hardware may be left in an unknown state and may lock up (this
kind of hardware usually does not deal well with intermingling of
command streams).
Similarly, if the direct-rendering client holds the hardware lock and
receives a SIGSTOP, the X server and all other direct-rendering clients
will block until the process releases the lock.
Ideally, the client should be permitted to complete the rendering
operation that is currently in progress and have the SIGKILL or SIGSTOP
signals delivered as soon as the hardware lock is released (or, after
some reasonable timeout, so that buggy clients can be halted). This
delay of signal delivery appears to require kernel-level changes that
cannot be performed by a loadable module using the standard module
interface."
Anyone knows if there is something planned to avoid this situation in
Linux 2.5/6? I'm just curious...
[ Please cc: me, I'm not no the list ]
Have a nice day!
-- Kamil Toman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:11 EST