"DRM removal soon" is premature

[Bruce Evans]

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.

> 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