Bug 32190

Which mesa and drm?

Here are the info asked for:

Mesa is 7.9~git20100924-0ubuntu2
libdrm is 2.4.22+git20101204

both from the glasen PPA.

Ok, that libdrm is doing something the kernel doesn't expect. Naughty kernel for trusting userspace. Naughty userspace for confusing the kernel.

Have fixed the kernel already, but I shouldn't release a libdrm that won't function on an older kernel...

commit 537703fd4805e9cd352965fce642670986822d22
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Dec 7 20:34:22 2010 +0000

    intel: Reorder need_fence vs fenced_command to avoid fences on gen4
    
    gen4+ hardware doesn't use fences for GPU access and the older kernel
    doesn't expect userspace to make such a mistake. So don't.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32190
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Thank you for the amazingly quick action!

I see that the fix has already been commited by you on the master branch of the git repo, so the ubuntu PPA by Stefan Glasenhardt can pick it up soon making many users happy!

I guess that the PPA maintainer has been extra fast too, since I've just been delivered a new libdrm deb and after that no more "pinning" error appears in dmesg.

However, I have noticed the following

[drm:i915_gem_do_execbuffer] *ERROR* Object ffff8800b0b08c00 appears more than once in object list

(anyway happening much less frequently than the previous)

Should I open a new bug for it?

also, in now checking I have noticed a

[drm] MTRR allocation failed.  Graphics performance may suffer

for what I have found on the internet this should not be important, yet please let me know if I should send a notice for this too and whether the appropriate destination is userspace or kernel.

(In reply to comment #6)
> I guess that the PPA maintainer has been extra fast too, since I've just been
> delivered a new libdrm deb and after that no more "pinning" error appears in
> dmesg.
> 
> However, I have noticed the following
> 
> [drm:i915_gem_do_execbuffer] *ERROR* Object ffff8800b0b08c00 appears more than
> once in object list

I've an open bug that mentions that. Never seen it myself and it should be impossible...

> (anyway happening much less frequently than the previous)
> 
> Should I open a new bug for it?
> 
> also, in now checking I have noticed a
> 
> [drm] MTRR allocation failed.  Graphics performance may suffer
> 
> for what I have found on the internet this should not be important, yet please
> let me know if I should send a notice for this too and whether the appropriate
> destination is userspace or kernel.

On a gen4 you can reasonable expect to have PAT which supersedes MTRR, though the conflicting MTRR configuration is still worrying but irrelevant.

> [drm:i915_gem_do_execbuffer] *ERROR* Object ffff8800b0b08c00 appears more than
> once in object list

I've an open bug that mentions that. Never seen it myself and it should be
impossible...

I have confirmed it on bug 31584 (hope it is the right one), so in case you need further information you have reference about my case there too.

Some checks of the messages log makes me think that the "impossible" (namely the object appearing more than once) happens with good repeatability in suspend/restore cycles, right after the restore.