CVS commit: src/sys/dev/onewire
Module Name:src Committed By: kardel Date: Tue Oct 10 19:21:39 UTC 2023 Modified Files: src/sys/dev/onewire: owtemp.c Log Message: PR kern/57088: add missing "onewire" link dependency Thanks Lloyd for pointing me to this PR as I independently fixed the missing module functionality (and also missing the link dependency). To generate a diff of this commit: cvs rdiff -u -r1.20 -r1.21 src/sys/dev/onewire/owtemp.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/sys/dev/onewire
Module Name:src Committed By: kardel Date: Tue Oct 10 19:21:39 UTC 2023 Modified Files: src/sys/dev/onewire: owtemp.c Log Message: PR kern/57088: add missing "onewire" link dependency Thanks Lloyd for pointing me to this PR as I independently fixed the missing module functionality (and also missing the link dependency). To generate a diff of this commit: cvs rdiff -u -r1.20 -r1.21 src/sys/dev/onewire/owtemp.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/sys/dev/onewire/owtemp.c diff -u src/sys/dev/onewire/owtemp.c:1.20 src/sys/dev/onewire/owtemp.c:1.21 --- src/sys/dev/onewire/owtemp.c:1.20 Sun Aug 27 13:20:09 2023 +++ src/sys/dev/onewire/owtemp.c Tue Oct 10 19:21:38 2023 @@ -1,4 +1,4 @@ -/* $NetBSD: owtemp.c,v 1.20 2023/08/27 13:20:09 kardel Exp $ */ +/* $NetBSD: owtemp.c,v 1.21 2023/10/10 19:21:38 kardel Exp $ */ /* $OpenBSD: owtemp.c,v 1.1 2006/03/04 16:27:03 grange Exp $ */ /*- @@ -51,7 +51,7 @@ */ #include -__KERNEL_RCSID(0, "$NetBSD: owtemp.c,v 1.20 2023/08/27 13:20:09 kardel Exp $"); +__KERNEL_RCSID(0, "$NetBSD: owtemp.c,v 1.21 2023/10/10 19:21:38 kardel Exp $"); #include #include @@ -318,7 +318,7 @@ owtemp_decode_ds1920(const uint8_t *buf) return (temp + 27315); } -MODULE(MODULE_CLASS_DRIVER, owtemp, NULL); +MODULE(MODULE_CLASS_DRIVER, owtemp, "onewire"); #ifdef _MODULE #include "ioconf.c"
CVS commit: src
Module Name:src
Committed By: kardel
Date: Sun Aug 27 13:20:10 UTC 2023
Modified Files:
src/distrib/sets/lists/debug: module.mi
src/distrib/sets/lists/modules: mi
src/sys/dev/onewire: owtemp.c
src/sys/modules: Makefile
Added Files:
src/sys/modules/owtemp: Makefile owtemp.ioconf
Log Message:
make owtemp a module
To generate a diff of this commit:
cvs rdiff -u -r1.24 -r1.25 src/distrib/sets/lists/debug/module.mi
cvs rdiff -u -r1.158 -r1.159 src/distrib/sets/lists/modules/mi
cvs rdiff -u -r1.19 -r1.20 src/sys/dev/onewire/owtemp.c
cvs rdiff -u -r1.279 -r1.280 src/sys/modules/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/owtemp/Makefile \
src/sys/modules/owtemp/owtemp.ioconf
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/distrib/sets/lists/debug/module.mi
diff -u src/distrib/sets/lists/debug/module.mi:1.24 src/distrib/sets/lists/debug/module.mi:1.25
--- src/distrib/sets/lists/debug/module.mi:1.24 Tue Dec 20 00:31:55 2022
+++ src/distrib/sets/lists/debug/module.mi Sun Aug 27 13:20:09 2023
@@ -1,4 +1,4 @@
-# $NetBSD: module.mi,v 1.24 2022/12/20 00:31:55 jakllsch Exp $
+# $NetBSD: module.mi,v 1.25 2023/08/27 13:20:09 kardel Exp $
./usr/libdata/debug/@MODULEDIR@ modules-base-kernel kmod,debug
./usr/libdata/debug/@MODULEDIR@/accf_dataready modules-base-kernel kmod,debug
./usr/libdata/debug/@MODULEDIR@/accf_dataready/accf_dataready.kmod.debug modules-base-kernel kmod,debug
@@ -308,6 +308,8 @@
./usr/libdata/debug/@MODULEDIR@/opencrypto/opencrypto.kmod.debug modules-base-kernel kmod,debug
./usr/libdata/debug/@MODULEDIR@/overlaymodules-base-kernel kmod,debug
./usr/libdata/debug/@MODULEDIR@/overlay/overlay.kmod.debug modules-base-kernel kmod,debug
+./usr/libdata/debug/@MODULEDIR@/owtempmodules-base-kernel kmod,debug
+./usr/libdata/debug/@MODULEDIR@/owtemp/owtemp.kmod.debug modules-base-kernel kmod,debug
./usr/libdata/debug/@MODULEDIR@/padmodules-base-kernel kmod,debug
./usr/libdata/debug/@MODULEDIR@/pad/pad.kmod.debug modules-base-kernel kmod,debug
./usr/libdata/debug/@MODULEDIR@/pciverbose modules-base-kernel kmod,debug
Index: src/distrib/sets/lists/modules/mi
diff -u src/distrib/sets/lists/modules/mi:1.158 src/distrib/sets/lists/modules/mi:1.159
--- src/distrib/sets/lists/modules/mi:1.158 Tue Dec 20 00:31:56 2022
+++ src/distrib/sets/lists/modules/mi Sun Aug 27 13:20:09 2023
@@ -1,4 +1,4 @@
-# $NetBSD: mi,v 1.158 2022/12/20 00:31:56 jakllsch Exp $
+# $NetBSD: mi,v 1.159 2023/08/27 13:20:09 kardel Exp $
#
# Note: don't delete entries from here - mark them as "obsolete" instead.
#
@@ -367,6 +367,8 @@
./@MODULEDIR@/opencrypto/opencrypto.kmod modules-base-kernel kmod
./@MODULEDIR@/overlaymodules-base-kernel kmod
./@MODULEDIR@/overlay/overlay.kmod modules-base-kernel kmod
+./@MODULEDIR@/owtempmodules-base-kernel kmod
+./@MODULEDIR@/owtemp/owtemp.kmod modules-base-kernel kmod
./@MODULEDIR@/padmodules-base-kernel kmod
./@MODULEDIR@/pad/pad.kmod modules-base-kernel kmod
./@MODULEDIR@/pciverbose modules-base-kernel kmod
Index: src/sys/dev/onewire/owtemp.c
diff -u src/sys/dev/onewire/owtemp.c:1.19 src/sys/dev/onewire/owtemp.c:1.20
--- src/sys/dev/onewire/owtemp.c:1.19 Sat Nov 30 23:06:52 2019
+++ src/sys/dev/onewire/owtemp.c Sun Aug 27 13:20:09 2023
@@ -1,4 +1,4 @@
-/* $NetBSD: owtemp.c,v 1.19 2019/11/30 23:06:52 ad Exp $ */
+/* $NetBSD: owtemp.c,v 1.20 2023/08/27 13:20:09 kardel Exp $ */
/* $OpenBSD: owtemp.c,v 1.1 2006/03/04 16:27:03 grange Exp $ */
/*-
@@ -51,13 +51,14 @@
*/
#include
-__KERNEL_RCSID(0, "$NetBSD: owtemp.c,v 1.19 2019/11/30 23:06:52 ad Exp $");
+__KERNEL_RCSID(0, "$NetBSD: owtemp.c,v 1.20 2023/08/27 13:20:09 kardel Exp $");
#include
#include
#include
#include
#include
+#include
#include
@@ -316,3 +317,37 @@ owtemp_decode_ds1920(const uint8_t *buf)
/* convert to uK */
return (temp + 27315);
}
+
+MODULE(MODULE_CLASS_DRIVER, owtemp, NULL);
+
+#ifdef _MODULE
+#include "ioconf.c"
+#endif
+
+static int
+owtemp_modcmd(modcmd_t cmd, void *opaque)
+{
+ int error;
+
+ error = 0;
+ switch (cmd) {
+ case MODULE_CMD_INIT:
+#ifdef _MODULE
+ error = config_init_component(cfdriver_ioconf_owtemp,
+ cfattach_ioconf_owtemp, cfdata_ioconf_owtemp);
+ if (error)
+ aprint_error("%s: unable to init component\n",
+ owtemp_cd.cd_name);
+#endif
+ break;
+ case MODULE_CMD_FINI:
+#ifdef _MODULE
+ config_fini_component(cfdriver_ioconf_owtemp,
+ cfattach_ioconf_owtemp, cfdata_ioconf_owtemp);
+#endif
+ break;
+ default:
+ error = ENOTTY;
+ }
+ return error;
+}
Index: src/sys/modules/Makefile
diff -u src/sys/modules/Makefile:1.279 src/sys/modules/Makefile:1.280
--- src/sys/modules/Makefile:1.279 Wed Aug 9 09:36:26 2023
+++ src/sys/modules/Makefile Sun Aug 27 13:20:09 2023
@@ -1,4 +1,4 @@
-# $NetBSD: Makefile,v 1.279 2023/08/09 09:36:26 andvar Exp $
+# $NetBSD:
CVS commit: src
Module Name:src Committed By: kardel Date: Sun Aug 27 13:20:10 UTC 2023 Modified Files: src/distrib/sets/lists/debug: module.mi src/distrib/sets/lists/modules: mi src/sys/dev/onewire: owtemp.c src/sys/modules: Makefile Added Files: src/sys/modules/owtemp: Makefile owtemp.ioconf Log Message: make owtemp a module To generate a diff of this commit: cvs rdiff -u -r1.24 -r1.25 src/distrib/sets/lists/debug/module.mi cvs rdiff -u -r1.158 -r1.159 src/distrib/sets/lists/modules/mi cvs rdiff -u -r1.19 -r1.20 src/sys/dev/onewire/owtemp.c cvs rdiff -u -r1.279 -r1.280 src/sys/modules/Makefile cvs rdiff -u -r0 -r1.1 src/sys/modules/owtemp/Makefile \ src/sys/modules/owtemp/owtemp.ioconf Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/sys/net/npf
Module Name:src
Committed By: kardel
Date: Tue Aug 8 16:10:42 UTC 2023
Modified Files:
src/sys/net/npf: npf_ruleset.c
Log Message:
The analysis documented in PR misc/56990 is correct.
Fix by not returning when encountering a ruleset rule.
The code up to now would stop at any group rule.
ruleset rules are marked as group rule and a dynamic rule.
processing is only finished when a result is present AND
we are looking at a plain group rule.
To generate a diff of this commit:
cvs rdiff -u -r1.51 -r1.52 src/sys/net/npf/npf_ruleset.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/net/npf/npf_ruleset.c
diff -u src/sys/net/npf/npf_ruleset.c:1.51 src/sys/net/npf/npf_ruleset.c:1.52
--- src/sys/net/npf/npf_ruleset.c:1.51 Sat May 30 14:16:56 2020
+++ src/sys/net/npf/npf_ruleset.c Tue Aug 8 16:10:41 2023
@@ -34,7 +34,7 @@
#ifdef _KERNEL
#include
-__KERNEL_RCSID(0, "$NetBSD: npf_ruleset.c,v 1.51 2020/05/30 14:16:56 rmind Exp $");
+__KERNEL_RCSID(0, "$NetBSD: npf_ruleset.c,v 1.52 2023/08/08 16:10:41 kardel Exp $");
#include
#include
@@ -891,7 +891,7 @@ npf_ruleset_inspect(npf_cache_t *npc, co
KASSERT(n < skip_to);
/* Group is a barrier: return a matching if found any. */
- if ((attr & NPF_RULE_GROUP) != 0 && final_rl) {
+ if ((attr & NPF_DYNAMIC_GROUP) == NPF_RULE_GROUP && final_rl) {
break;
}
CVS commit: src/sys/net/npf
Module Name:src Committed By: kardel Date: Tue Aug 8 16:10:42 UTC 2023 Modified Files: src/sys/net/npf: npf_ruleset.c Log Message: The analysis documented in PR misc/56990 is correct. Fix by not returning when encountering a ruleset rule. The code up to now would stop at any group rule. ruleset rules are marked as group rule and a dynamic rule. processing is only finished when a result is present AND we are looking at a plain group rule. To generate a diff of this commit: cvs rdiff -u -r1.51 -r1.52 src/sys/net/npf/npf_ruleset.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/sys/netinet6
Module Name:src
Committed By: kardel
Date: Wed Mar 29 13:01:44 UTC 2023
Modified Files:
src/sys/netinet6: nd6_nbr.c
Log Message:
use carp mac address when replying to neighbor solicitations referring
to carp interface addresses.
unconfuses commercial routers
To generate a diff of this commit:
cvs rdiff -u -r1.182 -r1.183 src/sys/netinet6/nd6_nbr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/netinet6/nd6_nbr.c
diff -u src/sys/netinet6/nd6_nbr.c:1.182 src/sys/netinet6/nd6_nbr.c:1.183
--- src/sys/netinet6/nd6_nbr.c:1.182 Mon Aug 2 12:56:25 2021
+++ src/sys/netinet6/nd6_nbr.c Wed Mar 29 13:01:44 2023
@@ -1,4 +1,4 @@
-/* $NetBSD: nd6_nbr.c,v 1.182 2021/08/02 12:56:25 andvar Exp $ */
+/* $NetBSD: nd6_nbr.c,v 1.183 2023/03/29 13:01:44 kardel Exp $ */
/* $KAME: nd6_nbr.c,v 1.61 2001/02/10 16:06:14 jinmei Exp $ */
/*
@@ -31,7 +31,7 @@
*/
#include
-__KERNEL_RCSID(0, "$NetBSD: nd6_nbr.c,v 1.182 2021/08/02 12:56:25 andvar Exp $");
+__KERNEL_RCSID(0, "$NetBSD: nd6_nbr.c,v 1.183 2023/03/29 13:01:44 kardel Exp $");
#ifdef _KERNEL_OPT
#include "opt_inet.h"
@@ -100,7 +100,7 @@ static int dad_maxtry = 15; /* max # of
void
nd6_ns_input(struct mbuf *m, int off, int icmp6len)
{
- struct ifnet *ifp;
+ struct ifnet *ifp, *ifpc;
struct ip6_hdr *ip6 = mtod(m, struct ip6_hdr *);
struct nd_neighbor_solicit *nd_ns;
struct in6_addr saddr6 = ip6->ip6_src;
@@ -116,10 +116,11 @@ nd6_ns_input(struct mbuf *m, int off, in
union nd_opts ndopts;
const struct sockaddr_dl *proxydl = NULL;
struct psref psref;
+ struct psref psref_c;
struct psref psref_ia;
char ip6buf[INET6_ADDRSTRLEN], ip6buf2[INET6_ADDRSTRLEN];
- ifp = m_get_rcvif_psref(m, );
+ ifp = ifpc = m_get_rcvif_psref(m, );
if (ifp == NULL)
goto freeit;
@@ -224,8 +225,15 @@ nd6_ns_input(struct mbuf *m, int off, in
if (ifp->if_carp && ifp->if_type != IFT_CARP) {
int s = pserialize_read_enter();
ifa = carp_iamatch6(ifp->if_carp, );
- if (ifa != NULL)
+ if (ifa != NULL) {
ifa_acquire(ifa, _ia);
+ if (ifa->ifa_ifp && ifa->ifa_ifp != ifp) {
+ifpc = ifa->ifa_ifp;
+if_acquire(ifpc, _c);
+ }
+ }
+
+
pserialize_read_exit(s);
} else
ifa = NULL;
@@ -350,14 +358,14 @@ nd6_ns_input(struct mbuf *m, int off, in
in6_all = in6addr_linklocal_allnodes;
if (in6_setscope(_all, ifp, NULL) != 0)
goto bad;
- nd6_na_output(ifp, _all, ,
+ nd6_na_output(ifpc, _all, ,
((anycast || proxy || !tlladdr) ? 0 : ND_NA_FLAG_OVERRIDE) |
(ip6_forwarding ? ND_NA_FLAG_ROUTER : 0),
tlladdr, (const struct sockaddr *)proxydl);
goto freeit;
}
- nd6_cache_lladdr(ifp, , lladdr, lladdrlen, ND_NEIGHBOR_SOLICIT, 0);
+ nd6_cache_lladdr(ifpc, , lladdr, lladdrlen, ND_NEIGHBOR_SOLICIT, 0);
nd6_na_output(ifp, , ,
((anycast || proxy || !tlladdr) ? 0 : ND_NA_FLAG_OVERRIDE) |
@@ -366,6 +374,9 @@ nd6_ns_input(struct mbuf *m, int off, in
freeit:
ifa_release(ifa, _ia);
m_put_rcvif_psref(ifp, );
+ if (ifp != ifpc)
+ if_put(ifpc, _c);
+
m_freem(m);
return;
CVS commit: src/sys/netinet6
Module Name:src Committed By: kardel Date: Wed Mar 29 13:01:44 UTC 2023 Modified Files: src/sys/netinet6: nd6_nbr.c Log Message: use carp mac address when replying to neighbor solicitations referring to carp interface addresses. unconfuses commercial routers To generate a diff of this commit: cvs rdiff -u -r1.182 -r1.183 src/sys/netinet6/nd6_nbr.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/crypto/dist/ipsec-tools/src/racoon
Module Name:src
Committed By: kardel
Date: Mon Feb 27 13:39:09 UTC 2023
Modified Files:
src/crypto/dist/ipsec-tools/src/racoon: grabmyaddr.c
Log Message:
cast to the correct message structure (rt_msghdr instead of if_msghdr)
To generate a diff of this commit:
cvs rdiff -u -r1.39 -r1.40 \
src/crypto/dist/ipsec-tools/src/racoon/grabmyaddr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/crypto/dist/ipsec-tools/src/racoon/grabmyaddr.c
diff -u src/crypto/dist/ipsec-tools/src/racoon/grabmyaddr.c:1.39 src/crypto/dist/ipsec-tools/src/racoon/grabmyaddr.c:1.40
--- src/crypto/dist/ipsec-tools/src/racoon/grabmyaddr.c:1.39 Wed Nov 25 14:15:41 2020
+++ src/crypto/dist/ipsec-tools/src/racoon/grabmyaddr.c Mon Feb 27 13:39:09 2023
@@ -1,4 +1,4 @@
-/* $NetBSD: grabmyaddr.c,v 1.39 2020/11/25 14:15:41 christos Exp $ */
+/* $NetBSD: grabmyaddr.c,v 1.40 2023/02/27 13:39:09 kardel Exp $ */
/*
* Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
* Copyright (C) 2008 Timo Teras .
@@ -849,7 +849,7 @@ kernel_sync()
{
caddr_t ref, buf, end;
size_t bufsiz;
- struct if_msghdr *ifm;
+ struct rt_msghdr *rtm;
#define MIBSIZ 6
int mib[MIBSIZ] = {
@@ -871,8 +871,10 @@ kernel_sync()
if (sysctl(mib, MIBSIZ, buf, , NULL, 0) >= 0) {
/* Parse both interfaces and addresses. */
- for (end = buf + bufsiz; buf < end; buf += ifm->ifm_msglen) {
- ifm = (struct if_msghdr *) buf;
+ for (end = buf + bufsiz; buf < end; buf += rtm->rtm_msglen) {
+ rtm = (struct rt_msghdr *) buf;
+ if (rtm->rtm_version != RTM_VERSION)
+continue;
kernel_handle_message(buf);
}
} else {
CVS commit: src/crypto/dist/ipsec-tools/src/racoon
Module Name:src Committed By: kardel Date: Mon Feb 27 13:39:09 UTC 2023 Modified Files: src/crypto/dist/ipsec-tools/src/racoon: grabmyaddr.c Log Message: cast to the correct message structure (rt_msghdr instead of if_msghdr) To generate a diff of this commit: cvs rdiff -u -r1.39 -r1.40 \ src/crypto/dist/ipsec-tools/src/racoon/grabmyaddr.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Module Name:src
Committed By: kardel
Date: Fri Feb 17 21:50:14 UTC 2023
Modified Files:
src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_ctldir.c
Log Message:
provide pathconf for .zfs control directory. avoids errors on
ls -l ../.zfs.
To generate a diff of this commit:
cvs rdiff -u -r1.14 -r1.15 \
src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ctldir.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ctldir.c
diff -u src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ctldir.c:1.14 src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ctldir.c:1.15
--- src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ctldir.c:1.14 Fri Nov 4 11:20:39 2022
+++ src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ctldir.c Fri Feb 17 21:50:13 2023
@@ -1842,6 +1842,7 @@ const struct vnodeopv_entry_desc zfs_sfs
{ _putpages_desc, genfs_null_putpages },
{ _islocked_desc, genfs_islocked },
{ _print_desc, sfs_print },
+ { _pathconf_desc, genfs_pathconf },
{ NULL, NULL }
};
CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Module Name:src Committed By: kardel Date: Fri Feb 17 21:50:14 UTC 2023 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_ctldir.c Log Message: provide pathconf for .zfs control directory. avoids errors on ls -l ../.zfs. To generate a diff of this commit: cvs rdiff -u -r1.14 -r1.15 \ src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ctldir.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/sys/net/npf
Module Name:src
Committed By: kardel
Date: Sun Feb 12 13:38:37 UTC 2023
Modified Files:
src/sys/net/npf: npf.h npf_mbuf.c npf_sendpkt.c
Log Message:
PR kern/56052:
allow block-return packets passed through without rule matching.
Included up-stream as https://github.com/rmind/npf/pull/115
To generate a diff of this commit:
cvs rdiff -u -r1.63 -r1.64 src/sys/net/npf/npf.h
cvs rdiff -u -r1.24 -r1.25 src/sys/net/npf/npf_mbuf.c
cvs rdiff -u -r1.22 -r1.23 src/sys/net/npf/npf_sendpkt.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/net/npf/npf.h
diff -u src/sys/net/npf/npf.h:1.63 src/sys/net/npf/npf.h:1.64
--- src/sys/net/npf/npf.h:1.63 Sat May 30 14:16:56 2020
+++ src/sys/net/npf/npf.h Sun Feb 12 13:38:37 2023
@@ -122,6 +122,7 @@ void * nbuf_ensure_writable(nbuf_t *, s
bool nbuf_cksum_barrier(nbuf_t *, int);
int nbuf_add_tag(nbuf_t *, uint32_t);
+int npf_mbuf_add_tag(nbuf_t *, struct mbuf *, uint32_t);
int nbuf_find_tag(nbuf_t *, uint32_t *);
/*
Index: src/sys/net/npf/npf_mbuf.c
diff -u src/sys/net/npf/npf_mbuf.c:1.24 src/sys/net/npf/npf_mbuf.c:1.25
--- src/sys/net/npf/npf_mbuf.c:1.24 Sat May 30 14:16:56 2020
+++ src/sys/net/npf/npf_mbuf.c Sun Feb 12 13:38:37 2023
@@ -36,7 +36,7 @@
#ifdef _KERNEL
#include
-__KERNEL_RCSID(0, "$NetBSD: npf_mbuf.c,v 1.24 2020/05/30 14:16:56 rmind Exp $");
+__KERNEL_RCSID(0, "$NetBSD: npf_mbuf.c,v 1.25 2023/02/12 13:38:37 kardel Exp $");
#include
#include
@@ -297,14 +297,13 @@ nbuf_cksum_barrier(nbuf_t *nbuf, int di)
}
/*
- * nbuf_add_tag: associate a tag with the network buffer.
+ * npf_mbuf_add_tag: associate a tag with the network buffer.
*
* => Returns 0 on success or error number on failure.
*/
int
-nbuf_add_tag(nbuf_t *nbuf, uint32_t val)
+npf_mbuf_add_tag(nbuf_t *nbuf, struct mbuf *m, uint32_t val)
{
- struct mbuf *m = nbuf->nb_mbuf0;
#ifdef _KERNEL
struct m_tag *mt;
uint32_t *dat;
@@ -328,6 +327,18 @@ nbuf_add_tag(nbuf_t *nbuf, uint32_t val)
}
/*
+ * nbuf_add_tag: associate a tag with the network buffer.
+ *
+ * => Returns 0 on success or error number on failure.
+ */
+int
+nbuf_add_tag(nbuf_t *nbuf, uint32_t val)
+{
+ struct mbuf *m = nbuf->nb_mbuf0;
+ return npf_mbuf_add_tag(nbuf, m, val);
+}
+
+/*
* nbuf_find_tag: find a tag associated with a network buffer.
*
* => Returns 0 on success or error number on failure.
Index: src/sys/net/npf/npf_sendpkt.c
diff -u src/sys/net/npf/npf_sendpkt.c:1.22 src/sys/net/npf/npf_sendpkt.c:1.23
--- src/sys/net/npf/npf_sendpkt.c:1.22 Sat May 30 14:16:56 2020
+++ src/sys/net/npf/npf_sendpkt.c Sun Feb 12 13:38:37 2023
@@ -33,7 +33,7 @@
#ifdef _KERNEL
#include
-__KERNEL_RCSID(0, "$NetBSD: npf_sendpkt.c,v 1.22 2020/05/30 14:16:56 rmind Exp $");
+__KERNEL_RCSID(0, "$NetBSD: npf_sendpkt.c,v 1.23 2023/02/12 13:38:37 kardel Exp $");
#include
#include
@@ -197,6 +197,9 @@ npf_return_tcp(npf_cache_t *npc)
}
}
+ /* don't look at our generated reject packets going out */
+ (void)npf_mbuf_add_tag(npc->npc_nbuf, m, NPF_NTAG_PASS);
+
/* Pass to IP layer. */
if (npf_iscached(npc, NPC_IP4)) {
return ip_output(m, NULL, NULL, IP_FORWARDING, NULL, NULL);
@@ -215,6 +218,9 @@ npf_return_icmp(const npf_cache_t *npc)
{
struct mbuf *m = nbuf_head_mbuf(npc->npc_nbuf);
+ /* don't look at our generated reject packets going out */
+ (void)nbuf_add_tag(npc->npc_nbuf, NPF_NTAG_PASS);
+
if (npf_iscached(npc, NPC_IP4)) {
icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_ADMIN_PROHIBIT, 0, 0);
return 0;
CVS commit: src/sys/net/npf
Module Name:src Committed By: kardel Date: Sun Feb 12 13:38:37 UTC 2023 Modified Files: src/sys/net/npf: npf.h npf_mbuf.c npf_sendpkt.c Log Message: PR kern/56052: allow block-return packets passed through without rule matching. Included up-stream as https://github.com/rmind/npf/pull/115 To generate a diff of this commit: cvs rdiff -u -r1.63 -r1.64 src/sys/net/npf/npf.h cvs rdiff -u -r1.24 -r1.25 src/sys/net/npf/npf_mbuf.c cvs rdiff -u -r1.22 -r1.23 src/sys/net/npf/npf_sendpkt.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src
Module Name:src
Committed By: kardel
Date: Sun Feb 12 13:21:28 UTC 2023
Modified Files:
src/sys/net/npf: npf_params.c
src/usr.sbin/npf: npf-params.7
Log Message:
PR kern/55654:
Switch default for parameter npf ip4.reassembly to 1.
This makes the NPF default configuration comply with host
requirements for IPv4.
To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/sys/net/npf/npf_params.c
cvs rdiff -u -r1.8 -r1.9 src/usr.sbin/npf/npf-params.7
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/net/npf/npf_params.c
diff -u src/sys/net/npf/npf_params.c:1.5 src/sys/net/npf/npf_params.c:1.6
--- src/sys/net/npf/npf_params.c:1.5 Thu Apr 28 17:28:15 2022
+++ src/sys/net/npf/npf_params.c Sun Feb 12 13:21:28 2023
@@ -26,7 +26,7 @@
#ifdef _KERNEL
#include
-__KERNEL_RCSID(0, "$NetBSD: npf_params.c,v 1.5 2022/04/28 17:28:15 martin Exp $");
+__KERNEL_RCSID(0, "$NetBSD: npf_params.c,v 1.6 2023/02/12 13:21:28 kardel Exp $");
#include
#include
@@ -56,7 +56,7 @@ npf_param_general_register(npf_t *npf)
{
"ip4.reassembly",
>ip4_reassembly,
- .default_val = 0, // false
+ .default_val = 1, // true - host requirements
.min = 0, .max = 1
},
{
Index: src/usr.sbin/npf/npf-params.7
diff -u src/usr.sbin/npf/npf-params.7:1.8 src/usr.sbin/npf/npf-params.7:1.9
--- src/usr.sbin/npf/npf-params.7:1.8 Thu Dec 17 05:33:06 2020
+++ src/usr.sbin/npf/npf-params.7 Sun Feb 12 13:21:28 2023
@@ -1,4 +1,4 @@
-.\" $NetBSD: npf-params.7,v 1.8 2020/12/17 05:33:06 taca Exp $
+.\" $NetBSD: npf-params.7,v 1.9 2023/02/12 13:21:28 kardel Exp $
.\"
.\" Copyright (c) 2019 Mindaugas Rasiukevicius
.\" All rights reserved.
@@ -60,11 +60,11 @@ Default: 1.
.It Li ip4.reassembly
Perform IPv4 reassembly before inspecting the packet.
Fragmentation is considered very harmful, so most networks are expected
-to prevent it; therefore, reassembly is disabled by default.
+to prevent it; reassembly is enabled by default.
However, while the packet should generally be reassembled at the receiver,
-reassembly by the packet filter might be necessary in order to perform state
+reassembly by the packet filter may be necessary in order to perform state
tracking.
-Default: 0.
+Default: 1.
.It Li ip6.reassembly
Perform IPv6 reassembly before inspecting the packet.
Discouraged in general but not prohibited by RFC 8200.
CVS commit: src
Module Name:src Committed By: kardel Date: Sun Feb 12 13:21:28 UTC 2023 Modified Files: src/sys/net/npf: npf_params.c src/usr.sbin/npf: npf-params.7 Log Message: PR kern/55654: Switch default for parameter npf ip4.reassembly to 1. This makes the NPF default configuration comply with host requirements for IPv4. To generate a diff of this commit: cvs rdiff -u -r1.5 -r1.6 src/sys/net/npf/npf_params.c cvs rdiff -u -r1.8 -r1.9 src/usr.sbin/npf/npf-params.7 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/sys/dev/hdaudio
Module Name:src
Committed By: kardel
Date: Thu Jan 5 09:57:39 UTC 2023
Modified Files:
src/sys/dev/hdaudio: hdafg.c
Log Message:
ignore NULL for hdaudio_audiodev in hdafg_freem
also guard against NULL in ad_{capture,playback}
observed during shutdown on Lenovo W510
To generate a diff of this commit:
cvs rdiff -u -r1.28 -r1.29 src/sys/dev/hdaudio/hdafg.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/dev/hdaudio/hdafg.c
diff -u src/sys/dev/hdaudio/hdafg.c:1.28 src/sys/dev/hdaudio/hdafg.c:1.29
--- src/sys/dev/hdaudio/hdafg.c:1.28 Tue May 24 06:28:00 2022
+++ src/sys/dev/hdaudio/hdafg.c Thu Jan 5 09:57:39 2023
@@ -1,4 +1,4 @@
-/* $NetBSD: hdafg.c,v 1.28 2022/05/24 06:28:00 andvar Exp $ */
+/* $NetBSD: hdafg.c,v 1.29 2023/01/05 09:57:39 kardel Exp $ */
/*
* Copyright (c) 2009 Precedence Technologies Ltd
@@ -60,7 +60,7 @@
*/
#include
-__KERNEL_RCSID(0, "$NetBSD: hdafg.c,v 1.28 2022/05/24 06:28:00 andvar Exp $");
+__KERNEL_RCSID(0, "$NetBSD: hdafg.c,v 1.29 2023/01/05 09:57:39 kardel Exp $");
#include
#include
@@ -4226,9 +4226,12 @@ hdafg_freem(void *opaque, void *addr, si
struct hdaudio_audiodev *ad = opaque;
struct hdaudio_stream *st;
- if (addr == DMA_KERNADDR(>ad_playback->st_data))
+ if (ad == NULL)
+ return;
+
+ if (ad->ad_playback != NULL && addr == DMA_KERNADDR(>ad_playback->st_data))
st = ad->ad_playback;
- else if (addr == DMA_KERNADDR(>ad_capture->st_data))
+ else if (ad->ad_capture != NULL && addr == DMA_KERNADDR(>ad_capture->st_data))
st = ad->ad_capture;
else
return;
CVS commit: src/sys/dev/hdaudio
Module Name:src
Committed By: kardel
Date: Thu Jan 5 09:57:39 UTC 2023
Modified Files:
src/sys/dev/hdaudio: hdafg.c
Log Message:
ignore NULL for hdaudio_audiodev in hdafg_freem
also guard against NULL in ad_{capture,playback}
observed during shutdown on Lenovo W510
To generate a diff of this commit:
cvs rdiff -u -r1.28 -r1.29 src/sys/dev/hdaudio/hdafg.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Module Name:src Committed By: kardel Date: Mon Oct 3 16:04:19 UTC 2022 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c Log Message: Revert. Spotted by hannken@ - fix needs to be in zfs_ctldir.c it is missing VOP_PATHCONF. To generate a diff of this commit: cvs rdiff -u -r1.79 -r1.80 \ src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c diff -u src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c:1.79 src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c:1.80 --- src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c:1.79 Tue Sep 27 10:33:21 2022 +++ src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c Mon Oct 3 16:04:19 2022 @@ -5027,7 +5027,7 @@ zfs_pathconf(vnode_t *vp, int cmd, ulong #endif default: - return (EINVAL); + return (EOPNOTSUPP); } }
CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Module Name:src Committed By: kardel Date: Mon Oct 3 16:04:19 UTC 2022 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c Log Message: Revert. Spotted by hannken@ - fix needs to be in zfs_ctldir.c it is missing VOP_PATHCONF. To generate a diff of this commit: cvs rdiff -u -r1.79 -r1.80 \ src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Good to know. So do we need to add path conf there? Frank 3 Oct 2022 11:34:09 J. Hannken-Illjes : > Frank, > > the vnode operations for ".zfs" are in zfs_ctldir.c and there > is no pathconf operation here ... > > -- > J. Hannken-Illjes - hann...@mailbox.org > >> On 3. Oct 2022, at 11:26, Frank Kardel wrote: >> >> Well, I am am happy to do that. But ls got eopnotsupp for fpathconf of ACL >> names and barked at them when listing the .zfs snapshot directory. Ls is >> only ignoring einval at that place. So something must be wrong there wrt tog. >> Frank >> >> 3 Oct 2022 10:53:10 J. Hannken-Illjes : >> >>>> On 27. Sep 2022, at 12:33, Frank Kardel wrote: >>>> >>>> Module Name: src >>>> Committed By: kardel >>>> Date: Tue Sep 27 10:33:21 UTC 2022 >>>> >>>> Modified Files: >>>> src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c >>>> >>>> Log Message: >>>> for unsupported names return EINVAL as per TOG >>>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html >>>> discussed with christos@ >>>> >>>> >>>> To generate a diff of this commit: >>>> cvs rdiff -u -r1.78 -r1.79 \ >>>> src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c >>> >>> This is completely wrong! >>> >>> The call sequence is "VOP_PATHCONF -> zfs_netbsd_pathconf -> zfs_pathconf" >>> where zfs_netbsd_pathconf() handles the NetBSD specific names if >>> zfs_pathconf() returns EOPNOTSUPP and also returns EINVAL for >>> unsupported names in this case. >>> >>> Please revert. >>> >>> -- >>> J. Hannken-Illjes - hann...@mailbox.org
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Well, I am am happy to do that. But ls got eopnotsupp for fpathconf of ACL names and barked at them when listing the .zfs snapshot directory. Ls is only ignoring einval at that place. So something must be wrong there wrt tog. Frank 3 Oct 2022 10:53:10 J. Hannken-Illjes : >> On 27. Sep 2022, at 12:33, Frank Kardel wrote: >> >> Module Name: src >> Committed By: kardel >> Date: Tue Sep 27 10:33:21 UTC 2022 >> >> Modified Files: >> src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c >> >> Log Message: >> for unsupported names return EINVAL as per TOG >> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html >> discussed with christos@ >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.78 -r1.79 \ >> src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c > > This is completely wrong! > > The call sequence is "VOP_PATHCONF -> zfs_netbsd_pathconf -> zfs_pathconf" > where zfs_netbsd_pathconf() handles the NetBSD specific names if > zfs_pathconf() returns EOPNOTSUPP and also returns EINVAL for > unsupported names in this case. > > Please revert. > > -- > J. Hannken-Illjes - hann...@mailbox.org
CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Module Name:src Committed By: kardel Date: Tue Sep 27 10:33:21 UTC 2022 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c Log Message: for unsupported names return EINVAL as per TOG https://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html discussed with christos@ To generate a diff of this commit: cvs rdiff -u -r1.78 -r1.79 \ src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c diff -u src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c:1.78 src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c:1.79 --- src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c:1.78 Sun Mar 27 16:26:26 2022 +++ src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c Tue Sep 27 10:33:21 2022 @@ -5027,7 +5027,7 @@ zfs_pathconf(vnode_t *vp, int cmd, ulong #endif default: - return (EOPNOTSUPP); + return (EINVAL); } }
CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Module Name:src Committed By: kardel Date: Tue Sep 27 10:33:21 UTC 2022 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c Log Message: for unsupported names return EINVAL as per TOG https://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html discussed with christos@ To generate a diff of this commit: cvs rdiff -u -r1.78 -r1.79 \ src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src
Thanks for that explanation. I was wondering if the same goal could be achieved with sypkgs as they seem to have about the same granularity as the MKxxx options. You would still build all component but could populate the images from the set of syspkgs. So you would be able to generate tailored images using appropriate sets of syspkgs. I don't know how well tested syspkgs currently are, but maybe that is already closer what you would need for you goal. syspkgs are already very granular per component. running "build.sh syspkgs" will create all system packages. Excerpt from my current syspkgs run: ... Registered base-rcs-bin-9.99.97.0.20210420 Packaged base-rcs-bin-9.99.97.0.20210420.tgz Registered base-psd-share-9.99.97.0.20220524 Packaged base-psd-share-9.99.97.0.20220524.tgz Registered base-ppp-bin-9.99.97.0.20220412 Packaged base-ppp-bin-9.99.97.0.20220412.tgz Registered base-postfix-examples-9.99.97.0.20220524 Packaged base-postfix-examples-9.99.97.0.20220524.tgz Registered base-postfix-usr-9.99.97.0.20220524 Packaged base-postfix-usr-9.99.97.0.20220524.tgz Registered base-pkgutil-bin-9.99.97.0.20210420 Packaged base-pkgutil-bin-9.99.97.0.20210420.tgz Registered base-ntp-bin-9.99.97.0.20210420 Packaged base-ntp-bin-9.99.97.0.20210420.tgz Registered base-nis-bin-9.99.97.0.20220411 Packaged base-nis-bin-9.99.97.0.20220411.tgz Registered base-nfsserver-bin-9.99.97.0.20211127 Packaged base-nfsserver-bin-9.99.97.0.20211127.tgz Registered base-nfsclient-bin-9.99.97.0.20210420 Packaged base-nfsclient-bin-9.99.97.0.20210420.tgz ... here you already get the ntp binaries. There are other syskpgs for ntp etc files. NTP syspkgs are: -rw-r--r-- 1 root wheel 1106566 May 29 19:10 /src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/base-ntp-bin-9.99.97.0.20210420.tgz -rw-r--r-- 1 root wheel 700 May 29 19:06 /src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/base-ntp-root-9.99.97.0.20220524.tgz -rw-r--r-- 1 root wheel 2869 May 29 19:06 /src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/etc-ntp-etc-9.99.97.0.20211028.tgz -rw-r--r-- 1 root wheel 1730 May 29 19:06 /src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/etc-ntp-rc-9.99.97.0.20201225.tgz -rw-r--r-- 1 root wheel78090 May 29 19:12 /src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/man-ntp-man-9.99.97.0.20100828.tgz -rw-r--r-- 1 root wheel 225558 May 29 19:11 /src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/misc-ntp-htmldoc-9.99.97.0.20220524.tgz base-ntp-bin-9.99.97.0.20210420.tgz looks like: Information for /src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/base-ntp-bin-9.99.97.0.20210420.tgz: Comment: utilities for network time protocol support Requires: base-sys-usr>=9.99.97 Description: utilities for network time protocol support Homepage: http://www.NetBSD.org/ and contains: Information for /src/NetBSD/cur/RELEASE/amd64/binary/syspkgs/base-ntp-bin-9.99.97.0.20210420.tgz: Files: /usr/sbin/ntp-keygen /usr/sbin/ntpd /usr/sbin/ntpdate /usr/sbin/ntpdc /usr/sbin/ntpq /usr/sbin/ntptime /usr/sbin/ntptrace /usr/sbin/sntp Currently 1383 syspkgs are built. There may be some work to clean up syspkgs but the structural packaging work is already done. Example for a current issue: /src/NetBSD/cur/src/distrib/sets/regpkg: ls: argument list too long ls: No such file or directory Registered comp-c-man-9.99.97.0.0 also some descriptions seem to be missing and other issues like missing (or mis-configured) packages. Frank On 05/29/22 18:39, nia wrote: On Sun, May 29, 2022 at 09:34:16AM +0200, Frank Kardel wrote: Hi *! I see we are building knobs to not build and install parts of the system. Somehow I missed the discussion on this. Could someone point me to that thread, so that I can understand the overall rationale? As for NTP: sysinst is configuring for ntp and ntpdate. How is sysinst supposed to handle a potentially missing NTP installation? Frank Hi, sorry I missed this email, please CC me next time. I talked about this a bit on ICB, but not on the lists yet. My end-game is to make it easier to make minimal embedded images of NetBSD. At work we are shipping an embedded OS derived from FreeBSD, with some patches and custom tools, and also "incredibly stripped down" with many knobs similar to this. It's extremely useful to exclude some non-essential components from the build without modifying the build system. As for why I want to do this to NetBSD, I had the idea of making a small-as-possible live image with GUI similar to Damn Small Linux. This is obviously focused on live and embedded images, so nothing using sysinst. It might be not too intrusive to conditionally enable some options in sysinst, though. There is a secondary goal, to identify groups of commands that are related. When all you have is a big unstructured list of commands, it's difficult to tell that everything configured with MKMROUTING is enabled, or that it's related to the the kernel option MKR
Re: CVS commit: src
Hi *! I see we are building knobs to not build and install parts of the system. Somehow I missed the discussion on this. Could someone point me to that thread, so that I can understand the overall rationale? As for NTP: sysinst is configuring for ntp and ntpdate. How is sysinst supposed to handle a potentially missing NTP installation? Frank On 05/28/22 13:17, Nia Alarie wrote: Module Name:src Committed By: nia Date: Sat May 28 11:17:36 UTC 2022 Modified Files: src/distrib/sets/lists/base: mi src/distrib/sets/lists/debug: mi src/distrib/sets/lists/etc: mi src/distrib/sets/lists/man: mi src/distrib/sets/lists/misc: mi src/etc: Makefile src/etc/rc.d: Makefile src/external/bsd: Makefile src/share/man/man5: mk.conf.5 src/share/mk: bsd.README bsd.own.mk Log Message: mk: Add MKNTP, MKTCPDUMP knobs. To generate a diff of this commit: cvs rdiff -u -r1.1302 -r1.1303 src/distrib/sets/lists/base/mi cvs rdiff -u -r1.381 -r1.382 src/distrib/sets/lists/debug/mi cvs rdiff -u -r1.267 -r1.268 src/distrib/sets/lists/etc/mi cvs rdiff -u -r1.1743 -r1.1744 src/distrib/sets/lists/man/mi cvs rdiff -u -r1.220 -r1.221 src/distrib/sets/lists/misc/mi cvs rdiff -u -r1.460 -r1.461 src/etc/Makefile cvs rdiff -u -r1.113 -r1.114 src/etc/rc.d/Makefile cvs rdiff -u -r1.72 -r1.73 src/external/bsd/Makefile cvs rdiff -u -r1.91 -r1.92 src/share/man/man5/mk.conf.5 cvs rdiff -u -r1.434 -r1.435 src/share/mk/bsd.README cvs rdiff -u -r1.1280 -r1.1281 src/share/mk/bsd.own.mk Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src
Hi ! This triggered an unexpected side effect. I have my ZFS vdev on gpt partitions as wedges. I configured the vdevs via the /dev/wedges/* symlinks via the wedge names. data 1.28T 424G 888G - 4% 32% 1.31x ONLINE - raidz2 1.28T 424G 888G - 4%32% wedges/zfs440g00 - - - - - - wedges/zfs440g10 - - - - - - wedges/zfs440g20 - - - - - - wedges/zfs440g30 - - - - - - wedges/zfs440g40 - - - - - - wedges/zfs440g50 - - - - - - cache - - - - - - wedges/zfsnv1c01 128G 4.64M 128G - 0% 0% This used to work in 9.99.85 (devpubd needs to run before zfs though). In 9.99.86 the NO_FOLLOW is now being honored the above strategy fails and leads to UNAVAIL pools. Importing the pools via /dev/dk* works but is not useful as the numbering of the dk slices can easily change. Uncommenting "filemode |= O_NOFOLLOW;" makes things work again. I am not sure why NO_FOLLOW was there and if we want to keep it how we would handle named wedges. We could create a /dev/wedgedev from devpubd with hard links to the devices - that would work with ZFS but is really ugly. Comments? Frank On 06/30/21 00:40, David A. Holland wrote: Module Name:src Committed By: dholland Date: Tue Jun 29 22:40:54 UTC 2021 Modified Files: src/external/cddl/osnet/sys/sys: vnode.h src/share/man/man9: errno.9 vnsubr.9 src/sys/dev: firmload.c fss.c kloader.c vnd.c src/sys/kern: kern_acct.c kern_core.c kern_descrip.c kern_ktrace_vfs.c kern_module_vfs.c subr_exec_fd.c subr_kobj_vfs.c tty_ptm.c vfs_syscalls.c vfs_vnops.c src/sys/miscfs/fdesc: fdesc_vnops.c src/sys/modules/lua: lua.c src/sys/sys: filedesc.h vnode.h src/sys/ufs/lfs: ulfs_extattr.c ulfs_quota1.c src/sys/ufs/ufs: ufs_extattr.c ufs_quota1.c Log Message: Add containment for the cloning devices hack in vn_open. Cloning devices (and also things like /dev/stderr) work by allocating a struct file, stuffing it in the file table (which is a layer violation), stuffing the file descriptor number for it in a magic field of struct lwp (which is gross), and then "failing" with one of two magic errnos, EDUPFD or EMOVEFD. Before this commit, all callers of vn_open in the kernel (there are quite a few) were expected to check for these errors and handle the situation. Needless to say, none of them except for open() itself did, resulting in internal negative errnos being returned to userspace. This hack is fairly deeply rooted and cannot be eliminated all at once. This commit adds logic to handle the magic errnos inside vn_open; now on success vn_open returns either a vnode or an integer file descriptor, along with a flag that says whether the underlying code requested EDUPFD or EMOVEFD. Callers not prepared to cope with file descriptors can pass NULL for the extra return values, in which case if a file descriptor would be produced vn_open fails with EOPNOTSUPP. Since I'm rearranging vn_open's signature anyway, stop exposing struct nameidata. Instead, take three arguments: an optional vnode to use as the starting point (like openat()), the path, and additional namei flags to use, restricted to NOCHROOT and TRYEMULROOT. (Other namei behavior, e.g. NOFOLLOW, can be requested via the open flags.) This change requires a kernel bump. Ride the one an hour ago. (That was supposed to be coordinated; did not intend to let an hour slip by. My fault.) To generate a diff of this commit: cvs rdiff -u -r1.18 -r1.19 src/external/cddl/osnet/sys/sys/vnode.h cvs rdiff -u -r1.5 -r1.6 src/share/man/man9/errno.9 cvs rdiff -u -r1.47 -r1.48 src/share/man/man9/vnsubr.9 cvs rdiff -u -r1.22 -r1.23 src/sys/dev/firmload.c cvs rdiff -u -r1.110 -r1.111 src/sys/dev/fss.c cvs rdiff -u -r1.28 -r1.29 src/sys/dev/kloader.c cvs rdiff -u -r1.281 -r1.282 src/sys/dev/vnd.c cvs rdiff -u -r1.97 -r1.98 src/sys/kern/kern_acct.c cvs rdiff -u -r1.34 -r1.35 src/sys/kern/kern_core.c cvs rdiff -u -r1.250 -r1.251 src/sys/kern/kern_descrip.c cvs rdiff -u -r1.2 -r1.3 src/sys/kern/kern_ktrace_vfs.c cvs rdiff -u -r1.17 -r1.18 src/sys/kern/kern_module_vfs.c cvs rdiff -u -r1.11 -r1.12 src/sys/kern/subr_exec_fd.c \ src/sys/kern/subr_kobj_vfs.c cvs rdiff -u -r1.42 -r1.43 src/sys/kern/tty_ptm.c cvs rdiff -u -r1.549 -r1.550 src/sys/kern/vfs_syscalls.c cvs rdiff -u -r1.215 -r1.216 src/sys/kern/vfs_vnops.c cvs rdiff -u -r1.137 -r1.138 src/sys/miscfs/fdesc/fdesc_vnops.c cvs rdiff -u -r1.24 -r1.25 src/sys/modules/lua/lua.c cvs rdiff -u -r1.68 -r1.69 src/sys/sys/filedesc.h cvs rdiff -u -r1.296 -r1.297 src/sys/sys/vnode.h cvs rdiff -u -r1.16 -r1.17 src/sys/ufs/lfs/ulfs_extattr.c cvs rdiff -u
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
Hi Roy !
That looks more semantics (the ones I know of - dynamic interface
scanning is one of my NTPd parts)
preserving now.
So far I see no other issues from the pitfalls I know of.
Lets hope our kernel and other SO_RERRORS systems miss any
interface scan worthy events.
Frank
On 01/03/21 12:03, Roy Marples wrote:
On 02/01/2021 23:33, Frank Kardel wrote:
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
...
This patch seems (by visual inspection) to break that logic.
Also the behavior now fully relies in the routing message
functionality which can be disabled
on serious procession errors - at that point the code robustness
relies on the periodic
re-scanning - so I am not sure whether the periodic re-scanning
should be completely
Valid points.
New patch sets disable_dynamic_updates if the -U 0 is given.
The only other code to touch disable_dynamic_updates is this
disable_dynamic_updates |= (sw_uid != 0); /* also notifies routing
message listener *
So this should be good now.
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/cmd_args.c
--- a/external/bsd/ntp/dist/ntpd/cmd_args.c Sat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/cmd_args.c Sun Jan 03 10:56:58
2021 +
@@ -181,9 +181,11 @@
if (HAVE_OPT( UPDATEINTERVAL )) {
long val = OPT_VALUE_UPDATEINTERVAL;
- if (val >= 0)
+ if (val >= 0) {
interface_interval = val;
- else {
+ if (interface_interval == 0)
+ disable_dynamic_updates = 1;
+ } else {
fprintf(stderr,
"command line interface update
interval %ld must not be negative\n",
val);
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sun Jan 03 10:56:58
2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSun Jan 03 10:56:58
2021 +
@@ -423,9 +423,11 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (!disable_dynamic_updates &&
+ interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
See man ntpd:
...
−U number, −−updateinterval=number
interval in seconds between scans for new or dropped
inter‐
faces. This option takes an integer number as its
argument.
Give the time in seconds between two scans for new or
dropped
interfaces. For systems with routing socket support the
scans will be performed shortly after the interface change
has been detected by the system. Use 0 to disable
scanning.
60 seconds is the minimum time between scans.
...
This patch seems (by visual inspection) to break that logic.
Also the behavior now fully relies in the routing message functionality
which can be disabled
on serious procession errors - at that point the code robustness relies
on the periodic
re-scanning - so I am not sure whether the periodic re-scanning should
be completely
disabled.
Best regards,
Frank
On 01/02/21 19:41, Roy Marples wrote:
On 02/01/2021 17:23, Roy Marples wrote:
That's a good point, with this we can now remove that forced sync on
a timer approach.
Does this look ok?
Better patch:
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 18:39:34
2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 18:39:34
2021 +
@@ -423,9 +423,10 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
Hi Roy ! I doubt that the explicit draining is helpful here as it already happens in the outer loop processing any routing socket input. All that is happening in the routing messages processing path is to call timer_interfacetimeout(current_time + UPDATE_GRACE) and this is robust for multiple calls. Ignoring ENOBUFS was ok here due to the automatic periodic interface updates. calling timer_interfacetimeout(current_time + UPDATE_GRACE) is also possible if you expect a single ENOBUFS within UPDATE_GRACE seconds. But there is no need o special case flushing the routing socket here. There is no functional improvement except for save a few cycles in the overflow case. Also the ntp_io system will periodically refresh it interface lists in time as it was explicitly designed to be robust against lost messages from the routing socket. We should try to keep the differences to the up-stream code as little as possible. Especially when the upstream code already handles the situation reasonably the is no need for additional code. Happy new year! Frank On 01/01/21 18:21, Roy Marples wrote: cvs rdiff -u -r1.27 -r1.28 src/external/bsd/ntp/dist/ntpd/ntp_io.c
Re: CVS commit: src/sys/dev/mii (PR/kern 55538)
Hi Martin ! That is strange - I didn't expect that, especially as the previous code was wrong with respect to state tracking. Can you check whether the addresses do not have the DEtACHED flag? You could try the dtrace script from the PR - it shows a little bit what is going on. There was also some mii fixing just before my patch, but I assume you testes with reverting just this commit. Sorry for the issue - I have yet to find an explaination for that behavior. Maybe comparing the dtrace outputs for both varainst can shed a light on what happens. Frank On 08/27/20 10:20, Martin Husemann wrote: On Mon, Aug 24, 2020 at 12:46:04PM +, Frank Kardel wrote: Module Name:src Committed By: kardel Date: Mon Aug 24 12:46:04 UTC 2020 Modified Files: src/sys/dev/mii: mii_physubr.c Log Message: Keep the change check invariant intact. The previous code could miss status updates by picking up a new status different from the tested status. This left addresses in the DETACHED state although the link status is already UP again. addresses PR/kern 55538 To generate a diff of this commit: cvs rdiff -u -r1.92 -r1.93 src/sys/dev/mii/mii_physubr.c Hi Frank, this change breaks the network on my macppc, with r1.93 it only seems to be able to send packets, but never receives answers (ARP does not complete, but other hosts see the ARP requests). gem0 at pci2 dev 15 function 0: Apple Computer GMAC Ethernet (rev. 0x01) gem0: interrupting at irq 41 brgphy0 at gem0 phy 0: BCM5411 1000BASE-T media interface, rev. 1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto gem0: Ethernet address 00:03:93:71:ff:cc, 10KB RX fifo, 4KB TX fifo It is connected to a gige switch: media: Ethernet autoselect (1000baseT full-duplex,master) status: active (which looks the same in the non-working kernel). Any ideas how to debug? Martin
Re: CVS commit: src/usr.bin/make
nbmake currently fails to build the tree. config.status: creating buildmake.sh compile arch.c compile buf.c compile compat.c compile cond.c compile dir.c compile for.c compile hash.c compile job.c compile main.c compile make.c compile make_malloc.c compile meta.c compile metachar.c compile parse.c compile str.c compile strlist.c compile suff.c compile targ.c compile trace.c compile util.c compile var.c compile lstAppend.c compile lstAtEnd.c compile lstAtFront.c compile lstClose.c compile lstConcat.c compile lstDatum.c compile lstDeQueue.c compile lstDestroy.c compile lstDupl.c compile lstEnQueue.c compile lstFind.c compile lstFindFrom.c compile lstFirst.c compile lstForEach.c compile lstForEachFrom.c compile lstInit.c compile lstInsert.c compile lstIsAtEnd.c compile lstIsEmpty.c compile lstLast.c compile lstMember.c compile lstNext.c compile lstOpen.c compile lstPrev.c compile lstRemove.c compile lstReplace.c compile lstSucc.c link nbmake ===> MAKECONF file: /etc/mk.conf objdir /src/NetBSD/native/src/obj.evbarm/tools nbmake: "/src/NetBSD/native/src/share/mk/bsd.nls.mk" line 18: Unknown directive nbmake: "/src/NetBSD/native/src/share/mk/bsd.nls.mk" line 19: Unknown directive nbmake: Fatal errors encountered -- cannot continue ERROR: bomb_getmakevar TOOLDIR: /tmp/nbbuild851/nbmake failed Frank On 07/19/20 14:26, Roland Illig wrote: Module Name:src Committed By: rillig Date: Sun Jul 19 12:26:17 UTC 2020 Modified Files: src/usr.bin/make: arch.c compat.c cond.c for.c job.c main.c make.c meta.c nonints.h parse.c suff.c var.c Log Message: make(1): rename Varf_Flags to VarEvalFlags In var.c there are lots of different flag types. To make any accidental mixture obvious, each flag group gets its own prefix. The only flag group that is visible outside of var.c is concerned with evaluating variables, therefore the "e", which replaces the former "f" that probably just meant "flag". To generate a diff of this commit: cvs rdiff -u -r1.73 -r1.74 src/usr.bin/make/arch.c cvs rdiff -u -r1.113 -r1.114 src/usr.bin/make/compat.c cvs rdiff -u -r1.79 -r1.80 src/usr.bin/make/cond.c src/usr.bin/make/nonints.h cvs rdiff -u -r1.54 -r1.55 src/usr.bin/make/for.c cvs rdiff -u -r1.201 -r1.202 src/usr.bin/make/job.c cvs rdiff -u -r1.280 -r1.281 src/usr.bin/make/main.c cvs rdiff -u -r1.99 -r1.100 src/usr.bin/make/make.c cvs rdiff -u -r1.86 -r1.87 src/usr.bin/make/meta.c cvs rdiff -u -r1.236 -r1.237 src/usr.bin/make/parse.c cvs rdiff -u -r1.88 -r1.89 src/usr.bin/make/suff.c cvs rdiff -u -r1.258 -r1.259 src/usr.bin/make/var.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch/xen/xen
HI, I am not sur whether it is the commit below, but 2 out 4 times my xen-DOMU from today (20200409/9.99.55) panics with following locking botch: [ 29.9301379] panic: kernel diagnostic assertion "IFNET_LOCKED(ifp)" failed: file "/usr/src/sys/arch/xen/xen/if_xennet_xenbus.c", line 1120 [ 29.9301379] cpu2: Begin traceback... [ 29.9301379] vpanic() at netbsd:vpanic+0x146 [ 29.9301379] kern_assert() at netbsd:kern_assert+0x48 [ 29.9301379] xennet_ioctl() at netbsd:xennet_ioctl+0x6d [ 29.9301379] if_mcast_op() at netbsd:if_mcast_op+0x6a [ 29.9301379] in6_addmulti() at netbsd:in6_addmulti+0x153 [ 29.9301379] in6_joingroup() at netbsd:in6_joingroup+0x45 [ 29.9301379] ip6_ctloutput() at netbsd:ip6_ctloutput+0x141c [ 29.9301379] udp6_ctloutput() at netbsd:udp6_ctloutput+0xa2 [ 29.9301379] udp6_ctloutput_wrapper() at netbsd:udp6_ctloutput_wrapper+0x2c [ 29.9301379] sosetopt() at netbsd:sosetopt+0x5c [ 29.9301379] sys_setsockopt() at netbsd:sys_setsockopt+0x8e [ 29.9301379] syscall() at netbsd:syscall+0x9c [ 29.9301379] --- syscall (number 105) --- [ 29.9301379] 75d934d3469a: [ 29.9301379] cpu2: End traceback... [ 29.9301379] rebooting... Best regards, Frank On 04/06/20 20:23, Jaromir Dolecek wrote: Module Name:src Committed By: jdolecek Date: Mon Apr 6 18:23:21 UTC 2020 Modified Files: src/sys/arch/xen/xen: if_xennet_xenbus.c Log Message: convert to IFEF_MPSAFE, also enable interrupt handler without biglock no performance difference observed compared to version before change, for neither UP nor MP DomU To generate a diff of this commit: cvs rdiff -u -r1.105 -r1.106 src/sys/arch/xen/xen/if_xennet_xenbus.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/uvm
Hi ! With this state of January 2nd we ran some tests for robustness and timing with our database setup: Machine: Mainboard: S2600WFT CPU: 2 x Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz machdep.spectre_v1.mitigated = 0 machdep.spectre_v2.hwmitigated = 1 machdep.spectre_v2.swmitigated = 1 machdep.spectre_v2.method = [GCC retpoline] + [Intel IBRS] machdep.spectre_v4.mitigated = 0 machdep.spectre_v4.method = (none) machdep.mds.mitigated = 0 machdep.mds.method = (none) machdep.taa.mitigated = 0 machdep.taa.method = [MDS] Memory: hw.physmem64 = 549446447104 hw.usermem64 = 549438365696 This machine is/has been a challenge to NetBSD as it has 0.5Tb Memory and 32 cores. Testcase is restoring a 1Tb Postgresql-11 database with varying degres of Postresql pg_restore parallelism. Why did we do the tests? The machine was installed with 8.99.24 as that supported the memory setup. The machine was not able to reliably copy with many db/restore processes and large memory - see PR kern/54209: NetBSD 8 large memory performance extremely low PR kern/54210: NetBSD-8 processes presumably not exiting for details. With Andrew Doran's work on the vm system we restarted the tests. The baseline is 8.99.24 from around Sep 3 04:10:20 UTC 2018: TEST 1 FRESH BOOT time pg_restore -Upgsql -p5433 -Fd -d db -j5 20200103-db.dmpdir 1826.599u 1752.878s 10:36:03.83 9.3%0+0k 397+0io 1789pf+0w Higher levels of parallelism lead to a higher probability for catatonic systems with increasing restore parallelism. Trouble starts around -j8 and gets worse at higher levels. TEST 2 9.99.33 from around Fri Jan 3 16:14:02 CET 2020 FRESH BOOT time pg_restore -Upgsql -p5433 -Fd -d db -j28 20200103-db.dmpdir 2047.925u 1191.878s 14:24:15.23 6.2%0+0k 0+0io 5784pf+0w This survived a -j28 run that was not possible with 8.99.24 - this a a big step forward, but ~4h slower real time. TEST 3 FRESH BOOT 9.99.34 from around Mon Jan 6 14:43:01 time pg_restore -Upgsql -p5433 -Fd -d db -j28 20200103-db.dmpdir 1816.348u 1792.530s 10:56:02.56 9.1%0+0k 395+0io 5620pf+0w -j5 run to compare to 9.99.33 - big improvement in real run time though system time went up. TEST 4 State after TEST 3 run to compare to 8.99.24 time pg_restore -Upgsql -p5433 -Fd -d db -j5 20200103-db.dmpdir 1706.548u 1748.623s 11:26:38.87 8.3%0+0k 0+0io 1420pf+0w This ran faster that -j28 - probably due to less contention, but 50 min slower that 8.99.24 after fresh boot. TEST 5: re-run TEST 4 with fresh boot for 8.99.24 comparison time pg_restore -Upgsql -p5433 -Fd -d db -j5 20200103-db.dmpdir 1710.665u 1611.083s 9:14:56.86 9.9% 0+0k 398+0io 1504pf+0w better the 8.99.24 for real time. There seems no big difference in system time between 8.99.24 and 9.99.34, but a big improvement in robustness. The lockups don't seem to happen any more and there are a fewer short term system freezes and the systems remains responsive with 9.99.34. The big differences in real time are interesting but the cause for that may not be easy to pinpoint. The database runs on an nvme: nvme0 at pci10 dev 0 function 0: Intel SSD DC P4500 (rev. 0x00) nvme0: NVMe 1.2 nvme0: for admin queue interrupting at msix4 vec 0 nvme0: INTEL SSDPE2KX040T8, firmware VDV10131, serial ... nvme0: for io queue 1 interrupting at msix4 vec 1 affinity to cpu0 [...] nvme0: for io queue 32 interrupting at msix4 vec 32 affinity to cpu31 ld0 at nvme0 nsid 1 ld0: 3726 GB, 486401 cyl, 255 head, 63 sec, 512 bytes/sect x 7814037168 sectors And we are seeing transfer rates up to 300Mb/s and up 80% busy on the complex I/O (load) and CPU (build index) workload. So in summary we a a big step forward in robustness. Thanks to Andrew for the big improvements here. Frank On 01/02/20 03:00, Andrew Doran wrote: > Module Name:src > Committed By:ad > Date:Thu Jan 2 02:00:35 UTC 2020 > > Modified Files: > src/sys/uvm: uvm_amap.c uvm_amap.h > > Log Message: > Back out the amap allocation changes from earlier today - have seen a panic > with them. Retain the lock changes. > > > To generate a diff of this commit: > cvs rdiff -u -r1.113 -r1.114 src/sys/uvm/uvm_amap.c > cvs rdiff -u -r1.38 -r1.39 src/sys/uvm/uvm_amap.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/sys
Great. works again. Frank On 01/03/20 20:14, Jason Thorpe wrote: On Jan 3, 2020, at 10:11 AM, Frank Kardel wrote: Hi Jason ! Could you please check that kmem using tools can cope with the missing _boottime symbol. Hey Frank... this should fix it: $NetBSD: vmstat.c,v 1.231 2020/01/03 19:13:54 thorpej Exp $ -- thorpej
Re: CVS commit: src/sys
Hi Jason ! Could you please check that kmem using tools can cope with the missing _boottime symbol. E.g.: # vmstat -s vmstat: undefined symbols: _boottime # This renders vmstat currently broken. Best regards Frank On 01/02/20 16:42, Jason R Thorpe wrote: Module Name:src Committed By: thorpej Date: Thu Jan 2 15:42:27 UTC 2020 Modified Files: src/sys/compat/common: kern_info_43.c kern_time_50.c src/sys/compat/netbsd32: netbsd32_sysctl.c src/sys/external/bsd/drm2/include/linux: ktime.h src/sys/fs/nfs/common: nfs_lock.c src/sys/kern: init_main.c init_sysctl.c kern_rndq.c kern_tc.c kern_time.c src/sys/miscfs/fdesc: fdesc_vnops.c src/sys/miscfs/kernfs: kernfs.h kernfs_vnops.c src/sys/miscfs/procfs: procfs_linux.c src/sys/nfs: nfs_serv.c src/sys/rump/librump/rumpkern: cons.c emul.c rump.c src/sys/sys: kernel.h timevar.h Log Message: - Eliminate the global "boottime" variable, which was being accessed without any synchronization against changes by e.g. clock_settime(). - Replace with new getbinboottime() / getnanoboottime() / getmicroboottime() functions (naming mirrors that of other time access functions in kern_tc.c). It returns the (maybe-converted) value of timebasebin, which also tracks our estimate of when the system was booted (i.e. the legacy "boottime" was redundant). XXX There needs to be a lockless synchronization mechanism for reading timebasebin, but this is a problem in kern_tc.c that pre-existed these "boottime" changes. At least now the problem is centralized in one location. To generate a diff of this commit: cvs rdiff -u -r1.37 -r1.38 src/sys/compat/common/kern_info_43.c cvs rdiff -u -r1.33 -r1.34 src/sys/compat/common/kern_time_50.c cvs rdiff -u -r1.40 -r1.41 src/sys/compat/netbsd32/netbsd32_sysctl.c cvs rdiff -u -r1.7 -r1.8 src/sys/external/bsd/drm2/include/linux/ktime.h cvs rdiff -u -r1.2 -r1.3 src/sys/fs/nfs/common/nfs_lock.c cvs rdiff -u -r1.516 -r1.517 src/sys/kern/init_main.c cvs rdiff -u -r1.222 -r1.223 src/sys/kern/init_sysctl.c cvs rdiff -u -r1.95 -r1.96 src/sys/kern/kern_rndq.c cvs rdiff -u -r1.53 -r1.54 src/sys/kern/kern_tc.c cvs rdiff -u -r1.202 -r1.203 src/sys/kern/kern_time.c cvs rdiff -u -r1.130 -r1.131 src/sys/miscfs/fdesc/fdesc_vnops.c cvs rdiff -u -r1.40 -r1.41 src/sys/miscfs/kernfs/kernfs.h cvs rdiff -u -r1.161 -r1.162 src/sys/miscfs/kernfs/kernfs_vnops.c cvs rdiff -u -r1.79 -r1.80 src/sys/miscfs/procfs/procfs_linux.c cvs rdiff -u -r1.177 -r1.178 src/sys/nfs/nfs_serv.c cvs rdiff -u -r1.8 -r1.9 src/sys/rump/librump/rumpkern/cons.c cvs rdiff -u -r1.194 -r1.195 src/sys/rump/librump/rumpkern/emul.c cvs rdiff -u -r1.338 -r1.339 src/sys/rump/librump/rumpkern/rump.c cvs rdiff -u -r1.31 -r1.32 src/sys/sys/kernel.h cvs rdiff -u -r1.39 -r1.40 src/sys/sys/timevar.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/sys/dev/i2c
Module Name:src Committed By: kardel Date: Tue Oct 8 21:16:11 UTC 2019 Modified Files: src/sys/dev/i2c: hytp14.c Log Message: enable FDT direct configuration. remove address test as the i2c address can be changed on this device. To generate a diff of this commit: cvs rdiff -u -r1.8 -r1.9 src/sys/dev/i2c/hytp14.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/sys/dev/i2c
Module Name:src
Committed By: kardel
Date: Tue Oct 8 21:16:11 UTC 2019
Modified Files:
src/sys/dev/i2c: hytp14.c
Log Message:
enable FDT direct configuration.
remove address test as the i2c address can be changed on this device.
To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/sys/dev/i2c/hytp14.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/dev/i2c/hytp14.c
diff -u src/sys/dev/i2c/hytp14.c:1.8 src/sys/dev/i2c/hytp14.c:1.9
--- src/sys/dev/i2c/hytp14.c:1.8 Sat Jun 16 21:24:36 2018
+++ src/sys/dev/i2c/hytp14.c Tue Oct 8 21:16:11 2019
@@ -36,8 +36,32 @@
* $FILE/AHHYTM_E2.1.pdf
*/
+/*
+ * FDT direct configuration fragment to be added to i2cX definition in dtsi file
+ * like in bcm2835-rpi.dtsi or another specific file.
+ *
+ * {
+ * pinctrl-names = "default";
+ * pinctrl-0 = <_gpio2>;
+ * status = "okay";
+ * clock-frequency = <10>;
+ * #address-cells = <1>;
+ * #size-cells = <0>;
+ * hythygtemp@28 {
+ * compatible = "ist-ag,i2c-hytp14";
+ * reg = <0x28>;
+ * status = "okay";
+ * };
+ * hythygtemp@29 {
+ * compatible = "ist-ag,i2c-hytp14";
+ * reg = <0x29>;
+ * status = "okay";
+ * };
+ * };
+ */
+
#include
-__KERNEL_RCSID(0, "$NetBSD: hytp14.c,v 1.8 2018/06/16 21:24:36 thorpej Exp $");
+__KERNEL_RCSID(0, "$NetBSD: hytp14.c,v 1.9 2019/10/08 21:16:11 kardel Exp $");
#include
#include
@@ -95,29 +119,30 @@ static struct hytp14_sensor hytp14_senso
}
};
+static const struct device_compatible_entry compat_data[] = {
+{ "i2c-hytp14", 0 },
+{ NULL, 0 }
+};
+
static int
hytp14_match(device_t parent, cfdata_t match, void *aux)
{
struct i2c_attach_args *ia = aux;
int match_result;
- if (iic_use_direct_match(ia, match, NULL, _result))
+ if (iic_use_direct_match(ia, match, compat_data, _result))
return match_result;
- if (ia->ia_addr == 0x28)
- return I2C_MATCH_ADDRESS_ONLY;
-
/*
- * XXXJRT
- * This device is an odd-ball; the i2c address can be changed
- * at run-time using a command sequence documented in the
- * application note, but the timing is critical (within 10ms
- * after power-on of the device), and the device always starts
- * up at address 0x28.
- *
- * How should we handle this?
+ * This device can be reprogrammed to use a different
+ * I2C address, thus checking for specific addresses
+ * is not helpful here.
+ * reprogramming is done via setting new values in
+ * the device EEPROM via the hytctl utility and
+ * a special GPIO setup - see hythygtemp(4) for more
+ * information.
*/
- return 0;
+ return I2C_MATCH_ADDRESS_ONLY;
}
static void
CVS commit: src/sbin/ifconfig
Module Name:src
Committed By: kardel
Date: Tue Oct 1 10:52:53 UTC 2019
Modified Files:
src/sbin/ifconfig: util.c
Log Message:
PR/54513 ifconfig exits on newly created carp interfaces
downgrade from err(EXIT_FAILURE, ... ) to warn() if ioctl(SIOCGLIFADDR) fails.
ifconfig now survives freshly created carp interfaces.
To generate a diff of this commit:
cvs rdiff -u -r1.18 -r1.19 src/sbin/ifconfig/util.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sbin/ifconfig/util.c
diff -u src/sbin/ifconfig/util.c:1.18 src/sbin/ifconfig/util.c:1.19
--- src/sbin/ifconfig/util.c:1.18 Fri Aug 16 10:33:17 2019
+++ src/sbin/ifconfig/util.c Tue Oct 1 10:52:53 2019
@@ -1,4 +1,4 @@
-/* $NetBSD: util.c,v 1.18 2019/08/16 10:33:17 msaitoh Exp $ */
+/* $NetBSD: util.c,v 1.19 2019/10/01 10:52:53 kardel Exp $ */
/*-
* Copyright (c) 2008 David Young. All rights reserved.
@@ -27,7 +27,7 @@
#include
#ifndef lint
-__RCSID("$NetBSD: util.c,v 1.18 2019/08/16 10:33:17 msaitoh Exp $");
+__RCSID("$NetBSD: util.c,v 1.19 2019/10/01 10:52:53 kardel Exp $");
#endif /* not lint */
#include
@@ -276,7 +276,7 @@ print_link_addresses(prop_dictionary_t e
iflr.prefixlen = sdl->sdl_alen * NBBY;
if (prog_ioctl(s, SIOCGLIFADDR, ) == -1)
- err(EXIT_FAILURE, "%s: ioctl", __func__);
+ warn("%s: ioctl SIOCGLIFADDR", __func__);
if (((iflr.flags & IFLR_ACTIVE) != 0) != print_active_only)
continue;
CVS commit: src/sbin/ifconfig
Module Name:src Committed By: kardel Date: Tue Oct 1 10:52:53 UTC 2019 Modified Files: src/sbin/ifconfig: util.c Log Message: PR/54513 ifconfig exits on newly created carp interfaces downgrade from err(EXIT_FAILURE, ... ) to warn() if ioctl(SIOCGLIFADDR) fails. ifconfig now survives freshly created carp interfaces. To generate a diff of this commit: cvs rdiff -u -r1.18 -r1.19 src/sbin/ifconfig/util.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/sys/dev/scsipi
Module Name:src
Committed By: kardel
Date: Sun May 19 19:06:53 UTC 2019
Modified Files:
src/sys/dev/scsipi: st.c
Log Message:
Add simple position recovery when positioning to EOM by reading
the position with READ_POSITION.
this allows for
mt eom
mt st
to return the correct file position.
To generate a diff of this commit:
cvs rdiff -u -r1.237 -r1.238 src/sys/dev/scsipi/st.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/dev/scsipi/st.c
diff -u src/sys/dev/scsipi/st.c:1.237 src/sys/dev/scsipi/st.c:1.238
--- src/sys/dev/scsipi/st.c:1.237 Sat Feb 23 11:57:41 2019
+++ src/sys/dev/scsipi/st.c Sun May 19 19:06:53 2019
@@ -1,4 +1,4 @@
-/* $NetBSD: st.c,v 1.237 2019/02/23 11:57:41 kamil Exp $ */
+/* $NetBSD: st.c,v 1.238 2019/05/19 19:06:53 kardel Exp $ */
/*-
* Copyright (c) 1998, 2004 The NetBSD Foundation, Inc.
@@ -50,7 +50,7 @@
*/
#include
-__KERNEL_RCSID(0, "$NetBSD: st.c,v 1.237 2019/02/23 11:57:41 kamil Exp $");
+__KERNEL_RCSID(0, "$NetBSD: st.c,v 1.238 2019/05/19 19:06:53 kardel Exp $");
#ifdef _KERNEL_OPT
#include "opt_scsi.h"
@@ -355,6 +355,7 @@ static int st_rewind(struct st_softc *,
static int st_interpret_sense(struct scsipi_xfer *);
static int st_touch_tape(struct st_softc *);
static int st_erase(struct st_softc *, int full, int flags);
+static void st_updatefilepos(struct st_softc *);
static int st_rdpos(struct st_softc *, int, uint32_t *);
static int st_setpos(struct st_softc *, int, uint32_t *);
@@ -1823,8 +1824,7 @@ st_space(struct st_softc *st, int number
st->blkno = -1;
}
} else if (what == SP_EOM) {
- /* This loses us relative position. */
- st->fileno = st->blkno = -1;
+st_updatefilepos(st);
}
}
return error;
@@ -1997,6 +1997,54 @@ st_rewind(struct st_softc *st, u_int imm
return error;
}
+static void
+st_updatefilepos(struct st_softc *st)
+{
+int error;
+uint8_t posdata[32];
+struct scsi_tape_read_position cmd;
+
+memset(, 0, sizeof(cmd));
+memset(, 0, sizeof(posdata));
+cmd.opcode = READ_POSITION;
+cmd.byte1 = 6; /* service action: LONG FORM */
+
+error = scsipi_command(st->sc_periph, (void *), sizeof(cmd),
+(void *), sizeof(posdata), ST_RETRIES, ST_CTL_TIME, NULL,
+XS_CTL_SILENT | XS_CTL_DATA_IN);
+
+if (error == 0) {
+#ifdef SCSIPI_DEBUG
+if (st->sc_periph->periph_dbflags & SCSIPI_DB3) {
+int hard;
+
+printf("posdata: ");
+for (hard = 0; hard < sizeof(posdata); hard++)
+printf("%02x ", posdata[hard] & 0xff);
+printf("\n");
+}
+#endif
+if (posdata[0] & 0xC) { /* Block|Mark Position Unknown */
+SC_DEBUG(st->sc_periph, SCSIPI_DB3,
+ ("st_updatefilepos block/mark position unknown (0x%02x)\n",
+ posdata[0]));
+} else {
+st->fileno = _8btol([16]);
+st->blkno = 0;
+SC_DEBUG(st->sc_periph, SCSIPI_DB3,
+ ("st_updatefilepos file position %"PRId64"\n",
+ st->fileno));
+return;
+}
+} else {
+SC_DEBUG(st->sc_periph, SCSIPI_DB3,
+ ("st_updatefilepos READ POSITION(LONG_FORM) failed (error=%d)\n",
+ error));
+}
+st->fileno = -1;
+st->blkno = -1;
+}
+
static int
st_rdpos(struct st_softc *st, int hard, uint32_t *blkptr)
{
Re: CVS commit: src/sys/dev/pci
Hi! Great, that did it - no more immediately visible device deficiencies. com* work wm1 works radeon still spits errors [10.941427] kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [12.002002] kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! graphics seem to work though with little flickering in glx windows. So except for the radeon startup (and possible minor flickering in glx windows) my system seems to work now when booted via UEFI. Maybe someone with more insight in the radeon reset code can give hints what could be missing. So the system looks usable now just leaving the radeon UVD reset issue as final topic. Thanks! Frank The left-over pci setup differences are: --- lspci-csm-201901272019-01-27 14:42:57.454117956 +0100 +++ lspci-uefi-20190127.12019-01-28 07:10:47.857701110 +0100 @@ -4,7 +4,7 @@ 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1451 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1451 -Flags: bus master, fast devsel, latency 0, IRQ 255 +Flags: fast devsel, IRQ 255 Capabilities: [40] Secure device Capabilities: [64] MSI: Enable- Count=1/4 Maskable- 64bit+ Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+ @@ -339,7 +339,7 @@ 21:00.0 Serial controller: MosChip Semiconductor Technology Ltd. 4-Port PCIe Serial Adapter (prog-if 02 [16550]) Subsystem: Device a000:1000 -Flags: bus master, fast devsel, latency 0, IRQ 11 +Flags: fast devsel, IRQ 11 I/O ports at b030 Memory at fcc07000 (32-bit, non-prefetchable) Memory at fcc06000 (32-bit, non-prefetchable) @@ -351,7 +351,7 @@ 21:00.1 Serial controller: MosChip Semiconductor Technology Ltd. 4-Port PCIe Serial Adapter (prog-if 02 [16550]) Subsystem: Device a000:1000 -Flags: bus master, fast devsel, latency 0, IRQ 11 +Flags: fast devsel, IRQ 11 I/O ports at b020 Memory at fcc05000 (32-bit, non-prefetchable) Memory at fcc04000 (32-bit, non-prefetchable) @@ -362,7 +362,7 @@ 21:00.2 Serial controller: MosChip Semiconductor Technology Ltd. 4-Port PCIe Serial Adapter (prog-if 02 [16550]) Subsystem: Device a000:1000 -Flags: bus master, fast devsel, latency 0, IRQ 10 +Flags: fast devsel, IRQ 10 I/O ports at b010 Memory at fcc03000 (32-bit, non-prefetchable) Memory at fcc02000 (32-bit, non-prefetchable) @@ -373,7 +373,7 @@ 21:00.3 Serial controller: MosChip Semiconductor Technology Ltd. 4-Port PCIe Serial Adapter (prog-if 02 [16550]) Subsystem: Device a000:1000 -Flags: bus master, fast devsel, latency 0, IRQ 5 +Flags: fast devsel, IRQ 5 I/O ports at b000 Memory at fcc01000 (32-bit, non-prefetchable) Memory at fcc0 (32-bit, non-prefetchable) @@ -384,7 +384,7 @@ 24:00.0 System peripheral: Meinberg Funkuhren GPS180PEX GPS Receiver (PCI Express) (rev 01) Subsystem: Meinberg Funkuhren GPS180PEX GPS Receiver (PCI Express) -Flags: bus master, fast devsel, latency 0, IRQ 5 +Flags: fast devsel, IRQ 5 I/O ports at a000 Memory at fcb0 (32-bit, non-prefetchable) Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+ @@ -465,7 +465,7 @@ 29:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 145a Subsystem: Advanced Micro Devices, Inc. [AMD] Device 145a -Flags: bus master, fast devsel, latency 0, IRQ 255 +Flags: fast devsel, IRQ 255 Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [64] Express Endpoint, MSI 00 @@ -476,9 +476,9 @@ 29:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1456 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1456 -Flags: bus master, fast devsel, latency 0, IRQ 11 -Memory at fd10 (32-bit, non-prefetchable) -Memory at fd20 (32-bit, non-prefetchable) +Flags: fast devsel, IRQ 11 +Memory at fd10 (32-bit, non-prefetchable) [disabled] +Memory at fd20 (32-bit, non-prefetchable) [disabled] Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [64] Express Endpoint, MSI 00 @@ -502,7 +502,7 @@ 2a:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 1455 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1455 -Flags: bus master, fast devsel, latency 0, IRQ 255 +Flags: fast devsel, IRQ 255 Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [64] Express Endpoint, MSI 00 On 01/28/19 05:11, Masanobu SAITOH wrote: Hi. On 2019/01/28 4:05, Frank
Re: CVS commit: src/sys/dev/pci
Hi, that made all devices being recognized during boot with UEFI - good. We seem closer, but not there yet (for my main board at least). There is still an issue with interrupts (or dma - see missing bus master in pci differences). It seems device interrupts via ioapic don't get interrupts/data at all or not reliably. This affects following devices AFAICS on my system: com* wm1 (PCIe network card) radeon (see errors below) MSI/X using devices seem to do fine. Interrupt allocation is the same in both environments: UEFI & CSM interrupt iddevice name(s) ioapic0 pin 9 acpi SCI ioapic0 pin 1 pckbc1 kbd msix0 vec 0 nvme0 adminq msix0 vec 1 nvme0 ioq1 msix0 vec 2 nvme0 ioq2 msix0 vec 3 nvme0 ioq3 msix0 vec 4 nvme0 ioq4 msix0 vec 5 nvme0 ioq5 msix0 vec 6 nvme0 ioq6 msix0 vec 7 nvme0 ioq7 msi1 vec 0 xhci0 msi2 vec 0 ahcisata0 msix3 vec 0 wm0TXRX0 msix3 vec 1 wm0TXRX1 msix3 vec 2 wm0LINK ioapic1 pin 10 wm1, com5 ioapic1 pin 11 com2, ahd0 ioapic1 pin 8 com3 ioapic1 pin 9 com4 msi4 vec 0 hdaudio0 msi5 vec 0 mpii0 msi6 vec 0 xhci1 msi7 vec 0 ahcisata1 msi8 vec 0 hdaudio1 ioapic0 pin 4 com0 ioapic1 pin 30 radeon0 Other hickups seen: keyboard input (PS/2) is sometimes repeated glxgears regularly stalls for a seconds and does not really run smoothly. llinfo entries for wm1 fail, arp resolution on wm1 fail wm1 seems completely broken - no packets are received there dmesg differences are from efi presence, minor difference memory size, different usb detection sequence. nothing critical. The main difference is the radeon* fails to properly initialize giving these diagnostics: kern info: [drm] radeon: irq initialized. kern info: [drm] ring test on 0 succeeded in 0 usecs kern info: [drm] ring test on 3 succeeded in 3 usecs kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:354)uvd_v1_0_start] *ERROR* UVD not responding, giving up!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_evergreen.c:5688)evergreen_startup] *ERROR* radeon: error initializing UVD (-1). kern info: [drm] ib test on ring 0 succeeded in 0 usecs kern info: [drm] ib test on ring 3 succeeded in 0 usecs Differences between pci configs (lspic -v) --- lspci-csm-20190127 2019-01-27 14:42:57.454117956 +0100 +++ lspci-uefi-20190127 2019-01-27 14:51:27.003880544 +0100 @@ -4,7 +4,7 @@ 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1451 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1451 - Flags: bus master, fast devsel, latency 0, IRQ 255 + Flags: fast devsel, IRQ 255 Capabilities: [40] Secure device Capabilities: [64] MSI: Enable- Count=1/4 Maskable- 64bit+ Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+ @@ -213,7 +213,7 @@ Capabilities: [100] Advanced Error Reporting 1d:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) (prog-if 00 [Normal decode]) - Flags: bus master, fast devsel, latency 0, IRQ 11 + Flags: fast devsel, IRQ 11 Bus: primary=1d, secondary=1e, subordinate=1e, sec-latency=0 I/O behind bridge:
Re: CVS commit: src/sys/dev/i2c
Hi Jason ! It is not so odd as your comment suggests. The I2C address is stored in the device EEPROM and perfectly survives a power off. All we need to be able to is to explicitly configure the device at a different address. I hope this capability was not disabled with this check-in as that would make my second sensor at 0x29 useless and prohibit multiple sensors on a I2C bus. For configuring the I2C address to a different value see the pkgsrc package hytctl. Thanks for re-working the attachment logic. Frank On 06/16/18 23:24, Jason R Thorpe wrote: Module Name:src Committed By: thorpej Date: Sat Jun 16 21:24:36 UTC 2018 Modified Files: src/sys/dev/i2c: hytp14.c Log Message: More cleanup to i2c autoconfiguration: - Get all of the drivers onto the new match quality constants. - Introduce a new helper function, iic_use_direct_match(), that has all of the logic for direct-config matching. If it returns true, the driver returns the match result (which may be 0). If it returns false, the driver does indirect-config matching. - iic_compat_match() now returns a weighted match quality; matches to lower-indexed "compatible" device property are more-specific matches, and return a better match quality accordingly. XXX This driver is an odd-ball with respect to the hardware device. See comments in the match routine. Unclear how best to handle it. To generate a diff of this commit: cvs rdiff -u -r1.7 -r1.8 src/sys/dev/i2c/hytp14.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/dev/pci/ixgbe
Hi,
I am now seeing that packet reception stops. tcpdump will only show
outgoing packets and no incoming packets.
ifconfig ixgX down
ifconfig ixgX up
gets things going again.
Code from 2018-02-24 was fine and I think even code shortly before this
commit was fine, but there was the mbuf used-after-free issue that hit
me pretty hard. So the system wasn't running for too long anyway.
Does that ring a bell ?
Frank
On 04/25/18 10:46, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Wed Apr 25 08:46:19 UTC 2018
Modified Files:
src/sys/dev/pci/ixgbe: ix_txrx.c ixgbe.h ixgbe_netbsd.c ixgbe_netbsd.h
ixgbe_osdep.h
Log Message:
Don't free and reallocate bus_dmamem when it's not required. Currently,
the watchdog timer is completely broken and never fire (it's from FreeBSD
(pre iflib)). If the problem is fixed and watchdog fired, ixgbe_init() always
calls ixgbe_jcl_reinit() and it causes panic. The reason is that
ixgbe_local_timer1(it includes watchdog function) is softint and
xgbe_jcl_reinit() calls bus_dmamem*() functions. bus_dmamem*() can't be called
from interrupt context.
One of the way to prevent panic is use worqueue for the timer, but it's
not a small change. (I'll do it in future).
Another way is not reallocate dmamem if it's not required. If both the MTU
(rx_mbuf_sz in reality) and the number of RX descriptors are not changed, it's
not required to call bus_dmamem_{unmap,free}(). Even if we use workque, this
change save time of ixgbe_init().
I have a code to fix broken watchdog timer but it sometime causes watchdog
timeout, so I don't commit it yet.
To generate a diff of this commit:
cvs rdiff -u -r1.40 -r1.41 src/sys/dev/pci/ixgbe/ix_txrx.c
cvs rdiff -u -r1.45 -r1.46 src/sys/dev/pci/ixgbe/ixgbe.h
cvs rdiff -u -r1.6 -r1.7 src/sys/dev/pci/ixgbe/ixgbe_netbsd.c
cvs rdiff -u -r1.7 -r1.8 src/sys/dev/pci/ixgbe/ixgbe_netbsd.h
cvs rdiff -u -r1.21 -r1.22 src/sys/dev/pci/ixgbe/ixgbe_osdep.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Re: CVS commit: src/sys/dev/pci/ixgbe
Hi,
I am now seeing that packet reception stops. tcpdump will only show
outgoing packets and no incoming packets.
ifconfig ixgX down
ifconfig ixgX up
gets things going again.
Code from 2018-02-24 was fine and I think even code shortly before this
commit was fine, but there was the mbuf used-after-free issue that hit
me pretty hard. So the system wasn't running for too long anyway.
Does that ring a bell ?
Frank
On 04/25/18 10:46, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Wed Apr 25 08:46:19 UTC 2018
Modified Files:
src/sys/dev/pci/ixgbe: ix_txrx.c ixgbe.h ixgbe_netbsd.c ixgbe_netbsd.h
ixgbe_osdep.h
Log Message:
Don't free and reallocate bus_dmamem when it's not required. Currently,
the watchdog timer is completely broken and never fire (it's from FreeBSD
(pre iflib)). If the problem is fixed and watchdog fired, ixgbe_init() always
calls ixgbe_jcl_reinit() and it causes panic. The reason is that
ixgbe_local_timer1(it includes watchdog function) is softint and
xgbe_jcl_reinit() calls bus_dmamem*() functions. bus_dmamem*() can't be called
from interrupt context.
One of the way to prevent panic is use worqueue for the timer, but it's
not a small change. (I'll do it in future).
Another way is not reallocate dmamem if it's not required. If both the MTU
(rx_mbuf_sz in reality) and the number of RX descriptors are not changed, it's
not required to call bus_dmamem_{unmap,free}(). Even if we use workque, this
change save time of ixgbe_init().
I have a code to fix broken watchdog timer but it sometime causes watchdog
timeout, so I don't commit it yet.
To generate a diff of this commit:
cvs rdiff -u -r1.40 -r1.41 src/sys/dev/pci/ixgbe/ix_txrx.c
cvs rdiff -u -r1.45 -r1.46 src/sys/dev/pci/ixgbe/ixgbe.h
cvs rdiff -u -r1.6 -r1.7 src/sys/dev/pci/ixgbe/ixgbe_netbsd.c
cvs rdiff -u -r1.7 -r1.8 src/sys/dev/pci/ixgbe/ixgbe_netbsd.h
cvs rdiff -u -r1.21 -r1.22 src/sys/dev/pci/ixgbe/ixgbe_osdep.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Re: CVS commit: src/sys/netinet
This must be revisited - IKE/racoon breaks with 1.240. racoon listens on port 500. packets for port 500 arrive at the interface (tcpdump sees them), but racoon NEVER receives any packets for port 500 (debug/ktuss sees nothing). Frank On 02/10/18 09:17, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Sat Feb 10 08:17:00 UTC 2018 Modified Files: src/sys/netinet: udp_usrreq.c Log Message: If the socket wants a ESP-over-UDP packet, and the packet is incorrect, stop processing it instead of giving it to udp4_sendup. It just doesn't make any sense not to drop it. I was already telling myself this the other day when I visited this place, but I just saw PR/36782 (11 years old) that suggests the exact same thing, so fix it. Now, udp4_espinudp always frees the mbuf, and is made void. The packet is not processed any further afterwards. To generate a diff of this commit: cvs rdiff -u -r1.239 -r1.240 src/sys/netinet/udp_usrreq.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/netinet6
comment fixed (CVS lines removed). Sorry for the noise Frank On 05/13/17 22:13, Frank Kardel wrote: Module Name:src Committed By: kardel Date: Sat May 13 20:13:27 UTC 2017 Modified Files: src/sys/netinet6: mld6.c Log Message: avoid a double ifa_release() and thus a panic when e. g. running ifmcstat CVS: -- CVS: CVSROOT cvs.NetBSD.org:/cvsroot CVS: please use "PR category/123" to have the commitmsg appended to PR 123 CVS: CVS: Please evaluate your changes and consider the following. CVS: Abort checkin if you answer no. CVS: => For all changes: CVS: Do the changed files compile? CVS: Has the change been tested? CVS: => If you are not completely familiar with the changed components: CVS: Has the change been posted for review? CVS: Have you allowed enough time for feedback? CVS: => If the change is major: CVS: => If the change adds files to, or removes files from $DESTDIR: CVS: => If you are changing a library or kernel interface: CVS: Have you successfully run "./build.sh release"? To generate a diff of this commit: cvs rdiff -u -r1.88 -r1.89 src/sys/netinet6/mld6.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sbin/ping
The bug seems to also exist in NetBSD-7.1 - maybe a pull-up would be helpful. Best regards, Frank Kardel On 03/17/17 07:52, Ryo Shimizu wrote: Module Name:src Committed By: ryo Date: Fri Mar 17 06:52:59 UTC 2017 Modified Files: src/sbin/ping: ping.c Log Message: Fix cksum calculation for clearing the cached route. In ping.c:r1.104, the size of echoreply packet was changed to ICMP_MINLEN, Therefore also calculation size must be ICMP_MINLEN. To generate a diff of this commit: cvs rdiff -u -r1.115 -r1.116 src/sbin/ping/ping.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys
On 01/04/17 09:37, Paul Goyette wrote:
On Wed, 4 Jan 2017, Frank Kardel wrote:
I would also suggest a 64 bit fraction like in struct bintime, which
we already have and use internally for timekeeping anyway along with
the timespec, timeval conversion functions.
Thus collecting can be faster as we don't need to make the
conversions when collectiing. I deem converting at userlevel the
least worry.
For time stamp fetching see "man 9 microtime" or
kern/kern_tc.c:{get,}bin{,up}time(). "get"-versions are cheaper, but
only updated at hardclock(). The non-get ones are directly related
to the current time counter.
Using bintime as the "native" timestamp representation would require
changes to the in-kernel structures, rather than just those used for
I see - I didn't look at the event collection yet. bintime is the native
kernel timestamp format,
though it is not used everywhere.
exporting the data to userland. And if the in-kernel structures are
changed, then we'll have to be able to print them from within the
kernel.
For userland we could just do float- or double-divide to convert the
fraction to printable format;
Yep that's the usual procedure.
sys/time.h already has a non-fp conversion to timeval/timespec.
static __inline void
bintime2timespec(const struct bintime *bt, struct timespec *ts)
{
ts->tv_sec = bt->sec;
ts->tv_nsec =
(long)(((uint64_t)10 * (uint32_t)(bt->frac >>
32)) >> 32);
}
it's not clear how we could print these
values from within the kernel (where we're not allowed to use fp?).
Would converting to timespec/timeval and the usual %d.%06?d printf-fmt
be an option without creating a horrible data wrangling mess? (I don't
know how many
printfs would be affected).
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Frank
Re: CVS commit: src/sys
Completely agreed, That's why I proposed to consider struct bintime. We can tackle various aspects of improving the implementations benefiting from the improved APIs at any time later. IMHO struct bintime is sufficiently powerful enough to cover the interface stability requirements (nsec are already being split by 4 with 4+GHz cycle counters - so something better than timespec should already be in scope). Frank On 01/04/17 22:55, Robert Elz wrote: Date:Wed, 04 Jan 2017 22:06:35 +0100 From:Frank Kardel <kar...@netbsd.org> Message-ID: <586d63db.9060...@netbsd.org> | The extendend resolution would be done providing the API. IMO, what is important right now, is that when designing new APIs (which is what Paul is doing) (and or changing old ones) we get that design right, so it doesn't need to change again in the future, with all the consqquest vessioning required to keep things working. Whether or not the data provided through the "really good" API is as good as it could be is a far less important issue - that can be improved (fairly unobtrusively) whenever someone has the time to work on it. kre
Re: CVS commit: src/sys
There are two things - the extended resolution and general timing handling. The extendend resolution would be done providing the API. But there is quite some work to make the APIs fullfull the expectations. For that we would need to go into the tickless direction and use precicion (one-) time interrupts for timeout and timing handling. That would be a more elaborate project. FreeBSD is using the precision time interrupts for a while now, if I looked correctly into the kernel code. But, I am too busy now for such a project. Frank On 01/04/17 20:52, Taylor R Campbell wrote: Date: Wed, 04 Jan 2017 10:58:47 +0100 From: Frank Kardel <kar...@kardel.name> I agree, the decision is whether we want bintime in the export format. Sounds good to me. We should use bintime more often. I have been meaning to add some high-resolution timer-related APIs that use it, e.g. cv_timedwaitbt, but my round tuit tank is running on fumes.
Re: CVS commit: src/sys
I agree, the decision is whether we want bintime in the export format.
For the microtime/nanotime question (see kern/kern_tc.c):
binuptime()=scaled time counter read
bintime()=binuptime()+bootimeoffset
nanotime()=bintime()+bintime2timespec()
microtime()=bintime()+bintime2timeval()
So any use of microtime and nanotime does the conversion from bintime to
the required format. So timestamp collection incurs this conversion
overhead.
The get-versions are cheaper, but they only provide a cached timestamp
from basically the last hardclock() event. So they are not really
suitable for
high resolution time stamping - but probably ok for file system time
stamps and probably device drivers.
Yes - time is a time consuming topic at a certain level and you are
almost always certain to get it wrong :-)
Frank
On 01/04/17 10:18, Paul Goyette wrote:
On Wed, 4 Jan 2017, Frank Kardel wrote:
On 01/04/17 09:37, Paul Goyette wrote:
On Wed, 4 Jan 2017, Frank Kardel wrote:
I would also suggest a 64 bit fraction like in struct bintime,
which we already have and use internally for timekeeping anyway
along with the timespec, timeval conversion functions.
Thus collecting can be faster as we don't need to make the
conversions when collectiing. I deem converting at userlevel the
least worry.
For time stamp fetching see "man 9 microtime" or
kern/kern_tc.c:{get,}bin{,up}time(). "get"-versions are cheaper,
but only updated at hardclock(). The non-get ones are directly related
to the current time counter.
Using bintime as the "native" timestamp representation would require
changes to the in-kernel structures, rather than just those used for
I see - I didn't look at the event collection yet. bintime is the
native kernel timestamp format,
though it is not used everywhere.
exporting the data to userland. And if the in-kernel structures are
changed, then we'll have to be able to print them from within the
kernel.
For userland we could just do float- or double-divide to convert the
fraction to printable format;
Yep that's the usual procedure.
sys/time.h already has a non-fp conversion to timeval/timespec.
static __inline void
bintime2timespec(const struct bintime *bt, struct timespec *ts)
{
ts->tv_sec = bt->sec;
ts->tv_nsec =
(long)(((uint64_t)10 * (uint32_t)(bt->frac >>
32)) >> 32);
}
it's not clear how we could print these
values from within the kernel (where we're not allowed to use fp?).
Would converting to timespec/timeval and the usual %d.%06?d
printf-fmt be an option without creating a horrible data wrangling
mess? (I don't know how many
printfs would be affected).
There's not many printfs to worry about - exactly 1 in the kernel, and
only 1 that I know of in userland (in vmstat.c). (The kernel one is
intended to be called via ddb(4)'s 'show kernhist' command - or some
other debugger, but I guess you could figure out a way to call it from
somewhere else.)
As long as we can guarantee that a time_t is always 64-bits, I don't
see any reason why we can't use the conversion functions from
sys/time.h in both kernel and user side.
Of course, it all depends on whether we decide on bintime as the
export format.
Just out of curiousity, how expensive is bintime(9), compared to
microtime(9) or nanotime(9)? We're already doing microtime to get the
in-kernel timestamp, so if bintime(9) is the same cost, it would be
better (IMHO) to change the internal value now. Then the only time we
need any conversion is at printf() time.
Wow - I never imagined how many worms there were in this little can!
:)
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++
Re: CVS commit: src/sys
I would also suggest a 64 bit fraction like in struct bintime, which we
already have and use internally for timekeeping anyway along with the
timespec, timeval conversion functions.
Thus collecting can be faster as we don't need to make the conversions
when collectiing. I deem converting at userlevel the least worry.
For time stamp fetching see "man 9 microtime" or
kern/kern_tc.c:{get,}bin{,up}time(). "get"-versions are cheaper, but
only updated at hardclock(). The non-get ones are directly related
to the current time counter.
Frank
On 01/04/17 07:45, Robert Elz wrote:
Date:Wed, 4 Jan 2017 05:52:45 +
From:David Holland
Message-ID: <20170104055245.ga16...@netbsd.org>
| also make it nsec...
Since it is a 64 bt value, better would be pico-secs if it is going
to continue to be a timeval/timespec kind of number - but better would be
to make it be a binary fraction of a second (ie: fixed point with the
point to the left of the MSBit position - then the precision can grow
as needed (to absurd values) without canging the API)
kre
Re: CVS commit: src
Seems to be a bit incomplete. I see failure in nilfs and fsck_lfs during a release build (i386). FRank On 03/28/15 20:24, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Sat Mar 28 19:24:06 UTC 2015 Modified Files: src/share/man/man9: buffercache.9 src/sys/fs/adosfs: advfsops.c advnops.c src/sys/fs/cd9660: cd9660_lookup.c cd9660_rrip.c cd9660_vfsops.c cd9660_vnops.c src/sys/fs/efs: efs_subr.c src/sys/fs/filecorefs: filecore_bmap.c filecore_vfsops.c filecore_vnops.c src/sys/fs/hfs: hfs_subr.c src/sys/fs/msdosfs: msdosfs_denode.c msdosfs_fat.c msdosfs_lookup.c msdosfs_vfsops.c msdosfs_vnops.c src/sys/fs/nilfs: nilfs_subr.c nilfs_vfsops.c src/sys/fs/ntfs: ntfs_subr.c ntfs_vfsops.c src/sys/fs/sysvbfs: bfs_sysvbfs.c src/sys/fs/v7fs: v7fs_io_kern.c src/sys/kern: vfs_bio.c src/sys/miscfs/specfs: spec_vnops.c src/sys/sys: buf.h src/sys/ufs/chfs: chfs_vnops.c src/sys/ufs/ext2fs: ext2fs_alloc.c ext2fs_balloc.c ext2fs_inode.c ext2fs_readwrite.c ext2fs_subr.c ext2fs_vfsops.c src/sys/ufs/ffs: ffs_alloc.c ffs_balloc.c ffs_inode.c ffs_snapshot.c ffs_vfsops.c ffs_wapbl.c src/sys/ufs/lfs: lfs.h lfs_balloc.c lfs_rfw.c lfs_segment.c lfs_syscalls.c lfs_vfsops.c ulfs_quota2.c ulfs_readwrite.c src/sys/ufs/ufs: ufs_quota2.c ufs_readwrite.c Log Message: Remove the 'cred' argument from bread(). Remove a now unused var in ffs_snapshot.c. Update the man page accordingly. ok hannken@ To generate a diff of this commit: cvs rdiff -u -r1.26 -r1.27 src/share/man/man9/buffercache.9 cvs rdiff -u -r1.72 -r1.73 src/sys/fs/adosfs/advfsops.c cvs rdiff -u -r1.45 -r1.46 src/sys/fs/adosfs/advnops.c cvs rdiff -u -r1.29 -r1.30 src/sys/fs/cd9660/cd9660_lookup.c cvs rdiff -u -r1.17 -r1.18 src/sys/fs/cd9660/cd9660_rrip.c cvs rdiff -u -r1.89 -r1.90 src/sys/fs/cd9660/cd9660_vfsops.c cvs rdiff -u -r1.50 -r1.51 src/sys/fs/cd9660/cd9660_vnops.c cvs rdiff -u -r1.10 -r1.11 src/sys/fs/efs/efs_subr.c cvs rdiff -u -r1.10 -r1.11 src/sys/fs/filecorefs/filecore_bmap.c cvs rdiff -u -r1.77 -r1.78 src/sys/fs/filecorefs/filecore_vfsops.c cvs rdiff -u -r1.42 -r1.43 src/sys/fs/filecorefs/filecore_vnops.c cvs rdiff -u -r1.17 -r1.18 src/sys/fs/hfs/hfs_subr.c cvs rdiff -u -r1.50 -r1.51 src/sys/fs/msdosfs/msdosfs_denode.c cvs rdiff -u -r1.28 -r1.29 src/sys/fs/msdosfs/msdosfs_fat.c cvs rdiff -u -r1.33 -r1.34 src/sys/fs/msdosfs/msdosfs_lookup.c cvs rdiff -u -r1.117 -r1.118 src/sys/fs/msdosfs/msdosfs_vfsops.c cvs rdiff -u -r1.91 -r1.92 src/sys/fs/msdosfs/msdosfs_vnops.c cvs rdiff -u -r1.12 -r1.13 src/sys/fs/nilfs/nilfs_subr.c cvs rdiff -u -r1.20 -r1.21 src/sys/fs/nilfs/nilfs_vfsops.c cvs rdiff -u -r1.60 -r1.61 src/sys/fs/ntfs/ntfs_subr.c cvs rdiff -u -r1.103 -r1.104 src/sys/fs/ntfs/ntfs_vfsops.c cvs rdiff -u -r1.10 -r1.11 src/sys/fs/sysvbfs/bfs_sysvbfs.c cvs rdiff -u -r1.2 -r1.3 src/sys/fs/v7fs/v7fs_io_kern.c cvs rdiff -u -r1.254 -r1.255 src/sys/kern/vfs_bio.c cvs rdiff -u -r1.145 -r1.146 src/sys/miscfs/specfs/spec_vnops.c cvs rdiff -u -r1.120 -r1.121 src/sys/sys/buf.h cvs rdiff -u -r1.26 -r1.27 src/sys/ufs/chfs/chfs_vnops.c cvs rdiff -u -r1.45 -r1.46 src/sys/ufs/ext2fs/ext2fs_alloc.c cvs rdiff -u -r1.39 -r1.40 src/sys/ufs/ext2fs/ext2fs_balloc.c cvs rdiff -u -r1.81 -r1.82 src/sys/ufs/ext2fs/ext2fs_inode.c cvs rdiff -u -r1.73 -r1.74 src/sys/ufs/ext2fs/ext2fs_readwrite.c cvs rdiff -u -r1.30 -r1.31 src/sys/ufs/ext2fs/ext2fs_subr.c cvs rdiff -u -r1.192 -r1.193 src/sys/ufs/ext2fs/ext2fs_vfsops.c cvs rdiff -u -r1.148 -r1.149 src/sys/ufs/ffs/ffs_alloc.c cvs rdiff -u -r1.60 -r1.61 src/sys/ufs/ffs/ffs_balloc.c cvs rdiff -u -r1.116 -r1.117 src/sys/ufs/ffs/ffs_inode.c cvs rdiff -u -r1.138 -r1.139 src/sys/ufs/ffs/ffs_snapshot.c cvs rdiff -u -r1.326 -r1.327 src/sys/ufs/ffs/ffs_vfsops.c cvs rdiff -u -r1.29 -r1.30 src/sys/ufs/ffs/ffs_wapbl.c cvs rdiff -u -r1.160 -r1.161 src/sys/ufs/lfs/lfs.h cvs rdiff -u -r1.80 -r1.81 src/sys/ufs/lfs/lfs_balloc.c cvs rdiff -u -r1.18 -r1.19 src/sys/ufs/lfs/lfs_rfw.c cvs rdiff -u -r1.236 -r1.237 src/sys/ufs/lfs/lfs_segment.c cvs rdiff -u -r1.155 -r1.156 src/sys/ufs/lfs/lfs_syscalls.c cvs rdiff -u -r1.321 -r1.322 src/sys/ufs/lfs/lfs_vfsops.c cvs rdiff -u -r1.17 -r1.18 src/sys/ufs/lfs/ulfs_quota2.c cvs rdiff -u -r1.14 -r1.15 src/sys/ufs/lfs/ulfs_readwrite.c cvs rdiff -u -r1.39 -r1.40 src/sys/ufs/ufs/ufs_quota2.c cvs rdiff -u -r1.114 -r1.115 src/sys/ufs/ufs/ufs_readwrite.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/dev/usb
Thanks Michael ! It really does improves the speed, great :-). Unfortunately, I am seeing about once a day a panic (uvm_fault) and the RPI thus is much less stable than before. The stack trace I could hand copy is: Trap in m_xhalf+0x9c bt gave: bpf_filter_ext+0xc _bpf_mtap+0x278 smsc_rxeof+0x11c usb_transfer_complete+0x2d4 dwc2_softintr+0x90 usb_softintr+0x28 softint_dispatch+0xec I'll now backout the change to see whether the panics disappear. Frank On 06/09/14 16:18, Michael van Elst wrote: Module Name:src Committed By: mlelstv Date: Mon Jun 9 14:18:28 UTC 2014 Modified Files: src/sys/dev/usb: if_smsc.c if_smscreg.h if_smscvar.h Log Message: Fix receive loop, enable turbo mode, checksum offloading still needs correct handling of pseudo headers. The Raspberry PI now copies at 2MByte/s with scp and 4MByte/s with NFS. Based on work from nick@. To generate a diff of this commit: cvs rdiff -u -r1.12 -r1.13 src/sys/dev/usb/if_smsc.c cvs rdiff -u -r1.3 -r1.4 src/sys/dev/usb/if_smscreg.h cvs rdiff -u -r1.2 -r1.3 src/sys/dev/usb/if_smscvar.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/distrib/sets/lists/modules
Thanks ! - I have it in my tree, but missed to commit it - sorry. Frank On 05/18/14 20:28, Jonathan A. Kollasch wrote: Module Name:src Committed By: jakllsch Date: Sun May 18 18:28:49 UTC 2014 Modified Files: src/distrib/sets/lists/modules: md.evbppc.powerpc mi Log Message: add hythygtemp module to set lists To generate a diff of this commit: cvs rdiff -u -r1.2 -r1.3 src/distrib/sets/lists/modules/md.evbppc.powerpc cvs rdiff -u -r1.68 -r1.69 src/distrib/sets/lists/modules/mi Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
Dennis, while the MC68020 did not have an MMU onboard there where Motorola PMMUs out there (MC68851). In the beginning there was an FPGA solution that emulated a subset of the MC68851 PMMU via the Coprocessor interface. Later when the PMMU became available it was also used in designs. E. g. I put an XC68851 (pre-production sample) into my Mac II around 1988 and could run A/UX (or whatever it was called). Early versions of NetBSD did work too. So there was some 'common' MMU support for the '20 via the PMMU coprocessor support. Sun had it's own MMU, though. The MC68851 came late to the market, that's probably the cause why so many non-Motorola solutions existed for the 68020. Frank On 04/15/14 21:43, Dennis Ferguson wrote: On 15 Apr, 2014, at 05:14 , Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: - NetBSD/x68k supports only X680x0 machines with MC68030 and higher processors. - Normal X68000 machines (i.e. all X680x0 except X68030) have MC68000, so 030 accelerators are required for the X68000 models, i.e. XVI, SUPER, EXPERT, PRO, and ACE. (BTW the normal X68030 has MC68EC030 so users also have to replace its CPU to with MC68030 to use NetBSD/x68k) - On the other hand, probably early x68k developers considered that some stupid users could try to boot NetBSD/x68k on X68000 without 030 and bootloaders should have some sanity checks. I'm pretty sure NetBSD could never run on a 68000 since the 68000 had no memory management unit. The 68010 and 68020 didn't have memory management units either, but Sun did proprietary MMUs for both (that's sun2 and sun3, respectively) and I think other companies may have done MMUs for the 68020. The 68030 was the first CPU in the series to come with an MMU built in. That generic x68x requires a 68030 makes sense since that's the first CPU where the code can count on knowing how the MMU works. A 68020 would have a manufacturer-specific MMU, while for the 68010 there is only sun2. There is no reason to restrict the instruction set to that of the 68000 in any case since NetBSD won't run on that. I once had a 68000 board that ran a 4.3 BSD kernel, but it was a 4.3 BSD kernel with all the process scheduling hacked out so that it ran exactly 1 compiled-in user space process, without memory protection. I used it as an ntp server. Dennis Ferguson
Re: CVS commit: src/sys/dev/scsipi
Hi Erik ! I agree that 5 minutes is a really long time. Actually the inventory command will wait even longer (5 min per element + 10 minutes as safeguard - I didn't change that). Generating a uprintf would mean to manage a separate callout and using, I believe, the tprintf() call from the callout function. I am not sure whether that is worth the trouble. What timeout should we take for the uprintf ? People with a slow device with a waiting indicator every 10 seconds will not gain any additional information other that they happen to have a slow device. Mostly changers are used in automated environments. I am not looking at night at the operations of our changers, but I am really annoyed when work is being aborted because of the scsi timeout being too short. tl;dr I'd prefer not to add 'interactive experience' support to the kernel, Maybe someone can wip up some tools(commands) for interactive usage. Maybe a warning about possible long operation times in the chio man page could help. Frank On 08/10/13 00:06, Erik Fair wrote: On Aug 9, 2013, at 12:58 , Frank Kardel kar...@netbsd.org wrote: Module Name:src Committed By: kardel Date: Fri Aug 9 19:58:44 UTC 2013 Modified Files: src/sys/dev/scsipi: ch.c Log Message: bump command timeout to 5 minutes. several types of changers (Overland PowerLoader, Dell PowerVault) have been exceeding the 100 sec limit aborting a perfectly (slowly) progressing operation. I think the kernel should uprintf(9) a notice to the effect that it has exceeded some (sooner than the 5 minute timeout) threshold and that it's really waiting for the device. Five minutes is a very long time for a timeout involving nominally local I/O devices. Without some progress indicator, users are likely to begin beating the system up (power cycle, etc) absent some persuasion to be patient. Erik f...@netbsd.org
Re: CVS commit: src/sys/dev/scsipi
Erik, I agree with this very much. Actually I have been toying around with this idea quite some time. My thoughts where to build a sysctl tree for all scsi commands with their default values and another level of sysctl timeout nodes where the vendor and device name or driver name is part of the hierarchy to override timeouts for some commands. Solaris has, I believe some of those knobs. So far I didn't manage to invest the time for a complete implementation. But maybe, as we currently are only suffering with changers, it would be sufficient to add a single timeout knob for the changers. Like dev.ch0.scsi_timeout=300 (s) How about that? Frank On 08/10/13 00:14, Erik Fair wrote: On Aug 9, 2013, at 12:58 , Frank Kardel kar...@netbsd.org wrote: Module Name:src Committed By: kardel Date: Fri Aug 9 19:58:44 UTC 2013 Modified Files: src/sys/dev/scsipi: ch.c Log Message: bump command timeout to 5 minutes. several types of changers (Overland PowerLoader, Dell PowerVault) have been exceeding the 100 sec limit aborting a perfectly (slowly) progressing operation. Upon further reflection, I believe that this timeout value should be a device-specific tunable parameter because there is such wide variation in changer behavior/performance; perhaps by kernel config, or by sysctl(8) on a per-device-node basis. Or some other mechanism you prefer. I believe that baking it into the kernel as a constant is not good design because we'll just see another commit just like this one at some later date, continuing to patch around the design problem. Erik f...@netbsd.org
Re: CVS commit: src/lib/libperfuse
Hi Christos, I think that didn't quite work the tree from this morning gives me this: lcc1: warnings being treated as errors /fs/raid1a/src/NetBSD/cur/src/lib/libperfuse/ops.c: In function 'perfuse_node_read': /fs/raid1a/src/NetBSD/cur/src/lib/libperfuse/ops.c:2838:22: error: comparison between signed and unsigned integer expressions /fs/raid1a/src/NetBSD/cur/src/lib/libperfuse/ops.c: In function 'perfuse_node_write': /fs/raid1a/src/NetBSD/cur/src/lib/libperfuse/ops.c:2945:22: error: comparison between signed and unsigned integer expressions Frank On 09/10/11 00:51, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Fri Sep 9 22:51:44 UTC 2011 Modified Files: src/lib/libperfuse: ops.c perfuse.c Log Message: make this build on amd64 and remove redundant and unused code. To generate a diff of this commit: cvs rdiff -u -r1.40 -r1.41 src/lib/libperfuse/ops.c cvs rdiff -u -r1.19 -r1.20 src/lib/libperfuse/perfuse.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/usr.bin/xlint/lint1
Are we missing a commit ? /bin/sh: Can't open /fs/raid1a/src/NetBSD/tc-merge/src/usr.bin/xlint/lint1/mkops *** Failed target: ops.h *** Failed command: AWK=/usr/btools/bin/nbawk /bin/sh /fs/raid1a/src/NetBSD/tc-merge/src/usr.bin/xlint/lint1/mkops -h /fs/raid1a/src/NetBSD/tc-merge/src/tools/lint1/../../usr.bin/xlint/lint1/ops.def ops.h *** Error code 2 Frank On 02/05/11 04:09, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Sat Feb 5 03:09:46 UTC 2011 Modified Files: src/usr.bin/xlint/lint1: Makefile.ops-c Makefile.ops-h Log Message: fix tools build. Why doesn't .PARSEDIR work? To generate a diff of this commit: cvs rdiff -u -r1.1 -r1.2 src/usr.bin/xlint/lint1/Makefile.ops-c \ src/usr.bin/xlint/lint1/Makefile.ops-h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src
Hello, is there a chance that the subdirectory needs yet to be committed? building release: [...] cleandir === sys/modules/tprof_pmi cleandir === sys/modules/tprof_amdpmi cd: can't cd to /fs/raid1a/src/NetBSD/tc-merge/src/sys/modules/tprof_amdpmi *** Failed target: cleandir-tprof_amdpmi and while in sys/modules: % cvs update tprof_amdpmi cvs update: nothing known about tprof_amdpmi % Regards, Frank On 02/05/11 15:08, YAMAMOTO Takashi wrote: Module Name:src Committed By: yamt Date: Sat Feb 5 14:08:13 UTC 2011 Modified Files: src/distrib/sets/lists/modules: md.amd64 md.i386 src/sys/modules: Makefile Log Message: build tprof_amdpmi To generate a diff of this commit: cvs rdiff -u -r1.12 -r1.13 src/distrib/sets/lists/modules/md.amd64 cvs rdiff -u -r1.13 -r1.14 src/distrib/sets/lists/modules/md.i386 cvs rdiff -u -r1.59 -r1.60 src/sys/modules/Makefile Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/dev/usb
Just a note. Today I tried out a -current (44 - 20110123) kernel and infortunately my modem (used for fax service) failed to be detected. The port is being disabled. -current as of 200910 (20) is working. Any ideas or is it time to start the kernel breakage binary hunt ? Frank PCI information: 000:00:0: Intel product 0x29e0 (host bridge, revision 0x01) 000:01:0: Intel product 0x29e1 (PCI bridge, revision 0x01) 000:26:0: Intel 82801I USB UHCI Controller (USB serial bus, revision 0x02) 000:26:1: Intel 82801I USB UHCI Controller (USB serial bus, revision 0x02) 000:26:2: Intel 82801I USB UHCI Controller (USB serial bus, revision 0x02) 000:26:7: Intel 82801I USB EHCI Controller (USB serial bus, interface 0x20, revision 0x02) 000:27:0: Intel 82801I High Definition Audio Controller (multimedia subclass 0x03, revision 0x02) 000:28:0: Intel 82801I PCI Express Port #1 (PCI bridge, revision 0x02) 000:28:3: Intel 82801I PCI Express Port #4 (PCI bridge, revision 0x02) 000:28:4: Intel 82801I PCI Express Port #5 (PCI bridge, revision 0x02) 000:28:5: Intel 82801I PCI Express Port #6 (PCI bridge, revision 0x02) 000:29:0: Intel 82801I USB UHCI Controller (USB serial bus, revision 0x02) 000:29:1: Intel 82801I USB UHCI Controller (USB serial bus, revision 0x02) 000:29:2: Intel 82801I USB UHCI Controller (USB serial bus, revision 0x02) 000:29:7: Intel 82801I USB EHCI Controller (USB serial bus, interface 0x20, revision 0x02) 000:30:0: Intel 82801BA Hub-PCI Bridge (PCI bridge, interface 0x01, revision 0x92) 000:31:0: Intel 82801IR LPC Interface Bridge (ISA bridge, revision 0x02) 000:31:2: Intel 82801I AHCI SATA Controller w/ 6 ports (SATA mass storage, interface 0x01, revision 0x02) 000:31:3: Intel 82801I SMBus Controller (SMBus serial bus, revision 0x02) usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), vendor 0x8086(0x8086), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), vendor 0x8086(0x8086), rev 1.00 port 1 powered port 2 addr 2: low speed, power 100 mA, config 1, Basic Optical Mouse(0x0084), Microsoft(0x045e), rev 0.00 Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), vendor 0x8086(0x8086), rev 1.00 port 1 addr 2: full speed, power 400 mA, config 2, ELSA Modem Board(0x2267), Lucent Technologies, Inc.(0x05cc), rev 1.00 port 2 addr 3: full speed, self powered, config 1, product 0x1446(0x1446), vendor 0x0451(0x0451), rev 1.10 port 1 powered port 2 powered port 3 powered port 4 powered Controller /dev/usb3: addr 1: high speed, self powered, config 1, EHCI root hub(0x), vendor 0x8086(0x8086), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered Controller /dev/usb4: addr 1: full speed, self powered, config 1, UHCI root hub(0x), vendor 0x8086(0x8086), rev 1.00 port 1 powered port 2 powered Controller /dev/usb5: addr 1: full speed, self powered, config 1, UHCI root hub(0x), vendor 0x8086(0x8086), rev 1.00 port 1 powered port 2 powered Controller /dev/usb6: addr 1: full speed, self powered, config 1, UHCI root hub(0x), vendor 0x8086(0x8086), rev 1.00 port 1 powered port 2 powered Controller /dev/usb7: addr 1: high speed, self powered, config 1, EHCI root hub(0x), vendor 0x8086(0x8086), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered Jared D. McNeill wrote: Module Name:src Committed By: jmcneill Date: Tue Jan 18 15:05:03 UTC 2011 Modified Files: src/sys/dev/usb: ehci.c Log Message: fix port reset for non-ETTF case broken by previous commit To generate a diff of this commit: cvs rdiff -u -r1.172 -r1.173 src/sys/dev/usb/ehci.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/dev/usb
Yes ! But it is good to know that additional information. Is there some document that gives a complete spec of the AT commands or are these even standardized ? Frank Christos Zoulas wrote: In article db28db51-d02e-4e29-93e6-b8e1500df...@jorvang.dk, Soren S. Jorvang so...@jorvang.dk wrote: On 20 Jun 2010, at 00:41, Frank Kardel wrote: src/sys/dev/usb: u3g.c usbdevs usbdevs.h usbdevs_data.h Log Message: add Huawei E1750 Mobile Broadband HSPA USB Stick That annoying virtual CD is easily disabled: http://forum.electroniq.net/index.php?topic=86.0 And for the also common ZTE ones: http://wiki.archlinux.org/index.php/ZTE_MF626_/_MF636#Disable_CD_mode_on_the_device And you've created the chicken and the egg problem. If I plug the device in and it appears as a umass, how am I supposed to turn it into a modem so I can type AT commands to it, if the driver does not do it for me? christos
Re: CVS commit: src/dist/ntp
Hi Christoph ! With the exception that I thought of it now I'd like to point you to http://mail-index.netbsd.org/source-changes-d/2009/06/13/msg000528.html Additionally I need to issue pullups for NetBSD 5 and NetBSD 4 - importing it into a full new reachover structure doesn't help there. Frank Christoph Egger wrote: Frank Kardel wrote: Module Name:src Committed By: kardel Date: Tue Dec 8 20:45:46 UTC 2009 Update of /cvsroot/src/dist/ntp In directory ivanova.netbsd.org:/tmp/cvs-serv4230 Log Message: Import ntp 4.2.4p8 Is there anything that speak against importing it into external/license/ ? Christoph
panic? - Re: CVS commit: src
Hi Jason ! I now get a KASSERT() assertion failure during boot in subr_xcall.c:199: KASSERT(xc_tailp xc_headp); Hand copied call stack: subr_xcall pool_cache_invalidate pmap_grow_kernel uvm_map_prepare uvm_map uvm_km_alloc vga_post_init ... more into autoconfig/device/bus scanning Frank Jason R Thorpe wrote: Module Name:src Committed By: thorpej Date: Thu Oct 15 20:50:13 UTC 2009 Modified Files: src/share/man/man9: pool_cache.9 src/sys/kern: subr_pool.c src/sys/sys: pool.h Log Message: - pool_cache_invalidate(): broadcast a cross-call to drain the per-CPU caches before draining the global cache. - pool_cache_invalidate_local(): remove. To generate a diff of this commit: cvs rdiff -u -r1.12 -r1.13 src/share/man/man9/pool_cache.9 cvs rdiff -u -r1.175 -r1.176 src/sys/kern/subr_pool.c cvs rdiff -u -r1.66 -r1.67 src/sys/sys/pool.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/usr.sbin/sup/source
Hi Christos ! This seems to break build.sh release: cc1: warnings being treated as errors /usr/src/usr.sbin/sup/sup/../source/supcmain.c: In function 'init': /usr/src/usr.sbin/sup/sup/../source/supcmain.c:676: warning: assignment from incompatible pointer type /usr/src/usr.sbin/sup/sup/../source/supcmain.c:684: warning: passing argument 2 of 'Tsearch' from incompatible pointer type /usr/src/usr.sbin/sup/sup/../source/supcmain.c:698: warning: passing argument 2 of 'parsecoll' from incompatible pointer type Frank Christos Zoulas wrote: Module Name:src Committed By: christos Date: Fri Oct 16 12:41:37 UTC 2009 Modified Files: src/usr.sbin/sup/source: log.c nxtarg.c quit.c scm.c scmio.c skipto.c stree.c supcmain.c supcmeat.c supcmisc.c supextern.h supfilesrv.c supmsg.c supmsg.h Log Message: constification from Paul Ripke to make it compile on OS/X To generate a diff of this commit: cvs rdiff -u -r1.9 -r1.10 src/usr.sbin/sup/source/log.c cvs rdiff -u -r1.5 -r1.6 src/usr.sbin/sup/source/nxtarg.c \ src/usr.sbin/sup/source/quit.c src/usr.sbin/sup/source/skipto.c cvs rdiff -u -r1.26 -r1.27 src/usr.sbin/sup/source/scm.c cvs rdiff -u -r1.16 -r1.17 src/usr.sbin/sup/source/scmio.c cvs rdiff -u -r1.12 -r1.13 src/usr.sbin/sup/source/stree.c cvs rdiff -u -r1.27 -r1.28 src/usr.sbin/sup/source/supcmain.c cvs rdiff -u -r1.34 -r1.35 src/usr.sbin/sup/source/supcmeat.c cvs rdiff -u -r1.19 -r1.20 src/usr.sbin/sup/source/supcmisc.c cvs rdiff -u -r1.20 -r1.21 src/usr.sbin/sup/source/supextern.h cvs rdiff -u -r1.41 -r1.42 src/usr.sbin/sup/source/supfilesrv.c cvs rdiff -u -r1.15 -r1.16 src/usr.sbin/sup/source/supmsg.c cvs rdiff -u -r1.6 -r1.7 src/usr.sbin/sup/source/supmsg.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/usr.bin/xlint/lint1
Hello Christos ! On 20091003 build release fails with: dependall === lib/libwrap compile libwrap/fix_options.ln /src/NetBSD/tc-merge/BUILD.i386/usr/include/netinet/ip.h(153): syntax error '__packed' [249] /src/NetBSD/tc-merge/BUILD.i386/usr/include/netinet/ip.h(154): syntax error '__packed' [249] /fs/raid1a/src/NetBSD/tc-merge/src/lib/libwrap/fix_options.c(137): warning: conversion to 'unsigned int' due to prototype, arg #2 [259] *** Failed target: fix_options.ln *** Failed command: CC=/usr/btools/bin/i486--netbsdelf-gcc /usr/btools/bin/i486--netbsdelf-lint -chapbxzFS -d /src/NetBSD/tc-merge/BUILD.i386/usr/include -DFACILITY=LOG_AUTHPRIV -DSEVERITY=LOG_INFO -DREAL_DAEMON_DIR=\/usr/libexec\ -DHOSTS_ACCESS -DDAEMON_UMASK=022 -DRFC931_TIMEOUT=10 -DALWAYS_HOSTNAME -DHOSTS_ALLOW=\/etc/hosts.allow\ -DHOSTS_DENY=\/etc/hosts.deny\ -DPROCESS_OPTIONS -DNETGROUP -DINET6 -D_FORTIFY_SOURCE=2 -i /src/NetBSD/tc-merge/src/lib/libwrap/fix_options.c *** Error code 1 Could it be that there may be an issue left :-) Frank Christos Zoulas wrote: Module Name:src Committed By: christos Date: Fri Oct 2 21:49:30 UTC 2009 Modified Files: src/usr.bin/xlint/lint1: decl.c Log Message: handle bit fields in packed structures. To generate a diff of this commit: cvs rdiff -u -r1.50 -r1.51 src/usr.bin/xlint/lint1/decl.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys
Hello Christoph ! Thanks for the tip. I was just being consistent with what was there. I looked around what would be affected if I changed to the uint* regime (get_timecount returns a u_int and that is implemented in quite a few MD-files). That is a minor rototill but it would just clean up the timecounter area. Many of the files where timecounter parts are implemented also contain the u_int* strategy for other data. So maybe a global sweep of u_int* to uint would be in order if that is were we want to go. I currently see little value in changing that per subsystem. Or do we follow the strategy that new stuff uses uint* ? In that case the change would be minor. Best regards, Frank Christoph Egger wrote: Frank Kardel wrote: Module Name:src Committed By: kardel Date: Sun Jun 14 13:16:32 UTC 2009 Modified Files: src/sys/kern: kern_tc.c src/sys/sys: timepps.h Log Message: Make PPS work with fast time counters ( 2GHz) by making the pps count time stamp and the update time stamp u_int64. The time delta between two PPS events can now be correctly calculated avoiding any unaccounted for wraps with 32-bit counters. Please use uint64_t instead of u_int64_t. Christoph
Re: CVS commit: src/dist/ntp
Hi Adam, there where several reasons/motivations: - I didn't think of moving ntp to the external dir at this time - what license name should we agree on (doc/3RDPARTY lists 'BSD-like') - is this now UDEL/MILLS or can we settle for 'bsd' ? - I am no sure how to sensibly move there - we have some local adjustments that need to be preserved - It would take me longer than I can currently afford the time. A good place the start using external/ would be when 4.2.6 comes out (real soon now :-)). That version has massive changes anyway (and also adds new components if they are deemed useful) and some config rules in the PPS area also change. So that would be the time to make the switch and worth the effort. Frank Adam Hamsik wrote: On Jun,Saturday 13 2009, at 11:18 AM, Frank Kardel wrote: Module Name:src Committed By:kardel Date:Sat Jun 13 09:18:53 UTC 2009 Update of /cvsroot/src/dist/ntp In directory ivanova.netbsd.org:/tmp/cvs-serv27381 Log Message: Import ntp 4.2.4p7 Why you haven't imported new ntp to external dir ? Regards Adam.
Re: CVS commit: src/sys
Hi ! As I already observed in another reply to a doc change referring to these changes. I have narrowed down the time frame where fdesc handling broke (at least for cups and its filter pipes). A kernel before 2009-05-23 22:00:00 works - a kernel after 2009-05-24 22:00:00 kills cups filter pipes with the foomatic perl script tripping over an EBADF in STDIN. Also cups CGI communication breaks. It seems to be that this change may have some corner cases worth to be examined. Frank -Andrew Doran wrote: Module Name:src Committed By: ad Date: Sun May 24 21:41:26 UTC 2009 Modified Files: src/sys/compat/netbsd32: netbsd32_ioctl.c src/sys/compat/svr4: svr4_filio.c src/sys/compat/svr4_32: svr4_32_filio.c src/sys/ddb: db_xxx.c src/sys/kern: init_sysctl.c kern_descrip.c kern_event.c kern_sig.c subr_exec_fd.c sys_aio.c sys_descrip.c sys_generic.c sys_select.c uipc_usrreq.c src/sys/miscfs/fdesc: fdesc_vfsops.c fdesc_vnops.c src/sys/miscfs/portal: portal_vnops.c src/sys/miscfs/procfs: procfs_vnops.c src/sys/sys: filedesc.h Log Message: More changes to improve kern_descrip.c. - Avoid atomics in more places. - Remove the per-descriptor mutex, and just use filedesc_t::fd_lock. It was only being used to synchronize close, and in any case we needed to take fd_lock to free the descriptor slot. - Optimize certain paths for the NDFDFILE case. - Sprinkle more comments and assertions. - Cache more stuff in filedesc_t. - Fix numerous minor bugs spotted along the way. - Restructure how the open files array is maintained, for clarity and so that we can eliminate the membar_consumer() call in fd_getfile(). This is mostly syntactic sugar; the main functional change is that fd_nfiles now lives alongside the open file array. Some measurements with libmicro: - simple file syscalls are like close() are between 1 to 10% faster. - some nice improvements, e.g. poll(1000) which is ~50% faster. To generate a diff of this commit: cvs rdiff -u -r1.41 -r1.42 src/sys/compat/netbsd32/netbsd32_ioctl.c cvs rdiff -u -r1.22 -r1.23 src/sys/compat/svr4/svr4_filio.c cvs rdiff -u -r1.16 -r1.17 src/sys/compat/svr4_32/svr4_32_filio.c cvs rdiff -u -r1.60 -r1.61 src/sys/ddb/db_xxx.c cvs rdiff -u -r1.163 -r1.164 src/sys/kern/init_sysctl.c cvs rdiff -u -r1.191 -r1.192 src/sys/kern/kern_descrip.c cvs rdiff -u -r1.64 -r1.65 src/sys/kern/kern_event.c cvs rdiff -u -r1.297 -r1.298 src/sys/kern/kern_sig.c cvs rdiff -u -r1.1 -r1.2 src/sys/kern/subr_exec_fd.c cvs rdiff -u -r1.23 -r1.24 src/sys/kern/sys_aio.c cvs rdiff -u -r1.12 -r1.13 src/sys/kern/sys_descrip.c cvs rdiff -u -r1.122 -r1.123 src/sys/kern/sys_generic.c cvs rdiff -u -r1.14 -r1.15 src/sys/kern/sys_select.c cvs rdiff -u -r1.125 -r1.126 src/sys/kern/uipc_usrreq.c cvs rdiff -u -r1.79 -r1.80 src/sys/miscfs/fdesc/fdesc_vfsops.c cvs rdiff -u -r1.106 -r1.107 src/sys/miscfs/fdesc/fdesc_vnops.c cvs rdiff -u -r1.82 -r1.83 src/sys/miscfs/portal/portal_vnops.c cvs rdiff -u -r1.173 -r1.174 src/sys/miscfs/procfs/procfs_vnops.c cvs rdiff -u -r1.54 -r1.55 src/sys/sys/filedesc.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/doc
Hi ! I tried a kernel from today (20090530). Strangely cups/foomatic fails with EBADF when attempting to read from STDIN in the foomatic perl script. A kernel from 20090516 works. Userland is from 20090516. Have there been library changes or is a bug hiding the in descriptor changes ? The system is a Q9450 MP system. Frank Andrew Doran wrote: Module Name:src Committed By: ad Date: Sun May 24 21:42:39 UTC 2009 Modified Files: src/doc: CHANGES Log Message: Note fd changes. To generate a diff of this commit: cvs rdiff -u -r1.1234 -r1.1235 src/doc/CHANGES Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
