Re: rtinit, RTF_HOST and netmask

2014-02-11 Thread Martin Pieuchot 
On 04/02/14(Tue) 10:50, Martin Pieuchot wrote:
 Diff below removes an old comment about bsdi4 and make it clear that
 netmasks are not needed for routes to host.
 
 ok?

Anybody?


 
 Index: net/route.c
 ===
 RCS file: /home/ncvs/src/sys/net/route.c,v
 retrieving revision 1.151
 diff -u -p -r1.151 route.c
 --- net/route.c   23 Jan 2014 10:16:30 -  1.151
 +++ net/route.c   4 Feb 2014 09:38:53 -
 @@ -1119,13 +1119,9 @@ rtinit(struct ifaddr *ifa, int cmd, int 
   info.rti_info[RTAX_LABEL] =
   rtlabel_id2sa(ifa-ifa_ifp-if_rtlabelid, sa_rl);
  
 - /*
 -  * XXX here, it seems that we are assuming that ifa_netmask is NULL
 -  * for RTF_HOST.  bsdi4 passes NULL explicitly (via intermediate
 -  * variable) when RTF_HOST is 1.  still not sure if i can safely
 -  * change it to meet bsdi4 behavior.
 -  */
 - info.rti_info[RTAX_NETMASK] = ifa-ifa_netmask;
 + if ((flags  RTF_HOST) == 0)
 + info.rti_info[RTAX_NETMASK] = ifa-ifa_netmask;
 +
   error = rtrequest1(cmd, info, RTP_CONNECTED, nrt, rtableid);
   if (cmd == RTM_DELETE) {
   if (error == 0  (rt = nrt) != NULL) {

Re: exp() / expl() on Linux and OpenBSD (expl() bug?)

2014-02-11 Thread Mark Kettenis 
 Date: Mon, 10 Feb 2014 22:35:02 -0700 (MST)
 From: Martynas Venckus marty...@cvs.openbsd.org
 
  Here's a diff that sticks a bit closer to the original code.  It's
  equivalent to your diff, and admittedly purely a matter of taste which
  version to prefer.
 
 I prefer my version better.  It's not '93 anymore and compilers are
 able to convert 0.0L and -1.0L precisely, otherwise we have a huge
 problem.  There's no need to obfuscate here by manually converting
 to floating point representation.
 
 Here's a diff which also includes same fix for ld128.  OK?

Fair enough.  Please commit.

 Index: ld128/s_floorl.c
 ===
 RCS file: /cvs/src/lib/libm/src/ld128/s_floorl.c,v
 retrieving revision 1.1
 diff -u -r1.1 s_floorl.c
 --- ld128/s_floorl.c  6 Jul 2011 00:02:42 -   1.1
 +++ ld128/s_floorl.c  11 Feb 2014 05:24:15 -
 @@ -34,10 +34,11 @@
   jj0 = ((i048)0x7fff)-0x3fff;
   if(jj048) {
   if(jj00) { /* raise inexact if x != 0 */
 - if(huge+x0.0) {/* return 0*sign(x) if |x|1 */
 - if(i0=0) {i0=i1=0;}
 + if(huge+x0.0) {
 + if(i0=0)
 + return 0.0L;
   else if(((i00x7fffLL)|i1)!=0)
 - { i0=0xbfffULL;i1=0;}
 + return -1.0L;
   }
   } else {
   i = (0xULL)jj0;
 Index: ld80/s_floorl.c
 ===
 RCS file: /cvs/src/lib/libm/src/ld80/s_floorl.c,v
 retrieving revision 1.2
 diff -u -r1.2 s_floorl.c
 --- ld80/s_floorl.c   25 Jul 2011 16:20:09 -  1.2
 +++ ld80/s_floorl.c   11 Feb 2014 05:24:01 -
 @@ -35,10 +35,11 @@
   jj0 = (se0x7fff)-0x3fff;
   if(jj031) {
   if(jj00) { /* raise inexact if x != 0 */
 - if(huge+x0.0) {/* return 0*sign(x) if |x|1 */
 - if(sx==0) {se=0;i0=i1=0;}
 + if(huge+x0.0) {
 + if(sx==0)
 + return 0.0L;
   else if(((se0x7fff)|i0|i1)!=0)
 - { se=0xbfff;i0=i1=0;}
 + return -1.0L;
   }
   } else {
   i = (0x7fff)jj0;

Re: em(4): Don't count RX overruns and missed packets as input errros

2014-02-11 Thread Brad Smith 
On Fri, Feb 07, 2014 at 06:15:44AM -0500, Brad Smith wrote:
 On Tue, Jan 28, 2014 at 02:08:09AM -0500, Brad Smith wrote:
  On Tue, Jan 28, 2014 at 01:21:46PM +1000, David Gwynne wrote:
   
   On 26 Jan 2014, at 11:31 am, Brad Smith b...@comstyle.com wrote:
   
On 31/12/13 5:50 AM, Mike Belopuhov wrote:
On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote:
On 31/12/13 3:14 AM, Mark Kettenis wrote:

Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith b...@comstyle.com

Don't count RX overruns and missed packets as inputs errors. They're
expected to increment when using MCLGETI.

OK?


These may be expected, but they're still packets that were not
received.  And it is useful to know about these, for example when
debugging TCP performance issues.


Well do we want to keep just the missed packets or both? Part of the
diff was inspired by this commit when I was looking at what counters
were incrementing..

for bge(4)..

revision 1.334
date: 2013/06/06 00:05:30;  author: dlg;  state: Exp;  lines: +2 -4;
dont count rx ring overruns as input errors. with MCLGETI controlling 
the
ring we expect to run out of rx descriptors as a matter of course, 
its not
an error.

ok mikeb@



it does screws up statistics big time.  does mpc counter follow 
rx_overruns?
why did we add them up both previously?

Yes, it does. I can't say why exactly but before MCLGETI for most 
environments
it was unlikely to have RX overruns.
   
   its not obvious?
   
   rx rings are usually massively over provisioned. eg, my myx has 512 
   entries in its
   rx ring. however, its interrupt mitigation is currently configured for 
   approximately
   16k interrupts a second. if you're sustaining 1m pps, then you can divide 
   that by the
   interrupt rate to figure out the average usage of the rx ring. so 1000 / 
   16 is about
   60-65 descriptors per interrupt. 512 is roughly an order of magnitude 
   more than what
   you need for that workload.
   
   if you were hitting the ring limits before MCLGETI, then that means you 
   dont have
   enough cpu to process the pps. increasing the ring size would make it 
   worse cos you'd
   spend more time freeing mbufs because you were too far behind on the pps 
   you could
   deal with.
  
  Ya, I don't know why I ultimately said I can't say why exactly as I was 
  thinking about
  what you said regaring having a lot of buffers allocated and that's why I 
  said it was
  unlikely to have RX overruns.
  
  Since this was changed for bge(4) then the other drivers using MCLGETI 
  should be changed
  as well if there is consensus about not adding the RX overruns to the 
  interfaces input
  errors counter. But I think kettenis has a point as well that this 
  information is useful
  its just we don't have any way of exposing that info to userland.
 
 Ok, so I looked at the other drivers using MCLGETI and there are a few others 
 also
 counting FIFO overruns towards input errors.
 
ping.

 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);
 Index: dev/pci/if_se.c
 ===
 RCS file: /home/cvs/src/sys/dev/pci/if_se.c,v
 retrieving revision 1.9
 diff -u -p -u -p -r1.9 if_se.c
 --- dev/pci/if_se.c   28 Dec 2013 03:34:54 -  1.9
 +++ dev/pci/if_se.c   28 Jan 2014 04:49:53 -
 @@ -939,7 +939,8 @@ se_rxeof(struct se_softc *sc)
   printf(%s: rx error %b\n,
   ifp-if_xname, rxstat, RX_ERR_BITS);
   se_discard_rxbuf(sc, i);
 - ifp-if_ierrors++;
 + if ((rxstat  RDS_OVRUN) == 0)
 + ifp-if_ierrors++;
   continue;
   }
  
 Index: dev/pci/if_sis.c
 ===
 RCS file: /home/cvs/src/sys/dev/pci/if_sis.c,v
 retrieving revision 1.115
 diff -u -p -u -p -r1.115 if_sis.c
 --- dev/pci/if_sis.c  28 Dec 2013 03:34:54 -  1.115
 +++ dev/pci/if_sis.c  28 Jan 2014 04:51:53 -
 @@ -1378,7 +1378,8 @@ sis_rxeof(struct sis_softc *sc)
   total_len = (ETHER_MAX_DIX_LEN - ETHER_CRC_LEN))
   rxstat = ~SIS_RXSTAT_GIANT;
   if (SIS_RXSTAT_ERROR(rxstat)) {
 -

Re: carp sends incorrect NA

2014-02-11 Thread Alexander Bluhm 
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.

bluhm

 
 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: em(4): Don't count RX overruns and missed packets as input errros

2014-02-11 Thread Mark Kettenis 
 Date: Tue, 11 Feb 2014 13:30:47 -0500
 From: Brad Smith b...@comstyle.com
 
  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.

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.

Re: em(4): Don't count RX overruns and missed packets as input errros

2014-02-11 Thread Brad Smith 
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 b...@comstyle.com
  
   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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[Patch] Add rtlabel to rt_newaddrmsg

2014-02-11 Thread Florian Riehm 
Hi tech@,

I'm using the ospfd with redistribute rtlabel statements.
If I add new addresses to interfaces with a route label, ospfd will
not notice it, because the route messages don't contain the route
label. Please have a look to the attached patch. It adds the
route label, so ospfd can handle it properly.

Regards,

florian


Index: rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.137
diff -u -p -r1.137 rtsock.c
--- rtsock.c22 Jan 2014 06:28:09 -  1.137
+++ rtsock.c11 Feb 2014 19:43:17 -
@@ -1193,12 +1193,15 @@ rt_newaddrmsg(int cmd, struct ifaddr *if
if ((cmd == RTM_ADD  pass == 2) ||
(cmd == RTM_DELETE  pass == 1)) {
struct rt_msghdr *rtm;
+   struct sockaddr_rtlabel sa_rl;

if (rt == 0)
continue;
info.rti_info[RTAX_NETMASK] = rt_mask(rt);
info.rti_info[RTAX_DST] = sa = rt_key(rt);
info.rti_info[RTAX_GATEWAY] = rt-rt_gateway;
+   info.rti_info[RTAX_LABEL] =
+   rtlabel_id2sa(rt-rt_labelid, sa_rl);
if ((m = rt_msg1(cmd, info)) == NULL)
continue;
rtm = mtod(m, struct rt_msghdr *);

iostat -I padding

2014-02-11 Thread Ted Unangst 
with the totals (-I) option, most of the fields overflow. comically.

this bumps many of their sizes, such that at least my laptop with
a whopping three hours uptime doesn't print out a tangled mess. normal
display untouched. if we need to pad the fields larger later we can,
this is a start.

Index: iostat.c
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
retrieving revision 1.32
diff -u -p -r1.32 iostat.c
--- iostat.c23 Nov 2013 22:51:42 -  1.32
+++ iostat.c11 Feb 2014 23:21:16 -
@@ -205,12 +205,18 @@ header(void)
 
/* Main Headers. */
if (ISSET(todo, SHOW_TTY))
-   printf(  tty);
+   if (ISSET(todo, SHOW_TOTALS))
+   printf(tty);
+   else
+   printf(  tty);
 
if (ISSET(todo, SHOW_STATS_1))
for (i = 0; i  dk_ndrive; i++)
if (cur.dk_select[i])
-   printf( %16.16s , cur.dk_name[i]);
+   if (ISSET(todo, SHOW_TOTALS))
+   printf( %18.18s , cur.dk_name[i]);
+   else
+   printf( %16.16s , cur.dk_name[i]);
if (ISSET(todo, SHOW_STATS_2))
for (i = 0; i  dk_ndrive; i++)
if (cur.dk_select[i])
@@ -222,13 +228,16 @@ header(void)
 
/* Sub-Headers. */
if (ISSET(todo, SHOW_TTY))
-   printf( tin tout);
+   if (ISSET(todo, SHOW_TOTALS))
+   printf(   tin tout);
+   else
+   printf( tin tout);
 
if (ISSET(todo, SHOW_STATS_1))
for (i = 0; i  dk_ndrive; i++)
if (cur.dk_select[i]) {
if (ISSET(todo, SHOW_TOTALS))
-   printf(  KB/t xfr MB   );
+   printf(  KB/t   xfr MB );
else
printf(  KB/t  t/s  MB/s );
}
@@ -262,7 +271,10 @@ disk_stats(double etime)
printf( %5.2f, mbps);
 
/* average transfers per second. */
-   printf( %4.0f, (cur.dk_rxfer[dn] + cur.dk_wxfer[dn]) / etime);
+   if (ISSET(todo, SHOW_TOTALS))
+   printf( %5.0f, (cur.dk_rxfer[dn] + cur.dk_wxfer[dn]) 
/ etime);
+   else
+   printf( %4.0f, (cur.dk_rxfer[dn] + cur.dk_wxfer[dn]) 
/ etime);
 
/* time busy in disk activity */
atime = (double)cur.dk_time[dn].tv_sec +
@@ -274,7 +286,10 @@ disk_stats(double etime)
(double)(1024 * 1024);
else
mbps = 0;
-   printf( %5.2f , mbps / etime);
+   if (ISSET(todo, SHOW_TOTALS))
+   printf( %6.2f , mbps / etime);
+   else
+   printf( %5.2f , mbps / etime);
}
 }
 
@@ -347,7 +362,12 @@ display(void)
etime = 1.0;
 
if (ISSET(todo, SHOW_TTY))
-   printf(%4.0f %4.0f, cur.tk_nin / etime, cur.tk_nout / etime);
+   if (ISSET(todo, SHOW_TOTALS))
+   printf(%6.0f %8.0f, cur.tk_nin / etime,
+   cur.tk_nout / etime);
+   else
+   printf(%4.0f %4.0f, cur.tk_nin / etime,
+   cur.tk_nout / etime);
 
if (ISSET(todo, SHOW_STATS_1))
disk_stats(etime);

release(8) patch

2014-02-11 Thread Frank Brodbeck 
Hi all,

${ARCH} in the release(8) manpage always bothered me somehow. Probably
it's because I do like copypaste and I think introducing a variable
here is not useful as everybody willing to build from source should know
what $(uname -m) does:

Index: release.8
===
RCS file: /cvs/src/share/man/man8/release.8,v
retrieving revision 1.67
diff -u -r1.67 release.8
--- release.8   26 Nov 2013 17:53:22 -  1.67
+++ release.8   11 Feb 2014 21:25:18 -
@@ -127,11 +127,8 @@
 To build a kernel the steps are:
 .Pp
 Change the current working directory.
-.Va ${ARCH}
-is the architecture of your machine, e.g.\
-.Li i386 .
 .Pp
-.Dl $ cd /usr/src/sys/arch/${ARCH}/conf
+.Dl $ cd /usr/src/sys/arch/$(uname -m)/conf
 .Pp
 Edit the kernel configuration file.
 .Va ${NAME}

I do not know about anything besides i386 and amd64 but at least for
those architectures the above is working.

Thanks,
Frank.

Re: release(8) patch

2014-02-11 Thread Stuart Henderson 
On 2014/02/11 22:35, Frank Brodbeck wrote:
 Hi all,
 
 ${ARCH} in the release(8) manpage always bothered me somehow. Probably
 it's because I do like copypaste and I think introducing a variable
 here is not useful as everybody willing to build from source should know
 what $(uname -m) does:
 
 Index: release.8
 ===
 RCS file: /cvs/src/share/man/man8/release.8,v
 retrieving revision 1.67
 diff -u -r1.67 release.8
 --- release.8   26 Nov 2013 17:53:22 -  1.67
 +++ release.8   11 Feb 2014 21:25:18 -
 @@ -127,11 +127,8 @@
  To build a kernel the steps are:
  .Pp
  Change the current working directory.
 -.Va ${ARCH}
 -is the architecture of your machine, e.g.\
 -.Li i386 .
  .Pp
 -.Dl $ cd /usr/src/sys/arch/${ARCH}/conf
 +.Dl $ cd /usr/src/sys/arch/$(uname -m)/conf
  .Pp
  Edit the kernel configuration file.
  .Va ${NAME}
 
 I do not know about anything besides i386 and amd64 but at least for
 those architectures the above is working.
 
 Thanks,
 Frank.
 

uname -m is the correct invocation here (the other architecture string,
i.e. cpu arch rather than machine arch, is returned by arch -s and would
be wrong for this).

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...

Re: [Patch] Add rtlabel to rt_newaddrmsg

2014-02-11 Thread Alexander Bluhm 
On Tue, Feb 11, 2014 at 09:07:04PM +0100, Florian Riehm wrote:
 Hi tech@,
 
 I'm using the ospfd with redistribute rtlabel statements.
 If I add new addresses to interfaces with a route label, ospfd will
 not notice it, because the route messages don't contain the route
 label. Please have a look to the attached patch. It adds the
 route label, so ospfd can handle it properly.

Makes sense to me, OK bluhm@

 
 Regards,
 
 florian
 
 
 Index: rtsock.c
 ===
 RCS file: /cvs/src/sys/net/rtsock.c,v
 retrieving revision 1.137
 diff -u -p -r1.137 rtsock.c
 --- rtsock.c22 Jan 2014 06:28:09 -  1.137
 +++ rtsock.c11 Feb 2014 19:43:17 -
 @@ -1193,12 +1193,15 @@ rt_newaddrmsg(int cmd, struct ifaddr *if
 if ((cmd == RTM_ADD  pass == 2) ||
 (cmd == RTM_DELETE  pass == 1)) {
 struct rt_msghdr *rtm;
 +   struct sockaddr_rtlabel sa_rl;
 
 if (rt == 0)
 continue;
 info.rti_info[RTAX_NETMASK] = rt_mask(rt);
 info.rti_info[RTAX_DST] = sa = rt_key(rt);
 info.rti_info[RTAX_GATEWAY] = rt-rt_gateway;
 +   info.rti_info[RTAX_LABEL] =
 +   rtlabel_id2sa(rt-rt_labelid, sa_rl);
 if ((m = rt_msg1(cmd, info)) == NULL)
 continue;
 rtm = mtod(m, struct rt_msghdr *);

Re: rtinit, RTF_HOST and netmask

2014-02-11 Thread Alexander Bluhm 
On Tue, Feb 11, 2014 at 04:00:25PM +0100, Martin Pieuchot wrote:
 On 04/02/14(Tue) 10:50, Martin Pieuchot wrote:
  Diff below removes an old comment about bsdi4 and make it clear that
  netmasks are not needed for routes to host.
  
  ok?

OK bluhm@

 
 Anybody?
 
 
  
  Index: net/route.c
  ===
  RCS file: /home/ncvs/src/sys/net/route.c,v
  retrieving revision 1.151
  diff -u -p -r1.151 route.c
  --- net/route.c 23 Jan 2014 10:16:30 -  1.151
  +++ net/route.c 4 Feb 2014 09:38:53 -
  @@ -1119,13 +1119,9 @@ rtinit(struct ifaddr *ifa, int cmd, int 
  info.rti_info[RTAX_LABEL] =
  rtlabel_id2sa(ifa-ifa_ifp-if_rtlabelid, sa_rl);
   
  -   /*
  -* XXX here, it seems that we are assuming that ifa_netmask is NULL
  -* for RTF_HOST.  bsdi4 passes NULL explicitly (via intermediate
  -* variable) when RTF_HOST is 1.  still not sure if i can safely
  -* change it to meet bsdi4 behavior.
  -*/
  -   info.rti_info[RTAX_NETMASK] = ifa-ifa_netmask;
  +   if ((flags  RTF_HOST) == 0)
  +   info.rti_info[RTAX_NETMASK] = ifa-ifa_netmask;
  +
  error = rtrequest1(cmd, info, RTP_CONNECTED, nrt, rtableid);
  if (cmd == RTM_DELETE) {
  if (error == 0  (rt = nrt) != NULL) {

Re: em(4): Don't count RX overruns and missed packets as input errros

2014-02-11 Thread Claudio Jeker 
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 b...@comstyle.com
  
   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.
 
 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 totally agree here. Packets are dropped and should be counted in some
ways else you may think all is fine but actually a lot of packets are
dropped by the driver.

-- 
:wq Claudio

Re: rtinit, RTF_HOST and netmask

2014-02-11 Thread Claudio Jeker 
On Tue, Feb 11, 2014 at 04:00:25PM +0100, Martin Pieuchot wrote:
 On 04/02/14(Tue) 10:50, Martin Pieuchot wrote:
  Diff below removes an old comment about bsdi4 and make it clear that
  netmasks are not needed for routes to host.
  
  ok?
 
 Anybody?
 

OK claudio@

 
  
  Index: net/route.c
  ===
  RCS file: /home/ncvs/src/sys/net/route.c,v
  retrieving revision 1.151
  diff -u -p -r1.151 route.c
  --- net/route.c 23 Jan 2014 10:16:30 -  1.151
  +++ net/route.c 4 Feb 2014 09:38:53 -
  @@ -1119,13 +1119,9 @@ rtinit(struct ifaddr *ifa, int cmd, int 
  info.rti_info[RTAX_LABEL] =
  rtlabel_id2sa(ifa-ifa_ifp-if_rtlabelid, sa_rl);
   
  -   /*
  -* XXX here, it seems that we are assuming that ifa_netmask is NULL
  -* for RTF_HOST.  bsdi4 passes NULL explicitly (via intermediate
  -* variable) when RTF_HOST is 1.  still not sure if i can safely
  -* change it to meet bsdi4 behavior.
  -*/
  -   info.rti_info[RTAX_NETMASK] = ifa-ifa_netmask;
  +   if ((flags  RTF_HOST) == 0)
  +   info.rti_info[RTAX_NETMASK] = ifa-ifa_netmask;
  +
  error = rtrequest1(cmd, info, RTP_CONNECTED, nrt, rtableid);
  if (cmd == RTM_DELETE) {
  if (error == 0  (rt = nrt) != NULL) {
  
 

-- 
:wq Claudio

Re: [Patch] Add rtlabel to rt_newaddrmsg

2014-02-11 Thread Claudio Jeker 
On Tue, Feb 11, 2014 at 09:07:04PM +0100, Florian Riehm wrote:
 Hi tech@,
 
 I'm using the ospfd with redistribute rtlabel statements.
 If I add new addresses to interfaces with a route label, ospfd will
 not notice it, because the route messages don't contain the route
 label. Please have a look to the attached patch. It adds the
 route label, so ospfd can handle it properly.

Makes sense to me. OK.

 
 Index: rtsock.c
 ===
 RCS file: /cvs/src/sys/net/rtsock.c,v
 retrieving revision 1.137
 diff -u -p -r1.137 rtsock.c
 --- rtsock.c22 Jan 2014 06:28:09 -  1.137
 +++ rtsock.c11 Feb 2014 19:43:17 -
 @@ -1193,12 +1193,15 @@ rt_newaddrmsg(int cmd, struct ifaddr *if
 if ((cmd == RTM_ADD  pass == 2) ||
 (cmd == RTM_DELETE  pass == 1)) {
 struct rt_msghdr *rtm;
 +   struct sockaddr_rtlabel sa_rl;
 
 if (rt == 0)
 continue;
 info.rti_info[RTAX_NETMASK] = rt_mask(rt);
 info.rti_info[RTAX_DST] = sa = rt_key(rt);
 info.rti_info[RTAX_GATEWAY] = rt-rt_gateway;
 +   info.rti_info[RTAX_LABEL] =
 +   rtlabel_id2sa(rt-rt_labelid, sa_rl);
 if ((m = rt_msg1(cmd, info)) == NULL)
 continue;
 rtm = mtod(m, struct rt_msghdr *);
 

-- 
:wq Claudio

Shuttle XS35V2 dmesg a couple of buglets (video and USB insertion)

2014-02-11 Thread Rod Whitworth 
buglet 1:
When booting and the screen goes to its 34 line 85 column mode the text
mode fits into 30cm wide and 22cm high at the top left corner of a 38cm
wide 30cm high screen.

X runs full screen.

buglet 2:
When capturing the dmesg into a file on a USB mem there was no white on
blue notice telling me that sd0 had been inserted. Or removed 8-)

Neither happens on an Intel 945GTP running the same snapshot.

dmesg:
OpenBSD 5.5-beta (GENERIC.MP) #233: Fri Feb  7 12:14:13 MST 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class)
1.80 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
real mem  = 2137223168 (2038MB)
avail mem = 2090381312 (1993MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/23/11, BIOS32 rev. 0 @
0xf0010, SMBIOS rev. 2.6 @ 0xfc8b0 (23 entries)
bios0: vendor American Megatrends Inc. version 080015 date 06/23/2011
bios0: Standard XS35
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI
acpi0: wakeup devices P0P1(S4) AZAL(S3) P0P4(S4) P0P5(S4) JLAN(S3)
P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
EUSB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class)
1.80 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class)
1.80 GHz
cpu2:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class)
1.80 GHz
cpu3:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAI
T,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 3, remapped to apid 4
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P5)
acpiprt4 at acpi0: bus -1 (P0P6)
acpiprt5 at acpi0: bus -1 (P0P7)
acpiprt6 at acpi0: bus -1 (P0P8)
acpiprt7 at acpi0: bus -1 (P0P9)
acpiec0 at acpi0
acpicpu0 at acpi0
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpitz0 at acpi0: critical temperature is 104 degC
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xda00! 0xce000/0x1800! 0xcf800/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
0:31:2: mem address conflict 0xfc00/0x400
pchb0 at pci0 dev 0 function 0 Intel Pineview DMI rev 0x02
vga1 at pci0 dev 2 function 0 Intel Pineview Video rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1024x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel Pineview Video rev 0x02 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02:
msi
azalia0: codecs: IDT 92HD81B1X
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4
int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 4
int 17
pci2 at ppb1 bus 2
JMicron SD/MMC rev 0x80 at pci2 dev 0 function 0 not configured
sdhc0 at pci2 dev 0 function 2 JMicron SD Host Controller rev 0x80:
apic 4 int 18
sdmmc0 at sdhc0
JMicron Memory Stick rev 0x80 at pci2 dev 0 function 3 not configured
jme0 at pci2 dev 0 function 5 JMicron JMC250 rev 0x03: msi, address
80:ee:73:28:4b:69
jmphy0 at jme0 phy 1: JMP211 10/100/1000 PHY, rev. 1
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 4
int 23
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 4
int 19
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 4
int 18
uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 4
int 16
ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 4
int 23
usb0 at ehci0: USB revision

Re: release(8) patch

2014-02-11 Thread Mark Kettenis 
 Date: Tue, 11 Feb 2014 22:35:27 +0100
 From: Frank Brodbeck f...@guug.de
 
 Hi all,
 
 ${ARCH} in the release(8) manpage always bothered me somehow. Probably
 it's because I do like copypaste and I think introducing a variable
 here is not useful as everybody willing to build from source should know
 what $(uname -m) does:
 
 Index: release.8
 ===
 RCS file: /cvs/src/share/man/man8/release.8,v
 retrieving revision 1.67
 diff -u -r1.67 release.8
 --- release.8   26 Nov 2013 17:53:22 -  1.67
 +++ release.8   11 Feb 2014 21:25:18 -
 @@ -127,11 +127,8 @@
  To build a kernel the steps are:
  .Pp
  Change the current working directory.
 -.Va ${ARCH}
 -is the architecture of your machine, e.g.\
 -.Li i386 .
  .Pp
 -.Dl $ cd /usr/src/sys/arch/${ARCH}/conf
 +.Dl $ cd /usr/src/sys/arch/$(uname -m)/conf
  .Pp
  Edit the kernel configuration file.
  .Va ${NAME}
 
 I do not know about anything besides i386 and amd64 but at least for
 those architectures the above is working.

Just make sure you set $ARCH in your .profile.