Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 23:50 Steve Kargl
wrote:
> On Mon, May 21, 2018 at 03:20:49PM -0700, K. Macy wrote:
> > >
> > > I just ask.
> > > Or why not include drm-next to base svn repo and add some
> > > option to make.conf to swith drm2/dem-next ?
> >
> > Even if it's not being built on amd64 we're still responsible for
> > keeping it building on !amd64 so long as it's in base. This makes
> > changing APIs and universe runs more burdensome. The graphics
> > developers have given you notice that it will now be your collective
> > responsibility to keep it up to date.
> >
>
> Not quite. One graphics developer has indicated a desire
> to remove working code, because it interferes with the
> graphics developers' port on a single architecture. There
> is no indication by that graphics developer that drm2 will
> be available in ports. You can go read the original post
> here:
>
> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
>
> The last paragraph is
>
>What does the community think? Is there anyone still using
>the drm2 driver on 12-CURRENT? If so, what is preventing
>you from switching to the port?
>
> The answer to the last two questions are "yes" and "the port
> does not work on i386".
>
> Yes, I recognize that you're clever enough to purposefully
> break the API so that you can thumb your nose at those of
> us who have older hardware.
>
> What is wrong with using
>
> .if ${MACHINE_ARCH} != amd64
> ...
> .endif
>
> to enable/disable drm2?
The answer to the first question is that the consensus seem to be that
moving to a port is best for the _majority_.
Let me ask you, what’s wrong with this one-liner after base install
pkg install drm2
?
>
> --
> Steve
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Another recent WITH_META_MODE= gotcha ": handling svn commit: r334008 - head/bin/sh
Attempting to build head -r334014 from -r333947 includes the code from -r334008,
and for which I get:
--- parser.o ---
/usr/src/bin/sh/parser.c:1440:9: error: use of undeclared identifier 'CQNL'
case CQNL:
^
1 error generated.
for what was added in -r334008.
# grep -r CQNL /usr/src/* | more
/usr/src/bin/sh/mksyntax.c: { "CQNL", "newline character in quotes" },
/usr/src/bin/sh/mksyntax.c: add("\n", "CQNL");
/usr/src/bin/sh/mksyntax.c: add("\n", "CQNL");
/usr/src/bin/sh/mksyntax.c: add("\n", "CQNL");
/usr/src/bin/sh/parser.c: case CQNL:
/usr/src/contrib/libarchive/libarchive/test/test_read_format_rar_binary_data.rar.uu:M+M7)?9;.A%CQNL-+4::&_UJQ*P"PPW:>)I5*8)7^>6(\]!Q"^9YCE>>`9OG8
Apparently this is something WITH_META_MODE= does not deal with.
Rebuilding after:
rm -fr /usr/obj/amd64_clang/*
(here I normally have the build materials) built fine.
(The "Making top.local.h from /usr/src/contrib/top/top.local.hs"
change to no longer have top.local.h or top.local.hs was another
example: for a while top.local.h was still referenced and old ones
would still be used if present.)
===
Mark Millard
marklmi26-fbsd at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r333974 fix-to-the-build exposes another breaks-the-build problem in top (at least for gcc based builds)
On 2018-May-21, at 5:46 PM, Mark Millard wrote: > FreeBSD-head-amd64-gcc (based on a more modern gcc) reports a > more explicit error for -r333974 and later: > > --- all_subdir_usr.bin --- > /workspace/src/usr.bin/top/commands.c:132:1: error: function declaration > isn't a prototype [-Werror=strict-prototypes] > scanint(str, intp) > ^~~ > > The older gcc 4.2.1 builds report: > > --- all_subdir_usr.bin/top --- > cc1: warnings being treated as errors > /usr/src/usr.bin/top/commands.c:134: warning: function declaration isn't a > prototype > *** [commands.o] Error code 1 > > make[4]: stopped in /usr/src/usr.bin/top > 1 error I should have been explicit that the material is from ci.freebsd.org . For reference, the gcc based builds seem to be: (all but the last being gcc 4.2.1 based if I undertand right) FreeBSD-head-mips-build FreeBSD-head-mips64-build FreeBSD-head-powerpc-build FreeBSD-head-powerpc64-build FreeBSD-head-powerpcspe-build FreeBSD-head-sparc64-build FreeBSD-head-amd64-gcc So those are what I'm reporting as having broken builds for the specific issue. === Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
head -r333974 fix-to-the-build exposes another breaks-the-build problem in top (at least for gcc based builds)
FreeBSD-head-amd64-gcc (based on a more modern gcc) reports a more explicit error for -r333974 and later: --- all_subdir_usr.bin --- /workspace/src/usr.bin/top/commands.c:132:1: error: function declaration isn't a prototype [-Werror=strict-prototypes] scanint(str, intp) ^~~ The older gcc 4.2.1 builds report: --- all_subdir_usr.bin/top --- cc1: warnings being treated as errors /usr/src/usr.bin/top/commands.c:134: warning: function declaration isn't a prototype *** [commands.o] Error code 1 make[4]: stopped in /usr/src/usr.bin/top 1 error === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 03:20:49PM -0700, K. Macy wrote:
> >
> > I just ask.
> > Or why not include drm-next to base svn repo and add some
> > option to make.conf to swith drm2/dem-next ?
>
> Even if it's not being built on amd64 we're still responsible for
> keeping it building on !amd64 so long as it's in base. This makes
> changing APIs and universe runs more burdensome. The graphics
> developers have given you notice that it will now be your collective
> responsibility to keep it up to date.
>
Not quite. One graphics developer has indicated a desire
to remove working code, because it interferes with the
graphics developers' port on a single architecture. There
is no indication by that graphics developer that drm2 will
be available in ports. You can go read the original post
here:
https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
The last paragraph is
What does the community think? Is there anyone still using
the drm2 driver on 12-CURRENT? If so, what is preventing
you from switching to the port?
The answer to the last two questions are "yes" and "the port
does not work on i386".
Yes, I recognize that you're clever enough to purposefully
break the API so that you can thumb your nose at those of
us who have older hardware.
What is wrong with using
.if ${MACHINE_ARCH} != amd64
...
.endif
to enable/disable drm2?
--
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
> > I just ask. > Or why not include drm-next to base svn repo and add some > option to make.conf to swith drm2/dem-next ? Even if it's not being built on amd64 we're still responsible for keeping it building on !amd64 so long as it's in base. This makes changing APIs and universe runs more burdensome. The graphics developers have given you notice that it will now be your collective responsibility to keep it up to date. Cheers. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, 21 May 2018 10:07:28 -0700 Steve Kargl wrote: > Why? "If it isn't broken, why fix it?" > > The conflict affects x86_64-*-freebsd aka amd64. The > conflict does not affect any other architecture. The > Makefile infrastructure can use MACHINE_ARCH to exclude > drm2 from build of amd64. > > I don't use netgraph or any of the if_*.ko modules. > Can we put all of that into ports? I don't use any > scsi controllers, so those can go too. Why make it > insanely fun for users to configure a FreeBSD system. > I just ask. Or why not include drm-next to base svn repo and add some option to make.conf to swith drm2/dem-next ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 01:16:12PM -0700, K. Macy wrote: > On Mon, May 21, 2018 at 10:07 AM, Steve Kargl > wrote: > > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote: > >> On Sun, 20 May 2018 21:10:28 +0200 > >> Oliver Pinter wrote: >>> > One of the reasons for the deprecation and removal of the drm2 bits > is that they prevent us from automatically loading the > drm-next/stable-kmod kernel modules, since the two collide. > Regards Then it wold be better to resolve this problem, rather then removing a working solution. What's about module versioning what in other cases works? >>> >>> May be just move old drm2 to ports? >> >> Why? "If it isn't broken, why fix it?" >> >> The conflict affects x86_64-*-freebsd aka amd64. The >> conflict does not affect any other architecture. The >> Makefile infrastructure can use MACHINE_ARCH to exclude >> drm2 from build of amd64. >> > Wasn't a strawman. Is it that difficult to use the Makefile infrastructure to exclude old drm2 on amd64? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 10:07 AM, Steve Kargl wrote: > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote: >> On Sun, 20 May 2018 21:10:28 +0200 >> Oliver Pinter wrote: >> >> > > One of the reasons for the deprecation and removal of the drm2 bits >> > > is that they prevent us from automatically loading the >> > > drm-next/stable-kmod kernel modules, since the two collide. >> > > Regards >> > >> > >> > Then it wold be better to resolve this problem, rather then removing a >> > working solution. What's about module versioning what in other cases >> > works? >> > >> >> May be just move old drm2 to ports? > > Why? "If it isn't broken, why fix it?" > > The conflict affects x86_64-*-freebsd aka amd64. The > conflict does not affect any other architecture. The > Makefile infrastructure can use MACHINE_ARCH to exclude > drm2 from build of amd64. > Having it as a port puts the burden squarely on those using it and not on the majority who are running hardware from this decade. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On 5/21/18, Oliver Pinter wrote:
> On 5/21/18, Steve Kargl wrote:
>> On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote:
>>>
>>> On 05/21/2018 10:07, Steve Kargl wrote:
>>> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
>>> >> On Sun, 20 May 2018 21:10:28 +0200
>>> >> Oliver Pinter wrote:
>>> >>
>>> One of the reasons for the deprecation and removal of the drm2 bits
>>> is that they prevent us from automatically loading the
>>> drm-next/stable-kmod kernel modules, since the two collide.
>>> Regards
>>> >>>
>>> >>> Then it wold be better to resolve this problem, rather then removing
>>> >>> a
>>> >>> working solution. What's about module versioning what in other cases
>>> >>> works?
>>> >>>
>>> >> May be just move old drm2 to ports?
>>> > Why? "If it isn't broken, why fix it?"
>>> >
>>> > The conflict affects x86_64-*-freebsd aka amd64. The
>>> > conflict does not affect any other architecture. The
>>> > Makefile infrastructure can use MACHINE_ARCH to exclude
>>> > drm2 from build of amd64.
>>> >
>>> > I don't use netgraph or any of the if_*.ko modules.
>>> > Can we put all of that into ports? I don't use any
>>> > scsi controllers, so those can go too. Why make it
>>> > insanely fun for users to configure a FreeBSD system.
>>> to play devils advocate - why include a kernel module that causes
>>> conflicts for a vast majority of the laptop devices that you can
>>> purchase today (as well as for the foreseeable future), while forcing
>>> the up to date and actively developed driver to not work out of the box?
>>
>> Poor advocacy. I stated old drm2 can be excluded by the
>> Makefile infrastructure and I've already provided a barebones
>> patch.
>>
>> Index: sys/modules/Makefile
>> ===
>> --- sys/modules/Makefile(revision 333609)
>> +++ sys/modules/Makefile(working copy)
>> @@ -112,7 +112,9 @@
>> ${_dpms} \
>> ${_dpt} \
>> ${_drm} \
>> +.if ${MACHINE_ARCH} != amd64
>> ${_drm2} \
>> +.endif
>> dummynet \
>> ${_ed} \
>> ${_efirt} \
>
> I prefer something like this:
>
> op@opn src# git diff
> diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC
> index 195b66daab51..034e2f8126fd 100644
> --- a/sys/amd64/conf/GENERIC
> +++ b/sys/amd64/conf/GENERIC
> @@ -23,6 +23,7 @@ ident GENERIC
>
> makeoptionsDEBUG=-g# Build kernel with gdb(1) debug
> symbols
> makeoptionsWITH_CTF=1 # Run ctfconvert(1) for DTrace
> support
> +makeoptionsWITHOUT_MODULES="drm drm2" # by default disable the
> building of DRM* for GENERIC
>
> optionsSCHED_ULE # ULE scheduler
> optionsPREEMPTION # Enable kernel thread preemption
>
Or make the function in this file smarter:
"./hw/xfree86/os-support/bsd/bsd_kmod.c"
#ifdef HAVE_XORG_CONFIG_H
#include
#endif
#include
#include
#include
#include
#include
#include "xf86_OSproc.h"
/*
* Load a FreeBSD kernel module.
* This is used by the DRI/DRM to load a DRM kernel module when
* the X server starts. It could be used for other purposes in the future.
* Input:
*modName - name of the kernel module (Ex: "tdfx")
* Return:
*0 for failure, 1 for success
*/
int
xf86LoadKernelModule(const char *modName)
{
if (kldload(modName) != -1)
return 1;
else
return 0;
}
>
>>
>> Those interested in killing old drm2 on amd64 can add the
>> requisite .if ... .endif to remove obsolscent *.ko.
>>
>>> IMHO it is issues like this (having out of date code that supports some
>>> edge cases) which makes it harder for developers to dog-food the actual
>>> OS they are developing on.
>>
>> You're talking to 1 of the 3 contributors that has tried over
>> the last 2 decades to improve libm (both its quality and
>> conformance to standards). The development and testing is
>> done on my old i386 laptop (which happily uses drm2), my
>> amd64 systems, and at one time sparc64 (flame.freebsd.org).
>> So, yeah, i386 and sparc64 allowed me to dog-food my code.
>>
>> BTW, there are uncountable many integers. How about avoiding
>> the conflict by using, say, '3' as in drm3.
>>
>> --
>> Steve
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On 5/21/18, Steve Kargl wrote:
> On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote:
>>
>> On 05/21/2018 10:07, Steve Kargl wrote:
>> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
>> >> On Sun, 20 May 2018 21:10:28 +0200
>> >> Oliver Pinter wrote:
>> >>
>> One of the reasons for the deprecation and removal of the drm2 bits
>> is that they prevent us from automatically loading the
>> drm-next/stable-kmod kernel modules, since the two collide.
>> Regards
>> >>>
>> >>> Then it wold be better to resolve this problem, rather then removing
>> >>> a
>> >>> working solution. What's about module versioning what in other cases
>> >>> works?
>> >>>
>> >> May be just move old drm2 to ports?
>> > Why? "If it isn't broken, why fix it?"
>> >
>> > The conflict affects x86_64-*-freebsd aka amd64. The
>> > conflict does not affect any other architecture. The
>> > Makefile infrastructure can use MACHINE_ARCH to exclude
>> > drm2 from build of amd64.
>> >
>> > I don't use netgraph or any of the if_*.ko modules.
>> > Can we put all of that into ports? I don't use any
>> > scsi controllers, so those can go too. Why make it
>> > insanely fun for users to configure a FreeBSD system.
>> to play devils advocate - why include a kernel module that causes
>> conflicts for a vast majority of the laptop devices that you can
>> purchase today (as well as for the foreseeable future), while forcing
>> the up to date and actively developed driver to not work out of the box?
>
> Poor advocacy. I stated old drm2 can be excluded by the
> Makefile infrastructure and I've already provided a barebones
> patch.
>
> Index: sys/modules/Makefile
> ===
> --- sys/modules/Makefile(revision 333609)
> +++ sys/modules/Makefile(working copy)
> @@ -112,7 +112,9 @@
> ${_dpms} \
> ${_dpt} \
> ${_drm} \
> +.if ${MACHINE_ARCH} != amd64
> ${_drm2} \
> +.endif
> dummynet \
> ${_ed} \
> ${_efirt} \
I prefer something like this:
op@opn src# git diff
diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC
index 195b66daab51..034e2f8126fd 100644
--- a/sys/amd64/conf/GENERIC
+++ b/sys/amd64/conf/GENERIC
@@ -23,6 +23,7 @@ ident GENERIC
makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols
makeoptionsWITH_CTF=1 # Run ctfconvert(1) for DTrace support
+makeoptionsWITHOUT_MODULES="drm drm2" # by default disable the
building of DRM* for GENERIC
optionsSCHED_ULE # ULE scheduler
optionsPREEMPTION # Enable kernel thread preemption
>
> Those interested in killing old drm2 on amd64 can add the
> requisite .if ... .endif to remove obsolscent *.ko.
>
>> IMHO it is issues like this (having out of date code that supports some
>> edge cases) which makes it harder for developers to dog-food the actual
>> OS they are developing on.
>
> You're talking to 1 of the 3 contributors that has tried over
> the last 2 decades to improve libm (both its quality and
> conformance to standards). The development and testing is
> done on my old i386 laptop (which happily uses drm2), my
> amd64 systems, and at one time sparc64 (flame.freebsd.org).
> So, yeah, i386 and sparc64 allowed me to dog-food my code.
>
> BTW, there are uncountable many integers. How about avoiding
> the conflict by using, say, '3' as in drm3.
>
> --
> Steve
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote:
>
> On 05/21/2018 10:07, Steve Kargl wrote:
> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
> >> On Sun, 20 May 2018 21:10:28 +0200
> >> Oliver Pinter wrote:
> >>
> One of the reasons for the deprecation and removal of the drm2 bits
> is that they prevent us from automatically loading the
> drm-next/stable-kmod kernel modules, since the two collide.
> Regards
> >>>
> >>> Then it wold be better to resolve this problem, rather then removing a
> >>> working solution. What's about module versioning what in other cases
> >>> works?
> >>>
> >> May be just move old drm2 to ports?
> > Why? "If it isn't broken, why fix it?"
> >
> > The conflict affects x86_64-*-freebsd aka amd64. The
> > conflict does not affect any other architecture. The
> > Makefile infrastructure can use MACHINE_ARCH to exclude
> > drm2 from build of amd64.
> >
> > I don't use netgraph or any of the if_*.ko modules.
> > Can we put all of that into ports? I don't use any
> > scsi controllers, so those can go too. Why make it
> > insanely fun for users to configure a FreeBSD system.
> to play devils advocate - why include a kernel module that causes
> conflicts for a vast majority of the laptop devices that you can
> purchase today (as well as for the foreseeable future), while forcing
> the up to date and actively developed driver to not work out of the box?
Poor advocacy. I stated old drm2 can be excluded by the
Makefile infrastructure and I've already provided a barebones
patch.
Index: sys/modules/Makefile
===
--- sys/modules/Makefile(revision 333609)
+++ sys/modules/Makefile(working copy)
@@ -112,7 +112,9 @@
${_dpms} \
${_dpt} \
${_drm} \
+.if ${MACHINE_ARCH} != amd64
${_drm2} \
+.endif
dummynet \
${_ed} \
${_efirt} \
Those interested in killing old drm2 on amd64 can add the
requisite .if ... .endif to remove obsolscent *.ko.
> IMHO it is issues like this (having out of date code that supports some
> edge cases) which makes it harder for developers to dog-food the actual
> OS they are developing on.
You're talking to 1 of the 3 contributors that has tried over
the last 2 decades to improve libm (both its quality and
conformance to standards). The development and testing is
done on my old i386 laptop (which happily uses drm2), my
amd64 systems, and at one time sparc64 (flame.freebsd.org).
So, yeah, i386 and sparc64 allowed me to dog-food my code.
BTW, there are uncountable many integers. How about avoiding
the conflict by using, say, '3' as in drm3.
--
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, 21 May 2018 10:29:54 -0700 "Pete Wright" said On 05/21/2018 10:07, Steve Kargl wrote: > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote: >> On Sun, 20 May 2018 21:10:28 +0200 >> Oliver Pinter wrote: >> One of the reasons for the deprecation and removal of the drm2 bits is that they prevent us from automatically loading the drm-next/stable-kmod kernel modules, since the two collide. Regards >>> >>> Then it wold be better to resolve this problem, rather then removing a >>> working solution. What's about module versioning what in other cases >>> works? >>> >> May be just move old drm2 to ports? > Why? "If it isn't broken, why fix it?" > > The conflict affects x86_64-*-freebsd aka amd64. The > conflict does not affect any other architecture. The > Makefile infrastructure can use MACHINE_ARCH to exclude > drm2 from build of amd64. > > I don't use netgraph or any of the if_*.ko modules. > Can we put all of that into ports? I don't use any > scsi controllers, so those can go too. Why make it > insanely fun for users to configure a FreeBSD system. to play devils advocate - why include a kernel module that causes conflicts for a vast majority of the laptop devices that you can purchase today (as well as for the foreseeable future), while forcing the up to date and actively developed driver to not work out of the box? IMHO it is issues like this (having out of date code that supports some edge cases) which makes it harder for developers to dog-food the actual OS they are developing on. Having things work on modern hardware by default seems like a great way to get more people on the platform testing and bugfixing things. The suggestion seems like a pretty good middle ground, people with older devices will still have workable code while also making it easier to continue to follow the state of the art in terms of hardware support. -pete Along the lines of Devils advocate; Why do *any* get "special" attention? Why does Intel get all the love? None of my nVidia cards get this; granted they're blobs. But I've been waiting ~1yr. for support for my AMD GPU to be supported. IOW why not make all of them a port? IMHO vt(4) , while a nice *initial* effort. Still falls *far* short of sc(ons). It's no big deal to whip up a custom kernel with support for your chosen video card/APU/GPU. Then there can be less complaints about "favoritism" -- everyone is treated equally. Why must the stock (GENERIC) kernel support "graphics mode" out-of-the-box? It appears to me; at this stage; or the *proposed* stage; that Intel will be the only _well supported_ hardware out-of-the-box. tl;dr; Make all video cards/APU/GPU support come from ports/kernel OPTIONS_KNOBS Thanks for your indulgence. --Chris -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/21/2018 10:07, Steve Kargl wrote: On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote: On Sun, 20 May 2018 21:10:28 +0200 Oliver Pinter wrote: One of the reasons for the deprecation and removal of the drm2 bits is that they prevent us from automatically loading the drm-next/stable-kmod kernel modules, since the two collide. Regards Then it wold be better to resolve this problem, rather then removing a working solution. What's about module versioning what in other cases works? May be just move old drm2 to ports? Why? "If it isn't broken, why fix it?" The conflict affects x86_64-*-freebsd aka amd64. The conflict does not affect any other architecture. The Makefile infrastructure can use MACHINE_ARCH to exclude drm2 from build of amd64. I don't use netgraph or any of the if_*.ko modules. Can we put all of that into ports? I don't use any scsi controllers, so those can go too. Why make it insanely fun for users to configure a FreeBSD system. to play devils advocate - why include a kernel module that causes conflicts for a vast majority of the laptop devices that you can purchase today (as well as for the foreseeable future), while forcing the up to date and actively developed driver to not work out of the box? IMHO it is issues like this (having out of date code that supports some edge cases) which makes it harder for developers to dog-food the actual OS they are developing on. Having things work on modern hardware by default seems like a great way to get more people on the platform testing and bugfixing things. The suggestion seems like a pretty good middle ground, people with older devices will still have workable code while also making it easier to continue to follow the state of the art in terms of hardware support. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote: > On Sun, 20 May 2018 21:10:28 +0200 > Oliver Pinter wrote: > > > > One of the reasons for the deprecation and removal of the drm2 bits > > > is that they prevent us from automatically loading the > > > drm-next/stable-kmod kernel modules, since the two collide. > > > Regards > > > > > > Then it wold be better to resolve this problem, rather then removing a > > working solution. What's about module versioning what in other cases > > works? > > > > May be just move old drm2 to ports? Why? "If it isn't broken, why fix it?" The conflict affects x86_64-*-freebsd aka amd64. The conflict does not affect any other architecture. The Makefile infrastructure can use MACHINE_ARCH to exclude drm2 from build of amd64. I don't use netgraph or any of the if_*.ko modules. Can we put all of that into ports? I don't use any scsi controllers, so those can go too. Why make it insanely fun for users to configure a FreeBSD system. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: vm_phys_free_pages: page 0x... has unexpected order 0
FreeBSD 12.0-CURRENT amd64 r332472 Does this panic ring a bell to anyone? Has it already been fixed? Thank you! panic: vm_phys_free_pages: page 0xf80cbfb71958 has unexpected order 0 cpuid = 3 time = 1526822662 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe017547c340 vpanic() at vpanic+0x18d/frame 0xfe017547c3a0 doadump() at doadump/frame 0xfe017547c420 vm_phys_free_pages() at vm_phys_free_pages+0x253/frame 0xfe017547c450 vm_page_free_phys_pglist() at vm_page_free_phys_pglist+0x37/frame 0xfe017547c470 vm_object_terminate() at vm_object_terminate+0x405/frame 0xfe017547c4d0 vm_object_deallocate() at vm_object_deallocate+0x45c/frame 0xfe017547c530 vm_map_process_deferred() at vm_map_process_deferred+0x99/frame 0xfe017547c560 vm_map_remove() at vm_map_remove+0xc6/frame 0xfe017547c590 exec_new_vmspace() at exec_new_vmspace+0x185/frame 0xfe017547c5f0 exec_elf64_imgact() at exec_elf64_imgact+0x907/frame 0xfe017547c6e0 kern_execve() at kern_execve+0x82c/frame 0xfe017547ca40 sys_execve() at sys_execve+0x4c/frame 0xfe017547cac0 amd64_syscall() at amd64_syscall+0x79b/frame 0xfe017547cbf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe017547cbf0 -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
