Re: svn commit: r335916 - head/sys/conf

2018-07-07 Thread Mark Millard via svn-src-head
Eugene Grosbein eugen at grosbein.net wrote on
Sat Jul 7 21:14:06 UTC 2018 :

> 07.07.2018 22:02, Andrew Gallatin wrote:
> 
> > One thing that was tangentially brought up is that the ability
> > to compile out-of-tree modules requires keeping the kernel-headers
> > around.  So we may need to identify all the headers that a module might
> > need, and install them in /boot/$KERNEL/sys or some-such.  This would
> > be needed if, for example, we wanted to install a new Nvidia or Virtual
> > Box module and have it work for older installed kernel versions too
> > (eg, across ABI breaking changes in -current).
> 
> We already have all headers in /usr/include, don't we?


Even if were true, it seems such would only be for self-hosted
builds, not cross-builds.

Even for self-host builds, it is not true as I understand.

(May be there is some implicit expectations/principles that
I'm missing that automatically covers the related issues,
but cross-builds seem to not be covered by parts of the
discussion.)

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

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


Re: svn commit: r335916 - head/sys/conf

2018-07-07 Thread Warner Losh
On Sat, Jul 7, 2018 at 7:06 PM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein  wrote:
> >
> > > 08.07.2018 4:38, Warner Losh wrote:
> > >
> > > > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > > > wrote:
> > > >
> > > > 07.07.2018 22:02, Andrew Gallatin wrote:
> > > >
> > > > > One thing that was tangentially brought up is that the ability
> > > > > to compile out-of-tree modules requires keeping the
> kernel-headers
> > > > > around.  So we may need to identify all the headers that a
> module
> > > might
> > > > > need, and install them in /boot/$KERNEL/sys or some-such.  This
> > > would
> > > > > be needed if, for example, we wanted to install a new Nvidia or
> > > Virtual
> > > > > Box module and have it work for older installed kernel
> versions too
> > > > > (eg, across ABI breaking changes in -current).
> > > >
> > > > We already have all headers in /usr/include, don't we?
> > > >
> > > >
> > > > Not really. We have a subset of the kernel headers that might not
> match
> > > the running kernel, nor be enough to build modules.
> > >
> > > They should match running kernel definitely as we do not support not
> > > syncronized kernel/world
> > > and installworld populates /usr/include.
> > >
> >
> > Nice theory. Lots and lots of people run this way. And it has worked
> well,
> > so long as the kernel is newer... so, no, they don't have to match.
>
> At some point I had an evolution of "make includes" that would work
> without the other parts of src being present (ie, only sys) so that
> you could update /usr/include with the kernel headers if you reved
> your kernel sources.
>
> Not sure how hard this would be to reimplement, but basically skip over
> missing parts of the src tree with a message (echo) that it could not
> find that particular set of sources was how it worked.


I really don't like this idea. It assumes The Kernel and The Includes.
However, that's not quite right. For people running releases, it's near
enough, but for developers it's not. I have, in the past, installed a
weekly kernel into /boot/kernel.$DATE and kept a constant userland. I did
this to catch performance regressions by being able to reboot quickly
between then. At any given time, we'd not have the right headers with this
scheme. Certainly not good enough to compile a module against the currently
booted kernel.

I've started to like the idea of keeping module sources for 3rd party
modules /usr/local/ and using that to rebuild the module for a
specific kernel. If we were to install the kernel includes / opt*.h files
also into /boot/$KERNEL/include somehow, then 3rd party modules could be
rebuilt at any time and we'd always have access to the builddir files that
matter... Something to consider... I think I read that Linux did this to
help prevent module breakage when new kernels are used...  It may be time
to ditch /boot/modules entirely in favor of a scheme like this.

> /usr/include is never, ever used to build the kernel (except for things
> > like aicasm).
>
> Is not /usr/include really the kernel/userland interface,
> not the kernel/kernel interface?
>

Yea, and more. It's a bit of hodge-podge, but on the whole, that's not an
inaccurate characterization. Especially the bit about it not being the
intra-kernel interface.

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


svn commit: r336080 - head/etc/mtree

2018-07-07 Thread Ian Lepore
Author: ian
Date: Sun Jul  8 01:29:48 2018
New Revision: 336080
URL: https://svnweb.freebsd.org/changeset/base/336080

Log:
  Create an aarch64 subdir under man4, now that we have aarch64 manpages.
  
  Reported by:  Mark Millard

Modified:
  head/etc/mtree/BSD.usr.dist

Modified: head/etc/mtree/BSD.usr.dist
==
--- head/etc/mtree/BSD.usr.dist Sun Jul  8 00:27:28 2018(r336079)
+++ head/etc/mtree/BSD.usr.dist Sun Jul  8 01:29:48 2018(r336080)
@@ -816,6 +816,8 @@
 man3
 ..
 man4
+aarch64
+..
 amd64
 ..
 arm
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336078 [ ci.freebsd.org 's FreeBSD-head-aarch64-build still broken ]

2018-07-07 Thread Ian Lepore
On Sat, 2018-07-07 at 18:03 -0700, Mark Millard wrote:
> https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8461/consoleTex
> t shows:
> 
> ===> share/man/man4/man4.aarch64 (distribute) cd
> /usr/src/share/man/man4/man4.aarch64; make __MAKE_CONF=/dev/null
> SRCCONF=/dev/null install installconfig -DNO_SUBDIR
> DESTDIR=/usr/obj/usr/src/arm64.aarch64/release/dist/base
> SHARED=copies install -o root -g wheel -m 444 armv8crypto.4.gz
> /usr/obj/usr/src/arm64.aarch64/release/dist/base/usr/share/man/man4/a
> arch64/ install:
> /usr/obj/usr/src/arm64.aarch64/release/dist/base/usr/share/man/man4/a
> arch64/: No such file or directory *** Error code 71 
> 
> (which is farther than it got before.)
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 
> 

r336080 may fix it.  I'm not sure, because I can't build an aarch64
world right now because of other build errors.

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


Re: svn commit: r335916 - head/sys/conf

2018-07-07 Thread Rodney W. Grimes
> On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein  wrote:
> 
> > 08.07.2018 4:38, Warner Losh wrote:
> >
> > > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > > wrote:
> > >
> > > 07.07.2018 22:02, Andrew Gallatin wrote:
> > >
> > > > One thing that was tangentially brought up is that the ability
> > > > to compile out-of-tree modules requires keeping the kernel-headers
> > > > around.  So we may need to identify all the headers that a module
> > might
> > > > need, and install them in /boot/$KERNEL/sys or some-such.  This
> > would
> > > > be needed if, for example, we wanted to install a new Nvidia or
> > Virtual
> > > > Box module and have it work for older installed kernel versions too
> > > > (eg, across ABI breaking changes in -current).
> > >
> > > We already have all headers in /usr/include, don't we?
> > >
> > >
> > > Not really. We have a subset of the kernel headers that might not match
> > the running kernel, nor be enough to build modules.
> >
> > They should match running kernel definitely as we do not support not
> > syncronized kernel/world
> > and installworld populates /usr/include.
> >
> 
> Nice theory. Lots and lots of people run this way. And it has worked well,
> so long as the kernel is newer... so, no, they don't have to match.

At some point I had an evolution of "make includes" that would work
without the other parts of src being present (ie, only sys) so that
you could update /usr/include with the kernel headers if you reved
your kernel sources.

Not sure how hard this would be to reimplement, but basically skip over
missing parts of the src tree with a message (echo) that it could not
find that particular set of sources was how it worked.

> And why a subset? Don'we support old-style kernel re-build "config; make
> > depend; make"
> > that does not require full /usr/src tree but /usr/src/sys only?
> >

Your mail agent is still mangling quoting.  Mostly when it line wraps.

> 
> /usr/include is never, ever used to build the kernel (except for things
> like aicasm).

Is not /usr/include really the kernel/userland interface,
not the kernel/kernel interface?

> Warner

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r335916 - head/sys/conf

2018-07-07 Thread Eugene Grosbein
08.07.2018 7:33, Warner Losh wrote:

> > We already have all headers in /usr/include, don't we?
> > Not really. We have a subset of the kernel headers that might not match 
> the running kernel, nor be enough to build modules.
> They should match running kernel definitely as we do not support not 
> syncronized kernel/world
> and installworld populates /usr/include.
> Nice theory. Lots and lots of people run this way. And it has worked well, so 
> long as the kernel is newer... so, no, they don't have to match.

It could work. It can also easily break things with newer kernel too, I can 
remember many cases.
/sbin/ipfw, ps, ifconfig, netstat, top, killall and some important others are 
not guaranteed to run with newer kernel.
I still run FreeBSD 4.11-STABLE inside 11.2-STABLE jail and that's why I know 
this.

> And why a subset? Don'we support old-style kernel re-build "config; make 
> depend; make"
> that does not require full /usr/src tree but /usr/src/sys only?
> /usr/include is never, ever used to build the kernel (except for things like 
> aicasm).

OO. We could still add the whole bunch of needed .h files from /usr/src/sys/ 
there.

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


Re: svn commit: r336078 [ ci.freebsd.org 's FreeBSD-head-aarch64-build still broken ]

2018-07-07 Thread Mark Millard via svn-src-head
https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8461/consoleText shows:

===> share/man/man4/man4.aarch64 (distribute) cd 
/usr/src/share/man/man4/man4.aarch64; make __MAKE_CONF=/dev/null 
SRCCONF=/dev/null install installconfig -DNO_SUBDIR 
DESTDIR=/usr/obj/usr/src/arm64.aarch64/release/dist/base SHARED=copies install 
-o root -g wheel -m 444 armv8crypto.4.gz 
/usr/obj/usr/src/arm64.aarch64/release/dist/base/usr/share/man/man4/aarch64/ 
install: 
/usr/obj/usr/src/arm64.aarch64/release/dist/base/usr/share/man/man4/aarch64/: 
No such file or directory *** Error code 71 

(which is farther than it got before.)

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

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


Re: svn commit: r336068 - in head/sys: dev/amdsmb modules/amdsmb

2018-07-07 Thread Warner Losh
On Sat, Jul 7, 2018, 6:51 PM Warner Losh  wrote:

>
>
> On Sat, Jul 7, 2018, 6:42 PM Andriy Gapon  wrote:
>
>> On 07/07/2018 18:55, Warner Losh wrote:
>> > Author: imp
>> > Date: Sat Jul  7 15:55:52 2018
>> > New Revision: 336068
>> > URL: https://svnweb.freebsd.org/changeset/base/336068
>> >
>> > Log:
>> >   Update AMDSMB to use PCI_MATCH
>>
>> Just curious if anyone still uses this driver for ancient hardware.
>> maybe de-orbit time?
>>
>
> No. All such discussions are on hold until I get the depreciation doc
> done, due by the end of the month. Then it might be a good one, but there
> is a lot in line in front of it...
>
> >   Differential Review: https://reviews.freebsd.org/D16172
>>
>> Just curious what's the point of referencing a review request that
>> - had no reviewers
>> - had no reviews
>> - does not even have a description
>>
>
> I shared it there for my GSoC student, and it wound up getting pushed as
> part of a different commute train by mistake.
>

Stupid autocorrect. Commit train. An unrelated fix was committed to the
branch I had for this by mistake (the ath one). I was in a hurry since I
wanted to get on the road and didn't check before pushing. My bad. I didn't
think it worth backing out...

Warner
>
> > Added:
>> >   head/sys/modules/amdsmb/
>> >   head/sys/modules/amdsmb/Makefile   (contents, props changed)
>> > Modified:
>> >   head/sys/dev/amdsmb/amdsmb.c
>> >
>> > Modified: head/sys/dev/amdsmb/amdsmb.c
>> >
>> ==
>> > --- head/sys/dev/amdsmb/amdsmb.c  Sat Jul  7 15:25:16 2018
>> (r336067)
>> > +++ head/sys/dev/amdsmb/amdsmb.c  Sat Jul  7 15:55:52 2018
>> (r336068)
>> > @@ -125,24 +125,22 @@ struct amdsmb_softc {
>> >
>> >  static int   amdsmb_detach(device_t dev);
>> >
>> > +struct pci_device_table amdsmb_devs[] = {
>> > + { PCI_DEV(AMDSMB_VENDORID_AMD, AMDSMB_DEVICEID_AMD8111_SMB2),
>> > +   PCI_DESCR("AMD-8111 SMBus 2.0 Controller") }
>> > +};
>> > +
>> >  static int
>> >  amdsmb_probe(device_t dev)
>> >  {
>> > - u_int16_t vid;
>> > - u_int16_t did;
>> > + const struct pci_device_table *tbl;
>> >
>> > - vid = pci_get_vendor(dev);
>> > - did = pci_get_device(dev);
>> > + tbl = PCI_MATCH(dev, amdsmb_devs);
>> > + if (tbl == NULL)
>> > + return (ENXIO);
>> > + device_set_desc(dev, tbl->descr);
>> >
>> > - if (vid == AMDSMB_VENDORID_AMD) {
>> > - switch(did) {
>> > - case AMDSMB_DEVICEID_AMD8111_SMB2:
>> > - device_set_desc(dev, "AMD-8111 SMBus 2.0
>> Controller");
>> > - return (BUS_PROBE_DEFAULT);
>> > - }
>> > - }
>> > -
>> > - return (ENXIO);
>> > + return (BUS_PROBE_DEFAULT);
>> >  }
>> >
>> >  static int
>> >
>> > Added: head/sys/modules/amdsmb/Makefile
>> >
>> ==
>> > --- /dev/null 00:00:00 1970   (empty, because file is newly added)
>> > +++ head/sys/modules/amdsmb/Makefile  Sat Jul  7 15:55:52 2018
>> (r336068)
>> > @@ -0,0 +1,8 @@
>> > +# $FreeBSD$
>> > +
>> > +.PATH:   ${SRCTOP}/sys/dev/amdsmb
>> > +
>> > +KMOD=amdsmb
>> > +SRCS=amdsmb.c bus_if.h device_if.h pci_if.h smbus_if.h
>> > +
>> > +.include 
>> >
>>
>>
>> --
>> Andriy Gapon
>>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336068 - in head/sys: dev/amdsmb modules/amdsmb

2018-07-07 Thread Warner Losh
On Sat, Jul 7, 2018, 6:42 PM Andriy Gapon  wrote:

> On 07/07/2018 18:55, Warner Losh wrote:
> > Author: imp
> > Date: Sat Jul  7 15:55:52 2018
> > New Revision: 336068
> > URL: https://svnweb.freebsd.org/changeset/base/336068
> >
> > Log:
> >   Update AMDSMB to use PCI_MATCH
>
> Just curious if anyone still uses this driver for ancient hardware.
> maybe de-orbit time?
>

No. All such discussions are on hold until I get the depreciation doc done,
due by the end of the month. Then it might be a good one, but there is a
lot in line in front of it...

>   Differential Review: https://reviews.freebsd.org/D16172
>
> Just curious what's the point of referencing a review request that
> - had no reviewers
> - had no reviews
> - does not even have a description
>

I shared it there for my GSoC student, and it wound up getting pushed as
part of a different commute train by mistake.

Warner

> Added:
> >   head/sys/modules/amdsmb/
> >   head/sys/modules/amdsmb/Makefile   (contents, props changed)
> > Modified:
> >   head/sys/dev/amdsmb/amdsmb.c
> >
> > Modified: head/sys/dev/amdsmb/amdsmb.c
> >
> ==
> > --- head/sys/dev/amdsmb/amdsmb.c  Sat Jul  7 15:25:16 2018
> (r336067)
> > +++ head/sys/dev/amdsmb/amdsmb.c  Sat Jul  7 15:55:52 2018
> (r336068)
> > @@ -125,24 +125,22 @@ struct amdsmb_softc {
> >
> >  static int   amdsmb_detach(device_t dev);
> >
> > +struct pci_device_table amdsmb_devs[] = {
> > + { PCI_DEV(AMDSMB_VENDORID_AMD, AMDSMB_DEVICEID_AMD8111_SMB2),
> > +   PCI_DESCR("AMD-8111 SMBus 2.0 Controller") }
> > +};
> > +
> >  static int
> >  amdsmb_probe(device_t dev)
> >  {
> > - u_int16_t vid;
> > - u_int16_t did;
> > + const struct pci_device_table *tbl;
> >
> > - vid = pci_get_vendor(dev);
> > - did = pci_get_device(dev);
> > + tbl = PCI_MATCH(dev, amdsmb_devs);
> > + if (tbl == NULL)
> > + return (ENXIO);
> > + device_set_desc(dev, tbl->descr);
> >
> > - if (vid == AMDSMB_VENDORID_AMD) {
> > - switch(did) {
> > - case AMDSMB_DEVICEID_AMD8111_SMB2:
> > - device_set_desc(dev, "AMD-8111 SMBus 2.0
> Controller");
> > - return (BUS_PROBE_DEFAULT);
> > - }
> > - }
> > -
> > - return (ENXIO);
> > + return (BUS_PROBE_DEFAULT);
> >  }
> >
> >  static int
> >
> > Added: head/sys/modules/amdsmb/Makefile
> >
> ==
> > --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> > +++ head/sys/modules/amdsmb/Makefile  Sat Jul  7 15:55:52 2018
> (r336068)
> > @@ -0,0 +1,8 @@
> > +# $FreeBSD$
> > +
> > +.PATH:   ${SRCTOP}/sys/dev/amdsmb
> > +
> > +KMOD=amdsmb
> > +SRCS=amdsmb.c bus_if.h device_if.h pci_if.h smbus_if.h
> > +
> > +.include 
> >
>
>
> --
> Andriy Gapon
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336068 - in head/sys: dev/amdsmb modules/amdsmb

2018-07-07 Thread Andriy Gapon
On 07/07/2018 18:55, Warner Losh wrote:
> Author: imp
> Date: Sat Jul  7 15:55:52 2018
> New Revision: 336068
> URL: https://svnweb.freebsd.org/changeset/base/336068
> 
> Log:
>   Update AMDSMB to use PCI_MATCH

Just curious if anyone still uses this driver for ancient hardware.
maybe de-orbit time?

>   Differential Review: https://reviews.freebsd.org/D16172

Just curious what's the point of referencing a review request that
- had no reviewers
- had no reviews
- does not even have a description

> Added:
>   head/sys/modules/amdsmb/
>   head/sys/modules/amdsmb/Makefile   (contents, props changed)
> Modified:
>   head/sys/dev/amdsmb/amdsmb.c
> 
> Modified: head/sys/dev/amdsmb/amdsmb.c
> ==
> --- head/sys/dev/amdsmb/amdsmb.c  Sat Jul  7 15:25:16 2018
> (r336067)
> +++ head/sys/dev/amdsmb/amdsmb.c  Sat Jul  7 15:55:52 2018
> (r336068)
> @@ -125,24 +125,22 @@ struct amdsmb_softc {
>  
>  static int   amdsmb_detach(device_t dev);
>  
> +struct pci_device_table amdsmb_devs[] = {
> + { PCI_DEV(AMDSMB_VENDORID_AMD, AMDSMB_DEVICEID_AMD8111_SMB2),
> +   PCI_DESCR("AMD-8111 SMBus 2.0 Controller") }
> +};
> +
>  static int
>  amdsmb_probe(device_t dev)
>  {
> - u_int16_t vid;
> - u_int16_t did;
> + const struct pci_device_table *tbl;
>  
> - vid = pci_get_vendor(dev);
> - did = pci_get_device(dev);
> + tbl = PCI_MATCH(dev, amdsmb_devs);
> + if (tbl == NULL)
> + return (ENXIO);
> + device_set_desc(dev, tbl->descr);
>  
> - if (vid == AMDSMB_VENDORID_AMD) {
> - switch(did) {
> - case AMDSMB_DEVICEID_AMD8111_SMB2:
> - device_set_desc(dev, "AMD-8111 SMBus 2.0 Controller");
> - return (BUS_PROBE_DEFAULT);
> - }
> - }
> -
> - return (ENXIO);
> + return (BUS_PROBE_DEFAULT);
>  }
>  
>  static int
> 
> Added: head/sys/modules/amdsmb/Makefile
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/sys/modules/amdsmb/Makefile  Sat Jul  7 15:55:52 2018
> (r336068)
> @@ -0,0 +1,8 @@
> +# $FreeBSD$
> +
> +.PATH:   ${SRCTOP}/sys/dev/amdsmb
> +
> +KMOD=amdsmb
> +SRCS=amdsmb.c bus_if.h device_if.h pci_if.h smbus_if.h
> +
> +.include 
> 


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


Re: svn commit: r335916 - head/sys/conf

2018-07-07 Thread Warner Losh
On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein  wrote:

> 08.07.2018 4:38, Warner Losh wrote:
>
> > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > wrote:
> >
> > 07.07.2018 22:02, Andrew Gallatin wrote:
> >
> > > One thing that was tangentially brought up is that the ability
> > > to compile out-of-tree modules requires keeping the kernel-headers
> > > around.  So we may need to identify all the headers that a module
> might
> > > need, and install them in /boot/$KERNEL/sys or some-such.  This
> would
> > > be needed if, for example, we wanted to install a new Nvidia or
> Virtual
> > > Box module and have it work for older installed kernel versions too
> > > (eg, across ABI breaking changes in -current).
> >
> > We already have all headers in /usr/include, don't we?
> >
> >
> > Not really. We have a subset of the kernel headers that might not match
> the running kernel, nor be enough to build modules.
>
> They should match running kernel definitely as we do not support not
> syncronized kernel/world
> and installworld populates /usr/include.
>

Nice theory. Lots and lots of people run this way. And it has worked well,
so long as the kernel is newer... so, no, they don't have to match.


And why a subset? Don'we support old-style kernel re-build "config; make
> depend; make"
> that does not require full /usr/src tree but /usr/src/sys only?
>

/usr/include is never, ever used to build the kernel (except for things
like aicasm).

Warner


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


svn commit: r336079 - in head: share/man/man4/man4.arm sys/arm/freescale/imx sys/modules/imx sys/modules/imx/imx6_ahci

2018-07-07 Thread Ian Lepore
Author: ian
Date: Sun Jul  8 00:27:28 2018
New Revision: 336079
URL: https://svnweb.freebsd.org/changeset/base/336079

Log:
  Add pnp info to imx6_ahci, and add a module makefile, and a manpage for it.

Added:
  head/share/man/man4/man4.arm/imx6_ahci.4   (contents, props changed)
  head/sys/modules/imx/imx6_ahci/
  head/sys/modules/imx/imx6_ahci/Makefile   (contents, props changed)
Modified:
  head/share/man/man4/man4.arm/Makefile
  head/sys/arm/freescale/imx/imx6_ahci.c
  head/sys/modules/imx/Makefile

Modified: head/share/man/man4/man4.arm/Makefile
==
--- head/share/man/man4/man4.arm/Makefile   Sun Jul  8 00:02:14 2018
(r336078)
+++ head/share/man/man4/man4.arm/Makefile   Sun Jul  8 00:27:28 2018
(r336079)
@@ -12,6 +12,7 @@ MAN=  \
bcm283x_pwm.4 \
cgem.4 \
devcfg.4 \
+   imx6_ahci.4 \
imx_wdog.4 \
mge.4 \
npe.4 \

Added: head/share/man/man4/man4.arm/imx6_ahci.4
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man4/man4.arm/imx6_ahci.4Sun Jul  8 00:27:28 2018
(r336079)
@@ -0,0 +1,65 @@
+.\"
+.\" Copyright (c) 2018 Ian Lepore 
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\"
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd July 7, 2018
+.Dt IMX6_AHCI 4
+.Os
+.Sh NAME
+.Nm imx6_ahci
+.Nd device driver for the NXP i.MX6 on-chip SATA controller
+.Sh SYNOPSIS
+To compile this driver into the kernel,
+place the following line in your
+kernel configuration file:
+.Bd -ragged -offset indent
+.Cd "device ahci"
+.Ed
+.Pp
+Alternatively, to load the driver as a
+module at boot time, place the following line in
+.Xr loader.conf 5 :
+.Bd -literal -offset indent
+imx6_ahci_load="YES"
+.Ed
+.Sh DESCRIPTION
+The
+.Nm
+driver provides
+support for the on-chip SATA controller found on some models of
+the NXP i.MX6 chip.
+The driver is a thin glue layer to interpret the platform's FDT
+data and marshall resources for the standard
+.Xr ahci 4
+driver.
+.Sh SEE ALSO
+.Xr ahci 4 ,
+.Xr fdt 4 ,
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Fx 12.0 .

Modified: head/sys/arm/freescale/imx/imx6_ahci.c
==
--- head/sys/arm/freescale/imx/imx6_ahci.c  Sun Jul  8 00:02:14 2018
(r336078)
+++ head/sys/arm/freescale/imx/imx6_ahci.c  Sun Jul  8 00:27:28 2018
(r336079)
@@ -64,6 +64,11 @@ __FBSDID("$FreeBSD$");
 #defineSATA_PHY_LANE0_OUT_STAT 0x2003
 #define  SATA_PHY_LANE0_OUT_STAT_RX_PLL_STATE(1 << 1)
 
+static struct ofw_compat_data compat_data[] = {
+   {"fsl,imx6q-ahci", true},
+   {NULL, false}
+};
+
 static int
 imx6_ahci_phy_ctrl(struct ahci_controller* sc, uint32_t bitmask, bool on)
 {
@@ -215,7 +220,7 @@ imx6_ahci_probe(device_t dev)
return (ENXIO);
}
 
-   if (!ofw_bus_is_compatible(dev, "fsl,imx6q-ahci")) {
+   if (!ofw_bus_search_compatible(dev, compat_data)->ocd_data) {
return (ENXIO);
}
device_set_desc(dev, "i.MX6 Integrated AHCI controller");
@@ -354,3 +359,5 @@ static driver_t ahci_ata_driver = {
 };
 
 DRIVER_MODULE(imx6_ahci, simplebus, ahci_ata_driver, ahci_devclass, 0, 0);
+MODULE_DEPEND(imx6_ahci, ahci, 1, 1, 1);
+SIMPLEBUS_PNP_INFO(compat_data)

Modified: head/sys/modules/imx/Makefile
==
--- head/sys/modules/imx/Makefile   Sun Jul  8 00:02:14 2018
(r336078)
+++ head/sys/modules/imx/Makefile   Sun Jul  

Re: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 man4.arm

2018-07-07 Thread Ravi Pokala
-Original Message-
From:  on behalf of Ian Lepore 

Date: 2018-07-07, Saturday at 17:02
To: Ravi Pokala , , 
, 
Subject: Re: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 
man4.arm

> On Sat, 2018-07-07 at 16:35 -0700, Ravi Pokala wrote:
>> -Original Message-
>> From:  on behalf of Ian Lepore 
>> Date: 2018-07-07, Saturday at 14:49
>> To: , , 
>> Subject: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 
>> man4.arm
>> 
>>> 
>>> Author: ian
>>> Date: Sat Jul  7 21:49:30 2018
>>> New Revision: 336077
>>> URL: https://svnweb.freebsd.org/changeset/base/336077
>>> 
>>> Log:
>>>   Move arm- and aarch64-specific manpages into arch-specific directories.
>>>   
>>>   This removes a bit of the .if/.endif clutter from man4/Makefile by using
>>>   the existing machinery that supports per-arch manpages.
>> Hi Ian,
>> 
>> This breaks arm64 buildworld:
>> 
>> make[8]: make[8]: don't know how to make armv8crypto.4. Stop
>> 
> 
> Doh!  Fixed in r336078; sorry about that.
> 
> -- Ian

No worries. :-)

Thanks,

Ravi (rpokala@)


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


Re: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 man4.arm

2018-07-07 Thread Ian Lepore
On Sat, 2018-07-07 at 16:35 -0700, Ravi Pokala wrote:
> -Original Message-
> From:  on behalf of Ian Lepore 
> Date: 2018-07-07, Saturday at 14:49
> To: , , 
> Subject: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 man4.arm
> 
> > 
> > Author: ian
> > Date: Sat Jul  7 21:49:30 2018
> > New Revision: 336077
> > URL: https://svnweb.freebsd.org/changeset/base/336077
> > 
> > Log:
> >   Move arm- and aarch64-specific manpages into arch-specific directories.
> >   
> >   This removes a bit of the .if/.endif clutter from man4/Makefile by using
> >   the existing machinery that supports per-arch manpages.
> Hi Ian,
> 
> This breaks arm64 buildworld:
> 
> make[8]: make[8]: don't know how to make armv8crypto.4. Stop
> 

Doh!  Fixed in r336078; sorry about that.

-- Ian

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


svn commit: r336078 - in head/share/man/man4: . man4.aarch64

2018-07-07 Thread Ian Lepore
Author: ian
Date: Sun Jul  8 00:02:14 2018
New Revision: 336078
URL: https://svnweb.freebsd.org/changeset/base/336078

Log:
  Move armv8crypto.4 into the aarch64 dir; should have been part of r336077.
  
  Pointy hat:   ian@
  Reported by:  rpokola@

Added:
  head/share/man/man4/man4.aarch64/armv8crypto.4
 - copied unchanged from r336077, head/share/man/man4/armv8crypto.4
Deleted:
  head/share/man/man4/armv8crypto.4

Copied: head/share/man/man4/man4.aarch64/armv8crypto.4 (from r336077, 
head/share/man/man4/armv8crypto.4)
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man4/man4.aarch64/armv8crypto.4  Sun Jul  8 00:02:14 
2018(r336078, copy of r336077, head/share/man/man4/armv8crypto.4)
@@ -0,0 +1,83 @@
+.\" Copyright (c) 2016 The FreeBSD Foundation
+.\" All rights reserved.
+.\"
+.\" This software was developed by Andrew Turner under
+.\" sponsorship from the FreeBSD Foundation.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd October 20, 2016
+.Dt ARMV8CRYPTO 4
+.Os
+.Sh NAME
+.Nm armv8crypto
+.Nd "driver for the AES accelerator on ARM CPUs"
+.Sh SYNOPSIS
+To compile this driver into the kernel,
+place the following lines in your
+kernel configuration file:
+.Bd -ragged -offset indent
+.Cd "device crypto"
+.Cd "device armv8crypto"
+.Ed
+.Pp
+Alternatively, to load the driver as a
+module at boot time, place the following line in
+.Xr loader.conf 5 :
+.Bd -literal -offset indent
+armv8crypto_load="YES"
+.Ed
+.Sh DESCRIPTION
+Starting with the ARMv8 architecture ARM Limited has added optional
+cryptography instructions to accelerate AES, SHA-1, SHA-2, and
+finite field arithmetic.
+.Pp
+The processor capability is reported as AES in the Instruction Set
+Attributes 0 line at boot.
+The
+.Nm
+driver does not attach on systems that lack the required CPU capability.
+.Pp
+The
+.Nm
+driver registers itself to accelerate AES operations for
+.Xr crypto 4 .
+.Sh SEE ALSO
+.Xr crypt 3 ,
+.Xr crypto 4 ,
+.Xr intro 4 ,
+.Xr ipsec 4 ,
+.Xr random 4 ,
+.Xr crypto 9
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Fx 11.0 .
+.Sh AUTHORS
+.An -nosplit
+The
+.Nm
+driver was written by
+.An Andrew Turner Aq Mt and...@freebsd.org .
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r335916 - head/sys/conf

2018-07-07 Thread Eugene Grosbein
08.07.2018 4:38, Warner Losh wrote:

> On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > wrote:
> 
> 07.07.2018 22:02, Andrew Gallatin wrote:
> 
> > One thing that was tangentially brought up is that the ability
> > to compile out-of-tree modules requires keeping the kernel-headers
> > around.  So we may need to identify all the headers that a module might
> > need, and install them in /boot/$KERNEL/sys or some-such.  This would
> > be needed if, for example, we wanted to install a new Nvidia or Virtual
> > Box module and have it work for older installed kernel versions too
> > (eg, across ABI breaking changes in -current).
> 
> We already have all headers in /usr/include, don't we?
> 
> 
> Not really. We have a subset of the kernel headers that might not match the 
> running kernel, nor be enough to build modules. 

They should match running kernel definitely as we do not support not 
syncronized kernel/world
and installworld populates /usr/include.

And why a subset? Don'we support old-style kernel re-build "config; make 
depend; make"
that does not require full /usr/src tree but /usr/src/sys only?


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


Re: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 man4.arm

2018-07-07 Thread Ravi Pokala
-Original Message-
From:  on behalf of Ian Lepore 

Date: 2018-07-07, Saturday at 14:49
To: , , 

Subject: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 man4.arm

> Author: ian
> Date: Sat Jul  7 21:49:30 2018
> New Revision: 336077
> URL: https://svnweb.freebsd.org/changeset/base/336077
> 
> Log:
>   Move arm- and aarch64-specific manpages into arch-specific directories.
>   
>   This removes a bit of the .if/.endif clutter from man4/Makefile by using
>   the existing machinery that supports per-arch manpages.

Hi Ian,

This breaks arm64 buildworld:

make[8]: make[8]: don't know how to make armv8crypto.4. Stop

-Ravi (rpokala@)


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


svn commit: r336077 - in head/share/man/man4: . man4.aarch64 man4.arm

2018-07-07 Thread Ian Lepore
Author: ian
Date: Sat Jul  7 21:49:30 2018
New Revision: 336077
URL: https://svnweb.freebsd.org/changeset/base/336077

Log:
  Move arm- and aarch64-specific manpages into arch-specific directories.
  
  This removes a bit of the .if/.endif clutter from man4/Makefile by using
  the existing machinery that supports per-arch manpages.

Added:
  head/share/man/man4/man4.aarch64/
  head/share/man/man4/man4.aarch64/Makefile   (contents, props changed)
  head/share/man/man4/man4.aarch64/rk_gpio.4
 - copied unchanged from r336076, head/share/man/man4/rk_gpio.4
  head/share/man/man4/man4.aarch64/rk_grf.4
 - copied unchanged from r336076, head/share/man/man4/rk_grf.4
  head/share/man/man4/man4.aarch64/rk_i2c.4
 - copied unchanged from r336076, head/share/man/man4/rk_i2c.4
  head/share/man/man4/man4.aarch64/rk_pinctrl.4
 - copied unchanged from r336076, head/share/man/man4/rk_pinctrl.4
  head/share/man/man4/man4.arm/aw_gpio.4
 - copied unchanged from r336076, head/share/man/man4/aw_gpio.4
  head/share/man/man4/man4.arm/aw_mmc.4
 - copied unchanged from r336076, head/share/man/man4/aw_mmc.4
  head/share/man/man4/man4.arm/aw_rtc.4
 - copied unchanged from r336076, head/share/man/man4/aw_rtc.4
  head/share/man/man4/man4.arm/aw_sid.4
 - copied unchanged from r336076, head/share/man/man4/aw_sid.4
  head/share/man/man4/man4.arm/aw_spi.4
 - copied unchanged from r336076, head/share/man/man4/aw_spi.4
  head/share/man/man4/man4.arm/aw_syscon.4
 - copied unchanged from r336076, head/share/man/man4/aw_syscon.4
  head/share/man/man4/man4.arm/bcm283x_pwm.4
 - copied unchanged from r336076, head/share/man/man4/bcm283x_pwm.4
Deleted:
  head/share/man/man4/aw_gpio.4
  head/share/man/man4/aw_mmc.4
  head/share/man/man4/aw_rtc.4
  head/share/man/man4/aw_sid.4
  head/share/man/man4/aw_spi.4
  head/share/man/man4/aw_syscon.4
  head/share/man/man4/bcm283x_pwm.4
  head/share/man/man4/rk_gpio.4
  head/share/man/man4/rk_grf.4
  head/share/man/man4/rk_i2c.4
  head/share/man/man4/rk_pinctrl.4
Modified:
  head/share/man/man4/Makefile
  head/share/man/man4/man4.arm/Makefile

Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileSat Jul  7 20:43:01 2018
(r336076)
+++ head/share/man/man4/MakefileSat Jul  7 21:49:30 2018
(r336077)
@@ -54,7 +54,6 @@ MAN=  aac.4 \
${_aout.4} \
${_apic.4} \
arcmsr.4 \
-   ${_armv8crypto.4} \
${_asmc.4} \
ata.4 \
ath.4 \
@@ -70,16 +69,9 @@ MAN= aac.4 \
audit.4 \
auditpipe.4 \
aue.4 \
-   ${_aw_gpio.4} \
-   ${_aw_mmc.4} \
-   ${_aw_rtc.4} \
-   ${_aw_sid.4} \
-   ${_aw_spi.4} \
-   ${_aw_syscon.4} \
axe.4 \
axge.4 \
bce.4 \
-   ${_bcm283x_pwm.4} \
bcma.4 \
bfe.4 \
bge.4 \
@@ -444,10 +436,6 @@ MAN=   aac.4 \
re.4 \
rgephy.4 \
rights.4 \
-   ${_rk_gpio.4} \
-   ${_rk_grf.4} \
-   ${_rk_i2c.4} \
-   ${_rk_pinctrl.4} \
rl.4 \
rndtest.4 \
route.4 \
@@ -762,23 +750,6 @@ MLINKS+=${_wpi.4} ${_if_wpi.4}
 MLINKS+=xe.4 if_xe.4
 MLINKS+=xl.4 if_xl.4
 
-.if ${MACHINE_CPUARCH} == "aarch64"
-_armv8crypto.4=armv8crypto.4
-_rk_gpio.4=rk_gpio.4
-_rk_grf.4= rk_grf.4
-_rk_i2c.4= rk_i2c.4
-_rk_pinctrl.4= rk_pinctrl.4
-.endif
-
-.if ${MACHINE_CPUARCH} == "arm" || ${MACHINE_CPUARCH} == "aarch64"
-_aw_gpio.4=aw_gpio.4
-_aw_mmc.4= aw_mmc.4
-_aw_rtc.4= aw_rtc.4
-_aw_sid.4= aw_sid.4
-_aw_spi.4= aw_spi.4
-_aw_syscon.4=  aw_syscon.4
-.endif
-
 .if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386"
 _acpi_asus.4=  acpi_asus.4
 _acpi_asus_wmi.4=  acpi_asus_wmi.4
@@ -894,10 +865,6 @@ _nvram2env.4=  nvram2env.4
 .if ${MACHINE_CPUARCH} == "powerpc"
 _nvd.4=nvd.4
 _nvme.4=   nvme.4
-.endif
-
-.if ${MACHINE_ARCH:Marmv[67]*} != "" || ${MACHINE_CPUARCH} == "aarch64"
-_bcm283x_pwm.4=  bcm283x_pwm.4
 .endif
 
 .if exists(${.CURDIR}/man4.${MACHINE_CPUARCH})

Added: head/share/man/man4/man4.aarch64/Makefile
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man4/man4.aarch64/Makefile   Sat Jul  7 21:49:30 2018
(r336077)
@@ -0,0 +1,23 @@
+# $FreeBSD$
+
+PACKAGE=runtime-manuals
+
+.PATH: ${.CURDIR}/../man4.arm # Some manpages are common to arm and aarch64
+
+MAN=   \
+   armv8crypto.4 \
+   aw_gpio.4 \
+   aw_mmc.4 \
+   aw_rtc.4 \
+   aw_sid.4 \
+   aw_spi.4 \
+   aw_syscon.4 \
+   bcm283x_pwm.4 \
+   rk_gpio.4 \
+   rk_grf.4 \
+   rk_i2c.4 \
+   rk_pinctrl.4 \
+
+MANSUBDIR=/aarch64
+
+.include 

Copied: head/share/man/man4/man4.aarch64/rk_gpio.4 (from r336076, 
head/share/man/man4/rk_gpio.4)

Re: svn commit: r335916 - head/sys/conf

2018-07-07 Thread Warner Losh
On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  wrote:

> 07.07.2018 22:02, Andrew Gallatin wrote:
>
> > One thing that was tangentially brought up is that the ability
> > to compile out-of-tree modules requires keeping the kernel-headers
> > around.  So we may need to identify all the headers that a module might
> > need, and install them in /boot/$KERNEL/sys or some-such.  This would
> > be needed if, for example, we wanted to install a new Nvidia or Virtual
> > Box module and have it work for older installed kernel versions too
> > (eg, across ABI breaking changes in -current).
>
> We already have all headers in /usr/include, don't we?
>

Not really. We have a subset of the kernel headers that might not match the
running kernel, nor be enough to build modules.

Warner

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


Re: svn commit: r335916 - head/sys/conf

2018-07-07 Thread Eugene Grosbein
07.07.2018 22:02, Andrew Gallatin wrote:

> One thing that was tangentially brought up is that the ability
> to compile out-of-tree modules requires keeping the kernel-headers
> around.  So we may need to identify all the headers that a module might
> need, and install them in /boot/$KERNEL/sys or some-such.  This would
> be needed if, for example, we wanted to install a new Nvidia or Virtual
> Box module and have it work for older installed kernel versions too
> (eg, across ABI breaking changes in -current).

We already have all headers in /usr/include, don't we?

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


Re: svn commit: r336028 - head/usr.bin/top

2018-07-07 Thread Cy Schubert
In message , 
=?utf-8?B?5b6M6Je
k5aSn5Zyw?= writes:
> 
> > 2018/07/07 8:53、Hiroki Sato のメール:
> > 
> > Daichi GOTO  wrote
> >  in <201807061207.w66c76cr043...@repo.freebsd.org>:
> > 
> > da> Author: daichi
> > da> Date: Fri Jul  6 12:07:06 2018
> > da> New Revision: 336028
> > da> URL: https://svnweb.freebsd.org/changeset/base/336028
> > da>
> > da> Log:
> > da>   Changed to eliminate the upper limit of command length displayed
> > da>   by "-a" and expand to match terminal width
> > da>
> > da>   Reviewed by:  eadler
> > da>   Approved by:  gnn (mentor)
> > da>   Differential Revision:https://reviews.freebsd.org/D16083
> > da>
> > da> Modified:
> > da>   head/usr.bin/top/display.c
> > da>   head/usr.bin/top/machine.c
> > da>   head/usr.bin/top/screen.c
> > da>   head/usr.bin/top/top.h
> > 
> > This change breaks displaying a prompt and messages in the
> > interactive mode by new_message() when typing "o" or "p", for
> > example.  While r336031 fixed a warning in GCC, it does not fix the
> > problem itself.  Please fix it.
>
> OK. I will fix this problem first.

This should circumvent the problem until you find a more permanent fix.

Index: /opt/src/svn-current/usr.bin/top/display.c
===
--- /opt/src/svn-current/usr.bin/top/display.c  (revision 336075)
+++ /opt/src/svn-current/usr.bin/top/display.c  (working copy)
@@ -960,7 +960,7 @@
 va_start(args, msgfmt);
 
 /* first, format the message */
-vsnprintf(next_msg, strlen(next_msg), msgfmt, args);
+vsnprintf(next_msg, screen_width + 5, msgfmt, args);
 
 va_end(args);
 

>
>
> > I also think restructure of the buffer management is required first
> > if we want to eliminate the column width limitation.  Using sbuf(9)
> > consistently may be better than incomplete conversion from static
> > arrays to malloc().
>
> I understand. Switching to sbuf(9) is the next step.
>
> > 
> > -- Hiroki
>
>
>


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


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


svn commit: r336076 - head/share/man/man4/man4.arm

2018-07-07 Thread Ian Lepore
Author: ian
Date: Sat Jul  7 20:43:01 2018
New Revision: 336076
URL: https://svnweb.freebsd.org/changeset/base/336076

Log:
  Add a manpage for the imx5/6 watchdog driver.

Added:
  head/share/man/man4/man4.arm/imx_wdog.4   (contents, props changed)
Modified:
  head/share/man/man4/man4.arm/Makefile

Modified: head/share/man/man4/man4.arm/Makefile
==
--- head/share/man/man4/man4.arm/Makefile   Sat Jul  7 19:27:49 2018
(r336075)
+++ head/share/man/man4/man4.arm/Makefile   Sat Jul  7 20:43:01 2018
(r336076)
@@ -4,11 +4,13 @@ PACKAGE=runtime-manuals
 
 MAN=   cgem.4 \
devcfg.4 \
+   imx_wdog.4 \
mge.4 \
npe.4 \
ti_adc.4
 
 MLINKS= cgem.4 if_cgem.4
+MLINKS+= imx_wdog.4 imxwdt.4
 MLINKS+= mge.4 if_mge.4
 MLINKS+=npe.4 if_npe.4
 

Added: head/share/man/man4/man4.arm/imx_wdog.4
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man4/man4.arm/imx_wdog.4 Sat Jul  7 20:43:01 2018
(r336076)
@@ -0,0 +1,112 @@
+.\"
+.\" Copyright (c) 2018 Ian Lepore 
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\"
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd July 7, 2018
+.Dt IMX_WDOG 4
+.Os
+.Sh NAME
+.Nm imx_wdog
+.Nd device driver for the NXP i.MX5 and i.MX6 watchdog timer
+.Sh SYNOPSIS
+To compile this driver into the kernel,
+place the following line in your
+kernel configuration file:
+.Bd -ragged -offset indent
+.Cd "device imxwdt"
+.Ed
+.Pp
+Alternatively, to load the driver as a
+module at boot time, place the following line in
+.Xr loader.conf 5 :
+.Bd -literal -offset indent
+imx_wdog_load="YES"
+.Ed
+.Sh DESCRIPTION
+The
+.Nm
+driver provides
+.Xr watchdog 4
+support for the watchdog timer present on NXP i.MX5 and i.MX6 processors.
+The i.MX watchdog hardware supports programmable timeouts ranging from
+0.5 to 128 seconds, in half-second increments.
+Once activated, the watchdog hardware cannot be deactivated, but the
+timeout period can be changed to any valid non-zero value.
+.Pp
+At power-on, a special 16-second
+.Sq power-down timer
+mode is automatically enabled by the hardware.
+It will assert the external WDOG_B signal, which may be connected to
+external hardware that causes the system to reset or power-down.
+The power-down timer is often reset by the boot loader (typically U-Boot).
+If the power-down timer is still active at the time when the normal
+watchdog is first enabled, the
+.Nm
+driver automatically disables it.
+.Pp
+The
+.Nm
+driver supports the FDT
+.Va fsl,external-reset
+property by enabling the assertion of the WDOG_B external timeout signal
+when the property is present.
+When running this way, the need to reset the system due to watchdog
+timeout is signaled by driving the WDOG_B line low; some external
+entity is expected to assert the chip's POR pin in response.
+The
+.Nm
+driver attempts to backstop this external reset by scheduling an
+interrupt to occur as well.
+The interrupt handler waits 1 second for the external reset to occur,
+then it triggers a normal software reset.
+Note that the WDOG_B signal can be configured to use a variety of
+pins on the chip.
+For the
+.Va fsl,external-reset
+property to be effective, the signal must be connected to an appropriate
+pin by the system's FDT pinctrl data.
+.Pp
+The
+.Nm
+driver supports the FDT
+.Va timeout-secs
+property by enabling the watchdog as soon as the driver attaches,
+using the given timeout value.
+This extends watchdog protection to much of the system startup process,
+but it still requires that
+.Xr watchdogd 4
+be configured to service the 

Re: svn commit: r335967 - head/sys/dev/mxge

2018-07-07 Thread Rick Macklem
Andrew Gallatin wrote:
>Given that we do TSO like Linux, and not like MS (meaning
>we express the size of the pre-segmented packet using the
>a 16-bit value in the IPv4/IPv6 header), supporting more
>than 64K is not possible in FreeBSD, so I'm basically
>saying "nerf this constraint".
Well, my understanding was that the total length of the TSO
segment is in the first header mbuf of the chain handed to
the net driver.
I thought the 16bit IP header was normally filled in with the
length because certain drivers/hardware expected that.

>MS windows does it better / different; they express the
>size of the pre-segmented packet in packet metadata,
>leaving ip->ip_len = 0.  This is better, since
>then the pseudo hdr checksum in the template header can be
>re-used (with the len added) for every segment by the NIC.
>If you've ever seen a driver set ip->ip_len = 0, and re-calc
>the pseudo-hdr checksum, that's why.   This is also why
>MS LSOv2 can support TSO of packets larger than 64K, since they're
>not constrained by the 16-bit value in the IP{4,6} header.
>The value of TSO larger than 64K is questionable at best though.
>Without pacing, you'd just get more packets dropped when
>talking across the internet..
I think some drivers already do TSO segments greater than 64K.
(It has been a while, but I recall "grep"ng for a case where if_hw_tsomax was
set to a large value and did find one. I think it was a "vm" fake hardware
driver.)

I suspect the challenge is more finding out what the hardware actually
expects the IP header length to be set to. If MS uses a setting of 0, I'd guess
most newer hardware can handle that?
Beyond that, this is way out of my area of exeprtise;-)

> if_hw_tsomaxsegsize is the maximum size of contiguous memory
> that a "chunk" of the TSO segment can be stored in for handling by
> the driver's transmit side. Since higher

>And this is what I object to.  TCP should not care about
>this.  Drivers should use busdma, or otherwise be capable of
>chopping large contig regions down to chunks that they can
>handle.   If a driver can really only handle 2K, then it should
>be having busdma give it an s/g list that is 2x as long, not having
>TCP call m_dupcl() 2x as often on page-sized data generated by
>sendfile (or more on non-x86 with larger pages).
>
>> level code such as NFS (and iSCSI, I think?) uses MCLBYTE clusters,
>> anything 2K or higher normally works the same.  Not sure about
>> sosend(), but I think it also copies the data into MCLBYTE clusters?
>> This would change if someday jumbo mbuf clusters become the norm.
>> (I tried changing the NFS code to use jumbo clusters, but it would
>>   result in fragmentation of the memory used for mbuf cluster allocation,
>>   so I never committed it.)
>
>At least for sendfile(), vm pages are wrapped up and attached to
>mbufs, so you have 4K (and potentially much more on non-x86).
>Doesn't NFS do something similar when sending data, or do you copy
>into clusters?
Most NFS RPC messages are small and fit into a regular mbuf. I have to look
at the code to see when/if it uses an mbuf cluster for those. (It has changed
a few times over the years.)
For Read replies, it uses a chain of mbuf clusters. I suspect that it could
do what sendfile does for UFS. Part of the problem is that NFS clients can do
byte aligned reads of any size, so going through the buffer cache is useful
sometimes. For write requests, odd sized writes that are byte aligned can often
happen when a loader does its thing.
For ZFS, I have no idea. I'm not a ZFS guy.
For write requests, the server gets whatever the TCP layer passes up,
which is normally a chain of mbufs.
(For the client substitute Read/Write, since the writes are copied out of the
 buffer cache and the Read replies come up from TCP.)

>I have changes which I have not upstreamed yet which enhance mbufs to
>carry TLS metadata & vector of physical addresses (which I call
>unmapped mbufs) for sendfile and kernel TLS.  As part of that,
>sosend (for kTLS) can allocate many pages and attach them to one mbuf.
>The idea (for kTLS) is that you can keep an entire TLS record (with
>framing information) in a single unmapped mbuf, which saves a
>huge amount of CPU which would be lost to cache misses doing
>pointer-chasing of really long mbuf chains (TLS hdrs and trailers
>are generally 13 and 16 bytes).  The goal was to regain CPU
>during Netflix's transition to https streaming.  However, it
>is unintentionally quite helpful on i386, since it reduces
>overhead from having to map/unmap sf_bufs. FWIW, these mbufs
>have been in production at Netflix for over a year, and carry
>a large fraction of the worlds internet traffic :)
These could probably be useful for the NFS server doing read replies, since
it does a VOP_READ() with a "uio" that refers to buffers (which happen to be
mbuf cluster data areas right now).
For the other cases, I'd have to look at it more closely.

They do sound interesting, rick
[stuff snipped]

svn commit: r336075 - head/sys/fs/nfsserver

2018-07-07 Thread Rick Macklem
Author: rmacklem
Date: Sat Jul  7 19:27:49 2018
New Revision: 336075
URL: https://svnweb.freebsd.org/changeset/base/336075

Log:
  Fix handling of the hybrid DS case for a pNFS server.
  
  After the addition of the "#mds_path" suffix for a DS specification on the
  "-p" nfsd option, it is possible to have a mix of DSs assigned to an MDS
  file system and DSs that store files for all DSs. This is what I referred
  to as "hybrid" above.
  At first, I didn't think this hybrid case would be useful, but I now believe
  that some system administrators may fine it useful.
  This patch modifies the file storage assignment algorithm so that it
  makes the "#mds_path" DSs take priority and the all file systems DSs
  are now only used for MDS file systems with no "#mds_path" DS servers.
  This only affects the pNFS server for this "hybrid" case.

Modified:
  head/sys/fs/nfsserver/nfs_nfsdport.c

Modified: head/sys/fs/nfsserver/nfs_nfsdport.c
==
--- head/sys/fs/nfsserver/nfs_nfsdport.cSat Jul  7 19:11:43 2018
(r336074)
+++ head/sys/fs/nfsserver/nfs_nfsdport.cSat Jul  7 19:27:49 2018
(r336075)
@@ -3848,7 +3848,7 @@ nfsrv_pnfscreate(struct vnode *vp, struct vattr *vap, 
 NFSPROC_T *p)
 {
struct nfsrvdscreate *dsc, *tdsc;
-   struct nfsdevice *ds, *mds;
+   struct nfsdevice *ds, *tds, *fds;
struct mount *mp;
struct pnfsdsfile *pf, *tpf;
struct pnfsdsattr dsattr;
@@ -3866,12 +3866,25 @@ nfsrv_pnfscreate(struct vnode *vp, struct vattr *vap, 
/* Get a DS server directory in a round-robin order. */
mirrorcnt = 1;
mp = vp->v_mount;
+   ds = fds = NULL;
NFSDDSLOCK();
-   TAILQ_FOREACH(ds, _devidhead, nfsdev_list) {
-   if (ds->nfsdev_nmp != NULL && (ds->nfsdev_mdsisset == 0 ||
-   (mp->mnt_stat.f_fsid.val[0] == ds->nfsdev_mdsfsid.val[0] &&
-mp->mnt_stat.f_fsid.val[1] == ds->nfsdev_mdsfsid.val[1])))
-   break;
+   /*
+* Search for the first entry that handles this MDS fs, but use the
+* first entry for all MDS fs's otherwise.
+*/
+   TAILQ_FOREACH(tds, _devidhead, nfsdev_list) {
+   if (tds->nfsdev_nmp != NULL) {
+   if (tds->nfsdev_mdsisset == 0 && ds == NULL)
+   ds = tds;
+   else if (tds->nfsdev_mdsisset != 0 &&
+   mp->mnt_stat.f_fsid.val[0] ==
+   tds->nfsdev_mdsfsid.val[0] &&
+   mp->mnt_stat.f_fsid.val[1] ==
+   tds->nfsdev_mdsfsid.val[1]) {
+   ds = fds = tds;
+   break;
+   }
+   }
}
if (ds == NULL) {
NFSDDSUNLOCK();
@@ -3881,17 +3894,18 @@ nfsrv_pnfscreate(struct vnode *vp, struct vattr *vap, 
i = dsdir[0] = ds->nfsdev_nextdir;
ds->nfsdev_nextdir = (ds->nfsdev_nextdir + 1) % nfsrv_dsdirsize;
dvp[0] = ds->nfsdev_dsdir[i];
-   mds = TAILQ_NEXT(ds, nfsdev_list);
-   if (nfsrv_maxpnfsmirror > 1 && mds != NULL) {
-   TAILQ_FOREACH_FROM(mds, _devidhead, nfsdev_list) {
-   if (mds->nfsdev_nmp != NULL &&
-   (mds->nfsdev_mdsisset == 0 ||
-(mp->mnt_stat.f_fsid.val[0] ==
- mds->nfsdev_mdsfsid.val[0] &&
+   tds = TAILQ_NEXT(ds, nfsdev_list);
+   if (nfsrv_maxpnfsmirror > 1 && tds != NULL) {
+   TAILQ_FOREACH_FROM(tds, _devidhead, nfsdev_list) {
+   if (tds->nfsdev_nmp != NULL &&
+   ((tds->nfsdev_mdsisset == 0 && fds == NULL) ||
+(tds->nfsdev_mdsisset != 0 && fds != NULL &&
+ mp->mnt_stat.f_fsid.val[0] ==
+ tds->nfsdev_mdsfsid.val[0] &&
  mp->mnt_stat.f_fsid.val[1] ==
- mds->nfsdev_mdsfsid.val[1]))) {
+ tds->nfsdev_mdsfsid.val[1]))) {
dsdir[mirrorcnt] = i;
-   dvp[mirrorcnt] = mds->nfsdev_dsdir[i];
+   dvp[mirrorcnt] = tds->nfsdev_dsdir[i];
mirrorcnt++;
if (mirrorcnt >= nfsrv_maxpnfsmirror)
break;
@@ -4495,7 +4509,7 @@ nfsrv_dsgetsockmnt(struct vnode *vp, int lktype, char 
struct nfsmount *nmp, *newnmp;
struct sockaddr *sad;
struct sockaddr_in *sin;
-   struct nfsdevice *ds, *fndds;
+   struct nfsdevice *ds, *tds, *fndds;
struct pnfsdsfile *pf;
uint32_t dsdir;
int error, fhiszero, fnd, gotone, i, mirrorcnt;
@@ -4563,6 +4577,7 @@ 

svn commit: r336074 - head/sys/ufs/ffs

2018-07-07 Thread Kirk McKusick
Author: mckusick
Date: Sat Jul  7 19:11:43 2018
New Revision: 336074
URL: https://svnweb.freebsd.org/changeset/base/336074

Log:
  Import commit from NetBSD with checkin message:
  
  Avoid Undefined Behavior in ffs_clusteracct()
  
  Change the type of 'bit' variable from int to unsigned int and use 
unsigned
  values consistently.
  
  sys/ufs/ffs/ffs_subr.c:336:10, shift exponent -1 is negative
  
  Detected with Kernel Undefined Behavior Sanitizer.
  
  Reported by 
  
  Submitted by: Pedro Giffuni

Modified:
  head/sys/ufs/ffs/ffs_subr.c

Modified: head/sys/ufs/ffs/ffs_subr.c
==
--- head/sys/ufs/ffs/ffs_subr.c Sat Jul  7 19:10:00 2018(r336073)
+++ head/sys/ufs/ffs/ffs_subr.c Sat Jul  7 19:11:43 2018(r336074)
@@ -473,7 +473,8 @@ ffs_clusteracct(struct fs *fs, struct cg *cgp, ufs1_da
int32_t *sump;
int32_t *lp;
u_char *freemapp, *mapp;
-   int i, start, end, forw, back, map, bit;
+   int i, start, end, forw, back, map;
+   u_int bit;
 
if (fs->fs_contigsumsize <= 0)
return;
@@ -495,7 +496,7 @@ ffs_clusteracct(struct fs *fs, struct cg *cgp, ufs1_da
end = cgp->cg_nclusterblks;
mapp = [start / NBBY];
map = *mapp++;
-   bit = 1 << (start % NBBY);
+   bit = 1U << (start % NBBY);
for (i = start; i < end; i++) {
if ((map & bit) == 0)
break;
@@ -516,7 +517,7 @@ ffs_clusteracct(struct fs *fs, struct cg *cgp, ufs1_da
end = -1;
mapp = [start / NBBY];
map = *mapp--;
-   bit = 1 << (start % NBBY);
+   bit = 1U << (start % NBBY);
for (i = start; i > end; i--) {
if ((map & bit) == 0)
break;
@@ -524,7 +525,7 @@ ffs_clusteracct(struct fs *fs, struct cg *cgp, ufs1_da
bit >>= 1;
} else {
map = *mapp--;
-   bit = 1 << (NBBY - 1);
+   bit = 1U << (NBBY - 1);
}
}
back = start - i;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336073 - head/sys/arm/freescale/imx

2018-07-07 Thread Ian Lepore
Author: ian
Date: Sat Jul  7 19:10:00 2018
New Revision: 336073
URL: https://svnweb.freebsd.org/changeset/base/336073

Log:
  Add support to the imx watchdog for the FDT "timeout-sec" property, by
  automatically initializing the watchdog using the given value.  Also,
  attach at BUS_PASS_TIMER to extend watchdog protection to more of the
  kernel init process.

Modified:
  head/sys/arm/freescale/imx/imx_wdog.c

Modified: head/sys/arm/freescale/imx/imx_wdog.c
==
--- head/sys/arm/freescale/imx/imx_wdog.c   Sat Jul  7 19:03:38 2018
(r336072)
+++ head/sys/arm/freescale/imx/imx_wdog.c   Sat Jul  7 19:10:00 2018
(r336073)
@@ -98,42 +98,52 @@ WR2(struct imx_wdog_softc *sc, bus_size_t offs, uint16
bus_write_2(sc->sc_res[MEMRES], offs, val);
 }
 
+static int
+imx_wdog_enable(struct imx_wdog_softc *sc, u_int timeout)
+{
+   uint16_t reg;
+
+   if (timeout < 1 || timeout > 128)
+   return (EINVAL);
+
+   mtx_lock(>sc_mtx);
+   if (timeout != sc->sc_timeout) {
+   sc->sc_timeout = timeout;
+   reg = RD2(sc, WDOG_CR_REG);
+   reg &= ~WDOG_CR_WT_MASK;
+   reg |= ((2 * timeout - 1) << WDOG_CR_WT_SHIFT);
+   WR2(sc, WDOG_CR_REG, reg | WDOG_CR_WDE);
+   }
+   /* Refresh counter */
+   WR2(sc, WDOG_SR_REG, WDOG_SR_STEP1);
+   WR2(sc, WDOG_SR_REG, WDOG_SR_STEP2);
+   /* Watchdog active, can disable rom-boot watchdog. */
+   if (sc->sc_pde_enabled) {
+   sc->sc_pde_enabled = false;
+   reg = RD2(sc, WDOG_MCR_REG);
+   WR2(sc, WDOG_MCR_REG, reg & ~WDOG_MCR_PDE);
+   }
+   mtx_unlock(>sc_mtx);
+
+   return (0);
+}
+
 static void
 imx_watchdog(void *arg, u_int cmd, int *error)
 {
struct imx_wdog_softc *sc;
-   uint16_t reg;
u_int timeout;
 
sc = arg;
-   mtx_lock(>sc_mtx);
if (cmd == 0) {
if (bootverbose)
device_printf(sc->sc_dev, "Can not be disabled.\n");
*error = EOPNOTSUPP;
} else {
timeout = (u_int)((1ULL << (cmd & WD_INTERVAL)) / 10U);
-   if (timeout > 1 && timeout < 128) {
-   if (timeout != sc->sc_timeout) {
-   sc->sc_timeout = timeout;
-   reg = RD2(sc, WDOG_CR_REG);
-   reg &= ~WDOG_CR_WT_MASK;
-   reg |= ((2 * timeout - 1) << WDOG_CR_WT_SHIFT);
-   WR2(sc, WDOG_CR_REG, reg | WDOG_CR_WDE);
-   }
-   /* Refresh counter */
-   WR2(sc, WDOG_SR_REG, WDOG_SR_STEP1);
-   WR2(sc, WDOG_SR_REG, WDOG_SR_STEP2);
-   /* Watchdog active, can disable rom-boot watchdog. */
-   if (sc->sc_pde_enabled) {
-   sc->sc_pde_enabled = false;
-   reg = RD2(sc, WDOG_MCR_REG);
-   WR2(sc, WDOG_MCR_REG, reg & ~WDOG_MCR_PDE);
-   }
+   if (imx_wdog_enable(sc, timeout) == 0)
*error = 0;
-   }
}
-   mtx_unlock(>sc_mtx);
 }
 
 static int
@@ -175,6 +185,7 @@ static int
 imx_wdog_attach(device_t dev)
 {
struct imx_wdog_softc *sc;
+   pcell_t timeout;
 
sc = device_get_softc(dev);
sc->sc_dev = dev;
@@ -209,6 +220,19 @@ imx_wdog_attach(device_t dev)
 
EVENTHANDLER_REGISTER(watchdog_list, imx_watchdog, sc, 0);
 
+   /* If there is a timeout-sec property, activate the watchdog. */
+   if (OF_getencprop(ofw_bus_get_node(sc->sc_dev), "timeout-sec",
+   , sizeof(timeout)) == sizeof(timeout)) {
+   if (timeout < 1 || timeout > 128) {
+   device_printf(sc->sc_dev, "ERROR: bad timeout-sec "
+   "property value %u, using 128\n", timeout);
+   timeout = 128;
+   }
+   imx_wdog_enable(sc, timeout);
+   device_printf(sc->sc_dev, "watchdog enabled using "
+   "timeout-sec property value %u\n", timeout);
+   }
+
/*
 * The watchdog hardware cannot be disabled, so there's little point in
 * coding up a detach() routine to carefully tear everything down, just
@@ -232,5 +256,6 @@ static driver_t imx_wdog_driver = {
 
 static devclass_t imx_wdog_devclass;
 
-DRIVER_MODULE(imx_wdog, simplebus, imx_wdog_driver, imx_wdog_devclass, 0, 0);
+EARLY_DRIVER_MODULE(imx_wdog, simplebus, imx_wdog_driver,
+imx_wdog_devclass, 0, 0, BUS_PASS_TIMER);
 SIMPLEBUS_PNP_INFO(compat_data);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, 

svn commit: r336072 - head/sys/arm/freescale/imx

2018-07-07 Thread Ian Lepore
Author: ian
Date: Sat Jul  7 19:03:38 2018
New Revision: 336072
URL: https://svnweb.freebsd.org/changeset/base/336072

Log:
  Correctly calculate the value to put in the imx wdog countdown register.
  
  The correct value is seconds*2-1.  The code was using just seconds*2, which
  led to being off by a half-second -- usually not a big deal, except when the
  value was the max (128) it overflowed so zero would get written to the
  countdown register, which equates to a timeout of a half second.

Modified:
  head/sys/arm/freescale/imx/imx_wdog.c

Modified: head/sys/arm/freescale/imx/imx_wdog.c
==
--- head/sys/arm/freescale/imx/imx_wdog.c   Sat Jul  7 17:58:20 2018
(r336071)
+++ head/sys/arm/freescale/imx/imx_wdog.c   Sat Jul  7 19:03:38 2018
(r336072)
@@ -118,8 +118,7 @@ imx_watchdog(void *arg, u_int cmd, int *error)
sc->sc_timeout = timeout;
reg = RD2(sc, WDOG_CR_REG);
reg &= ~WDOG_CR_WT_MASK;
-   reg |= (timeout << (WDOG_CR_WT_SHIFT + 1)) &
-   WDOG_CR_WT_MASK;
+   reg |= ((2 * timeout - 1) << WDOG_CR_WT_SHIFT);
WR2(sc, WDOG_CR_REG, reg | WDOG_CR_WDE);
}
/* Refresh counter */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r334880 - head/sys/dev/vnic

2018-07-07 Thread Mark Johnston
On Sat, Jun 09, 2018 at 02:47:49PM +, Andrew Turner wrote:
> Author: andrew
> Date: Sat Jun  9 14:47:49 2018
> New Revision: 334880
> URL: https://svnweb.freebsd.org/changeset/base/334880
> 
> Log:
>   In the ThunderX BGX network driver we were skipping the NULL terminator
>   when parsing the phy type, however this is included in the length returned
>   by OF_getprop. To fix this stop ignoring the terminator.
>   
>   PR: 228828
>   Reported by:sbruno
>   Sponsored by:   DARPA, AFRL

This seems to break vnic on packet.net ThunderXs.  In particular, VF
creation fails.  It seems the problem in my case is that there are
multiple PHY devices in the device tree, e.g., xfi@0, xfi@1.  With this
change, bgx_fdt_phy_name_match() fails to match against any device
containing a unit address in the node name.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336070 - in head/sys: arm/freescale/imx modules/imx modules/imx/imx_wdog

2018-07-07 Thread Ian Lepore
Author: ian
Date: Sat Jul  7 17:25:09 2018
New Revision: 336070
URL: https://svnweb.freebsd.org/changeset/base/336070

Log:
  Add pnp info and a module makefile for the imx_wdog watchdog driver.

Added:
  head/sys/modules/imx/imx_wdog/
  head/sys/modules/imx/imx_wdog/Makefile   (contents, props changed)
Modified:
  head/sys/arm/freescale/imx/imx_wdog.c
  head/sys/modules/imx/Makefile

Modified: head/sys/arm/freescale/imx/imx_wdog.c
==
--- head/sys/arm/freescale/imx/imx_wdog.c   Sat Jul  7 15:55:58 2018
(r336069)
+++ head/sys/arm/freescale/imx/imx_wdog.c   Sat Jul  7 17:25:09 2018
(r336070)
@@ -209,6 +209,13 @@ imx_wdog_attach(device_t dev)
sc->sc_pde_enabled = true;
 
EVENTHANDLER_REGISTER(watchdog_list, imx_watchdog, sc, 0);
+
+   /*
+* The watchdog hardware cannot be disabled, so there's little point in
+* coding up a detach() routine to carefully tear everything down, just
+* make the device busy so that detach can't happen.
+*/
+   device_busy(sc->sc_dev);
return (0);
 }
 
@@ -227,3 +234,4 @@ static driver_t imx_wdog_driver = {
 static devclass_t imx_wdog_devclass;
 
 DRIVER_MODULE(imx_wdog, simplebus, imx_wdog_driver, imx_wdog_devclass, 0, 0);
+SIMPLEBUS_PNP_INFO(compat_data);

Modified: head/sys/modules/imx/Makefile
==
--- head/sys/modules/imx/Makefile   Sat Jul  7 15:55:58 2018
(r336069)
+++ head/sys/modules/imx/Makefile   Sat Jul  7 17:25:09 2018
(r336070)
@@ -5,5 +5,6 @@ SUBDIR = \
../ffec \
imx_i2c \
imx_spi \
+   imx_wdog \

 .include 

Added: head/sys/modules/imx/imx_wdog/Makefile
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/modules/imx/imx_wdog/Makefile  Sat Jul  7 17:25:09 2018
(r336070)
@@ -0,0 +1,14 @@
+# $FreeBSD$
+
+.PATH: ${SRCTOP}/sys/arm/freescale/imx
+
+KMOD=  imx_wdog
+SRCS=  imx_wdog.c
+
+# Generated files...
+SRCS+= \
+   bus_if.h \
+   device_if.h \
+   ofw_bus_if.h \
+
+.include 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336026 - in head: lib/libnv usr.sbin/config

2018-07-07 Thread Kyle Evans
On Fri, Jul 6, 2018 at 6:23 AM, Kyle Evans  wrote:
> Author: kevans
> Date: Fri Jul  6 11:23:14 2018
> New Revision: 336026
> URL: https://svnweb.freebsd.org/changeset/base/336026
>
> Log:
>   config(8): Fix broken ABI
>
>   r336019 introduced ${SRCTOP}/sys to the include paths in order to pull in a
>   new sys/{c,}nv.h. This is wrong, because the build tree's ABI isn't
>   guaranteed to match what's running on the host system.
>
>   Fix instead by removing -I${SRCTOP}/sys and installing the libnv headers
>   with `make -C lib/libnv includes`... this may or may not get re-worked in
>   the future so that a userland lib isn't installing includes from sys/.
>
>   Reported by:  bdrewery
>
> Modified:
>   head/lib/libnv/Makefile
>   head/usr.sbin/config/Makefile
>
> Modified: head/lib/libnv/Makefile
> ==
> --- head/lib/libnv/Makefile Fri Jul  6 10:13:42 2018(r336025)
> +++ head/lib/libnv/Makefile Fri Jul  6 11:23:14 2018(r336026)
> @@ -17,6 +17,9 @@ SRCS+=msgio.c
>  SRCS+= nvlist.c
>  SRCS+= nvpair.c
>
> +INCSDIR=   ${INCLUDEDIR}/sys
> +INCS=  ${SRCTOP}/sys/sys/cnv.h ${SRCTOP}/sys/sys/nv.h
> +
>  HAS_TESTS=
>  SUBDIR.${MK_TESTS}+= tests
>

It seems that this isn't a sustainable solution, as it creates a
conflict between runtime-development and libnv-development packages as
both try to install these headers from sys/. If we want to use libnv
from legacy build in a bootstrap tool, though, we need lib/libnv to
setup INCS correctly.

Is there a better solution to either only do this if we're
BOOTSTRAPPING < 1200070 and staging worldtmp or just pull these from
sys/sys while still allowing them to be used in kernel as expected?
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336069 - head/sys/dev/ath

2018-07-07 Thread Warner Losh
Author: imp
Date: Sat Jul  7 15:55:58 2018
New Revision: 336069
URL: https://svnweb.freebsd.org/changeset/base/336069

Log:
  Fix PCI_SUBDEV call

Modified:
  head/sys/dev/ath/if_ath_pci.c

Modified: head/sys/dev/ath/if_ath_pci.c
==
--- head/sys/dev/ath/if_ath_pci.c   Sat Jul  7 15:55:52 2018
(r336068)
+++ head/sys/dev/ath/if_ath_pci.c   Sat Jul  7 15:55:58 2018
(r336069)
@@ -86,7 +86,7 @@ struct ath_pci_softc {
PCI_DEV(v,d)
 
 #definePCI_DEVICE_SUB(v, d, sv, sd)\
-   PCI_DEV(v, d), PCI_SUBDEV(v, d)
+   PCI_DEV(v, d), PCI_SUBDEV(sv, sd)
 
 #definePCI_VENDOR_ID_ATHEROS   0x168c
 #definePCI_VENDOR_ID_SAMSUNG   0x144d
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336068 - in head/sys: dev/amdsmb modules/amdsmb

2018-07-07 Thread Warner Losh
Author: imp
Date: Sat Jul  7 15:55:52 2018
New Revision: 336068
URL: https://svnweb.freebsd.org/changeset/base/336068

Log:
  Update AMDSMB to use PCI_MATCH
  
  Differential Review: https://reviews.freebsd.org/D16172

Added:
  head/sys/modules/amdsmb/
  head/sys/modules/amdsmb/Makefile   (contents, props changed)
Modified:
  head/sys/dev/amdsmb/amdsmb.c

Modified: head/sys/dev/amdsmb/amdsmb.c
==
--- head/sys/dev/amdsmb/amdsmb.cSat Jul  7 15:25:16 2018
(r336067)
+++ head/sys/dev/amdsmb/amdsmb.cSat Jul  7 15:55:52 2018
(r336068)
@@ -125,24 +125,22 @@ struct amdsmb_softc {
 
 static int amdsmb_detach(device_t dev);
 
+struct pci_device_table amdsmb_devs[] = {
+   { PCI_DEV(AMDSMB_VENDORID_AMD, AMDSMB_DEVICEID_AMD8111_SMB2),
+ PCI_DESCR("AMD-8111 SMBus 2.0 Controller") }
+};
+
 static int
 amdsmb_probe(device_t dev)
 {
-   u_int16_t vid;
-   u_int16_t did;
+   const struct pci_device_table *tbl;
 
-   vid = pci_get_vendor(dev);
-   did = pci_get_device(dev);
+   tbl = PCI_MATCH(dev, amdsmb_devs);
+   if (tbl == NULL)
+   return (ENXIO);
+   device_set_desc(dev, tbl->descr);
 
-   if (vid == AMDSMB_VENDORID_AMD) {
-   switch(did) {
-   case AMDSMB_DEVICEID_AMD8111_SMB2:
-   device_set_desc(dev, "AMD-8111 SMBus 2.0 Controller");
-   return (BUS_PROBE_DEFAULT);
-   }
-   }
-
-   return (ENXIO);
+   return (BUS_PROBE_DEFAULT);
 }
 
 static int

Added: head/sys/modules/amdsmb/Makefile
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/modules/amdsmb/MakefileSat Jul  7 15:55:52 2018
(r336068)
@@ -0,0 +1,8 @@
+# $FreeBSD$
+
+.PATH: ${SRCTOP}/sys/dev/amdsmb
+
+KMOD=  amdsmb
+SRCS=  amdsmb.c bus_if.h device_if.h pci_if.h smbus_if.h
+
+.include 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336067 - head/sys/dev/ath

2018-07-07 Thread Warner Losh
On Sat, Jul 7, 2018, 10:50 AM Conrad Meyer  wrote:

> On Sat, Jul 7, 2018 at 8:25 AM, Warner Losh  wrote:
> > Author: imp
> > Date: Sat Jul  7 15:25:16 2018
> > New Revision: 336067
> > URL: https://svnweb.freebsd.org/changeset/base/336067
> >
> > Log:
> >   Switch to using new PCI_MATCH stuff.
> >
> > Modified: head/sys/dev/ath/if_ath_pci.c
> >
> ==
> > --- head/sys/dev/ath/if_ath_pci.c   Sat Jul  7 15:25:11 2018
> (r336066)
> > +++ head/sys/dev/ath/if_ath_pci.c   Sat Jul  7 15:25:16 2018
> (r336067)
> > @@ -82,41 +82,12 @@ struct ath_pci_softc {
> > ...
> > -   int sub_vendor_id;
> > -   int sub_device_id;
> > +#definePCI_DEVICE_SUB(v, d, sv, sd)\
> > +   PCI_DEV(v, d), PCI_SUBDEV(v, d)
>
> PCI_SUBDEV(sv, sd)?
>

Doh.

Warner

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


Re: svn commit: r336067 - head/sys/dev/ath

2018-07-07 Thread Conrad Meyer
On Sat, Jul 7, 2018 at 8:25 AM, Warner Losh  wrote:
> Author: imp
> Date: Sat Jul  7 15:25:16 2018
> New Revision: 336067
> URL: https://svnweb.freebsd.org/changeset/base/336067
>
> Log:
>   Switch to using new PCI_MATCH stuff.
>
> Modified: head/sys/dev/ath/if_ath_pci.c
> ==
> --- head/sys/dev/ath/if_ath_pci.c   Sat Jul  7 15:25:11 2018
> (r336066)
> +++ head/sys/dev/ath/if_ath_pci.c   Sat Jul  7 15:25:16 2018
> (r336067)
> @@ -82,41 +82,12 @@ struct ath_pci_softc {
> ...
> -   int sub_vendor_id;
> -   int sub_device_id;
> +#definePCI_DEVICE_SUB(v, d, sv, sd)\
> +   PCI_DEV(v, d), PCI_SUBDEV(v, d)

PCI_SUBDEV(sv, sd)?

Best,
Conrad
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336067 - head/sys/dev/ath

2018-07-07 Thread Warner Losh
Author: imp
Date: Sat Jul  7 15:25:16 2018
New Revision: 336067
URL: https://svnweb.freebsd.org/changeset/base/336067

Log:
  Switch to using new PCI_MATCH stuff.

Modified:
  head/sys/dev/ath/if_ath_pci.c
  head/sys/dev/ath/if_ath_pci_devlist.h

Modified: head/sys/dev/ath/if_ath_pci.c
==
--- head/sys/dev/ath/if_ath_pci.c   Sat Jul  7 15:25:11 2018
(r336066)
+++ head/sys/dev/ath/if_ath_pci.c   Sat Jul  7 15:25:16 2018
(r336067)
@@ -82,41 +82,12 @@ struct ath_pci_softc {
void*sc_ih; /* interrupt handler */
 };
 
-/*
- * XXX eventually this should be some system level definition
- * so modules will have probe/attach information like USB.
- * But for now..
- */
-struct pci_device_id {
-   int vendor_id;
-   int device_id;
+#definePCI_VDEVICE(v, d)   \
+   PCI_DEV(v,d)
 
-   int sub_vendor_id;
-   int sub_device_id;
+#definePCI_DEVICE_SUB(v, d, sv, sd)\
+   PCI_DEV(v, d), PCI_SUBDEV(v, d)
 
-   int driver_data;
-
-   int match_populated:1;
-   int match_vendor_id:1;
-   int match_device_id:1;
-   int match_sub_vendor_id:1;
-   int match_sub_device_id:1;
-};
-
-#definePCI_VDEVICE(v, s) \
-   .vendor_id = (v), \
-   .device_id = (s), \
-   .match_populated = 1, \
-   .match_vendor_id = 1, \
-   .match_device_id = 1
-
-#definePCI_DEVICE_SUB(v, d, dv, ds) \
-   .match_populated = 1, \
-   .vendor_id = (v), .match_vendor_id = 1, \
-   .device_id = (d), .match_device_id = 1, \
-   .sub_vendor_id = (dv), .match_sub_vendor_id = 1, \
-   .sub_device_id = (ds), .match_sub_device_id = 1
-
 #definePCI_VENDOR_ID_ATHEROS   0x168c
 #definePCI_VENDOR_ID_SAMSUNG   0x144d
 #definePCI_VENDOR_ID_AZWAVE0x1a3b
@@ -130,50 +101,6 @@ struct pci_device_id {
 
 #include "if_ath_pci_devlist.h"
 
-/*
- * Attempt to find a match for the given device in
- * the given device table.
- *
- * Returns the device structure or NULL if no matching
- * PCI device is found.
- */
-static const struct pci_device_id *
-ath_pci_probe_device(device_t dev, const struct pci_device_id *dev_table, int 
nentries)
-{
-   int i;
-   int vendor_id, device_id;
-   int sub_vendor_id, sub_device_id;
-
-   vendor_id = pci_get_vendor(dev);
-   device_id = pci_get_device(dev);
-   sub_vendor_id = pci_get_subvendor(dev);
-   sub_device_id = pci_get_subdevice(dev);
-
-   for (i = 0; i < nentries; i++) {
-   /* Don't match on non-populated (eg empty) entries */
-   if (! dev_table[i].match_populated)
-   continue;
-
-   if (dev_table[i].match_vendor_id &&
-   (dev_table[i].vendor_id != vendor_id))
-   continue;
-   if (dev_table[i].match_device_id &&
-   (dev_table[i].device_id != device_id))
-   continue;
-   if (dev_table[i].match_sub_vendor_id &&
-   (dev_table[i].sub_vendor_id != sub_vendor_id))
-   continue;
-   if (dev_table[i].match_sub_device_id &&
-   (dev_table[i].sub_device_id != sub_device_id))
-   continue;
-
-   /* Match */
-   return (_table[i]);
-   }
-
-   return (NULL);
-}
-
 #defineBS_BAR  0x10
 #definePCIR_RETRY_TIMEOUT  0x41
 #definePCIR_CFG_PMCSR  0x48
@@ -244,12 +171,12 @@ ath_pci_attach(device_t dev)
const struct firmware *fw = NULL;
const char *buf;
 #endif
-   const struct pci_device_id *pd;
+   const struct pci_device_table *pd;
 
sc->sc_dev = dev;
 
/* Do this lookup anyway; figure out what to do with it later */
-   pd = ath_pci_probe_device(dev, ath_pci_id_table, 
nitems(ath_pci_id_table));
+   pd = PCI_MATCH(dev, ath_pci_id_table);
if (pd)
sc->sc_pci_devinfo = pd->driver_data;
 

Modified: head/sys/dev/ath/if_ath_pci_devlist.h
==
--- head/sys/dev/ath/if_ath_pci_devlist.h   Sat Jul  7 15:25:11 2018
(r336066)
+++ head/sys/dev/ath/if_ath_pci_devlist.h   Sat Jul  7 15:25:16 2018
(r336067)
@@ -29,7 +29,7 @@
  * $FreeBSD$
  */
 
-static const struct pci_device_id ath_pci_id_table[] = {
+static const struct pci_device_table ath_pci_id_table[] = {
{ PCI_VDEVICE(PCI_VENDOR_ID_ATHEROS, 0x0023) }, /* PCI   */
{ PCI_VDEVICE(PCI_VENDOR_ID_ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(PCI_VENDOR_ID_ATHEROS, 0x0027) }, /* PCI   */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail 

svn commit: r336065 - head

2018-07-07 Thread Warner Losh
Author: imp
Date: Sat Jul  7 15:25:06 2018
New Revision: 336065
URL: https://svnweb.freebsd.org/changeset/base/336065

Log:
  Mention the need to update devmatch.conf

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Sat Jul  7 14:46:02 2018(r336064)
+++ head/UPDATING   Sat Jul  7 15:25:06 2018(r336065)
@@ -63,6 +63,11 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
needed to be changed to work with it. This change was made with r335763
and requires a mergemaster / etcupdate / etc to update the installed 
file.
 
+20180628:
+   r335753 introduced a new quoting method. However, etc/devd/devmatch.conf
+   needed to be changed to work with it. This change was made with r335763
+   and requires a mergemaster / etcupdate / etc to update the installed 
file.
+
 20180612:
r334930 changed the interface between the NFS modules, so they all
need to be rebuilt.  r335018 did a __FreeBSD_version bump for this.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336066 - in head/sys: compat/linsysfs dev/pci

2018-07-07 Thread Warner Losh
Author: imp
Date: Sat Jul  7 15:25:11 2018
New Revision: 336066
URL: https://svnweb.freebsd.org/changeset/base/336066

Log:
  Create PCI_MATCH and pci_match_device
  
  Create a covenience function to match PCI device IDs. It's about 15
  years overdue.
  
  Differential Revision: https://reviews.freebsd.org/D15999

Modified:
  head/sys/compat/linsysfs/linsysfs.c
  head/sys/dev/pci/pci.c
  head/sys/dev/pci/pcivar.h

Modified: head/sys/compat/linsysfs/linsysfs.c
==
--- head/sys/compat/linsysfs/linsysfs.c Sat Jul  7 15:25:06 2018
(r336065)
+++ head/sys/compat/linsysfs/linsysfs.c Sat Jul  7 15:25:11 2018
(r336066)
@@ -273,6 +273,7 @@ linsysfs_fill_vgapci(PFS_FILL_ARGS)
return (0);
 }
 
+#undef PCI_DEV
 #define PCI_DEV "pci"
 #define DRMN_DEV "drmn"
 static int

Modified: head/sys/dev/pci/pci.c
==
--- head/sys/dev/pci/pci.c  Sat Jul  7 15:25:06 2018(r336065)
+++ head/sys/dev/pci/pci.c  Sat Jul  7 15:25:11 2018(r336066)
@@ -6244,3 +6244,39 @@ pcie_flr(device_t dev, u_int max_delay, bool force)
pci_printf(>cfg, "Transactions pending after FLR!\n");
return (true);
 }
+
+const struct pci_device_table *
+pci_match_device(device_t child, const struct pci_device_table *id, size_t 
nelt)
+{
+   bool match;
+   uint16_t vendor, device, subvendor, subdevice, class, subclass, revid;
+
+   vendor = pci_get_vendor(child);
+   device = pci_get_device(child);
+   subvendor = pci_get_subvendor(child);
+   subdevice = pci_get_subdevice(child);
+   class = pci_get_class(child);
+   subclass = pci_get_subclass(child);
+   revid = pci_get_revid(child);
+   while (nelt-- > 0) {
+   match = true;
+   if (id->match_flag_vendor)
+   match &= vendor == id->vendor;
+   if (id->match_flag_device)
+   match &= device == id->device;
+   if (id->match_flag_subvendor)
+   match &= subvendor == id->subvendor;
+   if (id->match_flag_subdevice)
+   match &= subdevice == id->subdevice;
+   if (id->match_flag_class)
+   match &= class == id->class_id;
+   if (id->match_flag_subclass)
+   match &= subclass == id->subclass;
+   if (id->match_flag_revid)
+   match &= revid == id->revid;
+   if (match)
+   return (id);
+   id++;
+   }
+   return (NULL);
+}

Modified: head/sys/dev/pci/pcivar.h
==
--- head/sys/dev/pci/pcivar.h   Sat Jul  7 15:25:06 2018(r336065)
+++ head/sys/dev/pci/pcivar.h   Sat Jul  7 15:25:11 2018(r336066)
@@ -259,6 +259,66 @@ typedef struct {
 
 extern uint32_t pci_numdevs;
 
+struct pci_device_table {
+#if BYTE_ORDER == LITTLE_ENDIAN
+   uint16_t
+   match_flag_vendor:1,
+   match_flag_device:1,
+   match_flag_subvendor:1,
+   match_flag_subdevice:1,
+   match_flag_class:1,
+   match_flag_subclass:1,
+   match_flag_revid:1,
+   match_flag_unused:9;
+#else
+   uint16_t
+   match_flag_unused:9,
+   match_flag_revid:1,
+   match_flag_subclass:1,
+   match_flag_class:1,
+   match_flag_subdevice:1,
+   match_flag_subvendor:1,
+   match_flag_device:1,
+   match_flag_vendor:1;
+#endif
+   uint16_tvendor;
+   uint16_tdevice;
+   uint16_tsubvendor;
+   uint16_tsubdevice;
+   uint16_tclass_id;
+   uint16_tsubclass;
+   uint16_trevid;
+   uint16_tunused;
+   uintptr_t   driver_data;
+   char*descr;
+};
+
+#definePCI_DEV(v, d)   
\
+   .match_flag_vendor = 1, .vendor = (v),  \
+   .match_flag_device = 1, .device = (d)
+#definePCI_SUBDEV(sv, sd)  
\
+   .match_flag_subvendor = 1, .subvendor = (sv),   \
+   .match_flag_subdevice = 1, .subdevice = (sd)
+#definePCI_CLASS(x)
\
+   .match_flag_class = 1, .class_id = (x)
+#definePCI_SUBCLASS(x) 
\
+   .match_flag_subclass = 1, .subclass = (x)
+#definePCI_REVID(x)
\
+   .match_flag_revid = 1, .revid = (x)
+#definePCI_DESCR(x)
\
+   .descr = (x)

Re: svn commit: r336025 - in head/sys: amd64/include i386/include

2018-07-07 Thread Rodney W. Grimes
... Applied the context axe ...

> >
> > A good reason for continuing UP support on x86 is to make it easy to
> > test UP builds in the MI parts of the kernel so that we don't break
> > things for the embedded architectures.  Unfortunately "make universe"
> > currently doesn't have any UP kernels, so I've managed to commit changes
> > that break UP builds and not known it until I received reports of broken
> > builds from other users
> >
> 
> UP kernels have not changed. The setups that have UP kernels generally need
> custom ones anyway, since there's so many devices that aren't used. Those
> setups aren't affected by this change.
> 
> You raise an interesting point, though: it hasn't been important enough to
> the project to include a UP kernel in CI testing we've done for years and
> years...

Should we add GENERIC-UP to atleast i386 and amd64 and include this in
the universe target?

Or perhaps teach LINT to also make LINT-UP? 

Regards,
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r335916 - head/sys/conf

2018-07-07 Thread Andrew Gallatin

On 07/05/18 19:59, John Baldwin wrote:


You misunderstand.  /usr/local/sys/modules would hold module sources so that
they can be recompiled when building a kernel without having to rebuild the
package or reinstall the package.  Binary modules would continue to be
installed in /boot/modules.



This is very similar to the approach that many Linux distributions take
with DKMS.  The kernel sources for out-of-tree modules are kept around,
and every time a kernel is installed, its new header files are used to
re-compile the out-of-tree module.   Similarly, when you install a
package containing a kernel module, it is re-compiled and installed
for every installed kernel.

One thing that was tangentially brought up is that the ability
to compile out-of-tree modules requires keeping the kernel-headers
around.  So we may need to identify all the headers that a module might
need, and install them in /boot/$KERNEL/sys or some-such.  This would
be needed if, for example, we wanted to install a new Nvidia or Virtual
Box module and have it work for older installed kernel versions too
(eg, across ABI breaking changes in -current).

This would certainly make life easier for people running -current.
This system works quite well on Linux.  For comparison, I used an
Ubuntu based desktop with Nvidia graphics at a previous employers,
and a FreeBSD-current desktop w/Nvidia graphics now. I've been left w/o
graphics  accidentally much more often on FreeBSD than I ever
had been on Ubuntu, even when compiling my own kernels from git..

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


Re: svn commit: r336042 - head/sys/dev/cxgbe/common

2018-07-07 Thread Andrew Gallatin

On 07/06/18 15:33, Navdeep Parhar wrote:



Log:
   cxgbe(4): Assume that any unknown flash on the card is 4MB and has 64KB
   sectors, instead of refusing to attach to the card.
   


Thank you!

Drew

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


Re: svn commit: r335967 - head/sys/dev/mxge

2018-07-07 Thread Andrew Gallatin

On 07/05/18 17:14, Rick Macklem wrote:

Andrew Gallatin wrote:
On 7/4/18 9:20 PM, Rodney W. Grimes wrote:
[stuff snipped]


It is using a magic constant twice, where one has a
derived value that is dependent on the value of the other.
That is bad and error prone and does not document that
one depends on the other.  Please fix this.  Or at least
make 65536 a #define so that it only needs changed one
place and clearly shows the interdependence of these
values.


To me, 65536 is one of the few cases where the magic number is
more meaningful than a name.  But fine, if you feel that
strongly about it, I'll change it for you.


Btw, in general, if_hw_tsomax and if_hw_tsomaxsegsize are not
related or the same value. It just happens that they both appear
to be related to 64K in this case. (I believe this is fairly common,
since the original Microsoft "standard" used 64K as a limit, since
it was stored in 16bits.)


Yes; exactly.


if_hw_tsomax is the maximum size of the entire TSO segment,
including MAC level headers (commonly 64K, due to Mircosoft...
but could be larger if the hardware guys chose to do so).


Given that we do TSO like Linux, and not like MS (meaning
we express the size of the pre-segmented packet using the
a 16-bit value in the IPv4/IPv6 header), supporting more
than 64K is not possible in FreeBSD, so I'm basically
saying "nerf this constraint".

MS windows does it better / different; they express the
size of the pre-segmented packet in packet metadata,
leaving ip->ip_len = 0.  This is better, since
then the pseudo hdr checksum in the template header can be
re-used (with the len added) for every segment by the NIC.
If you've ever seen a driver set ip->ip_len = 0, and re-calc
the pseudo-hdr checksum, that's why.   This is also why
MS LSOv2 can support TSO of packets larger than 64K, since they're
not constrained by the 16-bit value in the IP{4,6} header.
The value of TSO larger than 64K is questionable at best though.
Without pacing, you'd just get more packets dropped when
talking across the internet..


if_hw_tsomaxsegsize is the maximum size of contiguous memory
that a "chunk" of the TSO segment can be stored in for handling by
the driver's transmit side. Since higher


And this is what I object to.  TCP should not care about
this.  Drivers should use busdma, or otherwise be capable of
chopping large contig regions down to chunks that they can
handle.   If a driver can really only handle 2K, then it should
be having busdma give it an s/g list that is 2x as long, not having
TCP call m_dupcl() 2x as often on page-sized data generated by
sendfile (or more on non-x86 with larger pages).


level code such as NFS (and iSCSI, I think?) uses MCLBYTE clusters,
anything 2K or higher normally works the same.  Not sure about
sosend(), but I think it also copies the data into MCLBYTE clusters?
This would change if someday jumbo mbuf clusters become the norm.
(I tried changing the NFS code to use jumbo clusters, but it would
  result in fragmentation of the memory used for mbuf cluster allocation,
  so I never committed it.)



At least for sendfile(), vm pages are wrapped up and attached to
mbufs, so you have 4K (and potentially much more on non-x86).
Doesn't NFS do something similar when sending data, or do you copy
into clusters?

I have changes which I have not upstreamed yet which enhance mbufs to
carry TLS metadata & vector of physical addresses (which I call
unmapped mbufs) for sendfile and kernel TLS.  As part of that,
sosend (for kTLS) can allocate many pages and attach them to one mbuf.
The idea (for kTLS) is that you can keep an entire TLS record (with
framing information) in a single unmapped mbuf, which saves a
huge amount of CPU which would be lost to cache misses doing
pointer-chasing of really long mbuf chains (TLS hdrs and trailers
are generally 13 and 16 bytes).  The goal was to regain CPU
during Netflix's transition to https streaming.  However, it
is unintentionally quite helpful on i386, since it reduces
overhead from having to map/unmap sf_bufs. FWIW, these mbufs
have been in production at Netflix for over a year, and carry
a large fraction of the worlds internet traffic :)



rick
ps: And I'll admit I don't find 65536 very magic;-)



:)

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


svn commit: r336063 - head/sys/vm

2018-07-07 Thread Sean Bruno
Author: sbruno
Date: Sat Jul  7 13:37:44 2018
New Revision: 336063
URL: https://svnweb.freebsd.org/changeset/base/336063

Log:
  Wrap the declaration and assignment of "stripe" with #ifdef NUMA declarations
  as not all targets are NUMA aware.
  
  Found with gcc.
  
  Sponsored by: Limelight Networks
  Differential Revision:https://reviews.freebsd.org/D16113

Modified:
  head/sys/vm/uma_core.c

Modified: head/sys/vm/uma_core.c
==
--- head/sys/vm/uma_core.c  Sat Jul  7 13:35:06 2018(r336062)
+++ head/sys/vm/uma_core.c  Sat Jul  7 13:37:44 2018(r336063)
@@ -2860,7 +2860,9 @@ zone_import(uma_zone_t zone, void **bucket, int max, i
 {
uma_slab_t slab;
uma_keg_t keg;
+#ifdef NUMA
int stripe;
+#endif
int i;
 
slab = NULL;
@@ -2870,7 +2872,9 @@ zone_import(uma_zone_t zone, void **bucket, int max, i
if ((slab = zone->uz_slab(zone, keg, domain, flags)) == NULL)
break;
keg = slab->us_keg;
+#ifdef NUMA
stripe = howmany(max, vm_ndomains);
+#endif
while (slab->us_freecount && i < max) { 
bucket[i++] = slab_alloc_item(keg, slab);
if (keg->uk_free <= keg->uk_reserve)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336062 - head/sys/net

2018-07-07 Thread Sean Bruno
Author: sbruno
Date: Sat Jul  7 13:35:06 2018
New Revision: 336062
URL: https://svnweb.freebsd.org/changeset/base/336062

Log:
  struct ifmediareq *ifmrp is only used in the COMPAT_FREEBSD32 parts of
  ifioctl().  Move it inside the proper #ifdef.  This was throwing a valid
  "Assigned but unused" warning with gcc.
  
  Sponsored by: Limelight Networks
  Differential Revision:https://reviews.freebsd.org/D16063

Modified:
  head/sys/net/if.c

Modified: head/sys/net/if.c
==
--- head/sys/net/if.c   Sat Jul  7 12:28:16 2018(r336061)
+++ head/sys/net/if.c   Sat Jul  7 13:35:06 2018(r336062)
@@ -2969,8 +2969,8 @@ ifioctl(struct socket *so, u_long cmd, caddr_t data, s
 #ifdef COMPAT_FREEBSD32
caddr_t saved_data = NULL;
struct ifmediareq ifmr;
-#endif
struct ifmediareq *ifmrp;
+#endif
struct ifnet *ifp;
struct ifreq *ifr;
int error;
@@ -3016,8 +3016,8 @@ ifioctl(struct socket *so, u_long cmd, caddr_t data, s
 #endif
}
 
-   ifmrp = NULL;
 #ifdef COMPAT_FREEBSD32
+   ifmrp = NULL;
switch (cmd) {
case SIOCGIFMEDIA32:
case SIOCGIFXMEDIA32:
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336061 - head/sys/netinet/tcp_stacks

2018-07-07 Thread Michael Tuexen
Author: tuexen
Date: Sat Jul  7 12:28:16 2018
New Revision: 336061
URL: https://svnweb.freebsd.org/changeset/base/336061

Log:
  Allow alternate TCP stack to populate the TCP FO client cookie
  cache.
  
  Without this patch, TCP FO could be used when using alternate
  TCP stack, but only existing entires in the TCP client cookie
  cache could be used. This cache was not populated by connections
  using alternate TCP stacks.
  
  Sponsored by: Netflix, Inc.

Modified:
  head/sys/netinet/tcp_stacks/fastpath.c
  head/sys/netinet/tcp_stacks/rack.c

Modified: head/sys/netinet/tcp_stacks/fastpath.c
==
--- head/sys/netinet/tcp_stacks/fastpath.c  Sat Jul  7 11:53:39 2018
(r336060)
+++ head/sys/netinet/tcp_stacks/fastpath.c  Sat Jul  7 12:28:16 2018
(r336061)
@@ -109,6 +109,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #ifdef TCPDEBUG
 #include 
 #endif /* TCPDEBUG */
@@ -1761,6 +1762,13 @@ tcp_do_segment_fastslow(struct mbuf *m, struct tcphdr 
if ((tp->t_flags & TF_SACK_PERMIT) &&
(to.to_flags & TOF_SACKPERM) == 0)
tp->t_flags &= ~TF_SACK_PERMIT;
+   if (IS_FASTOPEN(tp->t_flags)) {
+   if (to.to_flags & TOF_FASTOPEN)
+   tcp_fastopen_update_cache(tp, to.to_mss,
+   to.to_tfo_len, to.to_tfo_cookie);
+   else
+   tcp_fastopen_disable_path(tp);
+   }
}
 
/*
@@ -2211,6 +2219,13 @@ tcp_do_segment_fastack(struct mbuf *m, struct tcphdr *
if ((tp->t_flags & TF_SACK_PERMIT) &&
(to.to_flags & TOF_SACKPERM) == 0)
tp->t_flags &= ~TF_SACK_PERMIT;
+   if (IS_FASTOPEN(tp->t_flags)) {
+   if (to.to_flags & TOF_FASTOPEN)
+   tcp_fastopen_update_cache(tp, to.to_mss,
+   to.to_tfo_len, to.to_tfo_cookie);
+   else
+   tcp_fastopen_disable_path(tp);
+   }
}
 
/*

Modified: head/sys/netinet/tcp_stacks/rack.c
==
--- head/sys/netinet/tcp_stacks/rack.c  Sat Jul  7 11:53:39 2018
(r336060)
+++ head/sys/netinet/tcp_stacks/rack.c  Sat Jul  7 12:28:16 2018
(r336061)
@@ -6656,6 +6656,13 @@ rack_hpts_do_segment(struct mbuf *m, struct tcphdr *th
if ((tp->t_flags & TF_SACK_PERMIT) &&
(to.to_flags & TOF_SACKPERM) == 0)
tp->t_flags &= ~TF_SACK_PERMIT;
+   if (IS_FASTOPEN(tp->t_flags)) {
+   if (to.to_flags & TOF_FASTOPEN)
+   tcp_fastopen_update_cache(tp, to.to_mss,
+   to.to_tfo_len, to.to_tfo_cookie);
+   else
+   tcp_fastopen_disable_path(tp);
+   }
}
/*
 * At this point we are at the initial call. Here we decide
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r336060 - head/usr.sbin/syslogd

2018-07-07 Thread Ed Schouten
Author: ed
Date: Sat Jul  7 11:53:39 2018
New Revision: 336060
URL: https://svnweb.freebsd.org/changeset/base/336060

Log:
  Allow the use of slashes in process names of RFC 3164 formatted messages.
  
  Tools such as Postfix use slashes in process names for hierarchy
  (postfix/qmgr). By allowing these slashes, syslogd is able to extract
  the process name and process ID nicely, so that they can be stored in
  RFC 5424 message fields.
  
  MFC after:1 week

Modified:
  head/usr.sbin/syslogd/syslogd.c

Modified: head/usr.sbin/syslogd/syslogd.c
==
--- head/usr.sbin/syslogd/syslogd.c Sat Jul  7 11:39:20 2018
(r336059)
+++ head/usr.sbin/syslogd/syslogd.c Sat Jul  7 11:53:39 2018
(r336060)
@@ -1120,7 +1120,7 @@ parsemsg_rfc3164_app_name_procid(char **msg, const cha
"abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"0123456789"
-   "_-");
+   "_-/");
if (app_name_length == 0)
goto bad;
m += app_name_length;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r336028 - head/usr.bin/top

2018-07-07 Thread 後藤大地 via svn-src-head

> 2018/07/07 8:53、Hiroki Sato のメール:
> 
> Daichi GOTO  wrote
>  in <201807061207.w66c76cr043...@repo.freebsd.org>:
> 
> da> Author: daichi
> da> Date: Fri Jul  6 12:07:06 2018
> da> New Revision: 336028
> da> URL: https://svnweb.freebsd.org/changeset/base/336028
> da>
> da> Log:
> da>   Changed to eliminate the upper limit of command length displayed
> da>   by "-a" and expand to match terminal width
> da>
> da>   Reviewed by:eadler
> da>   Approved by:gnn (mentor)
> da>   Differential Revision:  https://reviews.freebsd.org/D16083
> da>
> da> Modified:
> da>   head/usr.bin/top/display.c
> da>   head/usr.bin/top/machine.c
> da>   head/usr.bin/top/screen.c
> da>   head/usr.bin/top/top.h
> 
> This change breaks displaying a prompt and messages in the
> interactive mode by new_message() when typing "o" or "p", for
> example.  While r336031 fixed a warning in GCC, it does not fix the
> problem itself.  Please fix it.

OK. I will fix this problem first.


> I also think restructure of the buffer management is required first
> if we want to eliminate the column width limitation.  Using sbuf(9)
> consistently may be better than incomplete conversion from static
> arrays to malloc().

I understand. Switching to sbuf(9) is the next step.

> 
> -- Hiroki

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


svn commit: r336057 - head/sys/netinet

2018-07-07 Thread Michael Tuexen
Author: tuexen
Date: Sat Jul  7 11:18:26 2018
New Revision: 336057
URL: https://svnweb.freebsd.org/changeset/base/336057

Log:
  When initializing the TCP FO client cookie cache, take into account
  whether the TCP FO support is enabled or not for the client side.
  
  The code in tcp_fastopen_init() implicitly assumed that the sysctl
  variable V_tcp_fastopen_client_enable was initialized to 0. This
  was initially true, but was changed in r335610, which unmasked this
  bug.
  
  Thanks to Pieter de Goeje for reporting the issue on freebsd-net@

Modified:
  head/sys/netinet/tcp_fastopen.c

Modified: head/sys/netinet/tcp_fastopen.c
==
--- head/sys/netinet/tcp_fastopen.c Sat Jul  7 01:58:40 2018
(r336056)
+++ head/sys/netinet/tcp_fastopen.c Sat Jul  7 11:18:26 2018
(r336057)
@@ -408,7 +408,13 @@ tcp_fastopen_init(void)
TAILQ_INIT(_tcp_fastopen_ccache.base[i].ccb_entries);
mtx_init(_tcp_fastopen_ccache.base[i].ccb_mtx, 
"tfo_ccache_bucket",
 NULL, MTX_DEF);
-   V_tcp_fastopen_ccache.base[i].ccb_num_entries = -1; /* bucket 
disabled */
+   if (V_tcp_fastopen_client_enable) {
+   /* enable bucket */
+   V_tcp_fastopen_ccache.base[i].ccb_num_entries = 0;
+   } else {
+   /* disable bucket */
+   V_tcp_fastopen_ccache.base[i].ccb_num_entries = -1;
+   }
V_tcp_fastopen_ccache.base[i].ccb_ccache = 
_tcp_fastopen_ccache;
}
 
@@ -824,6 +830,9 @@ sysctl_net_inet_tcp_fastopen_client_enable(SYSCTL_HAND
/* enabled -> disabled */
for (i = 0; i < V_tcp_fastopen_ccache.buckets; i++) {
ccb = _tcp_fastopen_ccache.base[i];
+   KASSERT(ccb->ccb_num_entries > -1,
+   ("%s: ccb->ccb_num_entries %d is negative",
+   __func__, ccb->ccb_num_entries));
tcp_fastopen_ccache_bucket_trim(ccb, 0);
}
V_tcp_fastopen_client_enable = 0;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"