Ritesh Agrawal | 27 Feb 14:00 2015

DIAGNOSTIC panic in unp_gc function

Hi All,

I have been seeing random panics on my NetBSD-6.0 based system and this 
panic was in AF_LOCAL protocol code (uipc_usrreq.c). One of the panic was:

uvm_fault(0xffffffff81a195e0, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff803042ff cs 8 rflags 10283 cr2  8 cpl 0 rsp
fffffe810f27bab0
panic: trap
cpu1: Begin traceback...
printf_nolog() at netbsd:printf_nolog
startlwp() at netbsd:startlwp
alltraps() at netbsd:alltraps+0x96
unp_detach() at netbsd:unp_detach+0x2e
uipc_usrreq() at netbsd:uipc_usrreq+0x79
soclose() at netbsd:soclose+0x79
soo_close() at netbsd:soo_close+0x1a
closef() at netbsd:closef+0x4a
unp_thread() at netbsd:unp_thread+0x3cb
cpu1: End traceback...

I than installed the NetBSD kernel with "DIAGNOSTIC option" and the 
DIAGNOSTIC kernel paniced on following line no:

sys/kern/uipc_usrreq.c:1713 with current TOT for MAIN branch.

It seems that we can get into this code with file pointer reference 
count as 0.
I got into this situation by following steps:
(Continue reading)

Roy Marples | 27 Feb 13:34 2015

host route out of subnet

Hi List

I am working on an issue with managing a host route to a host outside of
the defined subnet.
We have a wiki on it here:
http://www.netbsd.org/docs/network/#nonsubnetgateway

 # ifconfig fxp0 inet 10.0.0.1
 # route add -host 192.168.0.1 -link fxp0 -iface
 # route add default -ifa 10.0.0.1 192.168.0.1

On -current at least, this fails.
netstat and route report the gateway as being an ethernet address made
from the letters fxp0 which also looks odd but seems to be a failing of
link_addr(3) or the way route and netstat display it.

On the other hand this works instead:

 # ifconfig fxp0 inet 10.0.0.1
 # route add -net 192.168.0.1/32 -link fxp0 -iface -cloning
 # route add default -ifa 10.0.0.1 192.168.0.1

I have had a very unsatisfactory ad-hoc chat with a few people, so I'm
bring this here.

1) Is the route add -host command above expected to work as described in
the wiki? If so a simple fix is not to use link_addr(3) and instead set
sdl->sdl_index to the interface index. This makes it then work.
However, the kernel then displays an advisory of arpresolve: unresolved
and rt_expire == 0 so it might just be working by accident rather than
(Continue reading)

Roy Marples | 26 Feb 15:06 2015

carp(4) code reduction

Hi List

With todays changes in -current I think it's possible to reduce the code
in carp_setroute. I don't use carp(4) and have little idea how it works,
but the patch looks right and mirrors an improvement made in other BSD.

What I don't know if it's correct, or the improvement relies on other
pieces as well.
The patch can be found here: http://www.netbsd.org/~roy/carp.diff

I won't apply it until I get some testing feedback or can try it myself.

Thanks

Roy

Roy Marples | 24 Feb 16:46 2015

RTF_LOCAL support

Hi List

FreeBSD and OpenBSD have added the routing flag RTF_LOCAL to indicate
the route represents a local address. They also create a local route for
each IPv4 address in a similar way to IPv6. dhcpcd and dhclient-script
do this for NetBSD as well, but it makes sense to move this into the
kernel for statically added addresses as well.

I have created a patch to do this for NetBSD which also moves the bulk
of the in6_if{add,rem}loop() functions into more generic
rt_ifa_{add,rem}local() functions and also renamed to
in6_if{add,rem}local(). in_if{add,rem}local() functions have also been
added to achieve the same functionality for IPv4.

One question though - sys/netinet/ip_carp.c has a large block of code
which looks like it handles this for IPv4. the IPv6 segment just calls
in6_{add,rem}loop(). Can this large block of code be changed to call
in_if{add,rem}local() for IPv4 or have I missed something? I don't know
anything about carp(4), hence asking.

Thanks
Roy
Attachment (rtf_local.diff): text/x-diff, 22 KiB
Hauke Fath | 20 Feb 13:14 2015
Picon

ixg(4) and Intel X540?

Hi,

I have a batch of servers here with an Intel X540-T1 10GbE card that I 
had hoped would be recognized as ixg(4) by NetBSD, but no...

pci1 at ppb0 bus 1
vendor 0x8086 product 0x1528 (ethernet network, revision 0x01) at pci1 
dev 0 function 0 not configured

OpenBSD 5.6 probes it as

ix0 at pci1 dev 0 function 0 "Intel X540T" rev. 0x01: msi, address 
a0:36:9f:23:21:fc

but then fails to detect a carrier.

FreeBSD 10.1 probes it as

ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.15> 
mem 0xf6000000-0xf61fffff,0xf6200000-0xf6203fff irq 16 at device 0.0 on 
pci1
ix0: Using MSIX interrupts with 5 vectors
ix0: Ethernet address: a0:36:9f:23:21:fc
ix0: PCI Express Bus: Speed 5.0GT/s Width x8

and then fails to recognize the cd drive it just booted from, so I 
couldn't run ifconfig.

I understand that the NetBSD ixg(4) was ported from FreeBSD 
<http://comments.gmane.org/gmane.os.netbsd.devel.network/12284>. What 
(Continue reading)

Robert Swindells | 18 Feb 21:10 2015
Picon

Adding const to in6_sin_2_v4mapsin6


Would anyone object to the following change ?

It makes it easier to use an address from the route cache as the
input to the address mapping.

Index: in6.c
===================================================================
RCS file: /cvsroot/src/sys/netinet6/in6.c,v
retrieving revision 1.180
diff -u -r1.180 in6.c
--- in6.c       2 Dec 2014 19:36:58 -0000       1.180
+++ in6.c       18 Feb 2015 19:39:39 -0000
 <at>  <at>  -2341,7 +2341,7  <at>  <at> 

 /* Convert sockaddr_in to sockaddr_in6 in v4 mapped addr format. */
 void
-in6_sin_2_v4mapsin6(struct sockaddr_in *sin, struct sockaddr_in6 *sin6)
+in6_sin_2_v4mapsin6(const struct sockaddr_in *sin, struct sockaddr_in6 *sin6)
 {
        memset(sin6, 0, sizeof(*sin6));
        sin6->sin6_len = sizeof(struct sockaddr_in6);
Index: in6.h
===================================================================
RCS file: /cvsroot/src/sys/netinet6/in6.h,v
retrieving revision 1.82
diff -u -r1.82 in6.h
--- in6.h       20 Jan 2015 21:27:36 -0000      1.82
+++ in6.h       18 Feb 2015 19:39:39 -0000
 <at>  <at>  -770,7 +770,7  <at>  <at> 
(Continue reading)

Manuel Bouyer | 13 Feb 17:37 2015

connect to 0.0.0.0 vs ::

Hello,
while trying to understand what apache is doing with pipes and why it
could end up hanging:
http://mail-index.netbsd.org/current-users/2015/02/13/msg026686.html

I though that maybe it could be related to these messages in the
logs:
[Sat Feb 15 14:18:42 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80
[Sat Feb 15 14:18:43 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80
[Sat Feb 15 14:18:44 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80
[Sat Feb 15 14:18:45 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80
[Sat Feb 15 14:18:46 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80

After more analisis of the apache code, it turns out the master
connects to its own listeing socket as a way to wake up one of its
childs (this is dummy_connection() in mpm_common.c, called from
ap_mpm_pod_signal() and ap_mpm_pod_killpg()). 

We have a different behavior for ipv4 and ipv6:
antioche:/tmp#telnet :: 80
Trying ::...
telnet: Unable to connect to remote host: Network is unreachable
antioche:/tmp#telnet 0.0.0.0 80
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.

and this cause apache to fail to wake its childs (and eventually fill up the
pipe, causing the problem I'm seeing now). Is it expected behavior ?
On a linux system, both 0.0.0.0 and :: connects to localhost if
(Continue reading)

Greg Troxel | 10 Feb 15:39 2015
Picon

quagga proposing to drop support for systems without IPv6


(quagga is one of the leading Free Software routing protocol daemons, and
runs well on NetBSD.)

quagga is proposing to drop the "--disable-ipv6" flag, which avoids
including v6 headers.  One will still be able to turn off OSPFv3 (for
v6) and RIPng.

This seems fine for us; I'm pretty sure not even mouse <at>  has a running
NetBSD system without v6 header files :-) I can't pin down the date from
memory, but I think we had IPv6 in the 2nd half of the 90s.  And I'm not
aware of any currently-maintained operating system out there without v6
support.

Does anyone see any reasons why this a) would be problematic on NetBSD
or b) (OT I know) be problematic anywhere else?
Havard Eidnes | 7 Feb 00:33 2015
Picon

TCP_INFO socket option

Hi,

I noticed that iperf3 on Linux (and presumably FreeBSD) can
display the number of retransmits and the current congestion
window for each measurement status interval for the TCP session
being tested.

The info for this comes from a TCP_INFO socket option initially
added in Linux 2.6.  The attached diff tries to implement this
for NetBSD (pulled from FreeBSD and then adapted), and the
resulting diff relative to netbsd-7 follows below.  The result
builds, at least -- that's as long as I've tested so far.

In order to implement this, I had to add three variables per
tcpcb.  I've not been able to find where to initialize these, or
whether they would already be zeroed on allocation of the tcpcb.

Any comments?

Regards,

- HÃ¥vard
Index: tcp.h
===================================================================
RCS file: /cvsroot/src/sys/netinet/tcp.h,v
retrieving revision 1.30
diff -u -r1.30 tcp.h
--- tcp.h	7 Jan 2012 20:20:22 -0000	1.30
(Continue reading)

Greg Troxel | 6 Feb 00:24 2015
Picon

if_bnx issues


I am trying to integrate a number of fixes for if_bnx back to netbsd
proper.  These are mostly about issues that manifest under unreasonable
load leading to mbuf exhaustion.  I would like some review on these.

This fix is due to Beverly Schwartz.

The issue is failing to get new hw_cons value from the hardware due to a
missing dmamap_sync.  This patch did fix the issue (on i386) and systems
with it are stable, but I'm not 100% certain the dmamap_sync is entirely
right.

Index: sys/dev/pci/if_bnx.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.57
diff -u -p -u -u -r1.57 if_bnx.c
--- if_bnx.c	9 Jul 2014 16:30:11 -0000	1.57
+++ if_bnx.c	5 Feb 2015 23:18:50 -0000
 <at>  <at>  -4656,6 +4656,8  <at>  <at>  bnx_rx_intr(struct bnx_softc *sc)

 		/* Refresh hw_cons to see if there's new work */
 		if (sw_cons == hw_cons) {
+			bus_dmamap_sync(sc->bnx_dmatag, sc->status_map, 0,
+					BNX_STATUS_BLK_SZ, BUS_DMASYNC_POSTREAD);
 			hw_cons = sc->hw_rx_cons =
 			    sblk->status_rx_quick_consumer_index0;
 			if ((hw_cons & USABLE_RX_BD_PER_PAGE) ==
Greg Troxel | 5 Feb 17:55 2015
Picon

[Greg Troxel] CVS commit: src/usr.sbin/mrouted

I would say this shows that no one uses multicast :-(

I have a number of fixes from a private tree that I will be applying as
I am able.  All of them have seen extensive testing in a
heavily-modified netbsd-6 tree and were subject to internal code review
at BBN.  Therefore, when they apply cleanly to current and my read is
that the fix is clearly still right, I'm going to just apply, compile
test (multiple arches) and commit, aiming for zero breakage.

Picon
From: Greg Troxel <gdt <at> netbsd.org>
Subject: CVS commit: src/usr.sbin/mrouted
Date: 2015-02-05 16:50:20 GMT
Module Name:	src
Committed By:	gdt
Date:		Thu Feb  5 16:50:19 UTC 2015

Modified Files:
	src/usr.sbin/mrouted: vif.c

Log Message:
Fix bug in mrouted about aging neighbors.

mrouted will periodically age its neighbors and will remove a neighbor
(Continue reading)


Gmane