Re: [RFC] ifconfig description
On 28 July 2015 at 20:55, Alexander V. Chernikov melif...@freebsd.org wrote: 28.07.2015, 15:32, Arseny Nasokin eir...@gmail.com: Separate ifconfig_IF_description will be simpler to use. I was also insisting on this.. +pluknet@ Sergey, maybe we could reconsider this stuff and add separate _description field? No, thanks. That means that we should also build up ifconfig_IF_group, ifconfig_IF_name and suchalikes for parity. I wouldn't object strongly though if someone will come up with a patch. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: moving ALTQ out of contrib
On Tue, Apr 14, 2015 at 11:07:49PM +0300, Gleb Smirnoff wrote: On Tue, Apr 14, 2015 at 04:53:46PM +0300, Gleb Smirnoff wrote: T Hi! T T With the new ifnet KPI, that is now being developed in projects/ifnet, T the ALTQ will need some tweaking. It is discontinued by initial author T for a decade now, and it has already experienced direct commits in T our tree. Thus, I see no good reasons to continue keeping it in contrib. T T In NetBSD they have it in sys/altq. T T I'd prefer to move it to sys/net/altq. T T Any objections or better ideas? Suggested diff. -- Totus tuus, Glebius. Index: ObsoleteFiles.inc === --- ObsoleteFiles.inc (revision 281525) +++ ObsoleteFiles.inc (working copy) @@ -38,6 +38,21 @@ # xargs -n1 | sort | uniq -d; # done +# 20150410: ALTQ moved to net/altq +OLD_FILES+=usr/include/altq/altq_rmclass_debug.h +OLD_FILES+=usr/include/altq/altq.h +OLD_FILES+=usr/include/altq/altq_cdnr.h +OLD_FILES+=usr/include/altq/altq_hfsc.h +OLD_FILES+=usr/include/altq/altq_priq.h +OLD_FILES+=usr/include/altq/altqconf.h +OLD_FILES+=usr/include/altq/altq_classq.h +OLD_FILES+=usr/include/altq/altq_red.h +OLD_FILES+=usr/include/altq/if_altq.h +OLD_FILES+=usr/include/altq/altq_var.h +OLD_FILES+=usr/include/altq/altq_rmclass.h +OLD_FILES+=usr/include/altq/altq_cbq.h +OLD_FILES+=usr/include/altq/altq_rio.h +OLD_DIRS+=usr/include/altq I wonder if changing location of installed header would break some ports. pgpl9qvmrMWql.pgp Description: PGP signature
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
I forward these mails for archives to easier track what was committed for this PR. -- Forwarded message -- From: Jack F Vogel j...@freebsd.org Date: 6 August 2013 22:00 Subject: svn commit: r254002 - head/sys/dev/e1000 To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Author: jfv Date: Tue Aug 6 18:00:53 2013 New Revision: 254002 URL: http://svnweb.freebsd.org/changeset/base/254002 Log: When the igb driver is static there are cases when early interrupts occur, resulting in a panic in refresh_mbufs, to prevent this add a check in the interrupt handler for DRV_RUNNING. MFC after: 1 day (critical for 9.2) Modified: head/sys/dev/e1000/if_igb.c Modified: head/sys/dev/e1000/if_igb.c == --- head/sys/dev/e1000/if_igb.c Tue Aug 6 17:22:06 2013(r254001) +++ head/sys/dev/e1000/if_igb.c Tue Aug 6 18:00:53 2013(r254002) @@ -1572,6 +1572,10 @@ igb_msix_que(void *arg) u32 newitr = 0; boolmore_rx; + /* Ignore spurious interrupts */ + if ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0) + return; + E1000_WRITE_REG(adapter-hw, E1000_EIMC, que-eims); ++que-irqs; -- Forwarded message -- From: Jack F Vogel j...@freebsd.org Date: 7 August 2013 01:16 Subject: svn commit: r254009 - releng/9.2/sys/dev/e1000 To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-rel...@freebsd.org Author: jfv Date: Tue Aug 6 21:16:00 2013 New Revision: 254009 URL: http://svnweb.freebsd.org/changeset/base/254009 Log: When the igb driver is static there are cases when early interrupts occur, resulting in a panic in refresh_mbufs, to prevent this add a check to the interrupt handler for DRV_RUNNING. Approved by: re Modified: releng/9.2/sys/dev/e1000/if_igb.c Directory Properties: releng/9.2/sys/ (props changed) releng/9.2/sys/dev/ (props changed) releng/9.2/sys/dev/e1000/ (props changed) Modified: releng/9.2/sys/dev/e1000/if_igb.c == --- releng/9.2/sys/dev/e1000/if_igb.c Tue Aug 6 21:01:38 2013 (r254008) +++ releng/9.2/sys/dev/e1000/if_igb.c Tue Aug 6 21:16:00 2013 (r254009) @@ -1572,6 +1572,10 @@ igb_msix_que(void *arg) u32 newitr = 0; boolmore_rx; + /* Ignore spurious interrupts */ + if ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0) + return; + E1000_WRITE_REG(adapter-hw, E1000_EIMC, que-eims); ++que-irqs; ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: [RFC] Prune net.inet6.ip6.rr_prune?
On 21 November 2012 22:39, Garrett Cooper yaneg...@gmail.com wrote: While going through the tree trying to document all of our net.inet6 sysctls, I noticed that net.inet6.ip6.rr_prune is defined, but not actually used anywhere in the stack: netinet6/ip6_var.h:VNET_DECLARE(int, ip6_rr_prune); /* router renumbering prefix netinet6/ip6_var.h:#define V_ip6_rr_prune VNET(ip6_rr_prune) netinet6/in6_proto.c:VNET_DEFINE(int, ip6_rr_prune) = 5; /* router renumbering prefix netinet6/in6_proto.c:SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_RR_PRUNE, rr_prune, CTLFLAG_RW, netinet6/in6_proto.c:VNET_NAME(ip6_rr_prune), 0, The knob was declared in r181803 and shuffled around a few times, but isn't in use anywhere (either then or now). Should I send out a PR to remove it (or am I missing some context)? I believe this knob became unused with invalidation of the prefix manipulation mechanism (including prefix or router renumbering, rfc2894) at KAME about 11 years ago. It was intended to schedule in6_rr_timer() callout every ip6_rr_prune seconds to check for expired prefixes and delete the associated addresses from interface. Last bits of old ipv6 prefix management stuff cleaned up in r231229. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: sorele() and ACCEPT_LOCK()
On 30 August 2012 04:23, Vijay Singh vijju.si...@gmail.com wrote:
Is there any reason why sorele() needs the accept lock to be held?
231 #define sorele(so) do {
\
232 ACCEPT_LOCK_ASSERT();
\
233 SOCK_LOCK_ASSERT(so);
\
234 if ((so)-so_count = 0)
\
235 panic(sorele);
\
236 if (--(so)-so_count == 0)
\
237 sofree(so);
\
238 else {
\
239 SOCK_UNLOCK(so);
\
240 ACCEPT_UNLOCK();
\
241 }
\
242 } while (0)
sofree() needs accept lock to be held to operate on a qstate field.
sofree() callers cannot be changed to push accept lock acquisition into
sofree() because that would require to reacquire sock lock around accept
lock to take locks in order; this in turn opens race.
See r136682 for details.
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: netstat: memstat_sysctl_all: Too many CPUs
On 20 March 2012 21:16, Ihsan Junaidi Ibrahim ihsan.juna...@gmail.com wrote: Hi folks, While trying to poke around my mbuf stats, I ran across the following error message. ihsan@sv01:~ $ netstat -m netstat: memstat_sysctl_all: Too many CPUs It's an E3-1230 CPU on a Supermicro X9SCM-F with 4G RAM. I'm on 9.0-RELEASE. Has anybody encountered this before? Well, that means that you are likely running libmemstat(3) library from RELENG_8. This error message (and a reason for it) was removed in 9.0. In 8.x and earlier this error was possible when kernel is compiled with MAXCPU kernel option value greater than 32. If you upgraded to 9.0 from an earlier release than please make sure you have kernel and world in sync. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: crash on lagg interface destroy
On 15 March 2012 02:48, Adarsh Joshi adarsh.jo...@qlogic.com wrote: Hello everyone, I tried to destroy a lagg interface (created using laggproto none) and I see the system crash. Steps to reproduce: Kldload if_lagg Ifconfig lagg0 create ifconfig lagg0 up laggproto none laggport ql0 laggport ql1 192.168.100.1 netmask 255.255.255.0 ifconfig lagg0 destroy uname -a FreeBSD bsd-02 7.4-RELEASE FreeBSD 7.4-RELEASE #0: Wed Mar 7 18:16:06 PST 2012 root@bsd-02:/usr/src/sys/amd64/compile/MYKERNEL amd64 Crash: Tracing command ifconfig pid 1443 tid 100182 td 0xff0023358740 Uart_z8530_class() at 0 Ifc_simple_destroy() at Ifc_simple_destroy+0x2a If_clone_destroyif() at If_clone_destroyif+0xa5 Ifioctl() at ifioctl+0x300 Kern_ioctl() at kern_ioctl+0xa2 Ioctl() at ioctl+0xf9 Syscall() at syscall+0x252 Xfast_syscall() at Xfast_syscall+0xab --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8008324bc, rsp = 0x7fffe348, rbp = 0x7ee27 --- This is just a thought. This thread has probably lost the race when tried to take a valid pointer to ifnet for the given interface using ifunit() function (as done in if_clone_destroyif()) and then is de-referencing a pointer to an already freed memory. Since FreeBSD 8.1 this was changed to use ifunit_ref() to protect ifnet pointer against early destroy by reference counting the ifnet pointer. But this function doesn't exists in 7.x. If this is the case, then this should be easily reproduced when two parallel threads are trying to destroy the cloned interface. So, first I'd try to upgrade to 8.1 or above. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Difference between struct addr and struct addrs
On 6 March 2012 11:08, hiren panchasara hiren.panchas...@gmail.com wrote: On Mon, Mar 5, 2012 at 10:57 PM, Sergey Kandaurov pluk...@gmail.com wrote: struct ifaddr is the in-kernel representation of the interface address. In kernel each network interface consists of a linked list of interface addresses, described by ifaddr structures. See man ifnet(9): http://man.freebsd.org/ifnet struct ifaddrs is used in the userland BSD API getifaddrs(3). This interface is used to get interface addresses in userland programs. See how it is used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c See man getifaddrs(3): http://man.freebsd.org/getifaddrs Thanks Sergey, appreciate your help. Are they connected in any way? Can I get one if I have another? Well, not strictly. getifaddrs() collects addresses on all network interfaces using sysctl interface to the routine table with NET_RT_IFLIST[L] argument. NET_RT_IFLIST[L] does what you would expect: it runs through the linked list of network interfaces and gathers all struct ifaddr on each of them. You can see how that works in /usr/src/sys/net/rtsock.c:sysctl_iflist(). See also man sysctl(3) w.r.t. NET_RT_IFLIST / NET_RT_IFLISTL. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Difference between struct addr and struct addrs
On 6 March 2012 06:05, hiren panchasara hiren.panchas...@gmail.com wrote: What is the difference between following 2 structs? /src/sys/net/if_var.h: struct ifaddr (from the comments seems like it contains a particular address (of probably many) information for an interface.) /src/include/ifaddrs.h: struct ifaddrs struct ifaddr is the in-kernel representation of the interface address. In kernel each network interface consists of a linked list of interface addresses, described by ifaddr structures. See man ifnet(9): http://man.freebsd.org/ifnet struct ifaddrs is used in the userland BSD API getifaddrs(3). This interface is used to get interface addresses in userland programs. See how it is used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c See man getifaddrs(3): http://man.freebsd.org/getifaddrs -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: [PATCH] Use of unreferenced ifa in in6
On 24 December 2011 00:08, John Baldwin j...@freebsd.org wrote:
The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in
in6_lifaddr_ioctl() does not grab a reference to an ifnet address structure
that it uses after dropping the IF_ADDR_LOCK(). Based on other code that uses
a similar pattern of finding an ifa while under the lock and then using it
after dropping the lock, I believe it should be acquiring a reference on the
ifa and then dropping that reference when it is done using the ifa. This
(untested) patch should fix this I believe:
[Some thoughts on this.]
FYI, a similar code exists in in_lifaddr_ioctl() under netinet/ which uses
an unreferenced ifa. Even when ifa reference is acquired, does this protect
ifa internals from concurrent changes? I would additionally lock ifa to
serialize multiple bcopy() operations. To do that, IFA_LOCK/UNLOCK() pair
exists to lock ifa with ifa_mtx. But there is only one place where such
locking is used explicitly. Initially IFA_LOCK/UNLOCK() were introduced in
2002 and used implicitly in IFAREF()/IFAFREE() to lock up ifaddr reference
counts. Two years later ifa_mtx started to be used explicitly in one place
to protect SIOCSIFNAME in net/if.c:ifhwioctl(). In 8.0 they are removed in
favor of refcount(9), and IFAREF/IFAFREE() moved to ifa_ref()/ifa_free(),
and now as said in r194602: The ifa_mtx is now used for exactly one ioctl,
and possibly should be removed.
Now I'm losing the chain, sorry..
Index: in6.c
===
--- in6.c (revision 228777)
+++ in6.c (working copy)
@@ -1767,6 +1767,8 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c
if (IN6_ARE_ADDR_EQUAL(candidate, match))
break;
}
+ if (ifa != NULL)
+ ifa_ref(ifa);
IF_ADDR_UNLOCK(ifp);
if (!ifa)
return EADDRNOTAVAIL;
@@ -1779,16 +1781,20 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c
bcopy(ia-ia_addr, iflr-addr, ia-ia_addr.sin6_len);
error = sa6_recoverscope(
(struct sockaddr_in6 *)iflr-addr);
- if (error != 0)
+ if (error != 0) {
+ ifa_free(ifa);
return (error);
+ }
if ((ifp-if_flags IFF_POINTOPOINT) != 0) {
bcopy(ia-ia_dstaddr, iflr-dstaddr,
ia-ia_dstaddr.sin6_len);
error = sa6_recoverscope(
(struct sockaddr_in6 *)iflr-dstaddr);
- if (error != 0)
+ if (error != 0) {
+ ifa_free(ifa);
return (error);
+ }
} else
bzero(iflr-dstaddr, sizeof(iflr-dstaddr));
@@ -1796,6 +1802,7 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c
in6_mask2len(ia-ia_prefixmask.sin6_addr, NULL);
iflr-flags = ia-ia6_flags; /* XXX */
+ ifa_free(ifa);
return 0;
} else {
@@ -1819,6 +1826,7 @@ in6_lifaddr_ioctl(struct socket *so, u_long cmd, c
ia-ia_prefixmask.sin6_len);
ifra.ifra_flags = ia-ia6_flags;
+ ifa_free(ifa);
return in6_control(so, SIOCDIFADDR_IN6, (caddr_t)ifra,
ifp, td);
}
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: [PATCH] Use of unreferenced ifa in in6
On 4 January 2012 00:17, John Baldwin j...@freebsd.org wrote:
On Tuesday, January 03, 2012 2:36:25 pm Sergey Kandaurov wrote:
On 24 December 2011 00:08, John Baldwin j...@freebsd.org wrote:
The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in
in6_lifaddr_ioctl() does not grab a reference to an ifnet address structure
that it uses after dropping the IF_ADDR_LOCK(). Based on other code that
uses
a similar pattern of finding an ifa while under the lock and then using it
after dropping the lock, I believe it should be acquiring a reference on
the
ifa and then dropping that reference when it is done using the ifa. This
(untested) patch should fix this I believe:
[Some thoughts on this.]
FYI, a similar code exists in in_lifaddr_ioctl() under netinet/ which uses
an unreferenced ifa. Even when ifa reference is acquired, does this protect
ifa internals from concurrent changes? I would additionally lock ifa to
serialize multiple bcopy() operations. To do that, IFA_LOCK/UNLOCK() pair
exists to lock ifa with ifa_mtx. But there is only one place where such
locking is used explicitly. Initially IFA_LOCK/UNLOCK() were introduced in
2002 and used implicitly in IFAREF()/IFAFREE() to lock up ifaddr reference
counts. Two years later ifa_mtx started to be used explicitly in one place
to protect SIOCSIFNAME in net/if.c:ifhwioctl(). In 8.0 they are removed in
favor of refcount(9), and IFAREF/IFAFREE() moved to ifa_ref()/ifa_free(),
and now as said in r194602: The ifa_mtx is now used for exactly one ioctl,
and possibly should be removed.
Now I'm losing the chain, sorry..
Hmm, I'm not sure if ifa objects become immutable or not once they are
referenced in the list. Other places in the code seem to use the ifa
without locking it though, merely obtaining a reference.
Yes, this is a main concern.
The in.c code doesn't even grab the IF_ADDR_LOCK(). :( The below patch
should fix that and add the same fix as done to the in6.c code.
Index: in.c
===
--- in.c (revision 229406)
+++ in.c (working copy)
@@ -784,6 +784,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca
}
}
+ IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link) {
if (ifa-ifa_addr-sa_family != AF_INET6)
continue;
@@ -794,6 +795,9 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca
if (candidate.s_addr == match.s_addr)
break;
}
+ if (ifa != NULL)
+ ifa_ref(ifa);
+ IF_ADDR_UNLOCK(ifp);
if (ifa == NULL)
return (EADDRNOTAVAIL);
ia = (struct in_ifaddr *)ifa;
@@ -812,6 +816,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca
in_mask2len(ia-ia_sockmask.sin_addr);
iflr-flags = 0; /*XXX*/
+ ifa_free(ifa);
return (0);
} else {
@@ -830,6 +835,7 @@ in_lifaddr_ioctl(struct socket *so, u_long cmd, ca
}
bcopy(ia-ia_sockmask, ifra.ifra_dstaddr,
ia-ia_sockmask.sin_len);
+ ifa_free(ifa);
return (in_control(so, SIOCDIFADDR, (caddr_t)ifra,
ifp, td));
With this patch in_lifaddr_ioctl() now looks more syntactically similar
to in6_lifaddr_ioctl(). They could look even more similar by eliminating
a lot of whitespace changes present here or there.
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: i386 compile sys/dev/ie
On 28 December 2011 10:58, Bruce Evans b...@optusnet.com.au wrote: On Wed, 28 Dec 2011, Bruce Evans wrote: On Wed, 28 Dec 2011, Sergey Kandaurov wrote: These were used in probe routine and are left from the newbus rewrite. I hacked ie a bit to build cleanly. [Not sure if I did this correctly.] Use of the __DEVOLATILE() abomination is never correct. It exploits the bug that -Wcast-qual is broken for casts through [u]intptr_t. Agreed. PS: I used to maintain some bad fixes in this area for ie, but now have only the following: % .Index: if_ie.c % .=== % .RCS file: /home/ncvs/src/sys/dev/ie/if_ie.c,v % .retrieving revision 1.99 % .diff -u -2 -r1.99 if_ie.c % .--- if_ie.c 17 Mar 2004 17:50:35 - 1.99 % .+++ if_ie.c 31 May 2004 06:57:05 - % .@@ -159,4 +159,7 @@ % . #define IE_BUF_LEN ETHER_MAX_LEN /* length of transmit buffer */ % . % .+/* XXX this driver uses `volatile' and `caddr_t' to a fault. */ % .+typedef volatile char *v_caddr_t; /* core address, pointer to volatile */ % .+ % . /* Forward declaration */ % . struct ie_softc; Perhaps, it should be finally committed. :) I never allowed the __DEFOO() abominations in my sys/cdefs.h, and at one time had all uses to them in /usr/src removed and ready to commit (there were about 2 of them. There are hundreds if not thousands now :-(). c_caddr_t and v_caddr_t are as abominable as __DEFOO(), so of course I never allowed them in my sys/types.h. But v_caddr_t is still easy to remove, since it is only used in the ie driver. It is used the break warnings from -Wcast-qual that more natural casts would give (but warnings still result from the implicit conversion for bcopy()): % if_ie.c:static v_caddr_t setup_rfa (struct ie_softc *, v_caddr_t); The very idea of a v_caddr_t is nonsense. caddr_t is a bad old type for a core address. In most cases, it means the same as void *, but was used because void * didn't exist. In FreeBSD, it must be precisely char * to work, since pointer arithmetic is perpetrated on it (the pointer arithmetic defeats its opaqueness). In a few cases, it is used for physical or device memory accesses. In must places, it should be spelled void *, and in other places it should be replaced by a vm virtual or physical address type, or a bus space type. To this mess, the ie driver, but mercifully no other code in /usr/src, adds v_caddr_t. caddr_t is supposed to be opaque, but if we just cast to that we will get a cast-qual error if we start with one of ie's excessively qualified pointers. Also, const caddr_t doesn't work since it puts the const in the wrong place. This is solved by looking inside caddr_t to add the const there. ie uses v_caddr_t as follows: First, in the above, some of the excessive qualifiers are in setup_rfa()'s return type and second parameter... % if_ie.c: setup_rfa(sc, (v_caddr_t) sc-rframes[0]); % if_ie.c: setup_rfa(sc, (v_caddr_t) sc-rframes[0]); /* ignore cast-qual */ ... this makes even calling setup_rfa() difficult. We start with a volatile struct ie_mumble **rframes. We can't just cast this to void * or caddr_t since this would cause a -Wcast-qual warning. Casting it to volatile void * would be even worse, since it removes a volatile qualifier that is in the (technically) right place and adds it back in a wrong place. So we use v_caddr_t to keep it in the same place. I should say for above that initially sc-rframes was: volatile struct ie_recv_frame_desc *rframes[MXFRAMES]; as well as its friends rbuffs, cbuffs, etc. Then it was changed to the current volatile ** form, and MXFRAMES was replaced to some dynamic value calculated from rman, so that gives even less chances to fix the ie code properly. /* * based on the amount of memory we have, allocate our tx and rx * resources. */ factor = rman_get_size(sc-mem_res) / 8192; sc-nframes = factor * NFRAMES; sc-nrxbufs = factor * NRXBUFS; sc-ntxbufs = factor * NTXBUFS; /* * Since all of these guys are arrays of pointers, allocate as one * big chunk and dole out accordingly. */ allocsize = sizeof(void *) * (sc-nframes + (sc-nrxbufs * 2) + (sc-ntxbufs * 3)); sc-rframes = (volatile struct ie_recv_frame_desc **) malloc(allocsize, M_DEVBUF, M_NOWAIT); then all these numerous buffs volatile friends point somewhere to this memory by setting its pointer to rframes like. sc-rbuffs = (volatile struct ie_recv_buf_desc **)sc-rframes[sc-nframes]; This prompts me to that the volatile qualifier is probably abused for many sc fields
Re: i386 compile sys/dev/ie
On 27 December 2011 23:45, Sean Bruno sean...@yahoo-inc.com wrote:
Doing a lot of compiles recently and keep noting this noise in
sys/dev/ie:
/dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function
'ieget':
/dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:682: warning:
passing argument 1 of 'bcopy' discards qualifiers from pointer target
type
[snip similar]
These type of errors are because bzero takes a volatile argument but wants
a non-volatile. This can be solved by casting to remove volatile modifier.
/dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: At top level:
/dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1155: warning:
'ee16_read_eeprom' defined but not used
/dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:1097: warning:
'find_ie_mem_size' defined but not used
These were used in probe routine and are left from the newbus rewrite.
I hacked ie a bit to build cleanly. [Not sure if I did this correctly.]
--
wbr,
pluknet
diff -urpN sys/dev/ie.orig/if_ie.c sys/dev/ie/if_ie.c
--- sys/dev/ie.orig/if_ie.c 2011-12-28 02:00:19.0 +0400
+++ sys/dev/ie/if_ie.c 2011-12-28 04:05:36.0 +0400
@@ -169,17 +169,12 @@ static void iestart_locked (struct ifne
static __inline void
ee16_interrupt_enable (struct ie_softc *);
-static void ee16_eeprom_outbits (struct ie_softc *, int, int);
-static void ee16_eeprom_clock (struct ie_softc *, int);
-static u_short ee16_read_eeprom (struct ie_softc *, int);
-static int ee16_eeprom_inbits (struct ie_softc *);
static __inline void
ie_ack (struct ie_softc *, u_int);
static void iereset (struct ie_softc *);
static void ie_readframe (struct ie_softc *, int);
static void ie_drop_packet_buffer (struct ie_softc *);
-static void find_ie_mem_size (struct ie_softc *);
static int command_and_wait (struct ie_softc *,
int, void volatile *, int);
static void run_tdr (struct ie_softc *,
@@ -300,12 +295,12 @@ ie_attach(device_t dev)
}
sc-rbuffs =
(volatile struct ie_recv_buf_desc **)sc-rframes[sc-nframes];
- sc-cbuffs = (volatile u_char **)sc-rbuffs[sc-nrxbufs];
+ sc-cbuffs = __DEVOLATILE(u_char **, sc-rbuffs[sc-nrxbufs]);
sc-xmit_cmds =
(volatile struct ie_xmit_cmd **)sc-cbuffs[sc-nrxbufs];
sc-xmit_buffs =
(volatile struct ie_xmit_buf **)sc-xmit_cmds[sc-ntxbufs];
- sc-xmit_cbuffs = (volatile u_char **)sc-xmit_buffs[sc-ntxbufs];
+ sc-xmit_cbuffs = __DEVOLATILE(u_char **, sc-xmit_buffs[sc-ntxbufs]);
if (bootverbose)
device_printf(sc-dev, hardware type %s, revision %d\n,
@@ -771,7 +766,7 @@ ieget(struct ie_softc *sc, struct mbuf *
if (thislen m-m_len - thismboff) {
int newlen = m-m_len - thismboff;
- bcopy((v_caddr_t) (sc-cbuffs[head] + offset),
+ bcopy(sc-cbuffs[head] + offset,
mtod(m, caddr_t) +thismboff, (unsigned) newlen);
/* ignore cast-qual warning */
m = m-m_next;
@@ -788,7 +783,7 @@ ieget(struct ie_softc *sc, struct mbuf *
* pointers, and so on.
*/
if (thislen m-m_len - thismboff) {
- bcopy((v_caddr_t) (sc-cbuffs[head] + offset),
+ bcopy(sc-cbuffs[head] + offset,
mtod(m, caddr_t) +thismboff, (unsigned) thislen);
thismboff += thislen; /* we are this far into the
* mbuf */
@@ -800,7 +795,7 @@ ieget(struct ie_softc *sc, struct mbuf *
* buffer's contents into the current mbuf. Do the
* combination of the above actions.
*/
- bcopy((v_caddr_t) (sc-cbuffs[head] + offset),
+ bcopy(sc-cbuffs[head] + offset,
mtod(m, caddr_t) + thismboff, (unsigned) thislen);
m = m-m_next;
thismboff = 0; /* new mbuf, start at the beginning */
@@ -846,7 +841,7 @@ ie_readframe(struct ie_softc *sc, int nu
struct ether_header *eh;
#endif
- bcopy((v_caddr_t) (sc-rframes[num]), rfd,
+ bcopy(__DEVOLATILE(caddr_t, sc-rframes[num]), rfd,
sizeof(struct ie_recv_frame_desc));
/*
@@ -936,7 +931,7 @@ iestart_locked(struct ifnet *ifp)
{
struct ie_softc *sc = ifp-if_softc;
struct mbuf *m0, *m;
- volatile unsigned char *buffer;
+ unsigned char *buffer;
u_short len;
/*
@@ -1023,7 +1018,7 @@ check_ie_present(struct ie_softc *sc)
scp = (volatile struct ie_sys_conf_ptr *) (uintptr_t)
(realbase + IE_SCP_ADDR);
- bzero((volatile char *) scp, sizeof *scp);
+ bzero(__DEVOLATILE(void *, scp), sizeof *scp);
/*
* First we put the ISCP at the bottom of memory; this tests to make
@@ -1032,10 +1027,10 @@ check_ie_present(struct ie_softc *sc)
* operation.
*/
iscp = (volatile struct ie_int_sys_conf_ptr *) sc-iomembot;
- bzero((volatile char *)iscp, sizeof *iscp);
+ bzero(__DEVOLATILE(char *, iscp), sizeof *iscp);
scb = (volatile struct ie_sys_ctl_block *) sc-iomembot;
- bzero((volatile char *)scb, sizeof *scb);
+ bzero(__DEVOLATILE(char *, scb), sizeof *scb);
scp-ie_bus_use = sc-bus_use; /* 8-bit or 16-bit */
scp-ie_iscp_ptr = (caddr_t) (uintptr_t)
@@ -1059,7 +1054,7 @@ check_ie_present(struct ie_softc *sc)
iscp = (void *) Align((caddr_t)
Re: [PATCH] Minor fixes to netinet6/icmp6.c
On 25 December 2011 04:58, John Baldwin j...@freebsd.org wrote:
On 12/23/11 6:38 PM, Sergey Kandaurov wrote:
On 23 December 2011 23:46, John Baldwinj...@freebsd.org wrote:
I found these nits while working on the patches to convert if_addr_mtx to
an
rwlock. The first change is cosmetic, it just un-inlines a
TAILQ_FOREACH().
The second change is an actual bug. The code is currently reading
TAILQ_FIRST(V_ifnet) without holding the appropriate lock.
Index: icmp6.c
===
--- icmp6.c (revision 228777)
+++ icmp6.c (working copy)
@@ -1780,7 +1780,7 @@ ni6_addrs(struct icmp6_nodeinfo *ni6, struct mbuf
}
IFNET_RLOCK_NOSLEEP();
- for (ifp = TAILQ_FIRST(V_ifnet); ifp; ifp = TAILQ_NEXT(ifp,
if_list)) {
+ TAILQ_FOREACH(ifp,V_ifnet, if_list) {
addrsofif = 0;
IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifa,ifp-if_addrhead, ifa_link) {
FWIW, there are much more of them in netinet6.
Some time ago I started to un-expand them to queue(3).
[not unfinished yet..]
I went ahead and did a sweep for queue(3) changes in netinet6. I went a bit
Great, thank you! This sweep is long overdue.
further and removed things like the ndpr_next hack, etc. This only includes
queue(3) changes though, not your other fixes like moving common code out of
Oops, yeah. This is an unrelated change.
blocks. I also fixed a few places to use *_EMPTY() instead of checking
*_FIRST() against NULL. There should be no functional change.
http://www.FreeBSD.org/~jhb/patches/inet6_queue.patch
Looks good. Please, commit with two notes:
a) You changed a loop with precondition
while (i DRLSTSIZ) { ... }
into
if (i = DRLSTSIZ)
and moved it below i++ increment, which effectively became
a loop with post-condition like do { ...} while ().
To preserve the current behavior I would move this check up
right under *_FOREACH() loop, like this:
TAILQ_FOREACH(dr, V_nd_defrouter, dr_entry) {
if (i = DRLSTSIZ)
break;
b)
It should be safe to use non-SAFE() FOREACH() variants of
queue(3) macros for most occurrences. SAFE() versions are
usually only used when you need to add/remove an element
on list w/o need to subsequent restart the *_FOREACH() loop.
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: [PATCH] Minor fixes to netinet6/icmp6.c
On 23 December 2011 23:46, John Baldwin j...@freebsd.org wrote:
I found these nits while working on the patches to convert if_addr_mtx to an
rwlock. The first change is cosmetic, it just un-inlines a TAILQ_FOREACH().
The second change is an actual bug. The code is currently reading
TAILQ_FIRST(V_ifnet) without holding the appropriate lock.
Index: icmp6.c
===
--- icmp6.c (revision 228777)
+++ icmp6.c (working copy)
@@ -1780,7 +1780,7 @@ ni6_addrs(struct icmp6_nodeinfo *ni6, struct mbuf
}
IFNET_RLOCK_NOSLEEP();
- for (ifp = TAILQ_FIRST(V_ifnet); ifp; ifp = TAILQ_NEXT(ifp,
if_list)) {
+ TAILQ_FOREACH(ifp, V_ifnet, if_list) {
addrsofif = 0;
IF_ADDR_LOCK(ifp);
TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link) {
FWIW, there are much more of them in netinet6.
Some time ago I started to un-expand them to queue(3).
[not unfinished yet..]
Index: /sys/netinet6/in6_ifattach.c
===
--- /sys/netinet6/in6_ifattach.c(revision 228686)
+++ /sys/netinet6/in6_ifattach.c(working copy)
@@ -405,7 +405,7 @@
/* next, try to get it from some other hardware interface */
IFNET_RLOCK_NOSLEEP();
- for (ifp = V_ifnet.tqh_first; ifp; ifp = ifp-if_list.tqe_next) {
+ TAILQ_FOREACH(ifp, V_ifnet, if_list) {
if (ifp == ifp0)
continue;
if (in6_get_hw_ifid(ifp, in6) != 0)
@@ -820,7 +820,7 @@
/*
* leave from multicast groups we have joined for the interface
*/
- while ((imm = ia-ia6_memberships.lh_first) != NULL) {
+ while ((imm = LIST_FIRST(ia-ia6_memberships)) != NULL) {
LIST_REMOVE(imm, i6mm_chain);
in6_leavegroup(imm);
}
@@ -923,8 +923,7 @@
V_ip6_temp_regen_advance) * hz, in6_tmpaddrtimer, curvnet);
bzero(nullbuf, sizeof(nullbuf));
- for (ifp = TAILQ_FIRST(V_ifnet); ifp;
- ifp = TAILQ_NEXT(ifp, if_list)) {
+ TAILQ_FOREACH(ifp, V_ifnet, if_list) {
ndi = ND_IFINFO(ifp);
if (bcmp(ndi-randomid, nullbuf, sizeof(nullbuf)) != 0) {
/*
Index: /sys/netinet6/icmp6.c
===
--- /sys/netinet6/icmp6.c (revision 228686)
+++ /sys/netinet6/icmp6.c (working copy)
@@ -779,9 +779,8 @@
/* -1 == no app on SEND socket */
if (error == 0)
return (IPPROTO_DONE);
- nd6_rs_input(m, off, icmp6len);
- } else
- nd6_rs_input(m, off, icmp6len);
+ }
+ nd6_rs_input(m, off, icmp6len);
m = NULL;
goto freeit;
}
@@ -793,9 +792,8 @@
if (error == 0)
goto freeit;
/* -1 == no app on SEND socket */
- nd6_rs_input(n, off, icmp6len);
- } else
- nd6_rs_input(n, off, icmp6len);
+ }
+ nd6_rs_input(n, off, icmp6len);
/* m stays. */
break;
@@ -813,9 +811,8 @@
SND_IN, ip6len);
if (error == 0)
return (IPPROTO_DONE);
- nd6_ra_input(m, off, icmp6len);
- } else
- nd6_ra_input(m, off, icmp6len);
+ }
+ nd6_ra_input(m, off, icmp6len);
m = NULL;
goto freeit;
}
@@ -824,9 +821,8 @@
SND_IN, ip6len);
if (error == 0)
goto freeit;
- nd6_ra_input(n, off, icmp6len);
- } else
- nd6_ra_input(n, off, icmp6len);
+ }
+ nd6_ra_input(n, off, icmp6len);
/* m stays. */
break;
@@ -842,9 +838,8 @@
SND_IN, ip6len);
if (error == 0)
return (IPPROTO_DONE);
- nd6_ns_input(m, off, icmp6len);
- } else
- nd6_ns_input(m, off, icmp6len);
+ }
+ nd6_ns_input(m, off, icmp6len);
m = NULL;
goto freeit;
}
@@ -853,9 +848,8 @@
Re: kern/162028: [ixgbe] [patch] misplaced #endif in ixgbe.c
The following reply was made to PR kern/162028; it has been noted by GNATS.
From: Sergey Kandaurov pluk...@gmail.com
To: bug-follo...@freebsd.org, hoomanfaza...@gmail.com
Cc:
Subject: Re: kern/162028: [ixgbe] [patch] misplaced #endif in ixgbe.c
Date: Sat, 29 Oct 2011 16:58:09 +0400
I have a more complete patch. Can you test it please?
Index: sys/dev/ixgbe/ixgbe.c
===
--- sys/dev/ixgbe/ixgbe.c (revision 226068)
+++ sys/dev/ixgbe/ixgbe.c (working copy)
@@ -867,16 +867,15 @@ static int
ixgbe_ioctl(struct ifnet * ifp, u_long command, caddr_t data)
{
struct adapter *adapter = ifp-if_softc;
- struct ifreq*ifr = (struct ifreq *) data;
+ struct ifreq*ifr = (struct ifreq *)data;
#if defined(INET) || defined(INET6)
- struct ifaddr *ifa = (struct ifaddr *)data;
- boolavoid_reset = FALSE;
+ struct ifaddr *ifa = (struct ifaddr *)data;
#endif
- int error = 0;
+ boolavoid_reset = FALSE;
+ int error = 0;
switch (command) {
-
-case SIOCSIFADDR:
+ case SIOCSIFADDR:
#ifdef INET
if (ifa-ifa_addr-sa_family == AF_INET)
avoid_reset = TRUE;
@@ -885,7 +884,6 @@ ixgbe_ioctl(struct ifnet * ifp, u_long command, ca
if (ifa-ifa_addr-sa_family == AF_INET6)
avoid_reset = TRUE;
#endif
-#if defined(INET) || defined(INET6)
/*
** Calling init results in link renegotiation,
** so we avoid doing it when possible.
@@ -894,12 +892,13 @@ ixgbe_ioctl(struct ifnet * ifp, u_long command, ca
ifp-if_flags |= IFF_UP;
if (!(ifp-if_drv_flags IFF_DRV_RUNNING))
ixgbe_init(adapter);
+#ifdef INET
if (!(ifp-if_flags IFF_NOARP))
arp_ifinit(ifp, ifa);
+#endif
} else
error = ether_ioctl(ifp, command, data);
break;
-#endif
case SIOCSIFMTU:
IOCTL_DEBUGOUT(ioctl: SIOCSIFMTU (Set Interface MTU));
if (ifr-ifr_mtu IXGBE_MAX_FRAME_SIZE - ETHER_HDR_LEN) {
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: when enable options SCTP_DEBUG in kernel configure file , where to get the message of debug?
On 30 September 2011 13:48, jyl yilinj...@gmail.com wrote: My Os is FreeBSD 9.0 Beta2. In kernel configure file, I enable the option of SCTP_DEBUG and rebuild the kernel. Then I use sctp to send or recv data from another computer ,after that I check the result from var/log/message or var/log/dmesg , both of the two files show any message about sctp debug. can anyone help me, why it does not work? Hi, you probably also need to actually enable it. Try this: sysctl net.inet.sctp.debug = 1 -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: LOR in route.c // scope6.c
On 19 August 2011 05:07, Garrett Cooper yaneg...@gmail.com wrote: Hi, I've periodically seen the following LOR when trying to repro a panic after restarting my network configuration: :lock order reversal: 1st 0xc4142f1c rtentry (rtentry) @ /usr/src/sys/net/routec:362 2nd 0xc3d08604 if_afdata (if_afdata) @ /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(...) _witness_debugger(...) _rw_wlock(...) in6_setscope(...) in6_purgeaddr(...) in6_control(...) ifioctl(...) soo_ioctl(...) kern_ioctl(...) ioctl(...) syscallenter(...) syscall(...) Xint0x80_syscall() I don't have a full backtrace or core for this. This was running r224948 UP with WITNESS. I just got exactly the same LOR on a very fresh current with /etc/rc.d/netif restart, and then I lost the system. Thanks for the report. I hope to dig out the solution... -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Usage of IFQ_DEQUEUE vs IFQ_DRV_DEQUEUE
On 24 August 2011 22:12, Patrick Mahan ma...@mahan.org wrote: Can somebody confirm my assumption on the following: If I am supporting ALTQ in a driver, then I should use the IFQ_DRV_DEQUEUE() macro. If I am not supporting ALTQ then it is okay IFQ_DEQUEUE() macro? If not what's the difference? Slightly confused... Just in case, have you read man 9 altq? It has a good description of these macros. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: BETA1 IPv6 crash
On 8 August 2011 22:06, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote: 2011/8/7 Sergey Kandaurov pluk...@gmail.com: On 7 August 2011 17:11, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote: I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the new installer. Major issue I noticed was the missing /home. It took me quite some time to get IPv6 working in the guest (a Linux configuration issue), but now that it works BETA1 panics in about 50% of the boot attempts: testbsd dumped core - see /var/crash/vmcore.0 Sun Aug 7 08:25:28 CEST 2011 FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... [..] panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 cpuid = 0 KDB: enter: panic Uptime: 28s Physical memory: 491 MB Dumping 45 MB: 30 14 #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc0a04965 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:430 #2 0xc0a04291 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc09f4a4a in _mtx_lock_sleep (m=0xc35f3a28, tid=3278693824, opts=0, file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676) at /usr/src/sys/kern/kern_mutex.c:341 #4 0xc09f4c67 in _mtx_lock_flags (m=0xc35f3a28, opts=0, file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676) at /usr/src/sys/kern/kern_mutex.c:203 #5 0xc0bbf007 in mld_set_version (mli=0xc3589a00, version=Variable version is not available. ) at /usr/src/sys/netinet6/mld6.c:1676 #6 0xc0bc0c00 in mld_input (m=0xc3951e00, off=48, icmp6len=24) at /usr/src/sys/netinet6/mld6.c:690 #7 0xc0ba5696 in icmp6_input (mp=0xc3313a54, offp=0xc3313a68, proto=58) at /usr/src/sys/netinet6/icmp6.c:654 #8 0xc0bba23a in ip6_input (m=0xc3951e00) at /usr/src/sys/netinet6/ip6_input.c:964 #9 0xc0ac9b1c in netisr_dispatch_src (proto=10, source=0, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1013 #10 0xc0ac9da0 in netisr_dispatch (proto=10, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1104 #11 0xc0abecf1 in ether_demux (ifp=0xc35f3800, m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:936 #12 0xc0abf1b3 in ether_nh_input (m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:755 #13 0xc0ac9b1c in netisr_dispatch_src (proto=9, source=0, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1013 #14 0xc0ac9da0 in netisr_dispatch (proto=9, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1104 #15 0xc0abe7f5 in ether_input (ifp=0xc35f3800, m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:796 #16 0xc0672bc9 in lem_handle_rxtx (context=0xc3732000, pending=1) at /usr/src/sys/dev/e1000/if_lem.c:3554 #17 0xc0a468ab in taskqueue_run_locked (queue=0xc359ca80) at /usr/src/sys/kern/subr_taskqueue.c:306 #18 0xc0a47307 in taskqueue_thread_loop (arg=0xc37365ec) at /usr/src/sys/kern/subr_taskqueue.c:495 #19 0xc09d7af8 in fork_exit (callout=0xc0a472a0 taskqueue_thread_loop, arg=0xc37365ec, frame=0xc3313d28) at /usr/src/sys/kern/kern_fork.c:941 #20 0xc0d1d714 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) This is the same as in PR kern/158426. Can you try the patch from PR followup and report us whether it helps? Full link to PR with patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/158426 I applied the patch and tried about 15 reboots and all went fine Hi, Tom. A better fix for this problem has been developed since then. Would you please try it as well? For doing that, you need to revert a previous patch and apply this one. Please report if this change also fixes the panic for you, so it has better chances to get into 9.0 release. Index: sys/netinet6/mld6.c === --- sys/netinet6/mld6.c (revision 224471) +++ sys/netinet6/mld6.c (working copy) @@ -680,7 +680,6 @@ mld_v1_input_query(struct ifnet *ifp, const struct IN6_MULTI_LOCK(); MLD_LOCK(); - IF_ADDR_LOCK(ifp); /* * Switch to MLDv1 host compatibility mode. @@ -693,6 +692,7 @@ mld_v1_input_query(struct ifnet *ifp, const struct if (timer == 0) timer = 1; + IF_ADDR_LOCK(ifp); if (is_general_query
Re: BETA1 IPv6 crash
On 7 August 2011 17:11, Tom Vijlbrief tom.vijlbr...@xs4all.nl wrote: I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the new installer. Major issue I noticed was the missing /home. It took me quite some time to get IPv6 working in the guest (a Linux configuration issue), but now that it works BETA1 panics in about 50% of the boot attempts: testbsd dumped core - see /var/crash/vmcore.0 Sun Aug 7 08:25:28 CEST 2011 FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... [..] panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 cpuid = 0 KDB: enter: panic Uptime: 28s Physical memory: 491 MB Dumping 45 MB: 30 14 #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc0a04965 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:430 #2 0xc0a04291 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc09f4a4a in _mtx_lock_sleep (m=0xc35f3a28, tid=3278693824, opts=0, file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676) at /usr/src/sys/kern/kern_mutex.c:341 #4 0xc09f4c67 in _mtx_lock_flags (m=0xc35f3a28, opts=0, file=0xc0f1ab65 /usr/src/sys/netinet6/mld6.c, line=1676) at /usr/src/sys/kern/kern_mutex.c:203 #5 0xc0bbf007 in mld_set_version (mli=0xc3589a00, version=Variable version is not available. ) at /usr/src/sys/netinet6/mld6.c:1676 #6 0xc0bc0c00 in mld_input (m=0xc3951e00, off=48, icmp6len=24) at /usr/src/sys/netinet6/mld6.c:690 #7 0xc0ba5696 in icmp6_input (mp=0xc3313a54, offp=0xc3313a68, proto=58) at /usr/src/sys/netinet6/icmp6.c:654 #8 0xc0bba23a in ip6_input (m=0xc3951e00) at /usr/src/sys/netinet6/ip6_input.c:964 #9 0xc0ac9b1c in netisr_dispatch_src (proto=10, source=0, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1013 #10 0xc0ac9da0 in netisr_dispatch (proto=10, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1104 #11 0xc0abecf1 in ether_demux (ifp=0xc35f3800, m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:936 #12 0xc0abf1b3 in ether_nh_input (m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:755 #13 0xc0ac9b1c in netisr_dispatch_src (proto=9, source=0, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1013 #14 0xc0ac9da0 in netisr_dispatch (proto=9, m=0xc3951e00) at /usr/src/sys/net/netisr.c:1104 #15 0xc0abe7f5 in ether_input (ifp=0xc35f3800, m=0xc3951e00) at /usr/src/sys/net/if_ethersubr.c:796 #16 0xc0672bc9 in lem_handle_rxtx (context=0xc3732000, pending=1) at /usr/src/sys/dev/e1000/if_lem.c:3554 #17 0xc0a468ab in taskqueue_run_locked (queue=0xc359ca80) at /usr/src/sys/kern/subr_taskqueue.c:306 #18 0xc0a47307 in taskqueue_thread_loop (arg=0xc37365ec) at /usr/src/sys/kern/subr_taskqueue.c:495 #19 0xc09d7af8 in fork_exit (callout=0xc0a472a0 taskqueue_thread_loop, arg=0xc37365ec, frame=0xc3313d28) at /usr/src/sys/kern/kern_fork.c:941 #20 0xc0d1d714 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) This is the same as in PR kern/158426. Can you try the patch from PR followup and report us whether it helps? Full link to PR with patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/158426 -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: bin/136661: [patch] ndp(8) ignores -f option
The following reply was made to PR bin/136661; it has been noted by GNATS. From: Sergey Kandaurov pluk...@gmail.com To: bug-follo...@freebsd.org, melif...@ipfw.ru Cc: Subject: Re: bin/136661: [patch] ndp(8) ignores -f option Date: Fri, 29 Jul 2011 14:47:28 +0400 The '-f' argument parsing was (accidentally?) removed with KAME sync in 2003. make command line argument parsing POSIX compliant. http://svn.freebsd.org/changeset/base/122615 http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/ndp/ndp.c#rev1.92 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/158873: When I launch pf daemon, I have a kernel panic
The following reply was made to PR kern/158873; it has been noted by GNATS. From: Sergey Kandaurov pluk...@gmail.com To: bug-follo...@freebsd.org, gobl...@gmail.com Cc: Subject: Re: kern/158873: When I launch pf daemon, I have a kernel panic Date: Wed, 13 Jul 2011 23:50:24 +0400 I think we need to merge net/if_pfsync.c 1.113 from vendor. Below is a more complete crash info. panic: _mtx_lock_sleep: recursed on non-recursive mutex pf task mtx @ /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:3163 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x802db93a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x8047f407 = kdb_backtrace+0x37 panic() at 0x80448017 = panic+0x187 _mtx_lock_sleep() at 0x80437513 = _mtx_lock_sleep+0x343 _mtx_lock_flags() at 0x8043768c = _mtx_lock_flags+0x16c pfsync_send_plus() at 0x81072eda = pfsync_send_plus+0xaa pfsync_clear_states() at 0x81072ffe = pfsync_clear_states+0x6e pfioctl() at 0x8106024b = pfioctl+0x1c0b devfs_ioctl_f() at 0x803c442a = devfs_ioctl_f+0x7a kern_ioctl() at 0x8049984e = kern_ioctl+0xbe ioctl() at 0x80499aed = ioctl+0xfd syscallenter() at 0x8048e30b = syscallenter+0x1cb syscall() at 0x806bd630 = syscall+0x60 Xfast_syscall() at 0x806a853d = Xfast_syscall+0xdd --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800da70ac, rsp = 0x7fffd528, rbp = 0 --- KDB: enter: panic [ thread pid 48453 tid 100192 ] Stopped at 0x8047f01b = kdb_enter+0x3b:movq $0,0x6eeb82(%rip) -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks
The following reply was made to PR kern/152036; it has been noted by GNATS. From: Sergey Kandaurov pluk...@gmail.com To: bug-follo...@freebsd.org, kby...@gmail.com Cc: Subject: Re: kern/152036: [libc] getifaddrs(3) returns truncated sockaddrs for netmasks Date: Mon, 11 Jul 2011 17:59:47 +0400 [Some thoughts and testing...] This is rather a kernel bug, i.e. this is not a getifaddrs() bug. This is confirmed by (undocumented) ioctl SIOCGIFNETMASK. I found that the bug is manifested for ip4, and not for lladdr, ipv6. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/158426: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676
The following reply was made to PR kern/158426; it has been noted by GNATS. From: Sergey Kandaurov pluk...@gmail.com To: bug-follo...@freebsd.org, t...@vr-web.de Cc: Subject: Re: kern/158426: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 Date: Thu, 30 Jun 2011 15:54:33 +0400 --0016e64aefda827b7b04a6ec9043 Content-Type: text/plain; charset=ISO-8859-1 The problem is that locking scope in MDL6 code is too wide. That results in that mld_set_version() is called with if_addr_mtx held, and then mld_set_version() locks it itself once again. Please try this patch (attached). -- wbr, pluknet --0016e64aefda827b7b04a6ec9043 Content-Type: text/plain; charset=US-ASCII; name=mld6.locking.txt Content-Disposition: attachment; filename=mld6.locking.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_gpjnoi020 SW5kZXg6IHN5cy9uZXRpbmV0Ni9tbGQ2LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQ2L21s ZDYuYwkocmV2aXNpb24gMjIzMDczKQorKysgc3lzL25ldGluZXQ2L21sZDYuYwkod29ya2luZyBj b3B5KQpAQCAtNjgwLDcgKzY4MCw2IEBACiAKIAlJTjZfTVVMVElfTE9DSygpOwogCU1MRF9MT0NL KCk7Ci0JSUZfQUREUl9MT0NLKGlmcCk7CiAKIAkvKgogCSAqIFN3aXRjaCB0byBNTER2MSBob3N0 IGNvbXBhdGliaWxpdHkgbW9kZS4KQEAgLTcwMCw2ICs2OTksNyBAQAogCQkgKi8KIAkJQ1RSMihL VFJfTUxELCAicHJvY2VzcyB2MSBnZW5lcmFsIHF1ZXJ5IG9uIGlmcCAlcCglcykiLAogCQkgICAg aWZwLCBpZnAtPmlmX3huYW1lKTsKKwkJSUZfQUREUl9MT0NLKGlmcCk7CiAJCVRBSUxRX0ZPUkVB Q0goaWZtYSwgJmlmcC0+aWZfbXVsdGlhZGRycywgaWZtYV9saW5rKSB7CiAJCQlpZiAoaWZtYS0+ aWZtYV9hZGRyLT5zYV9mYW1pbHkgIT0gQUZfSU5FVDYgfHwKIAkJCSAgICBpZm1hLT5pZm1hX3By b3Rvc3BlYyA9PSBOVUxMKQpAQCAtNzA3LDYgKzcwNyw3IEBACiAJCQlpbm0gPSAoc3RydWN0IGlu Nl9tdWx0aSAqKWlmbWEtPmlmbWFfcHJvdG9zcGVjOwogCQkJbWxkX3YxX3VwZGF0ZV9ncm91cChp bm0sIHRpbWVyKTsKIAkJfQorCQlJRl9BRERSX1VOTE9DSyhpZnApOwogCX0gZWxzZSB7CiAJCS8q CiAJCSAqIE1MRHYxIEdyb3VwLVNwZWNpZmljIFF1ZXJ5LgpAQCAtNzI0LDcgKzcyNSw2IEBACiAJ CWluNl9jbGVhcnNjb3BlKCZtbGQtPm1sZF9hZGRyKTsKIAl9CiAKLQlJRl9BRERSX1VOTE9DSyhp ZnApOwogCU1MRF9VTkxPQ0soKTsKIAlJTjZfTVVMVElfVU5MT0NLKCk7CiAKQEAgLTg4OCw3ICs4 ODgsNiBAQAogCiAJSU42X01VTFRJX0xPQ0soKTsKIAlNTERfTE9DSygpOwotCUlGX0FERFJfTE9D SyhpZnApOwogCiAJbWxpID0gTUxEX0lGSU5GTyhpZnApOwogCUtBU1NFUlQobWxpICE9IE5VTEws ICgiJXM6IG5vIG1sZF9pZmluZm8gZm9yIGlmcCAlcCIsIF9fZnVuY19fLCBpZnApKTsKQEAgLTk2 NCw3ICs5NjMsNiBAQAogCX0KIAogb3V0X2xvY2tlZDoKLQlJRl9BRERSX1VOTE9DSyhpZnApOwog CU1MRF9VTkxPQ0soKTsKIAlJTjZfTVVMVElfVU5MT0NLKCk7CiAK --0016e64aefda827b7b04a6ec9043-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ifa_add_loopback_route: insertion failed with ifconfig wlan0 up
On 8 April 2011 18:10, Dominique Goncalves dominique.goncal...@gmail.com wrote: Hi 2011/4/6 Sergey Kandaurov pluk...@gmail.com: On 6 April 2011 11:35, Dominique Goncalves dominique.goncal...@gmail.com wrote: Hi, I've installed FreeBSD 8.2-RELEASE on soekris net4801 with Atheros 9280 (mini pci card) as an access point using hostapd, so far it works . Sometimes I need to disable wireless with ifconfig wlan0 down but each times I run ifconfig wlan0 up, the kernel produces this error ifa_add_loopback_route: insertion failed is this a problem ? or maybe there is a better way to disable/enable wireless ? I see this too with a dumb test: vlan5: flags=8003UP,BROADCAST,MULTICAST metric 0 mtu 1500 ether 00:00:00:00:00:00 inet6 fe80::21a:64ff:fe68:d005%vlan5 prefixlen 64 scopeid 0xa inet 192.168.13.13 netmask 0x broadcast 192.168.13.13 nd6 options=3PERFORMNUD,ACCEPT_RTADV vlan: 0 parent interface: none On 8.1 ifconfig vlan5 up gives: ifa_add_loopback_route: insertion failed I guess I need to submit a PR. What step did you used to reproduce the problem ? I tried (on 8.2) to create a vlan but was not able to reproduce the error. Here it is. # ifconfig vlan5 create # ifconfig vlan5 192.168.13.16/32 # ifconfig vlan5 down # ifconfig vlan5 up -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ifa_add_loopback_route: insertion failed with ifconfig wlan0 up
On 6 April 2011 11:35, Dominique Goncalves dominique.goncal...@gmail.com wrote: Hi, I've installed FreeBSD 8.2-RELEASE on soekris net4801 with Atheros 9280 (mini pci card) as an access point using hostapd, so far it works . Sometimes I need to disable wireless with ifconfig wlan0 down but each times I run ifconfig wlan0 up, the kernel produces this error ifa_add_loopback_route: insertion failed is this a problem ? or maybe there is a better way to disable/enable wireless ? I see this too with a dumb test: vlan5: flags=8003UP,BROADCAST,MULTICAST metric 0 mtu 1500 ether 00:00:00:00:00:00 inet6 fe80::21a:64ff:fe68:d005%vlan5 prefixlen 64 scopeid 0xa inet 192.168.13.13 netmask 0x broadcast 192.168.13.13 nd6 options=3PERFORMNUD,ACCEPT_RTADV vlan: 0 parent interface: none On 8.1 ifconfig vlan5 up gives: ifa_add_loopback_route: insertion failed On head ifconfig vlan5 down gives: interface address is missing from cache = 0 in delete -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ifa_add_loopback_route: insertion failed with ifconfig wlan0 up
On 6 April 2011 15:05, Sergey Kandaurov pluk...@gmail.com wrote: On 6 April 2011 11:35, Dominique Goncalves dominique.goncal...@gmail.com wrote: Hi, I've installed FreeBSD 8.2-RELEASE on soekris net4801 with Atheros 9280 (mini pci card) as an access point using hostapd, so far it works . Sometimes I need to disable wireless with ifconfig wlan0 down but each times I run ifconfig wlan0 up, the kernel produces this error ifa_add_loopback_route: insertion failed is this a problem ? or maybe there is a better way to disable/enable wireless ? I see this too with a dumb test: vlan5: flags=8003UP,BROADCAST,MULTICAST metric 0 mtu 1500 ether 00:00:00:00:00:00 inet6 fe80::21a:64ff:fe68:d005%vlan5 prefixlen 64 scopeid 0xa inet 192.168.13.13 netmask 0x broadcast 192.168.13.13 nd6 options=3PERFORMNUD,ACCEPT_RTADV vlan: 0 parent interface: none On 8.1 ifconfig vlan5 up gives: ifa_add_loopback_route: insertion failed On head ifconfig vlan5 down gives: interface address is missing from cache = 0 in delete On more thing: on head ifconfig vlan5 destroy gives: if_delmulti_ifma: ifnet 0xfe006b38c000 disappeared -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: panic in dummynet
On 21 March 2011 12:43, Sergey Kandaurov pluk...@gmail.com wrote: Hi. This is a 8.1 box, not very much loaded. It has two simple dummynet rules. That's the first time it panics there. Any hints? db x/s *panicstr 0: *** error reading from address 0 *** db bt Tracing pid 0 tid 100116 td 0xff000ab057c0 m_copym() at m_copym+0x37 ip_fragment() at ip_fragment+0x132 ip_output() at ip_output+0xeef dummynet_send() at dummynet_send+0x14c dummynet_task() at dummynet_task+0x1b7 taskqueue_run() at taskqueue_run+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8399222d30, rbp = 0 --- Hmm.. Another crash today. Looks like it might be due to race with bce intr handler. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80611587 stack pointer = 0x28:0xff82b41da960 frame pointer = 0x28:0xff82b41da9c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (dummynet) db bt Tracing pid 0 tid 100121 td 0xff00094177c0 m_copym() at m_copym+0x37 ip_fragment() at ip_fragment+0x132 ip_output() at ip_output+0xeef dummynet_send() at dummynet_send+0x14c dummynet_task() at dummynet_task+0x1b7 taskqueue_run() at taskqueue_run+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff82b41dad30, rbp = 0 --- cpuid= 0 curthread= 0xff00094177c0: pid 0 dummynet cpuid= 1 curthread= 0xff00029a23e0: pid 12 irq257: bce1 cpuid= 2 curthread= 0xff00026fc3e0: pid 12 swi4: clock 100039 Run CPU 1 [irq257: bce1] 100038 RunQ[irq256: bce0] 100012 Run CPU 2 [swi4: clock] db bt 100039 Tracing pid 12 tid 100039 td 0xff00029a23e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x175 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0x805c62e4, rsp = 0xff852fe0, rbp = 0xf f82b155d7b0 --- callout_lock() at callout_lock+0x54 callout_reset_on() at callout_reset_on+0x43 tcp_do_segment() at tcp_do_segment+0x508 tcp_input() at tcp_input+0xd22 ip_input() at ip_input+0xad netisr_dispatch_src() at netisr_dispatch_src+0x7e ether_demux() at ether_demux+0x14d ether_input() at ether_input+0x17b ether_demux() at ether_demux+0x6f ether_input() at ether_input+0x17b bce_intr() at bce_intr+0x3b0 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff82b155dd30, rbp = 0 --- db bt 100038 Tracing pid 12 tid 100038 td 0xff00029a27c0 sched_switch() at sched_switch+0xea mi_switch() at mi_switch+0x16f ithread_loop() at ithread_loop+0x1d0 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff82b1554d30, rbp = 0 --- db bt 100012 Tracing pid 12 tid 100012 td 0xff00026fc3e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x175 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0x808a8270, rsp = 0xff859fe0, rbp = 0xff8c9bd0 --- Xinvlpg() at Xinvlpg ithread_loop() at ithread_loop+0x142 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8c9d30, rbp = 0 --- -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
panic in dummynet
Hi. This is a 8.1 box, not very much loaded. It has two simple dummynet rules. That's the first time it panics there. Any hints? db x/s *panicstr 0: *** error reading from address 0 *** db bt Tracing pid 0 tid 100116 td 0xff000ab057c0 m_copym() at m_copym+0x37 ip_fragment() at ip_fragment+0x132 ip_output() at ip_output+0xeef dummynet_send() at dummynet_send+0x14c dummynet_task() at dummynet_task+0x1b7 taskqueue_run() at taskqueue_run+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8399222d30, rbp = 0 --- -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ifconfig lo1 down
On 5 March 2011 21:43, fredrik danerklint fre...@fredan.se wrote: Hi, I would like to know what is the differents between ip4 and ip6 for this command. First: #ifconfig lo1 lo1: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet xx.xx.xx.2 netmask 0x inet6 2a03:::::xx02 prefixlen 128 nd6 options=3PERFORMNUD,ACCEPT_RTADV $ ping xx.xx.xx.2 PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes 64 bytes from xx.xx.xx.2: icmp_seq=0 ttl=64 time=0.012 ms 64 bytes from xx.xx.xx.2: icmp_seq=1 ttl=64 time=0.010 ms ^C and $ ping6 2a03:::::xx02 PING6(56=40+8+8 bytes) 2a03:::::xx02 -- 2a03:::::xx02 16 bytes from 2a03:::::xx02, icmp_seq=0 hlim=64 time=0.053 ms 16 bytes from 2a03:::::xx02, icmp_seq=1 hlim=64 time=0.032 ms ^C Now we run this command: # ifconfig lo1 down and trying to ping again: $ ping xx.xx.xx.2 PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ^C --- xx.xx.xx.2 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss works as expected (and this is what I want) but this command, however: $ ping6 2a03:::::xx02 PING6(56=40+8+8 bytes) 2a03:::::xx02 -- 2a03:::::xx02 16 bytes from 2a03:::::xx02, icmp_seq=0 hlim=64 time=0.048 ms 16 bytes from 2a03:::::xx02, icmp_seq=1 hlim=64 time=0.033 ms 16 bytes from 2a03:::::xx02, icmp_seq=2 hlim=64 time=0.032 ms ^C --- 2a03:::::xx02 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.032/0.038/0.048/0.007 ms My question is why is it not the same behavior of ip6 as of ip4? That's how forwarding works/differs for ipv4 and ipv6. You should be able to ping xx.xx.xx.2 again after adding static route. Something like route add xx.xx.xx.2 -iface -lo1. I can only say for the moment that from my observation ipv4 routes to itself exist as far as interface is up, and ipv6 routes don't depend on if iface is up. You can check this with netstat -r for both addresses with iface up and down. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
arpintr()-in_lltable_lookup() 8.1 bce(4) crash
Hi. That's the second crash on 8.1. A previous one was month ago on another box. They are almost identical. Kernel can't dump core on these disk controllers. Any hints are appreciated. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor read data, page not present instruction pointer = 0x20:0x805f30d2 stack pointer = 0x28:0xff82b1554890 frame pointer = 0x28:0xff82b15548c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 12 (irq256: bce0) db bt Tracing pid 12 tid 100038 td 0xff00029a17c0 propagate_priority() at propagate_priority+0x72 turnstile_wait() at turnstile_wait+0x1aa _rw_wlock_hard() at _rw_wlock_hard+0xfa in_lltable_lookup() at in_lltable_lookup+0x12b arpintr() at arpintr+0x9d6 netisr_dispatch_src() at netisr_dispatch_src+0x7e ether_demux() at ether_demux+0x14d ether_input() at ether_input+0x17b bce_intr() at bce_intr+0x3b0 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff82b1554d30, rbp = 0 --- kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0xc fault code = supervisor read data, page not present instruction pointer = 0x20:0x805f30c2 stack pointer = 0x28:0xff82b155d830 frame pointer = 0x28:0xff82b155d860 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 12 (irq257: bce1) db bt Tracing pid 12 tid 100039 td 0xff00029a23e0 propagate_priority() at propagate_priority+0x72 turnstile_wait() at turnstile_wait+0x1aa _rw_wlock_hard() at _rw_wlock_hard+0xfa in_lltable_lookup() at in_lltable_lookup+0x12b arpintr() at arpintr+0x9d6 netisr_dispatch_src() at netisr_dispatch_src+0x7e ether_demux() at ether_demux+0x14d ether_input() at ether_input+0x17b ether_demux() at ether_demux+0x6f ether_input() at ether_input+0x17b bce_intr() at bce_intr+0x3b0 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff82b155dd30, rbp = 0 --- That's what was on another CPUs atm, if that matters: db show proc 12 Process 12 (intr) at 0xff00026e7000: state: NORMAL uid: 0 gids: 0 parent: pid 0 at 0x80c7e3e0 ABI: null threads: 24 100065 I [irq1: atkbd0] 100064 I [swi0: uart uart] 100063 I [irq15: ata1] 100062 I [irq14: ata0] 100045 I [irq22: uhci1 uhci3] 100040 I [irq23: uhci0 uhci2+] 100039 L *lle 0xff032af863c0 [irq257: bce1] 100038 I [irq256: bce0] 100036 I [irq17: aac0] 100035 I [irq9: acpi0] 100034 I [swi5: +] 100032 I [swi2: cambio] 100028 I [swi6: task queue] 100027 I [swi6: Giant taskq] 100020 I [swi3: vm] 100019 Run CPU 1 [swi4: clock] 100018 Run CPU 5 [swi4: clock] 100017 Run CPU 6 [swi4: clock] 100016 I [swi4: clock] 100015 Run CPU 3 [swi4: clock] 100014 I [swi4: clock] 100013 CanRun [swi4: clock] 100012 I [swi4: clock] 100011 I [swi1: netisr 0] db show allpcpu Current CPU: 2 cpuid= 0 dynamic pcpu= 0x2a3f80 curthread= 0xff0061aca000: pid 52989 httpd curpcb = 0xff82b7e2fd40 fpcurthread = none idlethread = 0xff00026ea7c0: pid 11 idle: cpu0 curpmap
Re: rtadvd and carp
On 1 March 2011 02:28, User Red35 re...@zyni.com wrote: I am getting started with IPv6 and I am trying to get rtadvd working on the carp interface but it is not working so far. ### I have carp failover between two firewalls. The default gateway for ### hosts internal to the firewall is 172.31.98.103 for IPv4 ### and 2001:470:dead:98::103 for IPv6 # ifconfig carp1 carp1: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 172.31.98.103 netmask 0x inet6 2001:470:dead:98::103 prefixlen 64 nd6 options=3PERFORMNUD,ACCEPT_RTADV carp: MASTER vhid 1 advbase 1 advskew 60 # ### rtadvd does not work since carp1 does not have a link local address # rtadvd -f -D carp1 rtadvd[13262]: make_packet link-layer address option has null length on carp1. Treat as not included. rtadvd[13262]: ra_timer_update RA timer on carp1 is set to 16:0 rtadvd[13262]: sock_open IPV6_JOIN_GROUP(link) on carp1: Can't assign requested address # ### Per RFC 4861 Router advertisements are supposed to use ### link-local addresses... carp does not have one. ### ### http://tools.ietf.org/html/rfc4861#page-39 ### Section 6.1.2 IP Source Address is a link-local address. Routers must use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers. ### Is it possible to manually add the link-local address to a carp interface via ifconfig (or other utility)? I assume given the carp MAC 00:00:5e:00:01:01 the link-local address would look like this? fe80::200:5eff:fe00:101 Has anyone got anything similar working? I'm afraid you need to specify carpdev for the carp interface to manage this work. As far as I know, FreeBSD doesn't support carpdev (yet). -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: svn commit: r218741 - head/sys/netinet/ipfw
On 16 February 2011 18:43, Sergey Kandaurov pluk...@freebsd.org wrote:
Author: pluknet
Date: Wed Feb 16 15:43:35 2011
New Revision: 218741
URL: http://svn.freebsd.org/changeset/base/218741
Log:
Bump dummynet module version to meet dummynet schedulers' requirements,
and thus unbreak loading dummynet.ko via /boot/loader.conf.
Hi there.
Just a brief note that I'm going to merge it to stable/8.
What scares me is that it may cause some disruption due
to the change of module version on a stable branch.
On the order side, nothing depends on it in the base.
luigi@ cc:'ed as I'd like to know his opinion.
Reported by: rihad rihad att mail.ru on freebsd-net
Approved by: kib (mentor)
Modified:
head/sys/netinet/ipfw/ip_dummynet.c
Modified: head/sys/netinet/ipfw/ip_dummynet.c
==
--- head/sys/netinet/ipfw/ip_dummynet.c Wed Feb 16 15:27:54 2011
(r218740)
+++ head/sys/netinet/ipfw/ip_dummynet.c Wed Feb 16 15:43:35 2011
(r218741)
@@ -2294,7 +2294,7 @@ static moduledata_t dummynet_mod = {
#define DN_MODEV_ORD (SI_ORDER_ANY - 128) /* after ipfw */
DECLARE_MODULE(dummynet, dummynet_mod, DN_SI_SUB, DN_MODEV_ORD);
MODULE_DEPEND(dummynet, ipfw, 2, 2, 2);
-MODULE_VERSION(dummynet, 1);
+MODULE_VERSION(dummynet, 3);
/*
* Starting up. Done in order after dummynet_modevent() has been called.
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: cannot set mtu 1500 on em0 optical Gig-E
On 10 February 2011 21:49, Jay Borkenhagen j...@braeburn.org wrote: Hi, For quite a while now it appears that mtu on my gigabit ethernet fiber em0 cards cannot be configured higher than the default 1500 bytes. Here's what I get when I attempt to set it lower and higher on a brand new 8.2-RC3 box: === sandbox# uname -v FreeBSD 8.2-RC3 #0: Sun Jan 30 06:52:51 UTC 2011 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sandbox# sandbox# ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=18VLAN_MTU,VLAN_HWTAGGING ether 00:d0:b7:7c:f8:01 inet 10.1.2.3 netmask 0xff00 broadcast 10.1.2.255 media: Ethernet autoselect status: no carrier sandbox# ifconfig em0 mtu 1499 sandbox# ifconfig em0 | grep mtu em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1499 sandbox# ifconfig em0 mtu 1501 ifconfig: ioctl (set mtu): Invalid argument sandbox# ifconfig em0 | grep mtu em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1499 sandbox# ifconfig em0 mtu 1500 sandbox# ifconfig em0 | grep mtu em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 sandbox# sandbox# pciconf -lv | sed -n '/em0@/,/em1/p' em0@pci0:0:2:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class = network subclass = ethernet em1@pci0:0:4:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x03 hdr=0x00 sandbox# === However, back in the 6.2 days it allowed it: === [jayb@cactus ~]$ uname -v FreeBSD 6.2-PRERELEASE #0: Tue Dec 26 16:53:18 EST 2006 r...@cactus.iplabs.att.com:/usr/obj/usr/src/sys/CACTUS [jayb@cactus ~]$ [jayb@cactus ~]$ ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=8VLAN_MTU inet 10.0.1.152 netmask 0xfffc broadcast 10.0.1.155 ether 00:90:27:e3:0a:67 media: Ethernet autoselect status: no carrier [jayb@cactus ~]$ [jayb@cactus ~]$ sudo ifconfig em0 mtu 9000 [jayb@cactus ~]$ ifconfig em0 | grep mtu em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 9000 [jayb@cactus ~]$ [jayb@cactus ~]$ pciconf -lv | sed -n '/em0@/,/none0@/p' em0@pci0:2:0: class=0x02 card=0x10008086 chip=0x10008086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82542 Gigabit Ethernet Controller' class = network subclass = ethernet none0@pci0:4:0: class=0x088000 card=0x0767101e chip=0x9063101e rev=0x04 hdr=0x00 [jayb@cactus ~]$ Hmm.. Did jumbo frames really work on these cards for you? Intel claims: Adapters based on the Intel® 82542 and 82573V/E controller do not support Jumbo Frames. These correspond to the following product names: * Intel® PRO/1000 Gigabit Server Adapter * Intel® PRO/1000 PM Network Connection As seen from code, the behavior was changed to match the description (keep old 82542 from using jumbo frames) and merged to 6-STABLE before 6.3. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Slow Intel 10GbE CX4 adapter behaviour
On 9 February 2011 12:37, rihad ri...@mail.ru wrote: Problem solved, I'm so embarrassed :) The issue on 7.2 mentioned above with ixgbe (tons of fragmentation failed errors) was real. The issue in 8.3-RC3 was because dummynet wasn't being loaded at all... so no traffic could pass on it, despite dummynet_load=YES being set in /boot/loader.conf. So I turned it on in /etc/rc.conf : dummynet_enable=YES and loaded it kldload dummynet in order to do without a reboot. Works like a charm so far. Thanks to all! Looks like loading dummynet.ko via /boot/loader.conf doesn't work because dummynet.ko depends on dummynet.ko but of the different version. There are even more strange things: 1) dummynet.ko declares itself as version 1: /sys/netinet/ipfw/ip_dummynet.c: MODULE_VERSION(dummynet, 1); 2) dummynet.ko compiles into itself the various schedulers: fifo, prio, rr, etc; 3) these schedulers presumably think they are compiled standalone, so they are explicitly and strongly depend on dummynet of version 3 (why?): /sys/netinet/ipfw/dn_sched.h: MODULE_DEPEND(name, dummynet, 3, 3, 3); * That makes loader to error like dummynet: loading required module 'dummynet'. and, if loading dummynet.ko in loader prompt manually, then module 'dummynet' exists but with wrong version] This shall fix the problem: rebuilding only dummynet should be enough. %%% Index: /sys/netinet/ipfw/ip_dummynet.c === --- /sys/netinet/ipfw/ip_dummynet.c (revision 218026) +++ /sys/netinet/ipfw/ip_dummynet.c (working copy) @@ -2294,7 +2294,7 @@ #defineDN_MODEV_ORD(SI_ORDER_ANY - 128) /* after ipfw */ DECLARE_MODULE(dummynet, dummynet_mod, DN_SI_SUB, DN_MODEV_ORD); MODULE_DEPEND(dummynet, ipfw, 2, 2, 2); -MODULE_VERSION(dummynet, 1); +MODULE_VERSION(dummynet, 3); /* * Starting up. Done in order after dummynet_modevent() has been called. %%% -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Slow Intel 10GbE CX4 adapter behaviour
On 9 February 2011 18:15, rihad ri...@mail.ru wrote: On 02/09/2011 05:47 PM, Sergey Kandaurov wrote: On 9 February 2011 12:37, rihadri...@mail.ru wrote: Problem solved, I'm so embarrassed :) The issue on 7.2 mentioned above with ixgbe (tons of fragmentation failed errors) was real. The issue in 8.3-RC3 was because dummynet wasn't being loaded at all... so no traffic could pass on it, despite dummynet_load=YES being set in /boot/loader.conf. So I turned it on in /etc/rc.conf : dummynet_enable=YES and loaded it kldload dummynet in order to do without a reboot. Works like a charm so far. Thanks to all! Looks like loading dummynet.ko via /boot/loader.conf doesn't work because dummynet.ko depends on dummynet.ko but of the different version. Would dummynet_enable=YES in rc.conf still work? We haven't yet had a chance to reboot to test that. Yes, it would. Note that it depends on firewall_enable=YES also present in rc.conf. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Current state of FreeBSD routing
On 2 February 2011 02:11, Markus Oestreicher m...@x-trader.de wrote: Hi there! After a few hours of reading list archives and source code I need some clarification on the current state of FreeBSD forwarding capabilities. Given the following setup: - Quad Core CPU - Intel 82576 NIC (igb) - 8.2-RELEASE - Router with BGP full table 1) Queues: Card and driver seem to have support for multiple TX/RX queues. How many cores will it use for RX / TX per NIC? That depends on how many cpu cores you have. e.g. with several 82576 NICs installed I have 8 queues per each port. So it looks like # vmstat -ia | grep igb7 irq320: igb7:que 0 0 0 irq321: igb7:que 1 0 0 irq322: igb7:que 2 0 0 irq323: igb7:que 3 0 0 irq324: igb7:que 4 0 0 irq325: igb7:que 5 0 0 irq326: igb7:que 6 0 0 irq327: igb7:que 7 0 0 irq328: igb7:link 0 0 With Quad Core CPU you will have 4 queues. 2) Fastforwarding vs multiple netisr: In the past (6.x) using fastforwarding=1 was the best option for dedicated routers. I found multiple netisr added to 8.0. Can that help with routing on multiple cores? Any experience from using it in production? 3) lagg: I found lagg(4) mostly mentioned on home user setups. Any experience with using lagg in high-pps environments? (100k pps) Will lagg play nicely together with multiple netisr routing or fastforwarding? How much overhead will it add versus a single connection? Thanks a lot Markus -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: NDP Ethernet address display
On 8 January 2011 03:26, Boris Kochergin sp...@acm.poly.edu wrote:
Hi. I noticed that ndp(8) doesn't zero-pad Ethernet addresses, which is
inconsistent with arp(8):
# ndp -an
...
2001:470:897b::1 0:30:48:b1:1b:9c em0 permanent R
# arp -an
...
? (128.238.9.201) at 00:30:48:b1:1b:9c on em0 permanent [ethernet]
As everything else I can think of zero-pads them, this makes it a little
annoying to grep for addresses, etc. Is this intentional? It is the case in
7.x through CURRENT and the fix is quite simple:
--- /usr/src/usr.sbin/ndp/ndp.c.orig 2011-01-07 19:16:17.0 -0500
+++ /usr/src/usr.sbin/ndp/ndp.c 2011-01-07 19:15:36.0 -0500
@@ -828,7 +828,7 @@
if (sdl-sdl_alen) {
cp = (u_char *)LLADDR(sdl);
- snprintf(hbuf, sizeof(hbuf), %x:%x:%x:%x:%x:%x,
+ snprintf(hbuf, sizeof(hbuf),
%02x:%02x:%02x:%02x:%02x:%02x,
cp[0], cp[1], cp[2], cp[3], cp[4], cp[5]);
} else
snprintf(hbuf, sizeof(hbuf), (incomplete));
Or rather use getnameinfo() for that as NetBSD/KAME does, and
NetBSD's getnameinfo() AF_LINK support was merged at 6.3 time.
(See ndp.c#rev1.87 at KAME, ndp.c#rev1.35 at NetBSD).
--
wbr,
pluknet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: [PATCH] Netdump for review and testing -- preliminary version
[just don't know what namely need to test, so] All made according to your instructions. The only way I could trigger netdump was to run its ddb command by hand. Neither debug.kdb.enter nor debug.kdb.panic don't do it. Some numbers and output (bit verbose but again don't know what need to show here) Entered through debug.kdb.panic, thus Panicstring. db netdump --- netdump in progress. searching for server.. dumping to xx.xxx.xx.xx (00:1a:64:d3:4f:20) --- Physical memory: 2026 MB Dumping 1154 MB: 1139 1123 1107 1091 1075 1059 1043 1027 1011 995 979 963 947 931 915 899 883 867 851 835 819 803 787 771 755 739 723 707 691 675 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 Dump complete netdump finished. cancelling normal dump # ls -hl /home/fooserv/crash/ total 1182930 -rw-r--r-- 1 root wheel 404B Sep 29 12:05 info.fooserv.0 -rw-r--r-- 1 root wheel 1.1G Sep 29 12:05 vmcore.fooserv.0 Dump from fooserv [xx.xxx.xx.xx] Architecture: amd64 Architecture version: 2 Dump length: 1210687488B (1154 MB) blocksize: 8192 Dumptime: Wed Sep 29 11:55:30 2010 Hostname: fooserv Versionstring: FreeBSD 9.0-CURRENT #51: Wed Sep 29 07:18:24 UTC 2010 r...@fooserv:/usr/obj/usr/src/sys/GENERIC Panicstring: kdb_sysctl_panic Header parity check: Pass Dump complete I tried to netdump a bit later again, but it couldn't find server, which runs though, and client traffic was seen on server-side (w/o reply). db netdump --- netdump in progress. searching for server.. . . . . . . . . . . . Failed to contact netdump server As for netdumpserv, it misses #include sys/cdefs.h before __FBSDID(); I happily tested it on 7.3-amd64. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
