"DRM removal soon" is premature

[Johannes Lundberg]

On 2/14/19 8:20 PM, Bruce Evans wrote:
> On Thu, 14 Feb 2019, Warner Losh wrote:
>
>> On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl <
>> sgk at troutmask.apl.washington.edu> wrote:
>>> ...
>>> The in-tree version does not compile because someone disconnected
>>> drm2 from the build.  r342567 would not have happen if drm2 was
>>> not disconnected.
>>
>> Technically, it's just off by default. It's still connected to the
>> build.
>> We just don't have a good way to lint the code, as drm isn't in i386
>> NOTES.
>
> It is also only built in the modules tree if MK_MODULES_DRM2 is set (with
> further convolutions for MACHINE_CPU_ARCH).  This is apparently not
> set set
> by default or forced for universe, so drm2 doesn't get tested by universe
> either, and even extensively tests for changes like r343567 don't notice
> when they break it.

We are working on getting CI to build and test-load kmod ports on
changes in base that might cause breakage (mostly vm sub system) as soon
as they are committed.


>
>> You might try this fix instead, though I don't think it will matter. I
>> think the breakage you're seeing is a result of a subtle dependency
>> in the
>> drm2/ttm code with FreeBSD's vm system. Even had it been connected to
>> the
>> build and fixed at the time, I don't think it would have mattered.
>
> Another bug in the module is that it has no man pages.  I used kldload
> to find its dependencies.  i915kms didn't seem to depend on ttm.
>
>> diff --git a/sys/dev/drm2/ttm/ttm_bo.c b/sys/dev/drm2/ttm/ttm_bo.c
>> index 010afe6d8b3b..20083ff0fb53 100644
>> --- a/sys/dev/drm2/ttm/ttm_bo.c
>> +++ b/sys/dev/drm2/ttm/ttm_bo.c
>> @@ -1498,11 +1498,11 @@ int ttm_bo_global_init(struct
>> drm_global_reference
>> *ref)
>>        tries = 0;
>> retry:
>>        glob->dummy_read_page = vm_page_alloc_contig(NULL, 0, req,
>> -           1, 0, VM_MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE);
>> +           1, 0, 0xfffffffful, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE);
>>
>>        if (unlikely(glob->dummy_read_page == NULL)) {
>>                if (tries < 1 && vm_page_reclaim_contig(req, 1,
>> -                   0, VM_MAX_ADDRESS, PAGE_SIZE, 0)) {
>> +                   0, 0xfffffffful, PAGE_SIZE, 0)) {
>>                        tries++;
>>                        goto retry;
>>                }
>
> I used VM_MAX_KERNEL_ADDRESS.  kib said that it should be more related to
> bus spaces.  0xfffffffful seems just wrong on amd64.
>
>> Since that will eliminate the possibility that PAE is defined and
>> giving a
>> bigger max. Though it also likely won't matter if you have < 4GB of
>> RAM in
>> your machine. Obviously, this patch is not committable, but if it
>> works it
>> tells us something.
>
> r343567 gives most of PAE including its slowness, but doesn't give
> full PAE
> due to problems with device addresses.
>
>> But as I said, I doubt this will work as there's something subtle
>> (likely
>> the size of a variable or struct element) in ttm that's now out of sync.
>
> I see what look like subtle vm problems (a few frame buffer pages
> mismapped), but they are the same as a couple of years ago, and I don't
> have any devices mapped above 4G on i386.
>
> Bruce
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"