"DRM removal soon" is premature

[Warner Losh]

On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl <
sgk at troutmask.apl.washington.edu> wrote:

> On Thu, Feb 14, 2019 at 11:08:18AM -0700, Warner Losh wrote:
> > On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl <
> > sgk at troutmask.apl.washington.edu> wrote:
> >
> > > Warner,
> > >
> > > I'm not subscribed to freebsd-arch (well I am now!)
> > >
> > > drm-legacy-kmod is broken on i386-*-freebsd due
> > > to r343567.  I posted about this issue in
> > > freebsd-current, freebsd-x11 lists.  Find yourself
> > > a post r343567 system, build drm-legacy-kmod, and
> > > xorg and see what happens.
> > >
> > >
> > >
> https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072802.html
> > >
> https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022754.html
> >
> >
> > The in-tree versions don't even compile, how are they better than the
> > drm-legacy-kmod modules which do, but don't work for some people (and do
> > for others)?
> >
>
> 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.


> In your original post (which I cannot respond
> to as I came too late to freebsd-arch), you wrote
>
>    Since the drm-legacy-kmod or the drm-kmod packages seem to be
>    stable and working well for most people, the time has come to
>    finish the removal of most of the drm code in FreeBSD.
>
> I'm pointing out the fallacy of that statement for anyone
> running freebsd-current on i386 who uses drm-legacy-kmod.
>

Hence my qualification of "most people" :)


> Niclas proposed a fixed for drm-legacy-kmod here
>
> https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022759.html
>
> I reported on testing his proposed fix here
>
> https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022760.html
>
> and here
>
> https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022762.html


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.

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;
                }

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.

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.

Warner