svn commit: r360290 - in stable/11: etc/mtree share/mk share/zoneinfo share/zoneinfo/tests

[Xin LI]

Author: delphij
Date: Sat Apr 25 05:51:58 2020
New Revision: 360290
URL: https://svnweb.freebsd.org/changeset/base/360290

Log:
  MFC r359736: Always install backward compatibility timezones, as they
  are installed on all major Linux distributions as well as NetBSD and
  OpenBSD.

Modified:
  stable/11/etc/mtree/BSD.usr.dist
  stable/11/share/mk/src.opts.mk
  stable/11/share/zoneinfo/Makefile
  stable/11/share/zoneinfo/tests/Makefile
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/etc/mtree/BSD.usr.dist
==
--- stable/11/etc/mtree/BSD.usr.distSat Apr 25 02:18:59 2020
(r360289)
+++ stable/11/etc/mtree/BSD.usr.distSat Apr 25 05:51:58 2020
(r360290)
@@ -1491,15 +1491,25 @@
 ..
 Australia
 ..
+Brazil
+..
+Canada
+..
+Chile
+..
 Etc
 ..
 Europe
 ..
 Indian
 ..
+Mexico
+..
 Pacific
 ..
 SystemV
+..
+US
 ..
 ..
 ..

Modified: stable/11/share/mk/src.opts.mk
==
--- stable/11/share/mk/src.opts.mk  Sat Apr 25 02:18:59 2020
(r360289)
+++ stable/11/share/mk/src.opts.mk  Sat Apr 25 05:51:58 2020
(r360290)
@@ -210,7 +210,6 @@ __DEFAULT_NO_OPTIONS = \
 SORT_THREADS \
 SVN \
 ZONEINFO_LEAPSECONDS_SUPPORT \
-ZONEINFO_OLD_TIMEZONES_SUPPORT \
 
 
 #
@@ -457,7 +456,6 @@ MK_GROFF:=  no
 
 .if ${MK_ZONEINFO} == "no"
 MK_ZONEINFO_LEAPSECONDS_SUPPORT:= no
-MK_ZONEINFO_OLD_TIMEZONES_SUPPORT:= no
 .endif
 
 .if ${MK_CROSS_COMPILER} == "no"

Modified: stable/11/share/zoneinfo/Makefile
==
--- stable/11/share/zoneinfo/Makefile   Sat Apr 25 02:18:59 2020
(r360289)
+++ stable/11/share/zoneinfo/Makefile   Sat Apr 25 05:51:58 2020
(r360290)
@@ -40,11 +40,6 @@ CONTRIBDIR=  ${.CURDIR}/../../contrib/tzdata/
 MK_ZONEINFO_LEAPSECONDS_SUPPORT= yes
 .endif
 
-.if defined(OLDTIMEZONES)
-.warning "Using backwards compatibility variable for OLDTIMEZONES; please use 
WITH_ZONEINFO_OLD_TIMEZONES_SUPPORT instead"
-MK_ZONEINFO_OLD_TIMEZONES_SUPPORT= yes
-.endif
-
 .if ${MK_ZONEINFO_LEAPSECONDS_SUPPORT} != "no"
 LEAPFILE=  -L ${CONTRIBDIR}leapseconds
 .else
@@ -53,12 +48,9 @@ LEAPFILE=
 
 TZFILES=   africa antarctica asia australasia etcetera europe \
factory northamerica southamerica
+TZFILES+=  backward systemv
 POSIXRULES=America/New_York
 
-.if ${MK_ZONEINFO_OLD_TIMEZONES_SUPPORT} != "no"
-TZFILES+=  backward systemv
-.endif
-
 TZFILES:=  ${TZFILES:S/^/${CONTRIBDIR}/}
 
 TZBUILDDIR=${.OBJDIR}/builddir
@@ -78,10 +70,7 @@ TZBUILDSUBDIRS=  \
Indian \
Pacific \
SystemV
-
-.if ${MK_ZONEINFO_OLD_TIMEZONES_SUPPORT} != "no"
 TZBUILDSUBDIRS+= US Mexico Chile Canada Brazil
-.endif
 
 .if !defined(_SKIP_BUILD)
 all: zoneinfo

Modified: stable/11/share/zoneinfo/tests/Makefile
==
--- stable/11/share/zoneinfo/tests/Makefile Sat Apr 25 02:18:59 2020
(r360289)
+++ stable/11/share/zoneinfo/tests/Makefile Sat Apr 25 05:51:58 2020
(r360290)
@@ -8,10 +8,8 @@ PACKAGE=   tests
 
 FILESGROUPS+=  TESTFILES
 
-.if ${MK_ZONEINFO_OLD_TIMEZONES_SUPPORT} != "no"
 ATF_TESTS_SH+= backward_test
 TESTFILES+=backward
-.endif
 
 TESTFILES+=zoneinfo_common.sh
 TESTFILESPACKAGE= ${PACKAGE}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360289 - in head/sys/fs: nfs nfsclient nfsserver

[Rick Macklem]

Author: rmacklem
Date: Sat Apr 25 02:18:59 2020
New Revision: 360289
URL: https://svnweb.freebsd.org/changeset/base/360289

Log:
  Remove Mac OS/X macros that did nothing for FreeBSD.
  
  The macros CAST_USER_ADDR_T() and CAST_DOWN() were used for the Mac OS/X
  port. The first of these macros was a no-op for FreeBSD and the second
  is no longer used.
  This patch gets rid of them. It also deletes the "mbuf_t" typedef which
  is no longer used in the FreeBSD code from nfskpiport.h
  
  This patch should not change semantics.

Modified:
  head/sys/fs/nfs/nfs_commonsubs.c
  head/sys/fs/nfs/nfskpiport.h
  head/sys/fs/nfsclient/nfs_clcomsubs.c
  head/sys/fs/nfsserver/nfs_nfsdport.c

Modified: head/sys/fs/nfs/nfs_commonsubs.c
==
--- head/sys/fs/nfs/nfs_commonsubs.cSat Apr 25 00:57:48 2020
(r360288)
+++ head/sys/fs/nfs/nfs_commonsubs.cSat Apr 25 02:18:59 2020
(r360289)
@@ -652,7 +652,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct uio *ui
if (uiop->uio_segflg == UIO_SYSSPACE)
NFSBCOPY(mbufcp, uiocp, xfer);
else
-   copyout(mbufcp, CAST_USER_ADDR_T(uiocp), xfer);
+   copyout(mbufcp, uiocp, xfer);
left -= xfer;
len -= xfer;
mbufcp += xfer;
@@ -3759,8 +3759,7 @@ nfssvc_idname(struct nfsd_idargs *nidp)
}
if (nidp->nid_flag & NFSID_INITIALIZE) {
cp = malloc(nidp->nid_namelen + 1, M_NFSSTRING, M_WAITOK);
-   error = copyin(CAST_USER_ADDR_T(nidp->nid_name), cp,
-   nidp->nid_namelen);
+   error = copyin(nidp->nid_name, cp, nidp->nid_namelen);
if (error != 0) {
free(cp, M_NFSSTRING);
goto out;
@@ -3856,13 +3855,13 @@ nfssvc_idname(struct nfsd_idargs *nidp)
 */
newusrp = malloc(sizeof(struct nfsusrgrp) + nidp->nid_namelen,
M_NFSUSERGROUP, M_WAITOK | M_ZERO);
-   error = copyin(CAST_USER_ADDR_T(nidp->nid_name), newusrp->lug_name,
+   error = copyin(nidp->nid_name, newusrp->lug_name,
nidp->nid_namelen);
if (error == 0 && nidp->nid_ngroup > 0 &&
(nidp->nid_flag & NFSID_ADDUID) != 0) {
grps = malloc(sizeof(gid_t) * nidp->nid_ngroup, M_TEMP,
M_WAITOK);
-   error = copyin(CAST_USER_ADDR_T(nidp->nid_grps), grps,
+   error = copyin(nidp->nid_grps, grps,
sizeof(gid_t) * nidp->nid_ngroup);
if (error == 0) {
/*

Modified: head/sys/fs/nfs/nfskpiport.h
==
--- head/sys/fs/nfs/nfskpiport.hSat Apr 25 00:57:48 2020
(r360288)
+++ head/sys/fs/nfs/nfskpiport.hSat Apr 25 02:18:59 2020
(r360289)
@@ -43,13 +43,9 @@ typedef struct vnode *   vnode_t;
 #definevnode_mount(v)  ((v)->v_mount)
 #definevnode_vtype(v)  ((v)->v_type)
 
-typedef struct mbuf *  mbuf_t;
-
 /*
  * This stuff is needed by Darwin for handling the uio structure.
  */
-#defineCAST_USER_ADDR_T(a) (a)
-#defineCAST_DOWN(c, a) ((c) (a))
 #defineuio_uio_resid(p)((p)->uio_resid)
 #defineuio_uio_resid_add(p, v) ((p)->uio_resid += (v))
 #defineuio_uio_resid_set(p, v) ((p)->uio_resid = (v))

Modified: head/sys/fs/nfsclient/nfs_clcomsubs.c
==
--- head/sys/fs/nfsclient/nfs_clcomsubs.c   Sat Apr 25 00:57:48 2020
(r360288)
+++ head/sys/fs/nfsclient/nfs_clcomsubs.c   Sat Apr 25 02:18:59 2020
(r360289)
@@ -105,8 +105,7 @@ nfsm_uiombuf(struct nfsrv_descript *nd, struct uio *ui
NFSBCOPY(uiocp, mtod(mp, caddr_t) + mp->m_len,
xfer);
else
-   copyin(CAST_USER_ADDR_T(uiocp), mtod(mp, caddr_t)
-   + mp->m_len, xfer);
+   copyin(uiocp, mtod(mp, caddr_t) + mp->m_len, xfer);
mp->m_len += xfer;
left -= xfer;
uiocp += xfer;

Modified: head/sys/fs/nfsserver/nfs_nfsdport.c
==
--- head/sys/fs/nfsserver/nfs_nfsdport.cSat Apr 25 00:57:48 2020
(r360288)
+++ head/sys/fs/nfsserver/nfs_nfsdport.cSat Apr 25 02:18:59 2020
(r360289)
@@ -3712,8 +3712,7 @@ nfssvc_srvcall(struct thread *p, struct nfssvc_args *u
len = sizeof (struct nfsd_dumpclients) * dumplist.ndl_size;
dumpclients = malloc(len, M_TEMP, 

svn commit: r360288 - head/usr.sbin/bluetooth/hccontrol

[Hans Petter Selasky]

Author: hselasky
Date: Sat Apr 25 00:57:48 2020
New Revision: 360288
URL: https://svnweb.freebsd.org/changeset/base/360288

Log:
  Put advertising data in correct place.
  
  Submitted by: Marc Veldman 
  PR:   245848
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/usr.sbin/bluetooth/hccontrol/le.c

Modified: head/usr.sbin/bluetooth/hccontrol/le.c
==
--- head/usr.sbin/bluetooth/hccontrol/le.c  Sat Apr 25 00:14:17 2020
(r360287)
+++ head/usr.sbin/bluetooth/hccontrol/le.c  Sat Apr 25 00:57:48 2020
(r360288)
@@ -491,6 +491,7 @@ le_set_advertising_data(int s, int argc, char *argv[])
parse_param(argc, argv, buf, );
memset(cp.advertising_data, 0, sizeof(cp.advertising_data));
cp.advertising_data_length = len;
+   memcpy(cp.advertising_data, buf, len);
 
if (hci_request(s, NG_HCI_OPCODE(NG_HCI_OGF_LE,
NG_HCI_OCF_LE_SET_ADVERTISING_DATA), 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360287 - head/usr.sbin/freebsd-update

[Kyle Evans]

Author: kevans
Date: Sat Apr 25 00:14:17 2020
New Revision: 360287
URL: https://svnweb.freebsd.org/changeset/base/360287

Log:
  freebsd-update: rehash certs
  
  With the inclusion of caroot bits, we'll need to also rehash on update as we
  do in mergemaster/etcupdate.
  
  If certctl's installed on the system, just unconditionally rehash. This
  isn't an expensive operation, and we can refine it to compare
  INDEX-{OLD,NEW} later if we really want to.
  
  Reviewed by:  emaste, allanjude
  MFC after:3 days
  Differential Revision:https://reviews.freebsd.org/D21805

Modified:
  head/usr.sbin/freebsd-update/freebsd-update.sh

Modified: head/usr.sbin/freebsd-update/freebsd-update.sh
==
--- head/usr.sbin/freebsd-update/freebsd-update.sh  Fri Apr 24 22:17:13 
2020(r360286)
+++ head/usr.sbin/freebsd-update/freebsd-update.sh  Sat Apr 25 00:14:17 
2020(r360287)
@@ -2876,7 +2876,7 @@ install_delete () {
rm newfiles killfiles
 }
 
-# Install new files, delete old files, and update linker.hints
+# Install new files, delete old files, and update generated files
 install_files () {
# If we haven't already dealt with the kernel, deal with it.
if ! [ -f $1/kerneldone ]; then
@@ -2943,6 +2943,11 @@ Kernel updates have been installed.  Please reboot and
grep -vE '^[^|]*/lib/[^|]*\.so\.[0-9]+\|' > INDEX-NEW
install_from_index INDEX-NEW || return 1
install_delete INDEX-OLD INDEX-NEW || return 1
+
+   # Rehash certs if we actually have certctl installed.
+   if which certctl>/dev/null; then
+   env DESTDIR=${BASEDIR} certctl rehash
+   fi
 
# Rebuild generated pwd files.
if [ ${BASEDIR}/etc/master.passwd -nt ${BASEDIR}/etc/spwd.db ] 
||
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360286 - stable/12/sys/kern

[John Baldwin]

Author: jhb
Date: Fri Apr 24 22:17:13 2020
New Revision: 360286
URL: https://svnweb.freebsd.org/changeset/base/360286

Log:
  MFC 349871: Use 'retval' label for first error in syscallenter().
  
  This is more consistent with the rest of the function and lets us
  unindent most of the function.
  
  Sponsored by: DARPA

Modified:
  stable/12/sys/kern/subr_syscall.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/kern/subr_syscall.c
==
--- stable/12/sys/kern/subr_syscall.c   Fri Apr 24 22:10:02 2020
(r360285)
+++ stable/12/sys/kern/subr_syscall.c   Fri Apr 24 22:17:13 2020
(r360286)
@@ -85,69 +85,68 @@ syscallenter(struct thread *td)
(uintptr_t)td, "pid:%d", td->td_proc->p_pid, "arg0:%p", sa->args[0],
"arg1:%p", sa->args[1], "arg2:%p", sa->args[2]);
 
-   if (error == 0) {
+   if (error != 0)
+   goto retval;
 
-   STOPEVENT(p, S_SCE, sa->narg);
-   if (p->p_flag & P_TRACED) {
-   PROC_LOCK(p);
-   if (p->p_ptevents & PTRACE_SCE)
-   ptracestop((td), SIGTRAP, NULL);
-   PROC_UNLOCK(p);
-   }
-   if (td->td_dbgflags & TDB_USERWR) {
-   /*
-* Reread syscall number and arguments if
-* debugger modified registers or memory.
-*/
-   error = (p->p_sysent->sv_fetch_syscall_args)(td);
+   STOPEVENT(p, S_SCE, sa->narg);
+   if ((p->p_flag & P_TRACED) != 0) {
+   PROC_LOCK(p);
+   if (p->p_ptevents & PTRACE_SCE)
+   ptracestop((td), SIGTRAP, NULL);
+   PROC_UNLOCK(p);
+   }
+   if ((td->td_dbgflags & TDB_USERWR) != 0) {
+   /*
+* Reread syscall number and arguments if debugger
+* modified registers or memory.
+*/
+   error = (p->p_sysent->sv_fetch_syscall_args)(td);
 #ifdef KTRACE
-   if (KTRPOINT(td, KTR_SYSCALL))
-   ktrsyscall(sa->code, sa->narg, sa->args);
+   if (KTRPOINT(td, KTR_SYSCALL))
+   ktrsyscall(sa->code, sa->narg, sa->args);
 #endif
-   if (error != 0)
-   goto retval;
-   }
+   if (error != 0)
+   goto retval;
+   }
 
 #ifdef CAPABILITY_MODE
-   /*
-* In capability mode, we only allow access to system calls
-* flagged with SYF_CAPENABLED.
-*/
-   if (IN_CAPABILITY_MODE(td) &&
-   !(sa->callp->sy_flags & SYF_CAPENABLED)) {
-   error = ECAPMODE;
-   goto retval;
-   }
+   /*
+* In capability mode, we only allow access to system calls
+* flagged with SYF_CAPENABLED.
+*/
+   if (IN_CAPABILITY_MODE(td) &&
+   !(sa->callp->sy_flags & SYF_CAPENABLED)) {
+   error = ECAPMODE;
+   goto retval;
+   }
 #endif
 
-   error = syscall_thread_enter(td, sa->callp);
-   if (error != 0)
-   goto retval;
+   error = syscall_thread_enter(td, sa->callp);
+   if (error != 0)
+   goto retval;
 
 #ifdef KDTRACE_HOOKS
-   /* Give the syscall:::entry DTrace probe a chance to fire. */
-   if (__predict_false(systrace_enabled &&
-   sa->callp->sy_entry != 0))
-   (*systrace_probe_func)(sa, SYSTRACE_ENTRY, 0);
+   /* Give the syscall:::entry DTrace probe a chance to fire. */
+   if (__predict_false(systrace_enabled && sa->callp->sy_entry != 0))
+   (*systrace_probe_func)(sa, SYSTRACE_ENTRY, 0);
 #endif
 
-   AUDIT_SYSCALL_ENTER(sa->code, td);
-   error = (sa->callp->sy_call)(td, sa->args);
-   AUDIT_SYSCALL_EXIT(error, td);
+   AUDIT_SYSCALL_ENTER(sa->code, td);
+   error = (sa->callp->sy_call)(td, sa->args);
+   AUDIT_SYSCALL_EXIT(error, td);
 
-   /* Save the latest error return value. */
-   if ((td->td_pflags & TDP_NERRNO) == 0)
-   td->td_errno = error;
+   /* Save the latest error return value. */
+   if ((td->td_pflags & TDP_NERRNO) == 0)
+   td->td_errno = error;
 
 #ifdef KDTRACE_HOOKS
-   /* Give the syscall:::return DTrace probe a chance to fire. */
-   if (__predict_false(systrace_enabled &&
-   sa->callp->sy_return != 0))
-   (*systrace_probe_func)(sa, SYSTRACE_RETURN,
-   error ? -1 : td->td_retval[0]);
+   /* Give the syscall:::return DTrace probe a 

svn commit: r360285 - head/sys/net80211

[John Baldwin]

Author: jhb
Date: Fri Apr 24 22:10:02 2020
New Revision: 360285
URL: https://svnweb.freebsd.org/changeset/base/360285

Log:
  Don't indirect user pointers directly in two 802.11s ioctls.
  
  IEEE80211_MESH_RTCMD_ADD was invoking memcmp() to validate the
  supplied address directly on the user pointer rather than first doing
  a copyin() and validating the copied value.
  
  IEEE80211_MESH_RTCMD_DELETE was passing the user pointer directly to
  ieee80211_mesh_rt_del() rather than copying the user buffer into a
  temporary kernel buffer.
  
  Reviewed by:  brooks, kib
  Obtained from:CheriBSD
  MFC after:2 weeks
  Sponsored by: DARPA
  Differential Revision:https://reviews.freebsd.org/D24562

Modified:
  head/sys/net80211/ieee80211_mesh.c

Modified: head/sys/net80211/ieee80211_mesh.c
==
--- head/sys/net80211/ieee80211_mesh.c  Fri Apr 24 22:04:14 2020
(r360284)
+++ head/sys/net80211/ieee80211_mesh.c  Fri Apr 24 22:10:02 2020
(r360285)
@@ -3575,16 +3575,21 @@ mesh_ioctl_set80211(struct ieee80211vap *vap, struct i
ieee80211_mesh_rt_flush(vap);
break;
case IEEE80211_MESH_RTCMD_ADD:
-   if (IEEE80211_ADDR_EQ(vap->iv_myaddr, ireq->i_data) ||
-   IEEE80211_ADDR_EQ(broadcastaddr, ireq->i_data))
-   return EINVAL;
-   error = copyin(ireq->i_data, ,
+   error = copyin(ireq->i_data, tmpaddr,
IEEE80211_ADDR_LEN);
-   if (error == 0)
-   ieee80211_mesh_discover(vap, tmpaddr, NULL);
+   if (error != 0)
+   break;
+   if (IEEE80211_ADDR_EQ(vap->iv_myaddr, tmpaddr) ||
+   IEEE80211_ADDR_EQ(broadcastaddr, tmpaddr))
+   return EINVAL;
+   ieee80211_mesh_discover(vap, tmpaddr, NULL);
break;
case IEEE80211_MESH_RTCMD_DELETE:
-   ieee80211_mesh_rt_del(vap, ireq->i_data);
+   error = copyin(ireq->i_data, tmpaddr,
+   IEEE80211_ADDR_LEN);
+   if (error != 0)
+   break;
+   ieee80211_mesh_rt_del(vap, tmpaddr);
break;
default:
return ENOSYS;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360284 - head/lib/libc/sys

[Mateusz Piotrowski]

Author: 0mp (doc,ports committer)
Date: Fri Apr 24 22:04:14 2020
New Revision: 360284
URL: https://svnweb.freebsd.org/changeset/base/360284

Log:
  Fix a typo
  
  Reported by:  pstef
  MFC after:2 days

Modified:
  head/lib/libc/sys/procctl.2

Modified: head/lib/libc/sys/procctl.2
==
--- head/lib/libc/sys/procctl.2 Fri Apr 24 22:02:22 2020(r360283)
+++ head/lib/libc/sys/procctl.2 Fri Apr 24 22:04:14 2020(r360284)
@@ -29,7 +29,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd August 31, 2019
+.Dd April 25, 2020
 .Dt PROCCTL 2
 .Os
 .Sh NAME
@@ -674,7 +674,7 @@ or invalid signal number.
 .Xr dtrace 1 ,
 .Xr proccontrol 1 ,
 .Xr protect 1 ,
-.Xr cap_enter 2,
+.Xr cap_enter 2 ,
 .Xr kill 2 ,
 .Xr ktrace 2 ,
 .Xr mmap 2 ,
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360283 - head/usr.bin/env

[Mateusz Piotrowski]

Author: 0mp (doc,ports committer)
Date: Fri Apr 24 22:02:22 2020
New Revision: 360283
URL: https://svnweb.freebsd.org/changeset/base/360283

Log:
  Fix invalid use of macros and two typos
  
  It turns out that currently mandoc(1) is not handling Fl in Ss
  correctly (maybe it never was). Let's just replace "Fl S \ ..."
  with "-S ...". After all, this subsection title is stylized anyway, so Fl
  is not that helpful.
  
  MFC after:2 weeks

Modified:
  head/usr.bin/env/env.1

Modified: head/usr.bin/env/env.1
==
--- head/usr.bin/env/env.1  Fri Apr 24 21:30:31 2020(r360282)
+++ head/usr.bin/env/env.1  Fri Apr 24 22:02:22 2020(r360283)
@@ -31,7 +31,7 @@
 .\" From FreeBSD: src/usr.bin/printenv/printenv.1,v 1.17 2002/11/26 17:33:35 
ru Exp
 .\" $FreeBSD$
 .\"
-.Dd January 19, 2020
+.Dd April 24, 2020
 .Dt ENV 1
 .Os
 .Sh NAME
@@ -165,7 +165,7 @@ and
 .Ar utility
 may not be specified together.
 .\"
-.Ss Details of Fl S \ (split-string) processing
+.Ss Details of -S (split-string) processing
 The processing of the
 .Fl S
 option will split the given
@@ -292,11 +292,11 @@ processing.
 .Pp
 Also,
 .Fl S
-processing can not reference the value of the special parameters
+processing cannot reference the value of the special parameters
 which are defined by most shells.
 For instance,
 .Fl S
-can not recognize special parameters such as:
+cannot recognize special parameters such as:
 .Ql $* ,
 .Ql $@ ,
 .Ql $# ,
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r360241 - head/sys/dev/ichiic

[John Baldwin]

On 4/24/20 11:48 AM, Andriy Gapon wrote:
> On 24/04/2020 19:23, Justin Hibbits wrote:
>> Can you look at how ofw_iicbus does this?  Everything works just fine
>> with that, and it's compiled into the iicbus module as well.  Perhaps
>> you can pick some ideas from there.
>>
>> One thing I remember doing on the fsl_i2c driver was to just name the
>> driver iichb and everything worked beautifully.  Yes, it was sort of a
>> cop-out vs adding another attachment, but it solved the problem, and
>> does make sense.
> 
> Justin,
> 
> yes, "iichb" is the only name that has special properties because of
> DRIVER_MODULE(iicbus, iichb, ...) in icbus.c.
> That's essentially the same approach that is used for gpio.
> Maybe it's the way.
> But there was something that spooked me about many drivers having the same 
> name,
> but can't recall what.

Drivers can have the same name if they are prepared to handle the same
child devices.  For example, various Host-PCI and PCI-PCI bridge drivers
all use the "pcib" name as they all support having "pci" child devices
and provide the pcib_if methods "pci" bus devices expect their parent
to have, etc.  I suspect in the case of "iichb" the same is true and
that would be fine having all these drivers use the same name and rely
on the description string to differentiate different vendors, etc.

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

svn commit: r360282 - stable/11/sys/netinet

[Michael Tuexen]

Author: tuexen
Date: Fri Apr 24 21:30:31 2020
New Revision: 360282
URL: https://svnweb.freebsd.org/changeset/base/360282

Log:
  Improve the TCP SACK generation by reporting DSACKs
  
  MFC r347382:
  Receiver side DSACK implemenation.
  This adds initial support for RFC 2883.
  
  MFC r347407:
  Don't use C++ style comments.
  
  MFC r349987:
  This is the second in a number of patches needed to
  get BBRv1 into the tree. This fixes the DSACK bug but
  is also needed by BBR. We have yet to go two more
  one will be for the pacing code (tcp_ratelimit.c) and
  the second will be for the new updated LRO code that
  allows a transport to know the arrival times of packets
  and (tcp_lro.c). After that we should finally be able
  to get BBRv1 into head.
  
  MFC r351725:
  This patch improves the DSACK handling to conform with RFC 2883.
  The lowest SACK block is used when multiple Blocks would be elegible as
  DSACK blocks ACK blocks get reordered - while maintaining the ordering of
  SACK blocks not relevant in the DSACK context is maintained.
  
  MFC r351801:
  Fix the SACK block generation in the base TCP stack by bringing it in
  sync with the RACK stack.
  
  MFC r352072:
  Only update SACK/DSACK lists when a non-empty segment was received.
  This fixes hitting a KASSERT with a valid packet exchange.
  
  MFC r352386
  Don't write to memory outside of the allocated array for SACK blocks.
  
  MFC r356796:
  Remove debug code not needed anymore.
  
  MFC r357100:
  The server side of TCP fast open relies on the delayed ACK timer to allow
  including user data in the SYN-ACK. When DSACK support was added in
  r347382, an immediate ACK was sent even for the received SYN with
  user data. This patch fixes that and allows again to send user data with
  the SYN-ACK.
  
  This is joint work of rrs, rscheff, and tuexen.
  
  Differential Revision:https://reviews.freebsd.org/D19334
  Differential Revision:  https://reviews.freebsd.org/D20908
  Differential Revision:  https://reviews.freebsd.org/D21038
  Differential Revision:  https://reviews.freebsd.org/D21513
  Differential Revision:  https://reviews.freebsd.org/D21567
  Differential Revision:  https://reviews.freebsd.org/D23208
  Differential Revision:  https://reviews.freebsd.org/D23212

Modified:
  stable/11/sys/netinet/tcp_input.c
  stable/11/sys/netinet/tcp_output.c
  stable/11/sys/netinet/tcp_sack.c
  stable/11/sys/netinet/tcp_var.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/netinet/tcp_input.c
==
--- stable/11/sys/netinet/tcp_input.c   Fri Apr 24 21:21:49 2020
(r360281)
+++ stable/11/sys/netinet/tcp_input.c   Fri Apr 24 21:30:31 2020
(r360282)
@@ -1539,7 +1539,6 @@ tcp_autorcvbuf(struct mbuf *m, struct tcphdr *th, stru
} else {
tp->rfbuf_cnt += tlen;  /* add up */
}
-
return (newsize);
 }
 
@@ -2307,6 +2306,18 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, stru
TCPSTAT_INC(tcps_rcvpartduppack);
TCPSTAT_ADD(tcps_rcvpartdupbyte, todrop);
}
+   /*
+* DSACK - add SACK block for dropped range
+*/
+   if ((todrop > 0) && (tp->t_flags & TF_SACK_PERMIT)) {
+   tcp_update_sack_list(tp, th->th_seq,
+   th->th_seq + todrop);
+   /*
+* ACK now, as the next in-sequence segment
+* will clear the DSACK block again
+*/
+   tp->t_flags |= TF_ACKNOW;
+   }
drop_hdrlen += todrop;  /* drop from the top afterwards */
th->th_seq += todrop;
tlen -= todrop;
@@ -3035,6 +3046,8 @@ dodata:   
/* XXX */
if ((tlen || (thflags & TH_FIN) || tfo_syn) &&
TCPS_HAVERCVDFIN(tp->t_state) == 0) {
tcp_seq save_start = th->th_seq;
+   tcp_seq save_rnxt  = tp->rcv_nxt;
+   int save_tlen  = tlen;
m_adj(m, drop_hdrlen);  /* delayed header drop */
/*
 * Insert segment which includes th into TCP reassembly queue
@@ -3074,11 +3087,41 @@ dodata: 
/* XXX */
 * m_adj() doesn't actually frees any mbufs
 * when trimming from the head.
 */
-   thflags = tcp_reass(tp, th, _start, , m);
+   tcp_seq temp = save_start;
+   thflags = tcp_reass(tp, th, , , m);
tp->t_flags |= TF_ACKNOW;
}
-   if (tlen > 0 && (tp->t_flags & TF_SACK_PERMIT))
-   tcp_update_sack_list(tp, save_start, save_start + tlen);

svn commit: r360281 - head/sys/mips/mips

[Mark Johnston]

Author: markj
Date: Fri Apr 24 21:21:49 2020
New Revision: 360281
URL: https://svnweb.freebsd.org/changeset/base/360281

Log:
  Fix a race in pmap_emulate_modified().
  
  pmap_emulate_modify() was assuming that no changes to the pmap could
  take place between the TLB signaling the fault and
  pmap_emulate_modify()'s acquisition of the pmap lock, but that's clearly
  not even true in the uniprocessor case, nevermind the SMP case.
  
  Submitted by: Nathaniel Filardo 
  Reviewed by:  kib
  MFC after:2 weeks
  Differential Revision:https://reviews.freebsd.org/D24523

Modified:
  head/sys/mips/mips/pmap.c

Modified: head/sys/mips/mips/pmap.c
==
--- head/sys/mips/mips/pmap.c   Fri Apr 24 21:21:23 2020(r360280)
+++ head/sys/mips/mips/pmap.c   Fri Apr 24 21:21:49 2020(r360281)
@@ -3502,28 +3502,71 @@ pmap_emulate_modified(pmap_t pmap, vm_offset_t va)
 
PMAP_LOCK(pmap);
pte = pmap_pte(pmap, va);
-   if (pte == NULL)
-   panic("pmap_emulate_modified: can't find PTE");
-#ifdef SMP
-   /* It is possible that some other CPU changed m-bit */
-   if (!pte_test(pte, PTE_V) || pte_test(pte, PTE_D)) {
+
+   /*
+* It is possible that some other CPU or thread changed the pmap while
+* we weren't looking; in the SMP case, this is readily apparent, but
+* it can even happen in the UP case, because we may have been blocked
+* on PMAP_LOCK(pmap) above while someone changed this out from
+* underneath us.
+*/
+
+   if (pte == NULL) {
+   /*
+* This PTE's PTP (or one of its ancestors) has been reclaimed;
+* trigger a full fault to reconstruct it via pmap_enter.
+*/
+   PMAP_UNLOCK(pmap);
+   return (1);
+   }
+
+   if (!pte_test(pte, PTE_V)) {
+   /*
+* This PTE is no longer valid; the other thread or other
+* processor must have arranged for our TLB to no longer
+* have this entry, possibly by IPI, so no tlb_update is
+* required.  Fall out of the fast path and go take a
+* general fault before retrying the instruction (or taking
+* a signal).
+*/
+   PMAP_UNLOCK(pmap);
+   return (1);
+   }
+
+   if (pte_test(pte, PTE_D)) {
+   /*
+* This PTE is valid and has the PTE_D bit asserted; since
+* this is an increase in permission, we may have been expected
+* to update the TLB lazily.  Do so here and return, on the
+* fast path, to retry the instruction.
+*/
tlb_update(pmap, va, *pte);
PMAP_UNLOCK(pmap);
return (0);
}
-#else
-   if (!pte_test(pte, PTE_V) || pte_test(pte, PTE_D))
-   panic("pmap_emulate_modified: invalid pte");
-#endif
+
if (pte_test(pte, PTE_RO)) {
+   /*
+* This PTE is valid, not dirty, and read-only.  Go take a
+* full fault (most likely to upgrade this part of the address
+* space to writeable).
+*/
PMAP_UNLOCK(pmap);
return (1);
}
-   pte_set(pte, PTE_D);
-   tlb_update(pmap, va, *pte);
+
if (!pte_test(pte, PTE_MANAGED))
panic("pmap_emulate_modified: unmanaged page");
+
+   /*
+* PTE is valid, managed, not dirty, and not read-only.  Set PTE_D
+* and eagerly update the local TLB, returning on the fast path.
+*/
+
+   pte_set(pte, PTE_D);
+   tlb_update(pmap, va, *pte);
PMAP_UNLOCK(pmap);
+
return (0);
 }
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360280 - head/sys/mips/mips

[Mark Johnston]

Author: markj
Date: Fri Apr 24 21:21:23 2020
New Revision: 360280
URL: https://svnweb.freebsd.org/changeset/base/360280

Log:
  Fix a race between _pmap_unwire_ptp() and MipsDoTLBMiss().
  
  MipsDoTLBMiss() will load a segmap entry or pde, check that it isn't
  zero, and then chase that pointer to a physical page. If that page has
  been freed in the interim, it will read garbage and go on to populate
  the TLB with it.
  
  This can happen because pmap_unwire_ptp zeros out the pde and
  vm_page_free_zero()s the ptp (or, recursively, zeros out the segmap
  entry and vm_page_free_zero()s the pdp) without interlocking against
  MipsDoTLBMiss(). The pmap is locked, and pvh_global_lock may or may not
  be held, but this is not enough. Solve this issue by inserting TLB
  shootdowns within _pmap_unwire_ptp(); as MipsDoTLBMiss() runs with IRQs
  deferred, the IPIs involved in TLB shootdown are sufficient to ensure
  that MipsDoTLBMiss() sees either a zero segmap entry / pde or a non-zero
  entry and the pointed-to page still not freed.
  
  Submitted by: Nathaniel Filardo 
  Reviewed by:  kib
  MFC after:2 weeks
  Differential Revision:https://reviews.freebsd.org/D24491

Modified:
  head/sys/mips/mips/pmap.c

Modified: head/sys/mips/mips/pmap.c
==
--- head/sys/mips/mips/pmap.c   Fri Apr 24 19:43:07 2020(r360279)
+++ head/sys/mips/mips/pmap.c   Fri Apr 24 21:21:23 2020(r360280)
@@ -1004,18 +1004,26 @@ static void
 _pmap_unwire_ptp(pmap_t pmap, vm_offset_t va, vm_page_t m)
 {
pd_entry_t *pde;
+   vm_offset_t sva, eva;
 
PMAP_LOCK_ASSERT(pmap, MA_OWNED);
/*
 * unmap the page table page
 */
 #ifdef __mips_n64
-   if (m->pindex < NUPDE)
+   if (m->pindex < NUPDE) {
pde = pmap_pde(pmap, va);
-   else
+   sva = va & ~PDRMASK;
+   eva = sva + NBPDR;
+   } else {
pde = pmap_segmap(pmap, va);
+   sva = va & ~SEGMASK;
+   eva = sva + NBSEG;
+   }
 #else
pde = pmap_pde(pmap, va);
+   sva = va & ~SEGMASK;
+   eva = sva + NBSEG;
 #endif
*pde = 0;
pmap->pm_stats.resident_count--;
@@ -1026,12 +1034,22 @@ _pmap_unwire_ptp(pmap_t pmap, vm_offset_t va, vm_page_
vm_page_t pdpg;
 
/*
-* Recursively decrement next level pagetable refcount
+* Recursively decrement next level pagetable refcount.
+* Either that shoots down a larger range from TLBs (below)
+* or we're to shoot down just the page in question.
 */
pdp = (pd_entry_t *)*pmap_segmap(pmap, va);
pdpg = PHYS_TO_VM_PAGE(MIPS_DIRECT_TO_PHYS(pdp));
-   pmap_unwire_ptp(pmap, va, pdpg);
+   if (!pmap_unwire_ptp(pmap, va, pdpg)) {
+   pmap_invalidate_range(pmap, sva, eva);
+   }
+   } else {
+   /* Segmap entry shootdown */
+   pmap_invalidate_range(pmap, sva, eva);
}
+#else
+   /* Segmap entry shootdown */
+   pmap_invalidate_range(pmap, sva, eva);
 #endif
 
/*
@@ -1485,7 +1503,15 @@ pmap_pv_reclaim(pmap_t locked_pmap)
if (TAILQ_EMPTY(>md.pv_list))
vm_page_aflag_clear(m, PGA_WRITEABLE);
pc->pc_map[field] |= 1UL << bit;
-   pmap_unuse_pt(pmap, va, *pde);
+
+   /*
+* For simplicity, we will unconditionally shoot
+* down TLBs either at the end of this function
+* or at the top of the loop above if we switch
+* to a different pmap.
+*/
+   (void)pmap_unuse_pt(pmap, va, *pde);
+
freed++;
}
}
@@ -1714,6 +1740,23 @@ pmap_try_insert_pv_entry(pmap_t pmap, vm_page_t mpte, 
 
 /*
  * pmap_remove_pte: do the things to unmap a page in a process
+ *
+ * Returns true if this was the last PTE in the PT (and possibly the last PT in
+ * the PD, and possibly the last PD in the segmap), in which case...
+ *
+ *   1) the TLB has been invalidated for the whole PT's span (at least),
+ *   already, to ensure that MipsDoTLBMiss does not attempt to follow a
+ *   dangling pointer into a freed page.  No additional TLB shootdown is
+ *   required.
+ *
+ *   2) if this removal was part of a sweep to remove PTEs, it is safe to jump
+ *   to the PT span boundary and continue.
+ *
+ *   3) The given pde may now point onto a freed page and must not be
+ *   dereferenced
+ *
+ * If the return value is false, the TLB has not been shot down (and the segmap
+ * entry, PD, and PT all 

svn commit: r360279 - stable/11/sys/geom

[Alexander Motin]

Author: mav
Date: Fri Apr 24 19:43:07 2020
New Revision: 360279
URL: https://svnweb.freebsd.org/changeset/base/360279

Log:
  MFC r323977 (by cem): g_resize_provider_event: Do not invoke orphan method 
twice
  
  Like r266444, g_resize_provider_event can attempt to orphan an already
  orphaned geom_dev consumer.  This will cause a panic in g_dev_orphan.  Apply
  the same fix as was applied to g_orphan_register.

Modified:
  stable/11/sys/geom/geom_subr.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/geom/geom_subr.c
==
--- stable/11/sys/geom/geom_subr.c  Fri Apr 24 19:03:18 2020
(r360278)
+++ stable/11/sys/geom/geom_subr.c  Fri Apr 24 19:43:07 2020
(r360279)
@@ -627,6 +627,14 @@ g_resize_provider_event(void *arg, int flag)
LIST_FOREACH_SAFE(cp, >consumers, consumers, cp2) {
gp = cp->geom;
if (gp->resize == NULL && size < pp->mediasize) {
+   /*
+* XXX: g_dev_orphan method does deferred destroying
+* and it is possible, that other event could already
+* call the orphan method. Check consumer's flags to
+* do not schedule it twice.
+*/
+   if (cp->flags & G_CF_ORPHAN)
+   continue;
cp->flags |= G_CF_ORPHAN;
cp->geom->orphan(cp);
}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360278 - in stable/12: crypto/openssl crypto/openssl/apps crypto/openssl/crypto/aes crypto/openssl/crypto/asn1 crypto/openssl/crypto/bio crypto/openssl/crypto/ec crypto/openssl/crypto/...

[Jung-uk Kim]

Author: jkim
Date: Fri Apr 24 19:03:18 2020
New Revision: 360278
URL: https://svnweb.freebsd.org/changeset/base/360278

Log:
  MFC:  r360175
  
  Merge OpenSSL 1.1.1g.

Added:
  stable/12/crypto/openssl/doc/man3/X509_check_purpose.pod
 - copied unchanged from r360175, 
head/crypto/openssl/doc/man3/X509_check_purpose.pod
  stable/12/secure/lib/libcrypto/man/man3/X509_check_purpose.3
 - copied unchanged from r360175, 
head/secure/lib/libcrypto/man/man3/X509_check_purpose.3
Modified:
  stable/12/crypto/openssl/CHANGES
  stable/12/crypto/openssl/INSTALL
  stable/12/crypto/openssl/NEWS
  stable/12/crypto/openssl/README
  stable/12/crypto/openssl/apps/build.info
  stable/12/crypto/openssl/apps/dhparam.c
  stable/12/crypto/openssl/apps/dsa.c
  stable/12/crypto/openssl/apps/dsaparam.c
  stable/12/crypto/openssl/apps/ec.c
  stable/12/crypto/openssl/apps/ecparam.c
  stable/12/crypto/openssl/apps/engine.c
  stable/12/crypto/openssl/apps/gendsa.c
  stable/12/crypto/openssl/apps/genrsa.c
  stable/12/crypto/openssl/apps/ocsp.c
  stable/12/crypto/openssl/apps/pkcs12.c
  stable/12/crypto/openssl/apps/rsa.c
  stable/12/crypto/openssl/apps/rsautl.c
  stable/12/crypto/openssl/apps/s_time.c
  stable/12/crypto/openssl/apps/srp.c
  stable/12/crypto/openssl/apps/ts.c
  stable/12/crypto/openssl/crypto/aes/aes_core.c
  stable/12/crypto/openssl/crypto/aes/aes_local.h
  stable/12/crypto/openssl/crypto/asn1/asn1_lib.c
  stable/12/crypto/openssl/crypto/bio/bss_acpt.c
  stable/12/crypto/openssl/crypto/ec/ec_asn1.c
  stable/12/crypto/openssl/crypto/ec/ec_lib.c
  stable/12/crypto/openssl/crypto/ec/ec_mult.c
  stable/12/crypto/openssl/crypto/ec/ecp_smpl.c
  stable/12/crypto/openssl/crypto/evp/e_aes.c
  stable/12/crypto/openssl/crypto/rand/build.info
  stable/12/crypto/openssl/crypto/rand/drbg_ctr.c
  stable/12/crypto/openssl/crypto/x509/x509_vfy.c
  stable/12/crypto/openssl/crypto/x509v3/v3_purp.c
  stable/12/crypto/openssl/doc/man1/s_time.pod
  stable/12/crypto/openssl/doc/man3/EVP_aes.pod
  stable/12/crypto/openssl/doc/man3/RAND_set_rand_method.pod
  stable/12/crypto/openssl/include/openssl/opensslv.h
  stable/12/secure/lib/libcrypto/Makefile.inc
  stable/12/secure/lib/libcrypto/man/man3/ADMISSIONS.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_INTEGER_get_int64.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_ITEM_lookup.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_OBJECT_new.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_STRING_TABLE_add.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_STRING_length.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_STRING_new.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_STRING_print_ex.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_TIME_set.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_TYPE_get.3
  stable/12/secure/lib/libcrypto/man/man3/ASN1_generate_nconf.3
  stable/12/secure/lib/libcrypto/man/man3/ASYNC_WAIT_CTX_new.3
  stable/12/secure/lib/libcrypto/man/man3/ASYNC_start_job.3
  stable/12/secure/lib/libcrypto/man/man3/BF_encrypt.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_ADDR.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_ADDRINFO.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_connect.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_ctrl.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_f_base64.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_f_buffer.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_f_cipher.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_f_md.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_f_null.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_f_ssl.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_find_type.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_get_data.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_get_ex_new_index.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_meth_new.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_new.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_new_CMS.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_parse_hostserv.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_printf.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_push.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_read.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_s_accept.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_s_bio.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_s_connect.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_s_fd.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_s_file.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_s_mem.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_s_null.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_s_socket.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_set_callback.3
  stable/12/secure/lib/libcrypto/man/man3/BIO_should_retry.3
  stable/12/secure/lib/libcrypto/man/man3/BN_BLINDING_new.3
  stable/12/secure/lib/libcrypto/man/man3/BN_CTX_new.3
  stable/12/secure/lib/libcrypto/man/man3/BN_CTX_start.3
  stable/12/secure/lib/libcrypto/man/man3/BN_add.3
  stable/12/secure/lib/libcrypto/man/man3/BN_add_word.3
  

Re: svn commit: r360241 - head/sys/dev/ichiic

[Andriy Gapon]

On 24/04/2020 19:23, Justin Hibbits wrote:
> Can you look at how ofw_iicbus does this?  Everything works just fine
> with that, and it's compiled into the iicbus module as well.  Perhaps
> you can pick some ideas from there.
> 
> One thing I remember doing on the fsl_i2c driver was to just name the
> driver iichb and everything worked beautifully.  Yes, it was sort of a
> cop-out vs adding another attachment, but it solved the problem, and
> does make sense.

Justin,

yes, "iichb" is the only name that has special properties because of
DRIVER_MODULE(iicbus, iichb, ...) in icbus.c.
That's essentially the same approach that is used for gpio.
Maybe it's the way.
But there was something that spooked me about many drivers having the same name,
but can't recall what.

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

svn commit: r360277 - head/sys/arm64/arm64

[Mark Johnston]

Author: markj
Date: Fri Apr 24 18:47:57 2020
New Revision: 360277
URL: https://svnweb.freebsd.org/changeset/base/360277

Log:
  Fix handling of 1GB mappings in the arm64 minidump code.
  
  For such mappings we need to dump 512 page table pages, not one, and
  they need to be included in the pmap size recorded in the minidump
  header.
  
  MFC after:2 weeks
  Sponsored by: Juniper Networks, Klara Inc.

Modified:
  head/sys/arm64/arm64/minidump_machdep.c

Modified: head/sys/arm64/arm64/minidump_machdep.c
==
--- head/sys/arm64/arm64/minidump_machdep.c Fri Apr 24 18:47:42 2020
(r360276)
+++ head/sys/arm64/arm64/minidump_machdep.c Fri Apr 24 18:47:57 2020
(r360277)
@@ -34,8 +34,6 @@ __FBSDID("$FreeBSD$");
 
 #include "opt_watchdog.h"
 
-#include "opt_watchdog.h"
-
 #include 
 #include 
 #include 
@@ -68,7 +66,7 @@ static size_t fragsz;
 static void *dump_va;
 static size_t counter, progress, dumpsize;
 
-static uint64_t tmpbuffer[PAGE_SIZE / sizeof(uint64_t)];
+static uint64_t tmpbuffer[Ln_ENTRIES];
 
 CTASSERT(sizeof(*vm_page_dump) == 8);
 
@@ -210,16 +208,14 @@ blk_write(struct dumperinfo *di, char *ptr, vm_paddr_t
 int
 minidumpsys(struct dumperinfo *di)
 {
+   struct minidumphdr mdhdr;
pd_entry_t *l0, *l1, *l2;
pt_entry_t *l3;
-   uint32_t pmapsize;
vm_offset_t va;
vm_paddr_t pa;
-   int error;
uint64_t bits;
-   int i, bit;
-   int retry_count;
-   struct minidumphdr mdhdr;
+   uint32_t pmapsize;
+   int bit, error, i, j, retry_count;
 
retry_count = 0;
  retry:
@@ -231,11 +227,15 @@ minidumpsys(struct dumperinfo *di)
if (!pmap_get_tables(pmap_kernel(), va, , , , ))
continue;
 
-   /* We should always be using the l2 table for kvm */
-   if (l2 == NULL)
-   continue;
-
-   if ((*l2 & ATTR_DESCR_MASK) == L2_BLOCK) {
+   if ((*l1 & ATTR_DESCR_MASK) == L1_BLOCK) {
+   pa = *l1 & ~ATTR_MASK;
+   for (i = 0; i < Ln_ENTRIES * Ln_ENTRIES;
+   i++, pa += PAGE_SIZE)
+   if (is_dumpable(pa))
+   dump_add_page(pa);
+   pmapsize += (Ln_ENTRIES - 1) * PAGE_SIZE;
+   va += L1_SIZE - L2_SIZE;
+   } else if ((*l2 & ATTR_DESCR_MASK) == L2_BLOCK) {
pa = *l2 & ~ATTR_MASK;
for (i = 0; i < Ln_ENTRIES; i++, pa += PAGE_SIZE) {
if (is_dumpable(pa))
@@ -327,25 +327,31 @@ minidumpsys(struct dumperinfo *di)
error = blk_flush(di);
if (error)
goto fail;
-   } else if (l2 == NULL) {
+   } else if ((*l1 & ATTR_DESCR_MASK) == L1_BLOCK) {
+   /*
+* Handle a 1GB block mapping: write out 512 fake L2
+* pages.
+*/
pa = (*l1 & ~ATTR_MASK) | (va & L1_OFFSET);
 
-   /* Generate fake l3 entries based upon the l1 entry */
for (i = 0; i < Ln_ENTRIES; i++) {
-   tmpbuffer[i] = pa + (i * PAGE_SIZE) |
-   ATTR_DEFAULT | L3_PAGE;
+   for (j = 0; j < Ln_ENTRIES; j++) {
+   tmpbuffer[j] = pa + i * L2_SIZE +
+   j * PAGE_SIZE | ATTR_DEFAULT |
+   L3_PAGE;
+   }
+   error = blk_write(di, (char *), 0,
+   PAGE_SIZE);
+   if (error)
+   goto fail;
}
-   /* We always write a page, even if it is zero */
-   error = blk_write(di, (char *), 0, PAGE_SIZE);
-   if (error)
-   goto fail;
/* flush, in case we reuse tmpbuffer in the same block*/
error = blk_flush(di);
if (error)
goto fail;
bzero(, sizeof(tmpbuffer));
+   va += L1_SIZE - L2_SIZE;
} else if ((*l2 & ATTR_DESCR_MASK) == L2_BLOCK) {
-   /* TODO: Handle an invalid L2 entry */
pa = (*l2 & ~ATTR_MASK) | (va & L2_OFFSET);
 
/* Generate fake l3 entries based upon the l1 entry */
@@ -353,7 +359,6 @@ minidumpsys(struct dumperinfo *di)
tmpbuffer[i] = pa + (i * PAGE_SIZE) |
   

svn commit: r360276 - in head/sys: amd64/amd64 arm64/arm64 i386/i386 powerpc/powerpc

[Mark Johnston]

Author: markj
Date: Fri Apr 24 18:47:42 2020
New Revision: 360276
URL: https://svnweb.freebsd.org/changeset/base/360276

Log:
  Remove an obsolete TODO comment from several minidump implementations.
  
  The comment referenced a non-existent function, and these minidump
  implementations already buffer discontiguous physical data pages by
  mapping them into a single VA range that gets passed to the dump device,
  so there is no real advantage in batching calls to blk_write().
  
  The RISC-V and MIPS minidump implementations still write a page at a
  time and so would benefit from some form of batching.
  
  MFC after:2 weeks
  Sponsored by: Juniper Networks, Klara Inc.

Modified:
  head/sys/amd64/amd64/minidump_machdep.c
  head/sys/arm64/arm64/minidump_machdep.c
  head/sys/i386/i386/minidump_machdep_base.c
  head/sys/powerpc/powerpc/minidump_machdep.c

Modified: head/sys/amd64/amd64/minidump_machdep.c
==
--- head/sys/amd64/amd64/minidump_machdep.c Fri Apr 24 16:40:42 2020
(r360275)
+++ head/sys/amd64/amd64/minidump_machdep.c Fri Apr 24 18:47:42 2020
(r360276)
@@ -409,7 +409,6 @@ minidumpsys(struct dumperinfo *di)
}
 
/* Dump memory chunks */
-   /* XXX cluster it up and use blk_dump() */
for (i = 0; i < vm_page_dump_size / sizeof(*vm_page_dump); i++) {
bits = vm_page_dump[i];
while (bits) {

Modified: head/sys/arm64/arm64/minidump_machdep.c
==
--- head/sys/arm64/arm64/minidump_machdep.c Fri Apr 24 16:40:42 2020
(r360275)
+++ head/sys/arm64/arm64/minidump_machdep.c Fri Apr 24 18:47:42 2020
(r360276)
@@ -374,7 +374,6 @@ minidumpsys(struct dumperinfo *di)
}
 
/* Dump memory chunks */
-   /* XXX cluster it up and use blk_dump() */
for (i = 0; i < vm_page_dump_size / sizeof(*vm_page_dump); i++) {
bits = vm_page_dump[i];
while (bits) {

Modified: head/sys/i386/i386/minidump_machdep_base.c
==
--- head/sys/i386/i386/minidump_machdep_base.c  Fri Apr 24 16:40:42 2020
(r360275)
+++ head/sys/i386/i386/minidump_machdep_base.c  Fri Apr 24 18:47:42 2020
(r360276)
@@ -321,7 +321,6 @@ minidumpsys(struct dumperinfo *di)
}
 
/* Dump memory chunks */
-   /* XXX cluster it up and use blk_dump() */
for (i = 0; i < vm_page_dump_size / sizeof(*vm_page_dump); i++) {
bits = vm_page_dump[i];
while (bits) {

Modified: head/sys/powerpc/powerpc/minidump_machdep.c
==
--- head/sys/powerpc/powerpc/minidump_machdep.c Fri Apr 24 16:40:42 2020
(r360275)
+++ head/sys/powerpc/powerpc/minidump_machdep.c Fri Apr 24 18:47:42 2020
(r360276)
@@ -381,7 +381,6 @@ retry:
dump_total("pmap", pmapsize);
 
/* Dump memory chunks */
-   /* XXX cluster it up and use blk_dump() */
for (i = 0; i < vm_page_dump_size / sizeof(*vm_page_dump); i++) {
bits = vm_page_dump[i];
/* TODO optimize with bit manipulation instructions */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r360241 - head/sys/dev/ichiic

[John Baldwin]

On 4/24/20 9:57 AM, Warner Losh wrote:
> On Fri, Apr 24, 2020 at 10:07 AM Andriy Gapon  wrote:
>> Let's use ig4 as an example.
>> Across its source files we had the following DRIVER_MODULE declarations:
>> DRIVER_MODULE(ig4iic, acpi, ... -- in ig4_acpi.c
>> DRIVER_MODULE(iicbus, ig4iic, ... -- in ig4_iic.c
>> DRIVER_MODULE(acpi_iicbus, ig4iic, ... -- in ig4_iic.c
>> The first one is needed to register ig4iic driver under acpi bus.  Other
>> two are
>> needed to register iicbus and acpi_iicbus drivers under ig4iic bus.
>> The order is not explicitly defined, so the corresponding declaration can
>> be
>> processed in any order when ig4.ko is loaded and so the corresponding
>> devclass_add_driver() can be called in any order.
>>
> 
> It's a bug in newbus if that matters. I'll grant that it does today, but it
> shouldn't. In the past we've worked around this issue in a number of
> different ways (including having 3 different modules with the order encoded
> into those modules). It also indicates, perhaps, bugs in the iic acpi
> enumeration stuff, but that's a harder case to make without more careful
> study since I know that acpi_iic works around the bit of a mismatch between
> newbus' device model and ACPI's.

FWIW, this is a longstanding bug, and it is the reason DRIVER_MODULE_ORDERED
exists[1], precisely so you can get all the child driver module's registered 
first
and have the "top-most" (in the hierarchy) driver register last so that all
the others are ready as new child devices are created.  The _ORDERED solution
is the only one I'm aware of that we have used for a single module containing
multiple drivers.  It may be that we have split up into tiny modules in the
past, but that solution is probably worse as the dependencies are usually
the wrong way around (the "leaf" drivers probably depend on the parent drivers
so they get loaded in the exact wrong order for this case where you want all
the leaf drivers registered before an instance of the parent driver attaches)

1: https://svnweb.freebsd.org/base?view=revision=225079

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

Re: svn commit: r360241 - head/sys/dev/ichiic

[Warner Losh]

On Fri, Apr 24, 2020 at 10:07 AM Andriy Gapon  wrote:

> On 24/04/2020 18:11, Warner Losh wrote:
> >
> >
> > On Fri, Apr 24, 2020 at 8:47 AM Andriy Gapon  > > wrote:
> >
> > On 24/04/2020 17:29, Warner Losh wrote:
> > >
> > >
> > > On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  > 
> > > >> wrote:
> > >
> > > Author: avg
> > > Date: Fri Apr 24 07:49:21 2020
> > > New Revision: 360241
> > > URL: https://svnweb.freebsd.org/changeset/base/360241
> > >
> > > Log:
> > >   ig4: ensure that drivers always attach in correct order
> > >
> > >   Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI
> attachment
> > >   happens after iicbus and acpi_iicbus drivers are registered.
> > >
> > >   I have seen a problem where iicbus attached under ig4
> instead of
> > >   acpi_iicbus when ig4.ko was loaded with kldload.  I believe
> that that
> > >   happened because ig4 driver was a first driver to register,
> it attached
> > >   and created an iicbus child.  Then iicbus driver was
> registered and,
> > >   since it was the only driver that could attach to the iicbus
> child
> > >   device, it did exactly that.  After that acpi_iicbus driver
> was
> > >   registered.  It would be able to attach to the iicbus
> device, but it was
> > >   already attached, so nothing happened.
> > >
> > >
> > > Can you post more details of which devices are affected? From the
> description
> > > and the patch, I don't see how this could fix things.
> >
> > I think I listed them all: ig4iic with acpi attachment, iicbus and
> acpi_iicbus.
> > acpi
> >  \--- ig4iic
> >\ iicbus vs acpi_iicbus
> >
> > I tried to explain the problem and the fix in the commit message.
> If you want
> > to discuss any specifics, let's continue with specifics.  If there
> is anything
> > unclear in my explanation, I can clarify, but I need to understand
> what needs to
> > be clarified.
> >
> >
> > That won't fix the stated problem.
>
> It will.  It does.  You made me write an essay to explain why :)
>

Ah, it's a workaround for a newbus bug. OK. I'll work on fixing the newbus
bug then.


> > If changing the module order fixes something,
> > it's the wrong fix. Which is why I asked to make sure I understood the
> issue (it
> > was unclear if it was at the level indicated, or for the children of the
> iicbus).
> >
> > iicbus returns BUS_PROBE_GENERIC (-100) from its probe routine, while
> > acpi_iicbus returns BUS_PROBE_DEFAULT (-20). This means that acpi_iicbus
> should
> > always win. So something else is going on. We don't specify order on
> other
> > devices except for some weird, special needs drivers (this is not such a
> driver).
>
> This driver, along with all of other I2C controller drivers, has a
> particular
> quirk, so it can be called weird.
>
> It does not matter what the probe routines return if one of the drivers is
> not
> added to "newbus" at all (even if its code is loaded).  Its probe method
> is not
> executed.  And that's what I tried to explain in the commit message.
>
> Now, why this driver as well as all SMBus and I2C controller drivers are
> somewhat weird...  There is a multitude of drivers for SMBus and I2C
> controllers.  Those drivers have different names.  So, using newbus speak,
> smbus
> and iicbus drivers can attach to [newbus] devices under many different
> [newbus]
> buses.  For that reason, the corresponding DRIVER_MODULE declarations are
> not
> consolidated in smbus.c and iicbus.c; instead, they are spread over
> individual
> controller drivers.  So, loading of smbus or iicbus module does not result
> in a
> call to devclass_add_driver() that would register these drivers under some
> bus.
> And that's an unusual thing comparing to the most straightforward drivers.
>
> Let's use ig4 as an example.
> Across its source files we had the following DRIVER_MODULE declarations:
> DRIVER_MODULE(ig4iic, acpi, ... -- in ig4_acpi.c
> DRIVER_MODULE(iicbus, ig4iic, ... -- in ig4_iic.c
> DRIVER_MODULE(acpi_iicbus, ig4iic, ... -- in ig4_iic.c
> The first one is needed to register ig4iic driver under acpi bus.  Other
> two are
> needed to register iicbus and acpi_iicbus drivers under ig4iic bus.
> The order is not explicitly defined, so the corresponding declaration can
> be
> processed in any order when ig4.ko is loaded and so the corresponding
> devclass_add_driver() can be called in any order.
>

It's a bug in newbus if that matters. I'll grant that it does today, but it
shouldn't. In the past we've worked around this issue in a number of
different ways (including having 3 different modules with the order encoded
into those modules). It also indicates, perhaps, bugs in the iic acpi
enumeration stuff, but that's a 

svn commit: r360275 - stable/11/sys/dev/pci

[Alexander Motin]

Author: mav
Date: Fri Apr 24 16:40:42 2020
New Revision: 360275
URL: https://svnweb.freebsd.org/changeset/base/360275

Log:
  MFC r351514: Don't consider PCIe hot-plug command timeout fatal.
  
  According to my tests and errata to several generations of Intel CPUs,
  PCIe hot-plug command completion reporting is not very reliable thing.
  At least on my Supermicro X11DPi-NT board I never saw it reported.
  Before this change timeout code detached devices and tried to disable
  the slot, that in my case resulted in hot-plugged device being detached
  just a second after it was successfully detected and attached.  This
  change removes that, so in case of timeout it just prints the error and
  continue operation.  Linux does the same.

Modified:
  stable/11/sys/dev/pci/pci_pci.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/dev/pci/pci_pci.c
==
--- stable/11/sys/dev/pci/pci_pci.c Fri Apr 24 16:39:34 2020
(r360274)
+++ stable/11/sys/dev/pci/pci_pci.c Fri Apr 24 16:40:42 2020
(r360275)
@@ -1253,11 +1253,8 @@ pcib_pcie_cc_timeout(void *arg)
mtx_assert(, MA_OWNED);
sta = pcie_read_config(dev, PCIER_SLOT_STA, 2);
if (!(sta & PCIEM_SLOT_STA_CC)) {
-   device_printf(dev,
-   "HotPlug Command Timed Out - forcing detach\n");
-   sc->flags &= ~(PCIB_HOTPLUG_CMD_PENDING | PCIB_DETACH_PENDING);
-   sc->flags |= PCIB_DETACHING;
-   pcib_pcie_hotplug_update(sc, 0, 0, true);
+   device_printf(dev, "HotPlug Command Timed Out\n");
+   sc->flags &= ~PCIB_HOTPLUG_CMD_PENDING;
} else {
device_printf(dev,
"Missed HotPlug interrupt waiting for Command Completion\n");
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360274 - stable/12/sys/dev/pci

[Alexander Motin]

Author: mav
Date: Fri Apr 24 16:39:34 2020
New Revision: 360274
URL: https://svnweb.freebsd.org/changeset/base/360274

Log:
  MFC r351514: Don't consider PCIe hot-plug command timeout fatal.
  
  According to my tests and errata to several generations of Intel CPUs,
  PCIe hot-plug command completion reporting is not very reliable thing.
  At least on my Supermicro X11DPi-NT board I never saw it reported.
  Before this change timeout code detached devices and tried to disable
  the slot, that in my case resulted in hot-plugged device being detached
  just a second after it was successfully detected and attached.  This
  change removes that, so in case of timeout it just prints the error and
  continue operation.  Linux does the same.

Modified:
  stable/12/sys/dev/pci/pci_pci.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/dev/pci/pci_pci.c
==
--- stable/12/sys/dev/pci/pci_pci.c Fri Apr 24 16:33:07 2020
(r360273)
+++ stable/12/sys/dev/pci/pci_pci.c Fri Apr 24 16:39:34 2020
(r360274)
@@ -1269,11 +1269,8 @@ pcib_pcie_cc_timeout(void *arg)
mtx_assert(, MA_OWNED);
sta = pcie_read_config(dev, PCIER_SLOT_STA, 2);
if (!(sta & PCIEM_SLOT_STA_CC)) {
-   device_printf(dev,
-   "HotPlug Command Timed Out - forcing detach\n");
-   sc->flags &= ~(PCIB_HOTPLUG_CMD_PENDING | PCIB_DETACH_PENDING);
-   sc->flags |= PCIB_DETACHING;
-   pcib_pcie_hotplug_update(sc, 0, 0, true);
+   device_printf(dev, "HotPlug Command Timed Out\n");
+   sc->flags &= ~PCIB_HOTPLUG_CMD_PENDING;
} else {
device_printf(dev,
"Missed HotPlug interrupt waiting for Command Completion\n");
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360273 - head/release/arm64

[Emmanuel Vadot]

Author: manu
Date: Fri Apr 24 16:33:07 2020
New Revision: 360273
URL: https://svnweb.freebsd.org/changeset/base/360273

Log:
  Add PINE64 ROCK64 config for generation of release images

Added:
  head/release/arm64/ROCK64.conf   (contents, props changed)

Added: head/release/arm64/ROCK64.conf
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/release/arm64/ROCK64.conf  Fri Apr 24 16:33:07 2020
(r360273)
@@ -0,0 +1,28 @@
+#!/bin/sh
+#
+# $FreeBSD$
+#
+
+EMBEDDED_TARGET_ARCH="aarch64"
+EMBEDDED_TARGET="arm64"
+EMBEDDEDBUILD=1
+EMBEDDEDPORTS="sysutils/u-boot-rock64"
+FAT_SIZE="50m -b 16m"
+FAT_TYPE="16"
+IMAGE_SIZE="3072M"
+KERNEL="GENERIC"
+MD_ARGS="-x 63 -y 255"
+NODOC=1
+PART_SCHEME="GPT"
+export BOARDNAME="ROCK64"
+
+arm_install_uboot() {
+   UBOOT_DIR="/usr/local/share/u-boot/u-boot-rock64"
+   UBOOT_FILE_1="idbloader.img"
+   UBOOT_FILE_2="u-boot.itb"
+   chroot ${CHROOTDIR} dd if=${UBOOT_DIR}/${UBOOT_FILE_1} \
+   of=/dev/${mddev} bs=512 seek=64 conv=sync
+   chroot ${CHROOTDIR} dd if=${UBOOT_DIR}/${UBOOT_FILE_2} \
+   of=/dev/${mddev} bs=512 seek=16384 conv=sync
+   return 0
+}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360272 - head/release/arm64

[Emmanuel Vadot]

Author: manu
Date: Fri Apr 24 16:32:25 2020
New Revision: 360272
URL: https://svnweb.freebsd.org/changeset/base/360272

Log:
  Add PINE64 ROCKPro64 config for generation of release images
  
  Submitted by: Daniel Engberg
  Reviewed by:  imp
  Differential Revision:https://reviews.freebsd.org/D22538

Added:
  head/release/arm64/ROCKPRO64.conf   (contents, props changed)

Added: head/release/arm64/ROCKPRO64.conf
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/release/arm64/ROCKPRO64.conf   Fri Apr 24 16:32:25 2020
(r360272)
@@ -0,0 +1,28 @@
+#!/bin/sh
+#
+# $FreeBSD$
+#
+
+EMBEDDED_TARGET_ARCH="aarch64"
+EMBEDDED_TARGET="arm64"
+EMBEDDEDBUILD=1
+EMBEDDEDPORTS="sysutils/u-boot-rockpro64"
+FAT_SIZE="50m -b 16m"
+FAT_TYPE="16"
+IMAGE_SIZE="3072M"
+KERNEL="GENERIC"
+MD_ARGS="-x 63 -y 255"
+NODOC=1
+PART_SCHEME="GPT"
+export BOARDNAME="ROCKPRO64"
+
+arm_install_uboot() {
+   UBOOT_DIR="/usr/local/share/u-boot/u-boot-rockpro64"
+   UBOOT_FILE_1="idbloader.img"
+   UBOOT_FILE_2="u-boot.itb"
+   chroot ${CHROOTDIR} dd if=${UBOOT_DIR}/${UBOOT_FILE_1} \
+   of=/dev/${mddev} bs=512 seek=64 conv=sync
+   chroot ${CHROOTDIR} dd if=${UBOOT_DIR}/${UBOOT_FILE_2} \
+   of=/dev/${mddev} bs=512 seek=16384 conv=sync
+   return 0
+}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360271 - head/release/tools

[Emmanuel Vadot]

Author: manu
Date: Fri Apr 24 16:31:27 2020
New Revision: 360271
URL: https://svnweb.freebsd.org/changeset/base/360271

Log:
  Add support for generating release images using GPT for ARM
  
  Submitted by: Daniel Engberg (Original version)
  Differential Revision:https://reviews.freebsd.org/D22537

Modified:
  head/release/tools/arm.subr

Modified: head/release/tools/arm.subr
==
--- head/release/tools/arm.subr Fri Apr 24 16:19:03 2020(r360270)
+++ head/release/tools/arm.subr Fri Apr 24 16:31:27 2020(r360271)
@@ -65,13 +65,21 @@ umount_loop() {
 arm_create_disk() {
# Create the target raw file and temporary work directory.
chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
-   chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev}
-   chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
-   chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} 
/dev/${mddev}s1
-   chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
-   chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
-   chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k /dev/${mddev}s2
-   chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
+   if [ "${PART_SCHEME}" == "GPT" ]; then
+   chroot ${CHROOTDIR} gpart add -t efi -l efi -a 512k -s 
${FAT_SIZE} ${mddev}
+   chroot ${CHROOTDIR} newfs_msdos -L efi -F ${FAT_TYPE} 
/dev/${mddev}p1
+   chroot ${CHROOTDIR} gpart add -t freebsd-ufs -l rootfs -a 64k 
${mddev}
+   chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}p2
+   fi
+   if [ "${PART_SCHEME}" == "MBR" ]; then
+   chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} 
${mddev}
+   chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
+   chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} 
/dev/${mddev}s1
+   chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
+   chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
+   chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k 
/dev/${mddev}s2
+   chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
+   fi
 
return 0
 }
@@ -161,7 +169,12 @@ arm_setup_minimal_loader() {
 }
 
 arm_install_base() {
-   chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${DESTDIR}
+   if [ "${PART_SCHEME}" == "GPT" ]; then
+   chroot ${CHROOTDIR} mount /dev/${mddev}p2 ${DESTDIR}
+   fi
+   if [ "${PART_SCHEME}" == "MBR" ]; then
+   chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${DESTDIR}
+   fi
eval chroot ${CHROOTDIR} make -C ${WORLDDIR} \
TARGET=${EMBEDDED_TARGET} \
TARGET_ARCH=${EMBEDDED_TARGET_ARCH} \
@@ -178,10 +191,18 @@ arm_install_base() {
 
echo '# Custom /etc/fstab for FreeBSD embedded images' \
> ${CHROOTDIR}/${DESTDIR}/etc/fstab
-   echo "/dev/ufs/rootfs   /   ufs rw  1   1" \
-   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
-   echo "/dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0" \
-   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   if [ "${PART_SCHEME}" == "GPT" ]; then
+   echo "/dev/ufs/rootfs   /   ufs rw  1   1" \
+   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   echo "/dev/msdosfs/efi /boot/efi msdosfs rw,noatime 0 0" \
+   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   fi
+   if [ "${PART_SCHEME}" == "MBR" ]; then
+   echo "/dev/ufs/rootfs   /   ufs rw  1   1" \
+   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   echo "/dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 
0" \
+   >> ${CHROOTDIR}/${DESTDIR}/etc/fstab
+   fi
echo "tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0" \
>> ${CHROOTDIR}/${DESTDIR}/etc/fstab
 
@@ -206,8 +227,17 @@ arm_install_boot() {
FATMOUNT="${DESTDIR%${KERNEL}}/fat"
UFSMOUNT="${DESTDIR%${KERNEL}}/ufs"
chroot ${CHROOTDIR} mkdir -p "${FATMOUNT}" "${UFSMOUNT}"
-   chroot ${CHROOTDIR} mount_msdosfs /dev/${mddev}s1 ${FATMOUNT}
-   chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${UFSMOUNT}
+   if [ "${PART_SCHEME}" == "GPT" ]; then
+   dospart="/dev/${mddev}p1"
+   ufspart="/dev/${mddev}p2"
+   fi
+   if [ "${PART_SCHEME}" == "MBR" ]; then
+   dospart="/dev/${mddev}s1"
+   ufspart="/dev/${mddev}s2a"
+   fi
+
+   chroot ${CHROOTDIR} mount_msdosfs ${dospart} ${FATMOUNT}
+   chroot ${CHROOTDIR} mount ${ufspart} ${UFSMOUNT}
 
if [ "${EMBEDDED_TARGET}" == "arm" ]; then
chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/ubldr.bin \
___
svn-src-all@freebsd.org mailing list

Re: svn commit: r360241 - head/sys/dev/ichiic

[Justin Hibbits]

On Fri, 24 Apr 2020 19:07:35 +0300
Andriy Gapon  wrote:

> On 24/04/2020 18:11, Warner Losh wrote:
> > 
> > 
> > On Fri, Apr 24, 2020 at 8:47 AM Andriy Gapon  > > wrote:
> > 
> > On 24/04/2020 17:29, Warner Losh wrote:  
> > >
> > >
> > > On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  > >  
> >   
> > > >> wrote:
> > >
> > >     Author: avg
> > >     Date: Fri Apr 24 07:49:21 2020
> > >     New Revision: 360241
> > >     URL: https://svnweb.freebsd.org/changeset/base/360241
> > >
> > >     Log:
> > >       ig4: ensure that drivers always attach in correct order
> > >
> > >       Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's
> > >ACPI attachment happens after iicbus and acpi_iicbus drivers
> > >are registered.
> > >
> > >       I have seen a problem where iicbus attached under ig4
> > >instead of acpi_iicbus when ig4.ko was loaded with kldload.  I
> > >believe that that happened because ig4 driver was a first
> > >driver to register, it attached and created an iicbus child.
> > >Then iicbus driver was registered and, since it was the only
> > >driver that could attach to the iicbus child device, it did
> > >exactly that.  After that acpi_iicbus driver was registered.
> > >It would be able to attach to the iicbus device, but it was
> > >already attached, so nothing happened.
> > >
> > >
> > > Can you post more details of which devices are affected? From
> > > the description and the patch, I don't see how this could fix
> > > things.  
> > 
> > I think I listed them all: ig4iic with acpi attachment, iicbus
> > and acpi_iicbus. acpi
> >  \--- ig4iic
> >        \ iicbus vs acpi_iicbus
> > 
> > I tried to explain the problem and the fix in the commit
> > message.  If you want to discuss any specifics, let's continue with
> > specifics.  If there is anything unclear in my explanation, I can
> > clarify, but I need to understand what needs to be clarified.
> > 
> > 
> > That won't fix the stated problem.  
> 
> It will.  It does.  You made me write an essay to explain why :)
> 
> > If changing the module order fixes something,
> > it's the wrong fix. Which is why I asked to make sure I understood
> > the issue (it was unclear if it was at the level indicated, or for
> > the children of the iicbus).
> > 
> > iicbus returns BUS_PROBE_GENERIC (-100) from its probe routine,
> > while acpi_iicbus returns BUS_PROBE_DEFAULT (-20). This means that
> > acpi_iicbus should always win. So something else is going on. We
> > don't specify order on other devices except for some weird, special
> > needs drivers (this is not such a driver).  
> 
> This driver, along with all of other I2C controller drivers, has a
> particular quirk, so it can be called weird.
> 
> It does not matter what the probe routines return if one of the
> drivers is not added to "newbus" at all (even if its code is loaded).
>  Its probe method is not executed.  And that's what I tried to
> explain in the commit message.
> 
> Now, why this driver as well as all SMBus and I2C controller drivers
> are somewhat weird...  There is a multitude of drivers for SMBus and
> I2C controllers.  Those drivers have different names.  So, using
> newbus speak, smbus and iicbus drivers can attach to [newbus] devices
> under many different [newbus] buses.  For that reason, the
> corresponding DRIVER_MODULE declarations are not consolidated in
> smbus.c and iicbus.c; instead, they are spread over individual
> controller drivers.  So, loading of smbus or iicbus module does not
> result in a call to devclass_add_driver() that would register these
> drivers under some bus. And that's an unusual thing comparing to the
> most straightforward drivers.
> 
> Let's use ig4 as an example.
> Across its source files we had the following DRIVER_MODULE
> declarations: DRIVER_MODULE(ig4iic, acpi, ... -- in ig4_acpi.c
> DRIVER_MODULE(iicbus, ig4iic, ... -- in ig4_iic.c
> DRIVER_MODULE(acpi_iicbus, ig4iic, ... -- in ig4_iic.c
> The first one is needed to register ig4iic driver under acpi bus.
> Other two are needed to register iicbus and acpi_iicbus drivers under
> ig4iic bus. The order is not explicitly defined, so the corresponding
> declaration can be processed in any order when ig4.ko is loaded and
> so the corresponding devclass_add_driver() can be called in any order.
> 
> So, I observed in practice the scenario where the drivers were added
> in the written order.  First, ig4iic was added under acpi, it found
> the corresponding device, probed and attached to it.  In its attach
> method it added a new device named "iicbus" as a child.  Then, iicbus
> driver was added under ig4iic bus. That driver found the child device
> and attached to it.  Only then acpi_iicbus was added and it was too
> late to the party.
> 
> So, this is 

svn commit: r360270 - in stable/12/lib/libpmc/pmu-events/arch/x86: . bonnell broadwell broadwellde broadwellx cascadelakex goldmont goldmontplus haswell haswellx icelake ivybridge ivytown jaketown ...

[Alexander Motin]

Author: mav
Date: Fri Apr 24 16:19:03 2020
New Revision: 360270
URL: https://svnweb.freebsd.org/changeset/base/360270

Log:
  MFC r359622 (by mmacy): Update x86 counters

Added:
  stable/12/lib/libpmc/pmu-events/arch/x86/cascadelakex/
 - copied from r359622, head/lib/libpmc/pmu-events/arch/x86/cascadelakex/
  stable/12/lib/libpmc/pmu-events/arch/x86/icelake/
 - copied from r359622, head/lib/libpmc/pmu-events/arch/x86/icelake/
  stable/12/lib/libpmc/pmu-events/arch/x86/silvermont/other.json
 - copied unchanged from r359622, 
head/lib/libpmc/pmu-events/arch/x86/silvermont/other.json
  stable/12/lib/libpmc/pmu-events/arch/x86/tremontx/
 - copied from r359622, head/lib/libpmc/pmu-events/arch/x86/tremontx/
Modified:
  stable/12/lib/libpmc/pmu-events/arch/x86/bonnell/frontend.json
  stable/12/lib/libpmc/pmu-events/arch/x86/bonnell/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwell/bdw-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwell/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwell/floating-point.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwell/frontend.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwell/memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwell/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwellde/bdwde-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwellde/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwellx/bdx-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwellx/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwellx/floating-point.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwellx/memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/broadwellx/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/goldmont/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/goldmont/memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/goldmont/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/goldmont/virtual-memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/goldmontplus/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/goldmontplus/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/goldmontplus/virtual-memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/haswell/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/haswell/floating-point.json
  stable/12/lib/libpmc/pmu-events/arch/x86/haswell/hsw-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/haswell/memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/haswell/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/haswellx/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/haswellx/hsx-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/haswellx/memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/haswellx/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/ivybridge/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/ivybridge/ivb-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/ivybridge/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/ivytown/ivt-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/ivytown/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/ivytown/uncore-power.json
  stable/12/lib/libpmc/pmu-events/arch/x86/jaketown/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/jaketown/jkt-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/jaketown/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/jaketown/uncore-power.json
  stable/12/lib/libpmc/pmu-events/arch/x86/knightslanding/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/knightslanding/memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/knightslanding/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/knightslanding/virtual-memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/mapfile.csv
  stable/12/lib/libpmc/pmu-events/arch/x86/sandybridge/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/sandybridge/floating-point.json
  stable/12/lib/libpmc/pmu-events/arch/x86/sandybridge/frontend.json
  stable/12/lib/libpmc/pmu-events/arch/x86/sandybridge/memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/sandybridge/other.json
  stable/12/lib/libpmc/pmu-events/arch/x86/sandybridge/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/sandybridge/snb-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/sandybridge/virtual-memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/silvermont/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/silvermont/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/skylake/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/skylake/frontend.json
  stable/12/lib/libpmc/pmu-events/arch/x86/skylake/memory.json
  stable/12/lib/libpmc/pmu-events/arch/x86/skylake/pipeline.json
  stable/12/lib/libpmc/pmu-events/arch/x86/skylake/skl-metrics.json
  stable/12/lib/libpmc/pmu-events/arch/x86/skylakex/cache.json
  stable/12/lib/libpmc/pmu-events/arch/x86/skylakex/floating-point.json
  

Re: svn commit: r360241 - head/sys/dev/ichiic

[Andriy Gapon]

On 24/04/2020 18:11, Warner Losh wrote:
> 
> 
> On Fri, Apr 24, 2020 at 8:47 AM Andriy Gapon  > wrote:
> 
> On 24/04/2020 17:29, Warner Losh wrote:
> >
> >
> > On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  
> > >> wrote:
> >
> >     Author: avg
> >     Date: Fri Apr 24 07:49:21 2020
> >     New Revision: 360241
> >     URL: https://svnweb.freebsd.org/changeset/base/360241
> >
> >     Log:
> >       ig4: ensure that drivers always attach in correct order
> >
> >       Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI 
> attachment
> >       happens after iicbus and acpi_iicbus drivers are registered.
> >
> >       I have seen a problem where iicbus attached under ig4 instead of
> >       acpi_iicbus when ig4.ko was loaded with kldload.  I believe that 
> that
> >       happened because ig4 driver was a first driver to register, it 
> attached
> >       and created an iicbus child.  Then iicbus driver was registered 
> and,
> >       since it was the only driver that could attach to the iicbus child
> >       device, it did exactly that.  After that acpi_iicbus driver was
> >       registered.  It would be able to attach to the iicbus device, but 
> it was
> >       already attached, so nothing happened.
> >
> >
> > Can you post more details of which devices are affected? From the 
> description
> > and the patch, I don't see how this could fix things.
> 
> I think I listed them all: ig4iic with acpi attachment, iicbus and 
> acpi_iicbus.
> acpi
>  \--- ig4iic
>        \ iicbus vs acpi_iicbus
> 
> I tried to explain the problem and the fix in the commit message.  If you 
> want
> to discuss any specifics, let's continue with specifics.  If there is 
> anything
> unclear in my explanation, I can clarify, but I need to understand what 
> needs to
> be clarified.
> 
> 
> That won't fix the stated problem.

It will.  It does.  You made me write an essay to explain why :)

> If changing the module order fixes something,
> it's the wrong fix. Which is why I asked to make sure I understood the issue 
> (it
> was unclear if it was at the level indicated, or for the children of the 
> iicbus).
> 
> iicbus returns BUS_PROBE_GENERIC (-100) from its probe routine, while
> acpi_iicbus returns BUS_PROBE_DEFAULT (-20). This means that acpi_iicbus 
> should
> always win. So something else is going on. We don't specify order on other
> devices except for some weird, special needs drivers (this is not such a 
> driver).

This driver, along with all of other I2C controller drivers, has a particular
quirk, so it can be called weird.

It does not matter what the probe routines return if one of the drivers is not
added to "newbus" at all (even if its code is loaded).  Its probe method is not
executed.  And that's what I tried to explain in the commit message.

Now, why this driver as well as all SMBus and I2C controller drivers are
somewhat weird...  There is a multitude of drivers for SMBus and I2C
controllers.  Those drivers have different names.  So, using newbus speak, smbus
and iicbus drivers can attach to [newbus] devices under many different [newbus]
buses.  For that reason, the corresponding DRIVER_MODULE declarations are not
consolidated in smbus.c and iicbus.c; instead, they are spread over individual
controller drivers.  So, loading of smbus or iicbus module does not result in a
call to devclass_add_driver() that would register these drivers under some bus.
And that's an unusual thing comparing to the most straightforward drivers.

Let's use ig4 as an example.
Across its source files we had the following DRIVER_MODULE declarations:
DRIVER_MODULE(ig4iic, acpi, ... -- in ig4_acpi.c
DRIVER_MODULE(iicbus, ig4iic, ... -- in ig4_iic.c
DRIVER_MODULE(acpi_iicbus, ig4iic, ... -- in ig4_iic.c
The first one is needed to register ig4iic driver under acpi bus.  Other two are
needed to register iicbus and acpi_iicbus drivers under ig4iic bus.
The order is not explicitly defined, so the corresponding declaration can be
processed in any order when ig4.ko is loaded and so the corresponding
devclass_add_driver() can be called in any order.

So, I observed in practice the scenario where the drivers were added in the
written order.  First, ig4iic was added under acpi, it found the corresponding
device, probed and attached to it.  In its attach method it added a new device
named "iicbus" as a child.  Then, iicbus driver was added under ig4iic bus.
That driver found the child device and attached to it.  Only then acpi_iicbus
was added and it was too late to the party.

So, this is really about an order in which DRIVER_MODULE-s (which translate to
sysinit-s) _within a kld_ are processed.  Essentially, about an order of objects
in the corresponding section of a loadable ELF object. 

svn commit: r360269 - head/lib/libpmc/pmu-events/arch/x86

[Alexander Motin]

Author: mav
Date: Fri Apr 24 16:05:35 2020
New Revision: 360269
URL: https://svnweb.freebsd.org/changeset/base/360269

Log:
  Map family 0x5F (Denverton) to goldmont.
  
  According to the 325462-071US document, they should be the same.
  
  MFC after:1 week

Modified:
  head/lib/libpmc/pmu-events/arch/x86/mapfile.csv

Modified: head/lib/libpmc/pmu-events/arch/x86/mapfile.csv
==
--- head/lib/libpmc/pmu-events/arch/x86/mapfile.csv Fri Apr 24 15:27:56 
2020(r360268)
+++ head/lib/libpmc/pmu-events/arch/x86/mapfile.csv Fri Apr 24 16:05:35 
2020(r360269)
@@ -9,6 +9,7 @@ GenuineIntel-6-27,v4,bonnell,core
 GenuineIntel-6-36,v4,bonnell,core
 GenuineIntel-6-35,v4,bonnell,core
 GenuineIntel-6-5C,v8,goldmont,core
+GenuineIntel-6-5F,v8,goldmont,core
 GenuineIntel-6-7A,v1,goldmontplus,core
 GenuineIntel-6-3C,v24,haswell,core
 GenuineIntel-6-45,v24,haswell,core
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360268 - stable/11/sys/netpfil/pf

[Kristof Provost]

Author: kp
Date: Fri Apr 24 15:27:56 2020
New Revision: 360268
URL: https://svnweb.freebsd.org/changeset/base/360268

Log:
  MFC r360042:
  
  pf: Do not allow negative ps_len in DIOCGETSTATES
  
  Userspace may pass a negative ps_len value to us, which causes an
  assertion failure in malloc().
  Treat negative values as zero, i.e. return the required size.
  
  Reported-by:  syzbot+53370d9d0358ee2a0...@syzkaller.appspotmail.com

Modified:
  stable/11/sys/netpfil/pf/pf_ioctl.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/netpfil/pf/pf_ioctl.c
==
--- stable/11/sys/netpfil/pf/pf_ioctl.c Fri Apr 24 15:27:55 2020
(r360267)
+++ stable/11/sys/netpfil/pf/pf_ioctl.c Fri Apr 24 15:27:56 2020
(r360268)
@@ -1759,7 +1759,7 @@ relock_DIOCKILLSTATES:
struct pfsync_state *pstore, *p;
int i, nr;
 
-   if (ps->ps_len == 0) {
+   if (ps->ps_len <= 0) {
nr = uma_zone_get_cur(V_pf_state_z);
ps->ps_len = sizeof(struct pfsync_state) * nr;
break;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360267 - stable/12/sys/netpfil/pf

[Kristof Provost]

Author: kp
Date: Fri Apr 24 15:27:55 2020
New Revision: 360267
URL: https://svnweb.freebsd.org/changeset/base/360267

Log:
  MFC r360042:
  
  pf: Do not allow negative ps_len in DIOCGETSTATES
  
  Userspace may pass a negative ps_len value to us, which causes an
  assertion failure in malloc().
  Treat negative values as zero, i.e. return the required size.
  
  Reported-by:  syzbot+53370d9d0358ee2a0...@syzkaller.appspotmail.com

Modified:
  stable/12/sys/netpfil/pf/pf_ioctl.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/netpfil/pf/pf_ioctl.c
==
--- stable/12/sys/netpfil/pf/pf_ioctl.c Fri Apr 24 15:09:30 2020
(r360266)
+++ stable/12/sys/netpfil/pf/pf_ioctl.c Fri Apr 24 15:27:55 2020
(r360267)
@@ -2163,7 +2163,7 @@ relock_DIOCKILLSTATES:
struct pfsync_state *pstore, *p;
int i, nr;
 
-   if (ps->ps_len == 0) {
+   if (ps->ps_len <= 0) {
nr = uma_zone_get_cur(V_pf_state_z);
ps->ps_len = sizeof(struct pfsync_state) * nr;
break;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r360241 - head/sys/dev/ichiic

[Warner Losh]

On Fri, Apr 24, 2020 at 8:47 AM Andriy Gapon  wrote:

> On 24/04/2020 17:29, Warner Losh wrote:
> >
> >
> > On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  > > wrote:
> >
> > Author: avg
> > Date: Fri Apr 24 07:49:21 2020
> > New Revision: 360241
> > URL: https://svnweb.freebsd.org/changeset/base/360241
> >
> > Log:
> >   ig4: ensure that drivers always attach in correct order
> >
> >   Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI
> attachment
> >   happens after iicbus and acpi_iicbus drivers are registered.
> >
> >   I have seen a problem where iicbus attached under ig4 instead of
> >   acpi_iicbus when ig4.ko was loaded with kldload.  I believe that
> that
> >   happened because ig4 driver was a first driver to register, it
> attached
> >   and created an iicbus child.  Then iicbus driver was registered
> and,
> >   since it was the only driver that could attach to the iicbus child
> >   device, it did exactly that.  After that acpi_iicbus driver was
> >   registered.  It would be able to attach to the iicbus device, but
> it was
> >   already attached, so nothing happened.
> >
> >
> > Can you post more details of which devices are affected? From the
> description
> > and the patch, I don't see how this could fix things.
>
> I think I listed them all: ig4iic with acpi attachment, iicbus and
> acpi_iicbus.
> acpi
>  \--- ig4iic
>\ iicbus vs acpi_iicbus
>
> I tried to explain the problem and the fix in the commit message.  If you
> want
> to discuss any specifics, let's continue with specifics.  If there is
> anything
> unclear in my explanation, I can clarify, but I need to understand what
> needs to
> be clarified.
>

That won't fix the stated problem. If changing the module order fixes
something, it's the wrong fix. Which is why I asked to make sure I
understood the issue (it was unclear if it was at the level indicated, or
for the children of the iicbus).

iicbus returns BUS_PROBE_GENERIC (-100) from its probe routine, while
acpi_iicbus returns BUS_PROBE_DEFAULT (-20). This means that acpi_iicbus
should always win. So something else is going on. We don't specify order on
other devices except for some weird, special needs drivers (this is not
such a driver).

Unless I'm mistaken, the real problem is that the following line is missing
instead.
MODULE_DEPEND(ig4iic, acpi_iicbus, 1, 1, 1);
which makes the module dependencies explicit. Can you add that to
ig4_acpi.c, revert your change and see if that works? It will ensure that
the acpi_iicbus driver is loaded first. If things break because it isn't,
it sounds like a hard dependency for ig4. Since we're already pulling in
acpi, that doesn't seem unreasonable to me.

Warner


>
> >   MFC after:2 weeks
> >
> > Modified:
> >   head/sys/dev/ichiic/ig4_acpi.c
> >
> > Modified: head/sys/dev/ichiic/ig4_acpi.c
> >
>  
> ==
> > --- head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 05:05:58 2020
>
> > (r360240)
> > +++ head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 07:49:21 2020
>
> > (r360241)
> > @@ -192,5 +192,6 @@ static driver_t ig4iic_acpi_driver = {
> > sizeof(struct ig4iic_softc),
> >  };
> >
> > -DRIVER_MODULE(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0,
> 0);
> > +DRIVER_MODULE_ORDERED(ig4iic, acpi, ig4iic_acpi_driver,
> ig4iic_devclass, 0, 0,
> > +SI_ORDER_ANY);
> >  MODULE_DEPEND(ig4iic, acpi, 1, 1, 1);
> >
>
>
> --
> Andriy Gapon
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360266 - head/sys/dev/hwpmc

[Alexander Motin]

Author: mav
Date: Fri Apr 24 15:09:30 2020
New Revision: 360266
URL: https://svnweb.freebsd.org/changeset/base/360266

Log:
  Add family 0x5F (Denverton) to PMC_CPU_INTEL_ATOM_GOLDMONT.
  
  According to the 325462-071US document, they should be the same.
  
  MFC after:1 week

Modified:
  head/sys/dev/hwpmc/hwpmc_intel.c

Modified: head/sys/dev/hwpmc/hwpmc_intel.c
==
--- head/sys/dev/hwpmc/hwpmc_intel.cFri Apr 24 15:02:05 2020
(r360265)
+++ head/sys/dev/hwpmc/hwpmc_intel.cFri Apr 24 15:09:30 2020
(r360266)
@@ -204,6 +204,7 @@ pmc_intel_initialize(void)
nclasses = 3;
break;
case 0x5C:  /* Per Intel document 325462-071US 10/2019. */
+   case 0x5F:
cputype = PMC_CPU_INTEL_ATOM_GOLDMONT;
nclasses = 3;
break;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360265 - in stable/12/sys: dev/hwpmc sys

[Alexander Motin]

Author: mav
Date: Fri Apr 24 15:02:05 2020
New Revision: 360265
URL: https://svnweb.freebsd.org/changeset/base/360265

Log:
  MFC r359667 (by mw): Add hwpmc support for Intel Atom Goldmont 
microarchitecture
  
  Recognize new micro-architecture in hwpmc_intel driver. Based on Intel
  document 325462-071US. Tested with tools/test/hwpmc/pmctest.py
  on Atom E3930 SoC.

Modified:
  stable/12/sys/dev/hwpmc/hwpmc_intel.c
  stable/12/sys/sys/pmc.h
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/dev/hwpmc/hwpmc_intel.c
==
--- stable/12/sys/dev/hwpmc/hwpmc_intel.c   Fri Apr 24 14:55:07 2020
(r360264)
+++ stable/12/sys/dev/hwpmc/hwpmc_intel.c   Fri Apr 24 15:02:05 2020
(r360265)
@@ -203,6 +203,10 @@ pmc_intel_initialize(void)
cputype = PMC_CPU_INTEL_ATOM_SILVERMONT;
nclasses = 3;
break;
+   case 0x5C:  /* Per Intel document 325462-071US 10/2019. */
+   cputype = PMC_CPU_INTEL_ATOM_GOLDMONT;
+   nclasses = 3;
+   break;
}
break;
}
@@ -230,6 +234,7 @@ pmc_intel_initialize(void)
 */
case PMC_CPU_INTEL_ATOM:
case PMC_CPU_INTEL_ATOM_SILVERMONT:
+   case PMC_CPU_INTEL_ATOM_GOLDMONT:
case PMC_CPU_INTEL_BROADWELL:
case PMC_CPU_INTEL_BROADWELL_XEON:
case PMC_CPU_INTEL_SKYLAKE_XEON:
@@ -293,6 +298,7 @@ pmc_intel_finalize(struct pmc_mdep *md)
switch (md->pmd_cputype) {
case PMC_CPU_INTEL_ATOM:
case PMC_CPU_INTEL_ATOM_SILVERMONT:
+   case PMC_CPU_INTEL_ATOM_GOLDMONT:
case PMC_CPU_INTEL_BROADWELL:
case PMC_CPU_INTEL_BROADWELL_XEON:
case PMC_CPU_INTEL_SKYLAKE_XEON:

Modified: stable/12/sys/sys/pmc.h
==
--- stable/12/sys/sys/pmc.h Fri Apr 24 14:55:07 2020(r360264)
+++ stable/12/sys/sys/pmc.h Fri Apr 24 15:02:05 2020(r360265)
@@ -110,6 +110,7 @@ extern char pmc_cpuid[PMC_CPUID_LEN];
__PMC_CPU(INTEL_BROADWELL_XEON, 0x97,   "Intel Broadwell Xeon") \
__PMC_CPU(INTEL_SKYLAKE, 0x98,   "Intel Skylake")   \
__PMC_CPU(INTEL_SKYLAKE_XEON, 0x99,   "Intel Skylake Xeon") \
+   __PMC_CPU(INTEL_ATOM_GOLDMONT, 0x9A,   "Intel Atom Goldmont")   \
__PMC_CPU(INTEL_XSCALE, 0x100,  "Intel XScale") \
__PMC_CPU(MIPS_24K, 0x200,  "MIPS 24K") \
__PMC_CPU(MIPS_OCTEON,  0x201,  "Cavium Octeon")\
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360263 - head/usr.sbin/bluetooth/hccontrol

[Hans Petter Selasky]

Author: hselasky
Date: Fri Apr 24 14:53:55 2020
New Revision: 360263
URL: https://svnweb.freebsd.org/changeset/base/360263

Log:
  Rename two commands to match the Bluetooth specification in hccontrol(8).
  Fix some bad spelling while at it.
  
  Submitted by: Marc Veldman 
  PR:   245868
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/usr.sbin/bluetooth/hccontrol/host_controller_baseband.c

Modified: head/usr.sbin/bluetooth/hccontrol/host_controller_baseband.c
==
--- head/usr.sbin/bluetooth/hccontrol/host_controller_baseband.cFri Apr 
24 14:47:55 2020(r360262)
+++ head/usr.sbin/bluetooth/hccontrol/host_controller_baseband.cFri Apr 
24 14:53:55 2020(r360263)
@@ -1491,7 +1491,7 @@ hci_write_page_scan_mode(int s, int argc, char **argv)
 } /* hci_write_page_scan_mode */
 
 static int
-hci_read_le_host_supported_command(int s, int argc, char **argv) 
+hci_read_le_host_support(int s, int argc, char **argv) 
 {
ng_hci_read_le_host_supported_rp rp;
int n;
@@ -1508,13 +1508,13 @@ hci_read_le_host_supported_command(int s, int argc, ch
}
 
fprintf(stdout, "LE Host support: %#02x\n", rp.le_supported_host);
-   fprintf(stdout, "Simulateneouse LE Host : %#02x\n", 
rp.simultaneous_le_host);
+   fprintf(stdout, "Simultaneous LE Host : %#02x\n", 
rp.simultaneous_le_host);
 
return (OK);

 }
 static int
-hci_write_le_host_supported_command(int s, int argc, char **argv) 
+hci_write_le_host_support(int s, int argc, char **argv) 
 {
ng_hci_write_le_host_supported_cp cp;
ng_hci_write_le_host_supported_rp rp;
@@ -1948,14 +1948,14 @@ struct hci_command  
host_controller_baseband_commands[]
 _write_page_scan_mode
 },
 {
-"read_le_host_supported_command",  \
-"Read if this host is in le supported mode and stimulatenouse le supported 
mode",
-_read_le_host_supported_command,
+"read_le_host_support",\
+"Read if this host is in LE supported mode and simultaneous LE supported mode",
+_read_le_host_support,
 },  
 {
-"write_le_host_supported_command", \
-"write_le_host_supported_command le_host[0|1] stimultajeous_le[0|1]",
-_write_le_host_supported_command,
+"write_le_host_support",   \
+"write_le_host_support le_host[0|1] simultaneous_le[0|1]",
+_write_le_host_support,
 },  
 
 { NULL, }
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360262 - stable/12/sys/dev/hwpmc

[Alexander Motin]

Author: mav
Date: Fri Apr 24 14:47:55 2020
New Revision: 360262
URL: https://svnweb.freebsd.org/changeset/base/360262

Log:
  MFC r354470 (by gallatin): hwpmc : fix AMD perf counter MSR access
  
  - amd_intr() does not account for the offset (0x200) in the counter
  MSR address and ends up accessing invalid regions while reading
  counter value after the 4th counter (0xC001000[8,9,..]) and
  erroneously updates the counter values for counters [1-4].
  
  - amd_intr() should only check core pmcs for interrupts since
   other types of pmcs (L3,DF) cannot generate interrupts.
  
  - fix pmc NMI's being ignored due to NMI latency on newer AMD processors
  
  Note that this fixes a kernel panic due to GPFs accessing MSRs on
  higher core count AMD cpus (seen on both Rome 7502P, and
  Threadripper 2990WX 32-core CPUs)

Modified:
  stable/12/sys/dev/hwpmc/hwpmc_amd.c
  stable/12/sys/dev/hwpmc/hwpmc_amd.h
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/dev/hwpmc/hwpmc_amd.c
==
--- stable/12/sys/dev/hwpmc/hwpmc_amd.c Fri Apr 24 14:27:23 2020
(r360261)
+++ stable/12/sys/dev/hwpmc/hwpmc_amd.c Fri Apr 24 14:47:55 2020
(r360262)
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,6 +54,10 @@ __FBSDID("$FreeBSD$");
 enum pmc_class amd_pmc_class;
 #endif
 
+#defineOVERFLOW_WAIT_COUNT 50
+
+DPCPU_DEFINE_STATIC(uint32_t, nmi_counter);
+
 /* AMD K7 & K8 PMCs */
 struct amd_descr {
struct pmc_descr pm_descr;  /* "base class" */
@@ -739,6 +744,7 @@ amd_stop_pmc(int cpu, int ri)
struct pmc_hw *phw;
const struct amd_descr *pd;
uint64_t config;
+   int i;
 
KASSERT(cpu >= 0 && cpu < pmc_cpu_max(),
("[amd,%d] illegal CPU value %d", __LINE__, cpu));
@@ -761,6 +767,21 @@ amd_stop_pmc(int cpu, int ri)
/* turn off the PMC ENABLE bit */
config = pm->pm_md.pm_amd.pm_amd_evsel & ~AMD_PMC_ENABLE;
wrmsr(pd->pm_evsel, config);
+
+   /*
+* Due to NMI latency on newer AMD processors
+* NMI interrupts are ignored, which leads to
+* panic or messages based on kernel configuraiton
+*/
+
+   /* Wait for the count to be reset */
+   for (i = 0; i < OVERFLOW_WAIT_COUNT; i++) {
+   if (rdmsr(pd->pm_perfctr) & (1 << (pd->pm_descr.pd_width - 1)))
+   break;
+
+   DELAY(1);
+   }
+
return 0;
 }
 
@@ -779,6 +800,7 @@ amd_intr(struct trapframe *tf)
struct pmc *pm;
struct amd_cpu *pac;
pmc_value_t v;
+   uint32_t active = 0, count = 0;
 
cpu = curcpu;
KASSERT(cpu >= 0 && cpu < pmc_cpu_max(),
@@ -798,19 +820,21 @@ amd_intr(struct trapframe *tf)
 *
 * If found, we call a helper to process the interrupt.
 *
-* If multiple PMCs interrupt at the same time, the AMD64
-* processor appears to deliver as many NMIs as there are
-* outstanding PMC interrupts.  So we process only one NMI
-* interrupt at a time.
+* PMCs interrupting at the same time are collapsed into
+* a single interrupt. Check all the valid pmcs for
+* overflow.
 */
 
-   for (i = 0; retval == 0 && i < AMD_NPMCS; i++) {
+   for (i = 0; i < AMD_CORE_NPMCS; i++) {
 
if ((pm = pac->pc_amdpmcs[i].phw_pmc) == NULL ||
!PMC_IS_SAMPLING_MODE(PMC_TO_MODE(pm))) {
continue;
}
 
+   /* Consider pmc with valid handle as active */
+   active++;
+
if (!AMD_PMC_HAS_OVERFLOWED(i))
continue;
 
@@ -820,8 +844,8 @@ amd_intr(struct trapframe *tf)
continue;
 
/* Stop the PMC, reload count. */
-   evsel   = AMD_PMC_EVSEL_0 + i;
-   perfctr = AMD_PMC_PERFCTR_0 + i;
+   evsel   = amd_pmcdesc[i].pm_evsel;
+   perfctr = amd_pmcdesc[i].pm_perfctr;
v   = pm->pm_sc.pm_reloadcount;
config  = rdmsr(evsel);
 
@@ -837,6 +861,26 @@ amd_intr(struct trapframe *tf)
error = pmc_process_interrupt(PMC_HR, pm, tf);
if (error == 0)
wrmsr(evsel, config);
+   }
+
+   /*
+* Due to NMI latency, there can be a scenario in which
+* multiple pmcs gets serviced in an earlier NMI and we
+* do not find an overflow in the subsequent NMI.
+*
+* For such cases we keep a per-cpu count of active NMIs
+* and compare it with min(active pmcs, 2) to determine
+* if this NMI was for a pmc overflow which was serviced
+* in an earlier request or should be ignored.
+*/
+
+   if (retval) {
+   DPCPU_SET(nmi_counter, min(2, active));
+   

Re: svn commit: r360241 - head/sys/dev/ichiic

[Andriy Gapon]

On 24/04/2020 17:29, Warner Losh wrote:
> 
> 
> On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  > wrote:
> 
> Author: avg
> Date: Fri Apr 24 07:49:21 2020
> New Revision: 360241
> URL: https://svnweb.freebsd.org/changeset/base/360241
> 
> Log:
>   ig4: ensure that drivers always attach in correct order
> 
>   Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI attachment
>   happens after iicbus and acpi_iicbus drivers are registered.
> 
>   I have seen a problem where iicbus attached under ig4 instead of
>   acpi_iicbus when ig4.ko was loaded with kldload.  I believe that that
>   happened because ig4 driver was a first driver to register, it attached
>   and created an iicbus child.  Then iicbus driver was registered and,
>   since it was the only driver that could attach to the iicbus child
>   device, it did exactly that.  After that acpi_iicbus driver was
>   registered.  It would be able to attach to the iicbus device, but it was
>   already attached, so nothing happened.
> 
> 
> Can you post more details of which devices are affected? From the description
> and the patch, I don't see how this could fix things.

I think I listed them all: ig4iic with acpi attachment, iicbus and acpi_iicbus.
acpi
 \--- ig4iic
   \ iicbus vs acpi_iicbus

I tried to explain the problem and the fix in the commit message.  If you want
to discuss any specifics, let's continue with specifics.  If there is anything
unclear in my explanation, I can clarify, but I need to understand what needs to
be clarified.


>   MFC after:    2 weeks
> 
> Modified:
>   head/sys/dev/ichiic/ig4_acpi.c
> 
> Modified: head/sys/dev/ichiic/ig4_acpi.c
> 
> ==
> --- head/sys/dev/ichiic/ig4_acpi.c      Fri Apr 24 05:05:58 2020       
> (r360240)
> +++ head/sys/dev/ichiic/ig4_acpi.c      Fri Apr 24 07:49:21 2020       
> (r360241)
> @@ -192,5 +192,6 @@ static driver_t ig4iic_acpi_driver = {
>         sizeof(struct ig4iic_softc),
>  };
> 
> -DRIVER_MODULE(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0, 0);
> +DRIVER_MODULE_ORDERED(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 
> 0, 0,
> +    SI_ORDER_ANY);
>  MODULE_DEPEND(ig4iic, acpi, 1, 1, 1);
> 


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

Re: svn commit: r360241 - head/sys/dev/ichiic

[Warner Losh]

On Fri, Apr 24, 2020 at 1:49 AM Andriy Gapon  wrote:

> Author: avg
> Date: Fri Apr 24 07:49:21 2020
> New Revision: 360241
> URL: https://svnweb.freebsd.org/changeset/base/360241
>
> Log:
>   ig4: ensure that drivers always attach in correct order
>
>   Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI attachment
>   happens after iicbus and acpi_iicbus drivers are registered.
>
>   I have seen a problem where iicbus attached under ig4 instead of
>   acpi_iicbus when ig4.ko was loaded with kldload.  I believe that that
>   happened because ig4 driver was a first driver to register, it attached
>   and created an iicbus child.  Then iicbus driver was registered and,
>   since it was the only driver that could attach to the iicbus child
>   device, it did exactly that.  After that acpi_iicbus driver was
>   registered.  It would be able to attach to the iicbus device, but it was
>   already attached, so nothing happened.
>

Can you post more details of which devices are affected? From the
description and the patch, I don't see how this could fix things.

Warner


>   MFC after:2 weeks
>
> Modified:
>   head/sys/dev/ichiic/ig4_acpi.c
>
> Modified: head/sys/dev/ichiic/ig4_acpi.c
>
> ==
> --- head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 05:05:58 2020
> (r360240)
> +++ head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 07:49:21 2020
> (r360241)
> @@ -192,5 +192,6 @@ static driver_t ig4iic_acpi_driver = {
> sizeof(struct ig4iic_softc),
>  };
>
> -DRIVER_MODULE(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0, 0);
> +DRIVER_MODULE_ORDERED(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass,
> 0, 0,
> +SI_ORDER_ANY);
>  MODULE_DEPEND(ig4iic, acpi, 1, 1, 1);
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360261 - in stable/12/sys: arm64/arm64 riscv/riscv

[Mark Johnston]

Author: markj
Date: Fri Apr 24 14:27:23 2020
New Revision: 360261
URL: https://svnweb.freebsd.org/changeset/base/360261

Log:
  Fix the build after r360259.
  
  stable/12 is missing r357940.  For some reason this warning wasn't hit
  when I compiled locally.
  
  This is a direct commit to stable/12.
  
  Reported by:  Jenkins

Modified:
  stable/12/sys/arm64/arm64/mp_machdep.c
  stable/12/sys/riscv/riscv/mp_machdep.c

Modified: stable/12/sys/arm64/arm64/mp_machdep.c
==
--- stable/12/sys/arm64/arm64/mp_machdep.c  Fri Apr 24 13:53:40 2020
(r360260)
+++ stable/12/sys/arm64/arm64/mp_machdep.c  Fri Apr 24 14:27:23 2020
(r360261)
@@ -342,7 +342,7 @@ smp_after_idle_runnable(void *arg __unused)
for (cpu = 1; cpu < mp_ncpus; cpu++) {
if (bootstacks[cpu] != NULL) {
pc = pcpu_find(cpu);
-   while (atomic_load_ptr(>pc_curpcb) == NULL)
+   while ((void *)atomic_load_ptr(>pc_curpcb) == NULL)
cpu_spinwait();
kmem_free((vm_offset_t)bootstacks[cpu], PAGE_SIZE);
}

Modified: stable/12/sys/riscv/riscv/mp_machdep.c
==
--- stable/12/sys/riscv/riscv/mp_machdep.c  Fri Apr 24 13:53:40 2020
(r360260)
+++ stable/12/sys/riscv/riscv/mp_machdep.c  Fri Apr 24 14:27:23 2020
(r360261)
@@ -304,7 +304,7 @@ smp_after_idle_runnable(void *arg __unused)
for (cpu = 1; cpu < mp_ncpus; cpu++) {
if (bootstacks[cpu] != NULL) {
pc = pcpu_find(cpu);
-   while (atomic_load_ptr(>pc_curpcb) == NULL)
+   while ((void *)atomic_load_ptr(>pc_curpcb) == NULL)
cpu_spinwait();
kmem_free((vm_offset_t)bootstacks[cpu], PAGE_SIZE);
}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360260 - in head/stand: efi/loader/arch/amd64 i386/libi386 userboot/userboot

[Mark Johnston]

Author: markj
Date: Fri Apr 24 13:53:40 2020
New Revision: 360260
URL: https://svnweb.freebsd.org/changeset/base/360260

Log:
  Stop setting PG_U in bootstrap mappings.
  
  These mappings are never visible to userspace as they get replaced when
  the amd64 pmap is bootstrapped, but there is no need to set PG_U in the
  first place.
  
  Reviewed by:  alc, kib
  MFC after:1 week
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D24547

Modified:
  head/stand/efi/loader/arch/amd64/elf64_freebsd.c
  head/stand/i386/libi386/elf64_freebsd.c
  head/stand/userboot/userboot/elf64_freebsd.c

Modified: head/stand/efi/loader/arch/amd64/elf64_freebsd.c
==
--- head/stand/efi/loader/arch/amd64/elf64_freebsd.cFri Apr 24 13:49:51 
2020(r360259)
+++ head/stand/efi/loader/arch/amd64/elf64_freebsd.cFri Apr 24 13:53:40 
2020(r360260)
@@ -172,15 +172,15 @@ elf64_exec(struct preloaded_file *fp)
for (i = 0; i < 512; i++) {
/* Each slot of the L4 pages points to the same L3 page. */
PT4[i] = (pml4_entry_t)PT3;
-   PT4[i] |= PG_V | PG_RW | PG_U;
+   PT4[i] |= PG_V | PG_RW;
 
/* Each slot of the L3 pages points to the same L2 page. */
PT3[i] = (pdp_entry_t)PT2;
-   PT3[i] |= PG_V | PG_RW | PG_U;
+   PT3[i] |= PG_V | PG_RW;
 
/* The L2 page slots are mapped with 2MB pages for 1GB. */
PT2[i] = i * (2 * 1024 * 1024);
-   PT2[i] |= PG_V | PG_RW | PG_PS | PG_U;
+   PT2[i] |= PG_V | PG_RW | PG_PS;
}
 
printf("Start @ 0x%lx ...\n", ehdr->e_entry);

Modified: head/stand/i386/libi386/elf64_freebsd.c
==
--- head/stand/i386/libi386/elf64_freebsd.c Fri Apr 24 13:49:51 2020
(r360259)
+++ head/stand/i386/libi386/elf64_freebsd.c Fri Apr 24 13:53:40 2020
(r360260)
@@ -48,7 +48,6 @@ struct file_format amd64_elf_obj = { elf64_obj_loadfil
 
 #define PG_V   0x001
 #define PG_RW  0x002
-#define PG_U   0x004
 #define PG_PS  0x080
 
 typedef uint64_t p4_entry_t;
@@ -96,15 +95,15 @@ elf64_exec(struct preloaded_file *fp)
 for (i = 0; i < 512; i++) {
/* Each slot of the level 4 pages points to the same level 3 page */
PT4[i] = (p4_entry_t)VTOP((uintptr_t)[0]);
-   PT4[i] |= PG_V | PG_RW | PG_U;
+   PT4[i] |= PG_V | PG_RW;
 
/* Each slot of the level 3 pages points to the same level 2 page */
PT3[i] = (p3_entry_t)VTOP((uintptr_t)[0]);
-   PT3[i] |= PG_V | PG_RW | PG_U;
+   PT3[i] |= PG_V | PG_RW;
 
/* The level 2 page slots are mapped with 2MB pages for 1GB. */
PT2[i] = i * (2 * 1024 * 1024);
-   PT2[i] |= PG_V | PG_RW | PG_PS | PG_U;
+   PT2[i] |= PG_V | PG_RW | PG_PS;
 }
 
 entry_lo = ehdr->e_entry & 0x;

Modified: head/stand/userboot/userboot/elf64_freebsd.c
==
--- head/stand/userboot/userboot/elf64_freebsd.cFri Apr 24 13:49:51 
2020(r360259)
+++ head/stand/userboot/userboot/elf64_freebsd.cFri Apr 24 13:53:40 
2020(r360260)
@@ -60,7 +60,6 @@ struct file_format amd64_elf_obj = { elf64_obj_loadfil
 
 #define PG_V   0x001
 #define PG_RW  0x002
-#define PG_U   0x004
 #define PG_PS  0x080
 
 typedef uint64_t p4_entry_t;
@@ -127,15 +126,15 @@ elf64_exec(struct preloaded_file *fp)
for (i = 0; i < 512; i++) {
/* Each slot of the level 4 pages points to the same level 3 
page */
PT4[i] = (p4_entry_t) 0x3000;
-   PT4[i] |= PG_V | PG_RW | PG_U;
+   PT4[i] |= PG_V | PG_RW;
 
/* Each slot of the level 3 pages points to the same level 2 
page */
PT3[i] = (p3_entry_t) 0x4000;
-   PT3[i] |= PG_V | PG_RW | PG_U;
+   PT3[i] |= PG_V | PG_RW;
 
/* The level 2 page slots are mapped with 2MB pages for 1GB. */
PT2[i] = i * (2 * 1024 * 1024);
-   PT2[i] |= PG_V | PG_RW | PG_PS | PG_U;
+   PT2[i] |= PG_V | PG_RW | PG_PS;
}
 
 #ifdef DEBUG
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360259 - in stable/12/sys: arm64/arm64 riscv/riscv

[Mark Johnston]

Author: markj
Date: Fri Apr 24 13:49:51 2020
New Revision: 360259
URL: https://svnweb.freebsd.org/changeset/base/360259

Log:
  MFC r359280:
  Remove the secondary_stacks array in arm64 and riscv kernels.

Modified:
  stable/12/sys/arm64/arm64/locore.S
  stable/12/sys/arm64/arm64/mp_machdep.c
  stable/12/sys/riscv/riscv/locore.S
  stable/12/sys/riscv/riscv/mp_machdep.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/arm64/arm64/locore.S
==
--- stable/12/sys/arm64/arm64/locore.S  Fri Apr 24 13:31:22 2020
(r360258)
+++ stable/12/sys/arm64/arm64/locore.S  Fri Apr 24 13:49:51 2020
(r360259)
@@ -183,11 +183,10 @@ ENTRY(mpentry)
br  x15
 
 mp_virtdone:
-   ldr x4, =secondary_stacks
-   mov x5, #(PAGE_SIZE * KSTACK_PAGES)
-   mul x5, x0, x5
-   add sp, x4, x5
-
+   /* Start using the AP boot stack */
+   ldr x4, =bootstack
+   ldr x4, [x4]
+   mov sp, x4
b   init_secondary
 END(mpentry)
 #endif

Modified: stable/12/sys/arm64/arm64/mp_machdep.c
==
--- stable/12/sys/arm64/arm64/mp_machdep.c  Fri Apr 24 13:31:22 2020
(r360258)
+++ stable/12/sys/arm64/arm64/mp_machdep.c  Fri Apr 24 13:49:51 2020
(r360259)
@@ -122,7 +122,6 @@ static void ipi_preempt(void *);
 static void ipi_rendezvous(void *);
 static void ipi_stop(void *);
 
-struct mtx ap_boot_mtx;
 struct pcb stoppcbs[MAXCPU];
 
 static device_t cpu_list[MAXCPU];
@@ -137,10 +136,18 @@ static int cpu0 = -1;
 void mpentry(unsigned long cpuid);
 void init_secondary(uint64_t);
 
-uint8_t secondary_stacks[MAXCPU - 1][PAGE_SIZE * KSTACK_PAGES] __aligned(16);
+/* Synchronize AP startup. */
+static struct mtx ap_boot_mtx;
 
+/* Stacks for AP initialization, discarded once idle threads are started. */
+void *bootstack;
+static void *bootstacks[MAXCPU];
+
+/* Count of started APs, used to synchronize access to bootstack. */
+static volatile int aps_started;
+
 /* Set to 1 once we're ready to let the APs out of the pen. */
-volatile int aps_ready = 0;
+static volatile int aps_ready;
 
 /* Temporary variables for init_secondary()  */
 void *dpcpu[MAXCPU - 1];
@@ -277,14 +284,14 @@ init_secondary(uint64_t cpu)
"mov x18, %0 \n"
"msr tpidr_el1, %0" :: "r"(pcpup));
 
-   /* Spin until the BSP releases the APs */
-   while (!aps_ready)
+   /* Signal the BSP and spin until it has released all APs. */
+   atomic_add_int(_started, 1);
+   while (!atomic_load_int(_ready))
__asm __volatile("wfe");
 
/* Initialize curthread */
KASSERT(PCPU_GET(idlethread) != NULL, ("no idle thread"));
pcpup->pc_curthread = pcpup->pc_idlethread;
-   pcpup->pc_curpcb = pcpup->pc_idlethread->td_pcb;
 
/*
 * Identify current CPU. This is necessary to setup
@@ -314,6 +321,11 @@ init_secondary(uint64_t cpu)
}
mtx_unlock_spin(_boot_mtx);
 
+   /*
+* Assert that smp_after_idle_runnable condition is reasonable.
+*/
+   MPASS(PCPU_GET(curpcb) == NULL);
+
/* Enter the scheduler */
sched_throw(NULL);
 
@@ -321,6 +333,24 @@ init_secondary(uint64_t cpu)
/* NOTREACHED */
 }
 
+static void
+smp_after_idle_runnable(void *arg __unused)
+{
+   struct pcpu *pc;
+   int cpu;
+
+   for (cpu = 1; cpu < mp_ncpus; cpu++) {
+   if (bootstacks[cpu] != NULL) {
+   pc = pcpu_find(cpu);
+   while (atomic_load_ptr(>pc_curpcb) == NULL)
+   cpu_spinwait();
+   kmem_free((vm_offset_t)bootstacks[cpu], PAGE_SIZE);
+   }
+   }
+}
+SYSINIT(smp_after_idle_runnable, SI_SUB_SMP, SI_ORDER_ANY,
+smp_after_idle_runnable, NULL);
+
 /*
  *  Send IPI thru interrupt controller.
  */
@@ -451,7 +481,7 @@ start_cpu(u_int id, uint64_t target_cpu)
struct pcpu *pcpup;
vm_paddr_t pa;
u_int cpuid;
-   int err;
+   int err, naps;
 
/* Check we are able to start this cpu */
if (id > mp_maxid)
@@ -465,7 +495,7 @@ start_cpu(u_int id, uint64_t target_cpu)
 
/*
 * Rotate the CPU IDs to put the boot CPU as CPU 0. We keep the other
-* CPUs ordered as the are likely grouped into clusters so it can be
+* CPUs ordered as they are likely grouped into clusters so it can be
 * useful to keep that property, e.g. for the GICv3 driver to send
 * an IPI to all CPUs in the cluster.
 */
@@ -480,29 +510,41 @@ start_cpu(u_int id, uint64_t target_cpu)
dpcpu[cpuid - 1] = (void *)kmem_malloc(DPCPU_SIZE, M_WAITOK | M_ZERO);
dpcpu_init(dpcpu[cpuid - 1], cpuid);
 
+   bootstacks[cpuid] = (void *)kmem_malloc(PAGE_SIZE, M_WAITOK | M_ZERO);
+
+   naps = 

svn commit: r360258 - in stable/12/sys: dev/altera/jtag_uart dev/bvm dev/cfe dev/ofw dev/rp dev/xen/console kern netgraph sys

[Kyle Evans]

Author: kevans
Date: Fri Apr 24 13:31:22 2020
New Revision: 360258
URL: https://svnweb.freebsd.org/changeset/base/360258

Log:
  MFC r360051: tty: convert tty_lock_assert to tty_assert_locked
  
  A later change, currently being iterated on in D24459, will in-fact change
  the lock type to an sx so that TTY drivers can sleep on it if they need to.
  Committing this ahead of time to make the review in question a little more
  palatable.
  
  tty_lock_assert() is unfortunately still needed for now in two places to
  make sure that the tty lock has not been recursed upon, for those scenarios
  where it's supplied by the TTY driver and possibly a mutex that is allowed
  to recurse.

Modified:
  stable/12/sys/dev/altera/jtag_uart/altera_jtag_uart_tty.c
  stable/12/sys/dev/bvm/bvm_console.c
  stable/12/sys/dev/cfe/cfe_console.c
  stable/12/sys/dev/ofw/ofw_console.c
  stable/12/sys/dev/rp/rp.c
  stable/12/sys/dev/xen/console/xen_console.c
  stable/12/sys/kern/tty.c
  stable/12/sys/kern/tty_info.c
  stable/12/sys/kern/tty_ttydisc.c
  stable/12/sys/netgraph/ng_tty.c
  stable/12/sys/sys/tty.h
  stable/12/sys/sys/ttydevsw.h
  stable/12/sys/sys/ttydisc.h
  stable/12/sys/sys/ttyhook.h
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/dev/altera/jtag_uart/altera_jtag_uart_tty.c
==
--- stable/12/sys/dev/altera/jtag_uart/altera_jtag_uart_tty.c   Fri Apr 24 
13:29:08 2020(r360257)
+++ stable/12/sys/dev/altera/jtag_uart/altera_jtag_uart_tty.c   Fri Apr 24 
13:31:22 2020(r360258)
@@ -266,7 +266,7 @@ aju_handle_input(struct altera_jtag_uart_softc *sc, st
 {
int c;
 
-   tty_lock_assert(tp, MA_OWNED);
+   tty_assert_locked(tp);
AJU_LOCK_ASSERT(sc);
 
while (aju_readable(sc)) {
@@ -298,7 +298,7 @@ aju_handle_output(struct altera_jtag_uart_softc *sc, s
uint32_t v;
uint8_t ch;
 
-   tty_lock_assert(tp, MA_OWNED);
+   tty_assert_locked(tp);
AJU_LOCK_ASSERT(sc);
 
AJU_UNLOCK(sc);
@@ -364,7 +364,7 @@ aju_outwakeup(struct tty *tp)
 {
struct altera_jtag_uart_softc *sc = tty_softc(tp);
 
-   tty_lock_assert(tp, MA_OWNED);
+   tty_assert_locked(tp);
 
AJU_LOCK(sc);
aju_handle_output(sc, tp);

Modified: stable/12/sys/dev/bvm/bvm_console.c
==
--- stable/12/sys/dev/bvm/bvm_console.c Fri Apr 24 13:29:08 2020
(r360257)
+++ stable/12/sys/dev/bvm/bvm_console.c Fri Apr 24 13:31:22 2020
(r360258)
@@ -130,7 +130,7 @@ static void
 bvm_tty_close(struct tty *tp)
 {
 
-   tty_lock_assert(tp, MA_OWNED);
+   tty_assert_locked(tp);
callout_stop(_timer);
 }
 
@@ -159,7 +159,7 @@ bvm_timeout(void *v)
 
tp = (struct tty *)v;
 
-   tty_lock_assert(tp, MA_OWNED);
+   tty_assert_locked(tp);
while ((c = bvm_cngetc(NULL)) != -1)
ttydisc_rint(tp, c, 0);
ttydisc_rint_done(tp);

Modified: stable/12/sys/dev/cfe/cfe_console.c
==
--- stable/12/sys/dev/cfe/cfe_console.c Fri Apr 24 13:29:08 2020
(r360257)
+++ stable/12/sys/dev/cfe/cfe_console.c Fri Apr 24 13:31:22 2020
(r360258)
@@ -142,7 +142,7 @@ cfe_timeout(void *v)
 
tp = (struct tty *)v;
 
-   tty_lock_assert(tp, MA_OWNED);
+   tty_assert_locked(tp);
while ((c = cfe_cngetc(NULL)) != -1)
ttydisc_rint(tp, c, 0);
ttydisc_rint_done(tp);

Modified: stable/12/sys/dev/ofw/ofw_console.c
==
--- stable/12/sys/dev/ofw/ofw_console.c Fri Apr 24 13:29:08 2020
(r360257)
+++ stable/12/sys/dev/ofw/ofw_console.c Fri Apr 24 13:31:22 2020
(r360258)
@@ -152,7 +152,7 @@ ofw_timeout(void *v)
 
tp = (struct tty *)v;
 
-   tty_lock_assert(tp, MA_OWNED);
+   tty_assert_locked(tp);
while ((c = ofw_cngetc(NULL)) != -1)
ttydisc_rint(tp, c, 0);
ttydisc_rint_done(tp);

Modified: stable/12/sys/dev/rp/rp.c
==
--- stable/12/sys/dev/rp/rp.c   Fri Apr 24 13:29:08 2020(r360257)
+++ stable/12/sys/dev/rp/rp.c   Fri Apr 24 13:31:22 2020(r360258)
@@ -674,7 +674,7 @@ static void rp_do_poll(void *arg)
 
rp = arg;
tp = rp->rp_tty;
-   tty_lock_assert(tp, MA_OWNED);
+   tty_assert_locked(tp);
ctl = rp->rp_ctlp;
CtlMask = ctl->ctlmask(ctl);
if (CtlMask & (1 << rp->rp_aiop)) {

Modified: stable/12/sys/dev/xen/console/xen_console.c
==
--- stable/12/sys/dev/xen/console/xen_console.c Fri Apr 24 13:29:08 2020
(r360257)
+++ stable/12/sys/dev/xen/console/xen_console.c Fri Apr 24 13:31:22 2020   

svn commit: r360257 - stable/12/tests/sys/kqueue/libkqueue

[Kyle Evans]

Author: kevans
Date: Fri Apr 24 13:29:08 2020
New Revision: 360257
URL: https://svnweb.freebsd.org/changeset/base/360257

Log:
  MFC r360033, r360108: better precision in kqueue timer tests
  
  r360033:
  tests: kqueue: use a more precise timer for the NOTE_ABSTIME test
  
  Originally noticed while attempting to run the kqueue tests under
  qemu-user-static, this apparently just happens sometimes when running in a
  jail in general -- the timer will fire off "too early," but it's really just
  the result of imprecise measurements (noted by cem).
  
  Kicking this over to NOTE_USECONDS still tests the correct thing while
  allowing it to work more consistently; a basic sanity test reveals that we
  often end up coming in just less than 200 microseconds after the timer
  fired off.
  
  r360108:
  tests: kqueue: fix some issues with now() on ILP32 platforms
  
  There were ultimately two separate problems here:
  - a 32-bit long cannot represent microseconds since 1970 (noted by ian)
  - time_t is 32-bit on i386, so now() was wrong anyways even with the correct
return type.
  
  For the first, just explicitly use a uint64_t for now() and all of the
  callers. For the second, we need to explicitly cast tv_sec to uint64_t
  before it gets multiplied in the SEC_TO_US macro. Casting this instance
  rather than generally in the macro was arbitrarily chosen simply because all
  other uses are converting small relative time values.
  
  The tests now pass on i386, at least; presumably other ILP32 will be fine
  now as well.

Modified:
  stable/12/tests/sys/kqueue/libkqueue/timer.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/tests/sys/kqueue/libkqueue/timer.c
==
--- stable/12/tests/sys/kqueue/libkqueue/timer.cFri Apr 24 13:25:02 
2020(r360256)
+++ stable/12/tests/sys/kqueue/libkqueue/timer.cFri Apr 24 13:29:08 
2020(r360257)
@@ -30,13 +30,14 @@
 /* Get the current time with microsecond precision. Used for
  * sub-second timing to make some timer tests run faster.
  */
-static long
+static uint64_t
 now(void)
 {
 struct timeval tv;
 
 gettimeofday(, NULL);
-return SEC_TO_US(tv.tv_sec) + tv.tv_usec;
+/* Promote potentially 32-bit time_t to uint64_t before conversion. */
+return SEC_TO_US((uint64_t)tv.tv_sec) + tv.tv_usec;
 }
 
 /* Sleep for a given number of milliseconds. The timeout is assumed to
@@ -216,17 +217,17 @@ test_abstime(void)
 {
 const char *test_id = "kevent(EVFILT_TIMER, EV_ONESHOT, NOTE_ABSTIME)";
 struct kevent kev;
-time_t start;
-time_t stop;
-const int timeout = 3;
+uint64_t end, start, stop;
+const int timeout_sec = 3;
 
 test_begin(test_id);
 
 test_no_kevents();
 
-start = time(NULL);
+start = now();
+end = start + SEC_TO_US(timeout_sec);
 EV_SET(, vnode_fd, EVFILT_TIMER, EV_ADD | EV_ONESHOT,
-  NOTE_ABSTIME | NOTE_SECONDS, start + timeout, NULL);
+  NOTE_ABSTIME | NOTE_USECONDS, end, NULL);
 if (kevent(kqfd, , 1, NULL, 0, NULL) < 0)
 err(1, "%s", test_id);
 
@@ -235,10 +236,10 @@ test_abstime(void)
 kev.data = 1;
 kev.fflags = 0;
 kevent_cmp(, kevent_get(kqfd));
-stop = time(NULL);
-if (stop < start + timeout)
-err(1, "too early %jd %jd", (intmax_t)stop, (intmax_t)(start + 
timeout));
 
+stop = now();
+if (stop < end)
+err(1, "too early %jd %jd", (intmax_t)stop, (intmax_t)end);
 /* Check if the event occurs again */
 sleep(3);
 test_no_kevents();
@@ -252,7 +253,7 @@ test_update(void)
 const char *test_id = "kevent(EVFILT_TIMER (UPDATE), EV_ADD | EV_ONESHOT)";
 struct kevent kev;
 long elapsed;
-long start;
+uint64_t start;
 
 test_begin(test_id);
 
@@ -297,7 +298,7 @@ test_update_equal(void)
 const char *test_id = "kevent(EVFILT_TIMER (UPDATE=), EV_ADD | 
EV_ONESHOT)";
 struct kevent kev;
 long elapsed;
-long start;
+uint64_t start;
 
 test_begin(test_id);
 
@@ -341,7 +342,7 @@ test_update_expired(void)
 const char *test_id = "kevent(EVFILT_TIMER (UPDATE EXP), EV_ADD | 
EV_ONESHOT)";
 struct kevent kev;
 long elapsed;
-long start;
+uint64_t start;
 
 test_begin(test_id);
 
@@ -392,8 +393,7 @@ test_update_periodic(void)
 const char *test_id = "kevent(EVFILT_TIMER (UPDATE), periodic)";
 struct kevent kev;
 long elapsed;
-long start;
-long stop;
+uint64_t start, stop;
 
 test_begin(test_id);
 
@@ -450,8 +450,7 @@ test_update_timing(void)
 int iteration;
 int sleeptime;
 long elapsed;
-long start;
-long stop;
+uint64_t start, stop;
 
 test_begin(test_id);
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360256 - in stable/12/sys: kern sys

[Kyle Evans]

Author: kevans
Date: Fri Apr 24 13:25:02 2020
New Revision: 360256
URL: https://svnweb.freebsd.org/changeset/base/360256

Log:
  MFC r360140, r360155: kqueue timer/data fixes
  
  r360140:
  kqueue: fix conversion of timer data to sbintime
  
  This unbreaks the i386 kqueue timer tests after a recent change switched
  NOTE_ABSTIME over to using microseconds. Notably, the data argument (which
  holds useconds) is an int64_t, but we were passing it to timer2sbintime
  which takes an intptr_t. Perhaps in a previous incarnation, intptr_t would
  have made sense, but now it just leads to the timestamp getting truncated
  and subsequently rejected when it no longer fits in an intptr_t.
  
  r360155:
  kevent32: fix the split of data into data1/data2
  
  The current situation results in intermittent breakage if data gets split up
  with the sign bit set on the data1 half of it, as PAIR32TO64 will then:
  data1 | (data2 << 32) -> resulting in data1 getting sign-extended when it's
  implicitly widened and clobbering the result. AFAICT, there's no compelling
  reason for these to be signed.
  
  This was most exposed by flakiness in the kqueue timer tests under compat32
  after the ABSTIME test got switched over to using a better clock and
  microseconds.

Modified:
  stable/12/sys/kern/kern_event.c
  stable/12/sys/sys/event.h
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/kern/kern_event.c
==
--- stable/12/sys/kern/kern_event.c Fri Apr 24 13:24:19 2020
(r360255)
+++ stable/12/sys/kern/kern_event.c Fri Apr 24 13:25:02 2020
(r360256)
@@ -619,7 +619,7 @@ knote_fork(struct knlist *list, int pid)
 (NOTE_SECONDS | NOTE_MSECONDS | NOTE_USECONDS | NOTE_NSECONDS)
 
 static sbintime_t
-timer2sbintime(intptr_t data, int flags)
+timer2sbintime(int64_t data, int flags)
 {
int64_t secs;
 

Modified: stable/12/sys/sys/event.h
==
--- stable/12/sys/sys/event.h   Fri Apr 24 13:24:19 2020(r360255)
+++ stable/12/sys/sys/event.h   Fri Apr 24 13:25:02 2020(r360256)
@@ -111,7 +111,7 @@ struct kevent32 {
 #ifndef __amd64__
uint32_tpad0;
 #endif
-   int32_t data1, data2;
+   uint32_tdata1, data2;
uint32_tudata;  /* opaque user data identifier */
 #ifndef __amd64__
uint32_tpad1;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360255 - in stable/12/sys: kern sys

[Mark Johnston]

Author: markj
Date: Fri Apr 24 13:24:19 2020
New Revision: 360255
URL: https://svnweb.freebsd.org/changeset/base/360255

Log:
  MFC r359779:
  sbappendcontrol() needs to avoid clearing M_NOTREADY on data mbufs.

Modified:
  stable/12/sys/kern/uipc_sockbuf.c
  stable/12/sys/kern/uipc_usrreq.c
  stable/12/sys/sys/sockbuf.h
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/kern/uipc_sockbuf.c
==
--- stable/12/sys/kern/uipc_sockbuf.c   Fri Apr 24 13:23:16 2020
(r360254)
+++ stable/12/sys/kern/uipc_sockbuf.c   Fri Apr 24 13:24:19 2020
(r360255)
@@ -957,11 +957,11 @@ sbappendaddr(struct sockbuf *sb, const struct sockaddr
 
 void
 sbappendcontrol_locked(struct sockbuf *sb, struct mbuf *m0,
-struct mbuf *control)
+struct mbuf *control, int flags)
 {
struct mbuf *m, *mlast;
 
-   m_clrprotoflags(m0);
+   sbm_clrprotoflags(m0, flags);
m_last(control)->m_next = m0;
 
SBLASTRECORDCHK(sb);
@@ -979,11 +979,12 @@ sbappendcontrol_locked(struct sockbuf *sb, struct mbuf
 }
 
 void
-sbappendcontrol(struct sockbuf *sb, struct mbuf *m0, struct mbuf *control)
+sbappendcontrol(struct sockbuf *sb, struct mbuf *m0, struct mbuf *control,
+int flags)
 {
 
SOCKBUF_LOCK(sb);
-   sbappendcontrol_locked(sb, m0, control);
+   sbappendcontrol_locked(sb, m0, control, flags);
SOCKBUF_UNLOCK(sb);
 }
 

Modified: stable/12/sys/kern/uipc_usrreq.c
==
--- stable/12/sys/kern/uipc_usrreq.cFri Apr 24 13:23:16 2020
(r360254)
+++ stable/12/sys/kern/uipc_usrreq.cFri Apr 24 13:24:19 2020
(r360255)
@@ -1193,7 +1193,7 @@ uipc_send(struct socket *so, int flags, struct mbuf *m
case SOCK_STREAM:
if (control != NULL) {
sbappendcontrol_locked(>so_rcv, m,
-   control);
+   control, flags);
control = NULL;
} else
sbappend_locked(>so_rcv, m, flags);

Modified: stable/12/sys/sys/sockbuf.h
==
--- stable/12/sys/sys/sockbuf.h Fri Apr 24 13:23:16 2020(r360254)
+++ stable/12/sys/sys/sockbuf.h Fri Apr 24 13:24:19 2020(r360255)
@@ -140,9 +140,9 @@ int sbappendaddr_locked(struct sockbuf *sb, const stru
 intsbappendaddr_nospacecheck_locked(struct sockbuf *sb,
const struct sockaddr *asa, struct mbuf *m0, struct mbuf *control);
 void   sbappendcontrol(struct sockbuf *sb, struct mbuf *m0,
-   struct mbuf *control);
+   struct mbuf *control, int flags);
 void   sbappendcontrol_locked(struct sockbuf *sb, struct mbuf *m0,
-   struct mbuf *control);
+   struct mbuf *control, int flags);
 void   sbappendrecord(struct sockbuf *sb, struct mbuf *m0);
 void   sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0);
 void   sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360254 - stable/12/sys/compat/linuxkpi/common/src

[Mark Johnston]

Author: markj
Date: Fri Apr 24 13:23:16 2020
New Revision: 360254
URL: https://svnweb.freebsd.org/changeset/base/360254

Log:
  MFC r360052:
  Remove a vestigal reference to kmem_object.

Modified:
  stable/12/sys/compat/linuxkpi/common/src/linux_page.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/compat/linuxkpi/common/src/linux_page.c
==
--- stable/12/sys/compat/linuxkpi/common/src/linux_page.c   Fri Apr 24 
13:22:13 2020(r360253)
+++ stable/12/sys/compat/linuxkpi/common/src/linux_page.c   Fri Apr 24 
13:23:16 2020(r360254)
@@ -75,7 +75,7 @@ void *
 linux_page_address(struct page *page)
 {
 
-   if (page->object != kmem_object && page->object != kernel_object) {
+   if (page->object != kernel_object) {
return (PMAP_HAS_DMAP ?
((void *)(uintptr_t)PHYS_TO_DMAP(VM_PAGE_TO_PHYS(page))) :
NULL);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360253 - stable/12/sys/conf

[Mark Johnston]

Author: markj
Date: Fri Apr 24 13:22:13 2020
New Revision: 360253
URL: https://svnweb.freebsd.org/changeset/base/360253

Log:
  MFC r360046:
  Always compile minidump_machdep.c on arm.

Modified:
  stable/12/sys/conf/files.arm
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/conf/files.arm
==
--- stable/12/sys/conf/files.armFri Apr 24 13:20:37 2020
(r360252)
+++ stable/12/sys/conf/files.armFri Apr 24 13:22:13 2020
(r360253)
@@ -54,7 +54,7 @@ arm/arm/machdep_kdb.c standard
 arm/arm/machdep_intr.c standard
 arm/arm/machdep_ptrace.c   standard
 arm/arm/mem.c  optionalmem
-arm/arm/minidump_machdep.c optionalmem
+arm/arm/minidump_machdep.c standard
 arm/arm/mp_machdep.c   optionalsmp
 arm/arm/mpcore_timer.c optionalmpcore_timer
 arm/arm/nexus.cstandard
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360252 - stable/12/sys/riscv/riscv

[Mark Johnston]

Author: markj
Date: Fri Apr 24 13:20:37 2020
New Revision: 360252
URL: https://svnweb.freebsd.org/changeset/base/360252

Log:
  MFC r356675 (by mhorne):
  RISC-V: fix global symbol lookups for mpentry with lld

Modified:
  stable/12/sys/riscv/riscv/locore.S
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/riscv/riscv/locore.S
==
--- stable/12/sys/riscv/riscv/locore.S  Fri Apr 24 12:57:03 2020
(r360251)
+++ stable/12/sys/riscv/riscv/locore.S  Fri Apr 24 13:20:37 2020
(r360252)
@@ -287,7 +287,7 @@ ENTRY(mpentry)
li  t1, 4
mulwt1, t1, a0
/* Get the pointer */
-   la  t0, __riscv_boot_ap
+   lla t0, __riscv_boot_ap
add t0, t0, t1
 
 1:
@@ -296,7 +296,7 @@ ENTRY(mpentry)
beqzt1, 1b
 
/* Setup stack pointer */
-   la  t0, secondary_stacks
+   lla t0, secondary_stacks
li  t1, (PAGE_SIZE * KSTACK_PAGES)
mulwt2, t1, a0
add t0, t0, t2
@@ -306,14 +306,14 @@ ENTRY(mpentry)
add sp, t0, t1
 
/* Setup supervisor trap vector */
-   la  t0, mpva
+   lla t0, mpva
sub t0, t0, s9
li  t1, KERNBASE
add t0, t0, t1
csrwstvec, t0
 
/* Set page tables base register */
-   la  s2, pagetable_l1
+   lla s2, pagetable_l1
srlis2, s2, PAGE_SHIFT
li  t0, SATP_MODE_SV39
or  s2, s2, t0
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360251 - head

[Kyle Evans]

Author: kevans
Date: Fri Apr 24 12:57:03 2020
New Revision: 360251
URL: https://svnweb.freebsd.org/changeset/base/360251

Log:
  UPDATING: Fix the date of the closefrom(2) entry
  
  Apologies; my internal calendar says it's still February, but that doesn't
  seem to match reality where we've apparently advanced two months.

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Fri Apr 24 12:54:35 2020(r360250)
+++ head/UPDATING   Fri Apr 24 12:57:03 2020(r360251)
@@ -26,7 +26,7 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
disable the most expensive debugging functionality run
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
-20200224:
+20200424:
closefrom(2) has been moved under COMPAT12, and replaced in libc with a
stub that calls close_range(2).  If using a custom kernel configuration,
you may want to ensure that the COMPAT_FREEBSD12 option is included, as
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360250 - head

[Kyle Evans]

Author: kevans
Date: Fri Apr 24 12:54:35 2020
New Revision: 360250
URL: https://svnweb.freebsd.org/changeset/base/360250

Log:
  UPDATING: add a note about closefrom(2) marked COMPAT12
  
  Some of the consumers in-base may make it enticing enough to ensure that
  COMPAT_FREEBSD12, which is notably a fairly light option at the moment, is
  included in custom kernel configs.
  
  Suggested by: netchild
  Casualty: mail jail

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Fri Apr 24 11:03:15 2020(r360249)
+++ head/UPDATING   Fri Apr 24 12:54:35 2020(r360250)
@@ -26,6 +26,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
disable the most expensive debugging functionality run
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
+20200224:
+   closefrom(2) has been moved under COMPAT12, and replaced in libc with a
+   stub that calls close_range(2).  If using a custom kernel configuration,
+   you may want to ensure that the COMPAT_FREEBSD12 option is included, as
+   a slightly older -CURRENT userland and older FreeBSD userlands may not
+   be functional without closefrom(2).
+
 20200414:
Upstream DTS from Linux 5.6 was merged and they now have the SID
and THS (Secure ID controller and THermal Sensor) node present.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360249 - head/sys/dev/pci

[Andrew Turner]

Author: andrew
Date: Fri Apr 24 11:03:15 2020
New Revision: 360249
URL: https://svnweb.freebsd.org/changeset/base/360249

Log:
  Remove PCI_IO_WINDOW_OFFSET from the pci host generic fdt attachment.
  
  It doesn't seem to be needed, and breaks booting under bhyve/arm64.
  
  Discussed with:   br
  MFC after:2 weeks
  Sponsored by: Innovate UK

Modified:
  head/sys/dev/pci/pci_host_generic_fdt.c

Modified: head/sys/dev/pci/pci_host_generic_fdt.c
==
--- head/sys/dev/pci/pci_host_generic_fdt.c Fri Apr 24 10:20:54 2020
(r360248)
+++ head/sys/dev/pci/pci_host_generic_fdt.c Fri Apr 24 11:03:15 2020
(r360249)
@@ -65,8 +65,6 @@ __FBSDID("$FreeBSD$");
 
 #include "pcib_if.h"
 
-#definePCI_IO_WINDOW_OFFSET0x1000
-
 #defineSPACE_CODE_SHIFT24
 #defineSPACE_CODE_MASK 0x3
 #defineSPACE_CODE_IO_SPACE 0x1
@@ -170,8 +168,7 @@ pci_host_generic_attach(device_t dev)
pci_base, pci_base + size - 1);
} else if (sc->base.ranges[tuple].flags & FLAG_IO) {
error = rman_manage_region(>base.io_rman,
-   pci_base + PCI_IO_WINDOW_OFFSET,
-   pci_base + PCI_IO_WINDOW_OFFSET + size - 1);
+   pci_base, pci_base + size - 1);
} else
continue;
if (error) {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360248 - head/sys/crypto/ccp

[Andriy Gapon]

Author: avg
Date: Fri Apr 24 10:20:54 2020
New Revision: 360248
URL: https://svnweb.freebsd.org/changeset/base/360248

Log:
  ccp: add a new hardware ID, found on AMD Ryzen 3 3200U
  
  pciconf reports the device as:
  Family 17h (Models 10h-1fh) Platform Security Processor
  
  dmesg:
  ccp0:  mem 0xfe50-0xfe5f,0xfe68c000-0xfe68dfff at device 
0.2 on pci4
  crypto: assign ccp0 driver id 1, flags 0x100
  
  MFC after:1 week

Modified:
  head/sys/crypto/ccp/ccp.c

Modified: head/sys/crypto/ccp/ccp.c
==
--- head/sys/crypto/ccp/ccp.c   Fri Apr 24 10:03:11 2020(r360247)
+++ head/sys/crypto/ccp/ccp.c   Fri Apr 24 10:20:54 2020(r360248)
@@ -78,6 +78,7 @@ static struct pciid {
 } ccp_ids[] = {
{ 0x14561022, "AMD CCP-5a" },
{ 0x14681022, "AMD CCP-5b" },
+   { 0x15df1022, "AMD CCP-5a" },
 };
 
 static struct random_source random_ccp = {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360247 - head/stand

[Andrew Turner]

Author: andrew
Date: Fri Apr 24 10:03:11 2020
New Revision: 360247
URL: https://svnweb.freebsd.org/changeset/base/360247

Log:
  Build the arm64 loader with -ffixed-x18
  
  This stops the compiler from using the x18 register. Some UEFI
  implementations assume this will be preserved when calling the Boot
  Services.
  
  MFC after:2 weeks
  Sponsored by: Innovate UK

Modified:
  head/stand/defs.mk

Modified: head/stand/defs.mk
==
--- head/stand/defs.mk  Fri Apr 24 09:32:20 2020(r360246)
+++ head/stand/defs.mk  Fri Apr 24 10:03:11 2020(r360247)
@@ -119,7 +119,7 @@ SSP_CFLAGS=
 # currently has no /boot/loader, but may soon.
 CFLAGS+=   -ffreestanding ${CFLAGS_NO_SIMD}
 .if ${MACHINE_CPUARCH} == "aarch64"
-CFLAGS+=   -mgeneral-regs-only -fPIC
+CFLAGS+=   -mgeneral-regs-only -ffixed-x18 -fPIC
 .elif ${MACHINE_CPUARCH} == "riscv"
 CFLAGS+=   -march=rv64imac -mabi=lp64
 .else
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360246 - head/sys/dev/acpica

[Andriy Gapon]

Author: avg
Date: Fri Apr 24 09:32:20 2020
New Revision: 360246
URL: https://svnweb.freebsd.org/changeset/base/360246

Log:
  acpi_video: fix a crash in detach with an LCD output
  
  The crash happened because of a video output object was removed from a
  wrong container, crt_units instead of lcd_units.
  
  MFC after:1 week

Modified:
  head/sys/dev/acpica/acpi_video.c

Modified: head/sys/dev/acpica/acpi_video.c
==
--- head/sys/dev/acpica/acpi_video.cFri Apr 24 08:31:31 2020
(r360245)
+++ head/sys/dev/acpica/acpi_video.cFri Apr 24 09:32:20 2020
(r360246)
@@ -642,7 +642,10 @@ acpi_video_vo_destroy(struct acpi_video_output *vo)
 
switch (vo->adr & DOD_DEVID_MASK) {
case DOD_DEVID_MONITOR:
-   voqh = _units;
+   if ((vo->adr & DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD)
+   voqh = _units;
+   else
+   voqh = _units;
break;
case DOD_DEVID_TV:
voqh = _units;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360244 - stable/12/share/man/man4

[Li-Wen Hsu]

Author: lwhsu
Date: Fri Apr 24 08:31:13 2020
New Revision: 360244
URL: https://svnweb.freebsd.org/changeset/base/360244

Log:
  MFC r360165:
  
  Also update est(4) as r360162 and r360164

Modified:
  stable/12/share/man/man4/est.4
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/share/man/man4/est.4
==
--- stable/12/share/man/man4/est.4  Fri Apr 24 08:07:59 2020
(r360243)
+++ stable/12/share/man/man4/est.4  Fri Apr 24 08:31:13 2020
(r360244)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd October 18, 2012
+.Dd April 21, 2020
 .Dt EST 4
 .Os
 .Sh NAME
@@ -66,7 +66,7 @@ Attempt to infer information from direct probing of th
 Should only be used in diagnostic cases.
 .Pq default 0
 .It hw.est.strict
-Validate frequency requested is accepted by the cpu when set.
+Validate frequency requested is accepted by the CPU when set.
 It appears that this will only work on single core cpus.
 .Pq default 0
 .El
@@ -75,17 +75,17 @@ The following
 .Xr sysctl 8
 values are available
 .Bl -tag -width indent
-.It Va dev.est.%d.\%desc
+.It Va dev.est.%d.%desc
 Description of support, almost always Enhanced SpeedStep Frequency Control.
 .It dev.est.0.%desc: Enhanced SpeedStep Frequency Control
-.It Va dev.est.%d.\%driver
+.It Va dev.est.%d.%driver
 Driver in use, always est.
 .It dev.est.0.%driver: est
-.It Va dev.est.%d.\%parent
-.It dev.est.0.%parent: cpu0
-The cpu that is exposing these frequencies.
+.It Va dev.est.%d.%parent
+The CPU that is exposing these frequencies.
 For example
 .Va cpu0 .
+.It dev.est.0.%parent: cpu0
 .It Va dev.est.%d.freq_settings .
 The valid frequencies that are allowed by this CPU and their step values.
 .It dev.est.0.freq_settings: 2201/45000 2200/45000 2000/39581 1900/37387
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360245 - stable/11/share/man/man4

[Li-Wen Hsu]

Author: lwhsu
Date: Fri Apr 24 08:31:31 2020
New Revision: 360245
URL: https://svnweb.freebsd.org/changeset/base/360245

Log:
  MFC r360165:
  
  Also update est(4) as r360162 and r360164

Modified:
  stable/11/share/man/man4/est.4
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/share/man/man4/est.4
==
--- stable/11/share/man/man4/est.4  Fri Apr 24 08:31:13 2020
(r360244)
+++ stable/11/share/man/man4/est.4  Fri Apr 24 08:31:31 2020
(r360245)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd October 18, 2012
+.Dd April 21, 2020
 .Dt EST 4
 .Os
 .Sh NAME
@@ -66,7 +66,7 @@ Attempt to infer information from direct probing of th
 Should only be used in diagnostic cases.
 .Pq default 0
 .It hw.est.strict
-Validate frequency requested is accepted by the cpu when set.
+Validate frequency requested is accepted by the CPU when set.
 It appears that this will only work on single core cpus.
 .Pq default 0
 .El
@@ -75,17 +75,17 @@ The following
 .Xr sysctl 8
 values are available
 .Bl -tag -width indent
-.It Va dev.est.%d.\%desc
+.It Va dev.est.%d.%desc
 Description of support, almost always Enhanced SpeedStep Frequency Control.
 .It dev.est.0.%desc: Enhanced SpeedStep Frequency Control
-.It Va dev.est.%d.\%driver
+.It Va dev.est.%d.%driver
 Driver in use, always est.
 .It dev.est.0.%driver: est
-.It Va dev.est.%d.\%parent
-.It dev.est.0.%parent: cpu0
-The cpu that is exposing these frequencies.
+.It Va dev.est.%d.%parent
+The CPU that is exposing these frequencies.
 For example
 .Va cpu0 .
+.It dev.est.0.%parent: cpu0
 .It Va dev.est.%d.freq_settings .
 The valid frequencies that are allowed by this CPU and their step values.
 .It dev.est.0.freq_settings: 2201/45000 2200/45000 2000/39581 1900/37387
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360243 - head/usr.sbin/bluetooth/hccontrol

[Hans Petter Selasky]

Author: hselasky
Date: Fri Apr 24 08:07:59 2020
New Revision: 360243
URL: https://svnweb.freebsd.org/changeset/base/360243

Log:
  Add support for LE advertising to hccontrol(8).
  
  Submitted by: Marc Veldman 
  PR:   245848
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/usr.sbin/bluetooth/hccontrol/hccontrol.8
  head/usr.sbin/bluetooth/hccontrol/le.c

Modified: head/usr.sbin/bluetooth/hccontrol/hccontrol.8
==
--- head/usr.sbin/bluetooth/hccontrol/hccontrol.8   Fri Apr 24 07:55:39 
2020(r360242)
+++ head/usr.sbin/bluetooth/hccontrol/hccontrol.8   Fri Apr 24 08:07:59 
2020(r360243)
@@ -25,7 +25,7 @@
 .\" $Id: hccontrol.8,v 1.6 2003/08/06 21:26:38 max Exp $
 .\" $FreeBSD$
 .\"
-.Dd February 7, 2015
+.Dd April 24, 2020
 .Dt HCCONTROL 8
 .Os
 .Sh NAME
@@ -133,6 +133,8 @@ are:
 .It Cm Write_Page_Scan_Period_Mode
 .It Cm Read_Page_Scan_Mode
 .It Cm Write_Page_Scan_Mode
+.It Cm Read_LE_Host_Support
+.It Cm Write_LE_Host_Support
 .It Cm Read_Local_Version_Information
 .It Cm Read_Local_Supported_Commands
 .It Cm Read_Local_Supported_Features
@@ -143,6 +145,15 @@ are:
 .It Cm Reset_Failed_Contact_Counter
 .It Cm Get_Link_Quality
 .It Cm Read_RSSI
+.It Cm LE_Read_Local_Supported_Features
+.It Cm LE_Set_Advertising_Parameters 
+.It Cm LE_Read_Advertising_Physical_Channel_Tx_Power 
+.It Cm LE_Set_Advertising_Data
+.It Cm LE_Set_Scan_Response_Data
+.It Cm LE_Set_Advertising_Enable
+.It Cm LE_Set_Scan_Parameters
+.It Cm LE_Set_Scan_Enable
+.It Cm LE_Read_Supported_States
 .El
 .Pp
 The currently supported node commands in
@@ -170,6 +181,18 @@ are:
 .It Cm Write_Node_Role_Switch
 .It Cm Read_Node_List
 .El
+.Sh EXAMPLES
+Make the blutooth LE host, ubt0hci, scannable through
+.Xr hccontrol 8 commands:
+.Pp
+.Bd -literal -offset indent
+hccontrol -n ubt0hci le_set_advertising_enable disable
+hccontrol -n ubt0hci le_set_advertising_param
+hccontrol -n ubt0hci le_read_advertising_channel_tx_power
+hccontrol -n ubt0hci le_set_advertising_data
+hccontrol -n ubt0hci le_set_scan_response -n FBSD_Host
+hccontrol -n ubt0hci le_set_advertising_enable enable
+.Ed
 .Sh EXIT STATUS
 .Ex -std
 .Sh SEE ALSO

Modified: head/usr.sbin/bluetooth/hccontrol/le.c
==
--- head/usr.sbin/bluetooth/hccontrol/le.c  Fri Apr 24 07:55:39 2020
(r360242)
+++ head/usr.sbin/bluetooth/hccontrol/le.c  Fri Apr 24 08:07:59 2020
(r360243)
@@ -57,6 +57,9 @@ static int le_read_local_supported_features(int s, int
 static int set_le_event_mask(int s, uint64_t mask);
 static int set_event_mask(int s, uint64_t mask);
 static int le_enable(int s, int argc, char *argv[]);
+static int le_set_advertising_enable(int s, int argc, char *argv[]);
+static int le_set_advertising_param(int s, int argc, char *argv[]);
+static int le_read_advertising_channel_tx_power(int s, int argc, char *argv[]);
 
 static int
 le_set_scan_param(int s, int argc, char *argv[])
@@ -339,6 +342,170 @@ int le_enable(int s, int argc, char *argv[])
return OK;
 }
 
+static int
+le_set_advertising_enable(int s, int argc, char *argv[])
+{
+   ng_hci_le_set_advertise_enable_cp cp;
+   ng_hci_le_set_advertise_enable_rp rp;
+   int n, enable = 0;
+
+   if (argc != 1)
+   return USAGE;
+ 
+   if (strcmp(argv[0], "enable") == 0)
+   enable = 1;
+   else if (strcmp(argv[0], "disable") != 0)
+   return USAGE;
+
+   n = sizeof(rp);
+   cp.advertising_enable = enable;
+   if (hci_request(s, NG_HCI_OPCODE(NG_HCI_OGF_LE,
+   NG_HCI_OCF_LE_SET_ADVERTISE_ENABLE), 
+   (void *), sizeof(cp), (void *), ) == ERROR)
+   return (ERROR);
+   
+   if (rp.status != 0x00) {
+   fprintf(stdout, "Status: %s [%#02x]\n", 
+   hci_status2str(rp.status), rp.status);
+   return (FAILED);
+   }
+fprintf(stdout, "LE Advertising %s\n", (enable ? "enabled" : 
"disabled"));
+
+   return (OK);
+}
+
+static int
+le_set_advertising_param(int s, int argc, char *argv[])
+{
+   ng_hci_le_set_advertising_parameters_cp cp;
+   ng_hci_le_set_advertising_parameters_rp rp;
+
+   int n, ch;
+
+   cp.advertising_interval_min = 0x800;
+   cp.advertising_interval_max = 0x800;
+   cp.advertising_type = 0;
+   cp.own_address_type = 0;
+   cp.direct_address_type = 0;
+
+   cp.advertising_channel_map = 7;
+   cp.advertising_filter_policy = 0;
+
+   optreset = 1;
+   optind = 0;
+   while ((ch = getopt(argc, argv , "m:M:t:o:p:a:c:f:")) != -1) {
+   switch(ch) {
+   case 'm':
+   cp.advertising_interval_min =
+   (uint16_t)(strtod(optarg, NULL)/0.625);
+   break;
+

svn commit: r360242 - head/sys/dev/iicbus

[Andriy Gapon]

Author: avg
Date: Fri Apr 24 07:55:39 2020
New Revision: 360242
URL: https://svnweb.freebsd.org/changeset/base/360242

Log:
  acpi_iicbus: set device description in the probe method
  
  Kernel prints the device announcement before the attach method is
  called, so if the correct description is not set by the probe method,
  then the announcement would have an incorrect one.
  
  MFC after:1 week

Modified:
  head/sys/dev/iicbus/acpi_iicbus.c

Modified: head/sys/dev/iicbus/acpi_iicbus.c
==
--- head/sys/dev/iicbus/acpi_iicbus.c   Fri Apr 24 07:49:21 2020
(r360241)
+++ head/sys/dev/iicbus/acpi_iicbus.c   Fri Apr 24 07:55:39 2020
(r360242)
@@ -573,6 +573,7 @@ acpi_iicbus_probe(device_t dev)
if (handle == NULL)
return (ENXIO);
 
+   device_set_desc(dev, "Philips I2C bus (ACPI-hinted)");
return (BUS_PROBE_DEFAULT);
 }
 
@@ -581,8 +582,6 @@ acpi_iicbus_attach(device_t dev)
 {
struct acpi_iicbus_softc *sc = device_get_softc(dev);
int error;
-
-   device_set_desc(dev, "Philips I2C bus (ACPI-hinted)");
 
if (ACPI_FAILURE(acpi_iicbus_enumerate_children(dev)))
device_printf(dev, "children enumeration failed\n");
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r360241 - head/sys/dev/ichiic

[Andriy Gapon]

Author: avg
Date: Fri Apr 24 07:49:21 2020
New Revision: 360241
URL: https://svnweb.freebsd.org/changeset/base/360241

Log:
  ig4: ensure that drivers always attach in correct order
  
  Use DRIVER_MODULE_ORDERED(SI_ORDER_ANY) so that ig4's ACPI attachment
  happens after iicbus and acpi_iicbus drivers are registered.
  
  I have seen a problem where iicbus attached under ig4 instead of
  acpi_iicbus when ig4.ko was loaded with kldload.  I believe that that
  happened because ig4 driver was a first driver to register, it attached
  and created an iicbus child.  Then iicbus driver was registered and,
  since it was the only driver that could attach to the iicbus child
  device, it did exactly that.  After that acpi_iicbus driver was
  registered.  It would be able to attach to the iicbus device, but it was
  already attached, so nothing happened.
  
  MFC after:2 weeks

Modified:
  head/sys/dev/ichiic/ig4_acpi.c

Modified: head/sys/dev/ichiic/ig4_acpi.c
==
--- head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 05:05:58 2020
(r360240)
+++ head/sys/dev/ichiic/ig4_acpi.c  Fri Apr 24 07:49:21 2020
(r360241)
@@ -192,5 +192,6 @@ static driver_t ig4iic_acpi_driver = {
sizeof(struct ig4iic_softc),
 };
 
-DRIVER_MODULE(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0, 0);
+DRIVER_MODULE_ORDERED(ig4iic, acpi, ig4iic_acpi_driver, ig4iic_devclass, 0, 0,
+SI_ORDER_ANY);
 MODULE_DEPEND(ig4iic, acpi, 1, 1, 1);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r360233 - in head: contrib/jemalloc contrib/jemalloc/doc contrib/jemalloc/include/jemalloc contrib/jemalloc/include/jemalloc/internal contrib/jemalloc/src lib/libc/stdlib/jemalloc

[nonameless]

> Author: vangyzen
> Date: Thu Apr 23 23:57:43 2020
> New Revision: 360233
> URL: https://svnweb.freebsd.org/changeset/base/360233
> 
> Log:
> Update jemalloc to version 5.2.1
> 
> Revert r354606 to restore r data-ukrnet-code="354605">354605.
> 
> Apply one line from jemalloc commit d01b425e5d1e1 in hash_x86_128()
> to fix the build with gcc, which only allows a fallthrough attribute
> to appear before a case or default label.
> 
> Submitted by: jasone in r354605
> Discussed with: jasone
> Reviewed by: bdrewery
> MFC after: never, due to gcc 4.2.1
> Relnotes: yes
> Sponsored by: Dell EMC Isilon
> Differential Revision: https://reviews.freebsd.org/D24522
> 
> ...

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