Re: svn commit: r344648 - in head: . sys/kern sys/sys
On Sun, Mar 10, 2019 at 03:11:40PM +, Alexey Dokuchaev wrote: > On Thu, Feb 28, 2019 at 07:47:51AM +, Alexey Dokuchaev wrote: > > On Wed, Feb 27, 2019 at 10:56:55PM +, Mateusz Guzik wrote: > > > New Revision: 344648 > > > URL: https://svnweb.freebsd.org/changeset/base/344648 > > > > > > Log: > > > Rename seq to seqc to avoid namespace clashes with Linux > > > > > > ... > > > Added: > > > head/sys/sys/seqc.h (contents, props changed) > > > Deleted: > > > head/sys/sys/seq.h > > > > Why it was deleted and added as new file instead of being repocopied? > > Retransmit. Ping! ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348235 - head/sbin/ipfw
Author: ae
Date: Fri May 24 11:06:24 2019
New Revision: 348235
URL: https://svnweb.freebsd.org/changeset/base/348235
Log:
Add `missing` and `or-flush` options to "ipfw table create"
command to simplify firewall reloading.
The `missing` option suppresses EEXIST error code, but does check that
existing table has the same parameters as new one. The `or-flush` option
implies `missing` option and additionally does flush for table if it
is already exist.
Submitted by: lev
MFC after:2 weeks
Differential Revision:https://reviews.freebsd.org/D18339
Modified:
head/sbin/ipfw/ipfw.8
head/sbin/ipfw/ipfw2.h
head/sbin/ipfw/tables.c
Modified: head/sbin/ipfw/ipfw.8
==
--- head/sbin/ipfw/ipfw.8 Fri May 24 09:01:54 2019(r348234)
+++ head/sbin/ipfw/ipfw.8 Fri May 24 11:06:24 2019(r348235)
@@ -1,7 +1,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd April 21, 2019
+.Dd May 24, 2019
.Dt IPFW 8
.Os
.Sh NAME
@@ -2138,7 +2138,7 @@ The following creation options are supported:
.Bl -tag -width indent
.It Ar create-options : Ar create-option | create-options
.It Ar create-option : Cm type Ar table-type | Cm valtype Ar value-mask | Cm
algo Ar algo-desc |
-.Cm limit Ar number | Cm locked
+.Cm limit Ar number | Cm locked | Cm missing | Cm or-flush
.It Cm type
Table key type.
.It Cm valtype
@@ -2149,6 +2149,13 @@ Table algorithm to use (see below).
Maximum number of items that may be inserted into table.
.It Cm locked
Restrict any table modifications.
+.It Cm missing
+Do not fail if table already exists and has exactly same options as new one.
+.It Cm or-flush
+Flush existing table with same name instead of returning error.
+Implies
+.Cm missing
+so existing table must be compatible with new one.
.El
.Pp
Some of these options may be modified later via
Modified: head/sbin/ipfw/ipfw2.h
==
--- head/sbin/ipfw/ipfw2.h Fri May 24 09:01:54 2019(r348234)
+++ head/sbin/ipfw/ipfw2.h Fri May 24 11:06:24 2019(r348235)
@@ -264,6 +264,9 @@ enum tokens {
TOK_UNLOCK,
TOK_VLIST,
TOK_OLIST,
+ TOK_MISSING,
+ TOK_ORFLUSH,
+ TOK_OPTIONAL,
/* NAT64 tokens */
TOK_NAT64STL,
Modified: head/sbin/ipfw/tables.c
==
--- head/sbin/ipfw/tables.c Fri May 24 09:01:54 2019(r348234)
+++ head/sbin/ipfw/tables.c Fri May 24 11:06:24 2019(r348235)
@@ -327,6 +327,8 @@ static struct _s_x tablenewcmds[] = {
{ "algo",TOK_ALGO },
{ "limit", TOK_LIMIT },
{ "locked", TOK_LOCK },
+ { "missing", TOK_MISSING },
+ { "or-flush",TOK_ORFLUSH },
{ NULL, 0 }
};
@@ -389,19 +391,19 @@ table_print_type(char *tbuf, size_t size, uint8_t type
* Creates new table
*
* ipfw table NAME create [ type { addr | iface | number | flow } ]
- * [ algo algoname ]
+ * [ algo algoname ] [missing] [or-flush]
*/
static void
table_create(ipfw_obj_header *oh, int ac, char *av[])
{
- ipfw_xtable_info xi;
- int error, tcmd, val;
+ ipfw_xtable_info xi, xie;
+ int error, missing, orflush, tcmd, val;
uint32_t fset, fclear;
char *e, *p;
char tbuf[128];
+ missing = orflush = 0;
memset(&xi, 0, sizeof(xi));
-
while (ac > 0) {
tcmd = get_token(tablenewcmds, *av, "option");
ac--; av++;
@@ -457,6 +459,12 @@ table_create(ipfw_obj_header *oh, int ac, char *av[])
case TOK_LOCK:
xi.flags |= IPFW_TGFLAGS_LOCKED;
break;
+ case TOK_ORFLUSH:
+ orflush = 1;
+ /* FALLTHROUGH */
+ case TOK_MISSING:
+ missing = 1;
+ break;
}
}
@@ -466,8 +474,28 @@ table_create(ipfw_obj_header *oh, int ac, char *av[])
if (xi.vmask == 0)
xi.vmask = IPFW_VTYPE_LEGACY;
- if ((error = table_do_create(oh, &xi)) != 0)
+ error = table_do_create(oh, &xi);
+
+ if (error == 0)
+ return;
+
+ if (errno != EEXIST || missing == 0)
err(EX_OSERR, "Table creation failed");
+
+ /* Check that existing table is the same we are trying to create */
+ if (table_get_info(oh, &xie) != 0)
+ err(EX_OSERR, "Existing table check failed");
+
+ if (xi.limit != xie.limit || xi.type != xie.type ||
+ xi.tflags != xie.tflags || xi.vmask != xie.vmask || (
+ xi.algoname[0] != '\0' && strcmp(xi.algoname,
+ xie.algoname) != 0) || xi.flags != xie.flags)
+ errx(EX_DATAERR, "The existing table is not compatible "
+ "with on
svn commit: r348236 - head/sys/netinet6
Author: ae
Date: Fri May 24 11:45:32 2019
New Revision: 348236
URL: https://svnweb.freebsd.org/changeset/base/348236
Log:
Restore IPV6_NEXTHOP option support that seem was partially broken
since r286195.
Do not forget results of route lookup and initialize rt and ifp pointers.
PR: 238098
Submitted by: Masse Nicolas
MFC after:1 week
Modified:
head/sys/netinet6/in6_src.c
Modified: head/sys/netinet6/in6_src.c
==
--- head/sys/netinet6/in6_src.c Fri May 24 11:06:24 2019(r348235)
+++ head/sys/netinet6/in6_src.c Fri May 24 11:45:32 2019(r348236)
@@ -724,6 +724,10 @@ selectroute(struct sockaddr_in6 *dstsock, struct ip6_p
if (ron->ro_rt == NULL ||
(ron->ro_rt->rt_flags & RTF_GATEWAY) != 0)
error = EHOSTUNREACH;
+ else {
+ rt = ron->ro_rt;
+ ifp = rt->rt_ifp;
+ }
goto done;
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348205 - head/sys/netipsec
On 5/23/19 6:34 PM, Rodney W. Grimes wrote: > I did not need that info, just a list of IANA assigned numbers > of things you can not find in RFC/Ietf documents. I'll do the > leg work from the other side and if Ietf/Iana documents need > fixed I'll get that in process. Oh, to be clear, that specific language is direct from RFC 8221. For example, in section 5 after the table of encryption algorithms: IANA has allocated codes for cryptographic algorithms that have not been specified by the IETF. Such algorithms are noted as UNSPECIFIED. Usually, the use of these algorithms is limited to specific cases, and the absence of specification makes interoperability difficult for IPsec communications. These algorithms were not mentioned in [RFC7321], and this document clarifies that such algorithms MUST NOT be implemented for IPsec communications. Similarly, IANA also allocated code points for algorithms that are not expected to be used to secure IPsec communications. Such algorithms are noted as non-IPsec. As a result, these algorithms MUST NOT be implemented. Various ciphers that are older, not well tested, and never widely implemented have been changed to MUST NOT. On my (8th?) reading though, it may be that the first paragraph is only applying to the algorithms marked UNSPECIFIED in the earlier table which would cover des-32iv and possibly des-deriv in which case the wording I used in the commit log isn't quite clear. Also, just to make it clear, I don't care about IANA numbers, I was merely referencing the RFC's wording as the "why". -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348239 - in head/tools/tools/nanobsd: dhcpd pcengines
Author: emaste
Date: Fri May 24 15:21:23 2019
New Revision: 348239
URL: https://svnweb.freebsd.org/changeset/base/348239
Log:
nanobsd: exclude .git (and .hg) in the same places we exclude .svn
Allow support of other VCSes. Note that two other nanobsd files already
had a similar case, excluding .git and .hg in addition to CVS and .svn.
Sponsored by: The FreeBSD Foundation
Modified:
head/tools/tools/nanobsd/dhcpd/common
head/tools/tools/nanobsd/pcengines/common.conf
Modified: head/tools/tools/nanobsd/dhcpd/common
==
--- head/tools/tools/nanobsd/dhcpd/common Fri May 24 14:38:31 2019
(r348238)
+++ head/tools/tools/nanobsd/dhcpd/common Fri May 24 15:21:23 2019
(r348239)
@@ -83,7 +83,7 @@ cust_install_machine_files()
{
echo "cd ${NANO_CFG_BASE}/Files"
cd ${NANO_CFG_BASE}/Files
- find . -print | grep -Ev '/(CVS|\.svn)' | cpio -dumpv ${NANO_WORLDDIR}
+ find . -print | grep -Ev '/(CVS|\.git|\.hg|\.svn)' | cpio -dumpv
${NANO_WORLDDIR}
}
customize_cmd cust_install_files
customize_cmd cust_install_machine_files
Modified: head/tools/tools/nanobsd/pcengines/common.conf
==
--- head/tools/tools/nanobsd/pcengines/common.conf Fri May 24 14:38:31
2019(r348238)
+++ head/tools/tools/nanobsd/pcengines/common.conf Fri May 24 15:21:23
2019(r348239)
@@ -39,7 +39,7 @@ cust_install_machine_files() (
MACHINE_DIR="${NANO_TOOLS}/Files.${NANO_NAME}"
if [ -d "${MACHINE_DIR}" ]; then
cd ${MACHINE_DIR}
-find . -print | grep -Ev '/(CVS|\.svn)' | cpio -dumpv ${NANO_WORLDDIR}
+find . -print | grep -Ev '/(CVS|\.git|\.hg|\.svn)' | cpio -dumpv
${NANO_WORLDDIR}
else
echo "${MACHINE_DIR} not found, skipping step"
fi
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348241 - head
Author: markj
Date: Fri May 24 15:45:43 2019
New Revision: 348241
URL: https://svnweb.freebsd.org/changeset/base/348241
Log:
Modernize the MAKE_JUST_KERNELS hint in the top-level makefile.
It doesn't make sense to limit to -j12 anymore, build scalability
is better than it used to be. Fold the hint into the description
of the universe target.
Reviewed by: imp
MFC after:1 week
Differential Revision:https://reviews.freebsd.org/D20342
Modified:
head/Makefile
Modified: head/Makefile
==
--- head/Makefile Fri May 24 15:37:54 2019(r348240)
+++ head/Makefile Fri May 24 15:45:43 2019(r348241)
@@ -4,7 +4,8 @@
# The user-driven targets are:
#
# universe- *Really* build *everything* (buildworld and
-# all kernels on all architectures).
+# all kernels on all architectures). Define the
+# MAKE_JUST_KERNELS variable to only build kernels.
# tinderbox - Same as universe, but presents a list of failed build
# targets and exits with an error if there were any.
# buildworld - Rebuild *everything*, including glue to help do
@@ -45,12 +46,6 @@
# native-xtools-install
# - Install the files to the given DESTDIR/NXTP where
# NXTP defaults to /nxb-bin.
-#
-# "quick" way to test all kernel builds:
-# _jflag=`sysctl -n hw.ncpu`
-# _jflag=$(($_jflag * 2))
-# [ $_jflag -gt 12 ] && _jflag=12
-# make universe -DMAKE_JUST_KERNELS JFLAG=-j${_jflag}
#
# This makefile is simple by design. The FreeBSD make automatically reads
# the /usr/share/mk/sys.mk unless the -m argument is specified on the
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348241 - head
On 2019-05-24 11:45, Mark Johnston wrote: Modernize the MAKE_JUST_KERNELS hint in the top-level makefile. It doesn't make sense to limit to -j12 anymore, build scalability is better than it used to be. Fold the hint into the description of the universe target. Reviewed by: imp Dumb question about this: Will it update toolchains, or just use what can find? Thanks, Drew ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348241 - head
On Fri, May 24, 2019 at 9:24 AM Andrew Gallatin wrote:
> Dumb question about this: Will it update toolchains, or just use what
> can find?
-DMAKE_JUST_KERNELS doesn't touch toolchains. For that, there is the
less memorable build step:
export NCPU=$((1 * $(sysctl -n hw.ncpu) / 3)); make -sj${NCPU}
tinderbox JFLAG=-j${NCPU} UNIVERSE_TARGET=kernel-toolchain -DNO_CLEAN
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348246 - in head/sys: amd64/amd64 i386/i386
Author: kib
Date: Fri May 24 17:19:06 2019
New Revision: 348246
URL: https://svnweb.freebsd.org/changeset/base/348246
Log:
Fix a corner case in demotion of kernel mappings.
It is possible for the kernel mapping to be created with superpage by
directly installing pde using pmap_enter_2mpage() without filling the
corresponding page table page. This can happen e.g. if the range is
already backed by reservation and vm_fault_soft_fast() conditions are
satisfied, which was observed on the pipe_map.
In this case, demotion must fill the page obtained from the pmap
radix, same as if the page is newly allocated. Use PG_PROMOTED bit as
an indicator that the page is valid, instead of the wire count of the
page table page.
Since the PG_PROMOTED bit is set on pde when we leave TLB entries for
4k pages around, which in particular means that the ptes were filled,
it provides more correct indicator. Note that pmap_protect_pde()
clears PG_PROMOTED, which handles the case when protection was changed
on the superpage without adjusting ptes.
Reported by: pho
In collaboration with:alc
Tested by:alc, pho
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Differential revision:https://reviews.freebsd.org/D20380
Modified:
head/sys/amd64/amd64/pmap.c
head/sys/i386/i386/pmap.c
Modified: head/sys/amd64/amd64/pmap.c
==
--- head/sys/amd64/amd64/pmap.c Fri May 24 17:14:07 2019(r348245)
+++ head/sys/amd64/amd64/pmap.c Fri May 24 17:19:06 2019(r348246)
@@ -4537,8 +4537,10 @@ pmap_demote_pde_locked(pmap_t pmap, pd_entry_t *pde, v
" in pmap %p", va, pmap);
return (FALSE);
}
- if (va < VM_MAXUSER_ADDRESS)
+ if (va < VM_MAXUSER_ADDRESS) {
+ mpte->wire_count = NPTEPG;
pmap_resident_count_inc(pmap, 1);
+ }
}
mptepa = VM_PAGE_TO_PHYS(mpte);
firstpte = (pt_entry_t *)PHYS_TO_DMAP(mptepa);
@@ -4551,12 +4553,12 @@ pmap_demote_pde_locked(pmap_t pmap, pd_entry_t *pde, v
newpte = pmap_swap_pat(pmap, newpte);
/*
-* If the page table page is new, initialize it.
+* If the page table page is not leftover from an earlier promotion,
+* initialize it.
*/
- if (mpte->wire_count == 1) {
- mpte->wire_count = NPTEPG;
+ if ((oldpde & PG_PROMOTED) == 0)
pmap_fill_ptp(firstpte, newpte);
- }
+
KASSERT((*firstpte & PG_FRAME) == (newpte & PG_FRAME),
("pmap_demote_pde: firstpte and newpte map different physical"
" addresses"));
Modified: head/sys/i386/i386/pmap.c
==
--- head/sys/i386/i386/pmap.c Fri May 24 17:14:07 2019(r348245)
+++ head/sys/i386/i386/pmap.c Fri May 24 17:19:06 2019(r348246)
@@ -2768,8 +2768,10 @@ pmap_demote_pde(pmap_t pmap, pd_entry_t *pde, vm_offse
" in pmap %p", va, pmap);
return (FALSE);
}
- if (pmap != kernel_pmap)
+ if (pmap != kernel_pmap) {
+ mpte->wire_count = NPTEPG;
pmap->pm_stats.resident_count++;
+ }
}
mptepa = VM_PAGE_TO_PHYS(mpte);
@@ -2818,12 +2820,12 @@ pmap_demote_pde(pmap_t pmap, pd_entry_t *pde, vm_offse
newpte ^= PG_PDE_PAT | PG_PTE_PAT;
/*
-* If the page table page is new, initialize it.
+* If the page table page is not leftover from an earlier promotion,
+* initialize it.
*/
- if (mpte->wire_count == 1) {
- mpte->wire_count = NPTEPG;
+ if ((oldpde & PG_PROMOTED) == 0)
pmap_fill_ptp(firstpte, newpte);
- }
+
KASSERT((*firstpte & PG_FRAME) == (newpte & PG_FRAME),
("pmap_demote_pde: firstpte and newpte map different physical"
" addresses"));
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348241 - head
On Fri, May 24, 2019 at 10:08:53AM -0700, Conrad Meyer wrote:
> On Fri, May 24, 2019 at 9:24 AM Andrew Gallatin wrote:
> > Dumb question about this: Will it update toolchains, or just use what
> > can find?
>
> -DMAKE_JUST_KERNELS doesn't touch toolchains. For that, there is the
> less memorable build step:
>
> export NCPU=$((1 * $(sysctl -n hw.ncpu) / 3)); make -sj${NCPU}
> tinderbox JFLAG=-j${NCPU} UNIVERSE_TARGET=kernel-toolchain -DNO_CLEAN
Isn't that basically what the kernel-toolchains target does?
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348241 - head
On 5/24/19 10:08 AM, Conrad Meyer wrote:
> On Fri, May 24, 2019 at 9:24 AM Andrew Gallatin wrote:
>> Dumb question about this: Will it update toolchains, or just use what
>> can find?
>
> -DMAKE_JUST_KERNELS doesn't touch toolchains. For that, there is the
> less memorable build step:
>
> export NCPU=$((1 * $(sysctl -n hw.ncpu) / 3)); make -sj${NCPU}
> tinderbox JFLAG=-j${NCPU} UNIVERSE_TARGET=kernel-toolchain -DNO_CLEAN
You can spell it slightly shorter as 'make kernel-toolchains' (but still
needing -j, etc.)
--
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348247 - head/sys/dev/isp
Author: ken
Date: Fri May 24 17:58:29 2019
New Revision: 348247
URL: https://svnweb.freebsd.org/changeset/base/348247
Log:
Fix FC-Tape bugs caused in part by r345008.
The point of r345008 was to reset the Command Reference Number (CRN)
in some situations where a device stayed in the topology, but had
changed somehow.
This can include moving from a switch connection to a direct
connection or vice versa, or a device that temporarily goes away
and comes back. (e.g. moving to a different switch port)
There were a couple of bugs in that change:
- We were reporting that a device had not changed whenever the
Establish Image Pair bit was not set. That is not quite correct.
Instead, if the Establish Image Pair bit stays the same (set or
not), the device hasn't changed in that way.
- We weren't setting PRLI Word0 in the port database when a new
device arrived, so comparisons with the old value for the
Establish Image Pair bit weren't really possible. So, make sure
PRLI Word0 is set in the port database for new devices.
- We were resetting the CRN whenever the Establish Image Pair bit
was set for a device, even when the device had stayed the same
and the value of the bit hadn't changed. Now, only reset the
CRN for devices that have changed, not devices that sayed the
same.
The result of all of this was that if we had a single FC device on
an FC port and it went away and came back, we would wind up
correctly resetting the CRN.
But, if we had multiple devices connected via a switch, and there
was any change in one or more of those devices, all of the devices
that stayed the same would also have their CRN values reset.
The result, from a user standpoint, is that the tape drives, etc.
would all start to time out commands and the initiator would send
aborts.
sys/dev/isp/isp.c:
In isp_pdb_add_update(), look at whether the Establish
Image Pair bit has changed as part of the check to
determine whether a device is still the same. This was
causing erroneous change notifications. Also, when
creating a new port database entry, initialize the
PRLI Word 0 values.
sys/dev/isp/isp_freebsd.c:
In isp_async(), in the changed/stayed case, instead of
looking at the Establish Image Pair bit to determine
whether to reset the CRN, look at the command value.
(Changed vs. Stayed.) Only reset the CRN for devices
that have changed.
Sponsored by: Spectra Logic
MFC after:3 days
Modified:
head/sys/dev/isp/isp.c
head/sys/dev/isp/isp_freebsd.c
Modified: head/sys/dev/isp/isp.c
==
--- head/sys/dev/isp/isp.c Fri May 24 17:19:06 2019(r348246)
+++ head/sys/dev/isp/isp.c Fri May 24 17:58:29 2019(r348247)
@@ -3251,7 +3251,8 @@ isp_pdb_add_update(ispsoftc_t *isp, int chan, isp_pdb_
if (lp->portid == pdb->portid &&
lp->handle == pdb->handle &&
lp->prli_word3 == pdb->prli_word3 &&
- ((pdb->prli_word0 & PRLI_WD0_EST_IMAGE_PAIR) == 0)) {
+ ((pdb->prli_word0 & PRLI_WD0_EST_IMAGE_PAIR) ==
+(lp->prli_word0 & PRLI_WD0_EST_IMAGE_PAIR))) {
if (lp->state != FC_PORTDB_STATE_NEW)
lp->state = FC_PORTDB_STATE_VALID;
isp_prt(isp, ISP_LOG_SANCFG,
@@ -3282,6 +3283,7 @@ isp_pdb_add_update(ispsoftc_t *isp, int chan, isp_pdb_
lp->probational = 0;
lp->state = FC_PORTDB_STATE_NEW;
lp->portid = lp->new_portid = pdb->portid;
+ lp->prli_word0 = lp->new_prli_word0 = pdb->prli_word0;
lp->prli_word3 = lp->new_prli_word3 = pdb->prli_word3;
lp->handle = pdb->handle;
lp->port_wwn = wwpn;
Modified: head/sys/dev/isp/isp_freebsd.c
==
--- head/sys/dev/isp/isp_freebsd.c Fri May 24 17:19:06 2019
(r348246)
+++ head/sys/dev/isp/isp_freebsd.c Fri May 24 17:58:29 2019
(r348247)
@@ -3789,7 +3789,7 @@ isp_async(ispsoftc_t *isp, ispasync_t cmd, ...)
xpt_async(AC_CONTRACT, fc->path, &ac);
}
- if ((lp->new_prli_word0 & PRLI_WD0_EST_IMAGE_PAIR) &&
+ if ((cmd == ISPASYNC_DEV_CHANGED) &&
(crn_reset_done == 0))
isp_fcp_reset_crn(isp, bus, tgt, /*tgt_set*/ 1);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348248 - head/sys/powerpc/conf
Author: luporl Date: Fri May 24 18:41:31 2019 New Revision: 348248 URL: https://svnweb.freebsd.org/changeset/base/348248 Log: Make options MD_ROOT_MEM default on PPC64 Having this option enabled by default on PowerPC64 kernels makes booting ISO images much easier when on PowerNV. With it, the ISO may simply be given to the -i flag of kexec. Better yet, the ISO may be loop mounted on PetitBoot and its kernel may be used to load itself. Without this option, booting ISOs on remote PPC64 machines usually involve preparing a separate kernel, with this option enabled. Modified: head/sys/powerpc/conf/GENERIC64 Modified: head/sys/powerpc/conf/GENERIC64 == --- head/sys/powerpc/conf/GENERIC64 Fri May 24 17:58:29 2019 (r348247) +++ head/sys/powerpc/conf/GENERIC64 Fri May 24 18:41:31 2019 (r348248) @@ -53,6 +53,7 @@ options UFS_DIRHASH #Improve performance on big dire optionsUFS_GJOURNAL#Enable gjournal-based UFS journaling optionsQUOTA #Enable disk quotas for UFS optionsMD_ROOT #MD is a potential root device +optionsMD_ROOT_MEM #Enable use of initrd as MD root optionsNFSCL #Network Filesystem Client optionsNFSD#Network Filesystem Server optionsNFSLOCKD#Network Lock Manager ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348249 - in head/stand: . ficl libsa
Author: sjg
Date: Fri May 24 19:43:38 2019
New Revision: 348249
URL: https://svnweb.freebsd.org/changeset/base/348249
Log:
ficl pfopen: verify file
If the file is verified - do not allow write
otherwise do not allow read.
Add O_ACCMODE to stand.h
Reviewed by: stevek, mindal_semihalf.com
MFC after:3 days
Sponsored by: Juniper Networks
Differential Revision:https://reviews.freebsd.org/D20387
Modified:
head/stand/ficl.mk
head/stand/ficl/loader.c
head/stand/libsa/stand.h
Modified: head/stand/ficl.mk
==
--- head/stand/ficl.mk Fri May 24 18:41:31 2019(r348248)
+++ head/stand/ficl.mk Fri May 24 19:43:38 2019(r348249)
@@ -16,3 +16,7 @@ CFLAGS+= -fPIC
CFLAGS+= -I${FICLSRC} -I${FICLSRC}/${FICL_CPUARCH} -I${LDRSRC}
CFLAGS+= -DBF_DICTSIZE=15000
+
+.if ${MK_LOADER_VERIEXEC} != "no"
+CFLAGS+= -DLOADER_VERIEXEC -I${SRCTOP}/lib/libsecureboot/h
+.endif
Modified: head/stand/ficl/loader.c
==
--- head/stand/ficl/loader.cFri May 24 18:41:31 2019(r348248)
+++ head/stand/ficl/loader.cFri May 24 19:43:38 2019(r348249)
@@ -502,6 +502,23 @@ static void pfopen(FICL_VM *pVM)
/* open the file */
fd = open(name, mode);
+#ifdef LOADER_VERIEXEC
+if (fd >= 0) {
+ if (verify_file(fd, name, 0, VE_GUESS) < 0) {
+ /* not verified writing ok but reading is not */
+ if ((mode & O_ACCMODE) != O_WRONLY) {
+ close(fd);
+ fd = -1;
+ }
+ } else {
+ /* verified reading ok but writing is not */
+ if ((mode & O_ACCMODE) != O_RDONLY) {
+ close(fd);
+ fd = -1;
+ }
+ }
+}
+#endif
free(name);
stackPushINT(pVM->pStack, fd);
return;
Modified: head/stand/libsa/stand.h
==
--- head/stand/libsa/stand.hFri May 24 18:41:31 2019(r348248)
+++ head/stand/libsa/stand.hFri May 24 19:43:38 2019(r348249)
@@ -286,6 +286,7 @@ extern int open(const char *, int);
#defineO_RDONLY0x0
#define O_WRONLY 0x1
#define O_RDWR 0x2
+#define O_ACCMODE 0x3
/* NOT IMPLEMENTED */
#defineO_CREAT 0x0200 /* create if nonexistent */
#defineO_TRUNC 0x0400 /* truncate to zero length */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348250 - head/sys/powerpc/conf
Author: pkubaj (ports committer) Date: Fri May 24 20:01:59 2019 New Revision: 348250 URL: https://svnweb.freebsd.org/changeset/base/348250 Log: Add snd_hda(4) to GENERIC64 used by powerpc64. amd64 also has snd_hda(4) in GENERIC. Approved by: jhibbits (src committer), linimon (mentor) Modified: head/sys/powerpc/conf/GENERIC64 Modified: head/sys/powerpc/conf/GENERIC64 == --- head/sys/powerpc/conf/GENERIC64 Fri May 24 19:43:38 2019 (r348249) +++ head/sys/powerpc/conf/GENERIC64 Fri May 24 20:01:59 2019 (r348250) @@ -246,6 +246,7 @@ device pmu # Sound support device sound # Generic sound driver (required) device snd_ai2s# Apple I2S audio +device snd_hda # Intel High Definition Audio device snd_uaudio # USB Audio # Netmap provides direct access to TX/RX rings on supported NICs ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348250 - head/sys/powerpc/conf
On Fri, 24 May 2019 20:01:59 + (UTC) Piotr Kubaj wrote: > Author: pkubaj (ports committer) > Date: Fri May 24 20:01:59 2019 > New Revision: 348250 > URL: https://svnweb.freebsd.org/changeset/base/348250 > > Log: > Add snd_hda(4) to GENERIC64 used by powerpc64. > > amd64 also has snd_hda(4) in GENERIC. > > Approved by:jhibbits (src committer), linimon (mentor) > > Modified: > head/sys/powerpc/conf/GENERIC64 > > Modified: head/sys/powerpc/conf/GENERIC64 > == > --- head/sys/powerpc/conf/GENERIC64 Fri May 24 19:43:38 > 2019 (r348249) +++ head/sys/powerpc/conf/GENERIC64 Fri > May 24 20:01:59 2019 (r348250) @@ -246,6 +246,7 @@ > devicepmu # Sound support > device sound # Generic sound driver > (required) device snd_ai2s# Apple I2S audio > +device snd_hda # Intel High Definition > Audio device snd_uaudio # USB Audio > > # Netmap provides direct access to TX/RX rings on supported NICs > To note: This was done because there's a strange bug in the snd_hda module, with the hdaa component. For some reason it either doesn't find all the internal components it needs, or something, because there's a NULL dereference when trying to call a kobj method in hdaa_attach(). - Justin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348250 - head/sys/powerpc/conf
On Fri, May 24, 2019 at 03:16:51PM -0500, Justin Hibbits wrote: > On Fri, 24 May 2019 20:01:59 + (UTC) Piotr Kubaj wrote: > > New Revision: 348250 > > URL: https://svnweb.freebsd.org/changeset/base/348250 > > > > Log: > > Add snd_hda(4) to GENERIC64 used by powerpc64. > > > > amd64 also has snd_hda(4) in GENERIC. > > > > Modified: > > head/sys/powerpc/conf/GENERIC64 > > ... > > To note: This was done because there's a strange bug in the snd_hda > module, with the hdaa component. For some reason it either doesn't > find all the internal components it needs, or something, because > there's a NULL dereference when trying to call a kobj method in > hdaa_attach(). So this commit essentially masks the real bug somewhere rather than fixing it, is this what you're saying? ./danfe ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348251 - in head/sys: fs/ext2fs fs/fuse fs/msdosfs fs/nfsclient kern sys ufs/ffs
Author: asomers
Date: Fri May 24 20:27:50 2019
New Revision: 348251
URL: https://svnweb.freebsd.org/changeset/base/348251
Log:
Remove "struct ucred*" argument from vtruncbuf
vtruncbuf takes a "struct ucred*" argument. AFAICT, it's been unused ever
since that function was first added in r34611. Remove it. Also, remove some
"struct ucred" arguments from fuse and nfs functions that were only used by
vtruncbuf.
Reviewed by: cem
MFC after:2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision:https://reviews.freebsd.org/D20377
Modified:
head/sys/fs/ext2fs/ext2_inode.c
head/sys/fs/fuse/fuse_io.c
head/sys/fs/fuse/fuse_node.c
head/sys/fs/fuse/fuse_node.h
head/sys/fs/fuse/fuse_vnops.c
head/sys/fs/msdosfs/msdosfs_denode.c
head/sys/fs/nfsclient/nfs.h
head/sys/fs/nfsclient/nfs_clbio.c
head/sys/fs/nfsclient/nfs_clvnops.c
head/sys/kern/vfs_subr.c
head/sys/sys/vnode.h
head/sys/ufs/ffs/ffs_inode.c
Modified: head/sys/fs/ext2fs/ext2_inode.c
==
--- head/sys/fs/ext2fs/ext2_inode.c Fri May 24 20:01:59 2019
(r348250)
+++ head/sys/fs/ext2fs/ext2_inode.c Fri May 24 20:27:50 2019
(r348251)
@@ -356,7 +356,7 @@ ext2_ind_truncate(struct vnode *vp, off_t length, int
oip->i_ib[i] = oldblks[EXT2_NDADDR + i];
}
oip->i_size = osize;
- error = vtruncbuf(ovp, cred, length, (int)fs->e2fs_bsize);
+ error = vtruncbuf(ovp, length, (int)fs->e2fs_bsize);
if (error && (allerror == 0))
allerror = error;
vnode_pager_setsize(ovp, length);
@@ -530,7 +530,7 @@ ext2_ext_truncate(struct vnode *vp, off_t length, int
}
oip->i_size = osize;
- error = vtruncbuf(ovp, cred, length, (int)fs->e2fs_bsize);
+ error = vtruncbuf(ovp, length, (int)fs->e2fs_bsize);
if (error)
return (error);
Modified: head/sys/fs/fuse/fuse_io.c
==
--- head/sys/fs/fuse/fuse_io.c Fri May 24 20:01:59 2019(r348250)
+++ head/sys/fs/fuse/fuse_io.c Fri May 24 20:27:50 2019(r348251)
@@ -389,7 +389,7 @@ fuse_write_directbackend(struct vnode *vp, struct uio
if (uio->uio_offset > fvdat->filesize &&
fuse_data_cache_mode != FUSE_CACHE_UC) {
- fuse_vnode_setsize(vp, cred, uio->uio_offset);
+ fuse_vnode_setsize(vp, uio->uio_offset);
fvdat->flag &= ~FN_SIZECHANGE;
}
}
@@ -462,7 +462,7 @@ again:
if (bp != NULL) {
long save;
- err = fuse_vnode_setsize(vp, cred,
+ err = fuse_vnode_setsize(vp,
uio->uio_offset + n);
if (err) {
brelse(bp);
@@ -490,7 +490,7 @@ again:
lbn, on, n, uio, bcount, false);
bp = getblk(vp, lbn, bcount, PCATCH, 0, 0);
if (bp && uio->uio_offset + n > fvdat->filesize) {
- err = fuse_vnode_setsize(vp, cred,
+ err = fuse_vnode_setsize(vp,
uio->uio_offset + n);
if (err) {
brelse(bp);
Modified: head/sys/fs/fuse/fuse_node.c
==
--- head/sys/fs/fuse/fuse_node.cFri May 24 20:01:59 2019
(r348250)
+++ head/sys/fs/fuse/fuse_node.cFri May 24 20:27:50 2019
(r348251)
@@ -408,7 +408,7 @@ fuse_vnode_refreshsize(struct vnode *vp, struct ucred
}
int
-fuse_vnode_setsize(struct vnode *vp, struct ucred *cred, off_t newsize)
+fuse_vnode_setsize(struct vnode *vp, off_t newsize)
{
struct fuse_vnode_data *fvdat = VTOFUD(vp);
off_t oldsize;
@@ -421,7 +421,7 @@ fuse_vnode_setsize(struct vnode *vp, struct ucred *cre
fvdat->flag |= FN_SIZECHANGE;
if (newsize < oldsize) {
- err = vtruncbuf(vp, cred, newsize, fuse_iosize(vp));
+ err = vtruncbuf(vp, newsize, fuse_iosize(vp));
}
vnode_pager_setsize(vp, newsize);
return err;
Modified: head/sys/fs/fuse/fuse_node.h
==
--- head/sys/fs/fuse/fuse_node.hFri May 24 20:01:59 2019
(r348250)
+++ head/sys/fs/fuse/fuse_node.hFri May 24 20:27:50 2019
(r348251)
@@ -127,6 +127,6 @@ void fuse_vnode_refreshsize(struct vnode *vp, struct u
int fuse_vnode_savesize(struct vnode *vp, struct ucred *cred);
-int fuse_vnode_setsize(struct vnode *vp,
Re: svn commit: r348250 - head/sys/powerpc/conf
On Fri, 24 May 2019 20:22:52 + Alexey Dokuchaev wrote: > On Fri, May 24, 2019 at 03:16:51PM -0500, Justin Hibbits wrote: > > On Fri, 24 May 2019 20:01:59 + (UTC) Piotr Kubaj wrote: > > > New Revision: 348250 > > > URL: https://svnweb.freebsd.org/changeset/base/348250 > > > > > > Log: > > > Add snd_hda(4) to GENERIC64 used by powerpc64. > > > > > > amd64 also has snd_hda(4) in GENERIC. > > > > > > Modified: > > > head/sys/powerpc/conf/GENERIC64 > > > ... > > > > To note: This was done because there's a strange bug in the snd_hda > > module, with the hdaa component. For some reason it either doesn't > > find all the internal components it needs, or something, because > > there's a NULL dereference when trying to call a kobj method in > > hdaa_attach(). > > So this commit essentially masks the real bug somewhere rather than > fixing it, is this what you're saying? > > ./danfe It's a viable workaround to a problem that reaches a wide audience. Since it works built-in, I found it acceptable. I probably should have filed a bug for it a year ago when I hit it and worked around it, but it could also very well be a compiler issue. By the way, it works fine on powerpc (32-bit) loaded as a module. - Justin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348253 - head/usr.sbin/bhyve
Author: jhb
Date: Fri May 24 22:11:37 2019
New Revision: 348253
URL: https://svnweb.freebsd.org/changeset/base/348253
Log:
Add initial support for 'qSupported' to the debug server.
This doesn't recognize any features yet, but does parse the features
string. It advertises an arbitrary packet size of 4k.
Reviewed by: markj, Scott Phillips
MFC after:2 weeks
Differential Revision:https://reviews.freebsd.org/D20308
Modified:
head/usr.sbin/bhyve/gdb.c
Modified: head/usr.sbin/bhyve/gdb.c
==
--- head/usr.sbin/bhyve/gdb.c Fri May 24 20:36:07 2019(r348252)
+++ head/usr.sbin/bhyve/gdb.c Fri May 24 22:11:37 2019(r348253)
@@ -993,13 +993,72 @@ command_equals(const uint8_t *data, size_t len, const
}
static void
+check_features(const uint8_t *data, size_t len)
+{
+ char *feature, *next_feature, *str, *value;
+ bool supported;
+
+ str = malloc(len + 1);
+ memcpy(str, data, len);
+ str[len] = '\0';
+ next_feature = str;
+
+ while ((feature = strsep(&next_feature, ";")) != NULL) {
+ /*
+* Null features shouldn't exist, but skip if they
+* do.
+*/
+ if (strcmp(feature, "") == 0)
+ continue;
+
+ /*
+* Look for the value or supported / not supported
+* flag.
+*/
+ value = strchr(feature, '=');
+ if (value != NULL) {
+ *value = '\0';
+ value++;
+ supported = true;
+ } else {
+ value = feature + strlen(feature) - 1;
+ switch (*value) {
+ case '+':
+ supported = true;
+ break;
+ case '-':
+ supported = false;
+ break;
+ default:
+ /*
+* This is really a protocol error,
+* but we just ignore malformed
+* features for ease of
+* implementation.
+*/
+ continue;
+ }
+ value = NULL;
+ }
+
+ /* No currently supported features. */
+ }
+ free(str);
+
+ start_packet();
+
+ /* This is an arbitrary limit. */
+ append_string("PacketSize=4096");
+ finish_packet();
+}
+
+static void
gdb_query(const uint8_t *data, size_t len)
{
/*
* TODO:
* - qSearch
-* - qSupported
*/
if (command_equals(data, len, "qAttached")) {
start_packet();
@@ -1037,6 +1096,10 @@ gdb_query(const uint8_t *data, size_t len)
start_packet();
append_char('l');
finish_packet();
+ } else if (command_equals(data, len, "qSupported")) {
+ data += strlen("qSupported");
+ len -= strlen("qSupported");
+ check_features(data, len);
} else if (command_equals(data, len, "qThreadExtraInfo")) {
char buf[16];
int tid;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348254 - in head/sys: dev/cxgbe dev/mlx5/mlx5_en kern net net80211 netinet netinet6 netpfil/ipfw sys
Author: jhb Date: Fri May 24 22:30:40 2019 New Revision: 348254 URL: https://svnweb.freebsd.org/changeset/base/348254 Log: Restructure mbuf send tags to provide stronger guarantees. - Perform ifp mismatch checks (to determine if a send tag is allocated for a different ifp than the one the packet is being output on), in ip_output() and ip6_output(). This avoids sending packets with send tags to ifnet drivers that don't support send tags. Since we are now checking for ifp mismatches before invoking if_output, we can now try to allocate a new tag before invoking if_output sending the original packet on the new tag if allocation succeeds. To avoid code duplication for the fragment and unfragmented cases, add ip_output_send() and ip6_output_send() as wrappers around if_output and nd6_output_ifp, respectively. All of the logic for setting send tags and dealing with send tag-related errors is done in these wrapper functions. For pseudo interfaces that wrap other network interfaces (vlan and lagg), wrapper send tags are now allocated so that ip*_output see the wrapper ifp as the ifp in the send tag. The if_transmit routines rewrite the send tags after performing an ifp mismatch check. If an ifp mismatch is detected, the transmit routines fail with EAGAIN. - To provide clearer life cycle management of send tags, especially in the presence of vlan and lagg wrapper tags, add a reference count to send tags managed via m_snd_tag_ref() and m_snd_tag_rele(). Provide a helper function (m_snd_tag_init()) for use by drivers supporting send tags. m_snd_tag_init() takes care of the if_ref on the ifp meaning that code alloating send tags via if_snd_tag_alloc no longer has to manage that manually. Similarly, m_snd_tag_rele drops the refcount on the ifp after invoking if_snd_tag_free when the last reference to a send tag is dropped. This also closes use after free races if there are pending packets in driver tx rings after the socket is closed (e.g. from tcpdrop). In order for m_free to work reliably, add a new CSUM_SND_TAG flag in csum_flags to indicate 'snd_tag' is set (rather than 'rcvif'). Drivers now also check this flag instead of checking snd_tag against NULL. This avoids false positive matches when a forwarded packet has a non-NULL rcvif that was treated as a send tag. - cxgbe was relying on snd_tag_free being called when the inp was detached so that it could kick the firmware to flush any pending work on the flow. This is because the driver doesn't require ACK messages from the firmware for every request, but instead does a kind of manual interrupt coalescing by only setting a flag to request a completion on a subset of requests. If all of the in-flight requests don't have the flag when the tag is detached from the inp, the flow might never return the credits. The current snd_tag_free command issues a flush command to force the credits to return. However, the credit return is what also frees the mbufs, and since those mbufs now hold references on the tag, this meant that snd_tag_free would never be called. To fix, explicitly drop the mbuf's reference on the snd tag when the mbuf is queued in the firmware work queue. This means that once the inp's reference on the tag goes away and all in-flight mbufs have been queued to the firmware, tag's refcount will drop to zero and snd_tag_free will kick in and send the flush request. Note that we need to avoid doing this in the middle of ethofld_tx(), so the driver grabs a temporary reference on the tag around that loop to defer the free to the end of the function in case it sends the last mbuf to the queue after the inp has dropped its reference on the tag. - mlx5 preallocates send tags and was using the ifp pointer even when the send tag wasn't in use. Explicitly use the ifp from other data structures instead. - Sprinkle some assertions in various places to assert that received packets don't have a send tag, and that other places that overwrite rcvif (e.g. 802.11 transmit) don't clobber a send tag pointer. Reviewed by: gallatin, hselasky, rgrimes, ae Sponsored by: Netflix Differential Revision:https://reviews.freebsd.org/D20117 Modified: head/sys/dev/cxgbe/t4_main.c head/sys/dev/cxgbe/t4_sched.c head/sys/dev/cxgbe/t4_sge.c head/sys/dev/mlx5/mlx5_en/mlx5_en_main.c head/sys/dev/mlx5/mlx5_en/mlx5_en_rl.c head/sys/dev/mlx5/mlx5_en/mlx5_en_tx.c head/sys/kern/kern_mbuf.c head/sys/kern/uipc_mbuf.c head/sys/net/bpf.c head/sys/net/if.c head/sys/net/if_ethersubr.c head/sys/net/if_lagg.c head/sys/net/if_vlan.c head/sys/net/netisr.c head/sys/net80211/ieee80211_hwmp.c head/sys/net80211/ieee80211_mesh.c head/sys/net80211/ieee80211_output.c head/sys/net
svn commit: r348255 - head/sys/kern
Author: cem Date: Fri May 24 22:33:14 2019 New Revision: 348255 URL: https://svnweb.freebsd.org/changeset/base/348255 Log: Disable intr_storm_threshold mechanism by default The ixl.4 manual page has documented that the threshold falsely detects interrupt storms on 40Gbit NICs as long ago as 2015, and we have seen similar false positives with the ioat(4) DMA device (which can push GB/s). For example, synthetic load can be generated with tools/tools/ioat 'ioatcontrol 0 200 8192 1 1000' (allocate 200x8kB buffers, generate an interrupt for each one, and do this for 1000 milliseconds). With storm-detection disabled, the Broadwell-EP version of this device is capable of generating ~350k real interrupts per second. The following historical context comes from jhb@: Originally, the threshold worked around incorrect routing of PCI INTx interrupts on single-CPU systems which would end up in a hard hang during boot. Since the threshold was added, our PCI interrupt routing was improved, most PCI interrupts use edge-triggered MSI instead of level-triggered INTx, and typical systems have multiple CPUs available to service interrupts. On the off chance that the threshold is useful in the future, it remains available as a tunable and sysctl. Reviewed by: jhb Sponsored by: Dell EMC Isilon Differential Revision:https://reviews.freebsd.org/D20401 Modified: head/sys/kern/kern_intr.c Modified: head/sys/kern/kern_intr.c == --- head/sys/kern/kern_intr.c Fri May 24 22:30:40 2019(r348254) +++ head/sys/kern/kern_intr.c Fri May 24 22:33:14 2019(r348255) @@ -91,7 +91,7 @@ struct proc *intrproc; static MALLOC_DEFINE(M_ITHREAD, "ithread", "Interrupt Threads"); -static int intr_storm_threshold = 1000; +static int intr_storm_threshold = 0; SYSCTL_INT(_hw, OID_AUTO, intr_storm_threshold, CTLFLAG_RWTUN, &intr_storm_threshold, 0, "Number of consecutive interrupts before storm protection is enabled"); ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348250 - head/sys/powerpc/conf
> On Fri, 24 May 2019 20:22:52 + > Alexey Dokuchaev wrote: > > > On Fri, May 24, 2019 at 03:16:51PM -0500, Justin Hibbits wrote: > > > On Fri, 24 May 2019 20:01:59 + (UTC) Piotr Kubaj wrote: > > > > New Revision: 348250 > > > > URL: https://svnweb.freebsd.org/changeset/base/348250 > > > > > > > > Log: > > > > Add snd_hda(4) to GENERIC64 used by powerpc64. > > > > > > > > amd64 also has snd_hda(4) in GENERIC. > > > > > > > > Modified: > > > > head/sys/powerpc/conf/GENERIC64 > > > > ... > > > > > > To note: This was done because there's a strange bug in the snd_hda > > > module, with the hdaa component. For some reason it either doesn't > > > find all the internal components it needs, or something, because > > > there's a NULL dereference when trying to call a kobj method in > > > hdaa_attach(). > > > > So this commit essentially masks the real bug somewhere rather than > > fixing it, is this what you're saying? > > > > ./danfe > > It's a viable workaround to a problem that reaches a wide audience. > Since it works built-in, I found it acceptable. I probably should have > filed a bug for it a year ago when I hit it and worked around it, but it > could also very well be a compiler issue. > > By the way, it works fine on powerpc (32-bit) loaded as a module. Please do file a bug report now, please do mark the line in GENERIC64 with a comment XXX This is needed to work around foo so that it is documented why it is there and someone removing it does not go down a rabit hole others have already been down, and so that some day someone may go down that rabbit hole of there own free will and fix this for us. Paving over the top of obscure bugs with a hackish fix is ok, not documenting this state of affairs is not, IMHO. > - Justin -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348255 - head/sys/kern
Just wanted to say I really appreciate the details in this commit message. Its often the case the message get overlooked when it comes to the time needed to write a truly useful message to others and this a great example of the quality we should all try to follow. Regards Steve On Fri, 24 May 2019 at 23:33, Conrad Meyer wrote: > Author: cem > Date: Fri May 24 22:33:14 2019 > New Revision: 348255 > URL: https://svnweb.freebsd.org/changeset/base/348255 > > Log: > Disable intr_storm_threshold mechanism by default > > The ixl.4 manual page has documented that the threshold falsely detects > interrupt storms on 40Gbit NICs as long ago as 2015, and we have seen > similar false positives with the ioat(4) DMA device (which can push > GB/s). > > For example, synthetic load can be generated with tools/tools/ioat > 'ioatcontrol 0 200 8192 1 1000' (allocate 200x8kB buffers, generate an > interrupt for each one, and do this for 1000 milliseconds). With > storm-detection disabled, the Broadwell-EP version of this device is > capable > of generating ~350k real interrupts per second. > > The following historical context comes from jhb@: Originally, the > threshold > worked around incorrect routing of PCI INTx interrupts on single-CPU > systems > which would end up in a hard hang during boot. Since the threshold was > added, our PCI interrupt routing was improved, most PCI interrupts use > edge-triggered MSI instead of level-triggered INTx, and typical systems > have > multiple CPUs available to service interrupts. > > On the off chance that the threshold is useful in the future, it remains > available as a tunable and sysctl. > > Reviewed by: jhb > Sponsored by: Dell EMC Isilon > Differential Revision:https://reviews.freebsd.org/D20401 > > Modified: > head/sys/kern/kern_intr.c > > Modified: head/sys/kern/kern_intr.c > > == > --- head/sys/kern/kern_intr.c Fri May 24 22:30:40 2019(r348254) > +++ head/sys/kern/kern_intr.c Fri May 24 22:33:14 2019(r348255) > @@ -91,7 +91,7 @@ struct proc *intrproc; > > static MALLOC_DEFINE(M_ITHREAD, "ithread", "Interrupt Threads"); > > -static int intr_storm_threshold = 1000; > +static int intr_storm_threshold = 0; > SYSCTL_INT(_hw, OID_AUTO, intr_storm_threshold, CTLFLAG_RWTUN, > &intr_storm_threshold, 0, > "Number of consecutive interrupts before storm protection is > enabled"); > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348257 - head/sys/amd64/include
Author: kib Date: Fri May 24 23:26:17 2019 New Revision: 348257 URL: https://svnweb.freebsd.org/changeset/base/348257 Log: Add PG_PS_PDP_FRAME symbol. Similar to PG_FRAME and PG_PS_FRAME, it denotes the mask of the physical address component of 1G superpage PDP entry. Reviewed by: alc, markj Sponsored by: The FreeBSD Foundation MFC after:1 week Differential revision:https://reviews.freebsd.org/D20386 Modified: head/sys/amd64/include/pmap.h Modified: head/sys/amd64/include/pmap.h == --- head/sys/amd64/include/pmap.h Fri May 24 23:07:32 2019 (r348256) +++ head/sys/amd64/include/pmap.h Fri May 24 23:26:17 2019 (r348257) @@ -119,6 +119,7 @@ #definePG_PROMOTED X86_PG_AVAIL(54)/* PDE only */ #definePG_FRAME(0x000ff000ul) #definePG_PS_FRAME (0x000fffe0ul) +#definePG_PS_PDP_FRAME (0x000fc000ul) /* * Promotion to a 2MB (PDE) page mapping requires that the corresponding 4KB ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348258 - head/sys/amd64/amd64
Author: kib
Date: Fri May 24 23:28:11 2019
New Revision: 348258
URL: https://svnweb.freebsd.org/changeset/base/348258
Log:
Fix too loose assert in pmap_large_unmap().
The upper bound for the valid address from the large map used
LARGEMAP_MAX_ADDRESS instead of LARGEMAP_MIN_ADDRESS. Provide a
function-like macro for proper upper value.
Noted by: markj
Reviewed by: alc, markj
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Differential revision:https://reviews.freebsd.org/D20386
Modified:
head/sys/amd64/amd64/pmap.c
Modified: head/sys/amd64/amd64/pmap.c
==
--- head/sys/amd64/amd64/pmap.c Fri May 24 23:26:17 2019(r348257)
+++ head/sys/amd64/amd64/pmap.c Fri May 24 23:28:11 2019(r348258)
@@ -421,6 +421,8 @@ static int pmap_flags = PMAP_PDE_SUPERPAGE; /* flags f
static vmem_t *large_vmem;
static u_int lm_ents;
+#definePMAP_LARGEMAP_MAX_ADDRESS() \
+(LARGEMAP_MIN_ADDRESS + NBPML4 * (u_long)lm_ents)
int pmap_pcid_enabled = 1;
SYSCTL_INT(_vm_pmap, OID_AUTO, pcid_enabled, CTLFLAG_RDTUN | CTLFLAG_NOFETCH,
@@ -1060,6 +1062,7 @@ static void pmap_invalidate_pde_page(pmap_t pmap, vm_o
pd_entry_t pde);
static void pmap_kenter_attr(vm_offset_t va, vm_paddr_t pa, int mode);
static vm_page_t pmap_large_map_getptp_unlocked(void);
+static vm_paddr_t pmap_large_map_kextract(vm_offset_t va);
static void pmap_pde_attr(pd_entry_t *pde, int cache_bits, int mask);
#if VM_NRESERVLEVEL > 0
static void pmap_promote_pde(pmap_t pmap, pd_entry_t *pde, vm_offset_t va,
@@ -2961,6 +2964,9 @@ pmap_kextract(vm_offset_t va)
if (va >= DMAP_MIN_ADDRESS && va < DMAP_MAX_ADDRESS) {
pa = DMAP_TO_PHYS(va);
+ } else if (LARGEMAP_MIN_ADDRESS <= va &&
+ va < PMAP_LARGEMAP_MAX_ADDRESS()) {
+ pa = pmap_large_map_kextract(va);
} else {
pde = *vtopde(va);
if (pde & PG_PS) {
@@ -8775,6 +8781,39 @@ retry:
return ((pt_entry_t *)PHYS_TO_DMAP(mphys) + pmap_pte_index(va));
}
+static vm_paddr_t
+pmap_large_map_kextract(vm_offset_t va)
+{
+ pdp_entry_t *pdpe, pdp;
+ pd_entry_t *pde, pd;
+ pt_entry_t *pte, pt;
+
+ KASSERT(LARGEMAP_MIN_ADDRESS <= va && va < PMAP_LARGEMAP_MAX_ADDRESS(),
+ ("not largemap range %#lx", (u_long)va));
+ pdpe = pmap_large_map_pdpe(va);
+ pdp = *pdpe;
+ KASSERT((pdp & X86_PG_V) != 0,
+ ("invalid pdp va %#lx pdpe %#lx pdp %#lx", va,
+ (u_long)pdpe, pdp));
+ if ((pdp & X86_PG_PS) != 0) {
+ KASSERT((amd_feature & AMDID_PAGE1GB) != 0,
+ ("no 1G pages, va %#lx pdpe %#lx pdp %#lx", va,
+ (u_long)pdpe, pdp));
+ return ((pdp & PG_PS_PDP_FRAME) | (va & PDPMASK));
+ }
+ pde = pmap_pdpe_to_pde(pdpe, va);
+ pd = *pde;
+ KASSERT((pd & X86_PG_V) != 0,
+ ("invalid pd va %#lx pde %#lx pd %#lx", va, (u_long)pde, pd));
+ if ((pd & X86_PG_PS) != 0)
+ return ((pd & PG_PS_FRAME) | (va & PDRMASK));
+ pte = pmap_pde_to_pte(pde, va);
+ pt = *pte;
+ KASSERT((pt & X86_PG_V) != 0,
+ ("invalid pte va %#lx pte %#lx pt %#lx", va, (u_long)pte, pt));
+ return ((pt & PG_FRAME) | (va & PAGE_MASK));
+}
+
static int
pmap_large_map_getva(vm_size_t len, vm_offset_t align, vm_offset_t phase,
vmem_addr_t *vmem_res)
@@ -8891,8 +8930,8 @@ pmap_large_unmap(void *svaa, vm_size_t len)
return;
SLIST_INIT(&spgf);
- KASSERT(LARGEMAP_MIN_ADDRESS <= sva && sva + len <=
- LARGEMAP_MAX_ADDRESS + NBPML4 * (u_long)lm_ents,
+ KASSERT(LARGEMAP_MIN_ADDRESS <= sva &&
+ sva + len <= PMAP_LARGEMAP_MAX_ADDRESS(),
("not largemap range %#lx %#lx", (u_long)svaa, (u_long)svaa + len));
PMAP_LOCK(kernel_pmap);
for (va = sva; va < sva + len; va += inc) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348258 - head/sys/amd64/amd64
On Fri, May 24, 2019 at 11:28:11PM +, Konstantin Belousov wrote:
> Author: kib
> Date: Fri May 24 23:28:11 2019
> New Revision: 348258
> URL: https://svnweb.freebsd.org/changeset/base/348258
>
> Log:
> Fix too loose assert in pmap_large_unmap().
>
> The upper bound for the valid address from the large map used
> LARGEMAP_MAX_ADDRESS instead of LARGEMAP_MIN_ADDRESS. Provide a
> function-like macro for proper upper value.
This commit was inadvertently merged with the next one, where the commit
message was supposed to be
'Make pmap_kextract() operational over the large map.'
Other metadata in the log is correct.
I do not want to revert it for re-commit.
>
> Noted by: markj
> Reviewed by:alc, markj
> Sponsored by: The FreeBSD Foundation
> MFC after: 1 week
> Differential revision: https://reviews.freebsd.org/D20386
>
> Modified:
> head/sys/amd64/amd64/pmap.c
>
> Modified: head/sys/amd64/amd64/pmap.c
> ==
> --- head/sys/amd64/amd64/pmap.c Fri May 24 23:26:17 2019
> (r348257)
> +++ head/sys/amd64/amd64/pmap.c Fri May 24 23:28:11 2019
> (r348258)
> @@ -421,6 +421,8 @@ static int pmap_flags = PMAP_PDE_SUPERPAGE; /*
> flags f
>
> static vmem_t *large_vmem;
> static u_int lm_ents;
> +#define PMAP_LARGEMAP_MAX_ADDRESS() \
> +(LARGEMAP_MIN_ADDRESS + NBPML4 * (u_long)lm_ents)
>
> int pmap_pcid_enabled = 1;
> SYSCTL_INT(_vm_pmap, OID_AUTO, pcid_enabled, CTLFLAG_RDTUN | CTLFLAG_NOFETCH,
> @@ -1060,6 +1062,7 @@ static void pmap_invalidate_pde_page(pmap_t pmap, vm_o
> pd_entry_t pde);
> static void pmap_kenter_attr(vm_offset_t va, vm_paddr_t pa, int mode);
> static vm_page_t pmap_large_map_getptp_unlocked(void);
> +static vm_paddr_t pmap_large_map_kextract(vm_offset_t va);
> static void pmap_pde_attr(pd_entry_t *pde, int cache_bits, int mask);
> #if VM_NRESERVLEVEL > 0
> static void pmap_promote_pde(pmap_t pmap, pd_entry_t *pde, vm_offset_t va,
> @@ -2961,6 +2964,9 @@ pmap_kextract(vm_offset_t va)
>
> if (va >= DMAP_MIN_ADDRESS && va < DMAP_MAX_ADDRESS) {
> pa = DMAP_TO_PHYS(va);
> + } else if (LARGEMAP_MIN_ADDRESS <= va &&
> + va < PMAP_LARGEMAP_MAX_ADDRESS()) {
> + pa = pmap_large_map_kextract(va);
> } else {
> pde = *vtopde(va);
> if (pde & PG_PS) {
> @@ -8775,6 +8781,39 @@ retry:
> return ((pt_entry_t *)PHYS_TO_DMAP(mphys) + pmap_pte_index(va));
> }
>
> +static vm_paddr_t
> +pmap_large_map_kextract(vm_offset_t va)
> +{
> + pdp_entry_t *pdpe, pdp;
> + pd_entry_t *pde, pd;
> + pt_entry_t *pte, pt;
> +
> + KASSERT(LARGEMAP_MIN_ADDRESS <= va && va < PMAP_LARGEMAP_MAX_ADDRESS(),
> + ("not largemap range %#lx", (u_long)va));
> + pdpe = pmap_large_map_pdpe(va);
> + pdp = *pdpe;
> + KASSERT((pdp & X86_PG_V) != 0,
> + ("invalid pdp va %#lx pdpe %#lx pdp %#lx", va,
> + (u_long)pdpe, pdp));
> + if ((pdp & X86_PG_PS) != 0) {
> + KASSERT((amd_feature & AMDID_PAGE1GB) != 0,
> + ("no 1G pages, va %#lx pdpe %#lx pdp %#lx", va,
> + (u_long)pdpe, pdp));
> + return ((pdp & PG_PS_PDP_FRAME) | (va & PDPMASK));
> + }
> + pde = pmap_pdpe_to_pde(pdpe, va);
> + pd = *pde;
> + KASSERT((pd & X86_PG_V) != 0,
> + ("invalid pd va %#lx pde %#lx pd %#lx", va, (u_long)pde, pd));
> + if ((pd & X86_PG_PS) != 0)
> + return ((pd & PG_PS_FRAME) | (va & PDRMASK));
> + pte = pmap_pde_to_pte(pde, va);
> + pt = *pte;
> + KASSERT((pt & X86_PG_V) != 0,
> + ("invalid pte va %#lx pte %#lx pt %#lx", va, (u_long)pte, pt));
> + return ((pt & PG_FRAME) | (va & PAGE_MASK));
> +}
> +
> static int
> pmap_large_map_getva(vm_size_t len, vm_offset_t align, vm_offset_t phase,
> vmem_addr_t *vmem_res)
> @@ -8891,8 +8930,8 @@ pmap_large_unmap(void *svaa, vm_size_t len)
> return;
>
> SLIST_INIT(&spgf);
> - KASSERT(LARGEMAP_MIN_ADDRESS <= sva && sva + len <=
> - LARGEMAP_MAX_ADDRESS + NBPML4 * (u_long)lm_ents,
> + KASSERT(LARGEMAP_MIN_ADDRESS <= sva &&
> + sva + len <= PMAP_LARGEMAP_MAX_ADDRESS(),
> ("not largemap range %#lx %#lx", (u_long)svaa, (u_long)svaa + len));
> PMAP_LOCK(kernel_pmap);
> for (va = sva; va < sva + len; va += inc) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348259 - head/sys/geom/nop
Author: mckusick
Date: Sat May 25 00:07:49 2019
New Revision: 348259
URL: https://svnweb.freebsd.org/changeset/base/348259
Log:
When using the destroy option to shut down a nop GEOM module, I/O
operations already in its queue were not being properly drained.
The GEOM framework does the queue draining, but the module needs
to wait for the draining to happen. The waiting is done by adding
a g_nop_providergone() function to wait for the I/O operations to
finish up. This change is similar to change -r345758 made to the
memory-disk driver.
Submitted by: Chuck Silvers
Tested by:Chuck Silvers
MFC after:1 week
Sponsored by: Netflix
Modified:
head/sys/geom/nop/g_nop.c
Modified: head/sys/geom/nop/g_nop.c
==
--- head/sys/geom/nop/g_nop.c Fri May 24 23:28:11 2019(r348258)
+++ head/sys/geom/nop/g_nop.c Sat May 25 00:07:49 2019(r348259)
@@ -54,17 +54,26 @@ static int g_nop_destroy_geom(struct gctl_req *req, st
struct g_geom *gp);
static void g_nop_config(struct gctl_req *req, struct g_class *mp,
const char *verb);
-static void g_nop_dumpconf(struct sbuf *sb, const char *indent,
-struct g_geom *gp, struct g_consumer *cp, struct g_provider *pp);
+static g_access_t g_nop_access;
+static g_dumpconf_t g_nop_dumpconf;
+static g_orphan_t g_nop_orphan;
+static g_provgone_t g_nop_providergone;
+static g_resize_t g_nop_resize;
+static g_start_t g_nop_start;
struct g_class g_nop_class = {
.name = G_NOP_CLASS_NAME,
.version = G_VERSION,
.ctlreq = g_nop_config,
- .destroy_geom = g_nop_destroy_geom
+ .destroy_geom = g_nop_destroy_geom,
+ .access = g_nop_access,
+ .dumpconf = g_nop_dumpconf,
+ .orphan = g_nop_orphan,
+ .providergone = g_nop_providergone,
+ .resize = g_nop_resize,
+ .start = g_nop_start,
};
-
static void
g_nop_orphan(struct g_consumer *cp)
{
@@ -320,11 +329,6 @@ g_nop_create(struct gctl_req *req, struct g_class *mp,
sc->sc_wrotebytes = 0;
mtx_init(&sc->sc_lock, "gnop lock", NULL, MTX_DEF);
gp->softc = sc;
- gp->start = g_nop_start;
- gp->orphan = g_nop_orphan;
- gp->resize = g_nop_resize;
- gp->access = g_nop_access;
- gp->dumpconf = g_nop_dumpconf;
newpp = g_new_providerf(gp, "%s", gp->name);
newpp->flags |= G_PF_DIRECT_SEND | G_PF_DIRECT_RECEIVE;
@@ -357,6 +361,18 @@ fail:
return (error);
}
+static void
+g_nop_providergone(struct g_provider *pp)
+{
+ struct g_geom *gp = pp->geom;
+ struct g_nop_softc *sc = gp->softc;
+
+ gp->softc = NULL;
+ free(sc->sc_physpath, M_GEOM);
+ mtx_destroy(&sc->sc_lock);
+ g_free(sc);
+}
+
static int
g_nop_destroy(struct g_geom *gp, boolean_t force)
{
@@ -367,7 +383,6 @@ g_nop_destroy(struct g_geom *gp, boolean_t force)
sc = gp->softc;
if (sc == NULL)
return (ENXIO);
- free(sc->sc_physpath, M_GEOM);
pp = LIST_FIRST(&gp->provider);
if (pp != NULL && (pp->acr != 0 || pp->acw != 0 || pp->ace != 0)) {
if (force) {
@@ -381,9 +396,6 @@ g_nop_destroy(struct g_geom *gp, boolean_t force)
} else {
G_NOP_DEBUG(0, "Device %s removed.", gp->name);
}
- gp->softc = NULL;
- mtx_destroy(&sc->sc_lock);
- g_free(sc);
g_wither_geom(gp, ENXIO);
return (0);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348255 - head/sys/kern
+1 Original Message From: Steven Hartland Sent: May 24, 2019 4:21:39 PM PDT To: Conrad Meyer Cc: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r348255 - head/sys/kern Just wanted to say I really appreciate the details in this commit message. Its often the case the message get overlooked when it comes to the time needed to write a truly useful message to others and this a great example of the quality we should all try to follow. Regards Steve On Fri, 24 May 2019 at 23:33, Conrad Meyer wrote: > Author: cem > Date: Fri May 24 22:33:14 2019 > New Revision: 348255 > URL: https://svnweb.freebsd.org/changeset/base/348255 > > Log: > Disable intr_storm_threshold mechanism by default > > The ixl.4 manual page has documented that the threshold falsely detects > interrupt storms on 40Gbit NICs as long ago as 2015, and we have seen > similar false positives with the ioat(4) DMA device (which can push > GB/s). > > For example, synthetic load can be generated with tools/tools/ioat > 'ioatcontrol 0 200 8192 1 1000' (allocate 200x8kB buffers, generate an > interrupt for each one, and do this for 1000 milliseconds). With > storm-detection disabled, the Broadwell-EP version of this device is > capable > of generating ~350k real interrupts per second. > > The following historical context comes from jhb@: Originally, the > threshold > worked around incorrect routing of PCI INTx interrupts on single-CPU > systems > which would end up in a hard hang during boot. Since the threshold was > added, our PCI interrupt routing was improved, most PCI interrupts use > edge-triggered MSI instead of level-triggered INTx, and typical systems > have > multiple CPUs available to service interrupts. > > On the off chance that the threshold is useful in the future, it remains > available as a tunable and sysctl. > > Reviewed by: jhb > Sponsored by: Dell EMC Isilon > Differential Revision:https://reviews.freebsd.org/D20401 > > Modified: > head/sys/kern/kern_intr.c > > Modified: head/sys/kern/kern_intr.c > > == > --- head/sys/kern/kern_intr.c Fri May 24 22:30:40 2019(r348254) > +++ head/sys/kern/kern_intr.c Fri May 24 22:33:14 2019(r348255) > @@ -91,7 +91,7 @@ struct proc *intrproc; > > static MALLOC_DEFINE(M_ITHREAD, "ithread", "Interrupt Threads"); > > -static int intr_storm_threshold = 1000; > +static int intr_storm_threshold = 0; > SYSCTL_INT(_hw, OID_AUTO, intr_storm_threshold, CTLFLAG_RWTUN, > &intr_storm_threshold, 0, > "Number of consecutive interrupts before storm protection is > enabled"); > > -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348262 - head/sys/dev/virtio/pci
Author: cem
Date: Sat May 25 01:59:24 2019
New Revision: 348262
URL: https://svnweb.freebsd.org/changeset/base/348262
Log:
virtio_pci(4): Fix typo in read_ivar method
Prior to this revision, vtpci's BUS_READ_IVAR method on VIRTIO_IVAR_SUBVENDOR
accidentally returned the PCI subdevice.
The typo seems to have been introduced with the original commit adding
VIRTIO_IVAR_{{SUB,}DEVICE,{SUB,}VENDOR} to virtio_pci. The commit log and
code
strongly suggest that the ivar was intended to return the subvendor rather
than
the subdevice; it was likely just a copy/paste mistake.
Go ahead and rectify that.
Modified:
head/sys/dev/virtio/pci/virtio_pci.c
Modified: head/sys/dev/virtio/pci/virtio_pci.c
==
--- head/sys/dev/virtio/pci/virtio_pci.cSat May 25 01:58:00 2019
(r348261)
+++ head/sys/dev/virtio/pci/virtio_pci.cSat May 25 01:59:24 2019
(r348262)
@@ -408,7 +408,7 @@ vtpci_read_ivar(device_t dev, device_t child, int inde
*result = pci_get_device(dev);
break;
case VIRTIO_IVAR_SUBVENDOR:
- *result = pci_get_subdevice(dev);
+ *result = pci_get_subvendor(dev);
break;
default:
return (ENOENT);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348250 - head/sys/powerpc/conf
On Fri, May 24, 2019 at 6:01 PM Rodney W. Grimes wrote: > > > On Fri, 24 May 2019 20:22:52 + > > Alexey Dokuchaev wrote: > > > > > On Fri, May 24, 2019 at 03:16:51PM -0500, Justin Hibbits wrote: > > > > On Fri, 24 May 2019 20:01:59 + (UTC) Piotr Kubaj wrote: > > > > > New Revision: 348250 > > > > > URL: https://svnweb.freebsd.org/changeset/base/348250 > > > > > > > > > > Log: > > > > > Add snd_hda(4) to GENERIC64 used by powerpc64. > > > > > > > > > > amd64 also has snd_hda(4) in GENERIC. > > > > > > > > > > Modified: > > > > > head/sys/powerpc/conf/GENERIC64 > > > > > ... > > > > > > > > To note: This was done because there's a strange bug in the snd_hda > > > > module, with the hdaa component. For some reason it either doesn't > > > > find all the internal components it needs, or something, because > > > > there's a NULL dereference when trying to call a kobj method in > > > > hdaa_attach(). > > > > > > So this commit essentially masks the real bug somewhere rather than > > > fixing it, is this what you're saying? > > > > > > ./danfe > > > > It's a viable workaround to a problem that reaches a wide audience. > > Since it works built-in, I found it acceptable. I probably should have > > filed a bug for it a year ago when I hit it and worked around it, but it > > could also very well be a compiler issue. > > > > By the way, it works fine on powerpc (32-bit) loaded as a module. > > Please do file a bug report now, please do mark the line in GENERIC64 with > a comment XXX This is needed to work around foo so that it is documented > why it is there and someone removing it does not go down a rabit > hole others have already been down, and so that some day someone > may go down that rabbit hole of there own free will and fix this > for us. > > Paving over the top of obscure bugs with a hackish fix is ok, > not documenting this state of affairs is not, IMHO. > > > - Justin > -- > Rod Grimes rgri...@freebsd.org Bug filed as kern/238113. I don't think a XXX is necessarily needed in GENERIC64, since it's also parity with GENERIC on amd64. - Justin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348250 - head/sys/powerpc/conf
> On Fri, May 24, 2019 at 6:01 PM Rodney W. Grimes > wrote: > > > > > On Fri, 24 May 2019 20:22:52 + > > > Alexey Dokuchaev wrote: > > > > > > > On Fri, May 24, 2019 at 03:16:51PM -0500, Justin Hibbits wrote: > > > > > On Fri, 24 May 2019 20:01:59 + (UTC) Piotr Kubaj wrote: > > > > > > New Revision: 348250 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/348250 > > > > > > > > > > > > Log: > > > > > > Add snd_hda(4) to GENERIC64 used by powerpc64. > > > > > > > > > > > > amd64 also has snd_hda(4) in GENERIC. > > > > > > > > > > > > Modified: > > > > > > head/sys/powerpc/conf/GENERIC64 > > > > > > ... > > > > > > > > > > To note: This was done because there's a strange bug in the snd_hda > > > > > module, with the hdaa component. For some reason it either doesn't > > > > > find all the internal components it needs, or something, because > > > > > there's a NULL dereference when trying to call a kobj method in > > > > > hdaa_attach(). > > > > > > > > So this commit essentially masks the real bug somewhere rather than > > > > fixing it, is this what you're saying? > > > > > > > > ./danfe > > > > > > It's a viable workaround to a problem that reaches a wide audience. > > > Since it works built-in, I found it acceptable. I probably should have > > > filed a bug for it a year ago when I hit it and worked around it, but it > > > could also very well be a compiler issue. > > > > > > By the way, it works fine on powerpc (32-bit) loaded as a module. > > > > Please do file a bug report now, please do mark the line in GENERIC64 with > > a comment XXX This is needed to work around foo so that it is documented > > why it is there and someone removing it does not go down a rabit > > hole others have already been down, and so that some day someone > > may go down that rabbit hole of there own free will and fix this > > for us. > > > > Paving over the top of obscure bugs with a hackish fix is ok, > > not documenting this state of affairs is not, IMHO. > > > > > - Justin > > -- > > Rod Grimes > > rgri...@freebsd.org > > Bug filed as kern/238113. I don't think a XXX is necessarily needed > in GENERIC64, since it's also parity with GENERIC on amd64. Does the bug also exist on amd64? > - Justin -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r348250 - head/sys/powerpc/conf
On Fri, May 24, 2019 at 10:02 PM Rodney W. Grimes wrote: > > > On Fri, May 24, 2019 at 6:01 PM Rodney W. Grimes > > wrote: > > > > > > > On Fri, 24 May 2019 20:22:52 + > > > > Alexey Dokuchaev wrote: > > > > > > > > > On Fri, May 24, 2019 at 03:16:51PM -0500, Justin Hibbits wrote: > > > > > > On Fri, 24 May 2019 20:01:59 + (UTC) Piotr Kubaj wrote: > > > > > > > New Revision: 348250 > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/348250 > > > > > > > > > > > > > > Log: > > > > > > > Add snd_hda(4) to GENERIC64 used by powerpc64. > > > > > > > > > > > > > > amd64 also has snd_hda(4) in GENERIC. > > > > > > > > > > > > > > Modified: > > > > > > > head/sys/powerpc/conf/GENERIC64 > > > > > > > ... > > > > > > > > > > > > To note: This was done because there's a strange bug in the snd_hda > > > > > > module, with the hdaa component. For some reason it either doesn't > > > > > > find all the internal components it needs, or something, because > > > > > > there's a NULL dereference when trying to call a kobj method in > > > > > > hdaa_attach(). > > > > > > > > > > So this commit essentially masks the real bug somewhere rather than > > > > > fixing it, is this what you're saying? > > > > > > > > > > ./danfe > > > > > > > > It's a viable workaround to a problem that reaches a wide audience. > > > > Since it works built-in, I found it acceptable. I probably should have > > > > filed a bug for it a year ago when I hit it and worked around it, but it > > > > could also very well be a compiler issue. > > > > > > > > By the way, it works fine on powerpc (32-bit) loaded as a module. > > > > > > Please do file a bug report now, please do mark the line in GENERIC64 with > > > a comment XXX This is needed to work around foo so that it is documented > > > why it is there and someone removing it does not go down a rabit > > > hole others have already been down, and so that some day someone > > > may go down that rabbit hole of there own free will and fix this > > > for us. > > > > > > Paving over the top of obscure bugs with a hackish fix is ok, > > > not documenting this state of affairs is not, IMHO. > > > > > > > - Justin > > > -- > > > Rod Grimes > > > rgri...@freebsd.org > > > > Bug filed as kern/238113. I don't think a XXX is necessarily needed > > in GENERIC64, since it's also parity with GENERIC on amd64. > > Does the bug also exist on amd64? No idea. I don't have any amd64 hardware, and it's been in GENERIC for as long as I know. My unfounded guess is that it doesn't exist on amd64, but someone else would have to confirm that. - Justin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r348267 - head/sys/powerpc/aim
Author: jhibbits
Date: Sat May 25 04:56:06 2019
New Revision: 348267
URL: https://svnweb.freebsd.org/changeset/base/348267
Log:
powerpc64/pmap: Reapply r334235 to OEA64 pmap, clearing HID0_RADIX
This was lost in the re-merger of ISA3 MMU into moea64_native.
Modified:
head/sys/powerpc/aim/moea64_native.c
Modified: head/sys/powerpc/aim/moea64_native.c
==
--- head/sys/powerpc/aim/moea64_native.cSat May 25 04:31:04 2019
(r348266)
+++ head/sys/powerpc/aim/moea64_native.cSat May 25 04:56:06 2019
(r348267)
@@ -401,6 +401,12 @@ moea64_cpu_bootstrap_native(mmu_t mmup, int ap)
mtmsr(mfmsr() & ~PSL_DR & ~PSL_IR);
+ switch(mfpvr() >> 16) {
+ case IBMPOWER9:
+ mtspr(SPR_HID0, mfspr(SPR_HID0) & ~HID0_RADIX);
+ break;
+ }
+
/*
* Install kernel SLB entries
*/
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
