Re: head -r333905 broke the builds [ -r333906 changed the details but they are still broken]

2018-05-19 Thread Mark Millard 
On 2018-May-19, at 7:56 PM, Mark Millard  wrote:

> https://ci.freebsd.org shows all the builds being broken and
> going through the list -r333903 was working but -r333905 and
> later are not. (I ignore riscv64 here.)
> 
> Using powerpc64 as an -r333905 example:
> 
> --- sourcefilter.o ---
> In file included from 
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/netinet/ip_var.h:39,
> from /usr/src/lib/libc/net/sourcefilter.c:43:
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:42: error: 
> expected declaration specifiers or '...' before 'epoch_cb_count'
> cc1: warnings being treated as errors
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:42: warning: 
> data definition has no type or storage class
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: error: 
> expected declaration specifiers or '...' before 'epoch_cb_task'
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: warning: 
> 'struct grouptask' declared inside parameter list
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: warning: 
> its scope is only this definition or declaration, which is probably not what 
> you want
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: warning: 
> data definition has no type or storage class
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: error: 
> conflicting types for 'DPCPU_DECLARE'
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:42: error: 
> previous declaration of 'DPCPU_DECLARE' was here
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h: In function 
> 'epoch_enter_preempt':
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:68: error: 
> 'curthread' undeclared (first use in this function)
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:68: error: 
> (Each undeclared identifier is reported only once
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:68: error: for 
> each function it appears in.)
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h: In function 
> 'epoch_exit_preempt':
> /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:81: error: 
> 'curthread' undeclared (first use in this function)
> 
> 
> This seems to match up with:
> 
> Author: mmacy
> Date: Sun May 20 00:22:28 2018
> New Revision: 333905
> URL: 
> https://svnweb.freebsd.org/changeset/base/333905
> 
> 
> Log:
>  ip(6)_freemoptions: defer imo destruction to epoch callback task
> 
>  Avoid the ugly unlock / lock of the inpcbinfo where we need to
>  figure out what kind of lock we hold by simply deferring the
>  operation to another context. (Also a small dependency for
>  converting the pcbinfo read lock to epoch)
> 
> Modified:
>  head/sys/netinet/in_mcast.c
>  head/sys/netinet/in_pcb.c
>  head/sys/netinet/ip_var.h
>  head/sys/netinet6/in6_mcast.c
>  head/sys/netinet6/in6_var.h
>  head/sys/netinet6/ip6_var.h

It looks like -r333906 changed the error details. Using
i386 from ci.freebsd.org this time:

--- all_subdir_usr.sbin/sendmail ---
In file included from /usr/src/contrib/sendmail/src/daemon.c:51:
In file included from 
/usr/obj/usr/src/i386.i386/tmp/usr/include/netinet/ip_var.h:39:
In file included from /usr/obj/usr/src/i386.i386/tmp/usr/include/sys/epoch.h:33:
In file included from /usr/obj/usr/src/i386.i386/tmp/usr/include/sys/proc.h:47:
In file included from 
/usr/obj/usr/src/i386.i386/tmp/usr/include/sys/filedesc.h:42:
/usr/obj/usr/src/i386.i386/tmp/usr/include/sys/priority.h:128:8: error: 
redefinition of 'priority'
struct priority {
   ^
/usr/src/contrib/sendmail/src/sendmail.h:1081:8: note: previous definition is 
here
struct priority
   ^

This seems to happen for -r333906 and later versions on all
targets, including amd64. (I'm ignoring riscv64 that has been
broken for a long time.) powerpc64 agrees despite the gcc 4.2.1:

--- all_subdir_usr.sbin/sendmail ---
In file included from 
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/filedesc.h:42,
 from 
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/proc.h:47,
 from 
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:33,
 from 
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/netinet/ip_var.h:39,
 from /usr/src/contrib/sendmail/src/daemon.c:51:
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/priority.h:128: error: 
redefinition of 'struct priority'




===
Mark Millard
marklmi26-fbsd at yahoo.com
( dsl-only.net went
away in early 2018-Mar)






___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

head -r333905 broke the builds

2018-05-19 Thread Mark Millard 
https://ci.freebsd.org shows all the builds being broken and
going through the list -r333903 was working but -r333905 and
later are not. (I ignore riscv64 here.)

Using powerpc64 as an -r333905 example:

--- sourcefilter.o ---
In file included from 
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/netinet/ip_var.h:39,
 from /usr/src/lib/libc/net/sourcefilter.c:43:
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:42: error: 
expected declaration specifiers or '...' before 'epoch_cb_count'
cc1: warnings being treated as errors
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:42: warning: 
data definition has no type or storage class
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: error: 
expected declaration specifiers or '...' before 'epoch_cb_task'
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: warning: 
'struct grouptask' declared inside parameter list
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: warning: its 
scope is only this definition or declaration, which is probably not what you 
want
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: warning: 
data definition has no type or storage class
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:43: error: 
conflicting types for 'DPCPU_DECLARE'
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:42: error: 
previous declaration of 'DPCPU_DECLARE' was here
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h: In function 
'epoch_enter_preempt':
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:68: error: 
'curthread' undeclared (first use in this function)
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:68: error: (Each 
undeclared identifier is reported only once
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:68: error: for 
each function it appears in.)
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h: In function 
'epoch_exit_preempt':
/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include/sys/epoch.h:81: error: 
'curthread' undeclared (first use in this function)


This seems to match up with:

Author: mmacy
Date: Sun May 20 00:22:28 2018
New Revision: 333905
URL: 
https://svnweb.freebsd.org/changeset/base/333905


Log:
  ip(6)_freemoptions: defer imo destruction to epoch callback task
  
  Avoid the ugly unlock / lock of the inpcbinfo where we need to
  figure out what kind of lock we hold by simply deferring the
  operation to another context. (Also a small dependency for
  converting the pcbinfo read lock to epoch)

Modified:
  head/sys/netinet/in_mcast.c
  head/sys/netinet/in_pcb.c
  head/sys/netinet/ip_var.h
  head/sys/netinet6/in6_mcast.c
  head/sys/netinet6/in6_var.h
  head/sys/netinet6/ip6_var.h


===
Mark Millard
marklmi26-fbsd at yahoo.com
( dsl-only.net went
away in early 2018-Mar)






___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-19 Thread Andriy Gapon 
On 18/05/2018 20:58, Niclas Zeising wrote:
> [ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect reply-to
> and send all replies to freebsd-x11@.  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?

Please count me as one.

>  If so, what is preventing you from switching to the port?

Suspend / resume does not work with my hardware:
~~
panic: implment me!!
cpuid = 0
time = 1526764859
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe004d1c2280
vpanic() at vpanic+0x1a3/frame 0xfe004d1c22e0
panic() at panic+0x43/frame 0xfe004d1c2340
linux_pci_save_state() at linux_pci_save_state+0x12/frame 0xfe004d1c2350
radeon_suspend_kms() at radeon_suspend_kms+0x524/frame 0xfe004d1c23a0
linux_pci_suspend() at linux_pci_suspend+0x6e/frame 0xfe004d1c23d0
...
~~
The hardware is old, supported by radeonkms as opposed to amdgpu, but still..
Also, last time I checked audio over HDMI did not work, but I haven't tested the
latest version yet.

Finally, a counter-question, does keeping the code in its current state
(unsupported, but without explicitly stating so) obstruct the work on the new 
code?

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-19 Thread Mark Linimon 
On Fri, May 18, 2018 at 04:19:21PM -0400, Daniel Eischen wrote:
> I can easily imagine an embedded x86 kiosk type appliance.

We need to evaluate the tradeoff of "what we can imagine someone will
do with FreeBSD" vs. "what are people using with FreeBSD right now."

mcl
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-19 Thread Slawa Olhovchenkov 
On Sat, May 19, 2018 at 08:38:20PM +0200, Jan Beich wrote:

> Slawa Olhovchenkov  writes:
> 
> > On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote:
> >
> >> [ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect 
> >> reply-to and send all replies to freebsd-x11@.  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 
> >
> > What about old graphics card? I am have notebook w/ i945 chipset, is
> > this supported by graphics/drm-*?
> >
> > And what about nvidia?
> > (sorry, I am not developer this drivers, I am just user, I am don't
> > know what need for nvidia work etc)
> 
> NVIDIA dropped 32bit driver since 396.* series. None of x11/nvidia-driver*
> currently depend on either drm.ko or drm2.ko. However, Linux driver
> appears to depend on DRM/KMS since 364.12.

Some of my hardware supported only by nvidia 340.106.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-19 Thread Jan Beich 
Slawa Olhovchenkov  writes:

> On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote:
>
>> [ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect 
>> reply-to and send all replies to freebsd-x11@.  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 
>
> What about old graphics card? I am have notebook w/ i945 chipset, is
> this supported by graphics/drm-*?
>
> And what about nvidia?
> (sorry, I am not developer this drivers, I am just user, I am don't
> know what need for nvidia work etc)

NVIDIA dropped 32bit driver since 396.* series. None of x11/nvidia-driver*
currently depend on either drm.ko or drm2.ko. However, Linux driver
appears to depend on DRM/KMS since 364.12.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-19 Thread Slawa Olhovchenkov 
On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote:

> [ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect 
> reply-to and send all replies to freebsd-x11@.  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 

What about old graphics card? I am have notebook w/ i945 chipset, is
this supported by graphics/drm-*?
And what about nvidia?
(sorry, I am not developer this drivers, I am just user, I am don't
know what need for nvidia work etc)

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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-19 Thread Slawa Olhovchenkov 
On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh 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?

Removing drm2 remove all _graphics_ stuff.
I am have i386 notebook, I am don't need lates KMS, I am need just
X11/mplayer/firefox/skype.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-19 Thread Hans Petter Selasky 

On 05/19/18 05:56, Daniel Eischen wrote:

Yes, with VESA, albeit aspect ratios are off.

I'm using drm2 with an AMD (née ATI) Radeon 4850 (RV770), AGP.  This is on an 
amd64 somewhat old -current system.  Is this supported by the drm-next-kmod 
port?


I've used drm2 in the past, but noticed the anti-flicker support 
features are not as good as in the drm-next-kmod. Also video support is 
much better, external displays and so on, not only getting video on the 
built-in display but also various kinds of VGA, HDMI and displayports.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"