[Nouveau] [Bug 92504] [NVA5] Corruption in Plasma 5 on resume after changing screen configuration

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Oct 16 13:08:50 PDT 2015


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

--- Comment #7 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Actually the issue is most likely due to

[20351.450000] nouveau E[plasmashell[13570]] fail set_domain
[20351.450006] nouveau E[plasmashell[13570]] validating bo list
[20351.450015] nouveau E[plasmashell[13570]] validate: -22

Which is... odd. This happens when

        uint32_t domains = valid_domains & nvbo->valid_domains &
                (write_domains ? write_domains : read_domains);

        if (!domains)
                return -EINVAL;

Which means that unless nvbo->valid_domains had something funny in it, this is
all good. Hmmm....

        nvbo->valid_domains = NOUVEAU_GEM_DOMAIN_VRAM |
                              NOUVEAU_GEM_DOMAIN_GART;
        if (drm->device.info.family >= NV_DEVICE_INFO_V0_TESLA)
                nvbo->valid_domains &= domain;

So if we ever supply a valid/read/write domains that's not the same as the
domain we created the bo with, then this will fail. However after some scouring
of the code, I don't where we'd be messing this up. And unfortunately nothing
that libdrm prints will help this. I'm also unsure of 

If you can, could you patch 
drivers/gpu/drm/nouveau/nouveau_gem.c:nouveau_gem_set_domain to have a print of
all 4 inputs to domains to see why it's coming out as 0?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20151016/c0348a96/attachment.html>


More information about the Nouveau mailing list