<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 2:05 PM, Frediano Ziglio <span dir="ltr"><<a href="mailto:fziglio@redhat.com" target="_blank">fziglio@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">><br>
> In release build this does not affect the code.<br>
> In debug build we will have a warning printout when waiting<br>
> on event is close to 2 seconds - this can be a cause of following<br>
> stop by OS. The printout contains name of related event variable.<br>
> There is one event (in offload thread) that long wait on it<br>
> does not affect any functionality, for it this warning is disabled.<br>
><br>
> Signed-off-by: Yuri Benditovich <<a href="mailto:yuri.benditovich@daynix.com">yuri.benditovich@daynix.com</a>><br>
> ---<br>
> qxldod/QxlDod.cpp | 3 ++-<br>
> qxldod/QxlDod.h | 15 +++++++++++++--<br>
> 2 files changed, 15 insertions(+), 3 deletions(-)<br>
><br>
> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp<br>
> index 01de9b3..7e3afb3 100755<br>
> --- a/qxldod/QxlDod.cpp<br>
> +++ b/qxldod/QxlDod.cpp<br>
> @@ -5095,7 +5095,8 @@ void QxlDevice::<wbr>PresentThreadRoutine()<br>
> // No need for a mutex, only one consumer thread<br>
> SPICE_RING_CONS_WAIT(m_<wbr>PresentRing, wait);<br>
> while (wait) {<br>
> - WaitForObject(&m_PresentEvent, NULL);<br>
> + // we do not want indication of long wait on this event<br>
> + DoWaitForObject(&m_<wbr>PresentEvent, NULL, NULL);<br>
> SPICE_RING_CONS_WAIT(m_<wbr>PresentRing, wait);<br>
> }<br>
> drawables = *SPICE_RING_CONS_ITEM(m_<wbr>PresentRing);<br>
> diff --git a/qxldod/QxlDod.h b/qxldod/QxlDod.h<br>
> index 324b940..7bb5de5 100755<br>
> --- a/qxldod/QxlDod.h<br>
> +++ b/qxldod/QxlDod.h<br>
> @@ -416,11 +416,13 @@ struct Resource {<br>
><br>
> BOOLEAN<br>
> FORCEINLINE<br>
> -WaitForObject(<br>
> +DoWaitForObject(<br>
> PVOID Object,<br>
> - PLARGE_INTEGER Timeout)<br>
> + PLARGE_INTEGER Timeout,<br>
> + LPCSTR name)<br>
> {<br>
> NTSTATUS status;<br>
> + TimeMeasurement tm;<br>
> status = KeWaitForSingleObject (<br>
> Object,<br>
> Executive,<br>
> @@ -428,9 +430,18 @@ WaitForObject(<br>
> FALSE,<br>
> Timeout);<br>
> ASSERT(NT_SUCCESS(status));<br>
> + tm.Stop();<br>
> + if (name && tm.Diff() > 1900)<br>
> + {<br>
> + // 2 seconds in PresentDisplayOnly triggers watchdog on Win10RS1<br>
> + // when VSync control enabled. Print the exact event name.<br>
> + DbgPrint(TRACE_LEVEL_ERROR, ("Waiting %d ms for %s\n", tm.Diff(),<br>
> name));<br>
> + }<br>
> return (status == STATUS_SUCCESS);<br>
> }<br>
><br>
> +#define WaitForObject(o, timeout) DoWaitForObject((o), (timeout), #o)<br>
> +<br>
> VOID<br>
> FORCEINLINE<br>
> ReleaseMutex(<br>
<br>
</div></div>This patch looks good.<br>
Which timers did you discovered having the wait issue?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Depends where the problematic flow is - first one is DisplayEvent, then - MemLock</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Frediano<br>
</font></span></blockquote></div><br></div></div>