"DRM removal soon" is premature

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

"DRM removal soon" is premature

Steve Kargl
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

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Warner Losh
On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl <
[hidden email]> 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)?

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Steve Kargl
On Thu, Feb 14, 2019 at 11:08:18AM -0700, Warner Losh wrote:

> On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl <
> [hidden email]> 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.  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.

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

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Niclas Zeising-6
In reply to this post by Warner Losh
On 2/14/19 7:08 PM, Warner Losh wrote:

> On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl <
> [hidden email]> 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 code in drm-legacy-kmod and in base is exactly the same, with two
exceptions.  The port uses gpu-firmware-kmod instead of the base
firmware, so paths has been adjsusted, and there is a fix in there to
make it compile on 13, something that's not even in the base code.

I can give you a patch to the base stuff to make it compile (based on
the one in drm-legacy-kmod) if you are interested in testing, but I'm
pretty sure the failure will be the same, in your set up.

Regards
--
Niclas Zeising
FreeBSD Graphics Team
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Warner Losh
In reply to this post by Steve Kargl
On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl <
[hidden email]> 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 <
> > [hidden email]> 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" :)



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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Steve Kargl
On Thu, Feb 14, 2019 at 11:51:41AM -0700, Warner Losh wrote:

> On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl <
> [hidden email]> 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 <
>
> > 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.
>

I can't test the patch for several hours, and it will take
6 to 7 hours to rebuild world/kernel.  So, I'll have to report
back tomorrow.

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Warner Losh
On Thu, Feb 14, 2019 at 12:02 PM Steve Kargl <
[hidden email]> wrote:

> On Thu, Feb 14, 2019 at 11:51:41AM -0700, Warner Losh wrote:
> > On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl <
> > [hidden email]> 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 <
> >
> > > 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.
> >
>
> I can't test the patch for several hours, and it will take
> 6 to 7 hours to rebuild world/kernel.  So, I'll have to report
> back tomorrow.
>

You'd only need to rebuild sys/modules/drm2, since that's the only thing
that will change with the patch.

But I can wait. I won't be removing things before tomorrow.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Steve Kargl
On Thu, Feb 14, 2019 at 12:04:46PM -0700, Warner Losh wrote:

> On Thu, Feb 14, 2019 at 12:02 PM Steve Kargl <
> >
> > I can't test the patch for several hours, and it will take
> > 6 to 7 hours to rebuild world/kernel.  So, I'll have to report
> > back tomorrow.
> >
>
> You'd only need to rebuild sys/modules/drm2, since that's the only thing
> that will change with the patch.
>
> But I can wait. I won't be removing things before tomorrow.
>

Well, to get the laptop functional again, so that I could
continue testing some libm changes, I reverted trunk back
to r343566.  I would need to pull in r343567 with the
pmap.h changes.  Apply your patch to drm2, and rebuild the
entire kernel (including WITH_MODULE_DRM2).  I don't know
if this new kernel would be incompatible with the old
world.

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Bruce Evans-4
In reply to this post by Steve Kargl
On Thu, 14 Feb 2019, Steve Kargl 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 <
>> [hidden email]> wrote:
>>> ...
>>> 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.

KBI changes like r343567 indeed give DLL hell.  I usually avoid this
by not using modules, but recently decided to test drm2, and now have
4 sets of modules for 4 types of kernels (i386-3+1, i386+4+4-post-r343567,
i386+4+4-post-r343567-less-1-KBI-change, and amd64).  I currently have 86
test kernels going back to FreeBSD-7 and reboot with about the last 10 of
them frequently.

>>> 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)?

They do compile, except for 1 macro in 1 radeon (ttm) file broken by
r343567.  I used a quick fix.  They probably still don't compile with
gcc, but I used clang.  I only needed drm2 for i915kms and don't miss
radeon.  I built them using a normal build (cd ~/bde/sysXXX/modules/XXX;
make, after fixing or working around bugs in .PATH statements).
drm2/i915kms almost works.  It actually works better after r343567.
Before then, it usually hands on unload and panics on reload.

> The in-tree version does not compile because someone disconnected
> drm2 from the build.  r342567 would not have happen if drm2 was
> not disconnected.  In your original post (which I cannot respond
> to as I came too late to freebsd-arch), you wrote

drm2 never compiled as a non-module since its files aren't in conf/files.
And it never was in LINT, so never was well tested since LINT doesn't
contain modules, except possibly under the kernel tree where the build
has other problems and never worked for me since it doesn't pass down
critical macros (like CC=cc -m32 and my more specialized ones).

Bruce
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Bruce Evans-4
In reply to this post by Warner Losh
On Thu, 14 Feb 2019, Warner Losh wrote:

> On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl <
> [hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "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 <
>> [hidden email]> 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
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Ben Widawsky-3
In reply to this post by Steve Kargl
On 19-02-14 11:17:39, Steve Kargl wrote:

> On Thu, Feb 14, 2019 at 12:04:46PM -0700, Warner Losh wrote:
> > On Thu, Feb 14, 2019 at 12:02 PM Steve Kargl <
> > >
> > > I can't test the patch for several hours, and it will take
> > > 6 to 7 hours to rebuild world/kernel.  So, I'll have to report
> > > back tomorrow.
> > >
> >
> > You'd only need to rebuild sys/modules/drm2, since that's the only thing
> > that will change with the patch.
> >
> > But I can wait. I won't be removing things before tomorrow.
> >
>
> Well, to get the laptop functional again, so that I could
> continue testing some libm changes, I reverted trunk back
> to r343566.  I would need to pull in r343567 with the
> pmap.h changes.  Apply your patch to drm2, and rebuild the
> entire kernel (including WITH_MODULE_DRM2).  I don't know
> if this new kernel would be incompatible with the old
> world.
>

Not to pile on unnecessarily here, but I think the fundamental issue is that
there is nobody who wants to maintain the in-tree DRM, and removal is likely a
better option to half-assed maintenance. I'd imagine there'd be a different
discussion if several developers were clamoring to keep this driver well
maintained in the tree.

--
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Steve Kargl
On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote:
>
> Not to pile on unnecessarily here, but I think the fundamental issue is that
> there is nobody who wants to maintain the in-tree DRM, and removal is likely a
> better option to half-assed maintenance. I'd imagine there'd be a different
> discussion if several developers were clamoring to keep this driver well
> maintained in the tree.
>

Unhooking a driver from the build, so that it cannot expose
a change that breaks said driver is certainly a way to
ensure the driver is not maintained.

Wasted a weekend trying to find and attempting to fix the
damage caused by a change in src/sys to the drm-legacy-kmod
port.  You know, the port that was promised as part of the
drm2 removal.  I would have spent this weekend testing
changes to cexp, cexpf, the soon-to-be-submitted cexpl,
ccosh, ccoshf, and the soon-to-be-submitted ccoshl.  That's
all on hold now as I'm not sure when I'll be able to carve
out time for testing.

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Warner Losh
On Thu, Feb 14, 2019, 4:30 PM Steve Kargl <[hidden email]
wrote:

> On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote:
> >
> > Not to pile on unnecessarily here, but I think the fundamental issue is
> that
> > there is nobody who wants to maintain the in-tree DRM, and removal is
> likely a
> > better option to half-assed maintenance. I'd imagine there'd be a
> different
> > discussion if several developers were clamoring to keep this driver well
> > maintained in the tree.
> >
>
> Unhooking a driver from the build, so that it cannot expose
> a change that breaks said driver is certainly a way to
> ensure the driver is not maintained.
>

It was already unmaintained.

Wasted a weekend trying to find and attempting to fix the
> damage caused by a change in src/sys to the drm-legacy-kmod
> port.  You know, the port that was promised as part of the
> drm2 removal.  I would have spent this weekend testing
> changes to cexp, cexpf, the soon-to-be-submitted cexpl,
> ccosh, ccoshf, and the soon-to-be-submitted ccoshl.  That's
> all on hold now as I'm not sure when I'll be able to carve
> out time for testing.
>

That is unfortunate. The root cause though is that the config you are using
is on the trailing edge. It would have been fixed, in that it would have
built, but I'm pretty sure it would have still broken because no one is
using this config. I'd argue that having it in the tree too long, including
in 12, lead to an expectation that would continue to work when we knew a
year ago there was a high risk of undetected breakage happening. And
wasting your time because of those unrealistic expectations we've fostered
is definitely not a good outcome.

So I too am frustrated. And I'm sorry that it is causing you pain.

Warner

>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Johannes Lundberg
In reply to this post by Steve Kargl

On 2/14/19 11:30 PM, Steve Kargl wrote:

> On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote:
>> Not to pile on unnecessarily here, but I think the fundamental issue is that
>> there is nobody who wants to maintain the in-tree DRM, and removal is likely a
>> better option to half-assed maintenance. I'd imagine there'd be a different
>> discussion if several developers were clamoring to keep this driver well
>> maintained in the tree.
>>
> Unhooking a driver from the build, so that it cannot expose
> a change that breaks said driver is certainly a way to
> ensure the driver is not maintained.
>
> Wasted a weekend trying to find and attempting to fix the
> damage caused by a change in src/sys to the drm-legacy-kmod
> port.  You know, the port that was promised as part of the
> drm2 removal.  I would have spent this weekend testing
> changes to cexp, cexpf, the soon-to-be-submitted cexpl,
> ccosh, ccoshf, and the soon-to-be-submitted ccoshl.  That's
> all on hold now as I'm not sure when I'll be able to carve
> out time for testing.

This happens all time for me with virtualbox-kmod as well in current.
Changes to src breaks certain (kmod) ports and there's always a delay
until they are fixed. This is life in -CURRENT. I accept this and don't
go bitching to virtualbox-kmod maintainers about it. Your usage is an
edge case so naturally there will be a longer delay before breakage is
noticed, until we can get automated CI up and running (even so, there
will be a delay).

With graphics, there's a software fallback (vesa/scfb), virtualbox has
no such option.

For stable usage, there are -RELEASE options.



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Oliver Pinter-4
On Friday, February 15, 2019, Johannes Lundberg <[hidden email]> wrote:

>
> On 2/14/19 11:30 PM, Steve Kargl wrote:
> > On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote:
> >> Not to pile on unnecessarily here, but I think the fundamental issue is
> that
> >> there is nobody who wants to maintain the in-tree DRM, and removal is
> likely a
> >> better option to half-assed maintenance. I'd imagine there'd be a
> different
> >> discussion if several developers were clamoring to keep this driver well
> >> maintained in the tree.
> >>
> > Unhooking a driver from the build, so that it cannot expose
> > a change that breaks said driver is certainly a way to
> > ensure the driver is not maintained.
> >
> > Wasted a weekend trying to find and attempting to fix the
> > damage caused by a change in src/sys to the drm-legacy-kmod
> > port.  You know, the port that was promised as part of the
> > drm2 removal.  I would have spent this weekend testing
> > changes to cexp, cexpf, the soon-to-be-submitted cexpl,
> > ccosh, ccoshf, and the soon-to-be-submitted ccoshl.  That's
> > all on hold now as I'm not sure when I'll be able to carve
> > out time for testing.
>
> This happens all time for me with virtualbox-kmod as well in current.
> Changes to src breaks certain (kmod) ports and there's always a delay
> until they are fixed. This is life in -CURRENT. I accept this and don't
> go bitching to virtualbox-kmod maintainers about it. Your usage is an
> edge case so naturally there will be a longer delay before breakage is
> noticed, until we can get automated CI up and running (even so, there
> will be a delay).
>
> With graphics, there's a software fallback (vesa/scfb), virtualbox has
> no such option.


bhyve, pure qumu?


>
> For stable usage, there are -RELEASE options.
>
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Johannes Lundberg
On Fri, Feb 15, 2019 at 09:44 Oliver Pinter <[hidden email]>
wrote:

>
>
> On Friday, February 15, 2019, Johannes Lundberg <[hidden email]>
> wrote:
>
>>
>> On 2/14/19 11:30 PM, Steve Kargl wrote:
>> > On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote:
>> >> Not to pile on unnecessarily here, but I think the fundamental issue
>> is that
>> >> there is nobody who wants to maintain the in-tree DRM, and removal is
>> likely a
>> >> better option to half-assed maintenance. I'd imagine there'd be a
>> different
>> >> discussion if several developers were clamoring to keep this driver
>> well
>> >> maintained in the tree.
>> >>
>> > Unhooking a driver from the build, so that it cannot expose
>> > a change that breaks said driver is certainly a way to
>> > ensure the driver is not maintained.
>> >
>> > Wasted a weekend trying to find and attempting to fix the
>> > damage caused by a change in src/sys to the drm-legacy-kmod
>> > port.  You know, the port that was promised as part of the
>> > drm2 removal.  I would have spent this weekend testing
>> > changes to cexp, cexpf, the soon-to-be-submitted cexpl,
>> > ccosh, ccoshf, and the soon-to-be-submitted ccoshl.  That's
>> > all on hold now as I'm not sure when I'll be able to carve
>> > out time for testing.
>>
>> This happens all time for me with virtualbox-kmod as well in current.
>> Changes to src breaks certain (kmod) ports and there's always a delay
>> until they are fixed. This is life in -CURRENT. I accept this and don't
>> go bitching to virtualbox-kmod maintainers about it. Your usage is an
>> edge case so naturally there will be a longer delay before breakage is
>> noticed, until we can get automated CI up and running (even so, there
>> will be a delay).
>>
>> With graphics, there's a software fallback (vesa/scfb), virtualbox has
>> no such option.
>
>
> bhyve, pure qumu?
>

Yes bhyve is awesome and I use it mostly. Don’t get me wrong, I’m not
complaining about breakage, mearly stating the fact that that’s life in
-current. VBox kmods are usually fixed quickly, I think the biggest delay
is the time it takes to build all the packages. Maybe a fast lane for
critical kmod ports that can be upgraded/rebuilt isolated from the rest
would be something?




>
>>
>> For stable usage, there are -RELEASE options.
>>
>>
>>
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "[hidden email]"
>>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Steve Kargl
In reply to this post by Johannes Lundberg
On Fri, Feb 15, 2019 at 09:07:08AM +0000, Johannes Lundberg wrote:
>
> This happens all time for me with virtualbox-kmod as well in current.
> Changes to src breaks certain (kmod) ports and there's always a delay
> until they are fixed. This is life in -CURRENT. I accept this and don't
> go bitching to virtualbox-kmod maintainers about it. Your usage is an
> edge case so naturally there will be a longer delay before breakage is
> noticed, until we can get automated CI up and running (even so, there
> will be a delay).
>

Was virtualbox-kmod every a part of the FreeBSD base sytem?

drm2 was a part of the base system and it was functional
until it was unhooked from the build.  The issue with the
merged PAE vs. non-PAE i386/pmap.h would have been identified
prior to it being committed if either drm2 had not been
unhooked or if an exp-run over ports was run.

I also don't see how this is an edge case.  A part of drm2
removal was the creation of a port, so those who don't have
the luxury of updating hardware every year can continue to
use drm2.  If this type of breakage of functionality formerly
in base, and the name calling of someone pointing out the
breakage, is the new norm, then it is a harbinger of doom for
pkg-base.

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "DRM removal soon" is premature

Cy Schubert-4
On February 15, 2019 7:50:26 AM PST, Steve Kargl <[hidden email]> wrote:

>On Fri, Feb 15, 2019 at 09:07:08AM +0000, Johannes Lundberg wrote:
>>
>> This happens all time for me with virtualbox-kmod as well in current.
>> Changes to src breaks certain (kmod) ports and there's always a delay
>> until they are fixed. This is life in -CURRENT. I accept this and
>don't
>> go bitching to virtualbox-kmod maintainers about it. Your usage is an
>> edge case so naturally there will be a longer delay before breakage
>is
>> noticed, until we can get automated CI up and running (even so, there
>> will be a delay).
>>
>
>Was virtualbox-kmod every a part of the FreeBSD base sytem?
>
>drm2 was a part of the base system and it was functional
>until it was unhooked from the build.  The issue with the
>merged PAE vs. non-PAE i386/pmap.h would have been identified
>prior to it being committed if either drm2 had not been
>unhooked or if an exp-run over ports was run.
>
>I also don't see how this is an edge case.  A part of drm2
>removal was the creation of a port, so those who don't have
>the luxury of updating hardware every year can continue to
>use drm2.  If this type of breakage of functionality formerly
>in base, and the name calling of someone pointing out the
>breakage, is the new norm, then it is a harbinger of doom for
>pkg-base.

Just to add a data point, I use drm-current on a 13 year old i386 laptop running -current, used as an i386 test platform. Keeping it in sync with my amd64 platforms.

--
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX: <[hidden email]> Web: http://www.FreeBSD.org

        The need of the many outweighs the greed of the few.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"