Date: Thu, 14 Feb 2019 11:51:41 -0700 From: Warner Losh <imp@bsdimp.com> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: "DRM removal soon" is premature Message-ID: <CANCZdfrBTjV-rqU-VNRkFeQV2449ebgqi9qAAXYR6J_wygfxPg@mail.gmail.com> In-Reply-To: <20190214182419.GA67872@troutmask.apl.washington.edu> References: <20190214180101.GB67712@troutmask.apl.washington.edu> <CANCZdfqy%2Bs3QtEu%2BAhTm-HoJfByjeA9EeUGZ_3VrThvrcWvBow@mail.gmail.com> <20190214182419.GA67872@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl < sgk@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrBTjV-rqU-VNRkFeQV2449ebgqi9qAAXYR6J_wygfxPg>