[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