From owner-freebsd-net@FreeBSD.ORG Sun Aug 1 02:49:18 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 195B01065670; Sun, 1 Aug 2010 02:49:18 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id EC5088FC14; Sun, 1 Aug 2010 02:49:17 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o712nGOF049844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 31 Jul 2010 19:49:16 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o712nGge049843; Sat, 31 Jul 2010 19:49:16 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA13209; Sat, 31 Jul 10 19:37:47 PDT Date: Sat, 31 Jul 2010 19:37:39 -0700 From: perryh@pluto.rain.com To: fli@shapeshifter.se Message-Id: <4c54ddf3.dbUwkfoxXwnHLLQz%perryh@pluto.rain.com> References: <201007311310.o6VDA3S6082887@freefall.freebsd.org> In-Reply-To: <201007311310.o6VDA3S6082887@freefall.freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org, freebsd-net@freebsd.org, pilzableiter@web.de, bug-followup@freebsd.org Subject: Re: usb/149039: [uhso] Binding problem with uhso X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 02:49:18 -0000 > The following reply was made to PR usb/149039; it has been noted > by GNATS. > > From: Fredrik Lindberg > To: bug-followup@FreeBSD.org, pilzableiter@web.de > Cc: Hans Petter Selasky > Subject: Re: usb/149039: [uhso] Binding problem with uhso > Date: Sat, 31 Jul 2010 15:00:07 +0200 > > I apparently missed some interface flags (that really doesn't make > sense for this device, it's configured with a /32 mask so broadcast > etc can only be to itself) that the network stack wants to work > properly. Is a /32 mask even legal? Unless there's a special case involved, it ought to mean that there are no interfaces on the subnet other than this one, thus this interface has no peer to communicate with and might as well not exist. Adding net@ in hopes someone there knows what should happen. From owner-freebsd-net@FreeBSD.ORG Sun Aug 1 17:14:29 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AA581065674; Sun, 1 Aug 2010 17:14:29 +0000 (UTC) (envelope-from jilles@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF198FC17; Sun, 1 Aug 2010 17:14:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o71HETDP063834; Sun, 1 Aug 2010 17:14:29 GMT (envelope-from jilles@freefall.freebsd.org) Received: (from jilles@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o71HESwo063830; Sun, 1 Aug 2010 17:14:28 GMT (envelope-from jilles) Date: Sun, 1 Aug 2010 17:14:28 GMT Message-Id: <201008011714.o71HESwo063830@freefall.freebsd.org> To: yaharen@gm.dns-lab.jp, jilles@FreeBSD.org, freebsd-net@FreeBSD.org From: jilles@FreeBSD.org Cc: Subject: Re: bin/132911: ip6fw(8): argument type of fill_icmptypes is wrong and causes problem on amd64 platform X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 17:14:29 -0000 Synopsis: ip6fw(8): argument type of fill_icmptypes is wrong and causes problem on amd64 platform State-Changed-From-To: feedback->open State-Changed-By: jilles State-Changed-When: Sun Aug 1 17:13:28 UTC 2010 State-Changed-Why: Feedback has been received. However, note that ip6fw has been deprecated in recent FreeBSD versions. http://www.freebsd.org/cgi/query-pr.cgi?pr=132911 From owner-freebsd-net@FreeBSD.ORG Mon Aug 2 02:23:28 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC0F4106566C; Mon, 2 Aug 2010 02:23:28 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B357A8FC14; Mon, 2 Aug 2010 02:23:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o722NS7V093956; Mon, 2 Aug 2010 02:23:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o722NSe2093952; Mon, 2 Aug 2010 02:23:28 GMT (envelope-from linimon) Date: Mon, 2 Aug 2010 02:23:28 GMT Message-Id: <201008020223.o722NSe2093952@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 02:23:29 -0000 Old Synopsis: [rum] panic in rum(4) driver on 8.1-R New Synopsis: [rum] [panic] panic in rum(4) driver on 8.1-R Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 2 02:23:08 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149185 From owner-freebsd-net@FreeBSD.ORG Mon Aug 2 05:57:48 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C9CF106566C; Mon, 2 Aug 2010 05:57:48 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D7DA48FC0C; Mon, 2 Aug 2010 05:57:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o725vlLf002069; Mon, 2 Aug 2010 05:57:47 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o725vlao002065; Mon, 2 Aug 2010 05:57:47 GMT (envelope-from brucec) Date: Mon, 2 Aug 2010 05:57:47 GMT Message-Id: <201008020557.o725vlao002065@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/148862: [panic] page fault while in kernel mode at _mtx_lock_sleep X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 05:57:48 -0000 Synopsis: [panic] page fault while in kernel mode at _mtx_lock_sleep Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Aug 2 05:57:21 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148862 From owner-freebsd-net@FreeBSD.ORG Mon Aug 2 06:54:39 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24044106566B; Mon, 2 Aug 2010 06:54:39 +0000 (UTC) (envelope-from fli@shapeshifter.se) Received: from mx1.h3q.net (mx1.h3q.net [IPv6:2001:16d8:ffe5:1::f1]) by mx1.freebsd.org (Postfix) with ESMTP id D80928FC1C; Mon, 2 Aug 2010 06:54:38 +0000 (UTC) Received: from smtp-auth.h3q.net (smtp-auth.h3q.net [127.0.0.1]) (Authenticated sender: hidden) by mx1.h3q.net (Postfix) with ESMTPSA id 6381833D11 ; Mon, 2 Aug 2010 08:54:37 +0200 (CEST) Message-ID: <4C566B94.5090405@shapeshifter.se> Date: Mon, 02 Aug 2010 08:54:12 +0200 From: Fredrik Lindberg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <201007311310.o6VDA3S6082887@freefall.freebsd.org> <4c54ddf3.dbUwkfoxXwnHLLQz%perryh@pluto.rain.com> In-Reply-To: <4c54ddf3.dbUwkfoxXwnHLLQz%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org, freebsd-net@freebsd.org, pilzableiter@web.de, bug-followup@freebsd.org Subject: Re: usb/149039: [uhso] Binding problem with uhso X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 06:54:39 -0000 On 08/01/2010 04:37 AM, perryh@pluto.rain.com wrote: >> The following reply was made to PR usb/149039; it has been noted >> by GNATS. >> >> From: Fredrik Lindberg >> To: bug-followup@FreeBSD.org, pilzableiter@web.de >> Cc: Hans Petter Selasky >> Subject: Re: usb/149039: [uhso] Binding problem with uhso >> Date: Sat, 31 Jul 2010 15:00:07 +0200 >> >> I apparently missed some interface flags (that really doesn't make >> sense for this device, it's configured with a /32 mask so broadcast >> etc can only be to itself) that the network stack wants to work >> properly. > > Is a /32 mask even legal? Unless there's a special case involved, > it ought to mean that there are no interfaces on the subnet other > than this one, thus this interface has no peer to communicate with > and might as well not exist. > > Adding net@ in hopes someone there knows what should happen. > Yes, technically a /32 mask defines only one single address, but it's the only mask that really makes sense for this device. /32 masks are "legal" and commonly used for the loopback address of routers. But this is is indeed a very special case. The device has a USB interface that accepts raw IP-packets (with no other encapsulation). Once you have told the device to connect, it will tell you what IP-address you have and what DNS-servers to use, but that's it. My best guess is that the devices does PPP internally in firmware and abstracts the point-to-point link with a IP-packet interface. But since none of these details are available the only (as far as I know) viable thing is to set a /32 mask and set 0.0.0.0 (default route) to be directly reachable through the interface (route add -interface). Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Mon Aug 2 09:11:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D53106564A for ; Mon, 2 Aug 2010 09:11:47 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BF8278FC17 for ; Mon, 2 Aug 2010 09:11:46 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 08CB773098; Mon, 2 Aug 2010 11:22:07 +0200 (CEST) Date: Mon, 2 Aug 2010 11:22:07 +0200 From: Luigi Rizzo To: Patrick Mahan Message-ID: <20100802092207.GC2054@onelab2.iet.unipi.it> References: <4C535B18.8020205@mahan.org> <20100730233053.GA12554@onelab2.iet.unipi.it> <4C544ADC.2050109@mahan.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C544ADC.2050109@mahan.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: AltQ throughput issues (long message) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 09:11:47 -0000 On Sat, Jul 31, 2010 at 09:10:04AM -0700, Patrick Mahan wrote: ... > >part of it can be explained because AltQ counts the whole packet > >(eg. 1514 bytes for a full frame) whereas iperf only considers the > >UDP payload (e.g. 1470 bytes in your case). > > > > Okay, but that only accounts for 3% and I am seeing around 11%, any > idea what might be accounting for the remaining 8%? no, sometimes the extra icmp traffic plays a role, sometimes it is just the shaper that is not precise and has systematic errors (due to rounding in computing intervals and delays). I cannot comment precisely on AltQ because i don't know enough about its internals. > >The other thing you should check is whether there is any extra > >traffic going through the interface that competes for the bottleneck > >bandwidth. You have such huge drop rates in your tests that i > >would not be surprised if you had ICMP packets going around > >trying to slow down the sender. ... > Where do you see the drop? If you are looking at the end of the pfctl iperf reports show that it is dropping tons of packets (see below, Lost/Total) > >>npx8# iperf -c 172.16.13.10 -p 7788 -u -b 25M -u -i 30 -t 200 > >>------------------------------------------------------------ > >>Client connecting to 172.16.13.60, UDP port 7788 > >>Sending 1470 byte datagrams > >>UDP buffer size: 9.00 KByte (default) > >>------------------------------------------------------------ > >>[ 3] local 172.16.13.60 port 7788 connected with 172.16.38.80 port 41064 > >>[ ID] Interval Transfer Bandwidth Jitter Lost/Total > >>Datagrams > >>[ 3] 0.0-30.0 sec 5.96 MBytes 1.67 Mbits/sec 0.710 ms 59453/63706 > >>(93%) > >>[ ID] Interval Transfer Bandwidth Jitter Lost/Total > >>Datagrams > >>[ 3] 30.0-60.0 sec 5.95 MBytes 1.66 Mbits/sec 0.736 ms 59616/63859 > >>(93%) > > > >BTW have you tried dummynet in your config? > > > > How would you suggest using dummynet? Is it workable for a QoS solution? Very workable. see http://info.iet.unipi.it/~luigi/dummynet/ especially the video/slides at the top of the page. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Aug 2 09:42:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A018D1065670 for ; Mon, 2 Aug 2010 09:42:10 +0000 (UTC) (envelope-from mail@vas.org.ua) Received: from relay.electro.ua (electro.ua [213.186.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 610128FC0A for ; Mon, 2 Aug 2010 09:42:10 +0000 (UTC) Received: from [172.20.254.182] (gw.umc.com.ua [80.255.64.5]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by relay.electro.ua (Postfix) with ESMTPSA id 4CC22170B0 for ; Mon, 2 Aug 2010 12:22:46 +0300 (EEST) Message-ID: <4C568E4B.5070508@vas.org.ua> Date: Mon, 02 Aug 2010 12:22:19 +0300 From: Vasily Samoilov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: LLDP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 09:42:10 -0000 Hello. Do anyone knows any way to recieve (not send) LLDP (CDP, etc) packets from other networking hardware and query neighbour discovery results from FreeBSD box via snmp? Thanks in advance! From owner-freebsd-net@FreeBSD.ORG Mon Aug 2 11:07:06 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B182E106566C for ; Mon, 2 Aug 2010 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9DD728FC17 for ; Mon, 2 Aug 2010 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o72B7653035171 for ; Mon, 2 Aug 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o72B75er035169 for freebsd-net@FreeBSD.org; Mon, 2 Aug 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Aug 2010 11:07:05 GMT Message-Id: <201008021107.o72B75er035169@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 11:07:06 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/149185 net [rum] [panic] panic in rum(4) driver on 8.1-R o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148807 net [panic] 8.1-RELEASE "panic: sbdrop" and "panic: sbsndp o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148155 net [vimage] Kernel panic with PF/IPFilter + VIMAGE kernel o kern/148112 net [ath] Atheros 9285 cannot register with wifi AP (timeo o kern/148108 net [bge] FreeBSD 7.2 or 8.0 does not recognize, 4.11 can o kern/148078 net [ath] wireless networking stops functioning o kern/148004 net [em] Inconsistent networking with em driver on FreeBSD o kern/147989 net [em] em Receive errors / CRC Errors / Alignment Errors o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147824 net [msk]: watchdog timeouts & Tx descriptor error o kern/147684 net [nfe] nVidia MCP55 driver blocks IPMI LAN on load o kern/147352 net [netinet] [patch] replace printf() with log() for "Lim o kern/147245 net [dummynet] dummynet skip traffic over configured limit o kern/147155 net [ip6] setfb not work with ipv6 o kern/146909 net [rue] rue(4) does not detect OQO model01 network contr o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146628 net [tcp] [patch] TCP does not clear DF when MTU is below o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146263 net [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/ o kern/146250 net [netinet] [patch] Races on interface alias removal o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to o kern/144561 net [ixgbe] [patch] ixgbe driver errors f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140597 net [netinet] [patch] implement Lost Retransmission Detect o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137145 net [mbuf] [patch] Reference count computing isn't correct o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/81095 net IPsec connection stops working if associated network i o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 436 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 2 16:06:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4F1106566C for ; Mon, 2 Aug 2010 16:06:25 +0000 (UTC) (envelope-from jdixon@omniti.com) Received: from edge.omniti.com (smtp.omniti.com [8.8.38.6]) by mx1.freebsd.org (Postfix) with ESMTP id DE8D88FC2E for ; Mon, 2 Aug 2010 16:06:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; d=omniti.com; s=s1024; c=relaxed/relaxed; q=dns/txt; i=@omniti.com; t=1280765184; h=From:Subject:Date:To; bh=ZBUdPoTkYjXTQ+PfVQi4OWGgYV50VdOXaTT+oMwJw5E=; b=Wi3v4XNiMHV3UQ/VofOgOH4ckAC+MRXoOtTGjsJq6LngyDlr7j+5v+VjgZILy6jf nCBHu6LIy6wWuF5W1lajkAGt/Zesgybfkt4SzA9QaiCKOY+FsfTeVbA0P84b9/ns QAEMc9uFoSRX7YkRJAHzPAlKuh3wdA7ynf8KueraQ54=; Authentication-Results: edge smtp.user=jdixon@omniti.com; auth=pass (LOGIN) Received: from [68.55.0.29] ([68.55.0.29:57765] helo=omniti.com) by edge (envelope-from ) (ecelerity 2.2.3.46 r(37468M)) with ESMTPSA (cipher=AES256-SHA) id EE/F9-03560-00DE65C4; Mon, 02 Aug 2010 12:06:24 -0400 Date: Mon, 2 Aug 2010 12:06:20 -0400 From: Jason Dixon To: freebsd-net@freebsd.org Message-ID: <20100802160620.GS4578@omniti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Register now for Surge 2010 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 16:06:25 -0000 Registration for Surge Scalability Conference 2010 is open for all attendees! We have an awesome lineup of leaders from across the various communities that support highly scalable architectures, as well as the companies that implement them. Here's a small sampling from our list of speakers: John Allspaw, Etsy Theo Schlossnagle, OmniTI Rasmus Lerdorf, creator of PHP Tom Cook, Facebook Benjamin Black, fast_ip Artur Bergman, Wikia Christopher Brown, Opscode Bryan Cantrill, Joyent Baron Schwartz, Percona Paul Querna, Cloudkick Surge 2010 focuses on real case studies from production environments; the lessons learned from failure and how to re-engineer your way to a successful, highly scalable Internet architecture. The conference takes place at the Tremont Grand Historic Venue on Sept 30 and Oct 1, 2010 in Baltimore, MD. Register now to enjoy the Early Bird discount and guarantee your seat to this year's event! http://omniti.com/surge/2010/register Thanks, -- Jason Dixon OmniTI Computer Consulting, Inc. jdixon@omniti.com 443.325.1357 x.241 From owner-freebsd-net@FreeBSD.ORG Mon Aug 2 16:52:18 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21942106564A for ; Mon, 2 Aug 2010 16:52:18 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id CB84B8FC15 for ; Mon, 2 Aug 2010 16:52:17 +0000 (UTC) Received: from iad-wprd-xchw02.corp.verio.net (iad-wprd-xchw02.corp.verio.net [198.87.7.165]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 8BAD5B038127 for ; Mon, 2 Aug 2010 12:52:16 -0400 (EDT) Thread-Index: AcsyYxAIxtEl9eFxQ9meKcbbEIxUnQ== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.2.52]) by iad-wprd-xchw02.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 12:52:15 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Mon, 02 Aug 2010 11:52:14 -0500 Content-Transfer-Encoding: 7bit Date: Mon, 2 Aug 2010 11:52:14 -0500 From: "David DeSimone" Content-class: urn:content-classes:message To: Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Message-ID: <20100802165213.GD6052@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20100730181035.GI5168@verio.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100730181035.GI5168@verio.net> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 02 Aug 2010 16:52:15.0168 (UTC) FILETIME=[0F65EC00:01CB3263] Subject: Re: Kernel (7.3) crash due to mbuf leak? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 16:52:18 -0000 I will try asking this question again: Can anyone give me some pointers as to how I can analyze these crashdumps, or my running system, to determine what network subsystem is leaking these mbuf's? Before I start sifting through C code, I was wondering, does the mbuf subsystem have a built-in means of tracking which other subsystems are requesting memory, so that perhaps a clever gdb script can build a histogram of which subsystems are consuming large amounts of mbuf's? This would give me a pointer in the right direction to start investigating the cause of the leak. David DeSimone wrote: > > After upgrading a couple of our systems from 7.2-RELEASE to 7.3-RELEASE, > we have started to see them running out of mbuf's and crashing every > month or so. The panic string is: > > kmem_malloc(16384): kmem_map too small: 335233024 total allocated > > The actual panic signature (backtrace) shows a memory allocation failure > occurring in the filesystem code, but I do not think that is where the > problem lies. Instead, it is clear to me that the system is slowly > leaking mbuf's until there is no more kernel memory available, and the > filesystem is just the innocent bystander asking for memory and failing > to get it. > > Here's some netstat -m output on a couple of crashes: > > fs0# netstat -m -M vmcore.0 > > 882167/2902/885069 mbufs in use (current/cache/total) > 351/2041/2392/25600 mbuf clusters in use (current/cache/total/max) > 351/1569 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/199/199/12800 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) > 221249K/5603K/226853K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Aug 3 02:32:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E8941065670 for ; Tue, 3 Aug 2010 02:32:26 +0000 (UTC) (envelope-from drsweetlips@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5D8C78FC0A for ; Tue, 3 Aug 2010 02:32:26 +0000 (UTC) Received: by yxe42 with SMTP id 42so1832208yxe.13 for ; Mon, 02 Aug 2010 19:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=AFzcjoB4yVVuxeE+YUpPbOsda2+fC/kY2bhMvh/dbmY=; b=M1Oyqsj2ayLMWcGXQ6NT5DCEIRKZOHJ7aAMCKOxBKwEvLUrzYa65L+XorDg/D38AAC MruGOlR1znrbyvkoo5G9ZXzaSiyTp0Mynprbw2NRREc1PozQoaZ3Cj1tywQE112/j0vM m6Yr8LPnFJquZkgMyKlom2QEKxrESuEqNrJ0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=lxO5NQJgyqsDUG5JgJ/jJe1kfYBZSSZWb/ypr07/iw4CjolfFiNdvO9PVLcgMv4wTC yTvqkZRKLqKzzTvXkUetkjqCQGlizMKPBAksLNwk3b6gOFfVtkcunNBfr8YBsL5ySuRq Lo859c77vJg98Nw/Rle3KX89BnXEd0VJUY8y8= MIME-Version: 1.0 Received: by 10.150.202.9 with SMTP id z9mr7723382ybf.86.1280801179152; Mon, 02 Aug 2010 19:06:19 -0700 (PDT) Received: by 10.150.181.8 with HTTP; Mon, 2 Aug 2010 19:06:19 -0700 (PDT) Date: Mon, 2 Aug 2010 22:06:19 -0400 Message-ID: From: Troye Johnson To: freebsd-net@freebsd.org X-Mailman-Approved-At: Tue, 03 Aug 2010 03:17:06 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 02:32:26 -0000 Well, it's obvious that this list needs to be whittled down. First step, prune the erroneous. Second step, prioritize the remaining and fix the most important. Third step, create a program to teach n00bs how to write device drivers. From owner-freebsd-net@FreeBSD.ORG Tue Aug 3 08:36:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 516E6106566C for ; Tue, 3 Aug 2010 08:36:56 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id A73828FC19 for ; Tue, 3 Aug 2010 08:36:55 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 3A0727E8CE; Tue, 3 Aug 2010 18:19:50 +1000 (EST) Message-ID: <4C57D125.3010706@swin.edu.au> Date: Tue, 03 Aug 2010 18:19:49 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100726 Thunderbird/3.0.6 MIME-Version: 1.0 To: iccrg@cs.ucl.ac.uk, end2end-interest@postel.org, freebsd-net@freebsd.org, tmrg-interest@ICSI.Berkeley.EDU, ledbat@ietf.org, multipathtcp@ietf.org, tcpm@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: David Hayes , grenville armitage Subject: Software for FreeBSD TCP R&D X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 08:36:56 -0000 Hi all, (apologies for any duplicates you receive and please trim the CC list appropriately if you reply to this email) We're pleased to announce the release of a substantial set of new and updated BSD licenced software for TCP experimentation and research using FreeBSD: - "CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 (new) - "Hamilton Delay" Congestion Control Algorithm v0.2 (update) - Vegas Congestion Control Algorithm v0.2 (update) - H-TCP Congestion Control Algorithm v0.12 (update) - CUBIC Congestion Control Algorithm v0.10 (update) - Statistical Information For TCP Research (SIFTR) v1.2.3 (update) - Enhanced Round Trip Time (ERTT) Khelp Module v0.2 (update) - Khelp Framework for FreeBSD v0.1.1 (update) - Modular TCP Congestion Control for FreeBSD v0.10.0 (update) A more detailed summary of the various tools/patches is included at the end of this email. Everything mentioned above along with other papers, patches and software relevant/useful for protocol analysis, debugging and experimental research is available from: http://caia.swin.edu.au/urp/newtcp/tools.html The software was developed as part of the NewTCP research project at Swinburne University's Centre for Advanced Internet Architectures, made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. Testing and development was further assisted by a grant from the FreeBSD Foundation. We welcome any feedback and hope you enjoy playing with the code and tools. Cheers, Lawrence Stewart, David Hayes and Grenville Armitage http://caia.swin.edu.au NB: "CAIA-Hamilton Delay" and "Hamilton Delay" are our working names for algorithms which do not have established names in the literature. "CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 [1,2] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements an experimental delay based congestion control algorithm proposed by the Hamilton Institute [3] but with modifications made by CAIA [4]. It builds on Hamilton's initial proposal by adding tolerance to non-congestion related losses and still aims to allow delay- and loss-based algorithms to fairly coexist. "Hamilton Delay" Congestion Control Algorithm v0.2 [5,6] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements an experimental delay based congestion control algorithm proposed by the Hamilton Institute [3]. It provides a first step toward the ability of delay based algorithms to fairly coexist with loss based algorithms. Vegas Congestion Control Algorithm v0.2 [7,8] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the Vegas delay-based congestion control algorithm [9]. H-TCP Congestion Control Algorithm v0.12 [10,11] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the H-TCP loss based TCP congestion control algorithm [12]. CUBIC Congestion Control Algorithm v0.10 [13,14] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the CUBIC loss based TCP congestion control algorithm [15]. CUBIC is the current default algorithm used by Linux. Statistical Information For TCP Research (SIFTR) v1.2.3 [16,17] ---------------------------------------------------------------------- A FreeBSD 6/7/8/9 kernel module that logs a range of statistics on active TCP connections to a log file. It provides the ability to make highly granular measurements of TCP connection state, aimed at system administrators, developers and researchers. NB: SIFTR has been imported into FreeBSD's "head" svn branch (a.k.a. 9-CURRENT) as revision 209662 and will be backported to 8-STABLE in time for 8.2-RELEASE. Enhanced Round Trip Time (ERTT) Khelp Module v0.2 [18,19] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that provides enhanced RTT measurements for use by delay and rate based TCP congestion control algorithms. Robust estimates of RTT are provided even when the receiver uses delayed acknowledgements, TCP segmentation offload (TSO) or Selective Acknowledgements (SACK). This module is required by the delay based congestion control algorithms. Khelp Framework for FreeBSD v0.1.1 [20,21] ---------------------------------------------------------------------- A FreeBSD kernel patch that provides support for generic kernel modules known as "helpers" to hook into arbitrary points within the kernel and provide service(s) to the running system. This forms the foundation for the ERTT Khelp module. Modular TCP Congestion Control for FreeBSD v0.10.0 [22,23] ------------------------------------------------- This revision of the modular TCP congestion control framework patch provides a current snapshot of the project's development branch. Some fairly major changes and refactoring have gone into this release, along with numerous tweaks, bug fixes and enhancements to support the new delay based congestion control algorithms we have been working on. In theory, the framework now also supports sharing of congestion control algorithms between congestion aware transport protocols like TCP and SCTP, though this integration work is yet to be done. [1] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-0.1.tar.gz [2] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-readme-0.1.txt [3] L. Budzisz, R. Stanojevic, R. Shorten, and F. Baker, "A strategy for fair coexistence of loss and delay-based congestion control algorithms", IEEE Commun. Lett., vol. 13, no. 7, pp. 555-557, Jul. 2009. [4] D. A. Hayes and G. Armitage, "Improved coexistence and loss tolerance for delay based TCP congestion control", in Proceedings of 35th Annual IEEE Conference on Local Computer Networks (LCN 2010), Denver, Colorado, USA, 11-14 October 2010. [5] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-0.2.tar.gz [6] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-readme-0.2.txt [7] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-0.2.tar.gz [8] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-readme-0.2.txt [9] L. S. Brakmo and L. L. Peterson, "TCP Vegas: end to end congestion avoidance on a global internet", IEEE J. Sel. Areas Commun., vol. 13, no. 8, pp. 1465-1480, Oct. 1995. [10] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-0.12.tar.gz [11] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-readme-0.12.txt [12] D. Leith, R. Shorten, "H-TCP: TCP for high-speed and long-distance networks", in Second International Workshop on Protocols for Fast Long-Distance Networks, Argonne, Illinois USA, February 2004. [13] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-0.10.tar.gz [14] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-readme-0.10.txt [15] I. Rhee, L. Xu, S. Ha, "CUBIC for Fast Long-Distance Networks", Internet Draft, draft-rhee-tcpm-cubic-02.txt, August 2008. [16] http://caia.swin.edu.au/urp/newtcp/tools/siftr-1.2.3.tar.gz [17] http://caia.swin.edu.au/urp/newtcp/tools/siftr-readme-1.2.3.txt [18] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-0.2.tar.gz [19] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-readme-0.2.txt [20] http://caia.swin.edu.au/urp/newtcp/tools/caia_khelp_framework_v0.1.1_9.x.r209905.patch [21] http://caia.swin.edu.au/urp/newtcp/tools/khelp-readme-0.1.1.txt [22] http://caia.swin.edu.au/urp/newtcp/tools/caia_modularcc_v0.10.0_9.x.r209905.patch [23] http://caia.swin.edu.au/urp/newtcp/tools/modularcc-readme-0.10.0.txt From owner-freebsd-net@FreeBSD.ORG Tue Aug 3 14:30:09 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57E071065686 for ; Tue, 3 Aug 2010 14:30:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1DF8FC25 for ; Tue, 3 Aug 2010 14:30:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 97B7D46B8A for ; Tue, 3 Aug 2010 10:30:08 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C9E5D8A03C for ; Tue, 3 Aug 2010 10:30:07 -0400 (EDT) From: John Baldwin To: net@freebsd.org Date: Tue, 3 Aug 2010 10:29:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201008031029.11284.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 03 Aug 2010 10:30:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: vlan(4) interfaces have wrong interface type in sockaddr_dl address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 14:30:09 -0000 Currently vlan(4) interfaces have an interface type of IFT_ETHER instead of IFT_L2VLAN in the sockaddr_dl that is returned by getifaddrs(3). If you do a route lookup for a route that goes across a vlan then the sockaddr_dl generated for the routing message will specify IFT_L2VLAN (you can see it as 'arp -a' shows [vlan] instead of [ethernet] for those routes). However, the address returned via getifaddrs(3) has a type of IFT_ETHER. I think this is a bug of omission in that the vlan attach code needs to update the sockaddr_dl that is initialized in ether_ifattach(). This patch does that and fixes getifaddrs(3). Any objections? Index: if_vlan.c =================================================================== --- if_vlan.c (revision 211312) +++ if_vlan.c (working copy) @@ -640,6 +640,8 @@ struct ifvlan *ifv; struct ifnet *ifp; struct ifnet *p; + struct ifaddr *ifa; + struct sockaddr_dl *sdl; struct vlanreq vlr; static const u_char eaddr[ETHER_ADDR_LEN]; /* 00:00:00:00:00:00 */ @@ -738,6 +740,9 @@ ifp->if_baudrate = 0; ifp->if_type = IFT_L2VLAN; ifp->if_hdrlen = ETHER_VLAN_ENCAP_LEN; + ifa = ifp->if_addr; + sdl = (struct sockaddr_dl *)ifa->ifa_addr; + sdl->sdl_type = IFT_L2VLAN; if (ethertag) { error = vlan_config(ifv, p, tag); -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Aug 3 14:55:41 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B1C6106566B for ; Tue, 3 Aug 2010 14:55:41 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out9.libero.it (cp-out9.libero.it [212.52.84.109]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4708FC0C for ; Tue, 3 Aug 2010 14:55:41 +0000 (UTC) Received: from soth.ventu (151.51.20.251) by cp-out9.libero.it (8.5.107) id 4C4029D1030AD312 for freebsd-net@freebsd.org; Tue, 3 Aug 2010 16:55:39 +0200 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.4/8.14.3) with ESMTP id o73Etcr1015992 for ; Tue, 3 Aug 2010 16:55:38 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <4C582DEB.1000105@netfence.it> Date: Tue, 03 Aug 2010 16:55:39 +0200 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.1.11) Gecko/20100724 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: CARP over LAGG X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 14:55:41 -0000 Hello. On a couple of 7.2 systems, I've got some carp interfaces build upon a physical interface (em0 or igb0) and everything works fine. On both box I've tried aggregating two interfaces (resp. em0+em1 and igb0+igb1) into a lagg0 interface, using LACP. However, in this case CARP will stop working as all carp devices which work over lagg0 will stay in INIT state. Is this a bug? Is "carp over lagg" possible at all? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Tue Aug 3 17:06:49 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99BA41065672 for ; Tue, 3 Aug 2010 17:06:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 54BFB8FC12 for ; Tue, 3 Aug 2010 17:06:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C0D8B46B53 for ; Tue, 3 Aug 2010 13:06:48 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 06A3C8A03C for ; Tue, 3 Aug 2010 13:06:48 -0400 (EDT) From: John Baldwin To: net@freebsd.org Date: Tue, 3 Aug 2010 12:17:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201008031029.11284.jhb@freebsd.org> In-Reply-To: <201008031029.11284.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008031217.27479.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 03 Aug 2010 13:06:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: vlan(4) interfaces have wrong interface type in sockaddr_dl address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:06:49 -0000 On Tuesday, August 03, 2010 10:29:11 am John Baldwin wrote: > Currently vlan(4) interfaces have an interface type of IFT_ETHER instead of > IFT_L2VLAN in the sockaddr_dl that is returned by getifaddrs(3). If you do a > route lookup for a route that goes across a vlan then the sockaddr_dl > generated for the routing message will specify IFT_L2VLAN (you can see it as > 'arp -a' shows [vlan] instead of [ethernet] for those routes). However, the > address returned via getifaddrs(3) has a type of IFT_ETHER. I think this is a > bug of omission in that the vlan attach code needs to update the sockaddr_dl > that is initialized in ether_ifattach(). This patch does that and fixes > getifaddrs(3). Any objections? A few places in userland also need fixing to catch up to this I think. I did not patch getnameinfo(3) in libc since it explicitly claims in the comments that IFT_L2VLAN interfaces have a zero-length address (even though this claim is false in practice). Updated patch: Index: sys/net/if_vlan.c =================================================================== --- sys/net/if_vlan.c (revision 211312) +++ sys/net/if_vlan.c (working copy) @@ -640,6 +640,8 @@ struct ifvlan *ifv; struct ifnet *ifp; struct ifnet *p; + struct ifaddr *ifa; + struct sockaddr_dl *sdl; struct vlanreq vlr; static const u_char eaddr[ETHER_ADDR_LEN]; /* 00:00:00:00:00:00 */ @@ -738,6 +740,9 @@ ifp->if_baudrate = 0; ifp->if_type = IFT_L2VLAN; ifp->if_hdrlen = ETHER_VLAN_ENCAP_LEN; + ifa = ifp->if_addr; + sdl = (struct sockaddr_dl *)ifa->ifa_addr; + sdl->sdl_type = IFT_L2VLAN; if (ethertag) { error = vlan_config(ifv, p, tag); Index: sbin/ifconfig/af_link.c =================================================================== --- sbin/ifconfig/af_link.c (revision 211312) +++ sbin/ifconfig/af_link.c (working copy) @@ -58,7 +58,9 @@ struct sockaddr_dl *sdl = (struct sockaddr_dl *) ifa->ifa_addr; if (sdl != NULL && sdl->sdl_alen > 0) { - if (sdl->sdl_type == IFT_ETHER && + if ((sdl->sdl_type == IFT_ETHER || + sdl->sdl_type == IFT_L2VLAN || + sdl->sdl_type == IFT_BRIDGE) && sdl->sdl_alen == ETHER_ADDR_LEN) printf("\tether %s\n", ether_ntoa((struct ether_addr *)LLADDR(sdl))); Index: usr.sbin/ndp/ndp.c =================================================================== --- usr.sbin/ndp/ndp.c (revision 211312) +++ usr.sbin/ndp/ndp.c (working copy) @@ -433,6 +433,7 @@ switch (sdl->sdl_type) { case IFT_ETHER: case IFT_FDDI: case IFT_ISO88023: case IFT_ISO88024: case IFT_ISO88025: + case IFT_L2VLAN: case IFT_BRIDGE: goto overwrite; } } Index: usr.sbin/ppp/ipv6cp.c =================================================================== --- usr.sbin/ppp/ipv6cp.c (revision 211312) +++ usr.sbin/ppp/ipv6cp.c (working copy) @@ -148,6 +148,7 @@ switch(sdl->sdl_type) { case IFT_ETHER: case IFT_FDDI: + case IFT_L2VLAN: /* XXX need more cases? */ break; default: -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Aug 3 17:57:31 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD4241065673 for ; Tue, 3 Aug 2010 17:57:31 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 475178FC13 for ; Tue, 3 Aug 2010 17:57:30 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id o73HgU79087656; Tue, 3 Aug 2010 12:42:30 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id o73HgUmf087655; Tue, 3 Aug 2010 12:42:30 -0500 (CDT) (envelope-from brooks) Date: Tue, 3 Aug 2010 12:42:30 -0500 From: Brooks Davis To: John Baldwin Message-ID: <20100803174230.GA87066@lor.one-eyed-alien.net> References: <201008031029.11284.jhb@freebsd.org> <201008031217.27479.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <201008031217.27479.jhb@freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 03 Aug 2010 12:42:30 -0500 (CDT) Cc: net@freebsd.org Subject: Re: vlan(4) interfaces have wrong interface type in sockaddr_dl address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:57:31 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 03, 2010 at 12:17:27PM -0400, John Baldwin wrote: > On Tuesday, August 03, 2010 10:29:11 am John Baldwin wrote: > > Currently vlan(4) interfaces have an interface type of IFT_ETHER instea= d of=20 > > IFT_L2VLAN in the sockaddr_dl that is returned by getifaddrs(3). If yo= u do a=20 > > route lookup for a route that goes across a vlan then the sockaddr_dl= =20 > > generated for the routing message will specify IFT_L2VLAN (you can see = it as=20 > > 'arp -a' shows [vlan] instead of [ethernet] for those routes). However= , the=20 > > address returned via getifaddrs(3) has a type of IFT_ETHER. I think th= is is a=20 > > bug of omission in that the vlan attach code needs to update the sockad= dr_dl=20 > > that is initialized in ether_ifattach(). This patch does that and fixe= s=20 > > getifaddrs(3). Any objections? >=20 > A few places in userland also need fixing to catch up to this I think. I= did > not patch getnameinfo(3) in libc since it explicitly claims in the commen= ts > that IFT_L2VLAN interfaces have a zero-length address (even though this c= laim > is false in practice). Updated patch: This seems like the right thing to do. I might suggest merging the userspace changes well before the kernel changes or the results may be confusing. -- Brooks --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFMWFUFXY6L6fI4GtQRAtlJAJ9Hkm92at0kNSAUBupFQw2sF6s8jgCeMU3I BobDKg6wslhAn4CzuYzYpsQ= =wCM6 -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 3 21:35:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BD121065673 for ; Tue, 3 Aug 2010 21:35:20 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from sfgw1.moneybookers.com (sfgw1.moneybookers.com [195.34.111.179]) by mx1.freebsd.org (Postfix) with ESMTP id 5042C8FC1A for ; Tue, 3 Aug 2010 21:35:20 +0000 (UTC) Received: from sfgw1.moneybookers.com (localhost [127.0.0.1]) by sfgw1.moneybookers.com (Postfix) with ESMTPS id 21AA1B40C39; Tue, 3 Aug 2010 23:15:19 +0200 (CEST) Received: from maylo.moneybookers.com (maylo.dev.moneybookers.net [192.168.3.20]) by sfgw1.moneybookers.com (Postfix) with ESMTP id 6CE41B40C35; Tue, 3 Aug 2010 23:15:18 +0200 (CEST) Received: from [10.1.1.3] (unknown [10.46.0.25]) by maylo.moneybookers.com (Postfix) with ESMTP id 4DF5537BF81B; Tue, 3 Aug 2010 23:15:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Lambrev In-Reply-To: <4C582DEB.1000105@netfence.it> Date: Wed, 4 Aug 2010 00:15:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C582DEB.1000105@netfence.it> To: Andrea Venturoli X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: clamav-milter 0.96.1 at gw1.sof.moneybookers.net X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gw1.sof.moneybookers.net Cc: freebsd-net@freebsd.org Subject: Re: CARP over LAGG X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 21:35:20 -0000 Hello, This should be possible. I do have 7.2 systems which have lagg0 on = em0/em1 VLANs over lagg0 and carp over those VLANs. So I guess carp over lagg0 = should no be a problem. lagg0: flags=3D8943 = metric 0 mtu 1500 = options=3D19b ether 00:30:48:c8:2f:50 media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=3D1c laggport: em0 flags=3D1c vlan4: flags=3D8943 = metric 0 mtu 1500 options=3D3 ether 00:30:48:c8:2f:50 inet 10.62.4.253 netmask 0xffffff00 broadcast 10.62.4.255 media: Ethernet autoselect status: active vlan: 4 parent interface: lagg0 carp4: flags=3D49 metric 0 mtu 1500 inet 10.62.4.1 netmask 0xffffff00=20 carp: MASTER vhid 4 advbase 1 advskew 0 On Aug 3, 2010, at 5:55 PM, Andrea Venturoli wrote: > Hello. >=20 > On a couple of 7.2 systems, I've got some carp interfaces build upon a = physical interface (em0 or igb0) and everything works fine. >=20 > On both box I've tried aggregating two interfaces (resp. em0+em1 and = igb0+igb1) into a lagg0 interface, using LACP. > However, in this case CARP will stop working as all carp devices which = work over lagg0 will stay in INIT state. >=20 > Is this a bug? > Is "carp over lagg" possible at all? >=20 > bye & Thanks > av. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 02:30:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3BBD1065676 for ; Wed, 4 Aug 2010 02:30:32 +0000 (UTC) (envelope-from scottj75074@yahoo.com) Received: from web110707.mail.gq1.yahoo.com (web110707.mail.gq1.yahoo.com [67.195.13.214]) by mx1.freebsd.org (Postfix) with SMTP id 78EC58FC14 for ; Wed, 4 Aug 2010 02:30:32 +0000 (UTC) Received: (qmail 21347 invoked by uid 60001); 4 Aug 2010 02:02:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280887350; bh=1nKpkppWCMKdT54mlaGStVX7UvkSk8s9R5GnfilcSB4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=GSEIwSSplJHmTi/KQdeZjjxAbCq07YTN3KR4fp/7lyvWzOWqPz1NJzVeOTciDUG9O46kYQi9ZKuQgWIBrE/q9+GQW+i43sTULLi3EYoyh0fuqwRTmCWak1dvNvgrqCoId3QWpsuwTOgO1uAgLOpn9pJInXCjWbyuSrnbL9EV2m0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=IZbaPU5WrLaEpka0VH/zjxZCG45WZgfIVbFE7RYvwjpHgoNBH7pGunefGtO1o9jUSAJNF1uCHG3AXqmG67K1F0xRdtb5AcUSZLOMQ3J4fenqwR2FPr51wvOpCcISHuYXcnAqH8tGOPK5R80WZPLNy3/kfKpJXmmHBPtMMGjmxp4=; Message-ID: <798824.20619.qm@web110707.mail.gq1.yahoo.com> X-YMail-OSG: MS8gk6UVM1lgSIHY0KIarZGYpeCGDMLnGFVyBrqd2kAb.YN dPoNGxc5LAmq7tkH98mMMPafgvgeJDsJy7iMY0kwerV2GZyp.tVeOtQOJa2i COJ19h_dssMCogsnISX.tKZNWMZ3z0nm6WEarFpc3ww9RSIrIStKGSdm7WfJ rWXYSKIupItBxeiIKuZf1rBNk2rCa76hFCj3hdwAXTCY4zkp7dklmYkg2e2n KhdX_H7u2rIt7m2fs7inAwUIMpFZvb9oWerjyGiVWvn5xOuIwz1VC53UdpYy kX3AOUJmkJzQ2DFA8wg_cWX8ju4758b09sITWTky9Fps8ZdXtXC6SWA-- Received: from [24.6.145.200] by web110707.mail.gq1.yahoo.com via HTTP; Tue, 03 Aug 2010 19:02:30 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 Date: Tue, 3 Aug 2010 19:02:30 -0700 (PDT) From: Scott Johnson To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: 8.1-RELEASE em watchdog timeout broken? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 02:30:32 -0000 Under 8.0-RELEASE I would get warnings from em(4) in /var/log/messages about "watchdog timeouts" on em0 whenever my desktop PC connected to em0 was powered off. This was fine, except for the annoying warnings. Under 8.1-RELEASE I no longer get the warnings, and any time my desktop is powered off, when I turn it back on, it has no connectivity. The interface is dead until I log into the console and run: # ifconfig em0 down up The em(4) driver has changed a lot since 8.0-RELEASE. It seems this watchdog timeout is no longer working. The board is a Supermicro X7SPA-H with Intel 82574L GbE. Any ideas for debugging? From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 03:17:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC6DB106564A for ; Wed, 4 Aug 2010 03:17:37 +0000 (UTC) (envelope-from cybercorecentre@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 929568FC1D for ; Wed, 4 Aug 2010 03:17:37 +0000 (UTC) Received: by vws7 with SMTP id 7so4514361vws.13 for ; Tue, 03 Aug 2010 20:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=sX0Vclk3wNx8CTMB8z4tBQMXqkzzTJZEi8CebTe2fRI=; b=t2z8Jptv+nUX4hnXs8jUHxOAWT4EJ8QoXQCPEcJ9NVa9t/TQJgga+aI2jbbHLQrwAU Yy7r8THnQP6bmRidaBU4ZgNLu7wXfzy6OiV/Hh4ZMTPvJwsuwxUH4SJ1SeSUb97fFlyZ b4T7VVoQSzXfT5m3XSWpxI9vCGU7NLFITfvaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=AVT6Bn2OaNoN2VqrkpIK/Ror6SW9q8qT+swXxxSovD6h5w/nofi8qA75wRPcziSfLp uUUrNCBspw/UrgH+RRaS80mF6mJXTZRD1OVj7Ei6Ed/IvvPyR0d6W0UkMTGjN2euctib uR/LMxSgWsb9P8dMWw9ijGJWm9dW+jDJvqab8= MIME-Version: 1.0 Received: by 10.220.60.203 with SMTP id q11mr5899730vch.28.1280890431843; Tue, 03 Aug 2010 19:53:51 -0700 (PDT) Received: by 10.220.177.140 with HTTP; Tue, 3 Aug 2010 19:53:51 -0700 (PDT) In-Reply-To: <798824.20619.qm@web110707.mail.gq1.yahoo.com> References: <798824.20619.qm@web110707.mail.gq1.yahoo.com> Date: Wed, 4 Aug 2010 04:53:51 +0200 Message-ID: From: Jax To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: 8.1-RELEASE em watchdog timeout broken? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 03:17:37 -0000 "whenever my desktop PC" Now this is where u FAIL. Use dubuntu or windows7 on desktop not FBSD and don't try again. Jax On Wed, Aug 4, 2010 at 4:02 AM, Scott Johnson wrote: > Under 8.0-RELEASE I would get warnings from em(4) in /var/log/messages about > > "watchdog timeouts" on em0 whenever my desktop PC connected to em0 was powered > off. This was fine, except for the annoying warnings. > > Under 8.1-RELEASE I no longer get the warnings, and any time my desktop is > powered off, when I turn it back on, it has no connectivity. The interface is > dead until I log into the console and run: > # ifconfig em0 down up > > The em(4) driver has changed a lot since 8.0-RELEASE. It seems this watchdog > timeout is no longer working. > > The board is a Supermicro X7SPA-H with Intel 82574L GbE. > > Any ideas for debugging? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 05:19:12 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3FFE1065675 for ; Wed, 4 Aug 2010 05:19:12 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 78B598FC1B for ; Wed, 4 Aug 2010 05:19:12 +0000 (UTC) Received: by wwa36 with SMTP id 36so4805174wwa.31 for ; Tue, 03 Aug 2010 22:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=v45FNG4LoekVz87RXkHiSU6y/4n0+9Fungj9RkjeWG8=; b=MLuKCRF4iv6WivoeTyk2Vjm1b6z+BVABL5WGeGrYyiHI4umG9yeOAMpiwwMZLlb7um 70nayoom1OBdPKLJw8f3ktizNmAZDCJC/xOo2AbASfEOLIJQqTwPPN+giwk33kxzQw08 +SAT3qZjH/Lto43P+y7x2V2nJYDwxLYk3ybE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x2/p90f9rOdvA0pM5HXfkgqseIJGnfNuXh7cqFQXlKPxgmJ7yI2f1679nnivaE+/Yz Z3VXjJ2d65YDf1FVv4VIE54EqZUNpAz4ozexTY6gSN3VcgUTIQkg8QKj4jMgeoOaNAVF dpRRTM3oZDrRjw2NiVjtzuV/zSpVEcQCJTYyw= MIME-Version: 1.0 Received: by 10.216.44.209 with SMTP id n59mr1604112web.58.1280899151380; Tue, 03 Aug 2010 22:19:11 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Tue, 3 Aug 2010 22:19:11 -0700 (PDT) In-Reply-To: <798824.20619.qm@web110707.mail.gq1.yahoo.com> References: <798824.20619.qm@web110707.mail.gq1.yahoo.com> Date: Tue, 3 Aug 2010 22:19:11 -0700 Message-ID: From: Jack Vogel To: Scott Johnson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: 8.1-RELEASE em watchdog timeout broken? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 05:19:13 -0000 The watchdog is working in all the internal testing that we've done, if there's some corner case here then I need more info to reproduce it. I'm confused about what's what, which machine is your desktop and what is the 'other' system? For instance, we had a loud complaint about the watchdog here a while back, and it turned out the user had increased the system HZ value to something really high... I've yet to see something that indicates the code is broken. If it involves Windows then it goes outside the parameters of my testing so who knows :) Jack On Tue, Aug 3, 2010 at 7:02 PM, Scott Johnson wrote: > Under 8.0-RELEASE I would get warnings from em(4) in /var/log/messages > about > > "watchdog timeouts" on em0 whenever my desktop PC connected to em0 was > powered > off. This was fine, except for the annoying warnings. > > Under 8.1-RELEASE I no longer get the warnings, and any time my desktop is > powered off, when I turn it back on, it has no connectivity. The interface > is > dead until I log into the console and run: > # ifconfig em0 down up > > The em(4) driver has changed a lot since 8.0-RELEASE. It seems this > watchdog > timeout is no longer working. > > The board is a Supermicro X7SPA-H with Intel 82574L GbE. > > Any ideas for debugging? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 05:29:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CF94106564A for ; Wed, 4 Aug 2010 05:29:22 +0000 (UTC) (envelope-from scottj75074@yahoo.com) Received: from web110702.mail.gq1.yahoo.com (web110702.mail.gq1.yahoo.com [67.195.13.209]) by mx1.freebsd.org (Postfix) with SMTP id 568898FC08 for ; Wed, 4 Aug 2010 05:29:22 +0000 (UTC) Received: (qmail 87191 invoked by uid 60001); 4 Aug 2010 05:29:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280899761; bh=qYXSktmOHOHIIUnLgaS/Z9i4x6LvuiI2bBDGmZavu5I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=6mRWCis78Lyy+cl0pUQlgSmiaV+A7zXeUvHTcawYOLgR3wcLs6jZuqXhpqferlOWCpxwBqemT8EtBio2WtSdqVp+IMmWBCWNVDIqxfr+NTdiJHPVJRfJ8xkyPSOqAs4vDwkp5Bn0WNKodPx7tA/CY5D1fksrC1TLNcLFq7BC5uE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=GTmzprFc9tAUU+w1pp3tUVSLmtsznnGwMhLToykiISpaUAknGG/7CIZ00ERp4OwNC46RqN0lzUyK7MJNOGyT2Z5iXoHa+s0FmVAiG4us1GKKGLGWxlK6w9QWnsFBEYT25UqnKizDSJATIyYAQuA+8p9tIBN0lvdySO6sm3taREY=; Message-ID: <752348.86563.qm@web110702.mail.gq1.yahoo.com> X-YMail-OSG: Ge04pvoVM1l.AkBfN0wHHkdN_1OuS7AKbnG_AHHEZ0oEOEu VGHtiobVjHy4eaNOwYwKSvahOn13uI2ROREPbE7dLuN.yn_JvEpMXbmi31vJ WkEy3CrxAajdpt2EWAfvhJLGr.y33sOjiaIZLNLhyRzh5zzMgl7D5Amy6dVJ pPDofQYIL2TiqcwFFwwqKHnvyKnqsdpwj6ANpRA8dA60Io8slw53fVsWKJzw b7YA1S5H0vTYkwTN7jk__JgpCD6mQLwgrvM7Am2itvulw8qn5vE0MaEYg_I. Y15CKpNjVb3cfFrU5Y11cd.gLt.BDJ10DxYaU3Uw- Received: from [24.6.145.200] by web110702.mail.gq1.yahoo.com via HTTP; Tue, 03 Aug 2010 22:29:21 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 Date: Tue, 3 Aug 2010 22:29:21 -0700 (PDT) From: Scott Johnson To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: 8.1-RELEASE em watchdog timeout broken? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 05:29:22 -0000 > "whenever my desktop PC" > > Now this is where u FAIL. Use dubuntu or windows7 on desktop not FBSD > and don't try again. > > Jax Perhaps I wasn't clear. The desktop PC (which runs WinXP) is connected directly to the em0 port on my FreeBSD server. No Ethernet switch in-between. I connect it directly to the server so that I don't need a gigabit switch. The second Ethernet port on the FreeBSD box (em1) is connected to the 100Mb switch, and the two interfaces are bridged using if_bridge. Perhaps you could try not to be so rude with your unhelpful responses in the future. From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 13:21:40 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AB741065697; Wed, 4 Aug 2010 13:21:40 +0000 (UTC) (envelope-from misho@aitbg.com) Received: from mail.aitbg.com (fire.aitbg.com [84.238.153.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2CFC58FC0A; Wed, 4 Aug 2010 13:21:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.aitbg.com (Postfix) with ESMTP id 2765019D7F; Wed, 4 Aug 2010 16:03:14 +0300 (EEST) X-Virus-Scanned: amavisd-new at aitbg.com Received: from mail.aitbg.com ([127.0.0.1]) by localhost (mail.aitbg.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnKWAZyWsneS; Wed, 4 Aug 2010 16:03:08 +0300 (EEST) Received: from smurf.insecurebg.org (unknown [212.116.129.162]) by mail.aitbg.com (Postfix) with ESMTPSA id 4D33719D3B; Wed, 4 Aug 2010 16:03:08 +0300 (EEST) Date: Wed, 4 Aug 2010 16:01:24 +0300 From: Michael Pounov To: freebsd-ports@freebsd.org, freebsd-net@freebsd.org, freebsd-isp@freebsd.org Message-Id: <20100804160124.b50750be.misho@aitbg.com> Organization: AITNET ltd X-Mailer: Sylpheed 3.0.1 (GTK+ 2.18.7; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__4_Aug_2010_16_01_24_+0300_xE_AJaem.in9GCbR" Cc: Subject: ipsec-tools fix broken in CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 13:21:40 -0000 This is a multi-part message in MIME format. --Multipart=_Wed__4_Aug_2010_16_01_24_+0300_xE_AJaem.in9GCbR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, this patch file ipsec-tools_fbsd90.txt Fix broken ipsec-tools in freebsd 9.0-current. Because after change syscons stop compiling sources. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=149270 >Category: ports >Responsible: freebsd-ports-bugs >Synopsis: ipsec-tools is broken in CURRENT >Arrival-Date: Wed Aug 04 12:40:04 UTC 2010 -- M.Punov --------------------- AITNET - Sofia/Bulgaria - Software & Network Solutions (+359) 888 73 73 58;(+359) 2 402 4000 --Multipart=_Wed__4_Aug_2010_16_01_24_+0300_xE_AJaem.in9GCbR Content-Type: text/plain; name="ipsec-tools_fbsd90.txt" Content-Disposition: attachment; filename="ipsec-tools_fbsd90.txt" Content-Transfer-Encoding: 7bit Index: Makefile =================================================================== RCS file: /home/ncvs/ports/security/ipsec-tools/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 20 Mar 2010 15:12:15 -0000 1.26 +++ Makefile 4 Aug 2010 11:18:17 -0000 @@ -60,7 +60,7 @@ .include .if ${OSVERSION} > 900007 -BROKEN= fails to build with new utmpx +LDFLAGS+= -lulog .endif .ifdef(WITH_DEBUG) --- work/ipsec-tools-0.7.3/src/racoon/isakmp_cfg.c 2008-11-27 17:25:20.000000000 +0200 +++ work/ipsec-tools-0.7.3/src/racoon/isakmp_cfg_new.c 2010-08-04 14:58:27.000000000 +0300 @@ -38,7 +38,8 @@ #include #include -#include +#include +#include #if defined(__APPLE__) && defined(__MACH__) #include #endif @@ -1651,8 +1652,7 @@ int inout; { int error = 0; - struct utmp ut; - char term[UT_LINESIZE]; + char term[8]; char addr[NI_MAXHOST]; if (usr == NULL || usr[0]=='\0') { @@ -1665,33 +1665,20 @@ switch (inout) { case ISAKMP_CFG_LOGIN: - strncpy(ut.ut_name, usr, UT_NAMESIZE); - ut.ut_name[UT_NAMESIZE - 1] = '\0'; - - strncpy(ut.ut_line, term, UT_LINESIZE); - ut.ut_line[UT_LINESIZE - 1] = '\0'; - GETNAMEINFO_NULL(raddr, addr); - strncpy(ut.ut_host, addr, UT_HOSTSIZE); - ut.ut_host[UT_HOSTSIZE - 1] = '\0'; - ut.ut_time = time(NULL); - plog(LLV_INFO, LOCATION, NULL, "Accounting : '%s' logging on '%s' from %s.\n", - ut.ut_name, ut.ut_line, ut.ut_host); - - login(&ut); + term, usr, addr); + ulog_login(term, usr, addr); break; case ISAKMP_CFG_LOGOUT: - plog(LLV_INFO, LOCATION, NULL, "Accounting : '%s' unlogging from '%s'.\n", usr, term); - logout(term); - + ulog_logout(term); break; default: plog(LLV_ERROR, LOCATION, NULL, "Unepected inout\n"); --Multipart=_Wed__4_Aug_2010_16_01_24_+0300_xE_AJaem.in9GCbR-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 13:31:40 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6EB91065677; Wed, 4 Aug 2010 13:31:40 +0000 (UTC) (envelope-from misho@openbsd-bg.org) Received: from mail.aitbg.com (fire.aitbg.com [84.238.153.194]) by mx1.freebsd.org (Postfix) with ESMTP id 97EDD8FC14; Wed, 4 Aug 2010 13:31:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.aitbg.com (Postfix) with ESMTP id 37BB419D8A; Wed, 4 Aug 2010 16:12:19 +0300 (EEST) X-Virus-Scanned: amavisd-new at aitbg.com Received: from mail.aitbg.com ([127.0.0.1]) by localhost (mail.aitbg.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJNHiRjd9q9F; Wed, 4 Aug 2010 16:12:15 +0300 (EEST) Received: from smurf.insecurebg.org (unknown [212.116.129.162]) by mail.aitbg.com (Postfix) with ESMTPSA id 52A3019D2A; Wed, 4 Aug 2010 16:12:12 +0300 (EEST) Date: Wed, 4 Aug 2010 16:10:28 +0300 From: Michael Pounov To: freebsd-ports@freebsd.org, freebsd-net@freebsd.org, freebsd-isp@freebsd.org Message-Id: <20100804161028.b5bb28bd.misho@openbsd-bg.org> Organization: AITNET ltd X-Mailer: Sylpheed 3.0.1 (GTK+ 2.18.7; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__4_Aug_2010_16_10_28_+0300_e2yXFabKSTd1sgI=" Cc: Subject: ipsec-tools fix broken in CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 13:31:41 -0000 This is a multi-part message in MIME format. --Multipart=_Wed__4_Aug_2010_16_10_28_+0300_e2yXFabKSTd1sgI= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, this patch file ipsec-tools_fbsd90.txt Fix broken ipsec-tools in freebsd 9.0-current. Because after change syscons stop compiling sources. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=149270 >Category: ports >Responsible: freebsd-ports-bugs >Synopsis: ipsec-tools is broken in CURRENT >Arrival-Date: Wed Aug 04 12:40:04 UTC 2010 -- Michael Pounov --Multipart=_Wed__4_Aug_2010_16_10_28_+0300_e2yXFabKSTd1sgI= Content-Type: text/plain; name="ipsec-tools_fbsd90.txt" Content-Disposition: attachment; filename="ipsec-tools_fbsd90.txt" Content-Transfer-Encoding: 7bit Index: Makefile =================================================================== RCS file: /home/ncvs/ports/security/ipsec-tools/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 20 Mar 2010 15:12:15 -0000 1.26 +++ Makefile 4 Aug 2010 11:18:17 -0000 @@ -60,7 +60,7 @@ .include .if ${OSVERSION} > 900007 -BROKEN= fails to build with new utmpx +LDFLAGS+= -lulog .endif .ifdef(WITH_DEBUG) --- work/ipsec-tools-0.7.3/src/racoon/isakmp_cfg.c 2008-11-27 17:25:20.000000000 +0200 +++ work/ipsec-tools-0.7.3/src/racoon/isakmp_cfg_new.c 2010-08-04 14:58:27.000000000 +0300 @@ -38,7 +38,8 @@ #include #include -#include +#include +#include #if defined(__APPLE__) && defined(__MACH__) #include #endif @@ -1651,8 +1652,7 @@ int inout; { int error = 0; - struct utmp ut; - char term[UT_LINESIZE]; + char term[8]; char addr[NI_MAXHOST]; if (usr == NULL || usr[0]=='\0') { @@ -1665,33 +1665,20 @@ switch (inout) { case ISAKMP_CFG_LOGIN: - strncpy(ut.ut_name, usr, UT_NAMESIZE); - ut.ut_name[UT_NAMESIZE - 1] = '\0'; - - strncpy(ut.ut_line, term, UT_LINESIZE); - ut.ut_line[UT_LINESIZE - 1] = '\0'; - GETNAMEINFO_NULL(raddr, addr); - strncpy(ut.ut_host, addr, UT_HOSTSIZE); - ut.ut_host[UT_HOSTSIZE - 1] = '\0'; - ut.ut_time = time(NULL); - plog(LLV_INFO, LOCATION, NULL, "Accounting : '%s' logging on '%s' from %s.\n", - ut.ut_name, ut.ut_line, ut.ut_host); - - login(&ut); + term, usr, addr); + ulog_login(term, usr, addr); break; case ISAKMP_CFG_LOGOUT: - plog(LLV_INFO, LOCATION, NULL, "Accounting : '%s' unlogging from '%s'.\n", usr, term); - logout(term); - + ulog_logout(term); break; default: plog(LLV_ERROR, LOCATION, NULL, "Unepected inout\n"); --Multipart=_Wed__4_Aug_2010_16_10_28_+0300_e2yXFabKSTd1sgI=-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 20:22:52 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A8571065678; Wed, 4 Aug 2010 20:22:52 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 462388FC19; Wed, 4 Aug 2010 20:22:51 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 26E4A1E006D6; Wed, 4 Aug 2010 22:04:50 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id o74K2ZuO057192; Wed, 4 Aug 2010 22:02:35 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id o74K2Z1g057191; Wed, 4 Aug 2010 22:02:35 +0200 (CEST) (envelope-from nox) Date: Wed, 4 Aug 2010 22:02:35 +0200 (CEST) From: Juergen Lock Message-Id: <201008042002.o74K2Z1g057191@triton8.kn-bremen.de> To: bug-followup@FreeBSD.org X-Newsgroups: gmane.os.freebsd.devel.net,gmane.os.freebsd.bugs In-Reply-To: <201008020223.o722NSe2093952@freefall.freebsd.org> Organization: home Cc: freebsd-net@FreeBSD.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 20:22:52 -0000 Hi! Regarding the 8.1 if_rum(4) panics... I got a similar one, extracted a dump and tried to gather some info for someone who knows the code: The zero divide fault was because (apparently) rate was unitialized, as is ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. [1] Simply setting rate to something non-zero (I first tried 0xff, then 72 since that was used in station mode) without changing anything else stopped the panics but as probably to be expected, the wifi only partly worked, clients frequently disconnected. (I'll put the patch at the end of the mail. [2]) # ifconfig wlan0 create wlandev rum0 wlanmode ap ssid XXX # /etc/rc.d/hostapd onestart Starting hostapd. Configuration file: /etc/hostapd.conf Using interface wlan0 with hwaddr 00:22:75:fe:9d:4e and ssid 'XXX' bind(PF_UNIX): Address already in use Failed to setup control interface /etc/rc.d/hostapd: WARNING: failed to start hostapd # /etc/rc.d/hostapd onestart Starting hostapd. Configuration file: /etc/hostapd.conf Using interface wlan0 with hwaddr 00:22:75:fe:9d:4e and ssid 'XXX' # [...] Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80534a28 stack pointer = 0x28:0xffffff80ec0727a0 frame pointer = 0x28:0xffffff80ec0727b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 607 (hostapd) trap number = 18 panic: integer divide fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2ad trap() at trap+0x102 calltrap() at calltrap+0x8 --- trap 0x12, rip = 0xffffffff80534a28, rsp = 0xffffff80ec0727a0, rbp = 0xffffff80ec0727b0 --- rum_setup_tx_desc() at rum_setup_tx_desc+0x68 rum_start() at rum_start+0x1af if_transmit() at if_transmit+0xea ieee80211_start() at ieee80211_start+0x542 if_transmit() at if_transmit+0xea ether_output_frame() at ether_output_frame+0x33 ether_output() at ether_output+0x4ba bpfwrite() at bpfwrite+0x3a5 devfs_write_f() at devfs_write_f+0x8b dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 write() at write+0x55 syscall() at syscall+0x1e7 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (4, FreeBSD ELF64, write), rip = 0x8008a33cc, rsp = 0x7fffffffcd98, rbp = 0x800a29800 --- Uptime: 3m12s [...] #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff805f06c9 in boot (howto=260) at /data2v/home/nox/src-r81/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff805f0b1c in panic (fmt=Variable "fmt" is not available. ) at /data2v/home/nox/src-r81/src/sys/kern/kern_shutdown.c:590 #3 0xffffffff808e4d6d in trap_fatal (frame=0x12, eva=Variable "eva" is not available. ) at /data2v/home/nox/src-r81/src/sys/amd64/amd64/trap.c:777 #4 0xffffffff808e5782 in trap (frame=0xffffff80ec0726f0) at /data2v/home/nox/src-r81/src/sys/amd64/amd64/trap.c:588 #5 0xffffffff808ca8b3 in calltrap () at /data2v/home/nox/src-r81/src/sys/amd64/amd64/exception.S:223 #6 0xffffffff80534a28 in rum_setup_tx_desc (sc=Variable "sc" is not available. ) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1016 #7 0xffffffff80535e8f in rum_start (ifp=0xffffff0005e84000) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1265 #8 0xffffffff806a025a in if_transmit (ifp=0xffffff0005e84000, m=Variable "m" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/if.c:3357 #9 0xffffffff806e0cf2 in ieee80211_start (ifp=0xffffff00071eb000) at /data2v/home/nox/src-r81/src/sys/net80211/ieee80211_output.c:362 #10 0xffffffff806a025a in if_transmit (ifp=0xffffff00071eb000, m=Variable "m" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/if.c:3357 #11 0xffffffff806a4c43 in ether_output_frame (ifp=0xffffff00071eb000, m=0xffffff0007594800) ---Type to continue, or q to quit--- at /data2v/home/nox/src-r81/src/sys/net/if_ethersubr.c:452 #12 0xffffffff806a558a in ether_output (ifp=0xffffff00071eb000, m=0xffffff0007594800, dst=0xffffff0005e3e860, ro=Variable "ro" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/if_ethersubr.c:423 #13 0xffffffff80697865 in bpfwrite (dev=Variable "dev" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/bpf.c:939 #14 0xffffffff8057691b in devfs_write_f (fp=0xffffff0005f8f370, uio=0xffffff80ec072b10, cred=Variable "cred" is not available. ) at /data2v/home/nox/src-r81/src/sys/fs/devfs/devfs_vnops.c:1509 #15 0xffffffff80633025 in dofilewrite (td=0xffffff0005f82ba0, fd=4, fp=0xffffff0005f8f370, auio=0xffffff80ec072b10, offset=Variable "offset" is not available. ) at file.h:239 #16 0xffffffff80633330 in kern_writev (td=0xffffff0005f82ba0, fd=4, auio=0xffffff80ec072b10) at /data2v/home/nox/src-r81/src/sys/kern/sys_generic.c:446 #17 0xffffffff806333b5 in write (td=Variable "td" is not available. ) at /data2v/home/nox/src-r81/src/sys/kern/sys_generic.c:362 #18 0xffffffff808e5367 in syscall (frame=0xffffff80ec072c80) at /data2v/home/nox/src-r81/src/sys/amd64/amd64/trap.c:945 #19 0xffffffff808cab91 in Xfast_syscall () at /data2v/home/nox/src-r81/src/sys/amd64/amd64/exception.S:374 #20 0x00000008008a33cc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 6 #6 0xffffffff80534a28 in rum_setup_tx_desc (sc=Variable "sc" is not available. ) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1016 1016 plcp_length = (16 * len + rate - 1) / rate; (kgdb) p rate $1 = 0 (kgdb) l 1011 1012 plcp_length = len & 0xfff; 1013 desc->plcp_length_hi = plcp_length >> 6; 1014 desc->plcp_length_lo = plcp_length & 0x3f; 1015 } else { 1016 plcp_length = (16 * len + rate - 1) / rate; 1017 if (rate == 22) { 1018 remainder = (16 * len) % 22; 1019 if (remainder != 0 && remainder < 7) 1020 desc->plcp_service |= RT2573_PLCP_LENGEXT; (kgdb) up #7 0xffffffff80535e8f in rum_start (ifp=0xffffff0005e84000) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1265 1265 rum_setup_tx_desc(sc, &data->desc, flags, 0, m0->m_pkthdr.len, rate); (kgdb) l 1260 dur = ieee80211_ack_duration(ic->ic_rt, rate, 1261 ic->ic_flags & IEEE80211_F_SHPREAMBLE); 1262 *(uint16_t *)wh->i_dur = htole16(dur); 1263 } 1264 1265 rum_setup_tx_desc(sc, &data->desc, flags, 0, m0->m_pkthdr.len, rate); 1266 1267 DPRINTFN(10, "sending frame len=%d rate=%d\n", 1268 m0->m_pkthdr.len + (int)RT2573_TX_DESC_SIZE, rate); 1269 (kgdb) p wh No symbol "wh" in current context. (kgdb) p m0 Variable "m0" is not available. (kgdb) p tp->ucastrate No symbol "tp" in current context. (kgdb) p ni->nx_tx_rate Variable "ni" is not available. (kgdb) p wh No symbol "wh" in current context. (kgdb) p rate No symbol "rate" in current context. (kgdb) p ni Variable "ni" is not available. (kgdb) up #8 0xffffffff806a025a in if_transmit (ifp=0xffffff0005e84000, m=Variable "m" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/if.c:3357 3357 IFQ_HANDOFF(ifp, m, error); (kgdb) l 3352 static int 3353 if_transmit(struct ifnet *ifp, struct mbuf *m) 3354 { 3355 int error; 3356 3357 IFQ_HANDOFF(ifp, m, error); 3358 return (error); 3359 } 3360 3361 int (kgdb) down #7 0xffffffff80535e8f in rum_start (ifp=0xffffff0005e84000) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1265 1265 rum_setup_tx_desc(sc, &data->desc, flags, 0, m0->m_pkthdr.len, rate); (kgdb) p m $2 = (struct mbuf *) 0xffffff0007584400 (kgdb) p *m $3 = { m_hdr = { mh_next = 0xffffff0007594800, mh_nextpkt = 0x0, mh_data = 0xffffff0007584466 "\b\002", mh_len = 32, mh_flags = 82, mh_type = 1, pad = "\000\000\000\000\000" }, M_dat = { MH = { MH_pkthdr = { rcvif = 0xffffff80007e3000, header = 0x0, len = 131, flowid = 0, csum_flags = 0, csum_data = 0, tso_segsz = 2, PH_vt = { vt_vtag = 3, vt_nrecs = 3 ---Type to continue, or q to quit--- }, tags = { slh_first = 0x0 } }, MH_dat = { MH_ext = { ext_buf = 0x0, ext_free = 0x208000000000000, ext_arg1 = 0x111202bf1c000000, ext_arg2 = 0x22004e9dfe752200, ext_size = 1318977141, ref_cnt = 0x408e8800000003, ext_type = 1998915136 }, MH_databuf = '\0' , "\b\002\000\000\000\034¿\002\022\021\000\"uþ\235N\000\"uþ\235N \000ªª\003\000\000\000\210\216@\000@\006%w\n\000\000\a\n\000\000\006·\214\000\026ê\226x¶\027UøH\200\020 b\0243\000\000\001\001\b\n\000\0025\202¨\fþ³", '\0' } }, M_databuf = "\0000~\000\200ÿÿÿ\000\000\000\000\000\000\000\000\203", '\0' , "\002\000\003", '\0' , "\b\002\000\000\000\0---Type to continue, or q to quit--- 34¿\002\022\021\000\"uþ\235N\000\"uþ\235N \000ªª\003\000\000\000\210\216@\000@\006%w\n\000\000\a\n\000\000\006·\214\000\026ê\226x¶\027UøH\200\020 b\0243\000\000\001\001\b\n\000\0025\202¨\fþ³", '\0' } } (kgdb) p m->M_dat $4 = { MH = { MH_pkthdr = { rcvif = 0xffffff80007e3000, header = 0x0, len = 131, flowid = 0, csum_flags = 0, csum_data = 0, tso_segsz = 2, PH_vt = { vt_vtag = 3, vt_nrecs = 3 }, tags = { slh_first = 0x0 } }, MH_dat = { MH_ext = { ext_buf = 0x0, ext_free = 0x208000000000000, ext_arg1 = 0x111202bf1c000000, ---Type to continue, or q to quit--- ext_arg2 = 0x22004e9dfe752200, ext_size = 1318977141, ref_cnt = 0x408e8800000003, ext_type = 1998915136 }, MH_databuf = '\0' , "\b\002\000\000\000\034¿\002\022\021\000\"uþ\235N\000\"uþ\235N \000ªª\003\000\000\000\210\216@\000@\006%w\n\000\000\a\n\000\000\006·\214\000\026ê\226x¶\027UøH\200\020 b\0243\000\000\001\001\b\n\000\0025\202¨\fþ³", '\0' } }, M_databuf = "\0000~\000\200ÿÿÿ\000\000\000\000\000\000\000\000\203", '\0' , "\002\000\003", '\0' , "\b\002\000\000\000\034¿\002\022\021\000\"uþ\235N\000\"uþ\235N \000ªª\003\000\000\000\210\216@\000@\006%w\n\000\000\a\n\000\000\006·\214\000\026ê\226x¶\027UøH\200\020 b\0243\000\000\001\001\b\n\000\0025\202¨\fþ³", '\0' } (kgdb) p m->M_dat.MH.MH_pkthdr $5 = { rcvif = 0xffffff80007e3000, header = 0x0, len = 131, flowid = 0, csum_flags = 0, csum_data = 0, tso_segsz = 2, PH_vt = { vt_vtag = 3, vt_nrecs = 3 }, tags = { slh_first = 0x0 } } (kgdb) p m->M_dat.MH.MH_pkthdr.rcvif $6 = (struct ifnet *) 0xffffff80007e3000 (kgdb) p ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_txrate $7 = 0 (kgdb) p ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_chan $8 = (struct ieee80211_channel *) 0xffffff80007df300 (kgdb) p *((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_chan $9 = { ic_flags = 1152, ic_freq = 2437, ic_ieee = 6 '\006', ic_maxregpower = 0 '\0', ic_maxpower = 0 '\0', ic_minpower = 0 '\0', ic_state = 0 '\0', ic_extieee = 0 '\0', ic_maxantgain = 0 '\0', ic_pad = 0 '\0', ic_devdata = 0 } (kgdb) p vap No symbol "vap" in current context. (kgdb) p *((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap $10 = { iv_media = { ifm_mask = 0, ifm_media = 0, ifm_cur = 0xffffff0005ef48e0, ifm_list = { lh_first = 0xffffff0005ef4520 }, ifm_change = 0xffffffff806b7980 , ifm_status = 0xffffffff806b7f70 }, iv_ifp = 0xffffff00071eb000, iv_rawbpf = 0xffffff0005f20680, iv_sysctl = 0xffffff0005e3e850, iv_oid = 0xffffff0005f20200, iv_next = { tqe_next = 0x0, tqe_prev = 0xffffff80007df038 }, iv_ic = 0xffffff80007df000, iv_debug = 0, iv_stats = { is_rx_badversion = 0, ---Type to continue, or q to quit--- is_rx_tooshort = 0, is_rx_wrongbss = 0, is_rx_dup = 0, is_rx_wrongdir = 0, is_rx_mcastecho = 0, is_rx_notassoc = 0, is_rx_noprivacy = 0, is_rx_unencrypted = 0, is_rx_wepfail = 0, is_rx_decap = 0, is_rx_mgtdiscard = 0, is_rx_ctl = 0, is_rx_beacon = 3, is_rx_rstoobig = 0, is_rx_elem_missing = 0, is_rx_elem_toobig = 0, is_rx_elem_toosmall = 0, is_rx_elem_unknown = 0, is_rx_badchan = 0, is_rx_chanmismatch = 1, is_rx_nodealloc = 0, is_rx_ssidmismatch = 0, is_rx_auth_unsupported = 0, ---Type to continue, or q to quit--- is_rx_auth_fail = 0, is_rx_auth_countermeasures = 0, is_rx_assoc_bss = 0, is_rx_assoc_notauth = 0, is_rx_assoc_capmismatch = 0, is_rx_assoc_norate = 0, is_rx_assoc_badwpaie = 0, is_rx_deauth = 0, is_rx_disassoc = 0, is_rx_badsubtype = 0, is_rx_nobuf = 0, is_rx_decryptcrc = 0, is_rx_ahdemo_mgt = 0, is_rx_bad_auth = 0, is_rx_unauth = 0, is_rx_badkeyid = 0, is_rx_ccmpreplay = 0, is_rx_ccmpformat = 0, is_rx_ccmpmic = 0, is_rx_tkipreplay = 0, is_rx_tkipformat = 0, is_rx_tkipmic = 0, is_rx_tkipicv = 0, ---Type to continue, or q to quit--- is_rx_badcipher = 0, is_rx_nocipherctx = 0, is_rx_acl = 0, is_tx_nobuf = 0, is_tx_nonode = 0, is_tx_unknownmgt = 0, is_tx_badcipher = 0, is_tx_nodefkey = 0, is_tx_noheadroom = 0, is_tx_fragframes = 0, is_tx_frags = 0, is_scan_active = 1, is_scan_passive = 0, is_node_timeout = 0, is_crypto_nomem = 0, is_crypto_tkip = 3, is_crypto_tkipenmic = 3, is_crypto_tkipdemic = 0, is_crypto_tkipcm = 0, is_crypto_ccmp = 0, is_crypto_wep = 0, is_crypto_setkey_cipher = 0, is_crypto_setkey_nokey = 0, ---Type to continue, or q to quit--- is_crypto_delkey = 0, is_crypto_badcipher = 0, is_crypto_nocipher = 0, is_crypto_attachfail = 0, is_crypto_swfallback = 0, is_crypto_keyfail = 0, is_crypto_enmicfail = 0, is_ibss_capmismatch = 0, is_ibss_norate = 0, is_ps_unassoc = 0, is_ps_badaid = 0, is_ps_qempty = 0, is_ff_badhdr = 0, is_ff_tooshort = 0, is_ff_split = 0, is_ff_decap = 0, is_ff_encap = 0, is_rx_badbintval = 0, is_rx_demicfail = 0, is_rx_defrag = 0, is_rx_mgmt = 7, is_rx_action = 0, is_amsdu_tooshort = 0, ---Type to continue, or q to quit--- is_amsdu_split = 0, is_amsdu_decap = 0, is_amsdu_encap = 0, is_ampdu_bar_bad = 0, is_ampdu_bar_oow = 0, is_ampdu_bar_move = 0, is_ampdu_bar_rx = 0, is_ampdu_rx_flush = 0, is_ampdu_rx_oor = 0, is_ampdu_rx_copy = 0, is_ampdu_rx_drop = 0, is_tx_badstate = 0, is_tx_notassoc = 0, is_tx_classify = 0, is_dwds_mcast = 0, is_dwds_qdrop = 0, is_ht_assoc_nohtcap = 0, is_ht_assoc_downgrade = 0, is_ht_assoc_norate = 0, is_ampdu_rx_age = 0, is_ampdu_rx_move = 0, is_addba_reject = 0, is_addba_norequest = 0, ---Type to continue, or q to quit--- is_addba_badtoken = 0, is_addba_badpolicy = 0, is_ampdu_stop = 0, is_ampdu_stop_failed = 0, is_ampdu_rx_reorder = 0, is_scan_bg = 0, is_rx_deauth_code = 0 '\0', is_rx_disassoc_code = 0 '\0', is_rx_authfail_code = 0 '\0', is_beacon_miss = 0, is_rx_badstate = 0, is_ff_flush = 0, is_tx_ctl = 0, is_ampdu_rexmt = 0, is_ampdu_rexmt_fail = 0, is_mesh_wrongmesh = 0, is_mesh_nolink = 0, is_mesh_fwd_ttl = 0, is_mesh_fwd_nobuf = 0, is_mesh_fwd_tooshort = 0, is_mesh_fwd_disabled = 0, is_mesh_fwd_nopath = 0, is_hwmp_wrongseq = 0, ---Type to continue, or q to quit--- is_hwmp_rootreqs = 0, is_hwmp_rootrann = 0, is_mesh_badae = 0, is_mesh_rtaddfailed = 0, is_mesh_notproxy = 0, is_rx_badalign = 0, is_hwmp_proxy = 0, is_spare = {0 } }, iv_myaddr = "\000\"uþ\235N", iv_flags = 1090781200, iv_flags_ext = 1026, iv_flags_ht = 0, iv_flags_ven = 0, iv_caps = 562095104, iv_htcaps = 0, iv_opmode = IEEE80211_M_HOSTAP, iv_state = IEEE80211_S_RUN, iv_nstate = IEEE80211_S_RUN, iv_nstate_arg = -1, iv_nstate_task = { ta_link = { stqe_next = 0x0 ---Type to continue, or q to quit--- }, ta_pending = 0, ta_priority = 0, ta_func = 0xffffffff806e66d0 , ta_context = 0xffffff0005dfe000 }, iv_swbmiss_task = { ta_link = { stqe_next = 0x0 }, ta_pending = 0, ta_priority = 0, ta_func = 0xffffffff806e49f0 , ta_context = 0xffffff0005dfe000 }, iv_mgtsend = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 ---Type to continue, or q to quit--- } }, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0 }, iv_inact_init = 2, iv_inact_auth = 12, iv_inact_run = 20, iv_inact_probe = 2, iv_des_nssid = 1, iv_des_ssid = {{ len = 8, ssid = "XXX", '\0' }}, iv_des_bssid = "\000\000\000\000\000", iv_des_chan = 0xffff, iv_des_mode = 0, iv_nicknamelen = 0, iv_nickname = '\0' , ---Type to continue, or q to quit--- iv_bgscanidle = 250, iv_bgscanintvl = 300000, iv_scanvalid = 60000, iv_scanreq_duration = 0, iv_scanreq_mindwell = 0, iv_scanreq_maxdwell = 0, iv_scanreq_flags = 0, iv_scanreq_nssid = 0 '\0', iv_scanreq_ssid = {{ len = 0, ssid = '\0' }}, iv_roaming = IEEE80211_ROAMING_AUTO, iv_roamparms = {{ rssi = 0 '\0', rate = 0 '\0', pad = 0 }, { rssi = 14 '\016', rate = 24 '\030', pad = 0 }, { rssi = 14 '\016', ---Type to continue, or q to quit--- rate = 2 '\002', pad = 0 }, { rssi = 14 '\016', rate = 10 '\n', pad = 0 }, { rssi = 0 '\0', rate = 0 '\0', pad = 0 }, { rssi = 14 '\016', rate = 24 '\030', pad = 0 }, { rssi = 14 '\016', rate = 24 '\030', pad = 0 }, { rssi = 14 '\016', rate = 24 '\030', pad = 0 }, { ---Type to continue, or q to quit--- rssi = 14 '\016', rate = 129 '\201', pad = 0 }, { rssi = 14 '\016', rate = 129 '\201', pad = 0 }, { rssi = 14 '\016', rate = 12 '\f', pad = 0 }, { rssi = 14 '\016', rate = 6 '\006', pad = 0 }}, iv_bmissthreshold = 7 '\a', iv_bmiss_count = 0 '\0', iv_bmiss_max = 2, iv_swbmiss_count = 0, iv_swbmiss_period = 0, iv_swbmiss = { c_links = { ---Type to continue, or q to quit--- sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0 }, iv_ampdu_rxmax = 0, iv_ampdu_density = 0, iv_ampdu_limit = 0, iv_amsdu_limit = 0, iv_ampdu_mintraffic = {64, 128, 32, 32}, iv_aid_bitmap = 0xffffff0005e3e750, iv_max_aid = 128, iv_sta_assoc = 1, ---Type to continue, or q to quit--- iv_ps_sta = 0, iv_ps_pending = 0, iv_txseq = 0, iv_tim_len = 16, iv_tim_bitmap = 0xffffff0005e3e740 "", iv_dtim_period = 1 '\001', iv_dtim_count = 0 '\0', iv_csa_count = 0, iv_bss = 0xffffff80007f6000, iv_txparms = {{ ucastrate = 0 '\0', mgmtrate = 0 '\0', mcastrate = 0 '\0', maxretry = 0 '\0' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', ---Type to continue, or q to quit--- maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 0 '\0', mcastrate = 0 '\0', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', ---Type to continue, or q to quit--- mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 6 '\006', mcastrate = 6 '\006', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 3 '\003', mcastrate = 3 '\003', maxretry = 6 '\006' ---Type to continue, or q to quit--- }}, iv_rtsthreshold = 2346, iv_fragthreshold = 2346, iv_inact_timer = 0, iv_appie_beacon = 0x0, iv_appie_probereq = 0x0, iv_appie_proberesp = 0x0, iv_appie_assocreq = 0x0, iv_appie_assocresp = 0x0, iv_appie_wpa = 0xffffff0005ef43a0, iv_wpa_ie = 0x0, iv_rsn_ie = 0xffffff0005ef43a2 "0\030\001", iv_max_keyix = 4, iv_def_txkey = 1, iv_nw_keys = {{ wk_keylen = 0 '\0', wk_pad = 0 '\0', wk_flags = 3, wk_keyix = 65535, wk_rxkeyix = 65535, wk_key = '\0' , wk_keyrsc = {0 }, wk_keytsc = 0, ---Type to continue, or q to quit--- wk_cipher = 0xffffffff809fb0c0, wk_private = 0xffffff0005dfe000, wk_macaddr = "\000\000\000\000\000" }, { wk_keylen = 16 '\020', wk_pad = 0 '\0', wk_flags = 501, wk_keyix = 1, wk_rxkeyix = 65535, wk_key = "XXX", wk_keyrsc = {0 }, wk_keytsc = 4, wk_cipher = 0xffffffff809fb180, wk_private = 0xffffff0005f22e00, wk_macaddr = "ÿÿÿÿÿÿ" }, { wk_keylen = 0 '\0', wk_pad = 0 '\0', wk_flags = 3, wk_keyix = 65535, wk_rxkeyix = 65535, wk_key = '\0' , wk_keyrsc = {0 }, ---Type to continue, or q to quit--- wk_keytsc = 0, wk_cipher = 0xffffffff809fb0c0, wk_private = 0xffffff0005dfe000, wk_macaddr = "\000\000\000\000\000" }, { wk_keylen = 0 '\0', wk_pad = 0 '\0', wk_flags = 3, wk_keyix = 65535, wk_rxkeyix = 65535, wk_key = '\0' , wk_keyrsc = {0 }, wk_keytsc = 0, wk_cipher = 0xffffffff809fb0c0, wk_private = 0xffffff0005dfe000, wk_macaddr = "\000\000\000\000\000" }}, iv_key_alloc = 0xffffffff806bc2c0 , iv_key_delete = 0xffffffff806bc310 , iv_key_set = 0xffffffff806bc320 , iv_key_update_begin = 0xffffffff806bc330 , iv_key_update_end = 0xffffffff806bc330 , iv_auth = 0xffffffff8103a0e0, ---Type to continue, or q to quit--- iv_ec = 0x0, iv_acl = 0x0, iv_as = 0x0, iv_rate = 0xffffffff809fa9e0, iv_rs = 0xffffff0005e3e780, iv_tdma = 0x0, iv_mesh = 0x0, iv_hwmp = 0x0, iv_opdetach = 0xffffffff806c5130 , iv_input = 0xffffffff806c7e70 , iv_recv_mgmt = 0xffffffff806c5d30 , iv_recv_ctl = 0xffffffff806c54c0 , iv_deliver_data = 0xffffffff806c52b0 , iv_bmiss = 0, iv_reset = 0xffffffff806b76c0 , iv_update_beacon = 0xffffffff806e4640 , iv_update_ps = 0xffffffff806e3860 , iv_set_tim = 0xffffffff806e41d0 , iv_newstate = 0xffffffff805382a0 , iv_output = 0xffffffff806a50d0 , iv_spare = {0, 0, 0, 0, 0, 0} } (kgdb) p ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap) $11 = (struct ieee80211vap *) 0xffffff0005dfe000 (kgdb) p ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms [1] $12 = {{ ucastrate = 0 '\0', mgmtrate = 0 '\0', mcastrate = 0 '\0', maxretry = 0 '\0' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 0 '\0', ---Type to continue, or q to quit--- mcastrate = 0 '\0', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ---Type to continue, or q to quit--- ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 6 '\006', mcastrate = 6 '\006', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 3 '\003', mcastrate = 3 '\003', maxretry = 6 '\006' }} (kgdb) p (((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap)->iv_txxparms $13 = {{ ucastrate = 0 '\0', mgmtrate = 0 '\0', mcastrate = 0 '\0', maxretry = 0 '\0' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 0 '\0', ---Type to continue, or q to quit--- mcastrate = 0 '\0', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ---Type to continue, or q to quit--- ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 6 '\006', mcastrate = 6 '\006', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 3 '\003', mcastrate = 3 '\003', maxretry = 6 '\006' }} (kgdb) p *((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif) $14 = { ni_vap = 0xffffff0005dfe000, ni_ic = 0xffffff80007df000, ni_table = 0xffffff80007e07b0, ni_list = { tqe_next = 0x0, tqe_prev = 0xffffff80007f6018 }, ni_hash = { le_next = 0x0, le_prev = 0xffffff80007e0880 }, ni_refcnt = 2, ni_scangen = 0, ni_flags = 131108, ni_associd = 49153, ni_vlan = 0, ni_txpower = 100, ni_authmode = 3 '\003', ni_ath_flags = 0 '\0', ni_ath_defkeyix = 32767, ni_txparms = 0xffffff0005dfe4fc, ni_jointime = 192, ---Type to continue, or q to quit--- ni_challenge = 0x0, ni_ies = { wpa_ie = 0x0, rsn_ie = 0xffffff0005f2a49a "0\024\001", wme_ie = 0x0, ath_ie = 0x0, htcap_ie = 0x0, htinfo_ie = 0x0, tdma_ie = 0x0, meshid_ie = 0x0, spare = {0x0, 0x0, 0x0, 0x0}, data = 0xffffff0005f2a480 "", len = 48 }, ni_txseqs = {0 , 3}, ni_rxseqs = {0 , 16}, ni_rxfragstamp = 0, ni_rxfrag = {0x0, 0x0, 0x0}, ni_ucastkey = { wk_keylen = 0 '\0', wk_pad = 0 '\0', wk_flags = 3, wk_keyix = 65535, ---Type to continue, or q to quit--- wk_rxkeyix = 65535, wk_key = '\0' , wk_keyrsc = {0 }, wk_keytsc = 0, wk_cipher = 0xffffffff809fb0c0, wk_private = 0xffffff0005dfe000, wk_macaddr = "\000\000\000\000\000" }, ni_avgrssi = 2176, ni_noise = -95 '¡', ni_macaddr = "\000\034¿\002\022\021", ni_bssid = "\000\"uþ\235N", ni_tstamp = { data = "\000\000\000\000\000\000\000", tsf = 0 }, ni_intval = 1, ni_capinfo = 1073, ni_esslen = 0 '\0', ni_essid = '\0' , ni_rates = { rs_nrates = 12 '\f', rs_rates = "\202\204\213\f\022\226\030$0H`l\000\000" ---Type to continue, or q to quit--- }, ni_chan = 0xffffff80007df300, ni_fhdwell = 0, ni_fhindex = 0 '\0', ni_erp = 0, ni_timoff = 0, ni_dtim_period = 0 '\0', ni_dtim_count = 0 '\0', ni_meshidlen = 0 '\0', ni_meshid = '\0' , ni_mlstate = IEEE80211_NODE_MESH_IDLE, ni_mllid = 0, ni_mlpid = 0, ni_mltimer = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, ---Type to continue, or q to quit--- c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, ni_mlrcnt = 0 '\0', ni_mltval = 0 '\0', ni_htcap = 0, ni_htparam = 0 '\0', ni_htctlchan = 0 '\0', ni_ht2ndchan = 0 '\0', ni_htopmode = 0 '\0', ni_htstbc = 0 '\0', ni_chw = 0 '\0', ni_htrates = { rs_nrates = 0 '\0', rs_rates = '\0' }, ni_tx_ampdu = {{ txa_ni = 0x0, txa_flags = 0, ---Type to continue, or q to quit--- txa_ac = 0 '\0', txa_token = 0 '\0', txa_lastsample = 0, txa_pkts = 0, txa_avgpps = 0, txa_qbytes = 0, txa_qframes = 0, txa_start = 0, txa_seqpending = 0, txa_wnd = 0, txa_attempts = 0 '\0', txa_nextrequest = 0, txa_timer = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, ---Type to continue, or q to quit--- c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, txa_private = 0x0, txa_pad = {0, 0, 0, 0} }, { txa_ni = 0x0, txa_flags = 0, txa_ac = 0 '\0', txa_token = 0 '\0', txa_lastsample = 0, txa_pkts = 0, txa_avgpps = 0, txa_qbytes = 0, txa_qframes = 0, txa_start = 0, txa_seqpending = 0, txa_wnd = 0, txa_attempts = 0 '\0', txa_nextrequest = 0, ---Type to continue, or q to quit--- txa_timer = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, txa_private = 0x0, txa_pad = {0, 0, 0, 0} }, { txa_ni = 0x0, txa_flags = 0, txa_ac = 0 '\0', ---Type to continue, or q to quit--- txa_token = 0 '\0', txa_lastsample = 0, txa_pkts = 0, txa_avgpps = 0, txa_qbytes = 0, txa_qframes = 0, txa_start = 0, txa_seqpending = 0, txa_wnd = 0, txa_attempts = 0 '\0', txa_nextrequest = 0, txa_timer = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, c_arg = 0x0, ---Type to continue, or q to quit--- c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, txa_private = 0x0, txa_pad = {0, 0, 0, 0} }, { txa_ni = 0x0, txa_flags = 0, txa_ac = 0 '\0', txa_token = 0 '\0', txa_lastsample = 0, txa_pkts = 0, txa_avgpps = 0, txa_qbytes = 0, txa_qframes = 0, txa_start = 0, txa_seqpending = 0, txa_wnd = 0, txa_attempts = 0 '\0', txa_nextrequest = 0, txa_timer = { ---Type to continue, or q to quit--- c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, txa_private = 0x0, txa_pad = {0, 0, 0, 0} }}, ni_rx_ampdu = {{ rxa_flags = 0, rxa_qbytes = 0, rxa_qframes = 0, ---Type to continue, or q to quit--- rxa_seqstart = 0, rxa_start = 0, rxa_wnd = 0, rxa_age = 0, rxa_nframes = 0, rxa_m = {0x0 }, rxa_pad = {0, 0, 0, 0} } }, ni_inact = 2, ni_inact_reload = 12, ni_txrate = 0, ni_psq = { psq_lock = { lock_object = { lo_name = 0xffffffff809653c5 "unknown", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0 }, mtx_lock = 4 }, psq_len = 0, psq_maxlen = 50, ---Type to continue, or q to quit--- psq_drops = 0, psq_head = {{ head = 0x0, tail = 0x0, len = 0 }, { head = 0x0, tail = 0x0, len = 0 }} }, ni_stats = { ns_rx_data = 1, ns_rx_mgmt = 1, ns_rx_ctrl = 0, ns_rx_ucast = 0, ns_rx_mcast = 1, ns_rx_bytes = 20, ns_rx_beacons = 0, ns_rx_proberesp = 0, ns_rx_dup = 0, ns_rx_noprivacy = 0, ns_rx_wepfail = 0, ---Type to continue, or q to quit--- ns_rx_demicfail = 0, ns_rx_decap = 0, ns_rx_defrag = 0, ns_rx_disassoc = 0, ns_rx_deauth = 0, ns_rx_action = 0, ns_rx_decryptcrc = 0, ns_rx_unauth = 0, ns_rx_unencrypted = 0, ns_rx_drop = 0, ns_tx_data = 1, ns_tx_mgmt = 2, ns_tx_ctrl = 0, ns_tx_ucast = 1, ns_tx_mcast = 0, ns_tx_bytes = 107, ns_tx_probereq = 0, ns_tx_novlantag = 0, ns_tx_vlanmismatch = 0, ns_ps_discard = 0, ns_tx_assoc = 1, ns_tx_assoc_fail = 0, ns_tx_auth = 1, ---Type to continue, or q to quit--- ns_tx_auth_fail = 0, ns_tx_deauth = 0, ns_tx_deauth_code = 0, ns_tx_disassoc = 0, ns_tx_disassoc_code = 0, ns_spare = {0, 0, 0, 0, 0, 0, 0, 0} }, ni_wdsvap = 0x0, ni_rctls = 0x0, ni_spare = {0, 0, 0} } (kgdb) q And here comes the patch: (the first hunk is an unrelated stable/8 commit since I'm on the 8.1 release branch atm.) [2] Index: src/sys/dev/usb/wlan/if_rum.c =================================================================== RCS file: /home/scvs/src/sys/dev/usb/wlan/if_rum.c,v retrieving revision 1.20.2.7.2.1 diff -u -p -r1.20.2.7.2.1 if_rum.c --- src/sys/dev/usb/wlan/if_rum.c 14 Jun 2010 02:09:06 -0000 1.20.2.7.2.1 +++ src/sys/dev/usb/wlan/if_rum.c 1 Aug 2010 14:31:27 -0000 @@ -1049,7 +1049,7 @@ rum_sendprot(struct rum_softc *sc, ackrate = ieee80211_ack_rate(ic->ic_rt, rate); isshort = (ic->ic_flags & IEEE80211_F_SHPREAMBLE) != 0; - dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort); + dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort) + ieee80211_ack_duration(ic->ic_rt, rate, isshort); flags = RT2573_TX_MORE_FRAG; if (prot == IEEE80211_PROT_RTSCTS) { @@ -1216,6 +1216,17 @@ rum_tx_data(struct rum_softc *sc, struct rate = tp->ucastrate; else rate = ni->ni_txrate; +#if 1 + static int lastrate = 0; + if (rate == 0) { + /* XXX */ + rate = 72; + printf("wlan: rate = 0! using %d\n", rate); + } else if (rate != lastrate) { + printf("wlan: rate = %d\n", rate); + lastrate = rate; + } +#endif if (wh->i_fc[1] & IEEE80211_FC1_WEP) { k = ieee80211_crypto_encap(ni, m0); Using that patch I get: Aug 2 20:15:06 triton8 kernel: wlan: rate = 0! using 72 Aug 2 20:15:22 triton8 last message repeated 11 times Aug 2 20:15:22 triton8 kernel: Aug 2 20:15:24 triton8 kernel: wlan: rate = 0! using 72 Aug 2 20:15:26 triton8 last message repeated 16 times Aug 2 20:21:03 triton8 last message repeated 2 times Aug 2 20:22:46 triton8 last message repeated 19 times HTH, Juergen From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 20:30:14 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B6771065673 for ; Wed, 4 Aug 2010 20:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6218FC1D for ; Wed, 4 Aug 2010 20:30:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o74KUEn4083994 for ; Wed, 4 Aug 2010 20:30:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o74KUEGM083991; Wed, 4 Aug 2010 20:30:14 GMT (envelope-from gnats) Date: Wed, 4 Aug 2010 20:30:14 GMT Message-Id: <201008042030.o74KUEGM083991@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Juergen Lock Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Juergen Lock List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 20:30:14 -0000 The following reply was made to PR kern/149185; it has been noted by GNATS. From: Juergen Lock To: bug-followup@FreeBSD.org Cc: freebsd-net@FreeBSD.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Wed, 4 Aug 2010 22:02:35 +0200 (CEST) Hi! Regarding the 8.1 if_rum(4) panics... I got a similar one, extracted a dump and tried to gather some info for someone who knows the code: The zero divide fault was because (apparently) rate was unitialized, as is ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. [1] Simply setting rate to something non-zero (I first tried 0xff, then 72 since that was used in station mode) without changing anything else stopped the panics but as probably to be expected, the wifi only partly worked, clients frequently disconnected. (I'll put the patch at the end of the mail. [2]) # ifconfig wlan0 create wlandev rum0 wlanmode ap ssid XXX # /etc/rc.d/hostapd onestart Starting hostapd. Configuration file: /etc/hostapd.conf Using interface wlan0 with hwaddr 00:22:75:fe:9d:4e and ssid 'XXX' bind(PF_UNIX): Address already in use Failed to setup control interface /etc/rc.d/hostapd: WARNING: failed to start hostapd # /etc/rc.d/hostapd onestart Starting hostapd. Configuration file: /etc/hostapd.conf Using interface wlan0 with hwaddr 00:22:75:fe:9d:4e and ssid 'XXX' # [...] Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80534a28 stack pointer = 0x28:0xffffff80ec0727a0 frame pointer = 0x28:0xffffff80ec0727b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 607 (hostapd) trap number = 18 panic: integer divide fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2ad trap() at trap+0x102 calltrap() at calltrap+0x8 --- trap 0x12, rip = 0xffffffff80534a28, rsp = 0xffffff80ec0727a0, rbp = 0xffffff80ec0727b0 --- rum_setup_tx_desc() at rum_setup_tx_desc+0x68 rum_start() at rum_start+0x1af if_transmit() at if_transmit+0xea ieee80211_start() at ieee80211_start+0x542 if_transmit() at if_transmit+0xea ether_output_frame() at ether_output_frame+0x33 ether_output() at ether_output+0x4ba bpfwrite() at bpfwrite+0x3a5 devfs_write_f() at devfs_write_f+0x8b dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 write() at write+0x55 syscall() at syscall+0x1e7 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (4, FreeBSD ELF64, write), rip = 0x8008a33cc, rsp = 0x7fffffffcd98, rbp = 0x800a29800 --- Uptime: 3m12s [...] #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff805f06c9 in boot (howto=260) at /data2v/home/nox/src-r81/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff805f0b1c in panic (fmt=Variable "fmt" is not available. ) at /data2v/home/nox/src-r81/src/sys/kern/kern_shutdown.c:590 #3 0xffffffff808e4d6d in trap_fatal (frame=0x12, eva=Variable "eva" is not available. ) at /data2v/home/nox/src-r81/src/sys/amd64/amd64/trap.c:777 #4 0xffffffff808e5782 in trap (frame=0xffffff80ec0726f0) at /data2v/home/nox/src-r81/src/sys/amd64/amd64/trap.c:588 #5 0xffffffff808ca8b3 in calltrap () at /data2v/home/nox/src-r81/src/sys/amd64/amd64/exception.S:223 #6 0xffffffff80534a28 in rum_setup_tx_desc (sc=Variable "sc" is not available. ) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1016 #7 0xffffffff80535e8f in rum_start (ifp=0xffffff0005e84000) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1265 #8 0xffffffff806a025a in if_transmit (ifp=0xffffff0005e84000, m=Variable "m" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/if.c:3357 #9 0xffffffff806e0cf2 in ieee80211_start (ifp=0xffffff00071eb000) at /data2v/home/nox/src-r81/src/sys/net80211/ieee80211_output.c:362 #10 0xffffffff806a025a in if_transmit (ifp=0xffffff00071eb000, m=Variable "m" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/if.c:3357 #11 0xffffffff806a4c43 in ether_output_frame (ifp=0xffffff00071eb000, m=0xffffff0007594800) ---Type to continue, or q to quit--- at /data2v/home/nox/src-r81/src/sys/net/if_ethersubr.c:452 #12 0xffffffff806a558a in ether_output (ifp=0xffffff00071eb000, m=0xffffff0007594800, dst=0xffffff0005e3e860, ro=Variable "ro" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/if_ethersubr.c:423 #13 0xffffffff80697865 in bpfwrite (dev=Variable "dev" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/bpf.c:939 #14 0xffffffff8057691b in devfs_write_f (fp=0xffffff0005f8f370, uio=0xffffff80ec072b10, cred=Variable "cred" is not available. ) at /data2v/home/nox/src-r81/src/sys/fs/devfs/devfs_vnops.c:1509 #15 0xffffffff80633025 in dofilewrite (td=0xffffff0005f82ba0, fd=4, fp=0xffffff0005f8f370, auio=0xffffff80ec072b10, offset=Variable "offset" is not available. ) at file.h:239 #16 0xffffffff80633330 in kern_writev (td=0xffffff0005f82ba0, fd=4, auio=0xffffff80ec072b10) at /data2v/home/nox/src-r81/src/sys/kern/sys_generic.c:446 #17 0xffffffff806333b5 in write (td=Variable "td" is not available. ) at /data2v/home/nox/src-r81/src/sys/kern/sys_generic.c:362 #18 0xffffffff808e5367 in syscall (frame=0xffffff80ec072c80) at /data2v/home/nox/src-r81/src/sys/amd64/amd64/trap.c:945 #19 0xffffffff808cab91 in Xfast_syscall () at /data2v/home/nox/src-r81/src/sys/amd64/amd64/exception.S:374 #20 0x00000008008a33cc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 6 #6 0xffffffff80534a28 in rum_setup_tx_desc (sc=Variable "sc" is not available. ) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1016 1016 plcp_length = (16 * len + rate - 1) / rate; (kgdb) p rate $1 = 0 (kgdb) l 1011 1012 plcp_length = len & 0xfff; 1013 desc->plcp_length_hi = plcp_length >> 6; 1014 desc->plcp_length_lo = plcp_length & 0x3f; 1015 } else { 1016 plcp_length = (16 * len + rate - 1) / rate; 1017 if (rate == 22) { 1018 remainder = (16 * len) % 22; 1019 if (remainder != 0 && remainder < 7) 1020 desc->plcp_service |= RT2573_PLCP_LENGEXT; (kgdb) up #7 0xffffffff80535e8f in rum_start (ifp=0xffffff0005e84000) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1265 1265 rum_setup_tx_desc(sc, &data->desc, flags, 0, m0->m_pkthdr.len, rate); (kgdb) l 1260 dur = ieee80211_ack_duration(ic->ic_rt, rate, 1261 ic->ic_flags & IEEE80211_F_SHPREAMBLE); 1262 *(uint16_t *)wh->i_dur = htole16(dur); 1263 } 1264 1265 rum_setup_tx_desc(sc, &data->desc, flags, 0, m0->m_pkthdr.len, rate); 1266 1267 DPRINTFN(10, "sending frame len=%d rate=%d\n", 1268 m0->m_pkthdr.len + (int)RT2573_TX_DESC_SIZE, rate); 1269 (kgdb) p wh No symbol "wh" in current context. (kgdb) p m0 Variable "m0" is not available. (kgdb) p tp->ucastrate No symbol "tp" in current context. (kgdb) p ni->nx_tx_rate Variable "ni" is not available. (kgdb) p wh No symbol "wh" in current context. (kgdb) p rate No symbol "rate" in current context. (kgdb) p ni Variable "ni" is not available. (kgdb) up #8 0xffffffff806a025a in if_transmit (ifp=0xffffff0005e84000, m=Variable "m" is not available. ) at /data2v/home/nox/src-r81/src/sys/net/if.c:3357 3357 IFQ_HANDOFF(ifp, m, error); (kgdb) l 3352 static int 3353 if_transmit(struct ifnet *ifp, struct mbuf *m) 3354 { 3355 int error; 3356 3357 IFQ_HANDOFF(ifp, m, error); 3358 return (error); 3359 } 3360 3361 int (kgdb) down #7 0xffffffff80535e8f in rum_start (ifp=0xffffff0005e84000) at /data2v/home/nox/src-r81/src/sys/dev/usb/wlan/if_rum.c:1265 1265 rum_setup_tx_desc(sc, &data->desc, flags, 0, m0->m_pkthdr.len, rate); (kgdb) p m $2 = (struct mbuf *) 0xffffff0007584400 (kgdb) p *m $3 = { m_hdr = { mh_next = 0xffffff0007594800, mh_nextpkt = 0x0, mh_data = 0xffffff0007584466 "\b\002", mh_len = 32, mh_flags = 82, mh_type = 1, pad = "\000\000\000\000\000" }, M_dat = { MH = { MH_pkthdr = { rcvif = 0xffffff80007e3000, header = 0x0, len = 131, flowid = 0, csum_flags = 0, csum_data = 0, tso_segsz = 2, PH_vt = { vt_vtag = 3, vt_nrecs = 3 ---Type to continue, or q to quit--- }, tags = { slh_first = 0x0 } }, MH_dat = { MH_ext = { ext_buf = 0x0, ext_free = 0x208000000000000, ext_arg1 = 0x111202bf1c000000, ext_arg2 = 0x22004e9dfe752200, ext_size = 1318977141, ref_cnt = 0x408e8800000003, ext_type = 1998915136 }, MH_databuf = '\0' , "\b\002\000\000\000\034¿\002\022\021\000\"uþ\235N\000\"uþ\235N \000ªª\003\000\000\000\210\216@\000@\006%w\n\000\000\a\n\000\000\006·\214\000\026ê\226x¶\027UøH\200\020 b\0243\000\000\001\001\b\n\000\0025\202¨\fþ³", '\0' } }, M_databuf = "\0000~\000\200ÿÿÿ\000\000\000\000\000\000\000\000\203", '\0' , "\002\000\003", '\0' , "\b\002\000\000\000\0---Type to continue, or q to quit--- 34¿\002\022\021\000\"uþ\235N\000\"uþ\235N \000ªª\003\000\000\000\210\216@\000@\006%w\n\000\000\a\n\000\000\006·\214\000\026ê\226x¶\027UøH\200\020 b\0243\000\000\001\001\b\n\000\0025\202¨\fþ³", '\0' } } (kgdb) p m->M_dat $4 = { MH = { MH_pkthdr = { rcvif = 0xffffff80007e3000, header = 0x0, len = 131, flowid = 0, csum_flags = 0, csum_data = 0, tso_segsz = 2, PH_vt = { vt_vtag = 3, vt_nrecs = 3 }, tags = { slh_first = 0x0 } }, MH_dat = { MH_ext = { ext_buf = 0x0, ext_free = 0x208000000000000, ext_arg1 = 0x111202bf1c000000, ---Type to continue, or q to quit--- ext_arg2 = 0x22004e9dfe752200, ext_size = 1318977141, ref_cnt = 0x408e8800000003, ext_type = 1998915136 }, MH_databuf = '\0' , "\b\002\000\000\000\034¿\002\022\021\000\"uþ\235N\000\"uþ\235N \000ªª\003\000\000\000\210\216@\000@\006%w\n\000\000\a\n\000\000\006·\214\000\026ê\226x¶\027UøH\200\020 b\0243\000\000\001\001\b\n\000\0025\202¨\fþ³", '\0' } }, M_databuf = "\0000~\000\200ÿÿÿ\000\000\000\000\000\000\000\000\203", '\0' , "\002\000\003", '\0' , "\b\002\000\000\000\034¿\002\022\021\000\"uþ\235N\000\"uþ\235N \000ªª\003\000\000\000\210\216@\000@\006%w\n\000\000\a\n\000\000\006·\214\000\026ê\226x¶\027UøH\200\020 b\0243\000\000\001\001\b\n\000\0025\202¨\fþ³", '\0' } (kgdb) p m->M_dat.MH.MH_pkthdr $5 = { rcvif = 0xffffff80007e3000, header = 0x0, len = 131, flowid = 0, csum_flags = 0, csum_data = 0, tso_segsz = 2, PH_vt = { vt_vtag = 3, vt_nrecs = 3 }, tags = { slh_first = 0x0 } } (kgdb) p m->M_dat.MH.MH_pkthdr.rcvif $6 = (struct ifnet *) 0xffffff80007e3000 (kgdb) p ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_txrate $7 = 0 (kgdb) p ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_chan $8 = (struct ieee80211_channel *) 0xffffff80007df300 (kgdb) p *((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_chan $9 = { ic_flags = 1152, ic_freq = 2437, ic_ieee = 6 '\006', ic_maxregpower = 0 '\0', ic_maxpower = 0 '\0', ic_minpower = 0 '\0', ic_state = 0 '\0', ic_extieee = 0 '\0', ic_maxantgain = 0 '\0', ic_pad = 0 '\0', ic_devdata = 0 } (kgdb) p vap No symbol "vap" in current context. (kgdb) p *((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap $10 = { iv_media = { ifm_mask = 0, ifm_media = 0, ifm_cur = 0xffffff0005ef48e0, ifm_list = { lh_first = 0xffffff0005ef4520 }, ifm_change = 0xffffffff806b7980 , ifm_status = 0xffffffff806b7f70 }, iv_ifp = 0xffffff00071eb000, iv_rawbpf = 0xffffff0005f20680, iv_sysctl = 0xffffff0005e3e850, iv_oid = 0xffffff0005f20200, iv_next = { tqe_next = 0x0, tqe_prev = 0xffffff80007df038 }, iv_ic = 0xffffff80007df000, iv_debug = 0, iv_stats = { is_rx_badversion = 0, ---Type to continue, or q to quit--- is_rx_tooshort = 0, is_rx_wrongbss = 0, is_rx_dup = 0, is_rx_wrongdir = 0, is_rx_mcastecho = 0, is_rx_notassoc = 0, is_rx_noprivacy = 0, is_rx_unencrypted = 0, is_rx_wepfail = 0, is_rx_decap = 0, is_rx_mgtdiscard = 0, is_rx_ctl = 0, is_rx_beacon = 3, is_rx_rstoobig = 0, is_rx_elem_missing = 0, is_rx_elem_toobig = 0, is_rx_elem_toosmall = 0, is_rx_elem_unknown = 0, is_rx_badchan = 0, is_rx_chanmismatch = 1, is_rx_nodealloc = 0, is_rx_ssidmismatch = 0, is_rx_auth_unsupported = 0, ---Type to continue, or q to quit--- is_rx_auth_fail = 0, is_rx_auth_countermeasures = 0, is_rx_assoc_bss = 0, is_rx_assoc_notauth = 0, is_rx_assoc_capmismatch = 0, is_rx_assoc_norate = 0, is_rx_assoc_badwpaie = 0, is_rx_deauth = 0, is_rx_disassoc = 0, is_rx_badsubtype = 0, is_rx_nobuf = 0, is_rx_decryptcrc = 0, is_rx_ahdemo_mgt = 0, is_rx_bad_auth = 0, is_rx_unauth = 0, is_rx_badkeyid = 0, is_rx_ccmpreplay = 0, is_rx_ccmpformat = 0, is_rx_ccmpmic = 0, is_rx_tkipreplay = 0, is_rx_tkipformat = 0, is_rx_tkipmic = 0, is_rx_tkipicv = 0, ---Type to continue, or q to quit--- is_rx_badcipher = 0, is_rx_nocipherctx = 0, is_rx_acl = 0, is_tx_nobuf = 0, is_tx_nonode = 0, is_tx_unknownmgt = 0, is_tx_badcipher = 0, is_tx_nodefkey = 0, is_tx_noheadroom = 0, is_tx_fragframes = 0, is_tx_frags = 0, is_scan_active = 1, is_scan_passive = 0, is_node_timeout = 0, is_crypto_nomem = 0, is_crypto_tkip = 3, is_crypto_tkipenmic = 3, is_crypto_tkipdemic = 0, is_crypto_tkipcm = 0, is_crypto_ccmp = 0, is_crypto_wep = 0, is_crypto_setkey_cipher = 0, is_crypto_setkey_nokey = 0, ---Type to continue, or q to quit--- is_crypto_delkey = 0, is_crypto_badcipher = 0, is_crypto_nocipher = 0, is_crypto_attachfail = 0, is_crypto_swfallback = 0, is_crypto_keyfail = 0, is_crypto_enmicfail = 0, is_ibss_capmismatch = 0, is_ibss_norate = 0, is_ps_unassoc = 0, is_ps_badaid = 0, is_ps_qempty = 0, is_ff_badhdr = 0, is_ff_tooshort = 0, is_ff_split = 0, is_ff_decap = 0, is_ff_encap = 0, is_rx_badbintval = 0, is_rx_demicfail = 0, is_rx_defrag = 0, is_rx_mgmt = 7, is_rx_action = 0, is_amsdu_tooshort = 0, ---Type to continue, or q to quit--- is_amsdu_split = 0, is_amsdu_decap = 0, is_amsdu_encap = 0, is_ampdu_bar_bad = 0, is_ampdu_bar_oow = 0, is_ampdu_bar_move = 0, is_ampdu_bar_rx = 0, is_ampdu_rx_flush = 0, is_ampdu_rx_oor = 0, is_ampdu_rx_copy = 0, is_ampdu_rx_drop = 0, is_tx_badstate = 0, is_tx_notassoc = 0, is_tx_classify = 0, is_dwds_mcast = 0, is_dwds_qdrop = 0, is_ht_assoc_nohtcap = 0, is_ht_assoc_downgrade = 0, is_ht_assoc_norate = 0, is_ampdu_rx_age = 0, is_ampdu_rx_move = 0, is_addba_reject = 0, is_addba_norequest = 0, ---Type to continue, or q to quit--- is_addba_badtoken = 0, is_addba_badpolicy = 0, is_ampdu_stop = 0, is_ampdu_stop_failed = 0, is_ampdu_rx_reorder = 0, is_scan_bg = 0, is_rx_deauth_code = 0 '\0', is_rx_disassoc_code = 0 '\0', is_rx_authfail_code = 0 '\0', is_beacon_miss = 0, is_rx_badstate = 0, is_ff_flush = 0, is_tx_ctl = 0, is_ampdu_rexmt = 0, is_ampdu_rexmt_fail = 0, is_mesh_wrongmesh = 0, is_mesh_nolink = 0, is_mesh_fwd_ttl = 0, is_mesh_fwd_nobuf = 0, is_mesh_fwd_tooshort = 0, is_mesh_fwd_disabled = 0, is_mesh_fwd_nopath = 0, is_hwmp_wrongseq = 0, ---Type to continue, or q to quit--- is_hwmp_rootreqs = 0, is_hwmp_rootrann = 0, is_mesh_badae = 0, is_mesh_rtaddfailed = 0, is_mesh_notproxy = 0, is_rx_badalign = 0, is_hwmp_proxy = 0, is_spare = {0 } }, iv_myaddr = "\000\"uþ\235N", iv_flags = 1090781200, iv_flags_ext = 1026, iv_flags_ht = 0, iv_flags_ven = 0, iv_caps = 562095104, iv_htcaps = 0, iv_opmode = IEEE80211_M_HOSTAP, iv_state = IEEE80211_S_RUN, iv_nstate = IEEE80211_S_RUN, iv_nstate_arg = -1, iv_nstate_task = { ta_link = { stqe_next = 0x0 ---Type to continue, or q to quit--- }, ta_pending = 0, ta_priority = 0, ta_func = 0xffffffff806e66d0 , ta_context = 0xffffff0005dfe000 }, iv_swbmiss_task = { ta_link = { stqe_next = 0x0 }, ta_pending = 0, ta_priority = 0, ta_func = 0xffffffff806e49f0 , ta_context = 0xffffff0005dfe000 }, iv_mgtsend = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 ---Type to continue, or q to quit--- } }, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0 }, iv_inact_init = 2, iv_inact_auth = 12, iv_inact_run = 20, iv_inact_probe = 2, iv_des_nssid = 1, iv_des_ssid = {{ len = 8, ssid = "XXX", '\0' }}, iv_des_bssid = "\000\000\000\000\000", iv_des_chan = 0xffff, iv_des_mode = 0, iv_nicknamelen = 0, iv_nickname = '\0' , ---Type to continue, or q to quit--- iv_bgscanidle = 250, iv_bgscanintvl = 300000, iv_scanvalid = 60000, iv_scanreq_duration = 0, iv_scanreq_mindwell = 0, iv_scanreq_maxdwell = 0, iv_scanreq_flags = 0, iv_scanreq_nssid = 0 '\0', iv_scanreq_ssid = {{ len = 0, ssid = '\0' }}, iv_roaming = IEEE80211_ROAMING_AUTO, iv_roamparms = {{ rssi = 0 '\0', rate = 0 '\0', pad = 0 }, { rssi = 14 '\016', rate = 24 '\030', pad = 0 }, { rssi = 14 '\016', ---Type to continue, or q to quit--- rate = 2 '\002', pad = 0 }, { rssi = 14 '\016', rate = 10 '\n', pad = 0 }, { rssi = 0 '\0', rate = 0 '\0', pad = 0 }, { rssi = 14 '\016', rate = 24 '\030', pad = 0 }, { rssi = 14 '\016', rate = 24 '\030', pad = 0 }, { rssi = 14 '\016', rate = 24 '\030', pad = 0 }, { ---Type to continue, or q to quit--- rssi = 14 '\016', rate = 129 '\201', pad = 0 }, { rssi = 14 '\016', rate = 129 '\201', pad = 0 }, { rssi = 14 '\016', rate = 12 '\f', pad = 0 }, { rssi = 14 '\016', rate = 6 '\006', pad = 0 }}, iv_bmissthreshold = 7 '\a', iv_bmiss_count = 0 '\0', iv_bmiss_max = 2, iv_swbmiss_count = 0, iv_swbmiss_period = 0, iv_swbmiss = { c_links = { ---Type to continue, or q to quit--- sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0 }, iv_ampdu_rxmax = 0, iv_ampdu_density = 0, iv_ampdu_limit = 0, iv_amsdu_limit = 0, iv_ampdu_mintraffic = {64, 128, 32, 32}, iv_aid_bitmap = 0xffffff0005e3e750, iv_max_aid = 128, iv_sta_assoc = 1, ---Type to continue, or q to quit--- iv_ps_sta = 0, iv_ps_pending = 0, iv_txseq = 0, iv_tim_len = 16, iv_tim_bitmap = 0xffffff0005e3e740 "", iv_dtim_period = 1 '\001', iv_dtim_count = 0 '\0', iv_csa_count = 0, iv_bss = 0xffffff80007f6000, iv_txparms = {{ ucastrate = 0 '\0', mgmtrate = 0 '\0', mcastrate = 0 '\0', maxretry = 0 '\0' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', ---Type to continue, or q to quit--- maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 0 '\0', mcastrate = 0 '\0', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', ---Type to continue, or q to quit--- mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 6 '\006', mcastrate = 6 '\006', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 3 '\003', mcastrate = 3 '\003', maxretry = 6 '\006' ---Type to continue, or q to quit--- }}, iv_rtsthreshold = 2346, iv_fragthreshold = 2346, iv_inact_timer = 0, iv_appie_beacon = 0x0, iv_appie_probereq = 0x0, iv_appie_proberesp = 0x0, iv_appie_assocreq = 0x0, iv_appie_assocresp = 0x0, iv_appie_wpa = 0xffffff0005ef43a0, iv_wpa_ie = 0x0, iv_rsn_ie = 0xffffff0005ef43a2 "0\030\001", iv_max_keyix = 4, iv_def_txkey = 1, iv_nw_keys = {{ wk_keylen = 0 '\0', wk_pad = 0 '\0', wk_flags = 3, wk_keyix = 65535, wk_rxkeyix = 65535, wk_key = '\0' , wk_keyrsc = {0 }, wk_keytsc = 0, ---Type to continue, or q to quit--- wk_cipher = 0xffffffff809fb0c0, wk_private = 0xffffff0005dfe000, wk_macaddr = "\000\000\000\000\000" }, { wk_keylen = 16 '\020', wk_pad = 0 '\0', wk_flags = 501, wk_keyix = 1, wk_rxkeyix = 65535, wk_key = "XXX", wk_keyrsc = {0 }, wk_keytsc = 4, wk_cipher = 0xffffffff809fb180, wk_private = 0xffffff0005f22e00, wk_macaddr = "ÿÿÿÿÿÿ" }, { wk_keylen = 0 '\0', wk_pad = 0 '\0', wk_flags = 3, wk_keyix = 65535, wk_rxkeyix = 65535, wk_key = '\0' , wk_keyrsc = {0 }, ---Type to continue, or q to quit--- wk_keytsc = 0, wk_cipher = 0xffffffff809fb0c0, wk_private = 0xffffff0005dfe000, wk_macaddr = "\000\000\000\000\000" }, { wk_keylen = 0 '\0', wk_pad = 0 '\0', wk_flags = 3, wk_keyix = 65535, wk_rxkeyix = 65535, wk_key = '\0' , wk_keyrsc = {0 }, wk_keytsc = 0, wk_cipher = 0xffffffff809fb0c0, wk_private = 0xffffff0005dfe000, wk_macaddr = "\000\000\000\000\000" }}, iv_key_alloc = 0xffffffff806bc2c0 , iv_key_delete = 0xffffffff806bc310 , iv_key_set = 0xffffffff806bc320 , iv_key_update_begin = 0xffffffff806bc330 , iv_key_update_end = 0xffffffff806bc330 , iv_auth = 0xffffffff8103a0e0, ---Type to continue, or q to quit--- iv_ec = 0x0, iv_acl = 0x0, iv_as = 0x0, iv_rate = 0xffffffff809fa9e0, iv_rs = 0xffffff0005e3e780, iv_tdma = 0x0, iv_mesh = 0x0, iv_hwmp = 0x0, iv_opdetach = 0xffffffff806c5130 , iv_input = 0xffffffff806c7e70 , iv_recv_mgmt = 0xffffffff806c5d30 , iv_recv_ctl = 0xffffffff806c54c0 , iv_deliver_data = 0xffffffff806c52b0 , iv_bmiss = 0, iv_reset = 0xffffffff806b76c0 , iv_update_beacon = 0xffffffff806e4640 , iv_update_ps = 0xffffffff806e3860 , iv_set_tim = 0xffffffff806e41d0 , iv_newstate = 0xffffffff805382a0 , iv_output = 0xffffffff806a50d0 , iv_spare = {0, 0, 0, 0, 0, 0} } (kgdb) p ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap) $11 = (struct ieee80211vap *) 0xffffff0005dfe000 (kgdb) p ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms [1] $12 = {{ ucastrate = 0 '\0', mgmtrate = 0 '\0', mcastrate = 0 '\0', maxretry = 0 '\0' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 0 '\0', ---Type to continue, or q to quit--- mcastrate = 0 '\0', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ---Type to continue, or q to quit--- ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 6 '\006', mcastrate = 6 '\006', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 3 '\003', mcastrate = 3 '\003', maxretry = 6 '\006' }} (kgdb) p (((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap)->iv_txxparms $13 = {{ ucastrate = 0 '\0', mgmtrate = 0 '\0', mcastrate = 0 '\0', maxretry = 0 '\0' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 0 '\0', ---Type to continue, or q to quit--- mcastrate = 0 '\0', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 2 '\002', mcastrate = 2 '\002', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 12 '\f', mcastrate = 12 '\f', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ---Type to continue, or q to quit--- ucastrate = 255 'ÿ', mgmtrate = 128 '\200', mcastrate = 128 '\200', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 6 '\006', mcastrate = 6 '\006', maxretry = 6 '\006' }, { ucastrate = 255 'ÿ', mgmtrate = 3 '\003', mcastrate = 3 '\003', maxretry = 6 '\006' }} (kgdb) p *((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif) $14 = { ni_vap = 0xffffff0005dfe000, ni_ic = 0xffffff80007df000, ni_table = 0xffffff80007e07b0, ni_list = { tqe_next = 0x0, tqe_prev = 0xffffff80007f6018 }, ni_hash = { le_next = 0x0, le_prev = 0xffffff80007e0880 }, ni_refcnt = 2, ni_scangen = 0, ni_flags = 131108, ni_associd = 49153, ni_vlan = 0, ni_txpower = 100, ni_authmode = 3 '\003', ni_ath_flags = 0 '\0', ni_ath_defkeyix = 32767, ni_txparms = 0xffffff0005dfe4fc, ni_jointime = 192, ---Type to continue, or q to quit--- ni_challenge = 0x0, ni_ies = { wpa_ie = 0x0, rsn_ie = 0xffffff0005f2a49a "0\024\001", wme_ie = 0x0, ath_ie = 0x0, htcap_ie = 0x0, htinfo_ie = 0x0, tdma_ie = 0x0, meshid_ie = 0x0, spare = {0x0, 0x0, 0x0, 0x0}, data = 0xffffff0005f2a480 "", len = 48 }, ni_txseqs = {0 , 3}, ni_rxseqs = {0 , 16}, ni_rxfragstamp = 0, ni_rxfrag = {0x0, 0x0, 0x0}, ni_ucastkey = { wk_keylen = 0 '\0', wk_pad = 0 '\0', wk_flags = 3, wk_keyix = 65535, ---Type to continue, or q to quit--- wk_rxkeyix = 65535, wk_key = '\0' , wk_keyrsc = {0 }, wk_keytsc = 0, wk_cipher = 0xffffffff809fb0c0, wk_private = 0xffffff0005dfe000, wk_macaddr = "\000\000\000\000\000" }, ni_avgrssi = 2176, ni_noise = -95 '¡', ni_macaddr = "\000\034¿\002\022\021", ni_bssid = "\000\"uþ\235N", ni_tstamp = { data = "\000\000\000\000\000\000\000", tsf = 0 }, ni_intval = 1, ni_capinfo = 1073, ni_esslen = 0 '\0', ni_essid = '\0' , ni_rates = { rs_nrates = 12 '\f', rs_rates = "\202\204\213\f\022\226\030$0H`l\000\000" ---Type to continue, or q to quit--- }, ni_chan = 0xffffff80007df300, ni_fhdwell = 0, ni_fhindex = 0 '\0', ni_erp = 0, ni_timoff = 0, ni_dtim_period = 0 '\0', ni_dtim_count = 0 '\0', ni_meshidlen = 0 '\0', ni_meshid = '\0' , ni_mlstate = IEEE80211_NODE_MESH_IDLE, ni_mllid = 0, ni_mlpid = 0, ni_mltimer = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, ---Type to continue, or q to quit--- c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, ni_mlrcnt = 0 '\0', ni_mltval = 0 '\0', ni_htcap = 0, ni_htparam = 0 '\0', ni_htctlchan = 0 '\0', ni_ht2ndchan = 0 '\0', ni_htopmode = 0 '\0', ni_htstbc = 0 '\0', ni_chw = 0 '\0', ni_htrates = { rs_nrates = 0 '\0', rs_rates = '\0' }, ni_tx_ampdu = {{ txa_ni = 0x0, txa_flags = 0, ---Type to continue, or q to quit--- txa_ac = 0 '\0', txa_token = 0 '\0', txa_lastsample = 0, txa_pkts = 0, txa_avgpps = 0, txa_qbytes = 0, txa_qframes = 0, txa_start = 0, txa_seqpending = 0, txa_wnd = 0, txa_attempts = 0 '\0', txa_nextrequest = 0, txa_timer = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, ---Type to continue, or q to quit--- c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, txa_private = 0x0, txa_pad = {0, 0, 0, 0} }, { txa_ni = 0x0, txa_flags = 0, txa_ac = 0 '\0', txa_token = 0 '\0', txa_lastsample = 0, txa_pkts = 0, txa_avgpps = 0, txa_qbytes = 0, txa_qframes = 0, txa_start = 0, txa_seqpending = 0, txa_wnd = 0, txa_attempts = 0 '\0', txa_nextrequest = 0, ---Type to continue, or q to quit--- txa_timer = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, txa_private = 0x0, txa_pad = {0, 0, 0, 0} }, { txa_ni = 0x0, txa_flags = 0, txa_ac = 0 '\0', ---Type to continue, or q to quit--- txa_token = 0 '\0', txa_lastsample = 0, txa_pkts = 0, txa_avgpps = 0, txa_qbytes = 0, txa_qframes = 0, txa_start = 0, txa_seqpending = 0, txa_wnd = 0, txa_attempts = 0 '\0', txa_nextrequest = 0, txa_timer = { c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, c_arg = 0x0, ---Type to continue, or q to quit--- c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, txa_private = 0x0, txa_pad = {0, 0, 0, 0} }, { txa_ni = 0x0, txa_flags = 0, txa_ac = 0 '\0', txa_token = 0 '\0', txa_lastsample = 0, txa_pkts = 0, txa_avgpps = 0, txa_qbytes = 0, txa_qframes = 0, txa_start = 0, txa_seqpending = 0, txa_wnd = 0, txa_attempts = 0 '\0', txa_nextrequest = 0, txa_timer = { ---Type to continue, or q to quit--- c_links = { sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0x0 } }, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0 }, txa_private = 0x0, txa_pad = {0, 0, 0, 0} }}, ni_rx_ampdu = {{ rxa_flags = 0, rxa_qbytes = 0, rxa_qframes = 0, ---Type to continue, or q to quit--- rxa_seqstart = 0, rxa_start = 0, rxa_wnd = 0, rxa_age = 0, rxa_nframes = 0, rxa_m = {0x0 }, rxa_pad = {0, 0, 0, 0} } }, ni_inact = 2, ni_inact_reload = 12, ni_txrate = 0, ni_psq = { psq_lock = { lock_object = { lo_name = 0xffffffff809653c5 "unknown", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0 }, mtx_lock = 4 }, psq_len = 0, psq_maxlen = 50, ---Type to continue, or q to quit--- psq_drops = 0, psq_head = {{ head = 0x0, tail = 0x0, len = 0 }, { head = 0x0, tail = 0x0, len = 0 }} }, ni_stats = { ns_rx_data = 1, ns_rx_mgmt = 1, ns_rx_ctrl = 0, ns_rx_ucast = 0, ns_rx_mcast = 1, ns_rx_bytes = 20, ns_rx_beacons = 0, ns_rx_proberesp = 0, ns_rx_dup = 0, ns_rx_noprivacy = 0, ns_rx_wepfail = 0, ---Type to continue, or q to quit--- ns_rx_demicfail = 0, ns_rx_decap = 0, ns_rx_defrag = 0, ns_rx_disassoc = 0, ns_rx_deauth = 0, ns_rx_action = 0, ns_rx_decryptcrc = 0, ns_rx_unauth = 0, ns_rx_unencrypted = 0, ns_rx_drop = 0, ns_tx_data = 1, ns_tx_mgmt = 2, ns_tx_ctrl = 0, ns_tx_ucast = 1, ns_tx_mcast = 0, ns_tx_bytes = 107, ns_tx_probereq = 0, ns_tx_novlantag = 0, ns_tx_vlanmismatch = 0, ns_ps_discard = 0, ns_tx_assoc = 1, ns_tx_assoc_fail = 0, ns_tx_auth = 1, ---Type to continue, or q to quit--- ns_tx_auth_fail = 0, ns_tx_deauth = 0, ns_tx_deauth_code = 0, ns_tx_disassoc = 0, ns_tx_disassoc_code = 0, ns_spare = {0, 0, 0, 0, 0, 0, 0, 0} }, ni_wdsvap = 0x0, ni_rctls = 0x0, ni_spare = {0, 0, 0} } (kgdb) q And here comes the patch: (the first hunk is an unrelated stable/8 commit since I'm on the 8.1 release branch atm.) [2] Index: src/sys/dev/usb/wlan/if_rum.c =================================================================== RCS file: /home/scvs/src/sys/dev/usb/wlan/if_rum.c,v retrieving revision 1.20.2.7.2.1 diff -u -p -r1.20.2.7.2.1 if_rum.c --- src/sys/dev/usb/wlan/if_rum.c 14 Jun 2010 02:09:06 -0000 1.20.2.7.2.1 +++ src/sys/dev/usb/wlan/if_rum.c 1 Aug 2010 14:31:27 -0000 @@ -1049,7 +1049,7 @@ rum_sendprot(struct rum_softc *sc, ackrate = ieee80211_ack_rate(ic->ic_rt, rate); isshort = (ic->ic_flags & IEEE80211_F_SHPREAMBLE) != 0; - dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort); + dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort) + ieee80211_ack_duration(ic->ic_rt, rate, isshort); flags = RT2573_TX_MORE_FRAG; if (prot == IEEE80211_PROT_RTSCTS) { @@ -1216,6 +1216,17 @@ rum_tx_data(struct rum_softc *sc, struct rate = tp->ucastrate; else rate = ni->ni_txrate; +#if 1 + static int lastrate = 0; + if (rate == 0) { + /* XXX */ + rate = 72; + printf("wlan: rate = 0! using %d\n", rate); + } else if (rate != lastrate) { + printf("wlan: rate = %d\n", rate); + lastrate = rate; + } +#endif if (wh->i_fc[1] & IEEE80211_FC1_WEP) { k = ieee80211_crypto_encap(ni, m0); Using that patch I get: Aug 2 20:15:06 triton8 kernel: wlan: rate = 0! using 72 Aug 2 20:15:22 triton8 last message repeated 11 times Aug 2 20:15:22 triton8 kernel: Aug 2 20:15:24 triton8 kernel: wlan: rate = 0! using 72 Aug 2 20:15:26 triton8 last message repeated 16 times Aug 2 20:21:03 triton8 last message repeated 2 times Aug 2 20:22:46 triton8 last message repeated 19 times HTH, Juergen From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 21:02:13 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A124106567C; Wed, 4 Aug 2010 21:02:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9858FC1B; Wed, 4 Aug 2010 21:02:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o74L2CWT024387; Wed, 4 Aug 2010 21:02:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o74L2CZv024383; Wed, 4 Aug 2010 21:02:12 GMT (envelope-from linimon) Date: Wed, 4 Aug 2010 21:02:12 GMT Message-Id: <201008042102.o74L2CZv024383@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/149285: [ste] Permanent DOWN/UP network interface ste0 on 8.1-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 21:02:13 -0000 Old Synopsis: Permanent DOWN/UP network interface ste0 on 8.1-RELEASE New Synopsis: [ste] Permanent DOWN/UP network interface ste0 on 8.1-RELEASE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 4 21:01:54 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149285 From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 22:40:05 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FBB71065670 for ; Wed, 4 Aug 2010 22:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D1E448FC13 for ; Wed, 4 Aug 2010 22:40:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o74Me4aG012803 for ; Wed, 4 Aug 2010 22:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o74Me42B012802; Wed, 4 Aug 2010 22:40:04 GMT (envelope-from gnats) Date: Wed, 4 Aug 2010 22:40:04 GMT Message-Id: <201008042240.o74Me42B012802@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Edwin Groothuis Cc: Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Edwin Groothuis List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:40:05 -0000 The following reply was made to PR kern/144755; it has been noted by GNATS. From: Edwin Groothuis To: Bernhard Schmidt Cc: bug-followup@freebsd.org Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 Date: Thu, 5 Aug 2010 08:31:27 +1000 Hello Bernhard! On Wed, Jul 28, 2010 at 12:11:17PM +0200, Bernhard Schmidt wrote: > Can you check if wpa_supplicant gets started twice after > "/etc/rc.d/netif restart"? According to core.txt there are two wpa_supplicant processes, but I don't know if it is caused by a fork of itself or if it is caused by something started twice: 0 7084 1 0 56 0 5192 0 select Ds ?? 3686:38.00 [wpa_suppli 0 7085 1 0 57 0 5192 0 select Ds ?? 2617:11.00 [wpa_suppli Based on the PPID of 1 for both, I would say it gets started twice. root wpa_supplicant 7085 root / 2 drwxr-xr-x 512 r root wpa_supplicant 7085 wd / 2 drwxr-xr-x 512 r root wpa_supplicant 7085 text /usr 4526084 -r-xr-xr-x 295932 r root wpa_supplicant 7085 0 /dev 7 crw-rw-rw- null rw root wpa_supplicant 7085 1 /dev 7 crw-rw-rw- null rw root wpa_supplicant 7085 2 /dev 7 crw-rw-rw- null rw root wpa_supplicant 7085 3* internet dgram udp c52b1000 root wpa_supplicant 7085 4* route raw 0 c527f4d4 root wpa_supplicant 7085 5 /dev 15 crw------- bpf rw root wpa_supplicant 7084 root / 2 drwxr-xr-x 512 r root wpa_supplicant 7084 wd / 2 drwxr-xr-x 512 r root wpa_supplicant 7084 text /usr 4526084 -r-xr-xr-x 295932 r root wpa_supplicant 7084 0 /dev 7 crw-rw-rw- null rw root wpa_supplicant 7084 1 /dev 7 crw-rw-rw- null rw root wpa_supplicant 7084 2 /dev 7 crw-rw-rw- null rw root wpa_supplicant 7084 3* internet dgram udp c4f520dc root wpa_supplicant 7084 4* route raw 0 c527f670 root wpa_supplicant 7084 5* local stream c4f508bc root wpa_supplicant 7084 6 /var 23622 -rw------- 4 w root wpa_supplicant 7084 7* local stream c4f5035c <-> c4f50408 root wpa_supplicant 7084 8 /dev 15 crw------- bpf rw > I have the feeling that this is a more or less known issue, a race > between devd (/etc/pccard_ether) and /etc/rc.d/netif. There is a small > window (a few ms) where this can happen and our net80211 isn't capable > of handling two running wpa_supplicants on the same interface. Which > leads to all kind of weird issues, .e.g. panics. Nice! Is there a workaround or patch available for testing? Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Wed Aug 4 23:50:47 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B90E81065672; Wed, 4 Aug 2010 23:50:47 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE358FC0A; Wed, 4 Aug 2010 23:50:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o74Nol6S085343; Wed, 4 Aug 2010 23:50:47 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o74Nokd0085263; Wed, 4 Aug 2010 23:50:46 GMT (envelope-from yongari) Date: Wed, 4 Aug 2010 23:50:46 GMT Message-Id: <201008042350.o74Nokd0085263@freefall.freebsd.org> To: exkilla@mail.ru, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/149285: [ste] Permanent DOWN/UP network interface ste0 on 8.1-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 23:50:47 -0000 Synopsis: [ste] Permanent DOWN/UP network interface ste0 on 8.1-RELEASE State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Aug 4 23:49:17 UTC 2010 State-Changed-Why: I don't think this regression was caused by ste(4) overhauling. The message is printed by mii(4) layer to note link state changes. I have no idea how this does not happen on 8.0-RELEASE though as it has nothing to do with ste(4). But after ste(4) overhauling, ste(4) now correctly keeps track of current reported link state such that it wouldn't try to send packets if it know link is in DOWN state. Would you show me the output of "devinfo -rv | grep phy" both 8.1-RELEASE and 8.0-RELEASE? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Aug 4 23:49:17 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=149285 From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 05:21:03 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE8881065674; Thu, 5 Aug 2010 05:21:03 +0000 (UTC) (envelope-from alc@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 94B658FC19; Thu, 5 Aug 2010 05:21:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o755L3Dq013464; Thu, 5 Aug 2010 05:21:03 GMT (envelope-from alc@freefall.freebsd.org) Received: (from alc@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o755L19k013111; Thu, 5 Aug 2010 05:21:01 GMT (envelope-from alc) Date: Thu, 5 Aug 2010 05:21:01 GMT Message-Id: <201008050521.o755L19k013111@freefall.freebsd.org> To: okor@zone.salut.ru, alc@FreeBSD.org, freebsd-net@FreeBSD.org From: alc@FreeBSD.org Cc: Subject: Re: kern/122743: [mbuf] [panic] vm_page_unwire: invalid wire count: 0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 05:21:03 -0000 Synopsis: [mbuf] [panic] vm_page_unwire: invalid wire count: 0 State-Changed-From-To: open->closed State-Changed-By: alc State-Changed-When: Thu Aug 5 05:11:59 UTC 2010 State-Changed-Why: The panic reported in this PR was almost certainly a result of overflowing the vm_page's 16-bit wire_count field. This field has been changed to a 32-bit quantity in all versions of FreeBSD since 7.2. (See r186719.) http://www.freebsd.org/cgi/query-pr.cgi?pr=122743 From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 07:22:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A5DF1065674; Thu, 5 Aug 2010 07:22:23 +0000 (UTC) (envelope-from alexkozlov0@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B0CF8FC16; Thu, 5 Aug 2010 07:22:22 +0000 (UTC) Received: by bwz12 with SMTP id 12so3665052bwz.13 for ; Thu, 05 Aug 2010 00:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=Tp6rUaEp6zlRXwvwzHRuA0vH9yVw3+lB6qJ0VJtg8/A=; b=iisDEZWrTHzmT8rpL5kXT6TlWlXLMg2u14AYw4etHvkr12V/pB2jPNNasgWPJZwnTz zKgsfp0Z91OXEjrIemWE1VuehyrJ/hOL8eGXs5Tw4zWFC3gF5AUC4JOw9HEqsJOfyQwY 9pMhmGs9hUbAdRGFiFx3jKCs/pxiHmQiMQzX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=siBBF23sNrzMwea4V6QoBEbJDxb9W6a2vPpIzdc1/ptJzZan/0FlGgFQwnBzTvW4oi HEhJCR3efAU4C1Fa1UpH6V6lQddTcHxQFK+6u2Co/QpMlZ/tGAY/zTa7EKKjkfHigC+K 74JJMMlI6DBX87m8lWUtvznvXerw3sxXeHoMA= Received: by 10.204.160.146 with SMTP id n18mr7055310bkx.116.1280991170975; Wed, 04 Aug 2010 23:52:50 -0700 (PDT) Received: from ravenloft.kiev.ua (ravenloft.kiev.ua [94.244.131.95]) by mx.google.com with ESMTPS id a9sm6587357bky.11.2010.08.04.23.52.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 23:52:49 -0700 (PDT) Sender: Alex Kozlov Date: Thu, 5 Aug 2010 09:52:16 +0300 From: Alex Kozlov To: nox@freebsd.org, rpaulo@freebsd.org, freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org, spam@rm-rf.kiev.ua Message-ID: <20100805065216.GA53036@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 07:22:23 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: > Regarding the 8.1 if_rum(4) panics... I got a similar one, extracted > a dump and tried to gather some info for someone who knows the code: > > The zero divide fault was because (apparently) rate was unitialized, > as is > > ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] > > i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 This can be mitigated by patch [1] or by setting ucastrate option in ifconfig. Still real issue need to be solved. -- Adios --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" Index: sys/dev/usb/wlan/if_rum.c @@ -1153,9 +1153,11 @@ rate = params->ibp_rate0; if (!ieee80211_isratevalid(ic->ic_rt, rate)) { + device_printf(sc->sc_dev, "invalid rate=%d\n", rate); m_freem(m0); return EINVAL; } + flags = 0; if ((params->ibp_flags & IEEE80211_BPF_NOACK) == 0) flags |= RT2573_TX_NEED_ACK; @@ -1217,6 +1219,13 @@ else rate = ni->ni_txrate; + /* XXX ieee80211_ratectl sometimes set ni->ni_txrate to 0 */ + if (!ieee80211_isratevalid(ic->ic_rt, rate)) { + device_printf(sc->sc_dev, "invalid rate=%d\n", rate); + m_freem(m0); + return EINVAL; + } + if (wh->i_fc[1] & IEEE80211_FC1_WEP) { k = ieee80211_crypto_encap(ni, m0); if (k == NULL) { --Q68bSM7Ycu6FN28Q-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 07:30:13 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C28BB106567E for ; Thu, 5 Aug 2010 07:30:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B14D08FC1C for ; Thu, 5 Aug 2010 07:30:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o757UDMP052434 for ; Thu, 5 Aug 2010 07:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o757UD9I052424; Thu, 5 Aug 2010 07:30:13 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 07:30:13 GMT Message-Id: <201008050730.o757UD9I052424@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Kozlov Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Kozlov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 07:30:13 -0000 The following reply was made to PR kern/149185; it has been noted by GNATS. From: Alex Kozlov To: nox@freebsd.org, rpaulo@freebsd.org, freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org, spam@rm-rf.kiev.ua Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 09:52:16 +0300 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: > Regarding the 8.1 if_rum(4) panics... I got a similar one, extracted > a dump and tried to gather some info for someone who knows the code: > > The zero divide fault was because (apparently) rate was unitialized, > as is > > ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] > > i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 This can be mitigated by patch [1] or by setting ucastrate option in ifconfig. Still real issue need to be solved. -- Adios --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" Index: sys/dev/usb/wlan/if_rum.c @@ -1153,9 +1153,11 @@ rate = params->ibp_rate0; if (!ieee80211_isratevalid(ic->ic_rt, rate)) { + device_printf(sc->sc_dev, "invalid rate=%d\n", rate); m_freem(m0); return EINVAL; } + flags = 0; if ((params->ibp_flags & IEEE80211_BPF_NOACK) == 0) flags |= RT2573_TX_NEED_ACK; @@ -1217,6 +1219,13 @@ else rate = ni->ni_txrate; + /* XXX ieee80211_ratectl sometimes set ni->ni_txrate to 0 */ + if (!ieee80211_isratevalid(ic->ic_rt, rate)) { + device_printf(sc->sc_dev, "invalid rate=%d\n", rate); + m_freem(m0); + return EINVAL; + } + if (wh->i_fc[1] & IEEE80211_FC1_WEP) { k = ieee80211_crypto_encap(ni, m0); if (k == NULL) { --Q68bSM7Ycu6FN28Q-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 08:05:34 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55E0F1065672; Thu, 5 Aug 2010 08:05:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2BF378FC12; Thu, 5 Aug 2010 08:05:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7585Yrc096558; Thu, 5 Aug 2010 08:05:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o7585YEu096554; Thu, 5 Aug 2010 08:05:34 GMT (envelope-from linimon) Date: Thu, 5 Aug 2010 08:05:34 GMT Message-Id: <201008050805.o7585YEu096554@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:05:34 -0000 Old Synopsis: Doesn't work Atheros AR8131 PCIe Gigabit Ethernet New Synopsis: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 5 08:05:13 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149306 From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 08:06:02 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65D881065670; Thu, 5 Aug 2010 08:06:02 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3638FC17; Thu, 5 Aug 2010 08:06:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75862Vn096623; Thu, 5 Aug 2010 08:06:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75862wh096619; Thu, 5 Aug 2010 08:06:02 GMT (envelope-from linimon) Date: Thu, 5 Aug 2010 08:06:02 GMT Message-Id: <201008050806.o75862wh096619@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/149307: [ath] Doesn't work Atheros 9285 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:06:02 -0000 Old Synopsis: Doesn't work Atheros 9285 New Synopsis: [ath] Doesn't work Atheros 9285 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 5 08:05:47 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149307 From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 08:10:09 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA19106566C for ; Thu, 5 Aug 2010 08:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 019298FC08 for ; Thu, 5 Aug 2010 08:10:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o758A84u098066 for ; Thu, 5 Aug 2010 08:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o758A8Cm098065; Thu, 5 Aug 2010 08:10:08 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 08:10:08 GMT Message-Id: <201008050810.o758A8Cm098065@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:10:09 -0000 The following reply was made to PR kern/149185; it has been noted by GNATS. From: Bernhard Schmidt To: Alex Kozlov , bug-followup@freebsd.org Cc: nox@freebsd.org, rpaulo@freebsd.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 10:05:39 +0200 On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: >> =A0Regarding the 8.1 if_rum(4) panics... =A0I got a similar one, extract= ed >> a dump and tried to gather some info for someone who knows the code: >> >> =A0The zero divide fault was because (apparently) rate was unitialized, >> as is >> >> =A0 =A0 =A0 ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_= vap->iv_txparms[0] >> >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 > This can be mitigated by patch [1] or by setting ucastrate option in > ifconfig. Still real issue need to be solved. The real issue is that prior to an association (RUN state) ieee80211_ratectl_node_init() is not called, therefore iv_bss is not configured in any way. I'll look into that if no one beats me. --=20 Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 08:10:11 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10FC51065673 for ; Thu, 5 Aug 2010 08:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D958A8FC1B for ; Thu, 5 Aug 2010 08:10:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o758AAY4098091 for ; Thu, 5 Aug 2010 08:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o758AAo4098090; Thu, 5 Aug 2010 08:10:10 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 08:10:10 GMT Message-Id: <201008050810.o758AAo4098090@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:10:11 -0000 The following reply was made to PR kern/144755; it has been noted by GNATS. From: Bernhard Schmidt To: Edwin Groothuis , bug-followup@freebsd.org Cc: Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 Date: Thu, 5 Aug 2010 10:08:42 +0200 On Thu, Aug 5, 2010 at 00:31, Edwin Groothuis wrote: > Hello Bernhard! > > On Wed, Jul 28, 2010 at 12:11:17PM +0200, Bernhard Schmidt wrote: >> Can you check if wpa_supplicant gets started twice after >> "/etc/rc.d/netif restart"? > > According to core.txt there are two wpa_supplicant processes, but > I don't know if it is caused by a fork of itself or if it is caused > by something started twice: > > =A0 =A00 =A07084 =A0 =A0 1 =A0 0 =A056 =A00 =A05192 =A0 =A0 0 select Ds = =A0 =A0?? =A03686:38.00 [wpa_suppli > =A0 =A00 =A07085 =A0 =A0 1 =A0 0 =A057 =A00 =A05192 =A0 =A0 0 select Ds = =A0 =A0?? =A02617:11.00 [wpa_suppli > > Based on the PPID of 1 for both, I would say it gets started twice. Indeed. > > [..] >> I have the feeling that this is a more or less known issue, a race >> between devd (/etc/pccard_ether) and /etc/rc.d/netif. There is a small >> window (a few ms) where this can happen and our net80211 isn't capable >> of handling two running wpa_supplicants on the same interface. Which >> leads to all kind of weird issues, .e.g. panics. > > Nice! Is there a workaround or patch available for testing? A temporary workaround is to add a "sleep 1" in /etc/pccard_ether, something I'd rather not commit. I haven't yet found a clean solution for this.. any pointers welcome. :) --=20 Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 09:20:08 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABCC2106566B for ; Thu, 5 Aug 2010 09:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7FC728FC1C for ; Thu, 5 Aug 2010 09:20:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o759K5Au069282 for ; Thu, 5 Aug 2010 09:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o759K5BR069265; Thu, 5 Aug 2010 09:20:05 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 09:20:05 GMT Message-Id: <201008050920.o759K5BR069265@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Kozlov Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Kozlov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:20:08 -0000 The following reply was made to PR kern/149185; it has been noted by GNATS. From: Alex Kozlov To: Bernhard Schmidt , bug-followup@freebsd.org, nox@freebsd.org, rpaulo@freebsd.org, spam@rm-rf.kiev.ua Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 12:11:05 +0300 On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: > On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: > > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: > >>  Regarding the 8.1 if_rum(4) panics...  I got a similar one, extracted > >> a dump and tried to gather some info for someone who knows the code: > >> > >>  The zero divide fault was because (apparently) rate was unitialized, > >> as is > >> > >>       ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] > >> > >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. > > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 > > This can be mitigated by patch [1] or by setting ucastrate option in > > ifconfig. Still real issue need to be solved. > > The real issue is that prior to an association (RUN state) > ieee80211_ratectl_node_init() is not called, therefore iv_bss is not > configured in any way. ieee80211_ratectl_node_init() called from iv_newstate when switching to IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? Some call it from iv_newassoc, but this marked /* XXX move */ > I'll look into that if no one beats me. Thanks. -- Adios From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 09:40:10 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 409091065678 for ; Thu, 5 Aug 2010 09:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2EEA68FC14 for ; Thu, 5 Aug 2010 09:40:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o759e9tA089191 for ; Thu, 5 Aug 2010 09:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o759e98c089182; Thu, 5 Aug 2010 09:40:09 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 09:40:09 GMT Message-Id: <201008050940.o759e98c089182@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:40:10 -0000 The following reply was made to PR kern/149185; it has been noted by GNATS. From: Bernhard Schmidt To: Alex Kozlov , bug-followup@freebsd.org Cc: nox@freebsd.org, rpaulo@freebsd.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 11:34:35 +0200 On Thu, Aug 5, 2010 at 11:11, Alex Kozlov wrote: > On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: >> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: >> > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: >> >> =A0Regarding the 8.1 if_rum(4) panics... =A0I got a similar one, extr= acted >> >> a dump and tried to gather some info for someone who knows the code: >> >> >> >> =A0The zero divide fault was because (apparently) rate was unitialize= d, >> >> as is >> >> >> >> =A0 =A0 =A0 ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->= ni_vap->iv_txparms[0] >> >> >> >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. >> > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 >> > This can be mitigated by patch [1] or by setting ucastrate option in >> > ifconfig. Still real issue need to be solved. >> >> The real issue is that prior to an association (RUN state) >> ieee80211_ratectl_node_init() is not called, therefore iv_bss is not >> configured in any way. > ieee80211_ratectl_node_init() called from iv_newstate when switching to > IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? > Some call it from iv_newassoc, but this marked /* XXX move */ It is not wrong, but to late. Before RUN state and the iv_newassoc() call, you have to send frames for scanning and authentication, those need a valid rate too. I wonder if we can call node_init() in ieee80211_vap_setup() or something similar, that would definitely be early enough. >> I'll look into that if no one beats me. > Thanks. --=20 Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 10:10:07 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 579441065670 for ; Thu, 5 Aug 2010 10:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2506B8FC13 for ; Thu, 5 Aug 2010 10:10:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75AA7kn017167 for ; Thu, 5 Aug 2010 10:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75AA7vH017166; Thu, 5 Aug 2010 10:10:07 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 10:10:07 GMT Message-Id: <201008051010.o75AA7vH017166@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Rui Paulo Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rui Paulo List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 10:10:07 -0000 The following reply was made to PR kern/149185; it has been noted by GNATS. From: Rui Paulo To: Bernhard Schmidt Cc: Alex Kozlov , bug-followup@freebsd.org, nox@freebsd.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 10:38:44 +0100 On 5 Aug 2010, at 10:34, Bernhard Schmidt wrote: > On Thu, Aug 5, 2010 at 11:11, Alex Kozlov wrote: >> On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: >>> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov = wrote: >>>> On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: >>>>> Regarding the 8.1 if_rum(4) panics... I got a similar one, = extracted >>>>> a dump and tried to gather some info for someone who knows the = code: >>>>>=20 >>>>> The zero divide fault was because (apparently) rate was = unitialized, >>>>> as is >>>>>=20 >>>>> ((struct ieee80211_node *) = m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] >>>>>=20 >>>>> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it = matters. >>>> Yes, its seems that ratectl framework sometimes set ni->ni_txrate = to 0 >>>> This can be mitigated by patch [1] or by setting ucastrate option = in >>>> ifconfig. Still real issue need to be solved. >>>=20 >>> The real issue is that prior to an association (RUN state) >>> ieee80211_ratectl_node_init() is not called, therefore iv_bss is not >>> configured in any way. >> ieee80211_ratectl_node_init() called from iv_newstate when switching = to >> IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? >> Some call it from iv_newassoc, but this marked /* XXX move */ >=20 > It is not wrong, but to late. Before RUN state and the iv_newassoc() > call, you have to send frames for scanning and authentication, those > need a valid rate too. I wonder if we can call node_init() in > ieee80211_vap_setup() or something similar, that would definitely be > early enough. vap_setup() runs once and we need need to call node_init for each node = connected to an AP or for the AP node when the vap is a STA. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 16:30:14 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D0721065675 for ; Thu, 5 Aug 2010 16:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 10D2A8FC14 for ; Thu, 5 Aug 2010 16:30:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75GUDa1092956 for ; Thu, 5 Aug 2010 16:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75GUDNp092947; Thu, 5 Aug 2010 16:30:13 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 16:30:13 GMT Message-Id: <201008051630.o75GUDNp092947@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 16:30:14 -0000 The following reply was made to PR kern/149185; it has been noted by GNATS. From: Bernhard Schmidt To: Alex Kozlov Cc: bug-followup@freebsd.org, Juergen Lock , rpaulo@freebsd.org Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 18:25:32 +0200 --00c09f89939bd0b2e9048d15ff5b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 5, 2010 at 11:11, Alex Kozlov wrote: > On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: >> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: >> > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: >> >> =A0Regarding the 8.1 if_rum(4) panics... =A0I got a similar one, extr= acted >> >> a dump and tried to gather some info for someone who knows the code: >> >> >> >> =A0The zero divide fault was because (apparently) rate was unitialize= d, >> >> as is >> >> >> >> =A0 =A0 =A0 ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->= ni_vap->iv_txparms[0] >> >> >> >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. >> > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 >> > This can be mitigated by patch [1] or by setting ucastrate option in >> > ifconfig. Still real issue need to be solved. >> >> The real issue is that prior to an association (RUN state) >> ieee80211_ratectl_node_init() is not called, therefore iv_bss is not >> configured in any way. > ieee80211_ratectl_node_init() called from iv_newstate when switching to > IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? > Some call it from iv_newassoc, but this marked /* XXX move */ > >> I'll look into that if no one beats me. > Thanks. Please give attached patch a try, it should fix the issue for rum and all other drivers relying on the new ratectl stuff. Thanks --=20 Bernhard --00c09f89939bd0b2e9048d15ff5b Content-Type: application/octet-stream; name="net80211_ratectl_node_init.diff" Content-Disposition: attachment; filename="net80211_ratectl_node_init.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gchtkki90 SW5kZXg6IHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfbm9kZS5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9u ZXQ4MDIxMS9pZWVlODAyMTFfbm9kZS5jCShyZXZpc2lvbiAyMTA4NjIpCisrKyBzeXMvbmV0ODAy MTEvaWVlZTgwMjExX25vZGUuYwkod29ya2luZyBjb3B5KQpAQCAtODE3LDYgKzgxNyw3IEBAIGll ZWU4MDIxMV9zdGFfam9pbihzdHJ1Y3QgaWVlZTgwMjExdmFwICp2YXAsIHN0cnVjCiAJaWYgKGll ZWU4MDIxMV9pc2VycF9yYXRlc2V0KCZuaS0+bmlfcmF0ZXMpKQogCQluaS0+bmlfZmxhZ3MgfD0g SUVFRTgwMjExX05PREVfRVJQOwogCWllZWU4MDIxMV9ub2RlX3NldHVwdHhwYXJtcyhuaSk7CisJ aWVlZTgwMjExX3JhdGVjdGxfbm9kZV9pbml0KG5pKTsKIAogCXJldHVybiBpZWVlODAyMTFfc3Rh X2pvaW4xKGllZWU4MDIxMV9yZWZfbm9kZShuaSkpOwogfQpAQCAtMTQwMSw2ICsxNDAyLDcgQEAg aWVlZTgwMjExX2Zha2V1cF9hZGhvY19ub2RlKHN0cnVjdCBpZWVlODAyMTF2YXAgKnYKICNlbmRp ZgogCQl9CiAJCWllZWU4MDIxMV9ub2RlX3NldHVwdHhwYXJtcyhuaSk7CisJCWllZWU4MDIxMV9y YXRlY3RsX25vZGVfaW5pdChuaSk7CiAJCWlmIChpYy0+aWNfbmV3YXNzb2MgIT0gTlVMTCkKIAkJ CWljLT5pY19uZXdhc3NvYyhuaSwgMSk7CiAJCS8qIFhYWCBub3QgcmlnaHQgZm9yIDgwMi4xeC9X UEEgKi8KQEAgLTE0NzAsNiArMTQ3Miw3IEBAIGllZWU4MDIxMV9hZGRfbmVpZ2hib3Ioc3RydWN0 IGllZWU4MDIxMXZhcCAqdmFwLAogCQlpZiAoaWVlZTgwMjExX2lzZXJwX3JhdGVzZXQoJm5pLT5u aV9yYXRlcykpCiAJCQluaS0+bmlfZmxhZ3MgfD0gSUVFRTgwMjExX05PREVfRVJQOwogCQlpZWVl ODAyMTFfbm9kZV9zZXR1cHR4cGFybXMobmkpOworCQlpZWVlODAyMTFfcmF0ZWN0bF9ub2RlX2lu aXQobmkpOwogCQlpZiAoaWMtPmljX25ld2Fzc29jICE9IE5VTEwpCiAJCQlpYy0+aWNfbmV3YXNz b2MobmksIDEpOwogCQkvKiBYWFggbm90IHJpZ2h0IGZvciA4MDIuMXgvV1BBICovCkBAIC0yMzM4 LDYgKzIzNDEsNyBAQCBpZWVlODAyMTFfbm9kZV9qb2luKHN0cnVjdCBpZWVlODAyMTFfbm9kZSAq bmksIGludAogCSk7CiAKIAlpZWVlODAyMTFfbm9kZV9zZXR1cHR4cGFybXMobmkpOworCWllZWU4 MDIxMV9yYXRlY3RsX25vZGVfaW5pdChuaSk7CiAJLyogZ2l2ZSBkcml2ZXIgYSBjaGFuY2UgdG8g c2V0dXAgc3RhdGUgbGlrZSBuaV90eHJhdGUgKi8KIAlpZiAoaWMtPmljX25ld2Fzc29jICE9IE5V TEwpCiAJCWljLT5pY19uZXdhc3NvYyhuaSwgbmV3YXNzb2MpOwpJbmRleDogc3lzL25ldDgwMjEx L2llZWU4MDIxMV9zdGEuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX3N0 YS5jCShyZXZpc2lvbiAyMTA4NjIpCisrKyBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX3N0YS5jCSh3 b3JraW5nIGNvcHkpCkBAIC02MCw2ICs2MCw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNp ZmRlZiBJRUVFODAyMTFfU1VQUE9SVF9TVVBFUkcKICNpbmNsdWRlIDxuZXQ4MDIxMS9pZWVlODAy MTFfc3VwZXJnLmg+CiAjZW5kaWYKKyNpbmNsdWRlIDxuZXQ4MDIxMS9pZWVlODAyMTFfcmF0ZWN0 bC5oPgogCiAjZGVmaW5lCUlFRUU4MDIxMV9SQVRFMk1CUyhyKQkoKChyKSAmIElFRUU4MDIxMV9S QVRFX1ZBTCkgLyAyKQogCkBAIC0xNTk2LDYgKzE1OTcsNyBAQCBzdGFfcmVjdl9tZ210KHN0cnVj dCBpZWVlODAyMTFfbm9kZSAqbmksIHN0cnVjdCBtYgogCQkJICAgICBJRUVFODAyMTFfRl9KT0lO IHwgSUVFRTgwMjExX0ZfRE9CUlMpOwogCQkJaWVlZTgwMjExX3NldHVwX2Jhc2ljX2h0cmF0ZXMo bmksIGh0aW5mbyk7CiAJCQlpZWVlODAyMTFfbm9kZV9zZXR1cHR4cGFybXMobmkpOworCQkJaWVl ZTgwMjExX3JhdGVjdGxfbm9kZV9pbml0KG5pKTsKIAkJfSBlbHNlIHsKICNpZmRlZiBJRUVFODAy MTFfU1VQUE9SVF9TVVBFUkcKIAkJCWlmIChJRUVFODAyMTFfQVRIX0NBUCh2YXAsIG5pLCBJRUVF ODAyMTFfTk9ERV9BVEgpKQo= --00c09f89939bd0b2e9048d15ff5b-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 16:50:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 904F0106566B for ; Thu, 5 Aug 2010 16:50:02 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA1F8FC0C for ; Thu, 5 Aug 2010 16:50:01 +0000 (UTC) Received: by wyj26 with SMTP id 26so8480978wyj.13 for ; Thu, 05 Aug 2010 09:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QBdd8nE/XBW4GHYjMybuxq/BwcTGfj6D5Kgvd7NLStQ=; b=UpTTweuA/l/TI93DGuEngrEnp3HZMD1M3DF+lo42gYyP1xp2rJ2QTs2zIBG36p8yDD Fnupq2R+94XW4ayYXVQ2sV7lzIt10jbwVFx1fsfU7X4TxdB/U2G38wfX7tqWxix24Mav RU2Pj5TIQHMthexLs+i+3rh/oNBo/zVbR6FmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Vhayc2nFP6+G50K3NUJkaot7TDt6uiPJSU7Hh3Df1chg3PV2Esx9uOdUAR+NFiRPy3 Dsu+MDlrN6teTvRGCGc7CII0u+kLWUi7aX+s/IIw1x0gj0MRTgCCeyTRZQ+CSlGrOiVw pQp45K7LOpOq2ruSJlPK+ayLKCAPG7BDkh8WQ= MIME-Version: 1.0 Received: by 10.216.11.3 with SMTP id 3mr3720810wew.89.1281027001056; Thu, 05 Aug 2010 09:50:01 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Thu, 5 Aug 2010 09:49:59 -0700 (PDT) In-Reply-To: <798824.20619.qm@web110707.mail.gq1.yahoo.com> References: <798824.20619.qm@web110707.mail.gq1.yahoo.com> Date: Thu, 5 Aug 2010 09:49:59 -0700 Message-ID: From: Jack Vogel To: Scott Johnson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: 8.1-RELEASE em watchdog timeout broken? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 16:50:02 -0000 I'm sending this out as an update to the net mailing list. The problem is that the PC running Windows XP was attempting DHCP on power up thru the bridge, and for some reason this fails in the 8.1 code, but the good news is its fixed in STABLE/8. So, I would recommend going to the STABLE/8 e1000 code as a first step if you are having any problems with any of the 1G drivers. Jack On Tue, Aug 3, 2010 at 7:02 PM, Scott Johnson wrote: > Under 8.0-RELEASE I would get warnings from em(4) in /var/log/messages > about > > "watchdog timeouts" on em0 whenever my desktop PC connected to em0 was > powered > off. This was fine, except for the annoying warnings. > > Under 8.1-RELEASE I no longer get the warnings, and any time my desktop is > powered off, when I turn it back on, it has no connectivity. The interface > is > dead until I log into the console and run: > # ifconfig em0 down up > > The em(4) driver has changed a lot since 8.0-RELEASE. It seems this > watchdog > timeout is no longer working. > > The board is a Supermicro X7SPA-H with Intel 82574L GbE. > > Any ideas for debugging? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 17:20:10 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE04C106566C for ; Thu, 5 Aug 2010 17:20:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CCE1B8FC1D for ; Thu, 5 Aug 2010 17:20:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75HKAC9042105 for ; Thu, 5 Aug 2010 17:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75HKAmI042087; Thu, 5 Aug 2010 17:20:10 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 17:20:10 GMT Message-Id: <201008051720.o75HKAmI042087@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Troye Johnson Cc: Subject: Re: kern/149307: [ath] Doesn't work Atheros 9285 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Troye Johnson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 17:20:11 -0000 The following reply was made to PR kern/149307; it has been noted by GNATS. From: Troye Johnson To: bug-followup@freebsd.org, aksenzov@gmail.com Cc: Subject: Re: kern/149307: [ath] Doesn't work Atheros 9285 Date: Thu, 5 Aug 2010 17:12:56 +0000 --000e0cd2e71e59326d048d16a94b Content-Type: text/plain; charset=ISO-8859-1 The chip scans and associates (according to 'ifconfig') but 'dhclient wlan0' and '/etc/rc.d/netif start' both cannot establish IP. There are multiple PRs out on this issue. PR:kern/148112 is one of them. I will test as soon as word gets out on the mailing list. --000e0cd2e71e59326d048d16a94b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The chip scans and associates (according to 'ifconfig') but 'dh= client wlan0' and '/etc/rc.d/netif start' both cannot establish= IP. There are multiple PRs out on this issue. PR:kern/148112 is one of the= m. I will test as soon as word gets out on the mailing list.
--000e0cd2e71e59326d048d16a94b-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 17:20:12 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 815D8106566B for ; Thu, 5 Aug 2010 17:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6FDF48FC0A for ; Thu, 5 Aug 2010 17:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75HKCps042134 for ; Thu, 5 Aug 2010 17:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75HKCpL042133; Thu, 5 Aug 2010 17:20:12 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 17:20:12 GMT Message-Id: <201008051720.o75HKCpL042133@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Troye Johnson Cc: Subject: Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Troye Johnson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 17:20:12 -0000 The following reply was made to PR kern/149306; it has been noted by GNATS. From: Troye Johnson To: bug-followup@FreeBSD.org, aksenzov@gmail.com Cc: Subject: Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet Date: Thu, 5 Aug 2010 17:16:07 +0000 --000e0cd51986b1efd9048d16b405 Content-Type: text/plain; charset=ISO-8859-1 I think this is misfiled as I have this chip and it is detected properly and and I can transfer files over the link in 100mbit. Misfiled/erroneous PR? --000e0cd51986b1efd9048d16b405 Content-Type: text/html; charset=ISO-8859-1 I think this is misfiled as I have this chip and it is detected properly and and I can transfer files over the link in 100mbit. Misfiled/erroneous PR?
--000e0cd51986b1efd9048d16b405-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 18:20:12 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB88B106564A for ; Thu, 5 Aug 2010 18:20:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BFB5F8FC17 for ; Thu, 5 Aug 2010 18:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75IKBbP000897 for ; Thu, 5 Aug 2010 18:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75IKBaY000896; Thu, 5 Aug 2010 18:20:11 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 18:20:11 GMT Message-Id: <201008051820.o75IKBaY000896@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Kozlov Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Kozlov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 18:20:12 -0000 The following reply was made to PR kern/149185; it has been noted by GNATS. From: Alex Kozlov To: Bernhard Schmidt , bug-followup@freebsd.org, spam@rm-rf.kiev.ua Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Thu, 5 Aug 2010 21:14:41 +0300 On Thu, Aug 05, 2010 at 06:25:32PM +0200, Bernhard Schmidt wrote: > On Thu, Aug 5, 2010 at 11:11, Alex Kozlov wrote: > > On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: > >> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: > >> > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: > >> >>  Regarding the 8.1 if_rum(4) panics...  I got a similar one, extracted > >> >> a dump and tried to gather some info for someone who knows the code: > >> >> > >> >>  The zero divide fault was because (apparently) rate was unitialized, > >> >> as is > >> >> > >> >>       ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] > >> >> > >> >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. > >> > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 > >> > This can be mitigated by patch [1] or by setting ucastrate option in > >> > ifconfig. Still real issue need to be solved. > >> > >> The real issue is that prior to an association (RUN state) > >> ieee80211_ratectl_node_init() is not called, therefore iv_bss is not > >> configured in any way. > > ieee80211_ratectl_node_init() called from iv_newstate when switching to > > IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? > > Some call it from iv_newassoc, but this marked /* XXX move */ > >> I'll look into that if no one beats me. > > Thanks. > Please give attached patch a try, it should fix the issue for rum and > all other drivers relying on the new ratectl stuff. Testing. Thanks again. -- Adios From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 20:10:08 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7B3D106566C for ; Thu, 5 Aug 2010 20:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 80FCF8FC19 for ; Thu, 5 Aug 2010 20:10:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75KA8Ua007204 for ; Thu, 5 Aug 2010 20:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75KA8NX007203; Thu, 5 Aug 2010 20:10:08 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 20:10:08 GMT Message-Id: <201008052010.o75KA8NX007203@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 20:10:08 -0000 The following reply was made to PR kern/144755; it has been noted by GNATS. From: Bernhard Schmidt To: Edwin Groothuis Cc: bug-followup@freebsd.org Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 Date: Thu, 5 Aug 2010 22:08:38 +0200 --0015175cda7eab5eec048d191d67 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 5, 2010 at 00:31, Edwin Groothuis wrote: > [..] > Nice! Is there a workaround or patch available for testing? Please give the attached patch a try. It does not prevent wpa_supplicant from starting twice (for that you can define ctrl_interface= in wpa_supplicant.conf), but should no longer panic. Thanks. -- Bernhard --0015175cda7eab5eec048d191d67 Content-Type: application/octet-stream; name="iwi_node_ref.diff" Content-Disposition: attachment; filename="iwi_node_ref.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gci1jhyx0 SW5kZXg6IHN5cy9kZXYvaXdpL2lmX2l3aS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvaXdpL2lm X2l3aS5jCShyZXZpc2lvbiAyMTA4NzMpCisrKyBzeXMvZGV2L2l3aS9pZl9pd2kuYwkod29ya2lu ZyBjb3B5KQpAQCAtMTM2MiwxMyArMTM2MiwxNCBAQCBpd2lfY2hlY2tmb3Jxb3Moc3RydWN0IGll ZWU4MDIxMXZhcCAqdmFwLAogCQlmcm0gKz0gZnJtWzFdICsgMjsKIAl9CiAKLQluaSA9IHZhcC0+ aXZfYnNzOworCW5pID0gaWVlZTgwMjExX3JlZl9ub2RlKHZhcC0+aXZfYnNzKTsKIAluaS0+bmlf Y2FwaW5mbyA9IGNhcGluZm87CiAJbmktPm5pX2Fzc29jaWQgPSBhc3NvY2lkOwogCWlmICh3bWUg IT0gTlVMTCkKIAkJbmktPm5pX2ZsYWdzIHw9IElFRUU4MDIxMV9OT0RFX1FPUzsKIAllbHNlCiAJ CW5pLT5uaV9mbGFncyAmPSB+SUVFRTgwMjExX05PREVfUU9TOworCWllZWU4MDIxMV9mcmVlX25v ZGUobmkpOwogI3VuZGVmIFNVQlRZUEUKIH0KIApAQCAtMjc3OSw3ICsyNzgwLDcgQEAgaXdpX2F1 dGhfYW5kX2Fzc29jKHN0cnVjdCBpd2lfc29mdGMgKnNjLCBzdHJ1Y3QgaWUKIHsKIAlzdHJ1Y3Qg aWVlZTgwMjExY29tICppYyA9IHZhcC0+aXZfaWM7CiAJc3RydWN0IGlmbmV0ICppZnAgPSB2YXAt Pml2X2lmcDsKLQlzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pID0gdmFwLT5pdl9ic3M7CisJc3Ry dWN0IGllZWU4MDIxMV9ub2RlICpuaSA9IGllZWU4MDIxMV9yZWZfbm9kZSh2YXAtPml2X2Jzcyk7 CiAJc3RydWN0IGl3aV9jb25maWd1cmF0aW9uIGNvbmZpZzsKIAlzdHJ1Y3QgaXdpX2Fzc29jaWF0 ZSAqYXNzb2MgPSAmc2MtPmFzc29jOwogCXN0cnVjdCBpd2lfcmF0ZXNldCByczsKQEAgLTI5NDcs NiArMjk0OCw3IEBAIGl3aV9hdXRoX2FuZF9hc3NvYyhzdHJ1Y3QgaXdpX3NvZnRjICpzYywgc3Ry dWN0IGllCiAJICAgIGxlMTZ0b2goYXNzb2MtPmludHZhbCkpKTsKIAllcnJvciA9IGl3aV9jbWQo c2MsIElXSV9DTURfQVNTT0NJQVRFLCBhc3NvYywgc2l6ZW9mICphc3NvYyk7CiBkb25lOgorCWll ZWU4MDIxMV9mcmVlX25vZGUobmkpOwogCWlmIChlcnJvcikKIAkJSVdJX1NUQVRFX0VORChzYywg SVdJX0ZXX0FTU09DSUFUSU5HKTsKIAo= --0015175cda7eab5eec048d191d67-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 20:30:13 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DB4A1065674 for ; Thu, 5 Aug 2010 20:30:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5C02D8FC08 for ; Thu, 5 Aug 2010 20:30:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75KUDtl027230 for ; Thu, 5 Aug 2010 20:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75KUDnA027223; Thu, 5 Aug 2010 20:30:13 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 20:30:13 GMT Message-Id: <201008052030.o75KUDnA027223@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Hans-Werner Braun Cc: Subject: Re: kern/149086: [multicast] Generic multicast join failure in 8.1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hans-Werner Braun List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 20:30:13 -0000 The following reply was made to PR kern/149086; it has been noted by GNATS. From: Hans-Werner Braun To: bug-followup@FreeBSD.org, hwb@ucsd.edu Cc: Subject: Re: kern/149086: [multicast] Generic multicast join failure in 8.1 Date: Thu, 5 Aug 2010 13:20:56 -0700 A program that is a straight adaptation from the IO::Socket::Multicast man page does not work either: ---- #!/usr/local/bin/perl use strict; use IO::Socket::Multicast; use constant GROUP => '233.7.117.79'; use constant PORT => '4011'; my $sock = IO::Socket::Multicast->new(Proto=>'udp',LocalPort=>PORT); $sock->mcast_add(GROUP) || die "Couldn't set group: $!\n"; while (1) { my $data; next unless $sock->recv($data,1024); print $data; } ---- It only displays data if the multicast stream already exists on the local Ethernet, but it does not send the group join request out to initiate the receiving stream on the local Ethernet. From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 21:00:21 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10CDB106566C for ; Thu, 5 Aug 2010 21:00:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E877A8FC14 for ; Thu, 5 Aug 2010 21:00:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75L0Kfk056478 for ; Thu, 5 Aug 2010 21:00:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75L0KtK056477; Thu, 5 Aug 2010 21:00:20 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 21:00:20 GMT Message-Id: <201008052100.o75L0KtK056477@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Kozlov Cc: Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Kozlov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 21:00:21 -0000 The following reply was made to PR kern/144755; it has been noted by GNATS. From: Alex Kozlov To: Bernhard Schmidt , Edwin Groothuis , bug-followup@freebsd.org, spam@rm-rf.kiev.ua Cc: Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 Date: Thu, 5 Aug 2010 23:55:43 +0300 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 05, 2010 at 08:10:08PM +0000, Bernhard Schmidt wrote: > The following reply was made to PR kern/144755; it has been noted by GNATS. > > From: Bernhard Schmidt > To: Edwin Groothuis > Cc: bug-followup@freebsd.org > Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif > restart on 8-STABLE r205159 > Date: Thu, 5 Aug 2010 22:08:38 +0200 > > --0015175cda7eab5eec048d191d67 > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, Aug 5, 2010 at 00:31, Edwin Groothuis wrote: > > [..] > > Nice! Is there a workaround or patch available for testing? > > Please give the attached patch a try. It does not prevent > wpa_supplicant from starting twice (for that you can define > ctrl_interface= in wpa_supplicant.conf), but should no longer panic. I can reproduce this panic for if_rum, similiar patch also helps. wlan0: ieee80211_new_state_locked: pending RUN -> SCAN transition lost wlan0: ieee80211_new_state_locked: pending RUN -> SCAN transition lost Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffff fault code = supervisor read, page not present instruction pointer = 0x20:0xc0900d42 stack pointer = 0x28:0xc4f05bac frame pointer = 0x28:0xc4f05bb8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (rum0 taskq) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c0669547,c06cb000,c0660c6a,c4f05a5c,c4f05a5c,...) at 0xc0436706 = db_trace_self_wrapper+0x26 panic(c0660c6a,c0680c79,c4f05b6c,1,1,...) at 0xc04b898d = panic+0xed trap_fatal(c06c9740,f000,1,0,c04c0ef6,...) at 0xc06474bd = trap_fatal+0x23d trap_pfault(0,c066c5e8,2d7,0,c06c9220,...) at 0xc064787a = trap_pfault+0x27a trap(c4f05b6c) at 0xc06481ab = trap+0x39b calltrap() at 0xc062d4ac = calltrap+0x6 --- trap 0xc, eip = 0xc0900d42, esp = 0xc4f05bac, ebp = 0xc4f05bb8 --- ieee80211_getcapinfo(c5caa000,ffff,c08f415a,c5caa874,c5463d00,...) at 0xc0900d42 = ieee80211_getcapinfo+0x71 ieee80211_beacon_construct(c62a8000,18,676,c50f5c00,c54e3988,...) at 0xc090308d = ieee80211_beacon_construct+0x67 ieee80211_beacon_alloc(c62a8000,c5caa874,6,2c5,5,...) at 0xc09039a0 = ieee80211_beacon_alloc+0x93 rum_newstate(c5caa000,5,ffffffff,652,c5362014,...) at 0xc9a9b55f = rum_newstate+0x259 ieee80211_newstate_cb(c5caa000,4,0,c0695c9c,0,...) at 0xc0906eb8 = ieee80211_newstate_cb+0x7a taskqueue_run(c537db00,c537db18,0,c0661905,0,...) at 0xc04ef61a = taskqueue_run+0x8a taskqueue_thread_loop(c5362074,c4f05d38,0,0,0,...) at 0xc04efd74 = taskqueue_thread_loop+0x44 fork_exit(c04efd30,c5362074,c4f05d38) at 0xc048e868 = fork_exit+0x88 fork_trampoline() at 0xc062d524 = fork_trampoline+0x8 -- Adios --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" Index: sys/dev/usb/wlan/if_rum.c @@ -719,7 +719,7 @@ break; case IEEE80211_S_RUN: - ni = vap->iv_bss; + ni = ieee80211_ref_node(vap->iv_bss); if (vap->iv_opmode != IEEE80211_M_MONITOR) { rum_update_slot(ic->ic_ifp); @@ -743,6 +743,7 @@ tp = &vap->iv_txparms[ieee80211_chan2mode(ic->ic_curchan)]; if (tp->ucastrate == IEEE80211_FIXED_RATE_NONE) rum_ratectl_start(sc, ni); + ieee80211_free_node(ni); break; default: break; @@ -2216,7 +2217,7 @@ struct ieee80211com *ic = vap->iv_ic; struct ifnet *ifp = ic->ic_ifp; struct rum_softc *sc = ifp->if_softc; - struct ieee80211_node *ni = vap->iv_bss; + struct ieee80211_node *ni; int ok, fail; int sum, retrycnt; @@ -2230,8 +2231,10 @@ sum = ok+fail; retrycnt = (le32toh(sc->sta[5]) & 0xffff) + fail; + ni = ieee80211_ref_node(vap->iv_bss); ieee80211_ratectl_tx_update(vap, ni, &sum, &ok, &retrycnt); (void) ieee80211_ratectl_rate(ni, NULL, 0); + ieee80211_free_node(ni); ifp->if_oerrors += fail; /* count TX retry-fail as Tx errors */ --mYCpIKhGyMATD0i+-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 5 22:00:22 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36219106566B for ; Thu, 5 Aug 2010 22:00:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0A6A88FC38 for ; Thu, 5 Aug 2010 22:00:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o75M0Lk1015197 for ; Thu, 5 Aug 2010 22:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o75M0LMk015196; Thu, 5 Aug 2010 22:00:21 GMT (envelope-from gnats) Date: Thu, 5 Aug 2010 22:00:21 GMT Message-Id: <201008052200.o75M0LMk015196@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Kozlov Cc: Subject: Re: kern/144898: [wpi] [panic] wpi panics system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Kozlov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 22:00:22 -0000 The following reply was made to PR kern/144898; it has been noted by GNATS. From: Alex Kozlov To: Dominic Fandrey , bug-followup@freebsd.org, spam@rm-rf.kiev.ua Cc: Subject: Re: kern/144898: [wpi] [panic] wpi panics system Date: Fri, 6 Aug 2010 00:52:26 +0300 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Dominic It's seems to be common issue for many wireless if drivers. Can You please try this patch? Thanks. -- Adios --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" Index: sys/dev/wpi/if_wpi.c @@ -2399,7 +2399,7 @@ wpi_auth(struct wpi_softc *sc, struct ieee80211vap *vap) { struct ieee80211com *ic = vap->iv_ic; - struct ieee80211_node *ni = vap->iv_bss; + struct ieee80211_node *ni = ieee80211_ref_node(vap->iv_bss); struct wpi_node_info node; int error; @@ -2449,6 +2449,7 @@ node.action = htole32(WPI_ACTION_SET_RATE); node.antenna = WPI_ANTENNA_BOTH; error = wpi_cmd(sc, WPI_CMD_ADD_NODE, &node, sizeof node, 1); + ieee80211_free_node(ni); if (error != 0) device_printf(sc->sc_dev, "could not add BSS node\n"); @@ -2459,7 +2460,7 @@ wpi_run(struct wpi_softc *sc, struct ieee80211vap *vap) { struct ieee80211com *ic = vap->iv_ic; - struct ieee80211_node *ni = vap->iv_bss; + struct ieee80211_node *ni = ieee80211_ref_node(vap->iv_bss); int error; if (vap->iv_opmode == IEEE80211_M_MONITOR) { @@ -2493,8 +2494,9 @@ } error = wpi_set_txpower(sc, ni->ni_chan, 1); + ieee80211_free_node(ni); if (error != 0) { - device_printf(sc->sc_dev, "could set txpower\n"); + device_printf(sc->sc_dev, "could not set txpower\n"); return error; } --7AUc2qLy4jB3hD7Z-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 08:42:59 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A46106566B for ; Fri, 6 Aug 2010 08:42:59 +0000 (UTC) (envelope-from cybercorecentre@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 19B468FC14 for ; Fri, 6 Aug 2010 08:42:58 +0000 (UTC) Received: by vws7 with SMTP id 7so7141214vws.13 for ; Fri, 06 Aug 2010 01:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JQ4l94QO0O9F4FeHlerTgIg/v5FB7TS+OZ9zIzBmWcU=; b=SXTeMrNe3oQUOv53KtqHRdnOzlT5yo9tjFX+b10UY9jm3+W6OGzg7W9oWCoZ9s/DS/ hVQlXpo6cMRnv5aoJqDq/v/Sq9rGuzTYGySKqtmMSod/Y80J4BTahy2pltuAw/AileXc mzr8UyPH+51gQgo1Lm4xjL536XvkGRcbPttI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fdLRwhkUAJ8amniNBY8ZlqslFRewPO+iIWVqRl8Azfnj5uxFwYiGHV5cxFwg251Syu 7n48nBrKinWmRTsdAxZwUFBuR5PhD7DIfrNo+7yuIjwzzs7K47H4qJyZKGIHjOXc8gnv EvUwiasIUgalX1hC5eZrqnTX16dUQ6mGLdoZM= MIME-Version: 1.0 Received: by 10.220.88.147 with SMTP id a19mr8045929vcm.259.1281084178269; Fri, 06 Aug 2010 01:42:58 -0700 (PDT) Received: by 10.220.176.3 with HTTP; Fri, 6 Aug 2010 01:42:58 -0700 (PDT) In-Reply-To: <201008051720.o75HKCpL042133@freefall.freebsd.org> References: <201008051720.o75HKCpL042133@freefall.freebsd.org> Date: Fri, 6 Aug 2010 10:42:58 +0200 Message-ID: From: Charles Logan To: Troye Johnson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 08:42:59 -0000 Hi it;s not working because of you have to apply ms kb2010 08-9 patch. On Thu, Aug 5, 2010 at 7:20 PM, Troye Johnson wrote= : > The following reply was made to PR kern/149306; it has been noted by GNAT= S. > > From: Troye Johnson > To: bug-followup@FreeBSD.org, aksenzov@gmail.com > Cc: > Subject: Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit > =A0 =A0 =A0 =A0Ethernet > Date: Thu, 5 Aug 2010 17:16:07 +0000 > > =A0--000e0cd51986b1efd9048d16b405 > =A0Content-Type: text/plain; charset=3DISO-8859-1 > > =A0I think this is misfiled as I have this chip and it is detected proper= ly and > =A0and I can transfer files over the link in 100mbit. Misfiled/erroneous = PR? > > =A0--000e0cd51986b1efd9048d16b405 > =A0Content-Type: text/html; charset=3DISO-8859-1 > > =A0I think this is misfiled as I have this chip and it is detected proper= ly and and I can transfer files over the link in 100mbit. Misfiled/erroneou= s PR?
> > =A0--000e0cd51986b1efd9048d16b405-- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 08:46:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0E971065670 for ; Fri, 6 Aug 2010 08:46:53 +0000 (UTC) (envelope-from cybercorecentre@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 596188FC19 for ; Fri, 6 Aug 2010 08:46:52 +0000 (UTC) Received: by vws7 with SMTP id 7so7144022vws.13 for ; Fri, 06 Aug 2010 01:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GzzI73jloIsS1jhYFVqFlH+64erH3+2K3Bh1hy7VYVE=; b=jcqtQnrVd4XWgtw1DX4lzAaiW9imez4zm4i7ubyiUUH29ouEC+SFmht2B3cJlWErv7 iX3UxiwDeOqEikvYDlL0KWRdl1t9YUtor9Dcpi0m/dgHDVL+B/ibQppiZa+ydyAShvGg Urn7QxMKIIoA6GXkNGSZfuctMYGJOWmqhS2hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XWiuuJygQfu3DI9S1jBr0wvYRRoABAoBweb6tI5Gl2sF+fEXk6wtFq6iNbW3gkJaJ7 a+8JewXucjrRXPX0uilrQyf/wuwObli7aQ55L0TNY2FaKvX8gB7bI0C00EfE9QnKm64z UJ8tnKP1do2vmuNC3Q4tgNL0Y4C4VAkNUFK/I= MIME-Version: 1.0 Received: by 10.220.62.72 with SMTP id w8mr8067296vch.201.1281084412232; Fri, 06 Aug 2010 01:46:52 -0700 (PDT) Received: by 10.220.176.3 with HTTP; Fri, 6 Aug 2010 01:46:51 -0700 (PDT) In-Reply-To: References: <798824.20619.qm@web110707.mail.gq1.yahoo.com> Date: Fri, 6 Aug 2010 10:46:51 +0200 Message-ID: From: Charles Logan To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Scott Johnson Subject: Re: 8.1-RELEASE em watchdog timeout broken? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 08:46:53 -0000 Our company had to deal with the same problem We going to help you for 10k usd. On Wed, Aug 4, 2010 at 7:19 AM, Jack Vogel wrote: > The watchdog is working in all the internal testing that we've done, if > there's > some corner case here then I need more info to reproduce it. I'm confused > about what's what, which machine is your desktop and what is the 'other' > system? > > For instance, we had a loud complaint about the watchdog here a while bac= k, > and it turned out the user had increased the system HZ value to something > really high... =A0I've yet to see something that indicates the code is br= oken. > > If it involves Windows then it goes outside the parameters of my testing = so > who knows :) > > Jack > > > On Tue, Aug 3, 2010 at 7:02 PM, Scott Johnson wro= te: > >> Under 8.0-RELEASE I would get warnings from em(4) in /var/log/messages >> about >> >> "watchdog timeouts" on em0 whenever my desktop PC connected to em0 was >> powered >> off. This was fine, except for the annoying warnings. >> >> Under 8.1-RELEASE I no longer get the warnings, and any time my desktop = is >> powered off, when I turn it back on, it has no connectivity. The interfa= ce >> is >> dead until I log into the console and run: >> # ifconfig em0 down up >> >> The em(4) driver has changed a lot since 8.0-RELEASE. It seems this >> watchdog >> timeout is no longer working. >> >> The board is a Supermicro X7SPA-H with Intel 82574L GbE. >> >> Any ideas for debugging? >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 08:56:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56CE1065673 for ; Fri, 6 Aug 2010 08:56:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 36DE68FC1E for ; Fri, 6 Aug 2010 08:56:37 +0000 (UTC) Received: (qmail 27212 invoked from network); 6 Aug 2010 07:27:26 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Aug 2010 07:27:26 -0000 Message-ID: <4C5BCE48.5070504@freebsd.org> Date: Fri, 06 Aug 2010 10:56:40 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Maxim Dounin References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> In-Reply-To: <20100713140051.GV99657@mdounin.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Igor Sysoev Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 08:56:39 -0000 On 13.07.2010 16:01, Maxim Dounin wrote: > Hello! > > On Wed, May 12, 2010 at 04:47:02PM +0400, Igor Sysoev wrote: > >> It seems that net.inet.tcp.slowstart_flightsize does not work in 8-STABLE. >> For a long time I used slowstart_flightsize=2 on FreeBSD 4, 6, and 7 hosts. >> However, FreeBSD-8 always starts with the single packet. >> I saw this on different versions of 8-STABLE since 8 Oct 2009 till >> 04 Apr 2010. > > Finally I had some time to look into it (sorry for long delay). > > 1. Slow start isn't used on recent FreeBSD versions for initial snd_cwnd > calculations as long as you have rfc3390 support switched on (default since > Jan 06 23:29:46 2004, at least in 7.*). It effectively sets initial > snd_cwnd to 3*MSS on common networks and shouldn't cause any problems. > Slowstart_flightsize only affects connection restarts. > > 2. Due to bug in syncache code (patch below) all accepted connections has > their snd_cwnd reset to 1*MSS (since r171639, 7.0+ AFAIR). > > 3. Support for rfc3465 introduced in r187289 uncovered (2) as > ACK to SYN/ACK no longer causes snd_cwnd increase by MSS (actually, this > increase shouldn't happen as it's explicitly forbidden by rfc 3390, but > it's another issue). Snd_cwnd remains really small (1*MSS + 1) and this > causes really bad interaction with delayed acks on other side. > > As a workaround to delayed acks interaction problems you may disable > rfc3465 by setting net.inet.tcp.rfc3465 to 0. Correct fix would be to apply > the patch below. > > To Andre Oppermann: could you please take a look at the patch and > commit it if found appropriate? I've committed your fix with svn r210666. In a few days I will MFC it back to the stable branches. Thanks for reporting the bug and a patch for it. -- Andre > # HG changeset patch > # User Maxim Dounin > # Date 1279028684 -14400 > # Node ID 93699203f408fa8e22c971769bde9c26bd14d410 > # Parent e2cf8c51a6294a0d09d5628d96c6ab3ab626957e > Fix cwnd resetting problem introduced in r171639. > > Sc_rxmits counts timer engagements, not actual retransmits, and value 1 > corresponds to no retransmits. Revert check to correct one as present > before r171639. > > diff --git a/netinet/tcp_syncache.c b/netinet/tcp_syncache.c > --- a/netinet/tcp_syncache.c > +++ b/netinet/tcp_syncache.c > @@ -804,8 +804,10 @@ syncache_socket(struct syncache *sc, str > > /* > * If the SYN,ACK was retransmitted, reset cwnd to 1 segment. > + * Note that sc_rxmits counts timer engagements, not actual > + * retransmits. > */ > - if (sc->sc_rxmits) > + if (sc->sc_rxmits> 1) > tp->snd_cwnd = tp->t_maxseg; > tcp_timer_activate(tp, TT_KEEP, tcp_keepinit); > > > Maxim Dounin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 09:01:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EE87106567C for ; Fri, 6 Aug 2010 09:01:00 +0000 (UTC) (envelope-from cybercorecentre@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 06A998FC24 for ; Fri, 6 Aug 2010 09:00:59 +0000 (UTC) Received: by vws7 with SMTP id 7so7154822vws.13 for ; Fri, 06 Aug 2010 02:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CPRKAa/FfKWxfzh1GZQ7P0zYDB5fUCs3Z9ExrioSPgU=; b=RkvJpFA7KEhncgjAdyDJcCmOvy9d63DftwVqAZnKKZNAjM0/Phjr7SnQXO6jzBl+Bo 9dKDGVJKyFrW9c8P+yjO8CdXiMPAVuxjKI8On7IfNRLpSOT/k5CS1qWtVHzDF6hm1Jno a5FVbmzScjjpzPwadLydMqu/fjYrDZK6u/qj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WI+PCywz4NTEa16XVgV2vHTR1H03sKW6plMH+jJqoajSilFgiRgCIOlnhmueCQORDl WAHkQeEjUyUBurq/eKG+eh5Qg8TUCaL1bkT0YGz93KsVoc1r9l+xjZW7c/C+IcBVGsEO eu4/tpZcYKpCOtudFOnQO5x/ZsQa41ZtB0FSA= MIME-Version: 1.0 Received: by 10.220.80.102 with SMTP id s38mr1820003vck.139.1281085259154; Fri, 06 Aug 2010 02:00:59 -0700 (PDT) Received: by 10.220.176.3 with HTTP; Fri, 6 Aug 2010 02:00:58 -0700 (PDT) In-Reply-To: <4C5BCE48.5070504@freebsd.org> References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> Date: Fri, 6 Aug 2010 11:00:58 +0200 Message-ID: From: Charles Logan To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Igor Sysoev , Maxim Dounin Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 09:01:00 -0000 Sorry but this is not a bug. You set bad sysctl flags. We won't add it to our database and this is the final decison. Regards, Freebsd Team On Fri, Aug 6, 2010 at 10:56 AM, Andre Oppermann wrote: > On 13.07.2010 16:01, Maxim Dounin wrote: >> >> Hello! >> >> On Wed, May 12, 2010 at 04:47:02PM +0400, Igor Sysoev wrote: >> >>> It seems that net.inet.tcp.slowstart_flightsize does not work in >>> 8-STABLE. >>> For a long time I used slowstart_flightsize=3D2 on FreeBSD 4, 6, and 7 >>> hosts. >>> However, FreeBSD-8 always starts with the single packet. >>> I saw this on different versions of 8-STABLE since 8 Oct 2009 till >>> 04 Apr 2010. >> >> Finally I had some time to look into it (sorry for long delay). >> >> 1. Slow start isn't used on recent FreeBSD versions for initial snd_cwnd >> calculations as long as you have rfc3390 support switched on (default >> since >> Jan 06 23:29:46 2004, at least in 7.*). =A0It effectively sets initial >> snd_cwnd to 3*MSS on common networks and shouldn't cause any problems. >> Slowstart_flightsize only affects connection restarts. >> >> 2. Due to bug in syncache code (patch below) all accepted connections ha= s >> their snd_cwnd reset to 1*MSS (since r171639, 7.0+ AFAIR). >> >> 3. Support for rfc3465 introduced in r187289 uncovered (2) as >> ACK to SYN/ACK no longer causes snd_cwnd increase by MSS (actually, this >> increase shouldn't happen as it's explicitly forbidden by rfc 3390, but >> it's another issue). =A0Snd_cwnd remains really small (1*MSS + 1) and th= is >> causes really bad interaction with delayed acks on other side. >> >> As a workaround to delayed acks interaction problems you may disable >> rfc3465 by setting net.inet.tcp.rfc3465 to 0. =A0Correct fix would be to >> apply >> the patch below. >> >> To Andre Oppermann: could you please take a look at the patch and >> commit it if found appropriate? > > I've committed your fix with svn r210666. In a few days I will MFC it bac= k > to the stable branches. =A0Thanks for reporting the bug and a patch for i= t. > > -- > Andre > >> # HG changeset patch >> # User Maxim Dounin >> # Date 1279028684 -14400 >> # Node ID 93699203f408fa8e22c971769bde9c26bd14d410 >> # Parent =A0e2cf8c51a6294a0d09d5628d96c6ab3ab626957e >> Fix cwnd resetting problem introduced in r171639. >> >> Sc_rxmits counts timer engagements, not actual retransmits, and value 1 >> corresponds to no retransmits. =A0Revert check to correct one as present >> before r171639. >> >> diff --git a/netinet/tcp_syncache.c b/netinet/tcp_syncache.c >> --- a/netinet/tcp_syncache.c >> +++ b/netinet/tcp_syncache.c >> @@ -804,8 +804,10 @@ syncache_socket(struct syncache *sc, str >> >> =A0 =A0 =A0 =A0/* >> =A0 =A0 =A0 =A0 * If the SYN,ACK was retransmitted, reset cwnd to 1 segm= ent. >> + =A0 =A0 =A0 =A0* Note that sc_rxmits counts timer engagements, not act= ual >> + =A0 =A0 =A0 =A0* retransmits. >> =A0 =A0 =A0 =A0 */ >> - =A0 =A0 =A0 if (sc->sc_rxmits) >> + =A0 =A0 =A0 if (sc->sc_rxmits> =A01) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tp->snd_cwnd =3D tp->t_maxseg; >> =A0 =A0 =A0 =A0tcp_timer_activate(tp, TT_KEEP, tcp_keepinit); >> >> >> Maxim Dounin >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 09:47:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5C271065678 for ; Fri, 6 Aug 2010 09:47:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 100A78FC23 for ; Fri, 6 Aug 2010 09:47:33 +0000 (UTC) Received: (qmail 27733 invoked from network); 6 Aug 2010 08:18:22 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Aug 2010 08:18:22 -0000 Message-ID: <4C5BDA38.8020408@freebsd.org> Date: Fri, 06 Aug 2010 11:47:36 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Charles Logan References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 09:47:34 -0000 On 06.08.2010 11:00, Charles Logan wrote: > Sorry but this is not a bug. You set bad sysctl flags. Care to explain in more detail? For example which sysctl flag was set wrong? > We won't add it to our database and this is the final decison. Which database? > Regards, > Freebsd Team Which team? What is your @FreeBSD.ORG address? -- Andre > On Fri, Aug 6, 2010 at 10:56 AM, Andre Oppermann wrote: >> On 13.07.2010 16:01, Maxim Dounin wrote: >>> >>> Hello! >>> >>> On Wed, May 12, 2010 at 04:47:02PM +0400, Igor Sysoev wrote: >>> >>>> It seems that net.inet.tcp.slowstart_flightsize does not work in >>>> 8-STABLE. >>>> For a long time I used slowstart_flightsize=2 on FreeBSD 4, 6, and 7 >>>> hosts. >>>> However, FreeBSD-8 always starts with the single packet. >>>> I saw this on different versions of 8-STABLE since 8 Oct 2009 till >>>> 04 Apr 2010. >>> >>> Finally I had some time to look into it (sorry for long delay). >>> >>> 1. Slow start isn't used on recent FreeBSD versions for initial snd_cwnd >>> calculations as long as you have rfc3390 support switched on (default >>> since >>> Jan 06 23:29:46 2004, at least in 7.*). It effectively sets initial >>> snd_cwnd to 3*MSS on common networks and shouldn't cause any problems. >>> Slowstart_flightsize only affects connection restarts. >>> >>> 2. Due to bug in syncache code (patch below) all accepted connections has >>> their snd_cwnd reset to 1*MSS (since r171639, 7.0+ AFAIR). >>> >>> 3. Support for rfc3465 introduced in r187289 uncovered (2) as >>> ACK to SYN/ACK no longer causes snd_cwnd increase by MSS (actually, this >>> increase shouldn't happen as it's explicitly forbidden by rfc 3390, but >>> it's another issue). Snd_cwnd remains really small (1*MSS + 1) and this >>> causes really bad interaction with delayed acks on other side. >>> >>> As a workaround to delayed acks interaction problems you may disable >>> rfc3465 by setting net.inet.tcp.rfc3465 to 0. Correct fix would be to >>> apply >>> the patch below. >>> >>> To Andre Oppermann: could you please take a look at the patch and >>> commit it if found appropriate? >> >> I've committed your fix with svn r210666. In a few days I will MFC it back >> to the stable branches. Thanks for reporting the bug and a patch for it. >> >> -- >> Andre >> >>> # HG changeset patch >>> # User Maxim Dounin >>> # Date 1279028684 -14400 >>> # Node ID 93699203f408fa8e22c971769bde9c26bd14d410 >>> # Parent e2cf8c51a6294a0d09d5628d96c6ab3ab626957e >>> Fix cwnd resetting problem introduced in r171639. >>> >>> Sc_rxmits counts timer engagements, not actual retransmits, and value 1 >>> corresponds to no retransmits. Revert check to correct one as present >>> before r171639. >>> >>> diff --git a/netinet/tcp_syncache.c b/netinet/tcp_syncache.c >>> --- a/netinet/tcp_syncache.c >>> +++ b/netinet/tcp_syncache.c >>> @@ -804,8 +804,10 @@ syncache_socket(struct syncache *sc, str >>> >>> /* >>> * If the SYN,ACK was retransmitted, reset cwnd to 1 segment. >>> + * Note that sc_rxmits counts timer engagements, not actual >>> + * retransmits. >>> */ >>> - if (sc->sc_rxmits) >>> + if (sc->sc_rxmits> 1) >>> tp->snd_cwnd = tp->t_maxseg; >>> tcp_timer_activate(tp, TT_KEEP, tcp_keepinit); >>> >>> >>> Maxim Dounin >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 11:24:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E67106564A for ; Fri, 6 Aug 2010 11:24:06 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 26EBC8FC13 for ; Fri, 6 Aug 2010 11:24:05 +0000 (UTC) Received: by qwg5 with SMTP id 5so3398272qwg.13 for ; Fri, 06 Aug 2010 04:24:05 -0700 (PDT) Received: by 10.224.87.139 with SMTP id w11mr5819157qal.358.1281093845299; Fri, 06 Aug 2010 04:24:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.20 with HTTP; Fri, 6 Aug 2010 04:23:45 -0700 (PDT) In-Reply-To: <4C5BDA38.8020408@freebsd.org> References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <4C5BDA38.8020408@freebsd.org> From: Vlad Galu Date: Fri, 6 Aug 2010 13:23:45 +0200 Message-ID: To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 11:24:06 -0000 On Fri, Aug 6, 2010 at 11:47 AM, Andre Oppermann wrote: > On 06.08.2010 11:00, Charles Logan wrote: >> >> Sorry but this is not a bug. You set bad sysctl flags. > > Care to explain in more detail? =A0For example which sysctl flag was set > wrong? > >> We won't add it to our database and this is the final decison. > > Which database? > >> Regards, >> Freebsd Team > > Which team? =A0What is your @FreeBSD.ORG address? It's a spambot. --=20 Good, fast & cheap. Pick any two. From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 16:06:50 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F5201065680 for ; Fri, 6 Aug 2010 16:06:50 +0000 (UTC) (envelope-from sethj@greatbaysoftware.com) Received: from portcityhosting.com (edge.tidalhosting.net [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB4C8FC25 for ; Fri, 6 Aug 2010 16:06:48 +0000 (UTC) Received: from sjeacopello ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Fri, 6 Aug 2010 11:26:47 -0400 X-WatchGuard-Mail-Exception: Allow From: "Seth Jeacopello" To: Date: Fri, 6 Aug 2010 11:26:46 -0400 Message-ID: MIME-Version: 1.0 X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Server sporadically sending unexpected RST to Client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:06:50 -0000 Hello, We have recently upgraded some productions systems to 8.0-p2 from 7.1-p5 and are having some sporadic issues with TCP connections that were not occurring previously. The problem was first noticed while running slapd with clients coming in at various times to make LDAP queries; at various points during the day we would receive the follow message in the slapd log (along with the client complaining because the connection was reset): daemon: accept(7) failed errno=53 (Software caused connection abort) We began digging into slapd, during which we were running tcpdump to catch the traffic between the client and server. After a bit tracing through the dumps, the following pattern emerged during the failure times: Client -> Server [SYN] Server -> Client [SYN, ACK] Client -> Server [ACK] Client -> Server [Request] Server -> Client [RST] Server -> Client [Response] Client -> Server [RST] Between the trace above and the accept error, it prompted the question as to why slapd would be throwing an accept error and still be trying to respond to data? It felt like a double trigger, but slapd doesn't appear to be reusing anything, so our next steps lead us to either something in pf or in the kernel as potentially causing the error. The first step was to remove pf as a variable, so we disabled pf (pfctl -d) and found that the issue continued. Eventually, we turned on net.inet.flowtable.debug and net.inet.tcp.log_debug in order to capture some more data and that lead us to the following error: kernel: TCP: [10.174.80.233]:20949 to [10.174.80.242]:389 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST The first thought was we were overflowing the listen queue but netstat -sp tcp showed the listen queue overflows count was not increasing and the system itself didn't have that many connections coming in at that time (though there was quite a bit of activity from various clients). We also verified that the CPU and memory usage was within a reasonable range (nothing was being stressed and there was plenty of memory to go around. For the sake of being complete, the server in question is a dual CPU (eight cores total) Intel server with 12GB of memory). All of this prompted us to build a debug version of the kernel with some additional logging and we eventually found that we were ultimately failing in in_pcb.c, in_pcbconnect_setup we got EADDRINUSE returned after the in_pcblookup_hash call. We've also noticed that net.tcp.syncache.count will go to -1 when this failure occurs. Per a similar issue (http://lists.freebsd.org/pipermail/freebsd-net/2010-May/025307.html) we were lead to trying to turn off syncookies by setting net.inet.tcp.syncookies to zero which has lead to the error not reappearing (and syncache.count never goes back to -1), however, the connection failures would still occur (shown from client logs and backed up by tcpdumps that show the same pattern as above). This would seem to indicate that there is a problem with syncache. Additionally, we've also found the following pattern while debugging the kernel for the failed connection (note: syncookies is still disabled at this point): kernel: Entering syncache_add kernel: Entering syncache_expand kernel: TCP: [10.174.50.35]:43667 to [10.174.80.242]:389 tcpflags 0x18; syncache_expand: Just before syncache_socket() kernel: Entering syncache_socket kernel: Entering syncache_expand kernel: TCP: [10.174.50.35]:43667 to [10.174.80.242]:389 tcpflags 0x10; syncache_expand: Spurious ACK, segment rejected (syncookies disabled) The above pattern appears to indicate that the PSH is coming in before the final ACK in the handshake (somehow out of order); however, the tcpdumps clearly show everything is coming across in order. Finally, we've also attempted to test with syncookies=1 and syncookies_only=1, which results in the connection failures (as well as the reappearance of the slapd accept error messages). Does anyone have any thoughts on this issue? # uname -a FreeBSD HA1 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #8: Mon Apr 19 16:31:20 UTC 2010 sethj@newcastle.greatbaysoftware.com:/usr/obj/usr/src/sys/KERNEL i386 # sysctl net.inet.tcp.syncache net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: -1 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 # netstat -Lan | grep 389 tcp4 0/0/128 *.389 # netstat -sp tcp tcp: 5596836 packets sent 2431990 data packets (3645983288 bytes) 33 data packets (31121 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 2498873 ack-only packets (48245 delayed) 0 URG only packets 0 window probe packets 588193 window update packets 77883 control packets 10770625 packets received 4611316 acks (for 3643955099 bytes) 54176 duplicate acks 0 acks for unsent data 6172078 packets (2931863382 bytes) received in-sequence 72 completely duplicate packets (10151 bytes) 46 old duplicate packets 0 packets with some dup. data (0 bytes duped) 4136 out-of-order packets (3650806 bytes) 0 packets (0 bytes) of data after window 0 window probes 486096 window update packets 153 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 18353 connection requests 62559 connection accepts 0 bad connection attempts 0 listen queue overflows 1 ignored RSTs in the window 80905 connections established (including accepts) 80811 connections closed (including 21351 drops) 58462 connections updated cached RTT on close 58462 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 9 embryonic connections dropped 4523602 segments updated rtt (of 1677015 attempts) 11 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 207248 correct ACK header predictions 5223266 correct data packet header predictions 62537 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 62559 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 2 aborted 0 badack 0 unreach 0 zone failures 17491 cookies sent 24 cookies received 6 SACK recovery episodes 21 segment rexmits in SACK recovery episodes 25132 byte rexmits in SACK recovery episodes 64 SACK options (SACK blocks) received 2627 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window KERNCONF: # Inherit config (most stuff) -- this is slightly customized version... # inherits from GENERIC-cust (tweaked to disable the default scheduler) include PAE-cust # Name of this kernel ident KERNEL makeoptions NO_MODULES=yes #makeoptions MODULES_OVERRIDE=geom/geom_journal # Scheduler -- From /usr/src/sys/conf/NOTES: # # SCHED_ULE provides significant performance advantages over 4BSD on many # workloads on SMP machines. It supports cpu-affinity, per-cpu runqueues # and scheduler locks. It also has a stronger notion of interactivity # which leads to better responsiveness even on uniprocessor machines. This # will eventually become the default scheduler. # options SCHED_ULE # Note: we're compiling modules in statically since with PAE we don't want to # load KLDs. See comments in pae(4) and PAE kernel conf file. # Hardware Monitoring / Management device ipmi # Storage options GEOM_JOURNAL # Firewall device pf #PF OpenBSD packet-filter firewall device pflog #logging support interface for PF # device pfsync #synchronization interface for PF options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_NOPCC # Required for SMP builds # Linux Emulation options COMPAT_LINUX options LINPROCFS options LINSYSFS # Screen saver # device green_saver ### Network perf tuning options ACCEPT_FILTER_HTTP # options ZERO_COPY_SOCKETS # See polling(4)) options DEVICE_POLLING options HZ=1000 # Avoid scrambled kernel messages during boot -- Trac #1458 options PRINTF_BUFR_SIZE=256 # End config From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 17:03:28 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5520F106567E for ; Fri, 6 Aug 2010 17:03:28 +0000 (UTC) (envelope-from pebu3op@googlemail.com) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by mx1.freebsd.org (Postfix) with ESMTP id 196188FC1C for ; Fri, 6 Aug 2010 17:03:27 +0000 (UTC) Received: from raven.net.t-labs.tu-berlin.de (raven.net.t-labs.tu-berlin.de [130.149.220.18]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id AD162700043D for ; Fri, 6 Aug 2010 19:03:26 +0200 (CEST) From: Alexander Fiveg Organization: Google To: freebsd-net@freebsd.org Date: Fri, 6 Aug 2010 19:03:25 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201008061903.25659.pebu3op@googlemail.com> Subject: problem with 82599 controller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pebu3op@googlemail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 17:03:28 -0000 Hello, the following problem I've faced while working with 82599-controller (ixgbe driver): - During packet capturing, after the number of received packets exceeds all allocated descriptors (ixgbe_rxd * ixgbe_num_queues), the next new incoming packets will be sometimes DMA'ed into the RAM incorrectly. Output from my tcpdump session: % tcpdump -i ix1 ... 15:36:54.970343 IP 10.0.0.2.discard > 12.0.0.160.2200: UDP, length 58 15:36:55.070357 IP 10.0.0.2.discard > 12.0.0.161.2200: UDP, length 58 15:36:55.170373 c7:49:54:a8:00:0c (oui Unknown) > 35:c5:66:d7:df:e8 (oui Unknown), ethertype Unknown (0xd53b), length 100: 0x0000: 4d98 ed85 7537 3b6b 3b8f 7102 4b1c 2cd4 M...u7;k;.q.K.,. 0x0010: 41a8 2f3d 4faa fc8a a039 0fe2 5960 fad5 A./=O....9..Y`.. 0x0020: c8b0 964b b0e0 2213 6aa2 330c ef93 80a9 ...K..".j.3..... 0x0030: 6ac8 071b a9bd 0d51 ecca 94ba ac9c 873b j......Q.......; 0x0040: a83f aeb0 20f4 cfd9 d1fa 93f3 795c 7d20 .?..........y\}. 0x0050: 2993 ). 15:36:55.270388 IP 10.0.0.2.discard > 12.0.0.163.2200: UDP, length 58 ... For packets generating I am using Linux kernel packet generator. The receive- and send-interfaces are connected directly (without any hops in the middle). By the each new generated packet the destination-IP-address will be incremented, so I can proof the correctness of received traffic. This error appears in both -STABLE and -CURRENT I guess it is not a software bug and I would like to check out whether the controller is in order. Are there any test setups for 8259x controllers that I could use ? Thanks, Alex From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 17:21:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5030106564A for ; Fri, 6 Aug 2010 17:21:00 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 31D7C8FC1D for ; Fri, 6 Aug 2010 17:20:59 +0000 (UTC) Received: by wyj26 with SMTP id 26so9951706wyj.13 for ; Fri, 06 Aug 2010 10:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VuBpEC3A+HDf9nlrCvvy9Ys/KokpOUEh+hRU4GGgFvM=; b=xGWMb/Hsd8wyemd6N0Gk6N98DJfSjefKDAUGGCLcZeuxgP1/fTVBKvcJz7HksthhBF 7SuLxZdAlG880FlcMUpB5eWsk0LXQKd3Bj5tsec0tW5/WeJv9xX5nWoKRebql+SATN9v BjBUlexClRI+aTgumzyDhpGrwI19I0xGsY3/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Zbw3GakbMbt3+SJWeVGvxNUBTb9JWIQD9skdsqkGW2dFcKwTqHEDs8/sN7HM8WRDz7 jnPe17Wi2lNiDwVwtUDKD/4VDQ+KVx+FSRZQ95+rRFMeVeeYtiOU+0BCIQ53uZn8RIZN DXtKajGOgHssWOppZnWdM2xsOEzLM9zvdKnYk= MIME-Version: 1.0 Received: by 10.216.90.3 with SMTP id d3mr10924635wef.99.1281115259185; Fri, 06 Aug 2010 10:20:59 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Fri, 6 Aug 2010 10:20:58 -0700 (PDT) In-Reply-To: <201008061903.25659.pebu3op@googlemail.com> References: <201008061903.25659.pebu3op@googlemail.com> Date: Fri, 6 Aug 2010 10:20:58 -0700 Message-ID: From: Jack Vogel To: pebu3op@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: problem with 82599 controller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 17:21:00 -0000 What is the exact PCI ID of your adapter (pciconf -l)? How is it configured, on what kind of hardware, how many queues does it have, etc, etc? Jack On Fri, Aug 6, 2010 at 10:03 AM, Alexander Fiveg wrote: > Hello, > > the following problem I've faced while working with 82599-controller (ixgbe > driver): > > - During packet capturing, after the number of received packets exceeds all > allocated descriptors (ixgbe_rxd * ixgbe_num_queues), the next new incoming > packets will be sometimes DMA'ed into the RAM incorrectly. > > Output from my tcpdump session: > > % tcpdump -i ix1 > ... > 15:36:54.970343 IP 10.0.0.2.discard > 12.0.0.160.2200: UDP, length 58 > 15:36:55.070357 IP 10.0.0.2.discard > 12.0.0.161.2200: UDP, length 58 > 15:36:55.170373 c7:49:54:a8:00:0c (oui Unknown) > 35:c5:66:d7:df:e8 (oui > Unknown), ethertype Unknown (0xd53b), length 100: > 0x0000: 4d98 ed85 7537 3b6b 3b8f 7102 4b1c 2cd4 M...u7;k;.q.K.,. > 0x0010: 41a8 2f3d 4faa fc8a a039 0fe2 5960 fad5 A./=O....9..Y`.. > 0x0020: c8b0 964b b0e0 2213 6aa2 330c ef93 80a9 ...K..".j.3..... > 0x0030: 6ac8 071b a9bd 0d51 ecca 94ba ac9c 873b j......Q.......; > 0x0040: a83f aeb0 20f4 cfd9 d1fa 93f3 795c 7d20 .?..........y\}. > 0x0050: 2993 ). > 15:36:55.270388 IP 10.0.0.2.discard > 12.0.0.163.2200: UDP, length 58 > ... > > For packets generating I am using Linux kernel packet generator. The > receive- > and send-interfaces are connected directly (without any hops in the > middle). > By the each new generated packet the destination-IP-address will be > incremented, so I can proof the correctness of received traffic. This > error > appears in both -STABLE and -CURRENT > > I guess it is not a software bug and I would like to check out whether the > controller is in order. > > Are there any test setups for 8259x controllers that I could use ? > > Thanks, > Alex > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 17:56:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0624A106564A for ; Fri, 6 Aug 2010 17:56:02 +0000 (UTC) (envelope-from pebu3op@googlemail.com) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by mx1.freebsd.org (Postfix) with ESMTP id 7671E8FC15 for ; Fri, 6 Aug 2010 17:55:58 +0000 (UTC) Received: from raven.net.t-labs.tu-berlin.de (raven.net.t-labs.tu-berlin.de [130.149.220.18]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id E4700700043D; Fri, 6 Aug 2010 19:55:57 +0200 (CEST) From: Alexander Fiveg Organization: Google To: Jack Vogel Date: Fri, 6 Aug 2010 19:55:56 +0200 User-Agent: KMail/1.9.10 References: <201008061903.25659.pebu3op@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201008061955.56908.pebu3op@googlemail.com> Cc: freebsd-net@freebsd.org Subject: Re: problem with 82599 controller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pebu3op@googlemail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 17:56:02 -0000 On Friday 06 August 2010 19:20:58 Jack Vogel wrote: > What is the exact PCI ID of your adapter (pciconf -l)? 0x10fb % sysctl dev.ix.0 ~ dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.2.1 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0003 class=0x020000 dev.ix.0.%parent: pci1 dev.ix.0.stats: -1 dev.ix.0.debug: -1 dev.ix.0.flow_control: 3 dev.ix.0.enable_aim: 1 dev.ix.0.rx_processing_limit: 128 % pciconf -l none0@pci0:0:0:0: class=0x058000 card=0x00000000 chip=0x005e10de rev=0xa3 hdr=0x00 isab0@pci0:0:1:0: class=0x060100 card=0xcb8410de chip=0x005110de rev=0xa3 hdr=0x00 none1@pci0:0:1:1: class=0x0c0500 card=0xcb8410de chip=0x005210de rev=0xa2 hdr=0x00 ohci0@pci0:0:2:0: class=0x0c0310 card=0xcb8410de chip=0x005a10de rev=0xa2 hdr=0x00 ehci0@pci0:0:2:1: class=0x0c0320 card=0xcb8410de chip=0x005b10de rev=0xa3 hdr=0x00 atapci0@pci0:0:6:0: class=0x01018a card=0xcb8410de chip=0x005310de rev=0xf2 hdr=0x00 atapci1@pci0:0:7:0: class=0x010485 card=0xcb8410de chip=0x005410de rev=0xf3 hdr=0x00 atapci2@pci0:0:8:0: class=0x010485 card=0xcb8410de chip=0x005510de rev=0xf3 hdr=0x00 pcib1@pci0:0:9:0: class=0x060401 card=0x00000000 chip=0x005c10de rev=0xa2 hdr=0x01 pcib2@pci0:0:13:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 hdr=0x01 pcib3@pci0:0:14:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 hdr=0x01 hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 hostb4@pci0:0:25:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 hostb5@pci0:0:25:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 hostb6@pci0:0:25:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 hostb7@pci0:0:25:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 hostb8@pci0:0:26:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 hostb9@pci0:0:26:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 hostb10@pci0:0:26:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 hostb11@pci0:0:26:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 hostb12@pci0:0:27:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 hostb13@pci0:0:27:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 hostb14@pci0:0:27:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 hostb15@pci0:0:27:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vgapci0@pci0:3:1:0: class=0x030000 card=0x80081002 chip=0x47521002 rev=0x27 hdr=0x00 ix0@pci0:1:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 ix1@pci0:1:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 pcib5@pci0:4:1:0: class=0x060400 card=0x00000000 chip=0x74581022 rev=0x12 hdr=0x01 ioapic0@pci0:4:1:1: class=0x080010 card=0x74591022 chip=0x74591022 rev=0x12 hdr=0x00 pcib6@pci0:4:2:0: class=0x060400 card=0x00000000 chip=0x74581022 rev=0x12 hdr=0x01 ioapic1@pci0:4:2:1: class=0x080010 card=0x74591022 chip=0x74591022 rev=0x12 hdr=0x00 em0@pci0:5:3:0: class=0x020000 card=0x117a15d9 chip=0x10798086 rev=0x03 hdr=0x00 em1@pci0:5:3:1: class=0x020000 card=0x117a15d9 chip=0x10798086 rev=0x03 hdr=0x00 % uname -pr 8.1-STABLE i386 > > How is it configured, on what kind of hardware, how many queues does it > have, > etc, etc? 8 x CPUs - 8 x queues But by reducing the number of queues this problem will appear more often, because the descriptors will be more often reused. (It happens only by the reusing of descriptors. The first (desc_num*queue_num) packets are ALWAYS correctly! after kldload ixgbe.ko in /var/log/messages: Aug 6 16:21:52 ringmap-2 kernel: ix0: port 0xac00-0xac1f mem 0xfe780000-0xfe7fffff,0xfe77c000-0xfe77ffff irq 16 at device 0.0 on pci1 Aug 6 16:21:52 ringmap-2 kernel: ix0: Using MSIX interrupts with 9 vectors Aug 6 16:21:52 ringmap-2 kernel: ix0: [ITHREAD] Aug 6 16:21:52 ringmap-2 last message repeated 8 times Aug 6 16:21:52 ringmap-2 kernel: ix0: Ethernet address: 00:1b:21:5a:67:70 Aug 6 16:21:52 ringmap-2 kernel: ix0: PCI Express Bus: Speed 2.5Gb/s Width x8 Aug 6 16:21:52 ringmap-2 kernel: ix1: port 0xa800-0xa81f mem 0xfe680000-0xfe6fffff,0xfe778000-0xfe77bfff irq 17 at device 0.1 on pci1 Aug 6 16:21:52 ringmap-2 kernel: ix1: Using MSIX interrupts with 9 vectors Aug 6 16:21:52 ringmap-2 kernel: ix1: RX Descriptors exceed system mbuf max, using default instead! Aug 6 16:21:52 ringmap-2 kernel: ix1: [ITHREAD] Aug 6 16:21:52 ringmap-2 last message repeated 8 times Aug 6 16:21:52 ringmap-2 kernel: ix1: Ethernet address: 00:1b:21:5a:67:71 Aug 6 16:21:52 ringmap-2 kernel: ix1: PCI Express Bus: Speed 2.5Gb/s Width x8 ================================================ Something else ? Thanks, Alex > > Jack > > On Fri, Aug 6, 2010 at 10:03 AM, Alexander Fiveg wrote: > > Hello, > > > > the following problem I've faced while working with 82599-controller > > (ixgbe driver): > > > > - During packet capturing, after the number of received packets exceeds > > all allocated descriptors (ixgbe_rxd * ixgbe_num_queues), the next new > > incoming packets will be sometimes DMA'ed into the RAM incorrectly. > > > > Output from my tcpdump session: > > > > % tcpdump -i ix1 > > ... > > 15:36:54.970343 IP 10.0.0.2.discard > 12.0.0.160.2200: UDP, length 58 > > 15:36:55.070357 IP 10.0.0.2.discard > 12.0.0.161.2200: UDP, length 58 > > 15:36:55.170373 c7:49:54:a8:00:0c (oui Unknown) > 35:c5:66:d7:df:e8 (oui > > Unknown), ethertype Unknown (0xd53b), length 100: > > 0x0000: 4d98 ed85 7537 3b6b 3b8f 7102 4b1c 2cd4 M...u7;k;.q.K.,. > > 0x0010: 41a8 2f3d 4faa fc8a a039 0fe2 5960 fad5 A./=O....9..Y`.. > > 0x0020: c8b0 964b b0e0 2213 6aa2 330c ef93 80a9 ...K..".j.3..... > > 0x0030: 6ac8 071b a9bd 0d51 ecca 94ba ac9c 873b j......Q.......; > > 0x0040: a83f aeb0 20f4 cfd9 d1fa 93f3 795c 7d20 .?..........y\}. > > 0x0050: 2993 ). > > 15:36:55.270388 IP 10.0.0.2.discard > 12.0.0.163.2200: UDP, length 58 > > ... > > > > For packets generating I am using Linux kernel packet generator. The > > receive- > > and send-interfaces are connected directly (without any hops in the > > middle). > > By the each new generated packet the destination-IP-address will be > > incremented, so I can proof the correctness of received traffic. This > > error > > appears in both -STABLE and -CURRENT > > > > I guess it is not a software bug and I would like to check out whether > > the controller is in order. > > > > Are there any test setups for 8259x controllers that I could use ? > > > > Thanks, > > Alex > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 18:06:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CD981065675 for ; Fri, 6 Aug 2010 18:06:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 560B18FC0C for ; Fri, 6 Aug 2010 18:06:13 +0000 (UTC) Received: by wyj26 with SMTP id 26so10007788wyj.13 for ; Fri, 06 Aug 2010 11:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ftTA6AmVDAHpk/JcGFEzhbd/30j3LRQcLQHFWMiIDiI=; b=PbcDmzsgLgK/RDmvxX9urJIKfX90xqXUmnvM0MAsdc3vNP2IFHv0aJ3PfGnkVFm8q4 /kf3mzskdZKW3VKinB7UlacEsBke9BfRQmTI3bam4ubPymgXLwZNAoSCzt5TNSYkoiXH HkzABUdrglSBhcN1oatPMQGRku4dHjk3zyPf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F2BtoTn9do5zPnfiK+lX8QyAlACpCDBuqCZhCHvNJ0+XYM+bmFIfJGA39q+61UEbuP mkdHkESaHB/VpVbdM7/G37ntCTO+yp3XkQzC2jYB9Ttc/qzV6vHeyzwU62mCsqXi3pfs PFvV6xXN/kzHbyLwQSJ3F1imu5saUm4RJz76c= MIME-Version: 1.0 Received: by 10.216.2.129 with SMTP id 1mr1179683wef.40.1281117973135; Fri, 06 Aug 2010 11:06:13 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Fri, 6 Aug 2010 11:06:12 -0700 (PDT) In-Reply-To: <201008061955.56908.pebu3op@googlemail.com> References: <201008061903.25659.pebu3op@googlemail.com> <201008061955.56908.pebu3op@googlemail.com> Date: Fri, 6 Aug 2010 11:06:12 -0700 Message-ID: From: Jack Vogel To: pebu3op@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: problem with 82599 controller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 18:06:15 -0000 Ouch, you're running 32 bit? Can you compare 64 bit and see if that has any effect? Jack On Fri, Aug 6, 2010 at 10:55 AM, Alexander Fiveg wrote: > On Friday 06 August 2010 19:20:58 Jack Vogel wrote: > > What is the exact PCI ID of your adapter (pciconf -l)? > 0x10fb > > % sysctl dev.ix.0 > ~ > dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - > 2.2.1 > dev.ix.0.%driver: ix > dev.ix.0.%location: slot=0 function=0 > dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 > subdevice=0x0003 class=0x020000 > dev.ix.0.%parent: pci1 > dev.ix.0.stats: -1 > dev.ix.0.debug: -1 > dev.ix.0.flow_control: 3 > dev.ix.0.enable_aim: 1 > dev.ix.0.rx_processing_limit: 128 > > > % pciconf -l > none0@pci0:0:0:0: class=0x058000 card=0x00000000 chip=0x005e10de > rev=0xa3 hdr=0x00 > isab0@pci0:0:1:0: class=0x060100 card=0xcb8410de chip=0x005110de > rev=0xa3 hdr=0x00 > none1@pci0:0:1:1: class=0x0c0500 card=0xcb8410de chip=0x005210de > rev=0xa2 hdr=0x00 > ohci0@pci0:0:2:0: class=0x0c0310 card=0xcb8410de chip=0x005a10de > rev=0xa2 hdr=0x00 > ehci0@pci0:0:2:1: class=0x0c0320 card=0xcb8410de chip=0x005b10de > rev=0xa3 hdr=0x00 > atapci0@pci0:0:6:0: class=0x01018a card=0xcb8410de chip=0x005310de > rev=0xf2 hdr=0x00 > atapci1@pci0:0:7:0: class=0x010485 card=0xcb8410de chip=0x005410de > rev=0xf3 hdr=0x00 > atapci2@pci0:0:8:0: class=0x010485 card=0xcb8410de chip=0x005510de > rev=0xf3 hdr=0x00 > pcib1@pci0:0:9:0: class=0x060401 card=0x00000000 chip=0x005c10de > rev=0xa2 hdr=0x01 > pcib2@pci0:0:13:0: class=0x060400 card=0x00000000 chip=0x005d10de > rev=0xa3 hdr=0x01 > pcib3@pci0:0:14:0: class=0x060400 card=0x00000000 chip=0x005d10de > rev=0xa3 hdr=0x01 > hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 > rev=0x00 hdr=0x00 > hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 > rev=0x00 hdr=0x00 > hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 > rev=0x00 hdr=0x00 > hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 > rev=0x00 hdr=0x00 > hostb4@pci0:0:25:0: class=0x060000 card=0x00000000 chip=0x11001022 > rev=0x00 hdr=0x00 > hostb5@pci0:0:25:1: class=0x060000 card=0x00000000 chip=0x11011022 > rev=0x00 hdr=0x00 > hostb6@pci0:0:25:2: class=0x060000 card=0x00000000 chip=0x11021022 > rev=0x00 hdr=0x00 > hostb7@pci0:0:25:3: class=0x060000 card=0x00000000 chip=0x11031022 > rev=0x00 hdr=0x00 > hostb8@pci0:0:26:0: class=0x060000 card=0x00000000 chip=0x11001022 > rev=0x00 hdr=0x00 > hostb9@pci0:0:26:1: class=0x060000 card=0x00000000 chip=0x11011022 > rev=0x00 hdr=0x00 > hostb10@pci0:0:26:2: class=0x060000 card=0x00000000 chip=0x11021022 > rev=0x00 hdr=0x00 > hostb11@pci0:0:26:3: class=0x060000 card=0x00000000 chip=0x11031022 > rev=0x00 hdr=0x00 > hostb12@pci0:0:27:0: class=0x060000 card=0x00000000 chip=0x11001022 > rev=0x00 hdr=0x00 > hostb13@pci0:0:27:1: class=0x060000 card=0x00000000 chip=0x11011022 > rev=0x00 hdr=0x00 > hostb14@pci0:0:27:2: class=0x060000 card=0x00000000 chip=0x11021022 > rev=0x00 hdr=0x00 > hostb15@pci0:0:27:3: class=0x060000 card=0x00000000 chip=0x11031022 > rev=0x00 hdr=0x00 > vgapci0@pci0:3:1:0: class=0x030000 card=0x80081002 chip=0x47521002 > rev=0x27 hdr=0x00 > ix0@pci0:1:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 > hdr=0x00 > ix1@pci0:1:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 > hdr=0x00 > pcib5@pci0:4:1:0: class=0x060400 card=0x00000000 chip=0x74581022 > rev=0x12 hdr=0x01 > ioapic0@pci0:4:1:1: class=0x080010 card=0x74591022 chip=0x74591022 > rev=0x12 hdr=0x00 > pcib6@pci0:4:2:0: class=0x060400 card=0x00000000 chip=0x74581022 > rev=0x12 hdr=0x01 > ioapic1@pci0:4:2:1: class=0x080010 card=0x74591022 chip=0x74591022 > rev=0x12 hdr=0x00 > em0@pci0:5:3:0: class=0x020000 card=0x117a15d9 chip=0x10798086 rev=0x03 > hdr=0x00 > em1@pci0:5:3:1: class=0x020000 card=0x117a15d9 chip=0x10798086 rev=0x03 > hdr=0x00 > > % uname -pr > 8.1-STABLE i386 > > > > > > How is it configured, on what kind of hardware, how many queues does it > > have, > > etc, etc? > 8 x CPUs - 8 x queues > But by reducing the number of queues this problem will appear more often, > because the descriptors will be more often reused. (It happens only by the > reusing of descriptors. The first (desc_num*queue_num) packets are ALWAYS > correctly! > > > after kldload ixgbe.ko in /var/log/messages: > > Aug 6 16:21:52 ringmap-2 kernel: ix0: Network > Driver, Version - 2.2.1> port 0xac00-0xac1f mem > 0xfe780000-0xfe7fffff,0xfe77c000-0xfe77ffff irq 16 at device 0.0 on pci1 > Aug 6 16:21:52 ringmap-2 kernel: ix0: Using MSIX interrupts with 9 vectors > Aug 6 16:21:52 ringmap-2 kernel: ix0: [ITHREAD] > Aug 6 16:21:52 ringmap-2 last message repeated 8 times > Aug 6 16:21:52 ringmap-2 kernel: ix0: Ethernet address: 00:1b:21:5a:67:70 > Aug 6 16:21:52 ringmap-2 kernel: ix0: PCI Express Bus: Speed 2.5Gb/s Width > x8 > Aug 6 16:21:52 ringmap-2 kernel: ix1: Network > Driver, Version - 2.2.1> port 0xa800-0xa81f mem > 0xfe680000-0xfe6fffff,0xfe778000-0xfe77bfff irq 17 at device 0.1 on pci1 > Aug 6 16:21:52 ringmap-2 kernel: ix1: Using MSIX interrupts with 9 vectors > Aug 6 16:21:52 ringmap-2 kernel: ix1: RX Descriptors exceed system mbuf > max, > using default instead! > Aug 6 16:21:52 ringmap-2 kernel: ix1: [ITHREAD] > Aug 6 16:21:52 ringmap-2 last message repeated 8 times > Aug 6 16:21:52 ringmap-2 kernel: ix1: Ethernet address: 00:1b:21:5a:67:71 > Aug 6 16:21:52 ringmap-2 kernel: ix1: PCI Express Bus: Speed 2.5Gb/s Width > x8 > > ================================================ > > Something else ? > > Thanks, > Alex > > > > > > Jack > > > > On Fri, Aug 6, 2010 at 10:03 AM, Alexander Fiveg > wrote: > > > Hello, > > > > > > the following problem I've faced while working with 82599-controller > > > (ixgbe driver): > > > > > > - During packet capturing, after the number of received packets exceeds > > > all allocated descriptors (ixgbe_rxd * ixgbe_num_queues), the next new > > > incoming packets will be sometimes DMA'ed into the RAM incorrectly. > > > > > > Output from my tcpdump session: > > > > > > % tcpdump -i ix1 > > > ... > > > 15:36:54.970343 IP 10.0.0.2.discard > 12.0.0.160.2200: UDP, length 58 > > > 15:36:55.070357 IP 10.0.0.2.discard > 12.0.0.161.2200: UDP, length 58 > > > 15:36:55.170373 c7:49:54:a8:00:0c (oui Unknown) > 35:c5:66:d7:df:e8 > (oui > > > Unknown), ethertype Unknown (0xd53b), length 100: > > > 0x0000: 4d98 ed85 7537 3b6b 3b8f 7102 4b1c 2cd4 > M...u7;k;.q.K.,. > > > 0x0010: 41a8 2f3d 4faa fc8a a039 0fe2 5960 fad5 > A./=O....9..Y`.. > > > 0x0020: c8b0 964b b0e0 2213 6aa2 330c ef93 80a9 > ...K..".j.3..... > > > 0x0030: 6ac8 071b a9bd 0d51 ecca 94ba ac9c 873b > j......Q.......; > > > 0x0040: a83f aeb0 20f4 cfd9 d1fa 93f3 795c 7d20 > .?..........y\}. > > > 0x0050: 2993 ). > > > 15:36:55.270388 IP 10.0.0.2.discard > 12.0.0.163.2200: UDP, length 58 > > > ... > > > > > > For packets generating I am using Linux kernel packet generator. The > > > receive- > > > and send-interfaces are connected directly (without any hops in the > > > middle). > > > By the each new generated packet the destination-IP-address will be > > > incremented, so I can proof the correctness of received traffic. This > > > error > > > appears in both -STABLE and -CURRENT > > > > > > I guess it is not a software bug and I would like to check out whether > > > the controller is in order. > > > > > > Are there any test setups for 8259x controllers that I could use ? > > > > > > Thanks, > > > Alex > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 19:00:14 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AE2A106566C for ; Fri, 6 Aug 2010 19:00:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EE1CB8FC22 for ; Fri, 6 Aug 2010 19:00:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o76J0DsG059358 for ; Fri, 6 Aug 2010 19:00:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o76J0DGo059357; Fri, 6 Aug 2010 19:00:13 GMT (envelope-from gnats) Date: Fri, 6 Aug 2010 19:00:13 GMT Message-Id: <201008061900.o76J0DGo059357@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/77913: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 19:00:14 -0000 The following reply was made to PR kern/77913; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/77913: commit references a PR Date: Fri, 6 Aug 2010 18:57:22 +0000 (UTC) Author: bschmidt Date: Fri Aug 6 18:57:09 2010 New Revision: 210949 URL: http://svn.freebsd.org/changeset/base/210949 Log: MFC r182236,r182238,182250,182251: - Add recent ELSA additions to wi(4), plus make sure the list matches the driver for ELSA. - The APDL-325 is a Wireless LAN pcmcia adapter that sits inside some Billion Access Points. Fix wi(4) to recognise the adapter. - Remove opt_wi.h PR: kern/77913 Submitted by: Daan Vreeken [PA4DAN] Modified: stable/7/share/man/man4/wi.4 stable/7/sys/dev/pccard/pccarddevs stable/7/sys/dev/wi/if_wi_pccard.c stable/7/sys/modules/wi/Makefile Directory Properties: stable/7/share/man/man4/ (props changed) stable/7/sys/ (props changed) stable/7/sys/cddl/contrib/opensolaris/ (props changed) stable/7/sys/contrib/dev/acpica/ (props changed) stable/7/sys/contrib/pf/ (props changed) Modified: stable/7/share/man/man4/wi.4 ============================================================================== --- stable/7/share/man/man4/wi.4 Fri Aug 6 18:55:49 2010 (r210948) +++ stable/7/share/man/man4/wi.4 Fri Aug 6 18:57:09 2010 (r210949) @@ -189,6 +189,9 @@ Dlink DWL650 Prism-2.5 PCMCIA ELECOM Air@Hawk/LD-WL11/PCC PCMCIA ELSA MC-11 PCMCIA ELSA XI300 Prism-II PCMCIA +ELSA XI325 Prism-2.5 PCMCIA +ELSA APDL325 Prism-2.5 PCMCIA +ELSA XI330 Prism-3 PCMCIA ELSA XI800 Prism-II CF EMTAC A2424i Prism-II PCMCIA Ericsson Wireless LAN CARD C11 Spectrum24 PCMCIA Modified: stable/7/sys/dev/pccard/pccarddevs ============================================================================== --- stable/7/sys/dev/pccard/pccarddevs Fri Aug 6 18:55:49 2010 (r210948) +++ stable/7/sys/dev/pccard/pccarddevs Fri Aug 6 18:57:09 2010 (r210949) @@ -320,6 +320,7 @@ product ELSA MC2_IEEE 0x0001 AirLancer product ELSA XI300_IEEE 0x0002 XI300 Wireless LAN product ELSA XI800_IEEE 0x0004 XI800 CF Wireless LAN product ELSA XI325_IEEE 0x0005 XI325 Wireless LAN +product ELSA APDL325_IEEE 0x0006 ADPL325 Wireless LAN product ELSA XI330_IEEE 0x0010 XI330 Wireless LAN product ELSA WIFI_FLASH 0x0101 802.11b plus 128MB Flash Modified: stable/7/sys/dev/wi/if_wi_pccard.c ============================================================================== --- stable/7/sys/dev/wi/if_wi_pccard.c Fri Aug 6 18:55:49 2010 (r210948) +++ stable/7/sys/dev/wi/if_wi_pccard.c Fri Aug 6 18:57:09 2010 (r210949) @@ -41,8 +41,6 @@ #include __FBSDID("$FreeBSD$"); -#include "opt_wi.h" - #include #include #include @@ -126,6 +124,7 @@ static const struct pccard_product wi_pc PCMCIA_CARD(DLINK, DWL650H), PCMCIA_CARD(ELSA, XI300_IEEE), PCMCIA_CARD(ELSA, XI325_IEEE), + PCMCIA_CARD(ELSA, APDL325_IEEE), PCMCIA_CARD(ELSA, XI330_IEEE), PCMCIA_CARD(ELSA, XI800_IEEE), PCMCIA_CARD(ELSA, WIFI_FLASH), Modified: stable/7/sys/modules/wi/Makefile ============================================================================== --- stable/7/sys/modules/wi/Makefile Fri Aug 6 18:55:49 2010 (r210948) +++ stable/7/sys/modules/wi/Makefile Fri Aug 6 18:57:09 2010 (r210949) @@ -3,12 +3,7 @@ .PATH: ${.CURDIR}/../../dev/wi KMOD= if_wi -SRCS= opt_wi.h if_wi.c if_wi_pccard.c if_wi_pci.c \ +SRCS= if_wi.c if_wi_pccard.c if_wi_pci.c \ card_if.h device_if.h bus_if.h pci_if.h pccarddevs.h -.if !defined(KERNBUILDDIR) -opt_wi.h: - echo "#define WI_SYMBOL_FIRMWARE 1" > ${.TARGET} -.endif - .include _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 19:14:34 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4B441065679; Fri, 6 Aug 2010 19:14:34 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1938FC1C; Fri, 6 Aug 2010 19:14:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o76JEYBK078955; Fri, 6 Aug 2010 19:14:34 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o76JEYKW078951; Fri, 6 Aug 2010 19:14:34 GMT (envelope-from bschmidt) Date: Fri, 6 Aug 2010 19:14:34 GMT Message-Id: <201008061914.o76JEYKW078951@freefall.freebsd.org> To: Danovitsch@Vitsch.net, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/77913: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 19:14:34 -0000 Synopsis: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) State-Changed-From-To: patched->closed State-Changed-By: bschmidt State-Changed-When: Fri Aug 6 19:13:24 UTC 2010 State-Changed-Why: Patch is included head, stable/8 and stable/7, thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=77913 From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 20:13:14 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FE961065672 for ; Fri, 6 Aug 2010 20:13:14 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 19B8C8FC19 for ; Fri, 6 Aug 2010 20:13:13 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id o76Jx4T0071302 for ; Fri, 6 Aug 2010 12:59:08 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201008061959.o76Jx4T0071302@gw.catspoiler.org> Date: Fri, 6 Aug 2010 12:59:03 -0700 (PDT) From: Don Lewis To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: Subject: [ath] IBM 802.11B B/G 39T0073 card doesn't work in 8-STABLE but worked in 7-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 20:13:14 -0000 I upgraded my Thinkpad from 7-STABLE to 8-STABLE a few weeks ago and now my wireless card no longer works. It is recognized, but appears to be somewhat brain dead. # ifconfig ath0 ath0: flags=8802 metric 0 mtu 2290 ether 00:16:ce:00:ac:a7 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier # ifconfig ath0 up # ifconfig ath0 ath0: flags=8843 metric 0 mtu 2290 ether 00:16:ce:00:ac:a7 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier # ifconfig ath0 scan ifconfig: unable to get scan results # ifconfig ath0 list caps ifconfig: unable to get device capabilities: Invalid argument I turned on the ath and ath_hal kernel debug options and this is what shows up at boot: ath0: mem 0xc0200000-0xc020ffff irq 9 at device 2.0 on pci2 ath0: [ITHREAD] ar5212Attach: sc 0xc420c000 st 0x1 sh 0xe4553000 ar5212SetPowerMode: AWAKE -> AWAKE (set chip ) ar5212SetPowerMode: AWAKE -> AWAKE (set chip ) ar5212SetPowerMode: AWAKE -> AWAKE (set chip ) EEPROM protect 0x0 enableAniMIBCounters: Enable mib counters: OfdmPhyErrBase 0xbffe0c cckPhyErrBase 0xbfff38 ar5212Attach: return getchannels: cc 0 regDmn 0xf0 mode 0xffffff ecm getregstate: EEPROM cc 0 rd 0x10 getregstate: EEPROM rd 0x64 getchannels: !avail mode 0x182c (0x2) flags 0x2150 getchannels: !avail mode 0x182c (0x1) flags 0x140 getchannels: !avail mode 0x182c (0x40) flags 0x150 getchannels: !avail mode 0x182c (0x400) flags 0x8140 getchannels: !avail mode 0x182c (0x200) flags 0x4140 getchannels: !avail mode 0x182c (0x8000) flags 0x10480 getchannels: !avail mode 0x182c (0x20000) flags 0x20480 getchannels: !avail mode 0x182c (0x40000) flags 0x40480 getchannels: !avail mode 0x182c (0x10000) flags 0x10140 getchannels: !avail mode 0x182c (0x80000) flags 0x20140 getchannels: !avail mode 0x182c (0x100000) flags 0x40140 assignPrivateChannels: private[ 0] 2412/0xa0 -> channel 2412 assignPrivateChannels: private[ 1] 2417/0xa0 -> channel 2417 assignPrivateChannels: private[ 2] 2422/0xa0 -> channel 2422 assignPrivateChannels: private[ 3] 2427/0xa0 -> channel 2427 assignPrivateChannels: private[ 4] 2432/0xa0 -> channel 2432 assignPrivateChannels: private[ 5] 2437/0xa0 -> channel 2437 assignPrivateChannels: private[ 6] 2442/0xa0 -> channel 2442 assignPrivateChannels: private[ 7] 2447/0xa0 -> channel 2447 assignPrivateChannels: private[ 8] 2452/0xa0 -> channel 2452 assignPrivateChannels: private[ 9] 2457/0xa0 -> channel 2457 assignPrivateChannels: private[ 10] 2462/0xa0 -> channel 2462 assignPrivateChannels: 23 public, 11 private channels ath_hal_init_channels: cc 0 ath_getchannels: eeprom rd 100 cc 0 (mapped rd 100 cc 0) location I ecm ar5212GetRateTable: invalid mode 0x10000 ar5212GetRateTable: invalid mode 0x8000 ath_descdma_setup: rx DMA: 40 buffers 1 desc/buf ath_descdma_setup: rx DMA map: 0xe4563000 (3840) -> 0x111c000 (3840) ath_descdma_setup: tx DMA: 200 buffers 10 desc/buf ath_descdma_setup: tx DMA map: 0xe45c0000 (192000) -> 0x1180000 (192000) ath_descdma_setup: beacon DMA: 4 buffers 1 desc/buf ath_descdma_setup: beacon DMA map: 0xe45f0000 (384) -> 0x11af000 (384) ar5212SetupTxQueue: queue 9 ar5212SetupTxQueue: queue 8 ar5212SetupTxQueue: queue 0 ar5212SetupTxQueue: queue 1 ar5212SetupTxQueue: queue 2 ar5212SetupTxQueue: queue 3 ath0: AR5212 mac 5.9 RF2112 phy 4.3 Any thoughts on what's going wrong and how to fix it? From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 20:40:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AFF7106564A for ; Fri, 6 Aug 2010 20:40:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0BFED8FC08 for ; Fri, 6 Aug 2010 20:40:10 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o76Ke9aA097929; Fri, 6 Aug 2010 16:40:09 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008062040.o76Ke9aA097929@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Aug 2010 16:40:09 -0400 To: Don Lewis , freebsd-net@freebsd.org From: Mike Tancsa In-Reply-To: <201008061959.o76Jx4T0071302@gw.catspoiler.org> References: <201008061959.o76Jx4T0071302@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: [ath] IBM 802.11B B/G 39T0073 card doesn't work in 8-STABLE but worked in 7-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 20:40:11 -0000 At 03:59 PM 8/6/2010, Don Lewis wrote: ># ifconfig ath0 up ># ifconfig ath0 >ath0: flags=8843 metric 0 mtu 2290 > ether 00:16:ce:00:ac:a7 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier ># ifconfig ath0 scan Hi, I got caught in the same error. The wireless stuff in RELENG_8 is a bit different. You need to create a wlan interface on top of the ath driver. Take a look at wlan(4) ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 21:15:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19CEE106564A; Fri, 6 Aug 2010 21:15:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7DE978FC18; Fri, 6 Aug 2010 21:15:14 +0000 (UTC) Received: by wyj26 with SMTP id 26so10237321wyj.13 for ; Fri, 06 Aug 2010 14:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=SVo2PEuK4zcKagkro7c3IzGLp9oKkiGbpWs2fskDJHA=; b=tlTwbi0opybyEWvlyaBkQpQituil1qSFN3TSPvKIFsFWaJCJSaeNwPAZ873hyn5KUu 5WXP84H6F8xJvPalGa2CmapJMqJAUngv/j6g1PDcdsKyNQMuzqxR4w5qB7THeHlLwMO7 Mw2YFq4XsG8W3X4BCYvliSCx0IF8OuaYKAy1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=c1mb0LvZvdG+AtutcKm4sH3YjeS1YVRnh/UEKEhNGycpcDddKau9slT/Qkbz9KyzkQ HkZ4FID2moHG6aP/UNA63LeUBBGJHylgYzG2peFG5wJjFFc6IweT5QG/9jqmLyvuuOmG DO8xqcCZF2gJPxGwQeuR/tqgXwEyjPeyfYkOM= MIME-Version: 1.0 Received: by 10.227.7.212 with SMTP id e20mr10452147wbe.44.1281129313236; Fri, 06 Aug 2010 14:15:13 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Fri, 6 Aug 2010 14:15:13 -0700 (PDT) Date: Fri, 6 Aug 2010 14:15:13 -0700 Message-ID: From: Jack Vogel To: FreeBSD Net , FreeBSD stable , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Watchdog resets on 82575 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 21:15:15 -0000 If you have this adapter and have been getting watchdogs you need to pick up the small update I checked into HEAD today. When I added the SR-IOV support for the 82576 adapter I removed a call to set the MAC type in an early routine, thinking it was unnecessary, since a slightly later shared code init does the same thing. I also saw no problem when I did this on the 82576.... well, it did have a bad effect that I did not notice, the slightly later call, igb_setup_msix() did not have the mac set and this resulted in the 82575 creating more queues than it is really able to handle. So, bottom line, this is a critical fix for 82575: SVN rev 210968 Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Fri Aug 6 22:42:03 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA5561065670 for ; Fri, 6 Aug 2010 22:42:03 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id A3ADA8FC0A for ; Fri, 6 Aug 2010 22:42:03 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id o76MftVI071614; Fri, 6 Aug 2010 15:41:59 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201008062241.o76MftVI071614@gw.catspoiler.org> Date: Fri, 6 Aug 2010 15:41:55 -0700 (PDT) From: Don Lewis To: mike@sentex.net In-Reply-To: <201008062040.o76Ke9aA097929@lava.sentex.ca> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-net@FreeBSD.org Subject: Re: [ath] IBM 802.11B B/G 39T0073 card doesn't work in 8-STABLE but worked in 7-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 22:42:04 -0000 On 6 Aug, Mike Tancsa wrote: > At 03:59 PM 8/6/2010, Don Lewis wrote: >># ifconfig ath0 up >># ifconfig ath0 >>ath0: flags=8843 metric 0 mtu 2290 >> ether 00:16:ce:00:ac:a7 >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >># ifconfig ath0 scan > > Hi, > I got caught in the same error. The wireless stuff in > RELENG_8 is a bit different. You need to create a wlan interface on > top of the ath driver. Take a look at wlan(4) Thanks! I didn't expect to have to read /usr/src/UPDATING all the way back to early 2008 ... From owner-freebsd-net@FreeBSD.ORG Sat Aug 7 08:46:19 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCE16106566C; Sat, 7 Aug 2010 08:46:19 +0000 (UTC) (envelope-from bschmidt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B44838FC1B; Sat, 7 Aug 2010 08:46:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o778kJPo002693; Sat, 7 Aug 2010 08:46:19 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o778kJj7002689; Sat, 7 Aug 2010 08:46:19 GMT (envelope-from bschmidt) Date: Sat, 7 Aug 2010 08:46:19 GMT Message-Id: <201008070846.o778kJj7002689@freefall.freebsd.org> To: bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org, bschmidt@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: kern/110140: [ipw] ipw fails under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 08:46:19 -0000 Synopsis: [ipw] ipw fails under load Responsible-Changed-From-To: freebsd-net->bschmidt Responsible-Changed-By: bschmidt Responsible-Changed-When: Sat Aug 7 08:45:11 UTC 2010 Responsible-Changed-Why: Over to me. http://www.freebsd.org/cgi/query-pr.cgi?pr=110140 From owner-freebsd-net@FreeBSD.ORG Sat Aug 7 22:40:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A20510656D6 for ; Sat, 7 Aug 2010 22:40:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D7F518FC1B for ; Sat, 7 Aug 2010 22:40:23 +0000 (UTC) Received: (qmail 43907 invoked from network); 7 Aug 2010 21:10:54 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Aug 2010 21:10:54 -0000 Message-ID: <4C5DE0D5.7090802@freebsd.org> Date: Sun, 08 Aug 2010 00:40:21 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Seth Jeacopello References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Server sporadically sending unexpected RST to Client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 22:40:24 -0000 On 06.08.2010 17:26, Seth Jeacopello wrote: > Hello, > > We have recently upgraded some productions systems to 8.0-p2 > from 7.1-p5 and are having some sporadic issues with TCP connections that > were not occurring previously. I've looked your description in the email and syncache is neither the cause nor the source of the problem. It only shows the symptoms. In your case the likely problem is a very high connection rate and sockets in the time wait state. From your description it appears to be likely that the machine the connections are coming from has a very high connection rate towards this server. It seems to be reusing a particular source port to often or too early. You should check your tcpdumps for that. What OS and version is the sending system? -- Andre > The problem was first noticed while running slapd with clients coming in at > various times to make LDAP queries; at various points during the day we > would receive the follow message in the slapd log (along with the client > complaining because the connection was reset): > > daemon: accept(7) failed errno=53 (Software caused connection abort) > > > > > > We began digging into slapd, during which we were running tcpdump to catch > the traffic between the client and server. After a bit tracing through the > dumps, the following pattern emerged during the failure times: > > Client -> Server [SYN] > > Server -> Client [SYN, ACK] > > Client -> Server [ACK] > > Client -> Server [Request] > > Server -> Client [RST] > > Server -> Client [Response] > > Client -> Server [RST] > > > > > > Between the trace above and the accept error, it prompted the question as to > why slapd would be throwing an accept error and still be trying to respond > to data? It felt like a double trigger, but slapd doesn't appear to be > reusing anything, so our next steps lead us to either something in pf or in > the kernel as potentially causing the error. The first step was to remove > pf as a variable, so we disabled pf (pfctl -d) and found that the issue > continued. > > > > Eventually, we turned on net.inet.flowtable.debug and net.inet.tcp.log_debug > in order to capture some more data and that lead us to the following error: > > kernel: TCP: [10.174.80.233]:20949 to [10.174.80.242]:389 tcpflags > 0x10; tcp_input: Listen socket: Socket allocation failed due to limits > or memory shortage, sending RST > > > > > > The first thought was we were overflowing the listen queue but netstat -sp > tcp showed the listen queue overflows count was not increasing and the > system itself didn't have that many connections coming in at that time > (though there was quite a bit of activity from various clients). We also > verified that the CPU and memory usage was within a reasonable range > (nothing was being stressed and there was plenty of memory to go around. > For the sake of being complete, the server in question is a dual CPU (eight > cores total) Intel server with 12GB of memory). > > > > All of this prompted us to build a debug version of the kernel with some > additional logging and we eventually found that we were ultimately failing > in in_pcb.c, in_pcbconnect_setup we got EADDRINUSE returned after the > in_pcblookup_hash call. > > > > We've also noticed that net.tcp.syncache.count will go to -1 when this > failure occurs. > > > > Per a similar issue > (http://lists.freebsd.org/pipermail/freebsd-net/2010-May/025307.html) we > were lead to trying to turn off syncookies by setting > net.inet.tcp.syncookies to zero which has lead to the error not reappearing > (and syncache.count never goes back to -1), however, the connection failures > would still occur (shown from client logs and backed up by tcpdumps that > show the same pattern as above). This would seem to indicate that there is > a problem with syncache. > > > > Additionally, we've also found the following pattern while debugging the > kernel for the failed connection (note: syncookies is still disabled at this > point): > > kernel: Entering syncache_add > > kernel: Entering syncache_expand > > kernel: TCP: [10.174.50.35]:43667 to [10.174.80.242]:389 tcpflags > 0x18; syncache_expand: Just before syncache_socket() > > kernel: Entering syncache_socket > > kernel: Entering syncache_expand > > kernel: TCP: [10.174.50.35]:43667 to [10.174.80.242]:389 tcpflags 0x10; > syncache_expand: Spurious ACK, segment rejected (syncookies disabled) > > > > The above pattern appears to indicate that the PSH is coming in before the > final ACK in the handshake (somehow out of order); however, the tcpdumps > clearly show everything is coming across in order. > > > > Finally, we've also attempted to test with syncookies=1 and > syncookies_only=1, which results in the connection failures (as well as the > reappearance of the slapd accept error messages). > > > > Does anyone have any thoughts on this issue? > > > > > > > > # uname -a > > FreeBSD HA1 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #8: Mon Apr 19 16:31:20 > UTC 2010 > sethj@newcastle.greatbaysoftware.com:/usr/obj/usr/src/sys/KERNEL i386 > > > > # sysctl net.inet.tcp.syncache > > net.inet.tcp.syncache.rst_on_sock_fail: 1 > > net.inet.tcp.syncache.rexmtlimit: 3 > > net.inet.tcp.syncache.hashsize: 512 > > net.inet.tcp.syncache.count: -1 > > net.inet.tcp.syncache.cachelimit: 15360 > > net.inet.tcp.syncache.bucketlimit: 30 > > > > # netstat -Lan | grep 389 > > tcp4 0/0/128 *.389 > > > > # netstat -sp tcp > > tcp: > > 5596836 packets sent > > 2431990 data packets (3645983288 bytes) > > 33 data packets (31121 bytes) retransmitted > > 0 data packets unnecessarily retransmitted > > 0 resends initiated by MTU discovery > > 2498873 ack-only packets (48245 delayed) > > 0 URG only packets > > 0 window probe packets > > 588193 window update packets > > 77883 control packets > > 10770625 packets received > > 4611316 acks (for 3643955099 bytes) > > 54176 duplicate acks > > 0 acks for unsent data > > 6172078 packets (2931863382 bytes) received in-sequence > > 72 completely duplicate packets (10151 bytes) > > 46 old duplicate packets > > 0 packets with some dup. data (0 bytes duped) > > 4136 out-of-order packets (3650806 bytes) > > 0 packets (0 bytes) of data after window > > 0 window probes > > 486096 window update packets > > 153 packets received after close > > 0 discarded for bad checksums > > 0 discarded for bad header offset fields > > 0 discarded because packet too short > > 0 discarded due to memory problems > > 18353 connection requests > > 62559 connection accepts > > 0 bad connection attempts > > 0 listen queue overflows > > 1 ignored RSTs in the window > > 80905 connections established (including accepts) > > 80811 connections closed (including 21351 drops) > > 58462 connections updated cached RTT on close > > 58462 connections updated cached RTT variance on close > > 0 connections updated cached ssthresh on close > > 9 embryonic connections dropped > > 4523602 segments updated rtt (of 1677015 attempts) > > 11 retransmit timeouts > > 0 connections dropped by rexmit timeout > > 0 persist timeouts > > 0 connections dropped by persist timeout > > 0 Connections (fin_wait_2) dropped because of timeout > > 0 keepalive timeouts > > 0 keepalive probes sent > > 0 connections dropped by keepalive > > 207248 correct ACK header predictions > > 5223266 correct data packet header predictions > > 62537 syncache entries added > > 0 retransmitted > > 0 dupsyn > > 0 dropped > > 62559 completed > > 0 bucket overflow > > 0 cache overflow > > 0 reset > > 0 stale > > 2 aborted > > 0 badack > > 0 unreach > > 0 zone failures > > 17491 cookies sent > > 24 cookies received > > 6 SACK recovery episodes > > 21 segment rexmits in SACK recovery episodes > > 25132 byte rexmits in SACK recovery episodes > > 64 SACK options (SACK blocks) received > > 2627 SACK options (SACK blocks) sent > > 0 SACK scoreboard overflow > > 0 packets with ECN CE bit set > > 0 packets with ECN ECT(0) bit set > > 0 packets with ECN ECT(1) bit set > > 0 successful ECN handshakes > > 0 times ECN reduced the congestion window > > > > > > KERNCONF: > > > > # Inherit config (most stuff) -- this is slightly customized version... > > # inherits from GENERIC-cust (tweaked to disable the default scheduler) > > include PAE-cust > > > > # Name of this kernel > > ident KERNEL > > > > makeoptions NO_MODULES=yes > > #makeoptions MODULES_OVERRIDE=geom/geom_journal > > > > # Scheduler -- From /usr/src/sys/conf/NOTES: > > # > > # SCHED_ULE provides significant performance advantages over 4BSD on many > > # workloads on SMP machines. It supports cpu-affinity, per-cpu runqueues > > # and scheduler locks. It also has a stronger notion of interactivity > > # which leads to better responsiveness even on uniprocessor machines. This > > # will eventually become the default scheduler. > > # > > options SCHED_ULE > > > > > > # Note: we're compiling modules in statically since with PAE we don't want > to > > # load KLDs. See comments in pae(4) and PAE kernel conf file. > > > > # Hardware Monitoring / Management > > > > device ipmi > > > > # Storage > > > > options GEOM_JOURNAL > > > > # Firewall > > > > device pf #PF OpenBSD packet-filter firewall > > device pflog #logging support interface for PF > > # device pfsync #synchronization interface for PF > > > > options ALTQ > > > > options ALTQ_CBQ > > options ALTQ_RED > > options ALTQ_RIO > > options ALTQ_HFSC > > options ALTQ_CDNR > > options ALTQ_PRIQ > > > > options ALTQ_NOPCC # Required for SMP builds > > > > # Linux Emulation > > > > options COMPAT_LINUX > > options LINPROCFS > > options LINSYSFS > > > > # Screen saver > > > > # device green_saver > > > > ### Network perf tuning > > > > > > options ACCEPT_FILTER_HTTP > > # options ZERO_COPY_SOCKETS > > > > # See polling(4)) > > > > options DEVICE_POLLING > > options HZ=1000 > > > > # Avoid scrambled kernel messages during boot -- Trac #1458 > > options PRINTF_BUFR_SIZE=256 > > # End config > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >