[Nouveau] Trouble with TTM patches w/nouveau in linux-next

[Christian König]

Yeah, exactly that's the root cause of the problem.

GEM objects are the base class for TTM BOs for quite a while now.

So we at least need to initialize them or otherwise at least the size of 
the object is not available.

Going to send a fix in a few minutes.

Thanks,
Christian.

Am 09.06.21 um 17:13 schrieb Ilia Mirkin:
> GEM init happens here:
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm%2Ftree%2Fdrivers%2Fgpu%2Fdrm%2Fnouveau%2Fnouveau_gem.c%23n221&data=04%7C01%7Cchristian.koenig%40amd.com%7C228788b1c8524fa8128b08d92b591b81%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637588483983919147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=f%2BFFnPEAEoeuD8bKtnGtL5ZU0HBYpJAjqKqD29Xn9Kw%3D&reserved=0
>
> Note the bo alloc / gem init / bo init dance.
>
> I don't think there is a GEM object for internal allocations at all --
> we just allocate bo's directly and that's it. Perhaps you meant
> something else? I thought GEM was meant for externally-available
> objects.
>
> Cheers,
>
>    -ilia
>
> On Wed, Jun 9, 2021 at 10:58 AM Christian König
> <christian.koenig at amd.com> wrote:
>> Good point, but I think that is unrelated.
>>
>> My suspicion is rather that nouveau is not initializing the underlying
>> GEM object for internal allocations.
>>
>> So what happens is the same as on VMWGFX that TTM doesn't know anything
>> about the size to of the BO resulting in a kmalloc() with a random value
>> and eventually -ENOMEM.
>>
>> Good news is that I can reproduce it, so going to look into that later
>> today.
>>
>> Regards,
>> Christian.
>>
>> Am 09.06.21 um 16:52 schrieb Ilia Mirkin:
>>> Christian - potentially relevant is that Tegra doesn't have VRAM at
>>> all -- all GTT (or GART or whatever it's called nowadays). No
>>> fake/stolen VRAM.
>>>
>>> Cheers,
>>>
>>>     -ilia
>>>
>>> On Wed, Jun 9, 2021 at 10:18 AM Christian König
>>> <christian.koenig at amd.com> wrote:
>>>> Hi Mikko,
>>>>
>>>> strange sounds like Nouveau was somehow also using the GEM workaround
>>>> for VMWGFX as well.
>>>>
>>>> But -12 means -ENOMEM which doesn't fits into the picture.
>>>>
>>>> I will try with a G710, but if that doesn't yields anything I need some
>>>> more input from you.
>>>>
>>>> Thanks for the report,
>>>> Christian.
>>>>
>>>>
>>>> Am 09.06.21 um 15:47 schrieb Mikko Perttunen:
>>>>> Hi,
>>>>>
>>>>> I'm observing nouveau not initializing recently on linux-next on my
>>>>> Tegra186 Jetson TX2 board. Specifically it looks like BO allocation is
>>>>> failing when initializing the sync subsystem:
>>>>>
>>>>> [   21.858149] nouveau 17000000.gpu: DRM: failed to initialise sync
>>>>> subsystem, -28
>>>>>
>>>>> I have been bisecting and I have found two patches that affect this.
>>>>> Firstly, things first break on
>>>>>
>>>>> d02117f8efaa drm/ttm: remove special handling for non GEM drivers
>>>>>
>>>>> starting to return error code -12. Then, at
>>>>>
>>>>> d79025c7f5e3 drm/ttm: always initialize the full ttm_resource v2
>>>>>
>>>>> the error code changes to the above -28.
>>>>>
>>>>> If I checkout one commit prior to d79025c7f5e3 and revert
>>>>> d02117f8efaa, things work again. There are a bunch of other TTM
>>>>> commits between this and HEAD, so reverting these on top of HEAD
>>>>> doesn't work. However, I checked that both yesterday's and today's
>>>>> nexts are also broken.
>>>>>
>>>>> Thank you,
>>>>> Mikko
>>>>>
>>>> _______________________________________________
>>>> Nouveau mailing list
>>>> Nouveau at lists.freedesktop.org
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fnouveau&data=04%7C01%7Cchristian.koenig%40amd.com%7C228788b1c8524fa8128b08d92b591b81%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637588483983919147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dn0%2FRAOKKddFQbhJcjd3v1L%2BHc4hGlpWIURPTG33g50%3D&reserved=0