Created attachment 127520 [details] dmesg As the title says. Relevant dmesg output: [ 12.409144] ttm: no symbol version for memcpy [ 12.409146] ttm: Unknown symbol memcpy (err -22) [ 12.409167] ttm: no symbol version for clear_page [ 12.409167] ttm: Unknown symbol clear_page (err -22) [ 12.409178] ttm: no symbol version for copy_page [ 12.409179] ttm: Unknown symbol copy_page (err -22) [ 12.409204] ttm: no symbol version for phys_base [ 12.409205] ttm: Unknown symbol phys_base (err -22) [ 12.409216] ttm: no symbol version for memset [ 12.409216] ttm: Unknown symbol memset (err -22) [ 12.409219] ttm: no symbol version for ___preempt_schedule [ 12.409219] ttm: Unknown symbol ___preempt_schedule (err -22) Full dmesg output and kernel config are attached.
Created attachment 127521 [details] config
This looks like a build system / configuration / setup issue, not an amdgpu (or even ttm) bug.
Yeah, from the missing symbols I would guess that TTM was compiled with a different config than the rest of the kernel.
Well, the same config worked in pre 4.9-rc1 drm-next. The module and kernel were compiled together. However, this config is, and always has been, building amdgpu/ttm as a module, and the rest of the drivers (very minimal set, tied to this machine only) as built-in.
Can you bisect? I can't reproduce this and there haven't been any changes to ttm that would cause anything like this that I can see.
Might be changes to KConfig and deps handling.
Agreeing with the previous comments that this is probably not a TTM problem, I want to pass along that I have observed what is probably the same problem, but with many kernel modules unrelated to TTM and graphics. I think it might be possible to work around the problem by disabling CONFIG_MODVERSIONS, but just have not had the time to try that yet. I suspect that this has something to do with the changes in symbol exports that occurred in linux 4.9-rc1, which you can see if you do something like: diff -pruN linux-{4.8,4.9-rc1}/arch/x86/lib The symbols that I have had trouble with, such as memset, are ones that have had export declarations added to assembler sources (.S files). I see that the entry for memset in the generated file Module.symvers is different. In Linux 4.8, it looks like this: 0xfb578fc5 memset vmlinux EXPORT_SYMBOL In Linux 4.9-rc1, it looks like this: 0x00000000 memset vmlinux EXPORT_SYMBOL As you can see, the first field, which I believe is some sort of checksum of the C function declaration, is all zeroes for memset in Linux 4.9-rc1. I am still looking into this, but I am posting now because I may need to set this task aside for a day or two and didn't want to delay in passing along information that I think might be helpful in resolving your problem.
FYI, here is a very readable document that explains how kernel symbol versioning is implemented: http://tldp.org/HOWTO/Module-HOWTO/basekerncompat.html .
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/112.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.