[Bug 295788] graphics/drm-kmod: i915kms Hardware acceleration not working for Intel Braswell since >drm-510-kmod

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295788

--- Comment #13 from Roger Olofsson <[email protected]> ---
(In reply to Gleb Popov from comment #12)

Hi Gleb, I read your comment after doing this:

So something is happening in crocus_batch.c in the vicinity of line 210.

C:
    186 void
    187 crocus_init_batch(struct crocus_context *ice,
    188                   enum crocus_batch_name name,
    189                   int priority)
    190 {
    191    struct crocus_batch *batch = &ice->batches[name];
    192    struct crocus_screen *screen = (struct crocus_screen
*)ice->ctx.screen;
    193    struct intel_device_info *devinfo = &screen->devinfo;
    194
    195    batch->ice = ice;
    196    batch->screen = screen;
    197    batch->dbg = &ice->dbg;
    198    batch->reset = &ice->reset;
    199    batch->name = name;
    200    batch->contains_fence_signal = false;
    201
    202    if (devinfo->ver >= 7) {
    203       batch->fine_fences.uploader =
    204          u_upload_create(&ice->ctx, 4096, PIPE_BIND_CUSTOM,
    205                          PIPE_USAGE_STAGING, 0);
    206    }
    207    crocus_fine_fence_init(batch);
    208
    209    batch->hw_ctx_id = crocus_create_hw_context(screen->bufmgr);
    210    assert(batch->hw_ctx_id);
    211

Something must be wrong with batch->hw_ctx_id. Let's look at
crcocus_create_hw_context that's in crocus_bufmgr.c.

C:
   1521 uint32_t
   1522 crocus_create_hw_context(struct crocus_bufmgr *bufmgr)
   1523 {
   1524    uint32_t ctx_id;
   1525    if (!intel_gem_create_context(bufmgr->fd, &ctx_id)) {
   1526       DBG("intel_gem_create_context failed: %s\n", strerror(errno));
   1527       return 0;
   1528    }

This takes us to intel_gem_create_hw_context which is in intel_gem.c.

C:
     64 bool
     65 intel_gem_create_context(int fd, uint32_t *context_id)
     66 {
     67    return i915_gem_create_context(fd, context_id);
     68 }

And that goes to i915/intel_gem.c

C:
     31 bool
     32 i915_gem_create_context(int fd, uint32_t *context_id)
     33 {
     34    struct drm_i915_gem_context_create create = {};
     35    if (intel_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &create))
     36       return false;
     37    *context_id = create.ctx_id;
     38    return true;
     39 }

This goes on to intel_gem.h even though there is another intel_gem.h in the
i915 subdirectory.

C:
     77 static inline int
     78 intel_ioctl(int fd, unsigned long request, void *arg)
     79 {
     80     int ret;
     81 
     82     do {
     83         ret = ioctl(fd, request, arg);
     84     } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
     85     return ret;
     86 }

And there it goes to libc.so.7 on line 83 and if cont it breaks.


Process 2307 stopped
* thread #1, name = 'Xorg', stop reason = instruction step into
frame #0: 0x0000000840bb7a80 crocus_dri.so`intel_ioctl(fd=17,
request=3221775469, arg=0x0000000820a03f40) at intel_gem.h:83:15
80 int ret;
81
82 do {
-> 83 ret = ioctl(fd, request, arg);
84 } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
85 return ret;
86 }
(lldb) si
Process 2307 stopped
* thread #1, name = 'Xorg', stop reason = instruction step into
frame #0: 0x0000000841352cd0 crocus_dri.so`ioctl
crocus_dri.so`ioctl:
-> 0x841352cd0 <+0>: jmpq *0x6d352(%rip)
0x841352cd6 <+6>: pushq $0x14
0x841352cdb <+11>: jmp 0x841352b80

crocus_dri.so`dup:
0x841352ce0 <+0>: jmpq *0x6d34a(%rip)
(lldb) si
Process 2307 stopped
* thread #1, name = 'Xorg', stop reason = instruction step into
frame #0: 0x0000000828363a60 libc.so.7`__sys_ioctl at ioctl.S:4
(lldb)



Could the i915/intel_gem.h vs intel_gem.h be the issue?

Roger

-- 
You are receiving this mail because:
You are the assignee for the bug.