Re: Debug / Driver / Kernel / WiFi
Hi
Any updates?
Deface писал 18.10.2018 00:02:
Hi all,
The patch in attachment works fine for me and fixes the
[ERROR: ATH0 UNABLE TO RESET HARDWARE] issue that I had on my
FUJITSU SIEMENS ESPRIMO Mobile U9210.
Patch is relative to -current.
Please check.
Many Thanks Stefan Sperling
for Code Review and strong support with Copyright!
Oleg Pahl
(Munich)
On 10/06/18 14:28, Stefan Sperling wrote:
On Sat, Oct 06, 2018 at 01:32:55PM +0200, NN wrote:
Hi all,
Many thanks for your support and reply!
I am not Profi (I have experience < 1year with OpenBSD and C
Programming.),
that why its will take me a lot of time to fix and try something.
After Mr. Sperling first review of my Code ... I have made few
fixes.
In attachment you can see my new patch. Please, try it and send me
your
feedback.
Its working for me. (*no more ERROR: ath0 unable to reset
hardware*)
Thank you! This is looking great. I see only two remaining problems:
Please don't use C++-style // comments. The lines commented this way
can just be removed.
More importantly it looks like these changes are based on work done
by Nick Kossifidis in Linux ath5k. I am quoting the relevant changes
from the Linux git log below. So I doubt this is your original work.
It is OK to copy this code into OpenBSD because it is licensed under
ISC, the same licence used by our ath(4) driver which this Linux
code
was based on. But only under the condition that we give attribution
to the original author. So please copy Nick's copyright line into
our
files as well. You can find it at the top of each file you've copied
code from.
And then we should be good to go.
commit cc6323c7d8c231d83e592ff9f7acf2cac5e016f7
Author: Nick Kossifidis
Date: Sun Jul 20 06:44:43 2008 +0300
ath5k: Update channel functions
* Add channel function for RF2425 (got this from decompiling binary
HAL, i have no idea why there is a 5GHz section but i'm looking
into it)
* Update RF5112 channel function (also got this from decompiling
binary HAL)
* Set JAPAN setting for channel 14 on all PHY chips
Changes-licensed-under: ISC
Signed-off-by: Nick Kossifidis
Signed-off-by: John W. Linville
diff --git a/drivers/net/wireless/ath5k/phy.c
b/drivers/net/wireless/ath5k/phy.c
index 66af70bd14e7..cbc362d20719 100644
--- a/drivers/net/wireless/ath5k/phy.c
+++ b/drivers/net/wireless/ath5k/phy.c
@@ -1898,9 +1898,6 @@ static int ath5k_hw_rf5112_channel(struct
ath5k_hw *ah,
data = data0 = data1 = data2 = 0;
c = channel->center_freq;
- /*
- * Set the channel on the RF5112 or newer
- */
if (c < 4800) {
if (!((c - 2224) % 5)) {
data0 = ((2 * (c - 704)) - 3040) / 10;
@@ -1912,7 +1909,7 @@ static int ath5k_hw_rf5112_channel(struct
ath5k_hw *ah,
return -EINVAL;
data0 = ath5k_hw_bitswap((data0 << 2) & 0xff, 8);
- } else {
+ } else if ((c - (c % 5)) != 2 || c > 5435) {
if (!(c % 20) && c >= 5120) {
data0 = ath5k_hw_bitswap(((c - 4800) / 20 << 2), 8);
data2 = ath5k_hw_bitswap(3, 2);
@@ -1924,6 +1921,9 @@ static int ath5k_hw_rf5112_channel(struct
ath5k_hw *ah,
data2 = ath5k_hw_bitswap(1, 2);
} else
return -EINVAL;
+ } else {
+ data0 = ath5k_hw_bitswap((10 * (c - 2) - 4800) / 25 + 1, 8);
+ data2 = ath5k_hw_bitswap(0, 2);
}
data = (data0 << 4) | (data1 << 1) | (data2 << 2) | 0x1001;
@@ -1934,6 +1934,45 @@ static int ath5k_hw_rf5112_channel(struct
ath5k_hw *ah,
return 0;
}
+/*
+ * Set the channel on the RF2425
+ */
+static int ath5k_hw_rf2425_channel(struct ath5k_hw *ah,
+ struct ieee80211_channel *channel)
+{
+ u32 data, data0, data2;
+ u16 c;
+
+ data = data0 = data2 = 0;
+ c = channel->center_freq;
+
+ if (c < 4800) {
+ data0 = ath5k_hw_bitswap((c - 2272), 8);
+ data2 = 0;
+ /* ? 5GHz ? */
+ } else if ((c - (c % 5)) != 2 || c > 5435) {
+ if (!(c % 20) && c < 5120)
+ data0 = ath5k_hw_bitswap(((c - 4800) / 20 << 2), 8);
+ else if (!(c % 10))
+ data0 = ath5k_hw_bitswap(((c - 4800) / 10 << 1), 8);
+ else if (!(c % 5))
+ data0 = ath5k_hw_bitswap((c - 4800) / 5, 8);
+ else
+ return -EINVAL;
+ data2 = ath5k_hw_bitswap(1, 2);
+ } else {
+ data0 = ath5k_hw_bitswap((10 * (c - 2) - 4800) / 25 + 1, 8);
+ data2 = ath5k_hw_bitswap(0, 2);
+ }
+
+ data = (data0 << 4) | data2 << 2 | 0x1001;
+
+ ath5k_hw_reg_write(ah, data & 0xff, AR5K_RF_BUFFER);
+ ath5k_hw_reg_write(ah, (data >> 8) & 0x7f,
AR5K_RF_BUFFER_CONTROL_5);
+
+ return 0;
+}
+
/*
* Set a channel on the radio chip
*/
@@ -1963,6 +2002,9 @@ int ath5k_hw_channel(struct ath5k_hw *ah,
struct ieee80211_channel *channel)
case AR5K_RF5111:
ret = ath5k_hw_rf5111_channel(ah, channel);
break;
+ case AR5K_RF2425:
+ ret = ath5k_hw_rf2425_channel(ah, channel);
+ break;
default:
ret = ath5k_hw_rf5112_channel(ah, channel);
break;
@@ -1971,6 +2013,15 @@ int ath5k_hw_channel(struct ath5k_hw *ah,
struct ieee80211_channel *channel)
if (ret)
return ret;
+ /* Set JAPAN setting for channel 14 */
+ if (channel->center_freq == 2484) {
commit 1889ba0a48688b639c2b2e9e1b0fd8f84e2c37d1
Author: Nick Kossifidis
Date: Thu Apr 30 15:55:46 2009 -0400
ath5k: Put remaining EEPROM data on ee
Remove VFSLCKDEBUG + ASSERT_VP_ISLOCKED (dead code in VFS)
Hi,
After reading VOP_LOOKUP.9 based on recent commit, a try to remove some dead
code in VFS.
https://marc.info/?l=openbsd-cvs&m=153886730207657&w=2
VFSLCKDEBUG is not defined anywhere. It is misleading to read in
sys/kern/vfs_vops.c that ASSERT_VP_ISLOCKED(dvp) is being checked, when in
fact, it is just dead code.
Please review and comment!
Thanks
diff --git sys/kern/vfs_subr.c sys/kern/vfs_subr.c
index b89037e499a..2d09c6446c8 100644
--- sys/kern/vfs_subr.c
+++ sys/kern/vfs_subr.c
@@ -1049,9 +1049,6 @@ vclean(struct vnode *vp, int flags, struct proc *p)
VN_KNOTE(vp, NOTE_REVOKE);
vp->v_tag = VT_NON;
vp->v_flag &= ~VXLOCK;
-#ifdef VFSLCKDEBUG
- vp->v_flag &= ~VLOCKSWORK;
-#endif
if (vp->v_flag & VXWANT) {
vp->v_flag &= ~VXWANT;
wakeup(vp);
@@ -1886,11 +1883,6 @@ vinvalbuf(struct vnode *vp, int flags, struct ucred
*cred, struct proc *p,
struct buf *nbp, *blist;
int s, error;
-#ifdef VFSLCKDEBUG
- if ((vp->v_flag & VLOCKSWORK) && !VOP_ISLOCKED(vp))
- panic("%s: vp isn't locked, vp %p", __func__, vp);
-#endif
-
if (flags & V_SAVE) {
s = splbio();
vwaitforio(vp, 0, "vinvalbuf", 0);
diff --git sys/kern/vfs_vops.c sys/kern/vfs_vops.c
index 32fcb4a24cc..c1996e1e4a8 100644
--- sys/kern/vfs_vops.c
+++ sys/kern/vfs_vops.c
@@ -47,19 +47,6 @@
#include
#include
-#ifdef VFSLCKDEBUG
-#include /* for panic() */
-
-#define ASSERT_VP_ISLOCKED(vp) do {\
- if (((vp)->v_flag & VLOCKSWORK) && !VOP_ISLOCKED(vp)) { \
- VOP_PRINT(vp); \
- panic("vp not locked"); \
- } \
-} while (0)
-#else
-#define ASSERT_VP_ISLOCKED(vp) /* nothing */
-#endif
-
int
VOP_ISLOCKED(struct vnode *vp)
{
@@ -102,8 +89,6 @@ VOP_CREATE(struct vnode *dvp, struct vnode **vpp,
a.a_cnp = cnp;
a.a_vap = vap;
- ASSERT_VP_ISLOCKED(dvp);
-
if (dvp->v_op->vop_create == NULL)
return (EOPNOTSUPP);
@@ -124,8 +109,6 @@ VOP_MKNOD(struct vnode *dvp, struct vnode **vpp,
a.a_cnp = cnp;
a.a_vap = vap;
- ASSERT_VP_ISLOCKED(dvp);
-
if (dvp->v_op->vop_mknod == NULL)
return (EOPNOTSUPP);
@@ -164,8 +147,6 @@ VOP_CLOSE(struct vnode *vp, int fflag, struct ucred *cred,
struct proc *p)
a.a_cred = cred;
a.a_p = p;
- ASSERT_VP_ISLOCKED(vp);
-
if (vp->v_op->vop_close == NULL)
return (EOPNOTSUPP);
@@ -184,8 +165,6 @@ VOP_ACCESS(struct vnode *vp, int mode, struct ucred *cred,
struct proc *p)
a.a_cred = cred;
a.a_p = p;
- ASSERT_VP_ISLOCKED(vp);
-
if (vp->v_op->vop_access == NULL)
return (EOPNOTSUPP);
@@ -219,8 +198,6 @@ VOP_SETATTR(struct vnode *vp, struct vattr *vap, struct
ucred *cred,
a.a_cred = cred;
a.a_p = p;
- ASSERT_VP_ISLOCKED(vp);
-
if (vp->v_op->vop_setattr == NULL)
return (EOPNOTSUPP);
@@ -239,8 +216,6 @@ VOP_READ(struct vnode *vp, struct uio *uio, int ioflag,
struct ucred *cred)
a.a_ioflag = ioflag;
a.a_cred = cred;
- ASSERT_VP_ISLOCKED(vp);
-
if (vp->v_op->vop_read == NULL)
return (EOPNOTSUPP);
@@ -258,8 +233,6 @@ VOP_WRITE(struct vnode *vp, struct uio *uio, int ioflag,
a.a_ioflag = ioflag;
a.a_cred = cred;
- ASSERT_VP_ISLOCKED(vp);
-
if (vp->v_op->vop_write == NULL)
return (EOPNOTSUPP);
@@ -343,8 +316,6 @@ VOP_FSYNC(struct vnode *vp, struct ucred *cred, int waitfor,
a.a_waitfor = waitfor;
a.a_p = p;
- ASSERT_VP_ISLOCKED(vp);
-
if (vp->v_op->vop_fsync == NULL)
return (EOPNOTSUPP);
@@ -363,9 +334,6 @@ VOP_REMOVE(struct vnode *dvp, struct vnode *vp, struct
componentname *cnp)
a.a_vp = vp;
a.a_cnp = cnp;
- ASSERT_VP_ISLOCKED(dvp);
- ASSERT_VP_ISLOCKED(vp);
-
if (dvp->v_op->vop_remove == NULL)
return (EOPNOTSUPP);
@@ -384,8 +352,6 @@ VOP_LINK(struct vnode *dvp, struct vnode *vp, struct
componentname *cnp)
a.a_vp = vp;
a.a_cnp = cnp;
- ASSERT_VP_ISLOCKED(dvp);
-
if (dvp->v_op->vop_link == NULL)
return (EOPNOTSUPP);
@@ -411,8 +377,6 @@ VOP_RENAME(struct vnode *fdvp, struct vnode *fvp,
a.a_tvp = tvp;
a.a_tcnp = tcnp;
- ASSERT_VP_ISLOCKED(tdvp);
-
if (fdvp->v_op->vop_rename == NULL)
return (EOPNOTSUPP);
@@ -435,8 +399,6 @@ VOP_MKDIR(struct vnode *dvp, struct vnode **vpp,
a.a_cnp = cnp;
a.a_vap = vap;
- ASSERT_VP_ISLOCKED(dvp);
-
if (dvp->v_op->vop_mkdir == NULL)
return (EOPNOTSUPP);
@@ -455,9 +417,6 @@ VOP_RMDIR(struct vnode *dvp,
Re: cron.c patch
On Sat, Oct 20, 2018 at 2:41 PM Edgar Pettijohn III wrote: > On 10/20/18 6:40 PM, Philip Guenther wrote: > > On Sat, Oct 20, 2018 at 2:34 PM Edgar Pettijohn III < > ed...@pettijohn-web.com> wrote: > >> I'm guessing the if block will never hit since listen returns either 0 or >> -1. >> > > Uh, but -1 is true. > > my bad. -1 just feels so untrue. > On two's-complement systems (i.e., all modern CPUs), -1 is all bits set making it the *truest* value! :-)
Re: cron.c patch
On 10/20/18 6:40 PM, Philip Guenther wrote: On Sat, Oct 20, 2018 at 2:34 PM Edgar Pettijohn III mailto:ed...@pettijohn-web.com>> wrote: I'm guessing the if block will never hit since listen returns either 0 or -1. Uh, but -1 is true. Philip my bad. -1 just feels so untrue.
Re: cron.c patch
On Sat, Oct 20, 2018 at 2:34 PM Edgar Pettijohn III wrote: > I'm guessing the if block will never hit since listen returns either 0 or > -1. > Uh, but -1 is true. Philip
cron.c patch
I'm guessing the if block will never hit since listen returns either 0
or -1.
Index: cron.c
===
RCS file: /cvs/src/usr.sbin/cron/cron.c,v
retrieving revision 1.77
diff -u -p -u -r1.77 cron.c
--- cron.c 23 Oct 2017 15:15:22 - 1.77
+++ cron.c 20 Oct 2018 23:27:46 -
@@ -462,7 +462,7 @@ open_socket(void)
syslog(LOG_ERR, "(CRON) DEATH (can't bind socket)");
exit(EXIT_FAILURE);
}
- if (listen(sock, SOMAXCONN)) {
+ if (listen(sock, SOMAXCONN) != 0) {
warn("listen");
syslog(LOG_ERR, "(CRON) DEATH (can't listen on socket)");
exit(EXIT_FAILURE);
*
*
Re: bypass support for iommu on sparc64
This is OpenBSD tech@ On Sat, Oct 20, 2018 at 08:36:33PM +0100, Andrew Grillet wrote: > So, substitute opening and closing the connection to the network? > > Is the IOMMU not used for disk (and all SCSI) access also? > > > > On Sat, 20 Oct 2018 at 20:32, Theo de Raadt wrote: > > > Andrew Grillet wrote: > > > > > Ok, what I am proposing is that the IOMMU is set up when a file is opened > > > to provide the address space required for that file's IO. > > > > Wow, you keep saying file as if it means something. > > > > packets off the network are not associated with any specific "file" > > activity > > > > it isn't how the kernel works. > > > > You are ... way off target. > > >
Re: bypass support for iommu on sparc64
So, substitute opening and closing the connection to the network? Is the IOMMU not used for disk (and all SCSI) access also? On Sat, 20 Oct 2018 at 20:32, Theo de Raadt wrote: > Andrew Grillet wrote: > > > Ok, what I am proposing is that the IOMMU is set up when a file is opened > > to provide the address space required for that file's IO. > > Wow, you keep saying file as if it means something. > > packets off the network are not associated with any specific "file" > activity > > it isn't how the kernel works. > > You are ... way off target. >
Re: bypass support for iommu on sparc64
Andrew Grillet wrote: > Ok, what I am proposing is that the IOMMU is set up when a file is opened > to provide the address space required for that file's IO. Wow, you keep saying file as if it means something. packets off the network are not associated with any specific "file" activity it isn't how the kernel works. You are ... way off target.
Re: bypass support for iommu on sparc64
Ok, what I am proposing is that the IOMMU is set up when a file is opened to provide the address space required for that file's IO. This remains set up until the file is closed, avoiding frequent set-up and tear-down for each IO transfer. I assume that there is sufficient IOMMU address space to handle any plausible number of files open, and that it is possible to keep the knowledge of address spaces private to the Primary Ldom, and guests would only be aware of the mbufs visible to them, and this is acceptable. (If you cant trust the Primary, I rather suspect you are stuffed anyway). Clearly, dependent of IOMMU architecture, which I do not claim to understand, this could exhaust IO address space before it exhausts physical memory, I don't know. But I cannot see any other reason why this would not avoid frequent set-up and tear-downs. I get the impression that disk access is not great on my T machines. I expect a 1GHz T1000 to totally piss on a 4GHz Intel machine at web serving, and it doesn't. (Solaris annoys me too much to even try it, but I assume its better than OpenBSD on Spact64 at this time, or Larry Ellison would have to sell his yacht). On Sat, 20 Oct 2018 at 20:04, Theo de Raadt wrote: > In this case, what do mbufs have to do with files? > > I am very confused. > > > I was assuming that the main objection to allocating mbufs for duration > of > > file open, > > rather than allocating per transfer, this could result in a much higher > > number of mbufs > > being in use concurrently. I cannot see any other downside (which may be > > due to my > > not understanding a lot of stuff - I last wrote this level of stuff for > > Unix in the 1980's). > > > > On Sat, 20 Oct 2018 at 14:41, Theo de Raadt wrote: > > > > > Andrew Grillet wrote: > > > > > > > These days we are not so short of memory - would it not be possible > to > > > > allocate an mbuf (or two for double-buffered) for each file > > > > when opened, and free when closed? > > > > > > What does this have to do with files?? > > > >
Re: bypass support for iommu on sparc64
In this case, what do mbufs have to do with files? I am very confused. > I was assuming that the main objection to allocating mbufs for duration of > file open, > rather than allocating per transfer, this could result in a much higher > number of mbufs > being in use concurrently. I cannot see any other downside (which may be > due to my > not understanding a lot of stuff - I last wrote this level of stuff for > Unix in the 1980's). > > On Sat, 20 Oct 2018 at 14:41, Theo de Raadt wrote: > > > Andrew Grillet wrote: > > > > > These days we are not so short of memory - would it not be possible to > > > allocate an mbuf (or two for double-buffered) for each file > > > when opened, and free when closed? > > > > What does this have to do with files?? > >
Re: bypass support for iommu on sparc64
I was assuming that the main objection to allocating mbufs for duration of file open, rather than allocating per transfer, this could result in a much higher number of mbufs being in use concurrently. I cannot see any other downside (which may be due to my not understanding a lot of stuff - I last wrote this level of stuff for Unix in the 1980's). On Sat, 20 Oct 2018 at 14:41, Theo de Raadt wrote: > Andrew Grillet wrote: > > > These days we are not so short of memory - would it not be possible to > > allocate an mbuf (or two for double-buffered) for each file > > when opened, and free when closed? > > What does this have to do with files?? >
Re: vmd: servicing virtio devices from separate processes
* David Gwynne [2018-10-20 12:19:56 +1000]: Would sending and receiving a VM still work if I/O is run in different processes? dlg Hi dlg, It will have to be reworked completely but can be done, I think. -- Pratik
Re: relayd: sync host*() with ntpd
On Sat, Oct 20, 2018 at 05:30:59PM +0200, Klemens Nanni wrote:
> On Sat, Oct 20, 2018 at 11:57:13AM +0200, Denis Fondras wrote:
> > Sync changes to host_*() from ntpd to relayd.
> This looks good, however I'm not a relayd user.
> How did you test it? With both IPv4 and IPv6?
>
I tested both on my machine, that's not extensive test though (using listen and
forward in both IPv4 & IPv6 and checking if backend is reachable).
Also regress is IPv4 only.
> Some nits inline to squash inconsistencies with other `host_ip()' users
> in base.
>
Thank you, new diff below.
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
retrieving revision 1.228
diff -u -p -r1.228 parse.y
--- parse.y 7 Sep 2018 07:35:31 - 1.228
+++ parse.y 20 Oct 2018 16:07:19 -
@@ -123,8 +123,7 @@ static enum directiondir = RELAY_DIR_A
static char*rulefile = NULL;
static union hashkey *hashkey = NULL;
-struct address *host_v4(const char *);
-struct address *host_v6(const char *);
+struct address *host_ip(const char *);
int host_dns(const char *, struct addresslist *,
int, struct portrange *, const char *, int);
int host_if(const char *, struct addresslist *,
@@ -2929,49 +2928,22 @@ symget(const char *nam)
}
struct address *
-host_v4(const char *s)
+host_ip(const char *s)
{
- struct in_addr ina;
- struct sockaddr_in *sain;
- struct address *h;
-
- bzero(&ina, sizeof(ina));
- if (inet_pton(AF_INET, s, &ina) != 1)
- return (NULL);
-
- if ((h = calloc(1, sizeof(*h))) == NULL)
- fatal(__func__);
- sain = (struct sockaddr_in *)&h->ss;
- sain->sin_len = sizeof(struct sockaddr_in);
- sain->sin_family = AF_INET;
- sain->sin_addr.s_addr = ina.s_addr;
-
- return (h);
-}
-
-struct address *
-host_v6(const char *s)
-{
- struct addrinfo hints, *res;
- struct sockaddr_in6 *sa_in6;
- struct address *h = NULL;
+ struct addrinfo hints, *res;
+ struct address *h = NULL;
- bzero(&hints, sizeof(hints));
- hints.ai_family = AF_INET6;
- hints.ai_socktype = SOCK_DGRAM; /* dummy */
+ memset(&hints, 0, sizeof(hints));
+ hints.ai_family = AF_UNSPEC;
+ hints.ai_socktype = SOCK_DGRAM; /*dummy*/
hints.ai_flags = AI_NUMERICHOST;
if (getaddrinfo(s, "0", &hints, &res) == 0) {
- if ((h = calloc(1, sizeof(*h))) == NULL)
- fatal(__func__);
- sa_in6 = (struct sockaddr_in6 *)&h->ss;
- sa_in6->sin6_len = sizeof(struct sockaddr_in6);
- sa_in6->sin6_family = AF_INET6;
- memcpy(&sa_in6->sin6_addr,
- &((struct sockaddr_in6 *)res->ai_addr)->sin6_addr,
- sizeof(sa_in6->sin6_addr));
- sa_in6->sin6_scope_id =
- ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope_id;
-
+ if (res->ai_family == AF_INET ||
+ res->ai_family == AF_INET6) {
+ if ((h = calloc(1, sizeof(*h))) == NULL)
+ fatal(NULL);
+ memcpy(&h->ss, res->ai_addr, res->ai_addrlen);
+ }
freeaddrinfo(res);
}
@@ -2984,15 +2956,13 @@ host_dns(const char *s, struct addressli
{
struct addrinfo hints, *res0, *res;
int error, cnt = 0;
- struct sockaddr_in *sain;
- struct sockaddr_in6 *sin6;
struct address *h;
if ((cnt = host_if(s, al, max, port, ifname, ipproto)) != 0)
return (cnt);
bzero(&hints, sizeof(hints));
- hints.ai_family = PF_UNSPEC;
+ hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM; /* DUMMY */
hints.ai_flags = AI_ADDRCONFIG;
error = getaddrinfo(s, NULL, &hints, &res0);
@@ -3024,19 +2994,8 @@ host_dns(const char *s, struct addressli
}
if (ipproto != -1)
h->ipproto = ipproto;
- h->ss.ss_family = res->ai_family;
- if (res->ai_family == AF_INET) {
- sain = (struct sockaddr_in *)&h->ss;
- sain->sin_len = sizeof(struct sockaddr_in);
- sain->sin_addr.s_addr = ((struct sockaddr_in *)
- res->ai_addr)->sin_addr.s_addr;
- } else {
- sin6 = (struct sockaddr_in6 *)&h->ss;
- sin6->sin6_len = sizeof(struct sockaddr_in6);
- memcpy(&sin6->sin6_addr, &((struct sockaddr_in6 *)
- res->ai_addr)->sin6_addr, sizeof(struct in6_addr));
- }
+ mem
Re: relayd: sync host*() with ntpd
On Sat, Oct 20, 2018 at 11:57:13AM +0200, Denis Fondras wrote:
> Sync changes to host_*() from ntpd to relayd.
This looks good, however I'm not a relayd user.
How did you test it? With both IPv4 and IPv6?
Some nits inline to squash inconsistencies with other `host_ip()' users
in base.
> Index: parse.y
> ===
> RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
> retrieving revision 1.228
> diff -u -p -r1.228 parse.y
> --- parse.y 7 Sep 2018 07:35:31 - 1.228
> +++ parse.y 20 Oct 2018 09:56:28 -
> @@ -123,8 +123,7 @@ static enum direction dir = RELAY_DIR_A
> static char *rulefile = NULL;
> static union hashkey *hashkey = NULL;
>
> -struct address *host_v4(const char *);
> -struct address *host_v6(const char *);
> +struct address *host_ip(const char *);
> int host_dns(const char *, struct addresslist *,
> int, struct portrange *, const char *, int);
> int host_if(const char *, struct addresslist *,
> @@ -2929,49 +2928,21 @@ symget(const char *nam)
> }
>
> struct address *
> -host_v4(const char *s)
> +host_ip(const char *s)
> {
> - struct in_addr ina;
> - struct sockaddr_in *sain;
> - struct address *h;
> -
> - bzero(&ina, sizeof(ina));
> - if (inet_pton(AF_INET, s, &ina) != 1)
> - return (NULL);
> -
> - if ((h = calloc(1, sizeof(*h))) == NULL)
> - fatal(__func__);
> - sain = (struct sockaddr_in *)&h->ss;
> - sain->sin_len = sizeof(struct sockaddr_in);
> - sain->sin_family = AF_INET;
> - sain->sin_addr.s_addr = ina.s_addr;
> -
> - return (h);
> -}
> -
> -struct address *
> -host_v6(const char *s)
> -{
> - struct addrinfo hints, *res;
> - struct sockaddr_in6 *sa_in6;
> + struct addrinfo hints, *res;
Please aline `hints' with a space after the tab.
> struct address *h = NULL;
>
> - bzero(&hints, sizeof(hints));
> - hints.ai_family = AF_INET6;
> - hints.ai_socktype = SOCK_DGRAM; /* dummy */
> + memset(&hints, 0, sizeof(hints));
> + hints.ai_family = AF_UNSPEC;
> + hints.ai_socktype = SOCK_DGRAM; /*dummy*/
> hints.ai_flags = AI_NUMERICHOST;
> if (getaddrinfo(s, "0", &hints, &res) == 0) {
> - if ((h = calloc(1, sizeof(*h))) == NULL)
> - fatal(__func__);
> - sa_in6 = (struct sockaddr_in6 *)&h->ss;
> - sa_in6->sin6_len = sizeof(struct sockaddr_in6);
> - sa_in6->sin6_family = AF_INET6;
> - memcpy(&sa_in6->sin6_addr,
> - &((struct sockaddr_in6 *)res->ai_addr)->sin6_addr,
> - sizeof(sa_in6->sin6_addr));
> - sa_in6->sin6_scope_id =
> - ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope_id;
> -
> + if (res->ai_family == AF_INET || res->ai_family == AF_INET6) {
In ntpd and pfctl we break this into two lines, mind doing so here, too?
> + if ((h = calloc(1, sizeof(*h))) == NULL)
> + fatal(NULL);
> + memcpy(&h->ss, res->ai_addr, res->ai_addrlen);
> + }
> freeaddrinfo(res);
> }
>
> @@ -2984,15 +2955,13 @@ host_dns(const char *s, struct addressli
> {
> struct addrinfo hints, *res0, *res;
> int error, cnt = 0;
> - struct sockaddr_in *sain;
> - struct sockaddr_in6 *sin6;
> struct address *h;
>
> if ((cnt = host_if(s, al, max, port, ifname, ipproto)) != 0)
> return (cnt);
>
> bzero(&hints, sizeof(hints));
> - hints.ai_family = PF_UNSPEC;
> + hints.ai_family = AF_UNSPEC;
> hints.ai_socktype = SOCK_DGRAM; /* DUMMY */
> hints.ai_flags = AI_ADDRCONFIG;
> error = getaddrinfo(s, NULL, &hints, &res0);
> @@ -3024,19 +2993,8 @@ host_dns(const char *s, struct addressli
> }
> if (ipproto != -1)
> h->ipproto = ipproto;
> - h->ss.ss_family = res->ai_family;
>
> - if (res->ai_family == AF_INET) {
> - sain = (struct sockaddr_in *)&h->ss;
> - sain->sin_len = sizeof(struct sockaddr_in);
> - sain->sin_addr.s_addr = ((struct sockaddr_in *)
> - res->ai_addr)->sin_addr.s_addr;
> - } else {
> - sin6 = (struct sockaddr_in6 *)&h->ss;
> - sin6->sin6_len = sizeof(struct sockaddr_in6);
> - memcpy(&sin6->sin6_addr, &((struct sockaddr_in6 *)
> - res->ai_addr)->sin6_addr, sizeof(struct in6_addr));
> - }
> + memcpy(&h->ss, res->ai_addr, res->ai_addrlen);
>
> TAILQ_INSERT_HEAD(al, h, entry);
> cnt++;
> @@ -3125,11 +3083,7 @@ host(const char *s, struc
lld fix for ports gcc
The java stuff generates sections with names like .rodata.jutf8.10 and
.rodata.jutf.14 that have the entry size (sh_entsize) set to an
integerer that isn't a power of two. When merging these sections into
the final output, lld adjusts the alignment to be at least the entry
size. However, the alignment of a section should always be a power of
2, and this is checked later on. At that point lld throws us a fatal
error.
The diff below fixes this issue by sticking to the original alignment
if the entry size isn't a power of two. Presumably lld is trying to
optimize things here by making sure that entries are word or
cache-line aligned when possible. But such an optimization doesn't
make sense if the entry size isn't a power of 2
This makes the ports gcc build on amd64 systems with lld as the default linker.
ok?
Index: gnu/llvm/tools/lld/ELF/SyntheticSections.cpp
===
RCS file: /cvs/src/gnu/llvm/tools/lld/ELF/SyntheticSections.cpp,v
retrieving revision 1.8
diff -u -p -r1.8 SyntheticSections.cpp
--- gnu/llvm/tools/lld/ELF/SyntheticSections.cpp3 Jun 2018 12:34:03
- 1.8
+++ gnu/llvm/tools/lld/ELF/SyntheticSections.cpp20 Oct 2018 13:48:46
-
@@ -2512,7 +2512,9 @@ void elf::mergeSections() {
continue;
StringRef OutsecName = getOutputSectionName(MS);
-uint32_t Alignment = std::max(MS->Alignment, MS->Entsize);
+uint32_t Alignment = MS->Alignment;
+if (isPowerOf2_32(MS->Entsize))
+Alignment = std::max(Alignment, MS->Entsize);
auto I = llvm::find_if(MergeSections, [=](MergeSyntheticSection *Sec) {
// While we could create a single synthetic section for two different
Re: bypass support for iommu on sparc64
Andrew Grillet wrote: > These days we are not so short of memory - would it not be possible to > allocate an mbuf (or two for double-buffered) for each file > when opened, and free when closed? What does this have to do with files??
relayd: sync host*() with ntpd
Sync changes to host_*() from ntpd to relayd.
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
retrieving revision 1.228
diff -u -p -r1.228 parse.y
--- parse.y 7 Sep 2018 07:35:31 - 1.228
+++ parse.y 20 Oct 2018 09:56:28 -
@@ -123,8 +123,7 @@ static enum directiondir = RELAY_DIR_A
static char*rulefile = NULL;
static union hashkey *hashkey = NULL;
-struct address *host_v4(const char *);
-struct address *host_v6(const char *);
+struct address *host_ip(const char *);
int host_dns(const char *, struct addresslist *,
int, struct portrange *, const char *, int);
int host_if(const char *, struct addresslist *,
@@ -2929,49 +2928,21 @@ symget(const char *nam)
}
struct address *
-host_v4(const char *s)
+host_ip(const char *s)
{
- struct in_addr ina;
- struct sockaddr_in *sain;
- struct address *h;
-
- bzero(&ina, sizeof(ina));
- if (inet_pton(AF_INET, s, &ina) != 1)
- return (NULL);
-
- if ((h = calloc(1, sizeof(*h))) == NULL)
- fatal(__func__);
- sain = (struct sockaddr_in *)&h->ss;
- sain->sin_len = sizeof(struct sockaddr_in);
- sain->sin_family = AF_INET;
- sain->sin_addr.s_addr = ina.s_addr;
-
- return (h);
-}
-
-struct address *
-host_v6(const char *s)
-{
- struct addrinfo hints, *res;
- struct sockaddr_in6 *sa_in6;
+ struct addrinfo hints, *res;
struct address *h = NULL;
- bzero(&hints, sizeof(hints));
- hints.ai_family = AF_INET6;
- hints.ai_socktype = SOCK_DGRAM; /* dummy */
+ memset(&hints, 0, sizeof(hints));
+ hints.ai_family = AF_UNSPEC;
+ hints.ai_socktype = SOCK_DGRAM; /*dummy*/
hints.ai_flags = AI_NUMERICHOST;
if (getaddrinfo(s, "0", &hints, &res) == 0) {
- if ((h = calloc(1, sizeof(*h))) == NULL)
- fatal(__func__);
- sa_in6 = (struct sockaddr_in6 *)&h->ss;
- sa_in6->sin6_len = sizeof(struct sockaddr_in6);
- sa_in6->sin6_family = AF_INET6;
- memcpy(&sa_in6->sin6_addr,
- &((struct sockaddr_in6 *)res->ai_addr)->sin6_addr,
- sizeof(sa_in6->sin6_addr));
- sa_in6->sin6_scope_id =
- ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope_id;
-
+ if (res->ai_family == AF_INET || res->ai_family == AF_INET6) {
+ if ((h = calloc(1, sizeof(*h))) == NULL)
+ fatal(NULL);
+ memcpy(&h->ss, res->ai_addr, res->ai_addrlen);
+ }
freeaddrinfo(res);
}
@@ -2984,15 +2955,13 @@ host_dns(const char *s, struct addressli
{
struct addrinfo hints, *res0, *res;
int error, cnt = 0;
- struct sockaddr_in *sain;
- struct sockaddr_in6 *sin6;
struct address *h;
if ((cnt = host_if(s, al, max, port, ifname, ipproto)) != 0)
return (cnt);
bzero(&hints, sizeof(hints));
- hints.ai_family = PF_UNSPEC;
+ hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM; /* DUMMY */
hints.ai_flags = AI_ADDRCONFIG;
error = getaddrinfo(s, NULL, &hints, &res0);
@@ -3024,19 +2993,8 @@ host_dns(const char *s, struct addressli
}
if (ipproto != -1)
h->ipproto = ipproto;
- h->ss.ss_family = res->ai_family;
- if (res->ai_family == AF_INET) {
- sain = (struct sockaddr_in *)&h->ss;
- sain->sin_len = sizeof(struct sockaddr_in);
- sain->sin_addr.s_addr = ((struct sockaddr_in *)
- res->ai_addr)->sin_addr.s_addr;
- } else {
- sin6 = (struct sockaddr_in6 *)&h->ss;
- sin6->sin6_len = sizeof(struct sockaddr_in6);
- memcpy(&sin6->sin6_addr, &((struct sockaddr_in6 *)
- res->ai_addr)->sin6_addr, sizeof(struct in6_addr));
- }
+ memcpy(&h->ss, res->ai_addr, res->ai_addrlen);
TAILQ_INSERT_HEAD(al, h, entry);
cnt++;
@@ -3125,11 +3083,7 @@ host(const char *s, struct addresslist *
{
struct address *h;
- h = host_v4(s);
-
- /* IPv6 address? */
- if (h == NULL)
- h = host_v6(s);
+ h = host_ip(s);
if (h != NULL) {
if (port != NULL)
Re: bypass support for iommu on sparc64
These days we are not so short of memory - would it not be possible to allocate an mbuf (or two for double-buffered) for each file when opened, and free when closed? I can see the management might be more complex, but the performance benefits might be considerable. Also, for VM disk access (ldom on T) does this mean the process happens twice -once for disk-to-host and again for host-to-guest? In which case, allocating mbufs for the entire vdisk file to the host once at (VM) boot time (ldomctl start guest), and deallocating when it is shut down would save huge amounts of work. Unless the host is not involved in guest file access at all (don't know how you could safely do that). I can't see making all of memory visible to (even to kernel processes) in a guest is acceptable. Too much to go wrong. Andrew On Sat, 20 Oct 2018 at 01:59, David Gwynne wrote: > > > > On 19 Oct 2018, at 9:59 pm, Andrew Grillet wrote: > > > > Is the setup and teardown per transfer or when file is opened and closed? > > Or is it set up once per context switch of task? > > > > I am partly interested cos I would like to improve mt one day (as user of > > tape > > and Sparc64 Txxx) if I get the time. > > > > Andrew > > The overhead is per transfer. You might not get better performance out of > a tx000 because of the PCIe bridges involved, but you may also be lucky and > not have that bridge in the way. > > > > > > > > > On Fri, 19 Oct 2018 at 10:22, Mark Kettenis > wrote: > > > >>> Date: Fri, 19 Oct 2018 10:22:30 +1000 > >>> From: David Gwynne > >>> > >>> On Wed, May 10, 2017 at 10:09:59PM +1000, David Gwynne wrote: > On Mon, May 08, 2017 at 11:03:58AM +1000, David Gwynne wrote: > > on modern sparc64s (think fire or sparc enterprise Mx000 boxes), > > setting up and tearing down the translation table entries (TTEs) > > is very expensive. so expensive that the cost of doing it for disk > > io has a noticable impact on compile times. > > > > now that there's a BUS_DMA_64BIT flag, we can use that to decide > > to bypass the iommu for devices that set that flag, therefore > > avoiding the cost of handling the TTEs. > > > > the following diff adds support for bypass mappings to the iommu > > code on sparc64. it's based on a diff from kettenis@ back in 2009. > > the main changes are around coping with the differences between > > schizo/psycho and fire/oberon. > > > > the differences between the chips are now represented by a iommu_hw > > struct. these differences include how to enable the iommu (now via > > a function pointer), and masks for bypass addresses. > > > > ive tested this on oberon (on an m4000) and schizo (on a v880). > > however, the bypass code isnt working on fire (v245s). to cope with > > that for now, the iommu_hw struct lets drivers mask flag bits that > > are handled when creating a dmamap. this means fire boards will > > ignore BUS_DMA_64BIT until i can figure out whats wrong with them. > > i figured it out. it turns out Fire was working fine. however, > enabling 64bit dva on the onboard devices didnt work because the > serverworks/broadcom pcie to pcix bridge can only handle dma addresses > in the low 40 bits. because the fire bypass window is higher than > this, the bridge would choke and things stopped working. > > the updated diff attempts to handle this. basically when probing > the bridge, the platform creates a custom dma tag for it. this tag > intercets bus_dmamap_create and clears the BUS_DMA_64BIT flag before > handing it up to the parent bridge, which is pyro in my situation. > it looks like early sun4v boxes could make use of this too. > > > i have not tested this on psycho yet. if anyone has such a machine > > and is willing to work with me to figure it out, please talk to me. > > i still dont have psycho reports. > >>> > >>> Would anyone object if I committed this? I've been running it for the > >>> last release or two without issues, but with significant improvements > in > >>> performance on the machines involved. > >> > >> At the price of giving all PCI devices unrestricted access to memory. > >> > >> So I'm not eager to this, especially since on sun4v hardware bypassing > >> the iommu isn't possible as soon as multiple domains are enabled. And > >> we lose a useful diagnostic when developing drivers. Are you sure the > >> iommu overhead can't be reduced some other way? At some point we > >> probably want to add iommu support on amd64 and arm64, but if that > >> comes with a similar overhead as on sparc64 that's going to be a bit > >> of an issue. > >> > Index: dev/iommu.c > === > RCS file: /cvs/src/sys/arch/sparc64/dev/iommu.c,v > retrieving revision 1.74 > diff -u -p -r1.74 iommu.c > --- dev/iommu.c 30 Apr 2017 16:45:4
