[Bug 109114] [CI][BAT] igt at debugfs_test@read_all_entries* - incomplete

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Dec 20 09:47:35 UTC 2018


https://bugs.freedesktop.org/show_bug.cgi?id=109114

--- Comment #4 from Stanislav Lisovskiy <stanislav.lisovskiy at intel.com> ---
(In reply to Chris Wilson from comment #3)
> Yet you have the similar assumption about the state of crc.entries and a
> corresponding lockup during crc collection. Circumstantial, maybe. More
> likely that the assumption on crc.entries is incorrect and you should try
> and capture your knowledge of crc.entries and how the driver may differ in
> an igt.

What do you mean by "similar lockup"? I guess previously you were talking about
while loop in Mika's patch, waiting on crc.entries, with probably infinite
loop, however I'm not doing that, there is only one check for crc.entries
state, ok this could be also wrong, however in other code parts this is done
exactly same way, that is what I used as example:

int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame,
   uint32_t frame, uint32_t *crcs)
{
      struct drm_crtc_crc *crc = &crtc->crc;
      struct drm_crtc_crc_entry *entry;

      int head, tail;

      spin_lock(&crc->lock);

      /* Caller may not have noticed yet that userspace has stopped reading */
      if (!crc->entries) {
            spin_unlock(&crc->lock);
            return -EINVAL;
      }

...

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20181220/2a5fdcef/attachment-0001.html>


More information about the intel-gfx-bugs mailing list