Discussion:
[RFC] Deprecation and removal of the drm2 driver
(too old to reply)
Niclas Zeising
2018-05-18 17:58:10 UTC
Permalink
[ Cross posted to freebsd-current@ and freebsd-***@. Please respect
reply-to and send all replies to freebsd-***@. Thanks! ]


Hi!
I propose that we remove the old drm2 driver (sys/dev/drm2) from
FreeBSD. I suggest the driver is marked as deprecated in 11.x and
removed from 12.0, as was done for other drivers recently. Some
background and rationale:

The drm2 driver was the original port of a KMS driver to FreeBSD. It
was done by Konstantin Belousov to support Intel graphics cards, and
later extended by Jean-Sébastien Pédron as well as Konstantin to match
what's in Linux 3.8. This included unstable support from Haswell, but
nothing newer than that.

For quite some time now we have had the graphics/drm-stable-kmod and
graphics/drm-next-kmods which provides support for modern AMD and Intel
graphics cards. These ports, together with the linuxkpi, or lkpi, has
made it significantly easier to port and update our graphics drivers.
Further, these new drivers cover the same drivers as the old drm2 driver.

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?

Thank you
Regards
--
Niclas Zeising
FreeBSD x11/graphics team
Cy Schubert
2018-05-18 19:12:43 UTC
Permalink
The port doesn't support i386.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Niclas Zeising
Sent: 18/05/2018 11:00
To: freebsd-***@freebsd.org
Subject: [RFC] Deprecation and removal of the drm2 driver

[ Cross posted to freebsd-current@ and freebsd-***@. Please respect
reply-to and send all replies to freebsd-***@. Thanks! ]


Hi!
I propose that we remove the old drm2 driver (sys/dev/drm2) from
FreeBSD. I suggest the driver is marked as deprecated in 11.x and
removed from 12.0, as was done for other drivers recently. Some
background and rationale:

The drm2 driver was the original port of a KMS driver to FreeBSD. It
was done by Konstantin Belousov to support Intel graphics cards, and
later extended by Jean-Sébastien Pédron as well as Konstantin to match
what's in Linux 3.8. This included unstable support from Haswell, but
nothing newer than that.

For quite some time now we have had the graphics/drm-stable-kmod and
graphics/drm-next-kmods which provides support for modern AMD and Intel
graphics cards. These ports, together with the linuxkpi, or lkpi, has
made it significantly easier to port and update our graphics drivers.
Further, these new drivers cover the same drivers as the old drm2 driver.

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?

Thank you
Regards
--
Niclas Zeising
FreeBSD x11/graphics team
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
Warner Losh
2018-05-18 20:03:32 UTC
Permalink
On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
***@troutmask.apl.washington.edu> wrote:

> On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
> > On Fri, May 18, 2018, 20:00 Niclas Zeising <***@freebsd.org> wrote:
> >
> > > I propose that we remove the old drm2 driver (sys/dev/drm2) from
> > > FreeBSD. I suggest the driver is marked as deprecated in 11.x and
> > > removed from 12.0, as was done for other drivers recently. Some
> > > background and rationale:
> > >
> > > The drm2 driver was the original port of a KMS driver to FreeBSD. It
> > > was done by Konstantin Belousov to support Intel graphics cards, and
> > > later extended by Jean-Sébastien Pédron as well as Konstantin to match
> > > what's in Linux 3.8. This included unstable support from Haswell, but
> > > nothing newer than that.
> > >
> > > For quite some time now we have had the graphics/drm-stable-kmod and
> > > graphics/drm-next-kmods which provides support for modern AMD and Intel
> > > graphics cards. These ports, together with the linuxkpi, or lkpi, has
> > > made it significantly easier to port and update our graphics drivers.
> > > Further, these new drivers cover the same drivers as the old drm2
> driver.
> > >
> > > 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?
> > >
> > > Thank you
> > > Regards
> > > --
> > > Niclas Zeising
> > > FreeBSD x11/graphics team
> > > _______________________________________________
> > > freebsd-***@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> > >
> >
> > Sounds good ( deprecate resp remove ). It causes more confusion and
> > problems and it solves nothing.
> >
>
> Check the Makefiles
>
> % more /usr/ports/graphics/drm-next-kmod/Makefile
>
> ONLY_FOR_ARCHS= amd64
> ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on amd64
>
> Not to ia32 friendly.
>

So do people use i386 for desktop? And need the latest KMS stuff?

Warner
Johannes Lundberg
2018-05-18 20:33:40 UTC
Permalink
On Fri, May 18, 2018 at 9:22 PM, Ben Widawsky <***@bwidawsk.net> wrote:

> On 18-05-18 14:15:03, Warner Losh wrote:
> > On Fri, May 18, 2018 at 2:12 PM, Johannes Lundberg <***@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Fri, May 18, 2018 at 9:03 PM, Warner Losh <***@bsdimp.com> wrote:
> > >
> > >> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> > >> ***@troutmask.apl.washington.edu> wrote:
> > >>
> > >> > On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
> > >> > > On Fri, May 18, 2018, 20:00 Niclas Zeising <***@freebsd.org>
> > >> wrote:
> > >> > >
> > >> > > > I propose that we remove the old drm2 driver (sys/dev/drm2) from
> > >> > > > FreeBSD. I suggest the driver is marked as deprecated in 11.x
> and
> > >> > > > removed from 12.0, as was done for other drivers recently. Some
> > >> > > > background and rationale:
> > >> > > >
> > >> > > > The drm2 driver was the original port of a KMS driver to
> FreeBSD.
> > >> It
> > >> > > > was done by Konstantin Belousov to support Intel graphics
> cards, and
> > >> > > > later extended by Jean-Sébastien Pédron as well as Konstantin to
> > >> match
> > >> > > > what's in Linux 3.8. This included unstable support from
> Haswell,
> > >> but
> > >> > > > nothing newer than that.
> > >> > > >
> > >> > > > For quite some time now we have had the
> graphics/drm-stable-kmod and
> > >> > > > graphics/drm-next-kmods which provides support for modern AMD
> and
> > >> Intel
> > >> > > > graphics cards. These ports, together with the linuxkpi, or
> lkpi,
> > >> has
> > >> > > > made it significantly easier to port and update our graphics
> > >> drivers.
> > >> > > > Further, these new drivers cover the same drivers as the old
> drm2
> > >> > driver.
> > >> > > >
> > >> > > > 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?
> > >> > > >
> > >> > > > Thank you
> > >> > > > Regards
> > >> > > > --
> > >> > > > Niclas Zeising
> > >> > > > FreeBSD x11/graphics team
> > >> > > > _______________________________________________
> > >> > > > freebsd-***@freebsd.org mailing list
> > >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > >> > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> > >> > freebsd.org"
> > >> > > >
> > >> > >
> > >> > > Sounds good ( deprecate resp remove ). It causes more confusion
> and
> > >> > > problems and it solves nothing.
> > >> > >
> > >> >
> > >> > Check the Makefiles
> > >> >
> > >> > % more /usr/ports/graphics/drm-next-kmod/Makefile
> > >> >
> > >> > ONLY_FOR_ARCHS= amd64
> > >> > ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on
> > >> amd64
> > >> >
> > >> > Not to ia32 friendly.
> > >> >
> > >>
> > >> So do people use i386 for desktop? And need the latest KMS stuff?
> > >>
> > >
> > > Yeah I was wondering the same.. If you're running i386, do you need drm
> > > drivers? Will scfb work an i386? (probably has legacy bios and if I
> > > remember correctly, scfb is UEFI only)
> > > I do feel sorry for anyone who would have to revert back to VESA...
> > >
> > > Would it be too much trouble to move it to a port?
> > >
> >
> > If there's someone who needs it for i386, and wants to do the work and
> > maintain it, we should allow it. But the drm2 maintainers have said its
> > likely totally broken anyway.
> >
> > Warner
>
> As a long time developer in drm/i915, and newly interested in FreeBSD (ie.
> no
> history on the matter), is there some upside and/or desire to have native
> support, or is the drm-next-kmod solution good enough?
>

Given the fast evolution of graphics hardware and the amount of code in
only the AMD and Intel drivers, keep several native implementations seems
impossible, if not wasteful.
If you are referring to drm2 in the kernel, that's not much more native
than the drm kmods, it still uses a linux compatibility layer (but not as
sophisticated).

If we were to focus our effort somewhere, it should be to create a Common
Kernel Programming Interface for Linux and *BSDs, especially for DRM
drivers. Something a bit more stable that what we see in Linux today.
Rozhuk Ivan
2018-05-20 14:22:29 UTC
Permalink
On Fri, 18 May 2018 21:12:26 +0100
Johannes Lundberg <***@gmail.com> wrote:

Is Ryzen 2200G integrated graphic supported?
Rozhuk Ivan
2018-05-20 16:51:39 UTC
Permalink
On Sun, 20 May 2018 16:32:50 +0100
Johannes Lundberg <***@gmail.com> wrote:

> Not in the current port.
> I think it should be usable in 4.15 but need some more tweaking and
> updated firmware modules before we can update the port.
> Active development going on here
> https://github.com/FreeBSDDesktop/kms-drm/issues


Thanks!
What futures will avaible in 4.15 - 4.16?
Video decoding acceleration?
3d acceleration?
Niclas Zeising
2018-05-20 16:47:07 UTC
Permalink
On 05/20/18 18:40, Steve Kargl wrote:
> On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote:
>> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
>> ***@troutmask.apl.washington.edu> wrote:
>>
>>> On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
>>>> On Fri, May 18, 2018, 20:00 Niclas Zeising <***@freebsd.org> wrote:
>>>>
>>>>> I propose that we remove the old drm2 driver (sys/dev/drm2) from
>>>>> FreeBSD. I suggest the driver is marked as deprecated in 11.x and
>>>>> removed from 12.0, as was done for other drivers recently. Some
>>>>> background and rationale:
>>>>>
>>>>
>>>> Sounds good ( deprecate resp remove ). It causes more confusion and
>>>> problems and it solves nothing.
>>>>
>>>
>>> Check the Makefiles
>>>
>>> % more /usr/ports/graphics/drm-next-kmod/Makefile
>>>
>>> ONLY_FOR_ARCHS= amd64
>>> ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on amd64
>>>
>>> Not to ia32 friendly.
>>>
>>
>> So do people use i386 for desktop? And need the latest KMS stuff?
>>
>
> Just a data point. I had to replace the dead disk in my laptop,
> and after 2 days of doing a re-install and update of -current
> on a shiny new SSD.
>
> Before loading Xorg.
>
> % kldstat
> Id Refs Address Size Name
> 1 7 0x800000 1ac31d4 kernel
> 2 1 0x1e9ae000 5000 ums.ko
> 3 1 0x1e9b9000 4000 uhid.ko
>
> After starting Xorg without an xorg.conf in /etc/X11.
>
> Id Refs Address Size Name
> 1 27 0x800000 1ac31d4 kernel
> 2 1 0x1e9ae000 5000 ums.ko
> 3 1 0x1e9b9000 4000 uhid.ko
> 4 1 0x1eaa9000 96000 i915kms.ko
> 5 1 0x1eb40000 4a000 drm2.ko
> 6 4 0x1eb8b000 5000 iicbus.ko
> 7 1 0x1ebc9000 3000 iic.ko
> 8 1 0x1ebcf000 4000 iicbb.ko
>
> So, drm2.ko and i915kms.ko are loaded automatically. It is
> unclear why functionality that works should be removed.
>
> xwininfo shows
>
> Width: 1400
> Height: 1050
> Depth: 24
> Visual: 0x21
>

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
--
Niclas
Oliver Pinter
2018-05-21 18:25:41 UTC
Permalink
On 5/21/18, Steve Kargl <***@troutmask.apl.washington.edu> 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 <***@hardenedbsd.org> 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:

***@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

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support
+makeoptions WITHOUT_MODULES="drm drm2" # by default disable the
building of DRM* for GENERIC

options SCHED_ULE # ULE scheduler
options PREEMPTION # 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
>
Johannes Lundberg
2018-05-22 06:50:39 UTC
Permalink
On Mon, May 21, 2018 at 23:50 Steve Kargl <***@troutmask.apl.washington.edu>
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-***@freebsd.org"
>
A. Wilcox
2018-05-22 21:49:19 UTC
Permalink
>>>>> 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?



>
> With such long-time support offered by 11- branch, why hamper development
> of 12 by lugging around old, hard to maintain code that is relevant for
> only legacy hardware?
>


it makes me giggle that people still think non-amd64 is "legacy".

i386 is alive and well - new chips are being fabbed based on the 586
design with pci-e slots; not to mention things like the Talos and
AmigaOne for PowerPC.


--arw

--
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/
K. Macy
2018-05-22 21:56:55 UTC
Permalink
>
>
> it makes me giggle that people still think non-amd64 is "legacy".
>
> i386 is alive and well - new chips are being fabbed based on the 586
> design with pci-e slots; not to mention things like the Talos and
> AmigaOne for PowerPC.


DRM2 doesn't support anything later than mid-Haswell. The chips in
question all pre-date 2007. Users of low-volume hardware on chips from
that period are welcome to continue to sustain themselves on the drm2
port just as the other 95+% of the user base will use what is now
referred to as drm-next. Even by powerpc maintainers' admission DRM2
also only barely works there. I've promised Justin that I'll make
drm-next work on Talos once POWER9 support is solid enough.

Cheers.

-M
Steve Kargl
2018-05-22 23:26:03 UTC
Permalink
On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote:
> >
> >
> > it makes me giggle that people still think non-amd64 is "legacy".
> >
> > i386 is alive and well - new chips are being fabbed based on the 586
> > design with pci-e slots; not to mention things like the Talos and
> > AmigaOne for PowerPC.
>
>
> DRM2 doesn't support anything later than mid-Haswell. The chips in
> question all pre-date 2007. Users of low-volume hardware on chips from
> that period are welcome to continue to sustain themselves on the drm2
> port just as the other 95+% of the user base will use what is now
> referred to as drm-next. Even by powerpc maintainers' admission DRM2
> also only barely works there. I've promised Justin that I'll make
> drm-next work on Talos once POWER9 support is solid enough.

% dmesg | CPU
CPU: AMD FX(tm)-8350 Eight-Core Processor (4018.34-MHz K8-class CPU)
% kldstat
troutmask:sgk[205] kldstat
Id Refs Address Size Name
9 1 0xffffffff8141e000 db148 radeonkms.ko
10 1 0xffffffff814fa000 3f7d0 drm2.ko
11 2 0xffffffff8153a000 acf8 agp.ko
12 1 0xffffffff81545000 12f9 radeonkmsfw_CAICOS_pfp.ko
13 1 0xffffffff81547000 16f7 radeonkmsfw_CAICOS_me.ko
14 1 0xffffffff81549000 d73 radeonkmsfw_BTC_rlc.ko
15 1 0xffffffff8154a000 5f97 radeonkmsfw_CAICOS_mc.ko

Mid-Haswell?

--
Steve
K. Macy
2018-05-22 23:32:39 UTC
Permalink
Why are you running i386 on that?

On Tue, May 22, 2018 at 4:26 PM, Steve Kargl
<***@troutmask.apl.washington.edu> wrote:
> On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote:
>> >
>> >
>> > it makes me giggle that people still think non-amd64 is "legacy".
>> >
>> > i386 is alive and well - new chips are being fabbed based on the 586
>> > design with pci-e slots; not to mention things like the Talos and
>> > AmigaOne for PowerPC.
>>
>>
>> DRM2 doesn't support anything later than mid-Haswell. The chips in
>> question all pre-date 2007. Users of low-volume hardware on chips from
>> that period are welcome to continue to sustain themselves on the drm2
>> port just as the other 95+% of the user base will use what is now
>> referred to as drm-next. Even by powerpc maintainers' admission DRM2
>> also only barely works there. I've promised Justin that I'll make
>> drm-next work on Talos once POWER9 support is solid enough.
>
> % dmesg | CPU
> CPU: AMD FX(tm)-8350 Eight-Core Processor (4018.34-MHz K8-class CPU)
> % kldstat
> troutmask:sgk[205] kldstat
> Id Refs Address Size Name
> 9 1 0xffffffff8141e000 db148 radeonkms.ko
> 10 1 0xffffffff814fa000 3f7d0 drm2.ko
> 11 2 0xffffffff8153a000 acf8 agp.ko
> 12 1 0xffffffff81545000 12f9 radeonkmsfw_CAICOS_pfp.ko
> 13 1 0xffffffff81547000 16f7 radeonkmsfw_CAICOS_me.ko
> 14 1 0xffffffff81549000 d73 radeonkmsfw_BTC_rlc.ko
> 15 1 0xffffffff8154a000 5f97 radeonkmsfw_CAICOS_mc.ko
>
> Mid-Haswell?
>
> --
> Steve
Steve Kargl
2018-05-22 23:42:25 UTC
Permalink
On Tue, May 22, 2018 at 04:32:39PM -0700, K. Macy wrote:
> Why are you running i386 on that?
>

I'm not. Just pointing out that drm2 runs on amd64 as
well as i386. Also need to correct the dis-information
that drm2 only applies to mid-Haswell and older.

In the end, src committers will do what they want, so
this is my last post.

--
Steve
Steve Kargl
2018-05-22 23:35:58 UTC
Permalink
On Tue, May 22, 2018 at 07:50:39AM +0100, Johannes Lundberg wrote:
> On Mon, May 21, 2018 at 23:50 Steve Kargl <***@troutmask.apl.washington.edu>
> 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".
> >
> > 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_.

Best for amd64. For the majority, if one starts X, it
automatically loads drm2 if one allows X to configure
itself and drm2 applies. It's automatically loaded
on both by i386 laptop and amd64 desktop.

> Let me ask you, what’s wrong with this one-liner after base install
> pkg install drm2
> ?

1) The original email did not indicate the code would be
moved to a port. It simply said removed.

2) Nothing wrong if you know where to go looking for drm2.
FreeBSD goes from having drm2 automatically loaded for
a user to hoping that a user knows about a port.

3) I've already posted a 2-line patch for amd64 (twice actually).
How many lines are needed to make the port?

--
Steve
Cy Schubert
2018-05-18 22:27:43 UTC
Permalink
In message <***@sea.ntplx.net>, Daniel
Eischen wr
ites:
> On Fri, 18 May 2018, Warner Losh wrote:
>
> > On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> > ***@troutmask.apl.washington.edu> wrote:
> >>
> >> Check the Makefiles
> >>
> >> % more /usr/ports/graphics/drm-next-kmod/Makefile
> >>
> >> ONLY_FOR_ARCHS= amd64
> >> ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on amd64
> >>
> >> Not to ia32 friendly.
> >>
> >
> > So do people use i386 for desktop? And need the latest KMS stuff?
>
> I can easily imagine an embedded x86 kiosk type appliance. Does
> basic xorg stuff work without drm?

Yes, with VESA, albeit aspect ratios are off.


--
Cheers,
Cy Schubert <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.
Boris Samorodov
2018-05-20 13:05:57 UTC
Permalink
20.05.2018 16:03, Johannes Lundberg пишет:
> On Sun, May 20, 2018 at 1:36 PM, Boris Samorodov <***@passap.ru> wrote:
>
>> 18.05.2018 20:58, Niclas Zeising пишет:
>>
>>> Is there anyone still using the drm2 driver on 12-CURRENT? If so, what
>>> is preventing you from switching to the port?
>>
>> I use base packages and can not use port:
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069329.html
>
> If we remove drm.ko from base (which is suggested) you would be able to
> install the drm-stable/next-kmod packages without conflict.

Great, thanks.

--
WBR, bsam
Rodney W. Grimes
2018-05-22 22:12:39 UTC
Permalink
> >
> >
> > it makes me giggle that people still think non-amd64 is "legacy".
> >
> > i386 is alive and well - new chips are being fabbed based on the 586
> > design with pci-e slots; not to mention things like the Talos and
> > AmigaOne for PowerPC.

Yes, some how we need to shake off the idea that all the world
is going to be 64 bit, and stop talking about EOL for 32 bit
x86, IMHO that would be a serious mistake. For one any VM
that does not need >4G of address space is a waste to run
in 64 bit mode.

> DRM2 doesn't support anything later than mid-Haswell. The chips in
> question all pre-date 2007. Users of low-volume hardware on chips from

Um, haswell announced in 2011, started shipping in mid 2013, and last
product started to ship in 2015, so if "mid-haswell" is the supported
chip arrena that would be pre date 2012?

Also as the Moore's law curve flattens expect the life of these
older, but not so old, machines to live quiet some time. I
believe we are talking sandy bridge and earlier? If that is
corret Sandy bridge is still a very viable system.

> that period are welcome to continue to sustain themselves on the drm2
> port just as the other 95+% of the user base will use what is now
> referred to as drm-next. Even by powerpc maintainers' admission DRM2
> also only barely works there. I've promised Justin that I'll make
> drm-next work on Talos once POWER9 support is solid enough.

I think the original RFC has been answer, yes there are people still
using DRM2, and they wish to continue to use it into the 12.x time
frame.

Lets find a technically agreeable solution to that, and move forward.

I am concerned about just disabling the compile on amd64,
that typically leads to bit rot of the i386 code.

I am concerned about just shoving it out to ports, as that makes
it rot even faster.

I am still very concerned that our in base i9xx code is like 4
years old and everyone is told to go to kmod-next from ports
as well.

No, I do not have a solution, but I have not tried hard to find
one. I am sure if we try hard to find one it can be done.

Regards,
--
Rod Grimes ***@freebsd.org
K. Macy
2018-05-22 22:19:44 UTC
Permalink
> I am concerned about just shoving it out to ports, as that makes
> it rot even faster.
>
> I am still very concerned that our in base i9xx code is like 4
> years old and everyone is told to go to kmod-next from ports
> as well.
>
> No, I do not have a solution, but I have not tried hard to find
> one. I am sure if we try hard to find one it can be done.

drm-next is a port and it's what most everyone will be using going
forward. You're asking us to make a special case for a small vocal
group of i386 users. If i386 is sufficiently important, its user base
can support it.

Cheers.
-M
Nathan Whitehorn
2018-05-23 01:29:14 UTC
Permalink
On 05/22/18 18:12, Rodney W. Grimes wrote:
>>>
>>> it makes me giggle that people still think non-amd64 is "legacy".
>>>
>>> i386 is alive and well - new chips are being fabbed based on the 586
>>> design with pci-e slots; not to mention things like the Talos and
>>> AmigaOne for PowerPC.
> Yes, some how we need to shake off the idea that all the world
> is going to be 64 bit, and stop talking about EOL for 32 bit
> x86, IMHO that would be a serious mistake. For one any VM
> that does not need >4G of address space is a waste to run
> in 64 bit mode.
>
>> DRM2 doesn't support anything later than mid-Haswell. The chips in
>> question all pre-date 2007. Users of low-volume hardware on chips from
> Um, haswell announced in 2011, started shipping in mid 2013, and last
> product started to ship in 2015, so if "mid-haswell" is the supported
> chip arrena that would be pre date 2012?
>
> Also as the Moore's law curve flattens expect the life of these
> older, but not so old, machines to live quiet some time. I
> believe we are talking sandy bridge and earlier? If that is
> corret Sandy bridge is still a very viable system.
>
>> that period are welcome to continue to sustain themselves on the drm2
>> port just as the other 95+% of the user base will use what is now
>> referred to as drm-next. Even by powerpc maintainers' admission DRM2
>> also only barely works there. I've promised Justin that I'll make
>> drm-next work on Talos once POWER9 support is solid enough.
> I think the original RFC has been answer, yes there are people still
> using DRM2, and they wish to continue to use it into the 12.x time
> frame.
>
> Lets find a technically agreeable solution to that, and move forward.
>
> I am concerned about just disabling the compile on amd64,
> that typically leads to bit rot of the i386 code.
>
> I am concerned about just shoving it out to ports, as that makes
> it rot even faster.
>
> I am still very concerned that our in base i9xx code is like 4
> years old and everyone is told to go to kmod-next from ports
> as well.
>
> No, I do not have a solution, but I have not tried hard to find
> one. I am sure if we try hard to find one it can be done.
>
> Regards,

The real question in this thread is, I think: Do we want to co-version
the drm kernel modules with kernel/OS releases or with the graphics
drivers that use them (which are in ports)? I use the base modules (on
2014-era amd64 hardware), but would be perfectly happy with modules in
ports and it seems like there is a compelling argument for co-versioning
the things in x11-drivers with the kernel modules.

I would like to make a proposal here:
- Rename drm-next to drm-kmod
- Move sys/dev/drm2 to a new port drm-kmod-legacy
- Have one of the two, by default drm-kmod (amd64) or drm-kmod-legacy
(i386), pulled in as a dependency by the relevant X11 drivers
- Garbage-collect dev/drm, which supports 3DFX and Rage 128 and such
archaic things

I think this keeps the user experience intact and lets the graphics
developers update in the way that works best for them.
-Nathan
Rodney W. Grimes
2018-05-22 22:47:15 UTC
Permalink
> > I am concerned about just shoving it out to ports, as that makes
> > it rot even faster.
> >
> > I am still very concerned that our in base i9xx code is like 4
> > years old and everyone is told to go to kmod-next from ports
> > as well.
> >
> > No, I do not have a solution, but I have not tried hard to find
> > one. I am sure if we try hard to find one it can be done.
>
> drm-next is a port and it's what most everyone will be using going
> forward. You're asking us to make a special case for a small vocal
> group of i386 users. If i386 is sufficiently important, its user base
> can support it.

Are you saying there is only one way forward?


--
Rod Grimes ***@freebsd.org
Philip Homburg
2018-05-23 09:48:38 UTC
Permalink
>Also as the Moore's law curve flattens expect the life of these
>older, but not so old, machines to live quiet some time. I
>believe we are talking sandy bridge and earlier? If that is
>corret Sandy bridge is still a very viable system.

I noticed this lack of love for older systems recently.

I wanted to use an older Dell server to test the 11.2 BETAs and RCs.

Turns out, you can't install FreeBSD using a USB stick image because the
BIOS only support MBR. No idea why MBR support was dropped for the USB images.

In the end I had to find a CD burner, and after a couple of tries managed to
install from CD.

After that, my ansible playbooks started failing because /boot/loader.conf
is absent if you boot from zfs in combination with MBR.

Pity. This older server hardware is great for trying out new releases, play
with zfs, etc.
s***@nethelp.no
2018-05-23 10:29:21 UTC
Permalink
Hijacking a thread here,

> Turns out, you can't install FreeBSD using a USB stick image because the
> BIOS only support MBR. No idea why MBR support was dropped for the USB images.
>
> In the end I had to find a CD burner, and after a couple of tries managed to
> install from CD.

On a somewhat related note - I recently installed 11.1-STABLE on a box
with support for both UEFI and "good old fashioned BIOS". I initially
used UEFI and GPT, but ended up switching to BIOS and MBR because I
needed boot.config to enable booting from an alternate partition.

Despite lots of Googling I couldn't find a simple way to do this using
config stored on the disk itself (e.g. having "0:ad(0,f)/boot/loader"
in /boot.config) with UEFI.

Does anybody know if this can be done using UEFI?

Steinar Haug, Nethelp consulting, ***@nethelp.no
Toomas Soome
2018-05-23 10:48:58 UTC
Permalink
> On 23 May 2018, at 13:29, ***@nethelp.no wrote:
>
> Hijacking a thread here,
>
>> Turns out, you can't install FreeBSD using a USB stick image because the
>> BIOS only support MBR. No idea why MBR support was dropped for the USB images.
>>
>> In the end I had to find a CD burner, and after a couple of tries managed to
>> install from CD.
>
> On a somewhat related note - I recently installed 11.1-STABLE on a box
> with support for both UEFI and "good old fashioned BIOS". I initially
> used UEFI and GPT, but ended up switching to BIOS and MBR because I
> needed boot.config to enable booting from an alternate partition.
>
> Despite lots of Googling I couldn't find a simple way to do this using
> config stored on the disk itself (e.g. having "0:ad(0,f)/boot/loader"
> in /boot.config) with UEFI.
>
> Does anybody know if this can be done using UEFI?
>
> Steinar Haug, Nethelp consulting, ***@nethelp.no

it can but it a bit different situation there. you can not start bios boot loader from UEFI loader or vice versa, you only can use the same platform binaries.

for UEFI case, the boot1.efi does not process boot.config, so you have total 3 options - you switch boot disk in UEFI boot manager, or you use chain command to load either bootx64.efi from target disk ESP partition or you use chain command to load /boot/loader.efi from target disk freebsd root file system. You also can set currdev to point to new root, but usually you want a bit more (read in the configuration etc) so the chainload may be a bit easier.

Once you have figured out the proper file name to use with chain command, you can set chain_disk to have it as value and you will have chain menu entry… like chain_disk=zfs:zroot/ROOT/default:/boot/loader.efi

rgds,
toomas
Andreas Nilsson
2018-05-23 11:14:07 UTC
Permalink
On Wed, May 23, 2018 at 11:48 AM, Philip Homburg <pch-fbsd-***@u-1.phicoh.com>
wrote:

> >Also as the Moore's law curve flattens expect the life of these
> >older, but not so old, machines to live quiet some time. I
> >believe we are talking sandy bridge and earlier? If that is
> >corret Sandy bridge is still a very viable system.
>
> I noticed this lack of love for older systems recently.
>
> I wanted to use an older Dell server to test the 11.2 BETAs and RCs.
>
> Turns out, you can't install FreeBSD using a USB stick image because the
> BIOS only support MBR. No idea why MBR support was dropped for the USB
> images.
>

It's not that hard create a mbr based usb-stick. Far easier than to find a
CD burner.

>
> In the end I had to find a CD burner, and after a couple of tries managed
> to
> install from CD.
>
> After that, my ansible playbooks started failing because /boot/loader.conf
> is absent if you boot from zfs in combination with MBR.
>
I believe boot/loader.conf is something you have to create, it is not there
by default.

>
> Pity. This older server hardware is great for trying out new releases,
> play
> with zfs, etc.
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
>
Philip Homburg
2018-05-23 11:41:15 UTC
Permalink
>It's not that hard create a mbr based usb-stick. Far easier than to find a
>CD burner.

'Not hard' means
- undocumented. Or at least, if you start with release notes and install
instructions you won't find it.
- Probably only works if you already have a FreeBSD system.

And if it is indeed 'not hard', why not just generate such an image as part
of the release build?

>I believe boot/loader.conf is something you have to create, it is not there
>by default.

That's not the problem. The problem is that it lives on a separate zpool that
is lost at every reboot.
Ed Maste
2018-05-23 15:22:59 UTC
Permalink
On 23 May 2018 at 05:48, Philip Homburg <pch-fbsd-***@u-1.phicoh.com> wrote:
>
> Turns out, you can't install FreeBSD using a USB stick image because the
> BIOS only support MBR. No idea why MBR support was dropped for the USB images.

We haven't "dropped" MBR support, and our amd64 memstick images are a
combined hybrid format and do in general boot on legacy systems. That
said, there are a number of firmware implementations that refuse to
boot from the hybrid format - this has been a problem with Lenovo
firmware in particular.

Those of you with a system unable to boot from our MBR images, can you
reply to the "Boot USB memstick with MBR" fork of this thread with
details about the system and firmware version?
Glen Barber
2018-05-23 15:52:55 UTC
Permalink
On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> >Also as the Moore's law curve flattens expect the life of these
> >older, but not so old, machines to live quiet some time. I
> >believe we are talking sandy bridge and earlier? If that is
> >corret Sandy bridge is still a very viable system.
>
> I noticed this lack of love for older systems recently.
>
> I wanted to use an older Dell server to test the 11.2 BETAs and RCs.
>
> Turns out, you can't install FreeBSD using a USB stick image because the
> BIOS only support MBR. No idea why MBR support was dropped for the USB images.
>
> In the end I had to find a CD burner, and after a couple of tries managed to
> install from CD.
>
> After that, my ansible playbooks started failing because /boot/loader.conf
> is absent if you boot from zfs in combination with MBR.
>
> Pity. This older server hardware is great for trying out new releases, play
> with zfs, etc.

The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
built as hybrid images, supporting both MBR and GPT, as well as being
written to a flash drive (like memstick.img) as well as a CD.

MBR support was initially removed from the memstick installer, as it is
not compatible with some UEFI implementations. (Or, at least that is my
understanding, based on my limited intimate knowledge of UEFI.)

Glen
M&S - Krasznai András
2018-05-24 06:16:06 UTC
Permalink
hi

I am using a Lenovo T510 laptop with FreeBSD-CURRENT.

It contains Intel I5 processor and integrated Intel graphics adapter.

I tried to set it to drm-stable-kmod as well as to drm-next-kmod, none was working, I got a fatal trap, kernel panic during boot.

Compiling the packages on my system did not help. The graphics adapter can be old for drm-xxxx-kmod packages.

Drm2 from the base works correctly on my laptop.

rgds

Andras Krasznai




-----Eredeti üzenet-----
Feladó: owner-freebsd-***@freebsd.org [mailto:owner-freebsd-***@freebsd.org] Meghatalmazó Philip Homburg
Küldve: 2018. május 23. 11:49
Címzett: Rodney W. Grimes
Másolatot kap: K. Macy; A. Wilcox; FreeBSD Current
Tárgy: Re: [RFC] Deprecation and removal of the drm2 driver

>Also as the Moore's law curve flattens expect the life of these
>older, but not so old, machines to live quiet some time. I
>believe we are talking sandy bridge and earlier? If that is
>corret Sandy bridge is still a very viable system.

I noticed this lack of love for older systems recently.

I wanted to use an older Dell server to test the 11.2 BETAs and RCs.

Turns out, you can't install FreeBSD using a USB stick image because the
BIOS only support MBR. No idea why MBR support was dropped for the USB images.

In the end I had to find a CD burner, and after a couple of tries managed to
install from CD.

After that, my ansible playbooks started failing because /boot/loader.conf
is absent if you boot from zfs in combination with MBR.

Pity. This older server hardware is great for trying out new releases, play
with zfs, etc.
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
Hans Petter Selasky
2018-05-24 06:35:41 UTC
Permalink
On 05/24/18 08:16, M&S - Krasznai András wrote:
> I tried to set it to drm-stable-kmod as well as to drm-next-kmod, none was working, I got a fatal trap, kernel panic during boot.

Did you build from source? Can you show the panic?

drm-next-kmod should be loaded by /etc/rc.conf like this, can you try again?


kld_list="/boot/modules/i915kms.ko"


--HPS
Rodney W. Grimes
2018-05-24 15:22:12 UTC
Permalink
> On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > >Also as the Moore's law curve flattens expect the life of these
> > >older, but not so old, machines to live quiet some time. I
> > >believe we are talking sandy bridge and earlier? If that is
> > >corret Sandy bridge is still a very viable system.
> >
> > I noticed this lack of love for older systems recently.
> >
> > I wanted to use an older Dell server to test the 11.2 BETAs and RCs.
> >
> > Turns out, you can't install FreeBSD using a USB stick image because the
> > BIOS only support MBR. No idea why MBR support was dropped for the USB images.
> >
> > In the end I had to find a CD burner, and after a couple of tries managed to
> > install from CD.
> >
> > After that, my ansible playbooks started failing because /boot/loader.conf
> > is absent if you boot from zfs in combination with MBR.
> >
> > Pity. This older server hardware is great for trying out new releases, play
> > with zfs, etc.
>
> The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> built as hybrid images, supporting both MBR and GPT, as well as being
> written to a flash drive (like memstick.img) as well as a CD.

To clarify a minor point here, are the amd64 disc1.iso images or
both the amd64 and i386 disk1.iso images being built as "hybrid"?

As this is what I see on my system:
***@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 sectors
FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data '11_2_BETA2_I386_CD' (bootable)

> MBR support was initially removed from the memstick installer, as it is
> not compatible with some UEFI implementations. (Or, at least that is my
> understanding, based on my limited intimate knowledge of UEFI.)
>
> Glen
>

--
Rod Grimes ***@freebsd.org
Glen Barber
2018-05-24 16:02:34 UTC
Permalink
On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:
> > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > > >Also as the Moore's law curve flattens expect the life of these
> > > >older, but not so old, machines to live quiet some time. I
> > > >believe we are talking sandy bridge and earlier? If that is
> > > >corret Sandy bridge is still a very viable system.
> > >
> > > I noticed this lack of love for older systems recently.
> > >
> > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs.
> > >
> > > Turns out, you can't install FreeBSD using a USB stick image because the
> > > BIOS only support MBR. No idea why MBR support was dropped for the USB images.
> > >
> > > In the end I had to find a CD burner, and after a couple of tries managed to
> > > install from CD.
> > >
> > > After that, my ansible playbooks started failing because /boot/loader.conf
> > > is absent if you boot from zfs in combination with MBR.
> > >
> > > Pity. This older server hardware is great for trying out new releases, play
> > > with zfs, etc.
> >
> > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> > built as hybrid images, supporting both MBR and GPT, as well as being
> > written to a flash drive (like memstick.img) as well as a CD.
>
> To clarify a minor point here, are the amd64 disc1.iso images or
> both the amd64 and i386 disk1.iso images being built as "hybrid"?
>

Only amd64. i386 does not have UEFI-/GPT-related boot issues.

> As this is what I see on my system:
> ***@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 sectors
> FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data '11_2_BETA2_I386_CD' (bootable)
>
> > MBR support was initially removed from the memstick installer, as it is
> > not compatible with some UEFI implementations. (Or, at least that is my
> > understanding, based on my limited intimate knowledge of UEFI.)
> >

Glen
Rodney W. Grimes
2018-05-24 16:10:10 UTC
Permalink
-- Start of PGP signed section.
> On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:
> > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > > > >Also as the Moore's law curve flattens expect the life of these
> > > > >older, but not so old, machines to live quiet some time. I
> > > > >believe we are talking sandy bridge and earlier? If that is
> > > > >corret Sandy bridge is still a very viable system.
> > > >
> > > > I noticed this lack of love for older systems recently.
> > > >
> > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs.
> > > >
> > > > Turns out, you can't install FreeBSD using a USB stick image because the
> > > > BIOS only support MBR. No idea why MBR support was dropped for the USB images.
> > > >
> > > > In the end I had to find a CD burner, and after a couple of tries managed to
> > > > install from CD.
> > > >
> > > > After that, my ansible playbooks started failing because /boot/loader.conf
> > > > is absent if you boot from zfs in combination with MBR.
> > > >
> > > > Pity. This older server hardware is great for trying out new releases, play
> > > > with zfs, etc.
> > >
> > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> > > built as hybrid images, supporting both MBR and GPT, as well as being
> > > written to a flash drive (like memstick.img) as well as a CD.
> >
> > To clarify a minor point here, are the amd64 disc1.iso images or
> > both the amd64 and i386 disk1.iso images being built as "hybrid"?
> >
>
> Only amd64. i386 does not have UEFI-/GPT-related boot issues.

Here is a data point:

Test system is Dell R710,
First attempt is with BIOS in Boot mode: Bios
Second attempt is with BIOS in Boot mode: UEFI

Attemtped to boot amd64 version:
Screen goes white background, text appears (yes, way indented)
BTX version is 1.02
Consoles: internal video/keyboard
_

That last _ is a blinking cursor, system is hung, does repsond to C-A-del


Second attempt:
Works properly


I am going after Ed Maste's posted build image in the other thread now...


>
> > As this is what I see on my system:
> > ***@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 sectors
> > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data '11_2_BETA2_I386_CD' (bootable)
> >
> > > MBR support was initially removed from the memstick installer, as it is
> > > not compatible with some UEFI implementations. (Or, at least that is my
> > > understanding, based on my limited intimate knowledge of UEFI.)
> > >
>
> Glen
>
-- End of PGP section, PGP failed!

--
Rod Grimes ***@freebsd.org
O. Hartmann
2018-05-30 21:51:29 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Thu, 24 May 2018 09:10:10 -0700 (PDT)
"Rodney W. Grimes" <freebsd-***@pdx.rh.CN85.dnsmgr.net> schrieb:

> -- Start of PGP signed section.
> > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:
> > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > > > > >Also as the Moore's law curve flattens expect the life of these
> > > > > >older, but not so old, machines to live quiet some time. I
> > > > > >believe we are talking sandy bridge and earlier? If that is
> > > > > >corret Sandy bridge is still a very viable system.
> > > > >
> > > > > I noticed this lack of love for older systems recently.
> > > > >
> > > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs.
> > > > >
> > > > > Turns out, you can't install FreeBSD using a USB stick image because the
> > > > > BIOS only support MBR. No idea why MBR support was dropped for the USB images.
> > > > >
> > > > > In the end I had to find a CD burner, and after a couple of tries managed to
> > > > > install from CD.
> > > > >
> > > > > After that, my ansible playbooks started failing because /boot/loader.conf
> > > > > is absent if you boot from zfs in combination with MBR.
> > > > >
> > > > > Pity. This older server hardware is great for trying out new releases, play
> > > > > with zfs, etc.
> > > >
> > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> > > > built as hybrid images, supporting both MBR and GPT, as well as being
> > > > written to a flash drive (like memstick.img) as well as a CD.
> > >
> > > To clarify a minor point here, are the amd64 disc1.iso images or
> > > both the amd64 and i386 disk1.iso images being built as "hybrid"?
> > >
> >
> > Only amd64. i386 does not have UEFI-/GPT-related boot issues.
>
> Here is a data point:
>
> Test system is Dell R710,
> First attempt is with BIOS in Boot mode: Bios
> Second attempt is with BIOS in Boot mode: UEFI
>
> Attemtped to boot amd64 version:
> Screen goes white background, text appears (yes, way indented)
> BTX version is 1.02
> Consoles: internal video/keyboard
> _
>
> That last _ is a blinking cursor, system is hung, does repsond to C-A-del
>
>
> Second attempt:
> Works properly
>
>
> I am going after Ed Maste's posted build image in the other thread now...
>
>
> >
> > > As this is what I see on my system:
> > > ***@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : ID=0xee,
> > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 sectors
> > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data
> > > '11_2_BETA2_I386_CD' (bootable)
> > > > MBR support was initially removed from the memstick installer, as it is
> > > > not compatible with some UEFI implementations. (Or, at least that is my
> > > > understanding, based on my limited intimate knowledge of UEFI.)
> > > >
> >
> > Glen
> >
> -- End of PGP section, PGP failed!
>

Today, I tried to eliminate FreeBSD's native KMS drm2 by installing
graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT (FreeBSD 12.0-CURRENT
#46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel).

The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest firmware available
from late 2013) equipted with a XEON IvyBridge:

CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x7fbae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
AMD Features2=0x1<LAHF>
Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>
XSAVE Features=0x1<XSAVEOPT>
VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
TSC: P-state invariant, performance statistics
real memory = 17179869184 (16384 MB)
avail memory = 16295137280 (15540 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <ALASKA A M I>
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs


The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows seems to work).
So I'm stuck with BIOS.

Loading i915kms.ko/drm2.ko on the system put the console in a high-resolution mode
instead of this crap 80x25 ancient console immediately.

Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up in a trap
12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does load without
crashing the system - but the console is stuck in the clumsy 80x25 mode.

So why should I vote for non-working drivers to replace perfectly working ones?

oh


- --
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
Hans Petter Selasky
2018-05-31 07:28:52 UTC
Permalink
On 05/30/18 23:51, O. Hartmann wrote:
> Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up in a trap
> 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does load without
> crashing the system - but the console is stuck in the clumsy 80x25 mode.
>
> So why should I vote for non-working drivers to replace perfectly working ones?

Usually the crashes you get are low hanging fruit. Why not get the
backtrace and resolve the crash? It should take less than 10 minutes.

--HPS
Johannes Lundberg
2018-05-31 07:34:44 UTC
Permalink
On Wed, May 30, 2018 at 10:57 PM O. Hartmann <***@walstatt.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Thu, 24 May 2018 09:10:10 -0700 (PDT)
> "Rodney W. Grimes" <freebsd-***@pdx.rh.CN85.dnsmgr.net> schrieb:
>
> > -- Start of PGP signed section.
> > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:
> > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > > > > > >Also as the Moore's law curve flattens expect the life of these
> > > > > > >older, but not so old, machines to live quiet some time. I
> > > > > > >believe we are talking sandy bridge and earlier? If that is
> > > > > > >corret Sandy bridge is still a very viable system.
> > > > > >
> > > > > > I noticed this lack of love for older systems recently.
> > > > > >
> > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and
> RCs.
> > > > > >
> > > > > > Turns out, you can't install FreeBSD using a USB stick image
> because the
> > > > > > BIOS only support MBR. No idea why MBR support was dropped for
> the USB images.
> > > > > >
> > > > > > In the end I had to find a CD burner, and after a couple of
> tries managed to
> > > > > > install from CD.
> > > > > >
> > > > > > After that, my ansible playbooks started failing because
> /boot/loader.conf
> > > > > > is absent if you boot from zfs in combination with MBR.
> > > > > >
> > > > > > Pity. This older server hardware is great for trying out new
> releases, play
> > > > > > with zfs, etc.
> > > > >
> > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> > > > > built as hybrid images, supporting both MBR and GPT, as well as
> being
> > > > > written to a flash drive (like memstick.img) as well as a CD.
> > > >
> > > > To clarify a minor point here, are the amd64 disc1.iso images or
> > > > both the amd64 and i386 disk1.iso images being built as "hybrid"?
> > > >
> > >
> > > Only amd64. i386 does not have UEFI-/GPT-related boot issues.
> >
> > Here is a data point:
> >
> > Test system is Dell R710,
> > First attempt is with BIOS in Boot mode: Bios
> > Second attempt is with BIOS in Boot mode: UEFI
> >
> > Attemtped to boot amd64 version:
> > Screen goes white background, text appears (yes, way indented)
> > BTX version is 1.02
> > Consoles: internal video/keyboard
> > _
> >
> > That last _ is a blinking cursor, system is hung, does repsond to C-A-del
> >
> >
> > Second attempt:
> > Works properly
> >
> >
> > I am going after Ed Maste's posted build image in the other thread now...
> >
> >
> > >
> > > > As this is what I see on my system:
> > > > ***@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1
> : ID=0xee,
> > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695
> sectors
> > > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data
> > > > '11_2_BETA2_I386_CD' (bootable)
> > > > > MBR support was initially removed from the memstick installer, as
> it is
> > > > > not compatible with some UEFI implementations. (Or, at least that
> is my
> > > > > understanding, based on my limited intimate knowledge of UEFI.)
> > > > >
> > >
> > > Glen
> > >
> > -- End of PGP section, PGP failed!
> >
>
> Today, I tried to eliminate FreeBSD's native KMS drm2 by installing
> graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT
> (FreeBSD 12.0-CURRENT
> #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel).
>
> The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest
> firmware available
> from late 2013) equipted with a XEON IvyBridge:
>
> CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU)
> Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9
>
> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>
> Features2=0x7fbae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
> AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
> AMD Features2=0x1<LAHF>
> Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>
> XSAVE Features=0x1<XSAVEOPT>
> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> TSC: P-state invariant, performance statistics
> real memory = 17179869184 (16384 MB)
> avail memory = 16295137280 (15540 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: <ALASKA A M I>
> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>
>
> The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows
> seems to work).
> So I'm stuck with BIOS.
>
> Loading i915kms.ko/drm2.ko on the system put the console in a
> high-resolution mode
> instead of this crap 80x25 ancient console immediately.
>
> Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up
> in a trap
> 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does
> load without
> crashing the system - but the console is stuck in the clumsy 80x25 mode.
>
> So why should I vote for non-working drivers to replace perfectly working
> ones?
>
> oh
>
>
We're not replacing anything. We are moving the older drm1 and drm2 from
kernel to ports to make it easier for the majority of the users to load the
correct driver without conflicts.

We have updated drm-stable-kmod so that it now works on some older amd64
system also covered by drm2 but as always, ymmv. drm2 will later be
available as drm-legacy-kmod or something like that (name to be announced
later). Simply use/install the one that works best for you.



>
> - --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -----BEGIN PGP SIGNATURE-----
>
> iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWw8c/AAKCRDS528fyFhY
> lBl7Af0R7ymOzkWp7GcqymhUiOgfy3qvTSmHYgbTzYxsD54GEIfoAMvH1pHFp4yL
> b0NYx9HR+BU3d6GAf0Xq0sq78kMFAf9KUhDMLUHf06+ASJkS2uPyr+jZBZeBlTRc
> IsE0PaxErbYy8YLJhWXgrSYCM1KHIZisBNUOLGckcCIgTvu0MRsQ
> =yFzW
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
>
Konstantin Belousov
2018-05-31 10:16:43 UTC
Permalink
On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
> On Wed, May 30, 2018 at 10:57 PM O. Hartmann <***@walstatt.org> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Am Thu, 24 May 2018 09:10:10 -0700 (PDT)
> > "Rodney W. Grimes" <freebsd-***@pdx.rh.CN85.dnsmgr.net> schrieb:
> >
> > > -- Start of PGP signed section.
> > > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:
> > > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > > > > > > >Also as the Moore's law curve flattens expect the life of these
> > > > > > > >older, but not so old, machines to live quiet some time. I
> > > > > > > >believe we are talking sandy bridge and earlier? If that is
> > > > > > > >corret Sandy bridge is still a very viable system.
> > > > > > >
> > > > > > > I noticed this lack of love for older systems recently.
> > > > > > >
> > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and
> > RCs.
> > > > > > >
> > > > > > > Turns out, you can't install FreeBSD using a USB stick image
> > because the
> > > > > > > BIOS only support MBR. No idea why MBR support was dropped for
> > the USB images.
> > > > > > >
> > > > > > > In the end I had to find a CD burner, and after a couple of
> > tries managed to
> > > > > > > install from CD.
> > > > > > >
> > > > > > > After that, my ansible playbooks started failing because
> > /boot/loader.conf
> > > > > > > is absent if you boot from zfs in combination with MBR.
> > > > > > >
> > > > > > > Pity. This older server hardware is great for trying out new
> > releases, play
> > > > > > > with zfs, etc.
> > > > > >
> > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> > > > > > built as hybrid images, supporting both MBR and GPT, as well as
> > being
> > > > > > written to a flash drive (like memstick.img) as well as a CD.
> > > > >
> > > > > To clarify a minor point here, are the amd64 disc1.iso images or
> > > > > both the amd64 and i386 disk1.iso images being built as "hybrid"?
> > > > >
> > > >
> > > > Only amd64. i386 does not have UEFI-/GPT-related boot issues.
> > >
> > > Here is a data point:
> > >
> > > Test system is Dell R710,
> > > First attempt is with BIOS in Boot mode: Bios
> > > Second attempt is with BIOS in Boot mode: UEFI
> > >
> > > Attemtped to boot amd64 version:
> > > Screen goes white background, text appears (yes, way indented)
> > > BTX version is 1.02
> > > Consoles: internal video/keyboard
> > > _
> > >
> > > That last _ is a blinking cursor, system is hung, does repsond to C-A-del
> > >
> > >
> > > Second attempt:
> > > Works properly
> > >
> > >
> > > I am going after Ed Maste's posted build image in the other thread now...
> > >
> > >
> > > >
> > > > > As this is what I see on my system:
> > > > > ***@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> > > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1
> > : ID=0xee,
> > > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695
> > sectors
> > > > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data
> > > > > '11_2_BETA2_I386_CD' (bootable)
> > > > > > MBR support was initially removed from the memstick installer, as
> > it is
> > > > > > not compatible with some UEFI implementations. (Or, at least that
> > is my
> > > > > > understanding, based on my limited intimate knowledge of UEFI.)
> > > > > >
> > > >
> > > > Glen
> > > >
> > > -- End of PGP section, PGP failed!
> > >
> >
> > Today, I tried to eliminate FreeBSD's native KMS drm2 by installing
> > graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT
> > (FreeBSD 12.0-CURRENT
> > #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel).
> >
> > The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest
> > firmware available
> > from late 2013) equipted with a XEON IvyBridge:
> >
> > CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU)
> > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9
> >
> > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> >
> > Features2=0x7fbae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
> > AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
> > AMD Features2=0x1<LAHF>
> > Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>
> > XSAVE Features=0x1<XSAVEOPT>
> > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> > TSC: P-state invariant, performance statistics
> > real memory = 17179869184 (16384 MB)
> > avail memory = 16295137280 (15540 MB)
> > Event timer "LAPIC" quality 600
> > ACPI APIC Table: <ALASKA A M I>
> > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
> >
> >
> > The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows
> > seems to work).
> > So I'm stuck with BIOS.
> >
> > Loading i915kms.ko/drm2.ko on the system put the console in a
> > high-resolution mode
> > instead of this crap 80x25 ancient console immediately.
> >
> > Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up
> > in a trap
> > 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does
> > load without
> > crashing the system - but the console is stuck in the clumsy 80x25 mode.
> >
> > So why should I vote for non-working drivers to replace perfectly working
> > ones?
> >
> > oh
> >
> >
> We're not replacing anything. We are moving the older drm1 and drm2 from
> kernel to ports to make it easier for the majority of the users to load the
> correct driver without conflicts.
You do understand that you increase your maintainence load by this move.
dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
branches, so you will need to chase these updates.

>
> We have updated drm-stable-kmod so that it now works on some older amd64
> system also covered by drm2 but as always, ymmv. drm2 will later be
> available as drm-legacy-kmod or something like that (name to be announced
> later). Simply use/install the one that works best for you.
>
>
>
> >
> > - --
> > O. Hartmann
> >
> > Ich widerspreche der Nutzung oder ??bermittlung meiner Daten f??r
> > Werbezwecke oder f??r die Markt- oder Meinungsforschung (?? 28 Abs. 4 BDSG).
> > -----BEGIN PGP SIGNATURE-----
> >
> > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWw8c/AAKCRDS528fyFhY
> > lBl7Af0R7ymOzkWp7GcqymhUiOgfy3qvTSmHYgbTzYxsD54GEIfoAMvH1pHFp4yL
> > b0NYx9HR+BU3d6GAf0Xq0sq78kMFAf9KUhDMLUHf06+ASJkS2uPyr+jZBZeBlTRc
> > IsE0PaxErbYy8YLJhWXgrSYCM1KHIZisBNUOLGckcCIgTvu0MRsQ
> > =yFzW
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > freebsd-***@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
> >
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
Daniel Eischen
2018-05-31 14:23:33 UTC
Permalink
On Thu, 31 May 2018, Konstantin Belousov wrote:

> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>
>> We're not replacing anything. We are moving the older drm1 and drm2 from
>> kernel to ports to make it easier for the majority of the users to load the
>> correct driver without conflicts.
>
> You do understand that you increase your maintainence load by this move.
> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
> branches, so you will need to chase these updates.

I agree. One argument previously made was that it's easier
to maintain in ports. One data point from me - I rarely
update my ports, I update my OS much more frequently. In
fact, some times my ports get so out of date I just
(take off and) nuke /usr/local (from orbit, it's the only
way to be sure).

Also, are we trying to solve a problem by moving drm[2] to
ports that won't be a problem when base is pkg'ized? If
drm[2] is a package unto itself, then you don't have this
problem of ports conflicting with it, at least not so
much. You can either not install the base drm[2] package
or deinstall it to make way for a conflicting port. Once
drm[2] is pkg rm'd, it's not going to be reinstalled
again when you update the base OS.

And don't we have the same problem with sendmail and a
few other base services?

--
DE
Joe Maloney
2018-05-31 15:34:18 UTC
Permalink
I personally wish that more drivers, and firmware were separated from
base.

For example wireless firmware:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433

That was a ticket which I chimed in on about a firmware I needed to make my
wireless adapter work. I went through numerous efforts on IRC, and
elsewhere to try to bring attention that ticket in order to attempt to get
that firmware backported for several 10.x releases in a row without
success. The firmware worked perfectly fine in PC-BSD where it was cherry
picked for numerous 10.x releases.

Technically since I was using PC-BSD, and was a committer for that project
I had no real dire need to reach out to FreeBSD about the issue. I was
simply trying to help anyone else who might be encountering the same issue
trying to use stock FreeBSD because it was a simple backport. If my effort
had turned out to be more fruitful I would have spent more time pursuing
tickets, diffs, or whatever to get more things back-ported when I found
them. I am not sure where the breakdown was which did not allow that to
happen. Anyways I don't want to bikeshed, or anything but I just wanted to
point out how I think having more drivers, and firmware in ports could be
helpful to enhance compatibility for end users.

Having a separate port for legacy drm could definitely make things easier
to providing installation options for end users, and automating the post
install action chosen in TrueOS, GhostBSD, and future derivative projects
tailored for the desktop use case. For example for TrueOS we boot the
installer in failsafe mode with either VESA, or SCFB depending on whether
or not BIOS, or EFI is booted. Then we could simply make a checkbox for
legacy intel, or skylake + to install the correct package then the module
path for either driver can more or less remain the same. Eventually with
something like devmatch maybe that can even be fully automatic.

Joe Maloney

On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen <***@freebsd.org>
wrote:

> On Thu, 31 May 2018, Konstantin Belousov wrote:
>
> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>>
>> We're not replacing anything. We are moving the older drm1 and drm2 from
>>> kernel to ports to make it easier for the majority of the users to load
>>> the
>>> correct driver without conflicts.
>>>
>>
>> You do understand that you increase your maintainence load by this move.
>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
>> branches, so you will need to chase these updates.
>>
>
> I agree. One argument previously made was that it's easier
> to maintain in ports. One data point from me - I rarely
> update my ports, I update my OS much more frequently. In
> fact, some times my ports get so out of date I just
> (take off and) nuke /usr/local (from orbit, it's the only
> way to be sure).
>
> Also, are we trying to solve a problem by moving drm[2] to
> ports that won't be a problem when base is pkg'ized? If
> drm[2] is a package unto itself, then you don't have this
> problem of ports conflicting with it, at least not so
> much. You can either not install the base drm[2] package
> or deinstall it to make way for a conflicting port. Once
> drm[2] is pkg rm'd, it's not going to be reinstalled
> again when you update the base OS.
>
> And don't we have the same problem with sendmail and a
> few other base services?
>
> --
> DE
>
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
>
Ronald Klop
2018-05-31 16:02:26 UTC
Permalink
On Thu, 31 May 2018 17:34:18 +0200, Joe Maloney <***@ixsystems.com>
wrote:

> I personally wish that more drivers, and firmware were separated from
> base.
>
> For example wireless firmware:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
>
> That was a ticket which I chimed in on about a firmware I needed to make
> my
> wireless adapter work. I went through numerous efforts on IRC, and
> elsewhere to try to bring attention that ticket in order to attempt to
> get
> that firmware backported for several 10.x releases in a row without
> success. The firmware worked perfectly fine in PC-BSD where it was
> cherry
> picked for numerous 10.x releases.


I would support an idea that the FreeBSD project only delivers CURRENT
(and one periodic release with security fixes) and parties like PC-BSD
maintain stable branches and support for companies.

I read about this somewhere a while ago and the idea sticks. Backporting
to code 2+ years old is not the best use of human volunteer resources IMHO.

Regards,
Ronald.



>
> Technically since I was using PC-BSD, and was a committer for that
> project
> I had no real dire need to reach out to FreeBSD about the issue. I was
> simply trying to help anyone else who might be encountering the same
> issue
> trying to use stock FreeBSD because it was a simple backport. If my
> effort
> had turned out to be more fruitful I would have spent more time pursuing
> tickets, diffs, or whatever to get more things back-ported when I found
> them. I am not sure where the breakdown was which did not allow that to
> happen. Anyways I don't want to bikeshed, or anything but I just wanted
> to
> point out how I think having more drivers, and firmware in ports could be
> helpful to enhance compatibility for end users.
>
> Having a separate port for legacy drm could definitely make things easier
> to providing installation options for end users, and automating the post
> install action chosen in TrueOS, GhostBSD, and future derivative projects
> tailored for the desktop use case. For example for TrueOS we boot the
> installer in failsafe mode with either VESA, or SCFB depending on whether
> or not BIOS, or EFI is booted. Then we could simply make a checkbox for
> legacy intel, or skylake + to install the correct package then the module
> path for either driver can more or less remain the same. Eventually with
> something like devmatch maybe that can even be fully automatic.
>
> Joe Maloney
>
> On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen <***@freebsd.org>
> wrote:
>
>> On Thu, 31 May 2018, Konstantin Belousov wrote:
>>
>> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>>>
>>> We're not replacing anything. We are moving the older drm1 and drm2
>>> from
>>>> kernel to ports to make it easier for the majority of the users to
>>>> load
>>>> the
>>>> correct driver without conflicts.
>>>>
>>>
>>> You do understand that you increase your maintainence load by this
>>> move.
>>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in
>>> stable
>>> branches, so you will need to chase these updates.
>>>
>>
>> I agree. One argument previously made was that it's easier
>> to maintain in ports. One data point from me - I rarely
>> update my ports, I update my OS much more frequently. In
>> fact, some times my ports get so out of date I just
>> (take off and) nuke /usr/local (from orbit, it's the only
>> way to be sure).
>>
>> Also, are we trying to solve a problem by moving drm[2] to
>> ports that won't be a problem when base is pkg'ized? If
>> drm[2] is a package unto itself, then you don't have this
>> problem of ports conflicting with it, at least not so
>> much. You can either not install the base drm[2] package
>> or deinstall it to make way for a conflicting port. Once
>> drm[2] is pkg rm'd, it's not going to be reinstalled
>> again when you update the base OS.
>>
>> And don't we have the same problem with sendmail and a
>> few other base services?
>>
>> --
>> DE
>>
>> _______________________________________________
>> freebsd-***@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-***@freebsd.org"
>>
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-***@freebsd.org"
Andriy Gapon
2018-05-31 16:02:32 UTC
Permalink
On 31/05/2018 18:34, Joe Maloney wrote:
> I personally wish that more drivers, and firmware were separated from
> base.

I would agree with you IF FreeBSD had a defined and stable Device Driver
Interface. Or Thirdparty Module Interface. Or whatever the name.

--
Andriy Gapon
Johannes Lundberg
2018-05-31 17:51:50 UTC
Permalink
On Thu, May 31, 2018 at 4:34 PM Joe Maloney <***@ixsystems.com> wrote:

> I personally wish that more drivers, and firmware were separated from
> base.
>
>
I'm not a committer but as I understand there's not pre-commit integration
tests.. If one had that, plus that it would test build kmod ports against
the pre-commit state of head as well, then maybe this would work.


> For example wireless firmware:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
>
> That was a ticket which I chimed in on about a firmware I needed to make
> my wireless adapter work. I went through numerous efforts on IRC, and
> elsewhere to try to bring attention that ticket in order to attempt to get
> that firmware backported for several 10.x releases in a row without
> success. The firmware worked perfectly fine in PC-BSD where it was cherry
> picked for numerous 10.x releases.
>
> Technically since I was using PC-BSD, and was a committer for that project
> I had no real dire need to reach out to FreeBSD about the issue. I was
> simply trying to help anyone else who might be encountering the same issue
> trying to use stock FreeBSD because it was a simple backport. If my effort
> had turned out to be more fruitful I would have spent more time pursuing
> tickets, diffs, or whatever to get more things back-ported when I found
> them. I am not sure where the breakdown was which did not allow that to
> happen. Anyways I don't want to bikeshed, or anything but I just wanted to
> point out how I think having more drivers, and firmware in ports could be
> helpful to enhance compatibility for end users.
>
> Having a separate port for legacy drm could definitely make things easier
> to providing installation options for end users, and automating the post
> install action chosen in TrueOS, GhostBSD, and future derivative projects
> tailored for the desktop use case. For example for TrueOS we boot the
> installer in failsafe mode with either VESA, or SCFB depending on whether
> or not BIOS, or EFI is booted. Then we could simply make a checkbox for
> legacy intel, or skylake + to install the correct package then the module
> path for either driver can more or less remain the same. Eventually with
> something like devmatch maybe that can even be fully automatic.
>
> Joe Maloney
>
> On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen <***@freebsd.org>
> wrote:
>
>> On Thu, 31 May 2018, Konstantin Belousov wrote:
>>
>> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>>>
>>> We're not replacing anything. We are moving the older drm1 and drm2 from
>>>> kernel to ports to make it easier for the majority of the users to load
>>>> the
>>>> correct driver without conflicts.
>>>>
>>>
>>> You do understand that you increase your maintainence load by this move.
>>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
>>> branches, so you will need to chase these updates.
>>>
>>
>> I agree. One argument previously made was that it's easier
>> to maintain in ports. One data point from me - I rarely
>> update my ports, I update my OS much more frequently. In
>> fact, some times my ports get so out of date I just
>> (take off and) nuke /usr/local (from orbit, it's the only
>> way to be sure).
>>
>> Also, are we trying to solve a problem by moving drm[2] to
>> ports that won't be a problem when base is pkg'ized? If
>> drm[2] is a package unto itself, then you don't have this
>> problem of ports conflicting with it, at least not so
>> much. You can either not install the base drm[2] package
>> or deinstall it to make way for a conflicting port. Once
>> drm[2] is pkg rm'd, it's not going to be reinstalled
>> again when you update the base OS.
>>
>> And don't we have the same problem with sendmail and a
>> few other base services?
>>
>> --
>> DE
>>
>> _______________________________________________
>> freebsd-***@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org
>> "
>>
>
>
Oliver Pinter
2018-05-31 22:34:57 UTC
Permalink
On Thursday, May 31, 2018, Johannes Lundberg <***@gmail.com> wrote:

> On Thu, May 31, 2018 at 4:34 PM Joe Maloney <***@ixsystems.com>
> wrote:
>
> > I personally wish that more drivers, and firmware were separated from
> > base.
> >
> >
> I'm not a committer


>
>
If you are not a committer, how and why want to remove drm2 from the base
system?

From other side, how you want to maintain VM and other KPI changes in
unmaintained and abandoned port? ;) Or how you can guarantee to everyone
who breaks KPI to follow these breaks in an external abandoned port?


>
> but as I understand there's not pre-commit integration
> tests.. If one had that, plus that it would test build kmod ports against
> the pre-commit state of head as well, then maybe this would work.
>
>
> > For example wireless firmware:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
> >
> > That was a ticket which I chimed in on about a firmware I needed to make
> > my wireless adapter work. I went through numerous efforts on IRC, and
> > elsewhere to try to bring attention that ticket in order to attempt to
> get
> > that firmware backported for several 10.x releases in a row without
> > success. The firmware worked perfectly fine in PC-BSD where it was
> cherry
> > picked for numerous 10.x releases.
> >
> > Technically since I was using PC-BSD, and was a committer for that
> project
> > I had no real dire need to reach out to FreeBSD about the issue. I was
> > simply trying to help anyone else who might be encountering the same
> issue
> > trying to use stock FreeBSD because it was a simple backport. If my
> effort
> > had turned out to be more fruitful I would have spent more time pursuing
> > tickets, diffs, or whatever to get more things back-ported when I found
> > them. I am not sure where the breakdown was which did not allow that to
> > happen. Anyways I don't want to bikeshed, or anything but I just wanted
> to
> > point out how I think having more drivers, and firmware in ports could be
> > helpful to enhance compatibility for end users.
> >
> > Having a separate port for legacy drm could definitely make things easier
> > to providing installation options for end users, and automating the post
> > install action chosen in TrueOS, GhostBSD, and future derivative projects
> > tailored for the desktop use case. For example for TrueOS we boot the
> > installer in failsafe mode with either VESA, or SCFB depending on whether
> > or not BIOS, or EFI is booted. Then we could simply make a checkbox for
> > legacy intel, or skylake + to install the correct package then the module
> > path for either driver can more or less remain the same. Eventually with
> > something like devmatch maybe that can even be fully automatic.
> >
> > Joe Maloney
> >
> > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen <***@freebsd.org>
> > wrote:
> >
> >> On Thu, 31 May 2018, Konstantin Belousov wrote:
> >>
> >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
> >>>
> >>> We're not replacing anything. We are moving the older drm1 and drm2
> from
> >>>> kernel to ports to make it easier for the majority of the users to
> load
> >>>> the
> >>>> correct driver without conflicts.
> >>>>
> >>>
> >>> You do understand that you increase your maintainence load by this
> move.
> >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in
> stable
> >>> branches, so you will need to chase these updates.
> >>>
> >>
> >> I agree. One argument previously made was that it's easier
> >> to maintain in ports. One data point from me - I rarely
> >> update my ports, I update my OS much more frequently. In
> >> fact, some times my ports get so out of date I just
> >> (take off and) nuke /usr/local (from orbit, it's the only
> >> way to be sure).
> >>
> >> Also, are we trying to solve a problem by moving drm[2] to
> >> ports that won't be a problem when base is pkg'ized? If
> >> drm[2] is a package unto itself, then you don't have this
> >> problem of ports conflicting with it, at least not so
> >> much. You can either not install the base drm[2] package
> >> or deinstall it to make way for a conflicting port. Once
> >> drm[2] is pkg rm'd, it's not going to be reinstalled
> >> again when you update the base OS.
> >>
> >> And don't we have the same problem with sendmail and a
> >> few other base services?
> >>
> >> --
> >> DE
> >>
> >> _______________________________________________
> >> freebsd-***@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "
> freebsd-current-***@freebsd.org
> >> "
> >>
> >
> >
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
>
Pete Wright
2018-05-31 23:00:36 UTC
Permalink
On 05/31/2018 15:34, Oliver Pinter wrote:
> On Thursday, May 31, 2018, Johannes Lundberg <***@gmail.com> wrote:
>
>> On Thu, May 31, 2018 at 4:34 PM Joe Maloney <***@ixsystems.com>
>> wrote:
>>
>>> I personally wish that more drivers, and firmware were separated from
>>> base.
>>>
>>>
>> I'm not a committer
>
>>
> If you are not a committer, how and why want to remove drm2 from the base
> system?
Johannes did not start this threat.  A committer, Niclas Zeising, did. 
Johannes has stepped up and done a ton of work (along with many others,
some committers and some not) to get modern intel and amd GPU's working
under freebsd.  this was something that was a gaping hole in freebsd
when this work started a bit over a year ago, and i'm not sure why more
committers weren't embarrassed by this gap nor motivated to chip in.

regardless - not sure why you'd take his comment out of context :/ the
full quote was:
"I'm not a committer but as I understand there's not pre-commit
integration tests.. If one had that, plus that it would test build kmod
ports against the pre-commit state of head as well, then maybe this
would work."

not really sure what's controversial about that statement which would
prompt your reply - but i guess people dedicating their spare time to
help create useful things for others shouldn't go unpunished.

well i guess i broke my promise to ignore this bikeshed :(

-p

--
Pete Wright
***@nomadlogic.org
@nomadlogicLA
Oliver Pinter
2018-05-31 23:38:29 UTC
Permalink
On Friday, June 1, 2018, Pete Wright <***@nomadlogic.org> wrote:

>
>
> On 05/31/2018 15:34, Oliver Pinter wrote:
>
>> On Thursday, May 31, 2018, Johannes Lundberg <***@gmail.com> wrote:
>>
>> On Thu, May 31, 2018 at 4:34 PM Joe Maloney <***@ixsystems.com>
>>> wrote:
>>>
>>> I personally wish that more drivers, and firmware were separated from
>>>> base.
>>>>
>>>>
>>>> I'm not a committer
>>>
>>
>>
>>> If you are not a committer, how and why want to remove drm2 from the
>> base
>> system?
>>
> Johannes did not start this threat. A committer, Niclas Zeising, did.
> Johannes has stepped up and done a ton of work (along with many others,
> some committers and some not) to get modern intel and amd GPU's working
> under freebsd.


>
True. Yes I agree that their work is hard and it's a very big step forward
for supporting modern hardwares. And it's required modern desktops, but
please don't break the existing ones. This is my only request, probably it
was expressed in a harsh way, sorry.



>
>
> this was something that was a gaping hole in freebsd when this work
> started a bit over a year ago, and i'm not sure why more committers weren't
> embarrassed by this gap nor motivated to chip in.
>
> regardless - not sure why you'd take his comment out of context :/ the
> full quote was:
> "I'm not a committer but as I understand there's not pre-commit
> integration tests.. If one had that, plus that it would test build kmod
> ports against the pre-commit state of head as well, then maybe this would
> work."
>
> not really sure what's controversial about that statement which would
> prompt your reply - but i guess people dedicating their spare time to help
> create useful things for others shouldn't go unpunished.
>
> well i guess i broke my promise to ignore this bikeshed :(
>
> -p
>
> --
> Pete Wright
> ***@nomadlogic.org
> @nomadlogicLA
>
>
blubee blubeeme
2018-06-01 04:38:42 UTC
Permalink
On Fri, Jun 1, 2018, 07:42 Oliver Pinter <***@hardenedbsd.org>
wrote:

> On Friday, June 1, 2018, Pete Wright <***@nomadlogic.org> wrote:
>
> >
> >
> > On 05/31/2018 15:34, Oliver Pinter wrote:
> >
> >> On Thursday, May 31, 2018, Johannes Lundberg <***@gmail.com>
> wrote:
> >>
> >> On Thu, May 31, 2018 at 4:34 PM Joe Maloney <***@ixsystems.com>
> >>> wrote:
> >>>
> >>> I personally wish that more drivers, and firmware were separated from
> >>>> base.
> >>>>
> >>>>
> >>>> I'm not a committer
> >>>
> >>
> >>
> >>> If you are not a committer, how and why want to remove drm2 from the
> >> base
> >> system?
> >>
> > Johannes did not start this threat. A committer, Niclas Zeising, did.
> > Johannes has stepped up and done a ton of work (along with many others,
> > some committers and some not) to get modern intel and amd GPU's working
> > under freebsd.
>
>
> >
> True. Yes I agree that their work is hard and it's a very big step forward
> for supporting modern hardwares. And it's required modern desktops, but
> please don't break the existing ones.

Agreed

This is my only request, probably it
> was expressed in a harsh way, sorry.
>
>
>
> >
> >
> > this was something that was a gaping hole in freebsd when this work
> > started a bit over a year ago, and i'm not sure why more committers
> weren't
> > embarrassed by this gap nor motivated to chip in.
> >
> > regardless - not sure why you'd take his comment out of context :/ the
> > full quote was:
> > "I'm not a committer but as I understand there's not pre-commit
> > integration tests.. If one had that, plus that it would test build kmod
> > ports against the pre-commit state of head as well, then maybe this would
> > work."
> >
> > not really sure what's controversial about that statement which would
> > prompt your reply - but i guess people dedicating their spare time to
> help
> > create useful things for others shouldn't go unpunished.
> >
> > well i guess i broke my promise to ignore this bikeshed :(
> >
> > -p
> >
> > --
> > Pete Wright
> > ***@nomadlogic.org
> > @nomadlogicLA
> >
> >
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
>
Johannes Lundberg
2018-06-01 06:08:29 UTC
Permalink
On Thu, May 31, 2018 at 11:34 PM Oliver Pinter <
***@hardenedbsd.org> wrote:

>
>
> On Thursday, May 31, 2018, Johannes Lundberg <***@gmail.com> wrote:
>
>> On Thu, May 31, 2018 at 4:34 PM Joe Maloney <***@ixsystems.com>
>> wrote:
>>
>> > I personally wish that more drivers, and firmware were separated from
>> > base.
>> >
>> >
>> I'm not a committer
>
>
>>
>>
> If you are not a committer, how and why want to remove drm2 from the base
> system?
>


Nice way to shoot down people (who are working together with active
committers) trying to make FreeBSD and it's derivatives a better OS for its
users. As a way to help prevent breakage I suggested an upgrade to the
outdated build infrastructure. Something that should be done anyway. But
what do I know, I don't have a commit bit...



>
> From other side, how you want to maintain VM and other KPI changes in
> unmaintained and abandoned port? ;) Or how you can guarantee to everyone
> who breaks KPI to follow these breaks in an external abandoned port?
>
>
>>
>> but as I understand there's not pre-commit integration
>> tests.. If one had that, plus that it would test build kmod ports against
>> the pre-commit state of head as well, then maybe this would work.
>>
>>
>> > For example wireless firmware:
>> >
>> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
>> >
>> > That was a ticket which I chimed in on about a firmware I needed to make
>> > my wireless adapter work. I went through numerous efforts on IRC, and
>> > elsewhere to try to bring attention that ticket in order to attempt to
>> get
>> > that firmware backported for several 10.x releases in a row without
>> > success. The firmware worked perfectly fine in PC-BSD where it was
>> cherry
>> > picked for numerous 10.x releases.
>> >
>> > Technically since I was using PC-BSD, and was a committer for that
>> project
>> > I had no real dire need to reach out to FreeBSD about the issue. I was
>> > simply trying to help anyone else who might be encountering the same
>> issue
>> > trying to use stock FreeBSD because it was a simple backport. If my
>> effort
>> > had turned out to be more fruitful I would have spent more time pursuing
>> > tickets, diffs, or whatever to get more things back-ported when I found
>> > them. I am not sure where the breakdown was which did not allow that to
>> > happen. Anyways I don't want to bikeshed, or anything but I just
>> wanted to
>> > point out how I think having more drivers, and firmware in ports could
>> be
>> > helpful to enhance compatibility for end users.
>> >
>> > Having a separate port for legacy drm could definitely make things
>> easier
>> > to providing installation options for end users, and automating the post
>> > install action chosen in TrueOS, GhostBSD, and future derivative
>> projects
>> > tailored for the desktop use case. For example for TrueOS we boot the
>> > installer in failsafe mode with either VESA, or SCFB depending on
>> whether
>> > or not BIOS, or EFI is booted. Then we could simply make a checkbox for
>> > legacy intel, or skylake + to install the correct package then the
>> module
>> > path for either driver can more or less remain the same. Eventually
>> with
>> > something like devmatch maybe that can even be fully automatic.
>> >
>> > Joe Maloney
>> >
>> > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen <***@freebsd.org>
>> > wrote:
>> >
>> >> On Thu, 31 May 2018, Konstantin Belousov wrote:
>> >>
>> >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>> >>>
>> >>> We're not replacing anything. We are moving the older drm1 and drm2
>> from
>> >>>> kernel to ports to make it easier for the majority of the users to
>> load
>> >>>> the
>> >>>> correct driver without conflicts.
>> >>>>
>> >>>
>> >>> You do understand that you increase your maintainence load by this
>> move.
>> >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in
>> stable
>> >>> branches, so you will need to chase these updates.
>> >>>
>> >>
>> >> I agree. One argument previously made was that it's easier
>> >> to maintain in ports. One data point from me - I rarely
>> >> update my ports, I update my OS much more frequently. In
>> >> fact, some times my ports get so out of date I just
>> >> (take off and) nuke /usr/local (from orbit, it's the only
>> >> way to be sure).
>> >>
>> >> Also, are we trying to solve a problem by moving drm[2] to
>> >> ports that won't be a problem when base is pkg'ized? If
>> >> drm[2] is a package unto itself, then you don't have this
>> >> problem of ports conflicting with it, at least not so
>> >> much. You can either not install the base drm[2] package
>> >> or deinstall it to make way for a conflicting port. Once
>> >> drm[2] is pkg rm'd, it's not going to be reinstalled
>> >> again when you update the base OS.
>> >>
>> >> And don't we have the same problem with sendmail and a
>> >> few other base services?
>> >>
>> >> --
>> >> DE
>> >>
>> >> _______________________________________________
>> >> freebsd-***@freebsd.org mailing list
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >> To unsubscribe, send any mail to "
>> freebsd-current-***@freebsd.org
>> >> "
>> >>
>> >
>> >
>> _______________________________________________
>> freebsd-***@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org
>> "
>>
>
Mark Linimon
2018-05-31 20:49:46 UTC
Permalink
Straying off-topic from the Subject line ...

On Thu, May 31, 2018 at 11:34:18AM -0400, Joe Maloney wrote:
> Technically since I was using PC-BSD, and was a committer for that
> project I had no real dire need to reach out to FreeBSD about the
> [wireless driver issue]. I was simply trying to help anyone else
> who might be encountering the same issue trying to use stock FreeBSD
> because it was a simple backport. If my effort had turned out to be
> more fruitful I would have spent more time pursuing tickets, diffs,
> or whatever to get more things back-ported when I found them.

FreeBSD doesn't do well handling problem reports. We've known it for
years but no one has come up with a magic solution yet.

We have volunteers willing to triage, but not enough committers willing
to suspend working on their own priorities to work through the backlog.
(It's understandable, really.)

And the backlog is astounding. (*)

I hesitate to even look, but ...

kern 3270
ports 2010
bin 1607

The flow has decreased from where it was a few years ago -- this stat
says that 727 total new ones have come in this month.

We do slightly better turning over ports PRs -- due to the fact that
we attach a maintainer field to each port. This doesn't completely
solve the problem, but it goes some distance.

Finally, the number of PRs with patches stands around 1021. That is
particularly disappointing.

Well, it's too bad we weren't able to corral you into keeping working
on such things. fwiw.

mcl

*: there are other categories but these constitute the majority (9485
in total).
Matthew D. Fuller
2018-06-01 03:25:10 UTC
Permalink
On Thu, May 31, 2018 at 03:49:46PM -0500 I heard the voice of
Mark Linimon, and lo! it spake thus:
>
> We do slightly better turning over ports PRs -- due to the fact that
> we attach a maintainer field to each port. This doesn't completely
> solve the problem, but it goes some distance.

From my perspective as a maintainer of some and occasional contributor
to others, I think "slightly" undersells it a bit; hardly without
exception, but it generally works OK.

I wrote up a couple more paragraphs about why I think it happens and
what we'd need to do to import more of that sense over into src. But
it was way longer than it needs to be. We get a lot more man-hours in
ports/ acting as conduits for the "outside patches -> svn" pipeline
because the incentives are rigged. A bad outside contribution brought
into ports more often yields "hey, you should have noticed" to the
committer and more opprobrium back to the submitter. A bad outside
contribution brought into src falls all over the commiter.

Not entirely unreasonable, since a lot of even small-ish breakages in
src are much bigger deals than even large-ish breakages in ports. But
it still makes it expensive to contemplate being a conduit...


--
Matthew Fuller (MF4839) | ***@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
K. Macy
2018-06-01 04:04:25 UTC
Permalink
>
> I wrote up a couple more paragraphs about why I think it happens and
> what we'd need to do to import more of that sense over into src. But
> it was way longer than it needs to be. We get a lot more man-hours in
> ports/ acting as conduits for the "outside patches -> svn" pipeline
> because the incentives are rigged. A bad outside contribution brought
> into ports more often yields "hey, you should have noticed" to the
> committer and more opprobrium back to the submitter. A bad outside
> contribution brought into src falls all over the commiter.
>
> Not entirely unreasonable, since a lot of even small-ish breakages in
> src are much bigger deals than even large-ish breakages in ports. But
> it still makes it expensive to contemplate being a conduit...

Whereas the incentives in ports are structured such as to encourage
being a conduit and arguably it's a big part of being a responsible
porter, in src there is an active disincentive. A committer invites
substantial criticism by breaking src by importing a change but
invites no criticism for ignoring review requests or patches. There
are a few people who go through the pain of wading through patches and
committing them but as a general rule one has to have some level of
rapport with a proxy to get changes in without a bit. Whereas with
TrueOS the Git PR system lets one submit a change, the CI system
builds it to verify, and then it's thumbs up or thumbs down and it
goes in, undergoes further review / refinement, or is rejected
outright. There's something to be said for automation.

Submitting enhancements is even harder. There's always someone who
will be upset by a change in existing behavior, no matter how logical
a change may seem to the rest of us. This obvious change is almost 10
years old and seems completely common sense:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139389

I've been keeping it in my bookmarks hoping that Eitan will commit it,
but may at some point overcome my reservations and just go ahead and
commit.

My problem with the bug system is classification. If a bug report
refers to something I touched recently, it's easy to assign it to me.
However, when I've tried wading through the bug system to find things
that I might be able to fix, I have not found it easy at all. This is
where culling older bug reports comes in. With a poor signal to noise
ratio from too many PRs, what really happens is _fewer_ things get
fixed, not more.

Cheers.
-M
Mark Linimon
2018-06-01 10:31:50 UTC
Permalink
On Thu, May 31, 2018 at 09:04:25PM -0700, K. Macy wrote:
> This is where culling older bug reports comes in.

Well, even with doing that, the sheer number really doesn't help the
S/N that much. It may make someone a bit neurotic like me feel a bit
better, but that's all.

> However, when I've tried wading through the bug system to find things
> that I might be able to fix, I have not found it easy at all.

To me, reasoning about 'search' is the riqht direction to go. (Apologies
to folks for the long URLs, but I would rather not hide the search terms
here.)

We've been inconsistent about applying the 'patch-ready' tag to indicate
something is ready to go, but here's the current list for the Base System:

https://bugs.freebsd.org/bugzilla/buglist.cgi?keywords=patch-ready&keywords_type=allwords&list_id=232422&product=Base%20System&query_format=advanced&resolution=---

8 bugs. Not that bad.

The 'patch' tag by itself produces a much less satisfying result:

https://bugs.freebsd.org/bugzilla/buglist.cgi?keywords=patch&keywords_type=allwords&limit=0&list_id=232422&order=bug_id%20DESC&product=Base%20System&query_format=advanced&resolution=---

600 bugs. Moderately overwhelming.

Narrowing it down to just the 'kern' component only helps a little:

https://bugs.freebsd.org/bugzilla/buglist.cgi?component=kern&keywords=patch&keywords_type=allwords&list_id=232433&product=Base%20System&query_format=advanced&resolution=---

300 bugs.

Looking for tag 'regression' within that is more satisfying:

https://bugs.freebsd.org/bugzilla/buglist.cgi?component=kern&keywords=regression&keywords_type=allwords&list_id=232433&product=Base%20System&query_format=advanced&resolution=---

82 bugs.

tl:dr; expecting any sane person to 'browse' thousands of entries of
any kind from _any_ kind of list, is itself madness. OTOH myself, and
koobs and others, are willing to work on the search metadata to at
least make 'search' reasonable.

[obv. disclaimer: I am only citing statistics for Bugzilla here, not
Phabricator; I simply know it better.]

mcl
Mark Linimon
2018-06-01 10:14:54 UTC
Permalink
On Thu, May 31, 2018 at 10:25:10PM -0500, Matthew D. Fuller wrote:
> because the incentives are rigged. A bad outside contribution brought
> into ports more often yields "hey, you should have noticed" to the
> committer and more opprobrium back to the submitter.

I believe you're missing two important points:

- there is feedback to the ports committers that goes on behind the
scenes (e.g. not on public mailing lists);

- everyone who uses FreeBSD needs src to work. Not everyone who uses
FreeBSD needs even a large fraction of ports to work.

Let me reframe this debate. To me, the correct comparison is:

"compare commits to src"

vs.

"compare commits to key ports pieces such as Mk/, perl, apache24, &c"

Commits to the latter are thoroughly tested* in external staging areas
and/or "exp-runs" done by portmgr, _before_ they hit the tree.

For src committers that aren't aware: since adopting the exp-runs, there
have been far, far, fewer large-scale regressions of the ports tree.
Check the monthly portmgr reports to see how much work is going into
this -- and that doesn't count projects like gnome and kde that do their
own external precommit work.

Also, IMHO talking about whether this process is, or should be, automated
misses the point. The distinguishing feature is the buy-in by the people
who are making changes to the tree to have done sufficient testing _first_.
Without that buy-in, the tools are irrelvant.

Next, let me assure you that anyone who breaks those key pieces of ports
hears about it _immediately_.

tl:dr; at least for the key pieces, FreeBSD ports has moved away from the
"throw it at the wall to see if it will stick" paradigm. That's the part
of the codebase that ought to be the comparison point.

mcl

* almost always. They are supposed to be, in any case. Humans are involved.
Adrian Chadd
2018-06-04 19:03:40 UTC
Permalink
Hi,

As a driver/framework developer - no, don't do that.

It's worked mostly great for the video side of things because your
touch points are "the VM system" and "linuxkpi". And they're all in
one big driver pull from Linux.

For wifi as an example - it has a bunch of userland components, a
kernel framework component (net80211); it gets API churn from people
who keep making networking API changes without making them opaque (i
just got bitten by the STAILQ -> CK_STAILQ changes for multicast
iteration, instead of us growing a multicast iterator function thing.)

Having it be multiple drivers/firmware means that anyone doing wifi
development here would have to install /all/ of the relevant packages
and the net80211 stuff and userland just to get any work done and hope
it stays in sync.

It'd be nice if that was our stretch goal, but we ain't there yet.

As for your intel NIC - I'm sorry that you've had issues getting that
into the tree but you can just jump in #freebsd-wifi and whine at us
until we commit it. That's what we're there for.




-adrian
Matthew Macy
2018-06-04 19:07:25 UTC
Permalink
On Mon, Jun 4, 2018 at 12:03 PM, Adrian Chadd <***@gmail.com> wrote:
> Hi,
>
> As a driver/framework developer - no, don't do that.
>
> It's worked mostly great for the video side of things because your
> touch points are "the VM system" and "linuxkpi". And they're all in
> one big driver pull from Linux.
>
> For wifi as an example - it has a bunch of userland components, a
> kernel framework component (net80211); it gets API churn from people
> who keep making networking API changes without making them opaque (i
> just got bitten by the STAILQ -> CK_STAILQ changes for multicast
> iteration, instead of us growing a multicast iterator function thing.)

We've had one for several years. You're just not using it.

> Having it be multiple drivers/firmware means that anyone doing wifi
> development here would have to install /all/ of the relevant packages
> and the net80211 stuff and userland just to get any work done and hope
> it stays in sync.

This is the same old saw of people who can't be bothered to use ports.
It is more of a headache with ABI drift but it's certainly not a
fundamental impediment.

-M
Adrian Chadd
2018-06-05 05:27:35 UTC
Permalink
Hi,

If there's an API that isn't being used then great, I'll go find it
and fix up pieces in my spare time to use it. But the last drive by
cut/paste didn't do that; it just changed the code in place. :-)



-adrian
Matthew Macy
2018-06-05 05:36:47 UTC
Permalink
Implementing a callback in 140 different files for the sake of a handful of
out of tree drivers and people not reading updating is pretty prohibitive.
11 may be more your cup of tea.

On Mon, Jun 4, 2018 at 22:27 Adrian Chadd <***@gmail.com> wrote:

> Hi,
>
> If there's an API that isn't being used then great, I'll go find it
> and fix up pieces in my spare time to use it. But the last drive by
> cut/paste didn't do that; it just changed the code in place. :-)
>
>
>
> -adrian
>
Adrian Chadd
2018-06-13 15:26:26 UTC
Permalink
On Mon, 4 Jun 2018 at 22:36, Matthew Macy <***@gmail.com> wrote:
>
> Implementing a callback in 140 different files for the sake of a handful of out of tree drivers and people not reading updating is pretty prohibitive. 11 may be more your cup of tea.

This was the in tree wifi drivers.. :-)

Dude, we're on the same side. I'll take a look at the multicast
iterator stuff once I figure out why the athp receive performance in
my driver is terrible-y.



-adrian
Niclas Zeising
2018-05-29 19:28:49 UTC
Permalink
On 05/18/18 19:58, Niclas Zeising wrote:
> [ Cross posted to freebsd-current@ and freebsd-***@.  Please respect
> reply-to and send all replies to freebsd-***@.  Thanks! ]
>
>
> Hi!
> I propose that we remove the old drm2 driver (sys/dev/drm2) from
> FreeBSD.  I suggest the driver is marked as deprecated in 11.x and
> removed from 12.0, as was done for other drivers recently.  Some
> background and rationale:
>
> The drm2 driver was the original port of a KMS driver to FreeBSD.  It
> was done by Konstantin Belousov to support Intel graphics cards, and
> later extended by Jean-Sébastien Pédron as well as Konstantin to match
> what's in Linux 3.8.  This included unstable support from Haswell, but
> nothing newer than that.
>
> For quite some time now we have had the graphics/drm-stable-kmod and
> graphics/drm-next-kmods which provides support for modern AMD and Intel
> graphics cards.  These ports, together with the linuxkpi, or lkpi, has
> made it significantly easier to port and update our graphics drivers.
> Further, these new drivers cover the same drivers as the old drm2 driver.
>
> 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?
>


Wow, this blew up quite a lot bigger than I anticipated. I'll try to
summarize the discussion a bit below and then suggest a way forward.

The primary reasons we want to do this is because there are conflicts
between the new drm drivers in ports, and the drm drivers in base, since
they control the same hardware. It is hard to make conflicting drivers
to auto load in a consistent way. In order to improve the desktop
experience I'd like to see that graphics drivers are loaded on system
boot. There is also a push from upstream to have the xf86-video*
drivers stop loading driver kernel modules. It is also easier to keep a
port updated than keeping the base system updated, and updates can
propagate to multiple FreeBSD versions at once. This will also ensure
that all ports use the same firmware blobs.

So, to the summary. A lot of people are using i386, and as such still
need the old drm drivers. There were also some reports about issues
with the drm-next/stable drivers, which needs investigating. Power is
another architecture that also is not supported by drm-next/stable,
although we hope to extend support to powerpc in the future. There was a
lot of discussion regarding making it into a port, or only excluding the
driver on amd64, and similar suggestions.

To move forward, we'll do the following: Note that this is for current
only.
We take the drm and drm2 drivers and make a port for it, maintained by
the graphics team (x11@). After a transition period, then the drivers
are removed from base. At the same time, pkg-messages are added to
relevant places to point people to the various available drm drivers.

Regards
--
Niclas Zeising
FreeBSD graphics/x11 team
Mateusz Piotrowski
2018-05-30 00:52:08 UTC
Permalink
On Tue, 29 May 2018 17:39:57 -0700 (PDT)
"Rodney W. Grimes" <freebsd-***@pdx.rh.CN85.dnsmgr.net> wrote:

>> Let's also remember about our handbooks and those two wiki page:
>> * https://wiki.freebsd.org/Graphics
>> * https://wiki.freebsd.org/Graphics/FAQ
>This one has a bit rot on this claim:
> "The i915kms kernel-side driver is already built into the
> generic FreeBSD kernel. No need to install anything. '
>
>That is slightly miss leading, it is not "built into the generic",
>it is avaliable as a module, at least on 11 and 12, not sure on
>10 as I dont have 10 running any place anymore.

Good catch! Thanks.
Rodney W. Grimes
2018-05-31 14:21:06 UTC
Permalink
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA512
> > >
> > > Am Thu, 24 May 2018 09:10:10 -0700 (PDT)
> > > "Rodney W. Grimes" <freebsd-***@pdx.rh.CN85.dnsmgr.net> schrieb:
> > >
> > > > -- Start of PGP signed section.
> > > > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:
> > > > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:
> > > > > > > > >Also as the Moore's law curve flattens expect the life of these
> > > > > > > > >older, but not so old, machines to live quiet some time. I
> > > > > > > > >believe we are talking sandy bridge and earlier? If that is
> > > > > > > > >corret Sandy bridge is still a very viable system.
> > > > > > > >
> > > > > > > > I noticed this lack of love for older systems recently.
> > > > > > > >
> > > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and
> > > RCs.
> > > > > > > >
> > > > > > > > Turns out, you can't install FreeBSD using a USB stick image
> > > because the
> > > > > > > > BIOS only support MBR. No idea why MBR support was dropped for
> > > the USB images.
> > > > > > > >
> > > > > > > > In the end I had to find a CD burner, and after a couple of
> > > tries managed to
> > > > > > > > install from CD.
> > > > > > > >
> > > > > > > > After that, my ansible playbooks started failing because
> > > /boot/loader.conf
> > > > > > > > is absent if you boot from zfs in combination with MBR.
> > > > > > > >
> > > > > > > > Pity. This older server hardware is great for trying out new
> > > releases, play
> > > > > > > > with zfs, etc.
> > > > > > >
> > > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> > > > > > > built as hybrid images, supporting both MBR and GPT, as well as
> > > being
> > > > > > > written to a flash drive (like memstick.img) as well as a CD.
> > > > > >
> > > > > > To clarify a minor point here, are the amd64 disc1.iso images or
> > > > > > both the amd64 and i386 disk1.iso images being built as "hybrid"?
> > > > > >
> > > > >
> > > > > Only amd64. i386 does not have UEFI-/GPT-related boot issues.
> > > >
> > > > Here is a data point:
> > > >
> > > > Test system is Dell R710,
> > > > First attempt is with BIOS in Boot mode: Bios
> > > > Second attempt is with BIOS in Boot mode: UEFI
> > > >
> > > > Attemtped to boot amd64 version:
> > > > Screen goes white background, text appears (yes, way indented)
> > > > BTX version is 1.02
> > > > Consoles: internal video/keyboard
> > > > _
> > > >
> > > > That last _ is a blinking cursor, system is hung, does repsond to C-A-del
> > > >
> > > >
> > > > Second attempt:
> > > > Works properly
> > > >
> > > >
> > > > I am going after Ed Maste's posted build image in the other thread now...
> > > >
> > > >
> > > > >
> > > > > > As this is what I see on my system:
> > > > > > ***@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> > > > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1
> > > : ID=0xee,
> > > > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695
> > > sectors
> > > > > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data
> > > > > > '11_2_BETA2_I386_CD' (bootable)
> > > > > > > MBR support was initially removed from the memstick installer, as
> > > it is
> > > > > > > not compatible with some UEFI implementations. (Or, at least that
> > > is my
> > > > > > > understanding, based on my limited intimate knowledge of UEFI.)
> > > > > > >
> > > > >
> > > > > Glen
> > > > >
> > > > -- End of PGP section, PGP failed!
> > > >
> > >
> > > Today, I tried to eliminate FreeBSD's native KMS drm2 by installing
> > > graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT
> > > (FreeBSD 12.0-CURRENT
> > > #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel).
> > >
> > > The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest
> > > firmware available
> > > from late 2013) equipted with a XEON IvyBridge:
> > >
> > > CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU)
> > > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9
> > >
> > > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > >
> > > Features2=0x7fbae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
> > > AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
> > > AMD Features2=0x1<LAHF>
> > > Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>
> > > XSAVE Features=0x1<XSAVEOPT>
> > > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> > > TSC: P-state invariant, performance statistics
> > > real memory = 17179869184 (16384 MB)
> > > avail memory = 16295137280 (15540 MB)
> > > Event timer "LAPIC" quality 600
> > > ACPI APIC Table: <ALASKA A M I>
> > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
> > >
> > >
> > > The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows
> > > seems to work).
> > > So I'm stuck with BIOS.
> > >
> > > Loading i915kms.ko/drm2.ko on the system put the console in a
> > > high-resolution mode
> > > instead of this crap 80x25 ancient console immediately.
> > >
> > > Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up
> > > in a trap
> > > 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does
> > > load without
> > > crashing the system - but the console is stuck in the clumsy 80x25 mode.
> > >
> > > So why should I vote for non-working drivers to replace perfectly working
> > > ones?
> > >
> > > oh
> > >
> > >
> > We're not replacing anything. We are moving the older drm1 and drm2 from
> > kernel to ports to make it easier for the majority of the users to load the
> > correct driver without conflicts.
> You do understand that you increase your maintainence load by this move.
> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
> branches, so you will need to chase these updates.

This is my major concern with any discussion of drm that lives
outside of base. I am actually pretty amazed that kmod-next
works as often as it does.

I do remeber for a long time this
was a -current only modules, is that still true, or can I
load it on 11.0, 11.1 and 11.2Beta3 now?

> > We have updated drm-stable-kmod so that it now works on some older amd64
> > system also covered by drm2 but as always, ymmv. drm2 will later be
> > available as drm-legacy-kmod or something like that (name to be announced
> > later). Simply use/install the one that works best for you.


--
Rod Grimes ***@freebsd.org
Niclas Zeising
2018-05-31 16:53:56 UTC
Permalink
On 05/31/18 16:21, Rodney W. Grimes wrote:
>
> I do remeber for a long time this
> was a -current only modules, is that still true, or can I
> load it on 11.0, 11.1 and 11.2Beta3 now?

drm-stable-kmod works on 11.2 (including the betas) and later. We can't
backport the needed changes to the lkpi to the releases, for obvious
reasons, but they were backported some time between 11.1 and now.
Regards
--
Niclas
Jeffrey Bouquet
2018-05-31 17:41:41 UTC
Permalink
On Thu, 31 May 2018 18:02:26 +0200, "Ronald Klop" <ronald-***@klop.ws> wrote:

> On Thu, 31 May 2018 17:34:18 +0200, Joe Maloney <***@ixsystems.com>
> wrote:
>
> > I personally wish that more drivers, and firmware were separated from
> > base.
> >
> > For example wireless firmware:
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
> >
> > That was a ticket which I chimed in on about a firmware I needed to make
> > my
> > wireless adapter work. I went through numerous efforts on IRC, and
> > elsewhere to try to bring attention that ticket in order to attempt to
> > get
> > that firmware backported for several 10.x releases in a row without
> > success. The firmware worked perfectly fine in PC-BSD where it was
> > cherry
> > picked for numerous 10.x releases.
>
>
> I would support an idea that the FreeBSD project only delivers CURRENT
> (and one periodic release with security fixes) and parties like PC-BSD
> maintain stable branches and support for companies.
>
> I read about this somewhere a while ago and the idea sticks. Backporting
> to code 2+ years old is not the best use of human volunteer resources IMHO.
>
> Regards,
> Ronald.
>
>
>
> >
> > Technically since I was using PC-BSD, and was a committer for that
> > project
> > I had no real dire need to reach out to FreeBSD about the issue. I was
> > simply trying to help anyone else who might be encountering the same
> > issue
> > trying to use stock FreeBSD because it was a simple backport. If my
> > effort
> > had turned out to be more fruitful I would have spent more time pursuing
> > tickets, diffs, or whatever to get more things back-ported when I found
> > them. I am not sure where the breakdown was which did not allow that to
> > happen. Anyways I don't want to bikeshed, or anything but I just wanted
> > to
> > point out how I think having more drivers, and firmware in ports could be
> > helpful to enhance compatibility for end users.
> >
> > Having a separate port for legacy drm could definitely make things easier
> > to providing installation options for end users, and automating the post
> > install action chosen in TrueOS, GhostBSD, and future derivative projects
> > tailored for the desktop use case. For example for TrueOS we boot the
> > installer in failsafe mode with either VESA, or SCFB depending on whether
> > or not BIOS, or EFI is booted. Then we could simply make a checkbox for
> > legacy intel, or skylake + to install the correct package then the module
> > path for either driver can more or less remain the same. Eventually with
> > something like devmatch maybe that can even be fully automatic.
> >
> > Joe Maloney
> >
> > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen <***@freebsd.org>
> > wrote:
> >
> >> On Thu, 31 May 2018, Konstantin Belousov wrote:
> >>
> >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
> >>>
> >>> We're not replacing anything. We are moving the older drm1 and drm2
> >>> from
> >>>> kernel to ports to make it easier for the majority of the users to
> >>>> load
> >>>> the
> >>>> correct driver without conflicts.
> >>>>
> >>>
> >>> You do understand that you increase your maintainence load by this
> >>> move.
> >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in
> >>> stable
> >>> branches, so you will need to chase these updates.
> >>>
> >>
> >> I agree. One argument previously made was that it's easier
> >> to maintain in ports. One data point from me - I rarely
> >> update my ports, I update my OS much more frequently. In
> >> fact, some times my ports get so out of date I just
> >> (take off and) nuke /usr/local (from orbit, it's the only
> >> way to be sure).
> >>
> >> Also, are we trying to solve a problem by moving drm[2] to
> >> ports that won't be a problem when base is pkg'ized? If
> >> drm[2] is a package unto itself, then you don't have this
> >> problem of ports conflicting with it, at least not so
> >> much. You can either not install the base drm[2] package
> >> or deinstall it to make way for a conflicting port. Once
> >> drm[2] is pkg rm'd, it's not going to be reinstalled
> >> again when you update the base OS.
> >>
> >> And don't we have the same problem with sendmail and a
> >> few other base services?
> >>
> >> --
> >> DE
> >>
> >> _______________________________________________
> >> freebsd-***@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to
> >> "freebsd-current-***@freebsd.org"
> >>
> > _______________________________________________
> > freebsd-***@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-***@freebsd.org"
> _______________________________________________
> freebsd-***@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"


Is there a way to do that and ensure that it can be installed also on low power
and/or non UEFI -- mbr devices such as a 700 mhz ancient CPU? with
the less memory? Not important
any longer here due to time constraints but would ensure maybe a ten percent
greater user base from here on out than otherwise...
...........................................
If my overview is correct anyway.
Loading...