Date: Thu, 14 Feb 2019 21:47:22 +0000 From: Johannes Lundberg <johalun0@gmail.com> To: freebsd-arch@freebsd.org Subject: Re: "DRM removal soon" is premature Message-ID: <62d87c2d-2535-9bdd-c4c8-6a74121518a9@gmail.com> In-Reply-To: <20190215065959.S4212@besplex.bde.org> References: <20190214180101.GB67712@troutmask.apl.washington.edu> <CANCZdfqy%2Bs3QtEu%2BAhTm-HoJfByjeA9EeUGZ_3VrThvrcWvBow@mail.gmail.com> <20190214182419.GA67872@troutmask.apl.washington.edu> <CANCZdfrBTjV-rqU-VNRkFeQV2449ebgqi9qAAXYR6J_wygfxPg@mail.gmail.com> <20190215065959.S4212@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@troutmask.apl.washington.edu> wrote:
>>> ...
>>> The in-tree version does not compile because someone disconnected
>>> drm2 from the build.=C2=A0 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 (wi=
th
> further convolutions for MACHINE_CPU_ARCH).=C2=A0 This is apparently no=
t
> set set
> by default or forced for universe, so drm2 doesn't get tested by univer=
se
> either, and even extensively tests for changes like r343567 don't notic=
e
> 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.=C2=A0 I used kld=
load
> to find its dependencies.=C2=A0 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)
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tries =3D 0;
>> retry:
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 glob->dummy_read_page =3D vm_page=
_alloc_contig(NULL, 0, req,
>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1, 0, VM=
_MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE);
>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1, 0, 0x=
fffffffful, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE);
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (unlikely(glob->dummy_read_pag=
e =3D=3D NULL)) {
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 if (tries < 1 && vm_page_reclaim_contig(req, 1,
>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0, VM_MAX_ADDRESS, PAGE_SIZE, 0))=
{
>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0, 0xfffffffful, PAGE_SIZE, 0)) {=
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tries++;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto retry;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 }
>
> I used VM_MAX_KERNEL_ADDRESS.=C2=A0 kib said that it should be more rel=
ated to
> bus spaces.=C2=A0 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 syn=
c.
>
> 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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62d87c2d-2535-9bdd-c4c8-6a74121518a9>