Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On 2/12/14, Donovan Watteau wrote:
> On Thu, 6 Feb 2014, Donovan Watteau wrote:
>> David Coppa wrote:
>> > Take the following reduced test-case, adapted from what R's code
>> > does:
>> >
>> > ---8<---
>> >
>> > #include
>> > #include
>> > #include
>> >
>> > int main(void) {
>> >double theta = 1;
>> >long double lambda, pr, pr2;
>> >
>> >lambda = (0.5*theta);
>> >pr = exp(-lambda);
>> >pr2 = expl(-lambda);
>> >
>> >printf("theta == %g, pr == %Lg, pr2 == %Lg\n", theta, pr, pr2);
>> >exit(0);
>> > }
>> >
>> > ---8<---
>> >
>> > This produces the following output on Linux (x86_64):
>> >
>> > theta == 1, pr == 0.606531, pr2 == 0.606531
>> >
>> > While on OpenBSD -current amd64:
>> >
>> > theta == 1, pr == 0.606531, pr2 == nan
>>
>> FWIW, it looks even stranger on loongson:
>>
>> $ cc -o expl expl.c -O2 -pipe -lm
>> $ ./expl
>> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
>> $ ./expl
>> theta == 1, pr == 0.606531, pr2 == 0.606531
>> $ ./expl
>> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
>>
>> $ sysctl kern.version
>> kern.version=OpenBSD 5.5-beta (GENERIC) #106: Mon Feb 3 01:47:15 MST
>> 2014
>> t...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC
>
> A fix has been committed, but there's still a problem on loongson with
> libm updated:
>
> $ ls -l /usr/lib/libm.so.*
> -r--r--r-- 1 root bin 926033 Feb 12 12:17 /usr/lib/libm.so.9.0
> $ cc -o expl expl.c -O2 -pipe -lm
> $ for in in 1 2 3 4 5 6 ; do ./expl ; done
> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
> theta == 1, pr == 0.606531, pr2 == 0.606531
> theta == 1, pr == 0.606531, pr2 == 0.606531
> theta == 1, pr == 0.606531, pr2 == 0.606531
> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
> theta == 1, pr == 0.606531, pr2 == 0.606531
This isn't related to exp/expl. Looks like a bug in either compiler
or libc/printf/gdtoa. I don't have the hardware so I couldn't tell
much more.
As usual, there are a few ways to fix it:
1. Debug it and provide a diff,
2. Donate hardware. Oh, BTW I have a request for loongson in
http://www.openbsd.org/want.html sitting for over a year...
Re: release(8) patch
Hi,
first of all thanks for your feedback.
On Wed, Feb 12, 2014 at 12:27:18AM +, Stuart Henderson wrote:
> It isn't a big help for copy-and-paste though because the next section
> goes on to use ${NAME}, and then a bit later on there's your-destdir and
> your-releasedir...
On Wed, Feb 12, 2014 at 08:16:26AM +0100, Mark Kettenis wrote:
> Just make sure you set $ARCH in your .profile.
Yes and no. While ${NAME}, your-destdir and your-releasedir are not easily
discoverable by a tool - as those are also based on personal preference
- ${ARCH} is. This is also why I wouldn't like to waste a variable for
it. Not because I am running low on memory and / or variables but it
somehow doesn't feel correct to drag it along for something that I need
only every once in a while. YMMV.
But I also understand that it is more a bikeshed issue, so I won't
stress it any further.
Frank.
PS: I am subscribed to the list so no need to Cc: me, thanks.
Re: Trivial patch for ipv6
On Wed, Feb 12, 2014 at 10:10:36AM -0800, Loganaden Velvindron wrote:
> Hi All,
>
> based on a similar change from FreeBSD:
>
> Change the return error from EACCES to EPERM as it is not a file.
According to errno(2) EACCES is for file access permissions, so
EPERM seems more apporiate.
A grep for EACCES and EPERM in netinet and netinet6 shows that both
are used often. Do we want to move towards EPERM for networking?
I think ip6_mrouter_set() and ip6_mrouter_get() should stay in sync,
so please make the diff for both functions.
bluhm
>
> Index: src/sys/netinet6/ip6_mroute.c
> ===
> RCS file: /cvs/src/sys/netinet6/ip6_mroute.c,v
> retrieving revision 1.67
> diff -u -p -u -p -r1.67 ip6_mroute.c
> --- src/sys/netinet6/ip6_mroute.c 11 Nov 2013 09:15:35 - 1.67
> +++ src/sys/netinet6/ip6_mroute.c 12 Feb 2014 18:04:44 -
> @@ -247,7 +247,7 @@ int
> ip6_mrouter_set(int cmd, struct socket *so, struct mbuf *m)
> {
> if (cmd != MRT6_INIT && so != ip6_mrouter)
> - return (EACCES);
> + return (EPERM);
>
> switch (cmd) {
> case MRT6_INIT:
[Patch] ospfd: allow router lsa with 0 links
Hi Claudio,
could you please have a look to the following patch.
It removes a check that tries to make sure, a router lsa has at
least one link.
I have seen a problem with the check in the following situation:
On a router with only one ospf speaking interface, the link on this
interface goes down. The ospfd notice that, but doesn't generate
a router lsa for itself, because nlinks is zero. So the router doesn't
realize that it can not reach learned ospf routes anymore. The routes
get not deleted from the kernel routing table.
Sometimes I have also seen multiple times the same ospf routes inside
the kernel routing table, after the interface went up again. But this
is not reproducable all the time.
Do you see any situations were a router lsa with nlinks 0 could cause
trouble?
Regards,
Florian
Index: ospfe.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
retrieving revision 1.87
diff -u -p -r1.87 ospfe.c
--- ospfe.c 13 Nov 2013 20:43:00 - 1.87
+++ ospfe.c 12 Feb 2014 18:22:43 -
@@ -1020,7 +1020,7 @@ orig_rtr_lsa(struct area *area)
memcpy(ibuf_seek(buf, LS_CKSUM_OFFSET, sizeof(chksum)),
&chksum, sizeof(chksum));
- if (self && num_links)
+ if (self)
imsg_compose_event(iev_rde, IMSG_LS_UPD, self->peerid, 0,
-1, buf->buf, ibuf_size(buf));
else
Index: rde_lsdb.c
===
RCS file: /cvs/src/usr.sbin/ospfd/rde_lsdb.c,v
retrieving revision 1.49
diff -u -p -r1.49 rde_lsdb.c
--- rde_lsdb.c 14 Aug 2013 20:16:09 - 1.49
+++ rde_lsdb.c 12 Feb 2014 18:22:43 -
@@ -306,10 +306,6 @@ lsa_router_check(struct lsa *lsa, u_int1
}
nlinks = ntohs(lsa->data.rtr.nlinks);
- if (nlinks == 0) {
- log_warnx("lsa_check: invalid LSA router packet");
- return (0);
- }
for (i = 0; i < nlinks; i++) {
rtr_link = (struct lsa_rtr_link *)(buf + off);
off += sizeof(struct lsa_rtr_link);
Trivial patch for ipv6
Hi All,
based on a similar change from FreeBSD:
Change the return error from EACCES to EPERM as it is not a file.
Index: src/sys/netinet6/ip6_mroute.c
===
RCS file: /cvs/src/sys/netinet6/ip6_mroute.c,v
retrieving revision 1.67
diff -u -p -u -p -r1.67 ip6_mroute.c
--- src/sys/netinet6/ip6_mroute.c 11 Nov 2013 09:15:35 - 1.67
+++ src/sys/netinet6/ip6_mroute.c 12 Feb 2014 18:04:44 -
@@ -247,7 +247,7 @@ int
ip6_mrouter_set(int cmd, struct socket *so, struct mbuf *m)
{
if (cmd != MRT6_INIT && so != ip6_mrouter)
- return (EACCES);
+ return (EPERM);
switch (cmd) {
case MRT6_INIT:
Re: fix ntpd.8 rfc authors
Hi Arto, Arto Jonsson wrote on Wed, Feb 12, 2014 at 04:39:39PM +0200: > University of Delaware mixup. Done, thanks. Ingo > Index: ntpd.8 > === > RCS file: /cvs/src/usr.sbin/ntpd/ntpd.8,v > retrieving revision 1.36 > diff -u -p -r1.36 ntpd.8 > --- ntpd.84 Oct 2013 14:28:16 - 1.36 > +++ ntpd.812 Feb 2014 14:37:13 - > @@ -153,7 +153,6 @@ Socket file for communication with > .Pp > .Rs > .%A D. Mills > -.%A U. Delaware > .%A J. Martin > .%A J. Burbank > .%A W. Kasch
fix ntpd.8 rfc authors
University of Delaware mixup. Index: ntpd.8 === RCS file: /cvs/src/usr.sbin/ntpd/ntpd.8,v retrieving revision 1.36 diff -u -p -r1.36 ntpd.8 --- ntpd.8 4 Oct 2013 14:28:16 - 1.36 +++ ntpd.8 12 Feb 2014 14:37:13 - @@ -153,7 +153,6 @@ Socket file for communication with .Pp .Rs .%A D. Mills -.%A U. Delaware .%A J. Martin .%A J. Burbank .%A W. Kasch
Re: em(4): Don't count RX overruns and missed packets as input errros
On 02/12/2014 05:44 AM, Mike Belopuhov wrote: On 11 February 2014 20:05, Brad Smith wrote: On Tue, Feb 11, 2014 at 07:43:51PM +0100, Mark Kettenis wrote: Date: Tue, 11 Feb 2014 13:30:47 -0500 From: Brad Smith Index: arch/socppc/dev/if_tsec.c === RCS file: /home/cvs/src/sys/arch/socppc/dev/if_tsec.c,v retrieving revision 1.29 diff -u -p -u -p -r1.29 if_tsec.c --- arch/socppc/dev/if_tsec.c 29 Nov 2012 21:10:31 - 1.29 +++ arch/socppc/dev/if_tsec.c 28 Jan 2014 05:16:24 - @@ -779,7 +779,6 @@ tsec_errintr(void *arg) */ tsec_rx_proc(sc); tsec_write(sc, TSEC_RSTAT, TSEC_RSTAT_QHLT); - ifp->if_ierrors++; } return (1); This one doesn't seem right. This is the only place where the driver actually increases if_ierrors. Being the only place input errors are incremented is irrelevant. Its being incremented because the particular "error" is a FIFO overrun. I also still fundamentally disagree with the direction. I you guys really want to make a distinction between packets dropped because we're out of descriptors and packets that were not correctly received for other reasons, add a counter for that first and then change the drivers. I don't necessarily disagree with what you have said. I think we should have some additional counters to deal with some of the counters we are lumping into error counters. Since we can't seem to come to any consensus about how to deal with this I'm going to revert the bge(4) commit in question. no way. counting drops caused by the mclgeti should not be accounted as input errors. it makes it hard to debug things. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Locating where and why packets are dropped is essential to debugging network overload problems. A per-interface "packets dropped because of lack of resources" would make that process easier. There used to be several places in packet reception where packets were dropped with no record. I inserted counters to get at least a global count. It's conceptually very ugly to silently fail in a vital part of the network stack. It's definitely a frustrating inconvenience. Geoff Steckel
Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On Thu, 6 Feb 2014, Donovan Watteau wrote:
> David Coppa wrote:
> > Take the following reduced test-case, adapted from what R's code
> > does:
> >
> > ---8<---
> >
> > #include
> > #include
> > #include
> >
> > int main(void) {
> > double theta = 1;
> > long double lambda, pr, pr2;
> >
> > lambda = (0.5*theta);
> > pr = exp(-lambda);
> > pr2 = expl(-lambda);
> >
> > printf("theta == %g, pr == %Lg, pr2 == %Lg\n", theta, pr, pr2);
> > exit(0);
> > }
> >
> > ---8<---
> >
> > This produces the following output on Linux (x86_64):
> >
> > theta == 1, pr == 0.606531, pr2 == 0.606531
> >
> > While on OpenBSD -current amd64:
> >
> > theta == 1, pr == 0.606531, pr2 == nan
>
> FWIW, it looks even stranger on loongson:
>
> $ cc -o expl expl.c -O2 -pipe -lm
> $ ./expl
> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
> $ ./expl
> theta == 1, pr == 0.606531, pr2 == 0.606531
> $ ./expl
> theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
>
> $ sysctl kern.version
> kern.version=OpenBSD 5.5-beta (GENERIC) #106: Mon Feb 3 01:47:15 MST 2014
> t...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC
A fix has been committed, but there's still a problem on loongson with
libm updated:
$ ls -l /usr/lib/libm.so.*
-r--r--r-- 1 root bin 926033 Feb 12 12:17 /usr/lib/libm.so.9.0
$ cc -o expl expl.c -O2 -pipe -lm
$ for in in 1 2 3 4 5 6 ; do ./expl ; done
theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
theta == 1, pr == 0.606531, pr2 == 0.606531
theta == 1, pr == 0.606531, pr2 == 0.606531
theta == 1, pr == 0.606531, pr2 == 0.606531
theta == 1, pr == -9.15569e-2474, pr2 == 6.10667e-4944
theta == 1, pr == 0.606531, pr2 == 0.606531
Re: em(4): Don't count RX overruns and missed packets as input errros
On 11 February 2014 20:05, Brad Smith wrote: > On Tue, Feb 11, 2014 at 07:43:51PM +0100, Mark Kettenis wrote: >> > Date: Tue, 11 Feb 2014 13:30:47 -0500 >> > From: Brad Smith >> > >> > > Index: arch/socppc/dev/if_tsec.c >> > > === >> > > RCS file: /home/cvs/src/sys/arch/socppc/dev/if_tsec.c,v >> > > retrieving revision 1.29 >> > > diff -u -p -u -p -r1.29 if_tsec.c >> > > --- arch/socppc/dev/if_tsec.c 29 Nov 2012 21:10:31 - 1.29 >> > > +++ arch/socppc/dev/if_tsec.c 28 Jan 2014 05:16:24 - >> > > @@ -779,7 +779,6 @@ tsec_errintr(void *arg) >> > >*/ >> > > tsec_rx_proc(sc); >> > > tsec_write(sc, TSEC_RSTAT, TSEC_RSTAT_QHLT); >> > > - ifp->if_ierrors++; >> > > } >> > > >> > > return (1); >> >> >> This one doesn't seem right. This is the only place where the driver >> actually increases if_ierrors. > > Being the only place input errors are incremented is irrelevant. > Its being incremented because the particular "error" is a FIFO overrun. > >> I also still fundamentally disagree with the direction. I you guys >> really want to make a distinction between packets dropped because >> we're out of descriptors and packets that were not correctly received >> for other reasons, add a counter for that first and then change the >> drivers. > > I don't necessarily disagree with what you have said. I think we should > have some additional counters to deal with some of the counters we > are lumping into error counters. > > Since we can't seem to come to any consensus about how to deal with > this I'm going to revert the bge(4) commit in question. > no way. counting drops caused by the mclgeti should not be accounted as input errors. it makes it hard to debug things. > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >
Re: carp sends incorrect NA
On 11/02/14(Tue) 19:40, Alexander Bluhm wrote: > On Tue, Feb 11, 2014 at 03:53:24PM +0100, Martin Pieuchot wrote: > > When a carp node sends a neighbor advertisement, because its status > > switch from BACKUP to MASTER for example, it does it using a wrong > > mac address: the one from its real associated interface (carpdev). > > > > Because of this, a hack was added later on to remove and re-add the > > route entry to loopback for the local IPv6 address, otherwise this > > entry would be updated on the BACKUP node with the MAC address of > > the physical interface on the MASTER node! > > > > So this diff fix this by using the carp interface to send the NA and > > also change it for the ARP request for consistency. > > There is the ip-stealth mode where the switch must not see the > virtual MAC address to make it flooding. An ARP or ND packet with > the CARP MAC as source address would break the feature. This diff doesn't change anything on this regard. It changes the target link-layer address send inside the NA to be the CARP MAC address and not the physical interface's one. Without it I get: icmp6: neighbor adv: tgt is ...(RO)(tgt lladdr: 00:00:14:ee:43:71) ^ MAC addr. of carpdev And with it: icmp6: neighbor adv: tgt is ...(RO)(tgt lladdr: 00:00:5e:00:01:03) ^ CARP MAC addr So ok? > > Index: netinet/ip_carp.c > > === > > RCS file: /home/ncvs/src/sys/netinet/ip_carp.c,v > > retrieving revision 1.221 > > diff -u -p -r1.221 ip_carp.c > > --- netinet/ip_carp.c 7 Feb 2014 22:22:37 - 1.221 > > +++ netinet/ip_carp.c 11 Feb 2014 13:53:16 - > > @@ -509,17 +509,6 @@ carp_setroute(struct carp_softc *sc, int > > } > > break; > > } > > - > > -#ifdef INET6 > > - case AF_INET6: > > - if (sc->sc_balancing >= CARP_BAL_IP) > > - continue; > > - if (cmd == RTM_ADD) > > - in6_ifaddloop(ifa); > > - else > > - in6_ifremloop(ifa); > > - break; > > -#endif /* INET6 */ > > default: > > break; > > } > > @@ -1330,7 +1319,7 @@ carp_send_arp(struct carp_softc *sc) > > continue; > > > > in = ifatoia(ifa)->ia_addr.sin_addr.s_addr; > > - arprequest(sc->sc_carpdev, &in, &in, sc->sc_ac.ac_enaddr); > > + arprequest(&sc->sc_if, &in, &in, sc->sc_ac.ac_enaddr); > > DELAY(1000);/* XXX */ > > } > > splx(s); > > @@ -1351,7 +1340,7 @@ carp_send_na(struct carp_softc *sc) > > continue; > > > > in6 = &ifatoia6(ifa)->ia_addr.sin6_addr; > > - nd6_na_output(sc->sc_carpdev, &mcast, in6, > > + nd6_na_output(&sc->sc_if, &mcast, in6, > > ND_NA_FLAG_OVERRIDE | > > (ip6_forwarding ? ND_NA_FLAG_ROUTER : 0), 1, NULL); > > DELAY(1000);/* XXX */
Re: release(8) patch
On Wed, Feb 12, 2014 at 08:47:29AM +, Stuart Henderson wrote: > On 2014/02/12 08:16, Mark Kettenis wrote: > > Just make sure you set $ARCH in your .profile. > > I used to do that, but it can cause some confusion when working > on the ports tree. yes, i ran with $ARCH set for a while, and this caused all kind of funky side effects when building stuff. Since then i've use $MYARCH... Landry
Re: release(8) patch
On 2014/02/12 08:16, Mark Kettenis wrote: > Just make sure you set $ARCH in your .profile. I used to do that, but it can cause some confusion when working on the ports tree.
Re: release(8) patch
On Wed, Feb 12, 2014 at 08:16:26AM +0100, Mark Kettenis wrote: > > Just make sure you set $ARCH in your .profile. If you feel like it, how about a patch for /etc/skel ? It's not set by default !
