From owner-freebsd-net@FreeBSD.ORG Sun Feb 21 00:03:23 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 E26EB106566C; Sun, 21 Feb 2010 00:03:23 +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 BB65B8FC13; Sun, 21 Feb 2010 00:03:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1L03N1W040192; Sun, 21 Feb 2010 00:03:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1L03NWO040188; Sun, 21 Feb 2010 00:03:23 GMT (envelope-from linimon) Date: Sun, 21 Feb 2010 00:03:23 GMT Message-Id: <201002210003.o1L03NWO040188@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/144148: [msk] Slow network performance and high system cpu load while transfering data 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, 21 Feb 2010 00:03:24 -0000 Synopsis: [msk] Slow network performance and high system cpu load while transfering data Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 21 00:03:02 UTC 2010 Responsible-Changed-Why: reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=144148 From owner-freebsd-net@FreeBSD.ORG Sun Feb 21 10:29:04 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 1F940106566C for ; Sun, 21 Feb 2010 10:29:04 +0000 (UTC) (envelope-from patrick.ale@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id A6DC28FC14 for ; Sun, 21 Feb 2010 10:29:03 +0000 (UTC) Received: by bwz8 with SMTP id 8so1067568bwz.3 for ; Sun, 21 Feb 2010 02:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=eXUawnp+ylUCjWHLmXihX+i5EFuNn4vaEGiw1Z/bZkI=; b=etNV7ghjwHfETMDAg3BLcEYKbRuC9mbdde6vqFEPT62Y/18ZbnttmZGuiDk6qOHi0F iE+IM79fwTfgEw5A6y3/wHxWRwIallsJBeLERyMYwopI1ppw6Iq+RMIZheT7neS/3c5L N0VHEgBNeDn4hekRmy+ebsF54Y0BHuQHRjS7c= 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=xn4Ap/9T2fjDBhWS8AJbmRd2e8qwBOlSv7l3IATGXq6yP0TRXSmPo73fITHkwCS/fs Iw4xvNva+26+zgvqAnO3JiD3fvu5I2HHs8thjz7C0UNfrmcNwcQqu4svUuiDwb8uKfrF aJCnxCIy0hkgpUgblCPUqUxl9pgkkghHf1xWM= MIME-Version: 1.0 Received: by 10.204.34.24 with SMTP id j24mr2401144bkd.147.1266748134967; Sun, 21 Feb 2010 02:28:54 -0800 (PST) In-Reply-To: <20100216183531.GD1394@michelle.cdnetworks.com> References: <8d158e1f1002160429m747efaf1h478b6b9cf00b96c@mail.gmail.com> <20100216183531.GD1394@michelle.cdnetworks.com> Date: Sun, 21 Feb 2010 11:28:54 +0100 Message-ID: <8d158e1f1002210228y3d46c146xe0fa0263f5c80c47@mail.gmail.com> From: Patrick Ale To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Attansic L1 Gigabit discovered on install but no link 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, 21 Feb 2010 10:29:04 -0000 Good morning! On Tue, Feb 16, 2010 at 7:35 PM, Pyun YongHyeon wrote: > I assume you're using age(4). > age(4) is one of driver that still does full re-initialization while > dhclient(8) is running, how about unplugging the UTP cable and > replug it while DHCP is in progress? Actually it is the 'ale' driver (kinda funny when you look at my last name ;-) ).. And yes, you are right. When during the instalation I provide a static IP address, the link comes up and I have TCP/IP connectivity. DHCP always fails with 'no link' errors. > > There are several variants of L1 so please show me the dmesg > output. This is a 'dmesg | grep ale' output when I configure a static IP address: ale0: port 0x3000-0x307f mem 0xf6000000-0xf603ffff irq 16 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. miibus0: on ale0 ale0: Ethernet address: 00:a0:d1:a5:b8:9a ale0: [FILTER] ale0: link state changed to UP So for now it is workable but I'd like to find out why DHCP is failing and if I can help out trying to figure out what is going on :) Thanks all for your time, Patrick From owner-freebsd-net@FreeBSD.ORG Sun Feb 21 10:35: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 E422810656B9 for ; Sun, 21 Feb 2010 10:35:51 +0000 (UTC) (envelope-from egorenar@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7202D8FC29 for ; Sun, 21 Feb 2010 10:35:51 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so356173eyd.9 for ; Sun, 21 Feb 2010 02:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zknncjQ8Lhvz6EIGyqWFOc41Cq5+Fao7UHm2RwnyxzA=; b=t38YCxqMgEkENJIWvtwSMEMQ8qFOdzvJ/acIiSKYa6yHycZ2lpgtfHUfsjSEujqtEX GMBdrhkUOIZtsoU5X+YHsrSSzsNfEYz3cgK3x9ndwH4r+VKH1RiAOtwXBDKMuTyLvXo+ kxVEZXPCL0J+oh9t6L0eDNC+u8ah8TF9LIyUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o+U9zrXcUrad9rAyrSaZ3pIQIyDziM7aoKY9MbRLptmK5ELt3lj4pNodPYVWcWjNzE Z9pDjxvOAHT584RV9q2A2klviTJJDEPItifYIo7aLOrF1lDqmjfXsWM9b8wxzhoSMkud XxN3gH4i4+FRJw6A+HTnQQnyu8t6+VYupLz0I= MIME-Version: 1.0 Received: by 10.213.109.131 with SMTP id j3mr7387604ebp.36.1266748541510; Sun, 21 Feb 2010 02:35:41 -0800 (PST) In-Reply-To: <4B6F2A44.3010205@errno.com> References: <2d3b7e441002060028i5b1fc665p92b10fa21d77284d@mail.gmail.com> <8F5F80D8-A262-49F4-B580-781A44D3190D@freebsd.org> <2d3b7e441002060658h49712201m464dac80208db369@mail.gmail.com> <4B6DE491.8010901@errno.com> <2d3b7e441002070041waa8f968le66328ebeb7b163d@mail.gmail.com> <4B6F2A44.3010205@errno.com> Date: Sun, 21 Feb 2010 11:35:41 +0100 Message-ID: <2d3b7e441002210235q5c6de2bvaedfa460fcb0766e@mail.gmail.com> From: Alexander Egorenkov To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: HT rate set in net80211 not changeable for STA 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, 21 Feb 2010 10:35:52 -0000 This MCS32 HT rate causes problems with AMRR. If the connection between a client and an AP is very good and the AP supports MCS32, the client keeps increasing the Tx rate upto MCS32 and then the problems begin because the client starts to send with MCS32. Alex. On Sun, Feb 7, 2010 at 10:01 PM, Sam Leffler wrote: > Alexander Egorenkov wrote: > > >> >> On Sat, Feb 6, 2010 at 10:52 PM, Sam Leffler > sam@errno.com>> wrote: >> >> The advertised rate set should be initially set according to the >> capabilities of the device. There were no devices > 2x2 when I >> wrote the code so MCS15 is the max. To support such devices you >> need to do more than just grow the rateset. >> >> >> But my device is a 2T2R device and supports MCS32 (HT duplicate mode). >> >> > MCS32 is special; as you indicate it forces duplicate signal on the upper > and lower channels in HT40. There is no support for MCS32 in net80211. > > Sam > > From owner-freebsd-net@FreeBSD.ORG Sun Feb 21 16:56: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 D0E811065676 for ; Sun, 21 Feb 2010 16:56:22 +0000 (UTC) (envelope-from marco.borsatino@poste.it) Received: from relay-pt1.poste.it (relay-pt1.poste.it [62.241.4.164]) by mx1.freebsd.org (Postfix) with ESMTP id 94B4C8FC19 for ; Sun, 21 Feb 2010 16:56:22 +0000 (UTC) Received: from poste.it (192.168.44.52) by relay-pt1.poste.it (8.5.121.01) id 4B8086110000C167 for freebsd-net@freebsd.org; Sun, 21 Feb 2010 17:35:50 +0100 Date: Sun, 21 Feb 2010 17:35:50 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "marco\.borsatino\@poste\.it" To: freebsd-net@freebsd.org X-XaM3-API-Version: 5.0(R1) X-SenderIP: 79.41.173.29 Subject: DNS and DHCP cooperation 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, 21 Feb 2010 16:56:22 -0000 Hi to all. Sorry for my bad english.=0AA big (for me) problem with DNS an= d DHCP.=0AFor auto-educational purposes, I'm trying to configure a little= network using VirtualBox.=0AThe situation is Ok for DNS, as I've correct= ly configured my only DNS server with 2 subnets, each with only 1 PC; all= the clients can access the other client and my virtual server.=0ALater, = I've successfully installed DHCP, both client and server.=0ABut when I tr= y to make the server programs (named and dhcpd) to cooperate, I get lost = in the documentation (I'm using different sources), and the situation col= lapses.=0AMy client, which has a new DHCP assigned address, correctly pin= gs the other virtual PC in the network, but when I ping this client from = my virtual server, I see that it doesn't recognise the correct address (s= till present in the zone file); it always tries to ping 212.48.8.140, whi= ch seems not to exist in the real world (or at least it seems not to be e= achable from the real PC) nor, clearly, in my virtual little network.=0AO= k, I've made a mistake, normal. In fact, I haven't undestood how the DHCP= server updates zone files in the DNS server both server programs are in = the same virtual PC).=0ASo I came back to static address for my client; b= oth clients still ping the other, but my DNS server still tries to ping t= his misterious (for me) address.=0AI've deinstalled the BIND from ports, = but nothing has changed.=0ASo, two questions:=0A- Where can I find a docu= ment that explains how to use jointly the two servers (starting from a ve= ry basic point of view) how to use DNS and DHCP? When I read the document= s I'v found on the Internet, they correctly start considering securities = issues, but, for me, for now, that's not important; first I'd like to see= them to work;=0A- what is the reason of the strange beaviour of my virtu= al DNS server? I've solved starting with a new virtual PC, but I'd like t= o understand.=0A=0AThank for your help.=0A=0AMarco From owner-freebsd-net@FreeBSD.ORG Sun Feb 21 22:02:21 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 A74D2106566C for ; Sun, 21 Feb 2010 22:02:21 +0000 (UTC) (envelope-from hyama99@gmail.com) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1048FC16 for ; Sun, 21 Feb 2010 22:02:20 +0000 (UTC) Received: by fxm7 with SMTP id 7so1725701fxm.14 for ; Sun, 21 Feb 2010 14:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=pDO52Toiz5A6nJbamzncarKZrHsqF3vHGFxoHAdFYfg=; b=CdIBeONWeFYaWCgS/I4A2djt9sW/Njas6ZNi0nI0K0v7+08SwTTEvNrZUeWbqHgD2C uiK8LPmBIRnx4gvSiSWkI6G5GJAKYq4KYtWGEmvK3U5St01D+fog+lLLitw/6tEdyqGx NaLiuImjXSsnOXeMqAkdMfLMmvjaFva02jdhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=s4ehplISlq3fQRqWmiYqLC99jaZh8VukijtJ+Ahj04vwufsDzuMVDW03NcV/Oi8Cum 3WhsxTkWtceDsfyGIsZZjyhelyCnMGn6T7zkyszns3DTcK3W0dZJX/as57lKjguxezRf ZjwcZnVrwSxDXiKsBJXCPUHNyiVn3zo4+Zh9U= MIME-Version: 1.0 Received: by 10.239.185.203 with SMTP id d11mr98551hbh.145.1266789731563; Sun, 21 Feb 2010 14:02:11 -0800 (PST) Date: Mon, 22 Feb 2010 07:02:11 +0900 Message-ID: <90dbee151002211402o52ed7cf6q352bd1ef339379bf@mail.gmail.com> From: Hideki Yamamoto To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: IPv6 multicast packet size 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, 21 Feb 2010 22:02:21 -0000 Hi, I have encountered IPv6 multicast problem. I cannot send UDP packet longer than Shortest MTU. It seems the bug of IPv6 multicast kernel. I used the same application from FreeBSD 4.11. On that old version, any problems happens. When I would like to change the platform of this application from 4.11 to 7.2 or later, I encountered this problem. Does anyone have any information about this problem? The followings are OS information I have tested, the result of Tshark command, and source code of test program. Best regards, Hideki Yamamoto -------------------------------------------------------------------------- OS information -------------------------------------------------------------------------- # sysctl -a |grep v6 net.inet.tcp.v6mssdflt: 1024 net.inet6.ip6.v6only: 1 # sysctl -a |grep mtu net.inet.tcp.path_mtu_discovery: 1 net.inet.sctp.pmtu_raise_time: 600 net.inet6.ip6.mcast_pmtu: 0 # uname -a FreeBSD tulip 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Fri Jan 15 05:25:24 JST 2010 root@tulip:/usr/obj/usr/src/sys/tulip8 i386 tulip# -------------------------------------------------------------------------- Tshark output that shows the packets are devided into two packtet when delivering 1400 byte lenghth packets. -------------------------------------------------------------------------- # ./udp -s 1400 -o & # tshark -VV -i fxp1 host ff3e::9800:600 |grep -v aaaaaaaaa Capturing on fxp1 Frame 1 (1294 bytes on wire, 1294 bytes captured) Arrival Time: Feb 21, 2010 17:35:08.560297000 [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 1294 bytes Capture Length: 1294 bytes [Frame is marked: False] [Protocols in frame: eth:ipv6:data] Ethernet II, Src: Intel_89:d6:d9 (00:d0:b7:89:d6:d9), Dst: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) Destination: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) Address: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: Intel_89:d6:d9 (00:d0:b7:89:d6:d9) Address: Intel_89:d6:d9 (00:d0:b7:89:d6:d9) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IPv6 (0x86dd) Internet Protocol Version 6 0110 .... = Version: 6 [0110 .... = This field makes the filter "ip.version == 6" possible: 6] .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000 .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 Payload length: 1240 Next header: IPv6 fragment (0x2c) Hop limit: 1 Source: 2001:2a0:806:206:2d0:b7ff:fe89:d6d9 (2001:2a0:806:206:2d0:b7ff:fe89:d6d9) Destination: ff3e::9800:600 (ff3e::9800:600) Fragmentation Header Next header: UDP (0x11) 0000 0000 0000 0... = Offset: 0 (0x0000) .... .... .... ...1 = More Fragment: Yes Identification: 0xc31d92fa Data (1232 bytes) 0000 5d 61 46 50 05 80 b0 d6 61 61 61 61 61 61 61 61 ]aFP....aaaaaaaa Data: 5D6146500580B0D661616161616161616161616161616161... [Length: 1232] Frame 2 (238 bytes on wire, 238 bytes captured) Arrival Time: Feb 21, 2010 17:35:08.560324000 [Time delta from previous captured frame: 0.000027000 seconds] [Time delta from previous displayed frame: 0.000027000 seconds] [Time since reference or first frame: 0.000027000 seconds] Frame Number: 2 Frame Length: 238 bytes Capture Length: 238 bytes [Frame is marked: False] [Protocols in frame: eth:ipv6:udp:data] Ethernet II, Src: Intel_89:d6:d9 (00:d0:b7:89:d6:d9), Dst: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) Destination: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) Address: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: Intel_89:d6:d9 (00:d0:b7:89:d6:d9) Address: Intel_89:d6:d9 (00:d0:b7:89:d6:d9) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IPv6 (0x86dd) ------ /********************************************************************** udp.c (modified for MC Send Support) ***********************************************************************/ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include // Modify send_addr to Multicast Address char *send_addr="ff3e::9800:600"; char *send_port="18000"; char *recv_addr="2001:99::1"; char *recv_port="16000"; int send_s; int only_out=0; int only_in=0; int out_packet_size; struct addrinfo *send_res; // Add for MC support char *out_if="fxp1"; main(ac,av) int ac; char **av; { int c; while ((c = getopt(ac, av, "s:oi")) != -1) { switch (c) { case 'o': only_out++; break; case 'i': only_in++; break; case 's': out_packet_size = atoi(optarg); break; default: Usage(); exit (1); } } if( only_in && only_out ){ Usage(); exit (1); } if( only_in == 0 ){ create_send_socket(); send_v6_udp(); exit; } recv_v6_udp(); } Usage() { printf("Usage: udpgw [-o][-i][-s output_packet_size]\n"); } create_send_socket() { struct addrinfo hints; int error; struct sockaddr_in6 *sin6;// Add for MC Support int ifindex;// Add for MC Support memset(&hints, 0, sizeof(hints)); hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; error = getaddrinfo(send_addr, send_port, &hints, &send_res); if (error != 0) errx(1, "%s", gai_strerror(error)); send_res->ai_family = AF_INET6; send_s = socket(send_res->ai_family, send_res->ai_socktype, send_res->ai_protocol); if (send_s < 0) err(1, "socket"); // Add for MC support sin6 = (struct sockaddr_in6 *)send_res->ai_addr; if(IN6_IS_ADDR_MULTICAST(&(sin6->sin6_addr))) { if ( (ifindex = if_nametoindex(out_if)) == 0 ){ err(1, "socket-MC"); } error = setsockopt(send_s, IPPROTO_IPV6, IPV6_MULTICAST_IF, &ifindex, sizeof(ifindex)); if (error < 0){ err(1, "socket-MC"); } } } send_v6_udp() { int len,cc,i; char buf[2000]; for( i=0; i<2000 ; i++ ){ buf[i]='a'; } if( 1501 > out_packet_size ){ cc = out_packet_size ; }else{ cc = 1500; } printf("Let's send %d length packet to %s\n",cc,send_addr); while(1){ len = sendto(send_s, buf, cc, 0, send_res->ai_addr, send_res->ai_addrlen); sleep(1); } } recv_v6_udp() { int recv_s; struct addrinfo hints, *res; int error; int len,cc,ccout; char buf[2000]; FILE *outfp=stdout; int fromlen; struct sockaddr_in6 from6; memset(&hints, 0, sizeof(hints)); hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; error = getaddrinfo(recv_addr, recv_port, &hints, &res); if (error != 0) errx(1, "%s", gai_strerror(error)); res->ai_family = AF_INET6; recv_s = socket(res->ai_family, res->ai_socktype, res->ai_protocol); if (recv_s < 0) err(1, "socket"); while(1){ cc = recvfrom(recv_s, (void *)buf, sizeof(buf), 0, (struct sockaddr *)&from6, &fromlen); if (cc < 0) { warn("recvfrom"); continue; } if ( only_in == 0 ){ len = sendto(send_s, buf, cc, 0, send_res->ai_addr, send_res->ai_addrlen); } else { if ((ccout = fwrite(buf, cc, 1, outfp)) < 1) close(recv_s); } } } ------------- From owner-freebsd-net@FreeBSD.ORG Sun Feb 21 22:46:41 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 754881065692; Sun, 21 Feb 2010 22:46:41 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4BA8FC0C; Sun, 21 Feb 2010 22:46:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1LMkfdZ065410; Sun, 21 Feb 2010 22:46:41 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1LMkfXa065406; Sun, 21 Feb 2010 22:46:41 GMT (envelope-from gavin) Date: Sun, 21 Feb 2010 22:46:41 GMT Message-Id: <201002212246.o1LMkfXa065406@freefall.freebsd.org> To: caleb_lyness@yahoo.com, gavin@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/85266: [xe] [patch] xe(4) driver does not recognise Xircom XE2000 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, 21 Feb 2010 22:46:41 -0000 Synopsis: [xe] [patch] xe(4) driver does not recognise Xircom XE2000 State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Sun Feb 21 22:41:47 UTC 2010 State-Changed-Why: This patch was committed to HEAD on April 9, 2004 - I think it can be closed now :) http://www.freebsd.org/cgi/query-pr.cgi?pr=85266 From owner-freebsd-net@FreeBSD.ORG Sun Feb 21 23:53: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 BA0951065676 for ; Sun, 21 Feb 2010 23:53:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f199.google.com (mail-yx0-f199.google.com [209.85.210.199]) by mx1.freebsd.org (Postfix) with ESMTP id 633D98FC14 for ; Sun, 21 Feb 2010 23:53:41 +0000 (UTC) Received: by yxe37 with SMTP id 37so2540560yxe.27 for ; Sun, 21 Feb 2010 15:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Od1LIJ8nUL8Op2w6MtsIK6MY7Iyz0cYkSZEOXK+nw4w=; b=rByMa3ig6fZAVhoq0MJ1Ua+sOTSvDSxa3FJryJAisXKh40EfKO2MqOkMdbu8qaufL8 ic+W1ywtNFOuxma3D77POxKB9gNjdzqS7BomOfr3k3iMZ6tbyMc74O2EEGKs5+z7Dw1x HY2/DTYD3HeYeu4KeFmuFGL2tnFcSxKhuOBPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=f75zp1d7OuybPw4Owp3/zYAjMTCMAq1K2QG5o1cTVqyjc7wAH10DyNv47aqvogC9XD IZtDEcxTCNFLHws3qPFTW7rrdoz8RNenqqKlEmJPBPaJDRiQexjSAcoZLoXn5+/tXDzK gkT5Yfi6t6b+FsE68syFTcaOrzqNodmBNcFME= Received: by 10.101.5.12 with SMTP id h12mr4556630ani.52.1266796416521; Sun, 21 Feb 2010 15:53:36 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 15sm2724268gxk.14.2010.02.21.15.53.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Feb 2010 15:53:35 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 21 Feb 2010 15:52:57 -0800 From: Pyun YongHyeon Date: Sun, 21 Feb 2010 15:52:57 -0800 To: Patrick Ale Message-ID: <20100221235257.GB1251@michelle.cdnetworks.com> References: <8d158e1f1002160429m747efaf1h478b6b9cf00b96c@mail.gmail.com> <20100216183531.GD1394@michelle.cdnetworks.com> <8d158e1f1002210228y3d46c146xe0fa0263f5c80c47@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d158e1f1002210228y3d46c146xe0fa0263f5c80c47@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Attansic L1 Gigabit discovered on install but no link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 23:53:41 -0000 On Sun, Feb 21, 2010 at 11:28:54AM +0100, Patrick Ale wrote: > Good morning! > > On Tue, Feb 16, 2010 at 7:35 PM, Pyun YongHyeon wrote: > > > I assume you're using age(4). > > age(4) is one of driver that still does full re-initialization while > > dhclient(8) is running, how about unplugging the UTP cable and > > replug it while DHCP is in progress? > > Actually it is the 'ale' driver (kinda funny when you look at my last > name ;-) ).. > And yes, you are right. When during the instalation I provide a static > IP address, the link comes up and I have TCP/IP connectivity. DHCP > always fails with 'no link' errors. > > > After you see the failure DHCP, unplug the UTP cable and wait 2-3 seconds and replug the UTP cable again. And execute "dhclient ale0", does it make any difference? > > There are several variants of L1 so please show me the dmesg > > output. > > This is a 'dmesg | grep ale' output when I configure a static IP address: > > ale0: port 0x3000-0x307f > mem 0xf6000000-0xf603ffff irq 16 at device 0.0 on pci2 > ale0: 960 Tx FIFO, 1024 Rx FIFO > ale0: Using 1 MSI messages. > ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > miibus0: on ale0 > ale0: Ethernet address: 00:a0:d1:a5:b8:9a > ale0: [FILTER] > ale0: link state changed to UP > It seems you've removed PHY driver related message here. Show me the output of "devinfo -rv | grep phy". Also show me the output of "pciconf -lcv". > > So for now it is workable but I'd like to find out why DHCP is failing > and if I can help out trying to figure out what is going on :) > Last time I tried ale(4) it worked as expected. I have no longer access to ale(4) hardware so it would be hard to fix that but I'll see what I can do. > Thanks all for your time, > > Patrick From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 02:02:56 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 BFF4E106566C; Mon, 22 Feb 2010 02:02:56 +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 B20F88FC14; Mon, 22 Feb 2010 02:02:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1M22uLY036404; Mon, 22 Feb 2010 02:02:56 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1M22ut8036400; Mon, 22 Feb 2010 02:02:56 GMT (envelope-from yongari) Date: Mon, 22 Feb 2010 02:02:56 GMT Message-Id: <201002220202.o1M22ut8036400@freefall.freebsd.org> To: zephyrus.271@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/144148: [msk] Slow network performance and high system cpu load while transfering data 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, 22 Feb 2010 02:02:56 -0000 Synopsis: [msk] Slow network performance and high system cpu load while transfering data State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Feb 22 02:01:24 UTC 2010 State-Changed-Why: I remember there are stability issues on 88E8072 but it's somewhat hard to fix that mainly because I don't have the hardware to narrow down the issue. It seems you have two issues here, low performance number and high CPU usage during transfers. I have no idea how high CPU usage comes from msk(4) even if msk(4) gives poor performance. Would you show me the output of "sysctl dev.msk.0.stats"? And send captured traffics on receiver side(not on host with msk(4)) with tcpdump and send it to me. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Feb 22 02:01:24 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=144148 From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 11:07: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 6C7F61065694 for ; Mon, 22 Feb 2010 11:07:03 +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 348588FC18 for ; Mon, 22 Feb 2010 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1MB73oR039775 for ; Mon, 22 Feb 2010 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1MB72Zd039771 for freebsd-net@FreeBSD.org; Mon, 22 Feb 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Feb 2010 11:07:02 GMT Message-Id: <201002221107.o1MB72Zd039771@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, 22 Feb 2010 11:07:03 -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/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 o kern/143788 net [iwi] wpa_supplicant(8) can't set privacy on iwi inter 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/143627 net [ieee80211] [panic] A bug in ht_send_action_ba_addba c 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/143046 net [mxge] [panic] panics since mxge(4) update 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 bin/142547 net wpa_supplicant(8) drops connection on key renegotiatio 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/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo 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/140970 net [bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 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/140684 net [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail 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 s kern/140597 net [request] implement Lost Retransmission Detection 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/139761 net [bce] bce driver on IBM HS22 [No PHY found on Child MI 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 kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom 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 p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex 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/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ 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/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts 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/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after 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/134658 net [bce] bce driver fails on PowerEdge m610 blade. 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/133328 net [bge] [panic] Kernel panics with Windows7 client 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 kern/132991 net [bge] if_bge low performance problem f 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/131162 net [ath] Atheros driver bugginess and kernel crashes 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/128884 net [msk] if_msk page fault while in kernel mode 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/127834 net [ixgbe] [patch] wrong error counting 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) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami 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 bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode 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/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov 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 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/122839 net [em] FreeBSD 7 multicast routing problem 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/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 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 sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch 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/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic 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 kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset 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 kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n 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/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac 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 s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m 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/92090 net [bge] bge0: watchdog timeout -- resetting 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 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/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 bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase 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/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 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/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 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 399 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 11:34:58 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 C5F9F106566C for ; Mon, 22 Feb 2010 11:34:58 +0000 (UTC) (envelope-from minotaur@crete.org.ua) Received: from relay.padonki.org.ua (relay.padonki.org.ua [193.0.227.26]) by mx1.freebsd.org (Postfix) with ESMTP id 803C28FC08 for ; Mon, 22 Feb 2010 11:34:58 +0000 (UTC) Received: from minotaur by relay.padonki.org.ua with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NjWYw-000PuU-5v; Mon, 22 Feb 2010 13:34:54 +0200 Date: Mon, 22 Feb 2010 13:34:54 +0200 From: Alexander Shikoff To: "Bjoern A. Zeeb" Message-ID: <20100222113454.GA99461@crete.org.ua> References: <20100217132632.GA756@crete.org.ua> <4B7D5D95.20007@gmx.com> <86bpflqr5b.fsf@zhuzha.ua1> <20100220112639.L27327@maildrop.int.zabbadoz.net> <20100220115850.T27327@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline In-Reply-To: <20100220115850.T27327@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Alexander Shikoff Cc: freebsd-net@freebsd.org, Mikolaj Golub Subject: Re: mpd has hung X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Shikoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 11:34:58 -0000 On Sat, Feb 20, 2010 at 12:04:35PM +0000, Bjoern A. Zeeb wrote: > On Sat, 20 Feb 2010, Bjoern A. Zeeb wrote: > > > On Fri, 19 Feb 2010, Mikolaj Golub wrote: > > > >> On Thu, 18 Feb 2010 17:32:37 +0200 Nikos Vassiliadis wrote: > >> > >>> On 2/17/2010 3:26 PM, Alexander Shikoff wrote: > >>>> Hello All, > >>>> > >>>> I have mpd 5.3 running on 8.0-RC1 as PPPoE server (now only 5 clients). > >>>> Today mpd process hung and I cannot kill it with -9 signal, and I cannot > >>>> access it's console via telnet. > >>>> > >>>> State of process in `top` output is STOP: > >>>> 73551 root 2 44 0 29588K 5692K STOP 6 0:32 0.00% mpd5 > >>>> > >>>> # procstat -kk 73551 > >>>> PID TID COMM TDNAME KSTACK > >>>> 73551 100233 mpd5 - mi_switch+0x16f > >>>> sleepq_wait+0x42 _cv_wait+0x111 flowtable_flush+0x51 if_detach+0x2f2 > >>>> ng_iface_shutdown+0x1e ng_rmnode+0x167 ng_apply_item+0xef7 > >>>> ng_snd_item+0x2ce ngc_send+0x1d2 sosend_generic+0x3f6 kern_sendit+0x13d > >>>> sendit+0xdc sendto+0x4d syscall+0x1da Xfast_syscall+0xe1 > >>>> 73551 100502 mpd5 - mi_switch+0x16f > >>>> thread_suspend_switch+0xc6 thread_single+0x1b6 exit1+0x72 sigexit+0x7c > >>>> postsig+0x306 ast+0x279 doreti_ast+0x1f > >>>> > >>>> Is there a way to stop a process without rebooting a whole system? > >>>> Thanks in advance! > >>>> > >>>> P.S. I'm ready for experiments with it before tonight, but I cannot > >>>> force system to crash in order to get crash dump right now. > >>>> > >>> > >>> It's probably too late now, but are you sure that nobody pressed > >>> CTLR-Z while in the mpd console??? > >>> > >>> CTLR-Z will send SIGSTOP to the process and the process will > >>> stop. While stopped, all processing stops(including receiving > >>> SIGKILL, you cannot kill it, and the signals are queued). You > >>> have to send SIGCONT for the process to continue. > >> > >> We were discussing this problem with Alexander in another > >> (Russian/Ukrainian > >> speaking) maillist. And it looks like the problem is the following. > >> > >> mpd5 thread was detaching ng interface and when doing flowtable_flush() it > >> slept in cv_wait waiting for flowclean_cycles variable to be updated. It > >> should have been awaken by flowcleaner thread but this thread got stuck in > >> endless loop, supposedly in flowtable_clean_vnet()/flowtable_free_stale(), > >> I > >> think because of inconsistent state of some lists (iface?) due to if_detach > >> being in progress. > > > > I have patches that are out for review. > > I am not sure if they apply cleanly as they are broken out of the tail > side of a larger patchset. > > If you are not using VIMAGEs you could ignore the ones I marked with (*). > > http://people.freebsd.org/~bz/20100216-10-ft-cv.diff > http://people.freebsd.org/~bz/20100216-11-ft-debugging.diff > http://people.freebsd.org/~bz/20100216-12-ft-cleanup.diff (*) > http://people.freebsd.org/~bz/20100216-13-ft-ll-cleanup.diff > http://people.freebsd.org/~bz/20100216-18-ft-free.diff (*) > > If you are still seeing the hang and have DDB support in your kernel, > then break into the debugger and save the complete output of > ddb> ps > before rebooting. I cannot make tests right now because of that box in production. I need some time to remove all traffic from it. -- MINO-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 16:06: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 DD8AC10656A6; Mon, 22 Feb 2010 16:06:07 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B42A98FC0A; Mon, 22 Feb 2010 16:06:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1MG677k001080; Mon, 22 Feb 2010 16:06:07 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1MG67wF001076; Mon, 22 Feb 2010 16:06:07 GMT (envelope-from remko) Date: Mon, 22 Feb 2010 16:06:07 GMT Message-Id: <201002221606.o1MG67wF001076@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: misc/144206: Marvell Yukon NIC not working under FreeBSD 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, 22 Feb 2010 16:06:08 -0000 Synopsis: Marvell Yukon NIC not working under FreeBSD Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Feb 22 16:05:20 UTC 2010 Responsible-Changed-Why: Reassign to network http://www.freebsd.org/cgi/query-pr.cgi?pr=144206 From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 17:15: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 36D651065679; Mon, 22 Feb 2010 17:15:07 +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 0C09E8FC18; Mon, 22 Feb 2010 17:15:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1MHF6MK062281; Mon, 22 Feb 2010 17:15:06 GMT (envelope-from bschmidt@freefall.freebsd.org) Received: (from bschmidt@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1MHF694062277; Mon, 22 Feb 2010 17:15:06 GMT (envelope-from bschmidt) Date: Mon, 22 Feb 2010 17:15:06 GMT Message-Id: <201002221715.o1MHF694062277@freefall.freebsd.org> To: sweetpea-freebsd@tentacle.net, bschmidt@FreeBSD.org, freebsd-net@FreeBSD.org From: bschmidt@FreeBSD.org Cc: Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation 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, 22 Feb 2010 17:15:07 -0000 Synopsis: wpa_supplicant(8) drops connection on key renegotiation State-Changed-From-To: open->closed State-Changed-By: bschmidt State-Changed-When: Mon Feb 22 17:13:53 UTC 2010 State-Changed-Why: A fix has been commited and MFCed as r204215. http://www.freebsd.org/cgi/query-pr.cgi?pr=142547 From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 17:20: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 9820D106566B for ; Mon, 22 Feb 2010 17:20:03 +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 6D0AB8FC08 for ; Mon, 22 Feb 2010 17:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1MHK35Z062370 for ; Mon, 22 Feb 2010 17:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1MHK3P9062369; Mon, 22 Feb 2010 17:20:03 GMT (envelope-from gnats) Date: Mon, 22 Feb 2010 17:20:03 GMT Message-Id: <201002221720.o1MHK3P9062369@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: bin/142547: 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: Mon, 22 Feb 2010 17:20:03 -0000 The following reply was made to PR bin/142547; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/142547: commit references a PR Date: Mon, 22 Feb 2010 17:11:02 +0000 (UTC) Author: bschmidt Date: Mon Feb 22 17:10:47 2010 New Revision: 204215 URL: http://svn.freebsd.org/changeset/base/204215 Log: MFC r203673: Ensure that tkip_mixing_phase1() is called after a rekeying event when using plain s/w crypto. PR: bin/142547 Approved by: rpaulo (mentor) Modified: stable/8/sys/net80211/ieee80211_crypto_tkip.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/xen/xenpci/ (props changed) stable/8/sys/netinet/ (props changed) Modified: stable/8/sys/net80211/ieee80211_crypto_tkip.c ============================================================================== --- stable/8/sys/net80211/ieee80211_crypto_tkip.c Mon Feb 22 17:03:45 2010 (r204214) +++ stable/8/sys/net80211/ieee80211_crypto_tkip.c Mon Feb 22 17:10:47 2010 (r204215) @@ -144,6 +144,7 @@ tkip_setkey(struct ieee80211_key *k) return 0; } k->wk_keytsc = 1; /* TSC starts at 1 */ + ctx->rx_phase1_done = 0; return 1; } _______________________________________________ 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 Mon Feb 22 17:51:30 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 787E5106568B for ; Mon, 22 Feb 2010 17:51:30 +0000 (UTC) (envelope-from patrick.ale@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 075AB8FC12 for ; Mon, 22 Feb 2010 17:51:29 +0000 (UTC) Received: by bwz8 with SMTP id 8so1970299bwz.3 for ; Mon, 22 Feb 2010 09:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sLsLEJJrv8rdk5muy3cv/fMkknlsDJ8oirmuOdPbGgU=; b=mMGBSd8hLwiueMmWmTs4+ADwLTOXhYwIdQBnQuFVj+5fPN+cR/vrw1x2A5t5F17Zg6 9+s9RKWxK2v0oy9+vXXt11eyEyQcV0ZBNDQ/OOPsipNdG/9EGdUf9ObWI723U7IQLHDP c6Z/xjbdsWBve8KE5+j7UqLjvWGdZ3xC7M5XA= 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=feqd9/AGn/UC0oFIX2rYSSYEVdWuECAxk5CR2Ayj9h+iXtNia7JwtcB3CfuAiX2+qH /aPtaMzX9+Y+ANgjDGSen+Y86UwCgfxptTweCQh3M7sqhEz4Wh4hUCfAg01Mjc23giW5 P+RB1sdccBPEkUYE8o/eKbW+rZ8ZIRLKemiFE= MIME-Version: 1.0 Received: by 10.204.8.141 with SMTP id h13mr2181254bkh.92.1266861079224; Mon, 22 Feb 2010 09:51:19 -0800 (PST) In-Reply-To: <20100221235257.GB1251@michelle.cdnetworks.com> References: <8d158e1f1002160429m747efaf1h478b6b9cf00b96c@mail.gmail.com> <20100216183531.GD1394@michelle.cdnetworks.com> <8d158e1f1002210228y3d46c146xe0fa0263f5c80c47@mail.gmail.com> <20100221235257.GB1251@michelle.cdnetworks.com> Date: Mon, 22 Feb 2010 18:51:19 +0100 Message-ID: <8d158e1f1002220951g30214c92xb6d00cb2a8ae39c2@mail.gmail.com> From: Patrick Ale To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Attansic L1 Gigabit discovered on install but no link 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, 22 Feb 2010 17:51:30 -0000 On Mon, Feb 22, 2010 at 12:52 AM, Pyun YongHyeon wrote: > On Sun, Feb 21, 2010 at 11:28:54AM +0100, Patrick Ale wrote: >> Good morning! > > After you see the failure DHCP, unplug the UTP cable and wait 2-3 > seconds and replug the UTP cable again. And execute "dhclient ale0", > does it make any difference? Hi, Yes that works. Even better, I think it is fixed for me, I can't explain how though. During the installation and after the installation, a 'dhclient ale0' would throw 'no link' errors, when I yank the cable and put it back in and run 'dhclient ale0' as you suggested, it works. Now for the fun: I changed 'if_ale0="inet 192.168.1.2 "..etc etc. to "if_ale0="dhcp" in /etc/rc.conf, the link comes up normally after a reboot, without yanking cables etc. > It seems you've removed PHY driver related message here. > Show me the output of "devinfo -rv | grep phy". Also show me the > output of "pciconf -lcv". I am sending this email from Solaris now as I am still fighting to find a decent console email client (trying mutt and struggling). If you are still interested in the output, knowing my problem is solved, let me know and I will gladly provide you with the information. > > Last time I tried ale(4) it worked as expected. I have no longer > access to ale(4) hardware so it would be hard to fix that but I'll > see what I can do. It is working as expected for me now too, as I said, I am a bit puzzled but happy. I see my Intel Wireless is supported too so if you still want to have a look I could give you a login on my laptop over wireless so you can bring the interface up and down, I don't have any secret data here anyway and I doubt you're interested in Dutch music ;-) > I have to say, I am really impressed by the support you people give and gave me so far, thank you very much and I hope my knowledge about FreeBSD and it's internals soon will be sufficient to return the favor to the community. Patrick From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 18:00: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 7244B1065672 for ; Mon, 22 Feb 2010 18:00:22 +0000 (UTC) (envelope-from backup.efnet@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 00D3C8FC19 for ; Mon, 22 Feb 2010 18:00:20 +0000 (UTC) Received: by ewy3 with SMTP id 3so2669581ewy.13 for ; Mon, 22 Feb 2010 10:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=LwLgMoiIHohHUGAih9HQOg9Dtd9HPK+Mv9Py5wUHZd4=; b=nXiSb234raJ1oIZ3kkErJnSOpLEZq5Pwa6ELEQqZ/rOnMUYoWR/EbmYUzqqrRZP2qP dv4ReCKlVgN4BUKAwr04zOFzR9j3vmOTas/xteJ8PvwkLzpIST7FifjdfogXCU2srUHz EkCXk89LXAqA7JFZhQJ5O0OJtz+NFEENzNdc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=rChxlkVmm5gHUf2tXyGIXS/yqbnb42y3jUbRhrjU20xdl6E0uOtJjFRvavCS1In5E/ FIgjqcyRpalXo76D05YXm7vzOYI3EVBYf0RWxPu5RxM2goirHozkX8yXaDc0n7P062dD itKVWBrAK8Y/zo2kZ+VKTWKVcGXL5WJPwFqzk= Received: by 10.213.97.4 with SMTP id j4mr4596221ebn.9.1266860145033; Mon, 22 Feb 2010 09:35:45 -0800 (PST) Received: from ?0.0.0.0? (110100100.wikipotica.info [72.55.137.202]) by mx.google.com with ESMTPS id 23sm2769587eya.35.2010.02.22.09.35.42 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 09:35:44 -0800 (PST) Message-ID: <4B82B24C.1080801@gmail.com> Date: Mon, 22 Feb 2010 17:35:24 +0100 From: Backup User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100220 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <201002221715.o1MHF694062277@freefall.freebsd.org> In-Reply-To: <201002221715.o1MHF694062277@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation 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, 22 Feb 2010 18:00:22 -0000 On 02/22/10 18:15, bschmidt@FreeBSD.org wrote: > Synopsis: wpa_supplicant(8) drops connection on key renegotiation > > State-Changed-From-To: open->closed > State-Changed-By: bschmidt > State-Changed-When: Mon Feb 22 17:13:53 UTC 2010 > State-Changed-Why: > A fix has been commited and MFCed as r204215. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=142547 > _______________________________________________ > 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" > Silly question here. But will this patch be applied with portsnap fetch && update? Or will i have to path the kernel manually? -- In a world without walls and fences, who needs windows and gates. From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 18: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 5ABFE106566B for ; Mon, 22 Feb 2010 18:06:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 254258FC0A for ; Mon, 22 Feb 2010 18:06:49 +0000 (UTC) Received: by pwj7 with SMTP id 7so3384087pwj.13 for ; Mon, 22 Feb 2010 10:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=tF/v9n0VQKiINyg3/2QRUF5GlcVv/5lde1i7SO7a6ls=; b=p0lK5Cmq/m0i2TWArRhvpq9Ebe/zPysJdNFbjmSFisojxJbRBt+BDGbL1AjmkR4Jlb 71y1w2EJFSLQFqSMicwEaBuWm86mgKTQc21b8J/amgDvUGCBxgUZtVp5LrnMSEwTI2Nq 5PDXEoXFBiI9KwnjVLsCqGTQ4T4MtvKtXHHv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fgGZQ99aBKy9jbz55XDSr8M5dq97+73H7mfWTEEx1dQ2iOkuSOkN4ACHmUNgpfwEeK 8MyWAC6xY1FzCUYu4Q2xnbLoyK9pf+MB1lsSMMI3TBugim37OFuNvm8wpMt/x8vvqLmz A2R/HWUK/DjA71Tjti/1KPpcKLHLdW7PVZ++E= Received: by 10.114.188.5 with SMTP id l5mr6668553waf.188.1266862001716; Mon, 22 Feb 2010 10:06:41 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm155647pzk.8.2010.02.22.10.06.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 10:06:41 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 22 Feb 2010 10:06:04 -0800 From: Pyun YongHyeon Date: Mon, 22 Feb 2010 10:06:04 -0800 To: Patrick Ale Message-ID: <20100222180604.GD1251@michelle.cdnetworks.com> References: <8d158e1f1002160429m747efaf1h478b6b9cf00b96c@mail.gmail.com> <20100216183531.GD1394@michelle.cdnetworks.com> <8d158e1f1002210228y3d46c146xe0fa0263f5c80c47@mail.gmail.com> <20100221235257.GB1251@michelle.cdnetworks.com> <8d158e1f1002220951g30214c92xb6d00cb2a8ae39c2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d158e1f1002220951g30214c92xb6d00cb2a8ae39c2@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Attansic L1 Gigabit discovered on install but no link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:06:50 -0000 On Mon, Feb 22, 2010 at 06:51:19PM +0100, Patrick Ale wrote: > On Mon, Feb 22, 2010 at 12:52 AM, Pyun YongHyeon wrote: > > On Sun, Feb 21, 2010 at 11:28:54AM +0100, Patrick Ale wrote: > >> Good morning! > > > > After you see the failure DHCP, unplug the UTP cable and wait 2-3 > > seconds and replug the UTP cable again. And execute "dhclient ale0", > > does it make any difference? > > Hi, > > Yes that works. Even better, I think it is fixed for me, I can't > explain how though. > During the installation and after the installation, a 'dhclient ale0' > would throw 'no link' errors, when I yank the cable and put it back in > and run 'dhclient ale0' as you suggested, it works. > This indicates there is a problem for link state change detection. > Now for the fun: I changed 'if_ale0="inet 192.168.1.2 "..etc etc. to > "if_ale0="dhcp" in /etc/rc.conf, the link comes up normally after a > reboot, without yanking cables etc. > > > It seems you've removed PHY driver related message here. > > Show me the output of "devinfo -rv | grep phy". Also show me the > > output of "pciconf -lcv". > > I am sending this email from Solaris now as I am still fighting to > find a decent console email client (trying mutt and struggling). > If you are still interested in the output, knowing my problem is > solved, let me know and I will gladly provide you with the > information. > I'm still interested in seeing the output of "devinfo -rv | grep phy". > > > > Last time I tried ale(4) it worked as expected. I have no longer > > access to ale(4) hardware so it would be hard to fix that but I'll > > see what I can do. > > It is working as expected for me now too, as I said, I am a bit > puzzled but happy. > I see my Intel Wireless is supported too so if you still want to have > a look I could give you a login on my laptop over wireless so you can > bring the interface up and down, I don't have any secret data here > anyway and I doubt you're interested in Dutch music ;-) > > > > I have to say, I am really impressed by the support you people give > and gave me so far, thank you very much and I hope my knowledge about > FreeBSD and it's internals soon will be sufficient to return the favor > to the community. > > > Patrick From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 18:26:33 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 4C69B1065676 for ; Mon, 22 Feb 2010 18:26:33 +0000 (UTC) (envelope-from kirk.davis@epsb.ca) Received: from OWA01.EDU.epsb.ca (owa01.epsb.ca [198.161.119.28]) by mx1.freebsd.org (Postfix) with ESMTP id 205EB8FC18 for ; Mon, 22 Feb 2010 18:26:31 +0000 (UTC) Received: from Exchange26.EDU.epsb.ca ([10.0.5.123]) by OWA01.EDU.epsb.ca with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 11:14:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Feb 2010 11:14:30 -0700 Message-ID: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel em0: watchdog timeout Thread-Index: Acqz6uDQemyiHIXATCepvFLjkzXMRw== From: "Kirk Davis" To: X-OriginalArrivalTime: 22 Feb 2010 18:14:30.0840 (UTC) FILETIME=[E0C7F380:01CAB3EA] Cc: Kirk Davis Subject: Intel em0: watchdog timeout 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, 22 Feb 2010 18:26:33 -0000 Hi, I have a FreeBSD server running Quagga as a BGP router. It has a number of interfaces in it both bce and em. The most heavily used interfaces are starting to give me watchdog timeout errors just in the last week. We normally sustain about 300Mb/s on both of these interfaces but in the last week this now up to 380Mb/s. This is a Intel Pro/1000 PT dual interface PCI-E card. There is two of them in the server. The server is a Dell 2950 Searching the mailing list and checking on google has not turned up much. Since this is our main router it is difficult to test with. I have seen one message that suggests trying to set hw.em.rxd=3D1024 and hw.em.txd=3D1024 in loader.conf and another that suggested turning off but none this has not made any difference. The odd thing is that this just started. This box has been up and running fine for a while. The only thing different on our network had been an increase in the bandwidth. Any idea where I go from here to trouble shoot this? # uname -a FreeBSD inet-gw.epsb.ca 7.1-STABLE FreeBSD 7.1-STABLE #3: Mon Mar 23 16:08:53 MDT 2009 root@inet-gw-test.epsb.ca:/usr/obj/usr/src/sys/DELL2950 amd64 # tail /var/log/messages Feb 19 12:26:04 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 12:26:04 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:07 inet-gw kernel: em0: link state changed to UP Feb 19 12:26:08 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:10 inet-gw kernel: em0: link state changed to UP Feb 19 14:44:20 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 14:44:20 inet-gw kernel: em0: link state changed to DOWN Feb 19 14:44:23 inet-gw kernel: em0: link state changed to UP Feb 19 15:05:03 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:05:03 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:05:05 inet-gw kernel: em2: link state changed to UP Feb 19 15:07:39 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:07:39 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:07:42 inet-gw kernel: em2: link state changed to UP # from /var/run/dmesg.boot em0: port 0xdce0-0xdcff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 on pci8 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:a6:ae:94 em2: port 0xcce0-0xccff mem 0xde3e0000-0xde3fffff,0xde3c0000-0xde3dffff irq 16 at device 0.0 on pci10 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:15:17:a6:af:d6 # pciconf -lv em0@pci0:8:0:0: class=3D0x020000 card=3D0x135e8086 chip=3D0x105e8086 = rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/1000 PT' class =3D network subclass =3D ethernet em2@pci0:10:0:0: class=3D0x020000 card=3D0x135e8086 = chip=3D0x105e8086 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/1000 PT' class =3D network subclass =3D ethernet # netstat -bdhI em2 2 input (em2) output packets errs bytes packets errs bytes colls drops 65K 0 72M 51K 0 9.4M 0 0=20 69K 0 78M 52K 0 8.5M 0 0=20 76K 0 88M 55K 0 11M 0 0=20 74K 0 85M 54K 0 10M 0 0=20 78K 0 91M 56K 0 9.0M 0 0=20 75K 0 86M 54K 0 8.7M 0 0=20 74K 0 85M 54K 0 9.2M 0 0=20 75K 0 86M 56K 0 10M 0 0=20 78K 0 88M 55K 0 12M 0 0=20 78K 0 90M 58K 0 12M 0 0=20 76K 0 87M 54K 0 10M 0 0=20 79K 0 91M 56K 0 10M 0 0=20 ---- Kirk ------------------------------------------------------------------------ -------- Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools One Kingsway Ave.=20 Edmonton, Alberta, Canada T5H 4G9 From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 18:43:19 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 592611065672 for ; Mon, 22 Feb 2010 18:43:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id BEE508FC08 for ; Mon, 22 Feb 2010 18:43:18 +0000 (UTC) Received: by ewy3 with SMTP id 3so2716348ewy.13 for ; Mon, 22 Feb 2010 10:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YPK8GzkbL8lyj8Hfs7MARnEZlXeRICqnZvEEikkdtBs=; b=exRO5AEzut3BwYa7KeJoIdY/J0Sg2KWDzmwoQCLc1Kg0Zn9NqlDt0vGga6dhEuL6V8 jiFxFkQ3IfbqsYaLnVPnTU2TiAMGB1cWCQOvRX1Dzc/GtVtnl5RLYX5YXlAZadEgPioB 8voWZwuO9kUao/qdSA70O7ABdgj9XtyPXUDI4= 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=rcb505fHW/BxhYAf+4zsLxy35rNoKV79vupHcAIbCuhSEvbR4FvSvMHLyOYzwpTTEh lOQzQec7sDMyXl4LWj3L6cQxwX7YzNrp8t1aVzX1XQtbGTAkQNalgC7KhwgT8ZM8x8s1 XDrHex7lLnFHbUOyJfUUhii+laEsONo+QWO2c= MIME-Version: 1.0 Received: by 10.216.159.6 with SMTP id r6mr896475wek.67.1266864191455; Mon, 22 Feb 2010 10:43:11 -0800 (PST) In-Reply-To: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> Date: Mon, 22 Feb 2010 10:43:11 -0800 Message-ID: <2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> From: Jack Vogel To: Kirk Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Intel em0: watchdog timeout 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, 22 Feb 2010 18:43:19 -0000 With the increased load you might be running out of mbufs more easily, would suggest you increase the mbuf pool. This is an old old driver now, you might consider going to something a bit more recent. Jack On Mon, Feb 22, 2010 at 10:14 AM, Kirk Davis wrote: > Hi, > I have a FreeBSD server running Quagga as a BGP router. It has > a number of interfaces in it both bce and em. The most heavily used > interfaces are starting to give me watchdog timeout errors just in the > last week. We normally sustain about 300Mb/s on both of these > interfaces but in the last week this now up to 380Mb/s. > > This is a Intel Pro/1000 PT dual interface PCI-E card. There is > two of them in the server. The server is a Dell 2950 > > Searching the mailing list and checking on google has not turned > up much. Since this is our main router it is difficult to test with. I > have seen one message that suggests trying to set hw.em.rxd=1024 and > hw.em.txd=1024 in loader.conf and another that suggested turning off > but none this has not made any difference. > > The odd thing is that this just started. This box has been up > and running fine for a while. The only thing different on our network > had been an increase in the bandwidth. > > Any idea where I go from here to trouble shoot this? > > # uname -a > FreeBSD inet-gw.epsb.ca 7.1-STABLE FreeBSD 7.1-STABLE #3: Mon Mar 23 > 16:08:53 MDT 2009 > root@inet-gw-test.epsb.ca:/usr/obj/usr/src/sys/DELL2950 amd64 > > # tail /var/log/messages > Feb 19 12:26:04 inet-gw kernel: em0: watchdog timeout -- resetting > Feb 19 12:26:04 inet-gw kernel: em0: link state changed to DOWN > Feb 19 12:26:07 inet-gw kernel: em0: link state changed to UP > Feb 19 12:26:08 inet-gw kernel: em0: link state changed to DOWN > Feb 19 12:26:10 inet-gw kernel: em0: link state changed to UP > Feb 19 14:44:20 inet-gw kernel: em0: watchdog timeout -- resetting > Feb 19 14:44:20 inet-gw kernel: em0: link state changed to DOWN > Feb 19 14:44:23 inet-gw kernel: em0: link state changed to UP > Feb 19 15:05:03 inet-gw kernel: em2: watchdog timeout -- resetting > Feb 19 15:05:03 inet-gw kernel: em2: link state changed to DOWN > Feb 19 15:05:05 inet-gw kernel: em2: link state changed to UP > Feb 19 15:07:39 inet-gw kernel: em2: watchdog timeout -- resetting > Feb 19 15:07:39 inet-gw kernel: em2: link state changed to DOWN > Feb 19 15:07:42 inet-gw kernel: em2: link state changed to UP > > # from /var/run/dmesg.boot > em0: port 0xdce0-0xdcff mem > 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 on pci8 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:a6:ae:94 > em2: port 0xcce0-0xccff mem > 0xde3e0000-0xde3fffff,0xde3c0000-0xde3dffff irq 16 at device 0.0 on > pci10 > em2: Using MSI interrupt > em2: [FILTER] > em2: Ethernet address: 00:15:17:a6:af:d6 > > # pciconf -lv > em0@pci0:8:0:0: class=0x020000 card=0x135e8086 chip=0x105e8086 rev=0x06 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 PT' > class = network > subclass = ethernet > em2@pci0:10:0:0: class=0x020000 card=0x135e8086 chip=0x105e8086 > rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 PT' > class = network > subclass = ethernet > > # netstat -bdhI em2 2 > input (em2) output > packets errs bytes packets errs bytes colls drops > 65K 0 72M 51K 0 9.4M 0 0 > 69K 0 78M 52K 0 8.5M 0 0 > 76K 0 88M 55K 0 11M 0 0 > 74K 0 85M 54K 0 10M 0 0 > 78K 0 91M 56K 0 9.0M 0 0 > 75K 0 86M 54K 0 8.7M 0 0 > 74K 0 85M 54K 0 9.2M 0 0 > 75K 0 86M 56K 0 10M 0 0 > 78K 0 88M 55K 0 12M 0 0 > 78K 0 90M 58K 0 12M 0 0 > 76K 0 87M 54K 0 10M 0 0 > 79K 0 91M 56K 0 10M 0 0 > > > ---- Kirk > ------------------------------------------------------------------------ > -------- > Kirk Davis > Senior Network Analyst, ITS > Edmonton Public Schools > One Kingsway Ave. > Edmonton, Alberta, Canada > T5H 4G9 > > _______________________________________________ > 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 Mon Feb 22 18:49: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 63102106566C for ; Mon, 22 Feb 2010 18:49:14 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mx.techwires.net (mx.techwires.net [IPv6:2001:4d88:100f:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id EEE168FC22 for ; Mon, 22 Feb 2010 18:49:13 +0000 (UTC) Received: from maja.lab.techwires.net (p54B4D6B2.dip.t-dialin.net [84.180.214.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bschmidt) by mx.techwires.net (Postfix) with ESMTPSA id C845518224; Mon, 22 Feb 2010 19:49:12 +0100 (CET) Received: from maja.lab.techwires.net (localhost [127.0.0.1]) by maja.lab.techwires.net (8.14.4/8.14.4) with ESMTP id o1MInBVG002761; Mon, 22 Feb 2010 19:49:11 +0100 (CET) (envelope-from bschmidt@techwires.net) Received: (from bschmidt@localhost) by maja.lab.techwires.net (8.14.4/8.14.4/Submit) id o1MInBRk002760; Mon, 22 Feb 2010 19:49:11 +0100 (CET) (envelope-from bschmidt@techwires.net) X-Authentication-Warning: maja.lab.techwires.net: bschmidt set sender to bschmidt@techwires.net using -f From: Bernhard Schmidt To: freebsd-net@freebsd.org Date: Mon, 22 Feb 2010 19:49:10 +0100 User-Agent: KMail/1.12.4 (FreeBSD/9.0-CURRENT; KDE/4.3.5; amd64; ; ) References: <201002221715.o1MHF694062277@freefall.freebsd.org> <4B82B24C.1080801@gmail.com> In-Reply-To: <4B82B24C.1080801@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002221949.10873.bschmidt@techwires.net> Cc: Backup Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation 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, 22 Feb 2010 18:49:14 -0000 On Monday 22 February 2010 17:35:24 Backup wrote: > Silly question here. But will this patch be applied with portsnap fetch > && update? Or will i have to path the kernel manually? portsnap? you mean freebsd-update? No, it won't. You have to fetch/build your kernel manually for now. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 18:55:13 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 D44F21065693 for ; Mon, 22 Feb 2010 18:55:13 +0000 (UTC) (envelope-from kirk.davis@epsb.ca) Received: from Exchange22.EDU.epsb.ca (exchange22.epsb.ca [198.161.119.187]) by mx1.freebsd.org (Postfix) with ESMTP id A637C8FC13 for ; Mon, 22 Feb 2010 18:55:13 +0000 (UTC) Received: from Exchange26.EDU.epsb.ca ([10.0.5.123]) by Exchange22.EDU.epsb.ca with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 11:55:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Feb 2010 11:55:12 -0700 Message-ID: <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> In-Reply-To: <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel em0: watchdog timeout Thread-Index: Acqz7uQgZVgK+/BsTqaHP+sOdidp/QAAEA/A References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> From: "Kirk Davis" To: "Jack Vogel" , X-OriginalArrivalTime: 22 Feb 2010 18:55:12.0594 (UTC) FILETIME=[902E0B20:01CAB3F0] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Intel em0: watchdog timeout 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, 22 Feb 2010 18:55:13 -0000 I have a backup server sitting here that I am going to load 7.3-RC1 onto and test with it. It is the exact duplicate hardware so that should help with the upgraded driver. Does it make sence to go to 8.0? =20 Here is the mbuf usage on this server. I'm nore sure exactly how to read this but it seem to looks OK. # netstat -m 8181/5904/14085 mbufs in use (current/cache/total) 7159/3471/10630/25600 mbuf clusters in use (current/cache/total/max) 7159/3465 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 16363K/8834K/25197K 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/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines =20 ---- Kirk =20 ________________________________ From: Jack Vogel [mailto:jfvogel@gmail.com]=20 Sent: Monday, February 22, 2010 11:43 AM To: Kirk Davis Cc: freebsd-net@freebsd.org Subject: [SPAM:#] Re: Intel em0: watchdog timeout With the increased load you might be running out of mbufs more easily, would suggest you increase the mbuf pool. This is an old old driver now, you might consider going to something a bit more recent.=20 =20 Jack On Mon, Feb 22, 2010 at 10:14 AM, Kirk Davis wrote: Hi, I have a FreeBSD server running Quagga as a BGP router. It has a number of interfaces in it both bce and em. The most heavily used interfaces are starting to give me watchdog timeout errors just in the last week. We normally sustain about 300Mb/s on both of these interfaces but in the last week this now up to 380Mb/s. =09 This is a Intel Pro/1000 PT dual interface PCI-E card. There is two of them in the server. The server is a Dell 2950 =09 Searching the mailing list and checking on google has not turned up much. Since this is our main router it is difficult to test with. I have seen one message that suggests trying to set hw.em.rxd=3D1024 and hw.em.txd=3D1024 in loader.conf and another that suggested turning off but none this has not made any difference. =09 The odd thing is that this just started. This box has been up and running fine for a while. The only thing different on our network had been an increase in the bandwidth. =09 Any idea where I go from here to trouble shoot this? =09 # uname -a FreeBSD inet-gw.epsb.ca 7.1-STABLE FreeBSD 7.1-STABLE #3: Mon Mar 23 16:08:53 MDT 2009 root@inet-gw-test.epsb.ca:/usr/obj/usr/src/sys/DELL2950 amd64 =09 # tail /var/log/messages Feb 19 12:26:04 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 12:26:04 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:07 inet-gw kernel: em0: link state changed to UP Feb 19 12:26:08 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:10 inet-gw kernel: em0: link state changed to UP Feb 19 14:44:20 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 14:44:20 inet-gw kernel: em0: link state changed to DOWN Feb 19 14:44:23 inet-gw kernel: em0: link state changed to UP Feb 19 15:05:03 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:05:03 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:05:05 inet-gw kernel: em2: link state changed to UP Feb 19 15:07:39 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:07:39 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:07:42 inet-gw kernel: em2: link state changed to UP =09 # from /var/run/dmesg.boot em0: port 0xdce0-0xdcff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 on pci8 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:a6:ae:94 em2: port 0xcce0-0xccff mem 0xde3e0000-0xde3fffff,0xde3c0000-0xde3dffff irq 16 at device 0.0 on pci10 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:15:17:a6:af:d6 =09 # pciconf -lv em0@pci0:8:0:0: class=3D0x020000 card=3D0x135e8086 chip=3D0x105e8086 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/1000 PT' class =3D network subclass =3D ethernet em2@pci0:10:0:0: class=3D0x020000 card=3D0x135e8086 chip=3D0x105e8086 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/1000 PT' class =3D network subclass =3D ethernet =09 # netstat -bdhI em2 2 input (em2) output packets errs bytes packets errs bytes colls drops 65K 0 72M 51K 0 9.4M 0 0 69K 0 78M 52K 0 8.5M 0 0 76K 0 88M 55K 0 11M 0 0 74K 0 85M 54K 0 10M 0 0 78K 0 91M 56K 0 9.0M 0 0 75K 0 86M 54K 0 8.7M 0 0 74K 0 85M 54K 0 9.2M 0 0 75K 0 86M 56K 0 10M 0 0 78K 0 88M 55K 0 12M 0 0 78K 0 90M 58K 0 12M 0 0 76K 0 87M 54K 0 10M 0 0 79K 0 91M 56K 0 10M 0 0 =09 =09 ---- Kirk =09 ------------------------------------------------------------------------ -------- Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools One Kingsway Ave. Edmonton, Alberta, Canada T5H 4G9 =09 _______________________________________________ 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" =09 From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 19:13:46 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 4ED25106568B for ; Mon, 22 Feb 2010 19:13:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id A71738FC19 for ; Mon, 22 Feb 2010 19:13:45 +0000 (UTC) Received: by ewy3 with SMTP id 3so2748850ewy.13 for ; Mon, 22 Feb 2010 11:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=B/j9VHIdn/F6p6fhTLITQUgE5nOE04ON0/WfA8v8D2o=; b=BtRPOQerdpVpcU/8+34wHODJ3nuCsDnAJLIKyeJXOssXouBMCzOipTZ6oAIkDli3tQ 8RDIXzrvFsHtoOFoLJAEnYu4ySlDI5A48/7pmZUocG7qWMFpNQiFOMUshl1qXOHTgNPe 22Pyi4bUyIW5+x0/a6gUaXs+/JNWTP/bwZBx8= 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=C1DRhhcbacCKFWpp7ybmdoJZatrONNlD6SVYEP8SfS2CTSx9SgvxapgDTbGiGOxoyX 0vR8NAE3jnmo6fc9VMVNs717gF/E2Rc4TaItT9po6mkHLjuMJgncJk8YJEnAPrnqR9m2 aeqOGOKDaHbi9cpSZ2e4+xQUDRJPiHn4BerME= MIME-Version: 1.0 Received: by 10.216.180.202 with SMTP id j52mr1472215wem.214.1266866017856; Mon, 22 Feb 2010 11:13:37 -0800 (PST) In-Reply-To: <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> Date: Mon, 22 Feb 2010 11:13:37 -0800 Message-ID: <2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> From: Jack Vogel To: Kirk Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Intel em0: watchdog timeout 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, 22 Feb 2010 19:13:46 -0000 Try `sysctl dev.em.0.stats=1` and em.2, you're right though, doesn't look like any system mbuf failures. 7.2 seems to be a stable base OS and driver, 8 is better in some respects, but has not been without its reported problems. I leave the choice to you. Without more data I am not sure what is causing the watchdog. Jack On Mon, Feb 22, 2010 at 10:55 AM, Kirk Davis wrote: > I have a backup server sitting here that I am going to load 7.3-RC1 onto > and test with it. It is the exact duplicate hardware so that should help > with the upgraded driver. Does it make sence to go to 8.0? > > Here is the mbuf usage on this server. I'm nore sure exactly how to read > this but it seem to looks OK. > # netstat -m > 8181/5904/14085 mbufs in use (current/cache/total) > 7159/3471/10630/25600 mbuf clusters in use (current/cache/total/max) > 7159/3465 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/104/104/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 16363K/8834K/25197K 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/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > ---- Kirk > > > ------------------------------ > *From:* Jack Vogel [mailto:jfvogel@gmail.com] > *Sent:* Monday, February 22, 2010 11:43 AM > *To:* Kirk Davis > *Cc:* freebsd-net@freebsd.org > *Subject:* [SPAM:#] Re: Intel em0: watchdog timeout > > With the increased load you might be running out of mbufs more easily, > would suggest you increase the mbuf pool. > > This is an old old driver now, you might consider going to something a > bit more recent. > > Jack > > > On Mon, Feb 22, 2010 at 10:14 AM, Kirk Davis wrote: > >> Hi, >> I have a FreeBSD server running Quagga as a BGP router. It has >> a number of interfaces in it both bce and em. The most heavily used >> interfaces are starting to give me watchdog timeout errors just in the >> last week. We normally sustain about 300Mb/s on both of these >> interfaces but in the last week this now up to 380Mb/s. >> >> This is a Intel Pro/1000 PT dual interface PCI-E card. There is >> two of them in the server. The server is a Dell 2950 >> >> Searching the mailing list and checking on google has not turned >> up much. Since this is our main router it is difficult to test with. I >> have seen one message that suggests trying to set hw.em.rxd=1024 and >> hw.em.txd=1024 in loader.conf and another that suggested turning off >> but none this has not made any difference. >> >> The odd thing is that this just started. This box has been up >> and running fine for a while. The only thing different on our network >> had been an increase in the bandwidth. >> >> Any idea where I go from here to trouble shoot this? >> >> # uname -a >> FreeBSD inet-gw.epsb.ca 7.1-STABLE FreeBSD 7.1-STABLE #3: Mon Mar 23 >> 16:08:53 MDT 2009 >> root@inet-gw-test.epsb.ca:/usr/obj/usr/src/sys/DELL2950 amd64 >> >> # tail /var/log/messages >> Feb 19 12:26:04 inet-gw kernel: em0: watchdog timeout -- resetting >> Feb 19 12:26:04 inet-gw kernel: em0: link state changed to DOWN >> Feb 19 12:26:07 inet-gw kernel: em0: link state changed to UP >> Feb 19 12:26:08 inet-gw kernel: em0: link state changed to DOWN >> Feb 19 12:26:10 inet-gw kernel: em0: link state changed to UP >> Feb 19 14:44:20 inet-gw kernel: em0: watchdog timeout -- resetting >> Feb 19 14:44:20 inet-gw kernel: em0: link state changed to DOWN >> Feb 19 14:44:23 inet-gw kernel: em0: link state changed to UP >> Feb 19 15:05:03 inet-gw kernel: em2: watchdog timeout -- resetting >> Feb 19 15:05:03 inet-gw kernel: em2: link state changed to DOWN >> Feb 19 15:05:05 inet-gw kernel: em2: link state changed to UP >> Feb 19 15:07:39 inet-gw kernel: em2: watchdog timeout -- resetting >> Feb 19 15:07:39 inet-gw kernel: em2: link state changed to DOWN >> Feb 19 15:07:42 inet-gw kernel: em2: link state changed to UP >> >> # from /var/run/dmesg.boot >> em0: port 0xdce0-0xdcff mem >> 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 on pci8 >> em0: Using MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:15:17:a6:ae:94 >> em2: port 0xcce0-0xccff mem >> 0xde3e0000-0xde3fffff,0xde3c0000-0xde3dffff irq 16 at device 0.0 on >> pci10 >> em2: Using MSI interrupt >> em2: [FILTER] >> em2: Ethernet address: 00:15:17:a6:af:d6 >> >> # pciconf -lv >> em0@pci0:8:0:0: class=0x020000 card=0x135e8086 chip=0x105e8086 rev=0x06 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'PRO/1000 PT' >> class = network >> subclass = ethernet >> em2@pci0:10:0:0: class=0x020000 card=0x135e8086 chip=0x105e8086 >> rev=0x06 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'PRO/1000 PT' >> class = network >> subclass = ethernet >> >> # netstat -bdhI em2 2 >> input (em2) output >> packets errs bytes packets errs bytes colls drops >> 65K 0 72M 51K 0 9.4M 0 0 >> 69K 0 78M 52K 0 8.5M 0 0 >> 76K 0 88M 55K 0 11M 0 0 >> 74K 0 85M 54K 0 10M 0 0 >> 78K 0 91M 56K 0 9.0M 0 0 >> 75K 0 86M 54K 0 8.7M 0 0 >> 74K 0 85M 54K 0 9.2M 0 0 >> 75K 0 86M 56K 0 10M 0 0 >> 78K 0 88M 55K 0 12M 0 0 >> 78K 0 90M 58K 0 12M 0 0 >> 76K 0 87M 54K 0 10M 0 0 >> 79K 0 91M 56K 0 10M 0 0 >> >> >> ---- Kirk >> ------------------------------------------------------------------------ >> -------- >> Kirk Davis >> Senior Network Analyst, ITS >> Edmonton Public Schools >> One Kingsway Ave. >> Edmonton, Alberta, Canada >> T5H 4G9 >> >> _______________________________________________ >> 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 Mon Feb 22 19:34: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 C473F106566C for ; Mon, 22 Feb 2010 19:34:10 +0000 (UTC) (envelope-from backup.efnet@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5339C8FC15 for ; Mon, 22 Feb 2010 19:34:09 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so776350eye.3 for ; Mon, 22 Feb 2010 11:34:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4LljIjsWafvFLxJLPpz8plqhDys0C3aFTud6v2JuNBU=; b=iCxEt6wEkvu8bP7PWbQalpvfI9pHeOgo1/tjtjZboAOnPOyAa5w4q9VYlzM9u9P44/ lxY04raoLDMpNLyzANEKTwv5Oo2gMBrimfyaKfzqhyxTcIUQ84Ra8BodIejaNbRLqzXZ +Ab5lRnodpjGwjj/oAlulPfG1kiXX7IHtWlVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=s/Um4iaDgYnNW31yfVCT57Y96BJwfc0Tsz1Ky1KUDh/E2FjtzXd7Bf2gJUFGaWBh0u JoTBOfDwO4SfcXuzWVFTgaAHuy3gEgMfbKxORqteC5CUJZQaA5ejBoNi0deJSBldk8py XK9aQ/RPlvqvCMTtiMZ6ovCEuIEru+QrbX0fs= Received: by 10.213.68.13 with SMTP id t13mr1532141ebi.62.1266867243277; Mon, 22 Feb 2010 11:34:03 -0800 (PST) Received: from ?0.0.0.0? (110100100.wikipotica.info [72.55.137.202]) by mx.google.com with ESMTPS id 15sm2672940ewy.8.2010.02.22.11.34.00 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 11:34:02 -0800 (PST) Message-ID: <4B82CE13.4010304@gmail.com> Date: Mon, 22 Feb 2010 19:33:55 +0100 From: Backup User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100220 Thunderbird/3.0.1 MIME-Version: 1.0 To: Bernhard Schmidt References: <201002221715.o1MHF694062277@freefall.freebsd.org> <4B82B24C.1080801@gmail.com> <201002221949.10873.bschmidt@techwires.net> In-Reply-To: <201002221949.10873.bschmidt@techwires.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation 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, 22 Feb 2010 19:34:10 -0000 On 02/22/10 19:49, Bernhard Schmidt wrote: > On Monday 22 February 2010 17:35:24 Backup wrote: > >> Silly question here. But will this patch be applied with portsnap fetch >> && update? Or will i have to path the kernel manually? >> > portsnap? you mean freebsd-update? No, it won't. You have to fetch/build your > kernel manually for now. > > Alright, thanks for the reply :) -- In a world without walls and fences, who needs windows and gates. From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 20:46:35 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 158241065672 for ; Mon, 22 Feb 2010 20:46:35 +0000 (UTC) (envelope-from kirk.davis@epsb.ca) Received: from Exchange22.EDU.epsb.ca (exchange22.epsb.ca [198.161.119.187]) by mx1.freebsd.org (Postfix) with ESMTP id DD95E8FC19 for ; Mon, 22 Feb 2010 20:46:34 +0000 (UTC) Received: from Exchange26.EDU.epsb.ca ([10.0.5.123]) by Exchange22.EDU.epsb.ca with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 13:46:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Feb 2010 13:46:33 -0700 Message-ID: <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> In-Reply-To: <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel em0: watchdog timeout Thread-Index: Acqz8ySKb3Qr2EGzQK+F8V0QX/sW1wAC8zXg References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> From: "Kirk Davis" To: "Jack Vogel" X-OriginalArrivalTime: 22 Feb 2010 20:46:33.0712 (UTC) FILETIME=[1E6FBF00:01CAB400] Cc: freebsd-net@freebsd.org Subject: Re: Intel em0: watchdog timeout 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, 22 Feb 2010 20:46:35 -0000 From: Jack Vogel [mailto:jfvogel@gmail.com]=20 =09 Try `sysctl dev.em.0.stats=3D1` and em.2, you're right though, doesn't look like any system mbuf failures. Does this need to be done in loader.conf? It doesn't seem to take from the command line. # sysctl dev.em.2.stats=3D1 =20 dev.em.2.stats: -1 -> -1 # sysctl dev.em.2.stats dev.em.2.stats: -1 =20 =09 7.2 seems to be a stable base OS and driver, 8 is better in some respects, but has not been without its reported problems. I leave the choice to you. =09 Without more data I am not sure what is causing the watchdog. Yes, I am having trouble tracking it down. I up'ed the mbufs to 65536 just to see if it made any difference but it is still happening. ############ SET NMBCLUSTERS TO 65536 ########################## Feb 22 12:45:21 inet-gw kernel: em0: watchdog timeout -- resetting Feb 22 12:45:21 inet-gw kernel: em0: link state changed to DOWN Feb 22 12:45:25 inet-gw kernel: em0: link state changed to UP Feb 22 12:45:25 inet-gw kernel: em0: link state changed to DOWN Feb 22 12:45:28 inet-gw kernel: em0: link state changed to UP Feb 22 12:45:29 inet-gw kernel: em0: link state changed to DOWN Feb 22 12:45:31 inet-gw kernel: em0: link state changed to UP # netstat -m 8183/6037/14220 mbufs in use (current/cache/total) 7160/3598/10758/65536 mbuf clusters in use (current/cache/total/max) 7160/3592 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 16365K/9121K/25487K 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/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines I guess I will have to build up the new server with 7.3 on it and see if the newer driver makes any difference. =09 ---- Kirk =09 =09 =09 On Mon, Feb 22, 2010 at 10:55 AM, Kirk Davis wrote: =09 I have a backup server sitting here that I am going to load 7.3-RC1 onto and test with it. It is the exact duplicate hardware so that should help with the upgraded driver. Does it make sence to go to 8.0? =20 Here is the mbuf usage on this server. I'm nore sure exactly how to read this but it seem to looks OK. # netstat -m 8181/5904/14085 mbufs in use (current/cache/total) 7159/3471/10630/25600 mbuf clusters in use (current/cache/total/max) 7159/3465 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 16363K/8834K/25197K 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/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines =09 =20 ---- Kirk =20 ________________________________ From: Jack Vogel [mailto:jfvogel@gmail.com]=20 Sent: Monday, February 22, 2010 11:43 AM To: Kirk Davis Cc: freebsd-net@freebsd.org Subject: [SPAM:#] Re: Intel em0: watchdog timeout =09 =09 With the increased load you might be running out of mbufs more easily, would suggest you increase the mbuf pool. =09 This is an old old driver now, you might consider going to something a bit more recent.=20 =20 Jack =09 =09 =09 On Mon, Feb 22, 2010 at 10:14 AM, Kirk Davis wrote: =09 Hi, I have a FreeBSD server running Quagga as a BGP router. It has a number of interfaces in it both bce and em. The most heavily used interfaces are starting to give me watchdog timeout errors just in the last week. We normally sustain about 300Mb/s on both of these interfaces but in the last week this now up to 380Mb/s. =09 This is a Intel Pro/1000 PT dual interface PCI-E card. There is two of them in the server. The server is a Dell 2950 =09 Searching the mailing list and checking on google has not turned up much. Since this is our main router it is difficult to test with. I have seen one message that suggests trying to set hw.em.rxd=3D1024 and hw.em.txd=3D1024 in loader.conf and another that suggested turning off but none this has not made any difference. =09 The odd thing is that this just started. This box has been up and running fine for a while. The only thing different on our network had been an increase in the bandwidth. =09 Any idea where I go from here to trouble shoot this? =09 # uname -a FreeBSD inet-gw.epsb.ca 7.1-STABLE FreeBSD 7.1-STABLE #3: Mon Mar 23 16:08:53 MDT 2009 =09 root@inet-gw-test.epsb.ca:/usr/obj/usr/src/sys/DELL2950 amd64 =09 # tail /var/log/messages Feb 19 12:26:04 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 12:26:04 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:07 inet-gw kernel: em0: link state changed to UP Feb 19 12:26:08 inet-gw kernel: em0: link state changed to DOWN Feb 19 12:26:10 inet-gw kernel: em0: link state changed to UP Feb 19 14:44:20 inet-gw kernel: em0: watchdog timeout -- resetting Feb 19 14:44:20 inet-gw kernel: em0: link state changed to DOWN Feb 19 14:44:23 inet-gw kernel: em0: link state changed to UP Feb 19 15:05:03 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:05:03 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:05:05 inet-gw kernel: em2: link state changed to UP Feb 19 15:07:39 inet-gw kernel: em2: watchdog timeout -- resetting Feb 19 15:07:39 inet-gw kernel: em2: link state changed to DOWN Feb 19 15:07:42 inet-gw kernel: em2: link state changed to UP =09 # from /var/run/dmesg.boot em0: port 0xdce0-0xdcff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 on pci8 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:a6:ae:94 em2: port 0xcce0-0xccff mem 0xde3e0000-0xde3fffff,0xde3c0000-0xde3dffff irq 16 at device 0.0 on pci10 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:15:17:a6:af:d6 =09 # pciconf -lv em0@pci0:8:0:0: class=3D0x020000 card=3D0x135e8086 chip=3D0x105e8086 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/1000 PT' class =3D network subclass =3D ethernet em2@pci0:10:0:0: class=3D0x020000 card=3D0x135e8086 chip=3D0x105e8086 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/1000 PT' class =3D network subclass =3D ethernet =09 # netstat -bdhI em2 2 input (em2) output packets errs bytes packets errs bytes colls drops 65K 0 72M 51K 0 9.4M 0 0 69K 0 78M 52K 0 8.5M 0 0 76K 0 88M 55K 0 11M 0 0 74K 0 85M 54K 0 10M 0 0 78K 0 91M 56K 0 9.0M 0 0 75K 0 86M 54K 0 8.7M 0 0 74K 0 85M 54K 0 9.2M 0 0 75K 0 86M 56K 0 10M 0 0 78K 0 88M 55K 0 12M 0 0 78K 0 90M 58K 0 12M 0 0 76K 0 87M 54K 0 10M 0 0 79K 0 91M 56K 0 10M 0 0 =09 =09 ---- Kirk =09 ------------------------------------------------------------------------ -------- Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools One Kingsway Ave. Edmonton, Alberta, Canada T5H 4G9 =09 _______________________________________________ freebsd-net@freebsd.org mailing list =09 http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =09 From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 21:08:05 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 46EBC106568D for ; Mon, 22 Feb 2010 21:08:05 +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 EBA108FC25 for ; Mon, 22 Feb 2010 21:08:04 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o1ML7v3Z059734; Mon, 22 Feb 2010 16:07:57 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201002222107.o1ML7v3Z059734@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Feb 2010 16:08:25 -0500 To: "Kirk Davis" , "Jack Vogel" From: Mike Tancsa In-Reply-To: <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.ep sb.ca> References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Intel em0: watchdog timeout 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, 22 Feb 2010 21:08:05 -0000 At 03:46 PM 2/22/2010, Kirk Davis wrote: >Does this need to be done in loader.conf? It doesn't seem to take from >the command line. ># sysctl dev.em.2.stats=1 >dev.em.2.stats: -1 -> -1 > ># sysctl dev.em.2.stats >dev.em.2.stats: -1 Hi, After you issue those commands, the driver will spit out a lot of useful stats to syslog. It will report something like the following in /var/log/messages Feb 22 16:06:31 offsite kernel: em0: Excessive collisions = 0 Feb 22 16:06:31 offsite kernel: em0: Sequence errors = 0 Feb 22 16:06:31 offsite kernel: em0: Defer count = 0 Feb 22 16:06:31 offsite kernel: em0: Missed Packets = 0 Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers = 0 Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors = 0 Feb 22 16:06:31 offsite kernel: em0: Receive errors = 0 Feb 22 16:06:31 offsite kernel: em0: Crc errors = 0 Feb 22 16:06:31 offsite kernel: em0: Alignment errors = 0 Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier extension errors = 0 Feb 22 16:06:31 offsite kernel: em0: RX overruns = 0 Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts = 0 Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Feb 22 16:06:31 offsite kernel: em0: XON Rcvd = 0 Feb 22 16:06:31 offsite kernel: em0: XON Xmtd = 0 Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd = 0 Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd = 0 Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd = 2559032551 Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd = 1568751141 Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd = 0 Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed = 0 ---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 Mon Feb 22 21:09: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 900D810656AB for ; Mon, 22 Feb 2010 21:09:39 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 23AC48FC45 for ; Mon, 22 Feb 2010 21:09:38 +0000 (UTC) Received: by wwb22 with SMTP id 22so554407wwb.13 for ; Mon, 22 Feb 2010 13:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZmsFE9zmyBN7Qhuekn3s+KEWHhKBNqqksledsEcS9Ho=; b=beHhk+otN6YiC4d/eEG6fPkrrdAG/HBp3Kcq1jOujMEFu4JChU/5MFZS9LGn6ZGBcT Wgc15ocTp1JWxN+caE8owjqvZ/vtpfkUSKyOrn5HsjbvacVaXNtHUIvIzrJLoqu4T+Cm 3qF6qZKo/B3RGSQj7jGf/TdRNY4Ben29vW/sI= 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=BFTD9qdTCI+5FBpiL9vjWAQAIMQ0G1ZzhDy4OFRrkS7hCCBLfKNnf+tjFPXCKWyaWY AEyBgLEVKVMCNn3vMwudbb6zB4bk3/qpFiqGmH30u4HeVOkKnf0aSjyWC46Yo8y5RfzE SFc6tcHqGfvET+WU1RjFvzRbtPNsTXYgUBRq0= MIME-Version: 1.0 Received: by 10.216.162.202 with SMTP id y52mr2690958wek.76.1266872975608; Mon, 22 Feb 2010 13:09:35 -0800 (PST) In-Reply-To: <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> Date: Mon, 22 Feb 2010 13:09:35 -0800 Message-ID: <2a41acea1002221309i43abe533jc801cc81dd1c15b3@mail.gmail.com> From: Jack Vogel To: Kirk Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Intel em0: watchdog timeout 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, 22 Feb 2010 21:09:39 -0000 On Mon, Feb 22, 2010 at 12:46 PM, Kirk Davis wrote: > > From: Jack Vogel [mailto:jfvogel@gmail.com] > > Try `sysctl dev.em.0.stats=1` and em.2, you're right though, > doesn't look like any > system mbuf failures. > > > Does this need to be done in loader.conf? It doesn't seem to take from > the command line. > # sysctl dev.em.2.stats=1 > dev.em.2.stats: -1 -> -1 > > # sysctl dev.em.2.stats > dev.em.2.stats: -1 > > > you will only see the data on the system console, if you're in a graphics environment use `tail /var/log/messages' and you will see it :) > 7.2 seems to be a stable base OS and driver, 8 is better in some > respects, but > has not been without its reported problems. I leave the choice > to you. > > Without more data I am not sure what is causing the watchdog. > > Yes, I am having trouble tracking it down. I up'ed the mbufs to 65536 > just to see if it made any difference but it is still happening. > I have the testers here set: nmbclusters 262144 Jack From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 21:43:58 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 C47AC106566C for ; Mon, 22 Feb 2010 21:43:58 +0000 (UTC) (envelope-from kirk.davis@epsb.ca) Received: from Exchange22.EDU.epsb.ca (exchange22.epsb.ca [198.161.119.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9789A8FC16 for ; Mon, 22 Feb 2010 21:43:58 +0000 (UTC) Received: from Exchange26.EDU.epsb.ca ([10.0.5.123]) by Exchange22.EDU.epsb.ca with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 14:43:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Feb 2010 14:43:57 -0700 Message-ID: <529374128DC1B04D9D037911B8E8F05301C17A56@Exchange26.EDU.epsb.ca> In-Reply-To: <201002222107.o1ML7v3Z059734@lava.sentex.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel em0: watchdog timeout Thread-Index: Acq0AyAQox1E50HNSzSULBjpLRnbngABI91Q References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> <201002222107.o1ML7v3Z059734@lava.sentex.ca> From: "Kirk Davis" To: "Mike Tancsa" , "Jack Vogel" X-OriginalArrivalTime: 22 Feb 2010 21:43:57.0299 (UTC) FILETIME=[22F96C30:01CAB408] Cc: freebsd-net@freebsd.org Subject: RE: Intel em0: watchdog timeout 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, 22 Feb 2010 21:43:58 -0000 =20 > -----Original Message----- > From: Mike Tancsa [mailto:mike@sentex.net]=20 > Subject: Re: Intel em0: watchdog timeout >=20 > At 03:46 PM 2/22/2010, Kirk Davis wrote: > >Does this need to be done in loader.conf? It doesn't seem=20 > to take from > >the command line. > ># sysctl dev.em.2.stats=3D1 > >dev.em.2.stats: -1 -> -1 > > > ># sysctl dev.em.2.stats > >dev.em.2.stats: -1 >=20 > Hi, > After you issue those commands, the driver will spit out a=20 > lot of useful stats to syslog. It will report something like the=20 > following in /var/log/messages >=20 > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Sequence errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Defer count =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Missed Packets =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Crc errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Alignment errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier=20 > extension errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: RX overruns =3D 0 > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts =3D 0 > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D = 0=20 > LINK MSIX IRQ =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd =3D 2559032551 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd =3D 1568751141 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed =3D 0 Thanks Mike and Jack. I don't know why I didn'ty notice the output in /var/log/messages Here is the output for the two interfaces that are causing this issue. Feb 22 13:33:52 inet-gw kernel: em0: Excessive collisions =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Sequence errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Defer count =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Missed Packets =3D 24296 Feb 22 13:33:52 inet-gw kernel: em0: Receive No Buffers =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive Length Errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Crc errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Alignment errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Collision/Carrier extension errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: RX overruns =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: watchdog timeouts =3D 6 Feb 22 13:33:52 inet-gw kernel: em0: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Rcvd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Rcvd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Rcvd =3D 424303810 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Xmtd =3D 576529136 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Failed =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:34:12 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:34:12 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:34:12 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:34:12 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:34:12 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:34:12 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Rcvd =3D 713607509 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Xmtd =3D 569694020 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Failed =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:35:10 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:35:10 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:35:10 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:35:10 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:35:10 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:35:10 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:35:10 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:35:10 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Rcvd =3D 715555016 Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Xmtd =3D 571157561 Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Failed =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:39:12 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:39:12 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:39:12 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:39:12 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:39:12 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:39:12 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:39:12 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:39:12 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Rcvd =3D 723521981 Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Xmtd =3D 577211431 Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Failed =3D 0 Can this be the problem? "Receive No Buffers =3D 275612" ---- Kirk Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools One Kingsway Ave.=20 Edmonton, Alberta, Canada T5H 4G9 phone: 1-780-429-8308 From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 22:44: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 49315106566B for ; Mon, 22 Feb 2010 22:44:52 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id A4B9B8FC14 for ; Mon, 22 Feb 2010 22:44:51 +0000 (UTC) Received: by ewy3 with SMTP id 3so2967284ewy.13 for ; Mon, 22 Feb 2010 14:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZbhZfyqRkzdfUJC2RN7wtC9YUz42cYktgKLRPK0XSPM=; b=QIO95lySaIeuRtXDsKVArXIyiD2v0KFrViK8jJKYI6PiG3Jg9HoTTnKnnhtQwC+VBY LpBqp/FEJKc2wchA+Bo5GSkePWomrueZkDGRY0rrSN3ltTEzMnAgYtmWjPy3q84SchyD 8j3RBTfbsyw5uAqcBpM7opU8qlCOO9umEcxfY= 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=KEFvYBBlTF5KLK/4DviMFahonnT2fVbxRfEO10mJnj2MpOoiC/5oiOmm8UHYI0oYV6 EwVGD24L7VptD4Gnk7qO25CTS9U3HZhbWURJKGmUZ8eDDhrMxCRJ+5xcFDpZHFrBeyui G3UixJcmWMl5sjt4b0oeT9zBhK2+PYFJLn/0s= MIME-Version: 1.0 Received: by 10.216.177.82 with SMTP id c60mr136482wem.25.1266878678024; Mon, 22 Feb 2010 14:44:38 -0800 (PST) In-Reply-To: <529374128DC1B04D9D037911B8E8F05301C17A56@Exchange26.EDU.epsb.ca> References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> <201002222107.o1ML7v3Z059734@lava.sentex.ca> <529374128DC1B04D9D037911B8E8F05301C17A56@Exchange26.EDU.epsb.ca> Date: Mon, 22 Feb 2010 14:44:37 -0800 Message-ID: <2a41acea1002221444o6e449602m1830761b21837c41@mail.gmail.com> From: Jack Vogel To: Kirk Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: Intel em0: watchdog timeout 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, 22 Feb 2010 22:44:52 -0000 OK, so you are still failing to get mbufs in the RX side, increase the nmbcluster value, and then what size is your RX ring (number of rx descriptors)? If you havent already done so, change that to 1024. I am developing a change in the RX code right now that will help this situation, but am doing so in the 10G driver, once its solid there I will be backporting it into the 1G drivers, it will make discards almost unnecessary. Jack On Mon, Feb 22, 2010 at 1:43 PM, Kirk Davis wrote: > > > > -----Original Message----- > > From: Mike Tancsa [mailto:mike@sentex.net] > > Subject: Re: Intel em0: watchdog timeout > > > > At 03:46 PM 2/22/2010, Kirk Davis wrote: > > >Does this need to be done in loader.conf? It doesn't seem > > to take from > > >the command line. > > ># sysctl dev.em.2.stats=1 > > >dev.em.2.stats: -1 -> -1 > > > > > ># sysctl dev.em.2.stats > > >dev.em.2.stats: -1 > > > > Hi, > > After you issue those commands, the driver will spit out a > > lot of useful stats to syslog. It will report something like the > > following in /var/log/messages > > > > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions = 0 > > Feb 22 16:06:31 offsite kernel: em0: Sequence errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Defer count = 0 > > Feb 22 16:06:31 offsite kernel: em0: Missed Packets = 0 > > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers = 0 > > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Receive errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Crc errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Alignment errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier > > extension errors = 0 > > Feb 22 16:06:31 offsite kernel: em0: RX overruns = 0 > > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts = 0 > > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > > LINK MSIX IRQ = 0 > > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd = 0 > > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd = 0 > > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd = 0 > > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd = 0 > > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd = 2559032551 > > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd = 1568751141 > > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd = 0 > > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed = 0 > > Thanks Mike and Jack. I don't know why I didn'ty notice the output in > /var/log/messages > > Here is the output for the two interfaces that are causing this issue. > > Feb 22 13:33:52 inet-gw kernel: em0: Excessive collisions = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Sequence errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Defer count = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Missed Packets = 24296 > Feb 22 13:33:52 inet-gw kernel: em0: Receive No Buffers = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Receive Length Errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Receive errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Crc errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Alignment errors = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Collision/Carrier extension errors > = 0 > Feb 22 13:33:52 inet-gw kernel: em0: RX overruns = 0 > Feb 22 13:33:52 inet-gw kernel: em0: watchdog timeouts = 6 > Feb 22 13:33:52 inet-gw kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > LINK MSIX IRQ = 0 > Feb 22 13:33:52 inet-gw kernel: em0: XON Rcvd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: XON Xmtd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: XOFF Rcvd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: XOFF Xmtd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Rcvd = 424303810 > Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Xmtd = 576529136 > Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Xmtd = 0 > Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Failed = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Excessive collisions = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Sequence errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Defer count = 20 > Feb 22 13:34:12 inet-gw kernel: em2: Missed Packets = 68059 > Feb 22 13:34:12 inet-gw kernel: em2: Receive No Buffers = 275612 > Feb 22 13:34:12 inet-gw kernel: em2: Receive Length Errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Receive errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Crc errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Alignment errors = 0 > Feb 22 13:34:12 inet-gw kernel: em2: Collision/Carrier extension errors > = 0 > Feb 22 13:34:12 inet-gw kernel: em2: RX overruns = 17 > Feb 22 13:34:12 inet-gw kernel: em2: watchdog timeouts = 38 > Feb 22 13:34:12 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > LINK MSIX IRQ = 0 > Feb 22 13:34:12 inet-gw kernel: em2: XON Rcvd = 21 > Feb 22 13:34:12 inet-gw kernel: em2: XON Xmtd = 8344 > Feb 22 13:34:12 inet-gw kernel: em2: XOFF Rcvd = 30 > Feb 22 13:34:12 inet-gw kernel: em2: XOFF Xmtd = 9159 > Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Rcvd = 713607509 > Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Xmtd = 569694020 > Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Xmtd = 0 > Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Failed = 0 > Feb 22 13:35:10 inet-gw kernel: em2: Excessive collisions = 0 > Feb 22 13:35:10 inet-gw kernel: em2: Sequence errors = 0 > Feb 22 13:35:10 inet-gw kernel: em2: Defer count = 20 > Feb 22 13:35:10 inet-gw kernel: em2: Missed Packets = 68059 > Feb 22 13:35:10 inet-gw kernel: em2: Receive No Buffers = 275612 > Feb 22 13:35:10 inet-gw kernel: em2: Receive Length Errors = 0 > Feb 22 13:35:10 inet-gw kernel: em2: Receive errors = 0 > Feb 22 13:35:10 inet-gw kernel: em2: Crc errors = 0 > Feb 22 13:35:10 inet-gw kernel: em2: Alignment errors = 0 > Feb 22 13:35:10 inet-gw kernel: em2: Collision/Carrier extension errors > = 0 > Feb 22 13:35:10 inet-gw kernel: em2: RX overruns = 17 > Feb 22 13:35:10 inet-gw kernel: em2: watchdog timeouts = 38 > Feb 22 13:35:10 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > LINK MSIX IRQ = 0 > Feb 22 13:35:10 inet-gw kernel: em2: XON Rcvd = 21 > Feb 22 13:35:10 inet-gw kernel: em2: XON Xmtd = 8344 > Feb 22 13:35:10 inet-gw kernel: em2: XOFF Rcvd = 30 > Feb 22 13:35:10 inet-gw kernel: em2: XOFF Xmtd = 9159 > Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Rcvd = 715555016 > Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Xmtd = 571157561 > Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Xmtd = 0 > Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Failed = 0 > Feb 22 13:39:12 inet-gw kernel: em2: Excessive collisions = 0 > Feb 22 13:39:12 inet-gw kernel: em2: Sequence errors = 0 > Feb 22 13:39:12 inet-gw kernel: em2: Defer count = 20 > Feb 22 13:39:12 inet-gw kernel: em2: Missed Packets = 68059 > Feb 22 13:39:12 inet-gw kernel: em2: Receive No Buffers = 275612 > Feb 22 13:39:12 inet-gw kernel: em2: Receive Length Errors = 0 > Feb 22 13:39:12 inet-gw kernel: em2: Receive errors = 0 > Feb 22 13:39:12 inet-gw kernel: em2: Crc errors = 0 > Feb 22 13:39:12 inet-gw kernel: em2: Alignment errors = 0 > Feb 22 13:39:12 inet-gw kernel: em2: Collision/Carrier extension errors > = 0 > Feb 22 13:39:12 inet-gw kernel: em2: RX overruns = 17 > Feb 22 13:39:12 inet-gw kernel: em2: watchdog timeouts = 38 > Feb 22 13:39:12 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 > LINK MSIX IRQ = 0 > Feb 22 13:39:12 inet-gw kernel: em2: XON Rcvd = 21 > Feb 22 13:39:12 inet-gw kernel: em2: XON Xmtd = 8344 > Feb 22 13:39:12 inet-gw kernel: em2: XOFF Rcvd = 30 > Feb 22 13:39:12 inet-gw kernel: em2: XOFF Xmtd = 9159 > Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Rcvd = 723521981 > Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Xmtd = 577211431 > Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Xmtd = 0 > Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Failed = 0 > > > Can this be the problem? "Receive No Buffers = 275612" > > ---- Kirk > Kirk Davis > Senior Network Analyst, ITS > Edmonton Public Schools > One Kingsway Ave. > Edmonton, Alberta, Canada > T5H 4G9 > phone: 1-780-429-8308 > > > From owner-freebsd-net@FreeBSD.ORG Mon Feb 22 23:37: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 4570E106568B for ; Mon, 22 Feb 2010 23:37:52 +0000 (UTC) (envelope-from kirk.davis@epsb.ca) Received: from OWA01.EDU.epsb.ca (owa01.epsb.ca [198.161.119.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0E01B8FC17 for ; Mon, 22 Feb 2010 23:37:51 +0000 (UTC) Received: from Exchange26.EDU.epsb.ca ([10.0.5.123]) by OWA01.EDU.epsb.ca with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 16:37:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Feb 2010 16:37:50 -0700 Message-ID: <529374128DC1B04D9D037911B8E8F05301C17A57@Exchange26.EDU.epsb.ca> In-Reply-To: <2a41acea1002221444o6e449602m1830761b21837c41@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel em0: watchdog timeout Thread-Index: Acq0EKIpglmJFQoQTZ+2YB9QOrNkEAABoINA References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> <201002222107.o1ML7v3Z059734@lava.sentex.ca> <529374128DC1B04D9D037911B8E8F05301C17A56@Exchange26.EDU.epsb.ca> <2a41acea1002221444o6e449602m1830761b21837c41@mail.gmail.com> From: "Kirk Davis" To: "Jack Vogel" X-OriginalArrivalTime: 22 Feb 2010 23:37:50.0984 (UTC) FILETIME=[0C2B0080:01CAB418] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: RE: Intel em0: watchdog timeout 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, 22 Feb 2010 23:37:52 -0000 OK. I have the following in /boot/loader.conf (and rebooted) hw.em.rxd=3D1024 hw.em.txd=3D1024 =20 Should this be hw.em2.rxd? Is it set per interface or across all interfaces? =20 nmbcluster=3D262144 =20 # sysctl dev.em.2.stats=3D1 Feb 22 16:29:57 inet-gw kernel: em2: Defer count =3D 20 Feb 22 16:29:57 inet-gw kernel: em2: Missed Packets =3D 119947 =20 Feb 22 16:29:57 inet-gw kernel: em2: Receive No Buffers =3D 276762 Feb 22 16:29:57 inet-gw kernel: em2: Receive Length Errors =3D 0=20 Feb 22 16:29:57 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: RX overruns =3D 21 Feb 22 16:29:57 inet-gw kernel: em2: watchdog timeouts =3D 47 Feb 22 16:29:57 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: XON Rcvd =3D 22 Feb 22 16:29:57 inet-gw kernel: em2: XON Xmtd =3D 8349 Feb 22 16:29:57 inet-gw kernel: em2: XOFF Rcvd =3D 31 Feb 22 16:29:57 inet-gw kernel: em2: XOFF Xmtd =3D 15779 Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Rcvd =3D 966101852 Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Xmtd =3D 755993237 Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Failed =3D 0 =20 still seeing the watchdog timer and link up/down messages. =20 Should I try going higher than 1024 on the hw.em.rxd? I'm not sure the next time I can schedule another reboot on this production server. =20 ---- Kirk =20 Kirk Davis=20 Senior Network Analyst, ITS=20 Edmonton Public Schools=20 One Kingsway Ave.=20 Edmonton, Alberta, Canada=20 T5H 4G9=20 phone: 1-780-429-8308=20 =20 ________________________________ From: Jack Vogel [mailto:jfvogel@gmail.com]=20 Sent: Monday, February 22, 2010 3:45 PM To: Kirk Davis Cc: Mike Tancsa; freebsd-net@freebsd.org Subject: Re: Intel em0: watchdog timeout =09 =09 OK, so you are still failing to get mbufs in the RX side, increase the nmbcluster value, and then what size is your RX ring (number of rx descriptors)? =09 If you havent already done so, change that to 1024.=20 =09 I am developing a change in the RX code right now that will help this situation, but am doing so in the 10G driver, once its solid there I will be backporting it into the 1G drivers, it will make discards almost unnecessary. =09 Jack =09 =09 On Mon, Feb 22, 2010 at 1:43 PM, Kirk Davis wrote: =09 > -----Original Message----- > From: Mike Tancsa [mailto:mike@sentex.net] > Subject: Re: Intel em0: watchdog timeout > > At 03:46 PM 2/22/2010, Kirk Davis wrote: > >Does this need to be done in loader.conf? It doesn't seem > to take from > >the command line. > ># sysctl dev.em.2.stats=3D1 > >dev.em.2.stats: -1 -> -1 > > > ># sysctl dev.em.2.stats > >dev.em.2.stats: -1 > > Hi, > After you issue those commands, the driver will spit out a > lot of useful stats to syslog. It will report something like the > following in /var/log/messages > > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Sequence errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Defer count =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Missed Packets =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Crc errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Alignment errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier > extension errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: RX overruns =3D 0 > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts =3D 0 > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 > LINK MSIX IRQ =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd =3D 2559032551 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd =3D 1568751141 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed =3D 0 =09 =09 Thanks Mike and Jack. I don't know why I didn'ty notice the output in /var/log/messages =09 Here is the output for the two interfaces that are causing this issue. =09 Feb 22 13:33:52 inet-gw kernel: em0: Excessive collisions =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Sequence errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Defer count =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Missed Packets =3D 24296 Feb 22 13:33:52 inet-gw kernel: em0: Receive No Buffers =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive Length Errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Crc errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Alignment errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Collision/Carrier extension errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: RX overruns =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: watchdog timeouts =3D 6 Feb 22 13:33:52 inet-gw kernel: em0: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Rcvd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Rcvd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Rcvd =3D 424303810 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Xmtd =3D 576529136 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Failed =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:34:12 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:34:12 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:34:12 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:34:12 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:34:12 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:34:12 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Rcvd =3D 713607509 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Xmtd =3D 569694020 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Failed =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:35:10 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:35:10 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:35:10 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:35:10 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:35:10 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:35:10 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:35:10 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:35:10 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Rcvd =3D 715555016 Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Xmtd =3D 571157561 Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Failed =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:39:12 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:39:12 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:39:12 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:39:12 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:39:12 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:39:12 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:39:12 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:39:12 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Rcvd =3D 723521981 Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Xmtd =3D 577211431 Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Failed =3D 0 =09 =09 Can this be the problem? "Receive No Buffers =3D 275612" =09 ---- Kirk Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools One Kingsway Ave. Edmonton, Alberta, Canada T5H 4G9 =09 phone: 1-780-429-8308 =09 =09 =09 From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 00:29: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 996F01065672 for ; Tue, 23 Feb 2010 00:29:47 +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 08C238FC12 for ; Tue, 23 Feb 2010 00:29:46 +0000 (UTC) Received: by wyb40 with SMTP id 40so442517wyb.13 for ; Mon, 22 Feb 2010 16:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oW+uOWH2bxM2Uj4GdefiUzgF/KP7LGwq96VlT7I+xDg=; b=c8NKyhjTDw0qpHy3ubnLnpOvczV+HV4a7GO0EhKbGUeNTwyGNfkkIkvUUBNig0vfG8 jGSgoRJ8hlT5SFC8yMxgFDJqdvthprvBqEMCcqtf1CvDj/B0m4Ex0vtD5OGudD6HpZOh hPyxYBzqpVSbS/L2ikxe6YUXA9l3r6XRPqgNo= 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=LA/W/9qkKJFG7Hb3G4LRs6EHVGRz5uTUNI14isOPXloFcdto8a7rfr0V+9aFQSy297 r4smUBvWN1htao5MYISWRcel5EDa0zYinL9kQOydIV7QefL4vzNdSOq7f2hFrZ982ZSH 6QqnJvhy5Fn0kvQQs5Xe2+VkgajCj3ICjkvZo= MIME-Version: 1.0 Received: by 10.216.177.82 with SMTP id c60mr208141wem.25.1266884980973; Mon, 22 Feb 2010 16:29:40 -0800 (PST) In-Reply-To: <529374128DC1B04D9D037911B8E8F05301C17A57@Exchange26.EDU.epsb.ca> References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> <201002222107.o1ML7v3Z059734@lava.sentex.ca> <529374128DC1B04D9D037911B8E8F05301C17A56@Exchange26.EDU.epsb.ca> <2a41acea1002221444o6e449602m1830761b21837c41@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A57@Exchange26.EDU.epsb.ca> Date: Mon, 22 Feb 2010 16:29:40 -0800 Message-ID: <2a41acea1002221629vbe7548am7b5f1ba94d7efa9f@mail.gmail.com> From: Jack Vogel To: Kirk Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: Intel em0: watchdog timeout 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, 23 Feb 2010 00:29:47 -0000 Is your driver static, ie builtin, to the kernel, or do you load/unload it as a module? I ask because perhaps we could try a later driver, and being a module makes that easier. Jack On Mon, Feb 22, 2010 at 3:37 PM, Kirk Davis wrote: > OK. I have the following in /boot/loader.conf (and rebooted) > hw.em.rxd=1024 > hw.em.txd=1024 > > Should this be hw.em2.rxd? Is it set per interface or across all > interfaces? > > nmbcluster=262144 > > # sysctl dev.em.2.stats=1 > Feb 22 16:29:57 inet-gw kernel: em2: Defer count = 20 > Feb 22 16:29:57 inet-gw kernel: em2: Missed Packets = 119947 > Feb 22 16:29:57 inet-gw kernel: em2: Receive No Buffers = 276762 > Feb 22 16:29:57 inet-gw kernel: em2: Receive Length Errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: Receive errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: Crc errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: Alignment errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: Collision/Carrier extension errors = 0 > Feb 22 16:29:57 inet-gw kernel: em2: RX overruns = 21 > Feb 22 16:29:57 inet-gw kernel: em2: watchdog timeouts = 47 > Feb 22 16:29:57 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK > MSIX IRQ = 0 > Feb 22 16:29:57 inet-gw kernel: em2: XON Rcvd = 22 > Feb 22 16:29:57 inet-gw kernel: em2: XON Xmtd = 8349 > Feb 22 16:29:57 inet-gw kernel: em2: XOFF Rcvd = 31 > Feb 22 16:29:57 inet-gw kernel: em2: XOFF Xmtd = 15779 > Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Rcvd = 966101852 > Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Xmtd = 755993237 > Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Xmtd = 0 > Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Failed = 0 > > still seeing the watchdog timer and link up/down messages. > > Should I try going higher than 1024 on the hw.em.rxd? I'm not sure the > next time I can schedule another reboot on this production server. > > ---- Kirk > > > *Kirk Davis*** > *Senior Network Analyst, ITS* > *Edmonton Public Schools* > *One Kingsway Ave. * > *Edmonton, Alberta, Canada* > *T5H 4G9* > *phone: 1-780-429-8308* > > > ------------------------------ > *From:* Jack Vogel [mailto:jfvogel@gmail.com] > *Sent:* Monday, February 22, 2010 3:45 PM > *To:* Kirk Davis > *Cc:* Mike Tancsa; freebsd-net@freebsd.org > > *Subject:* Re: Intel em0: watchdog timeout > > OK, so you are still failing to get mbufs in the RX side, increase the > nmbcluster > value, and then what size is your RX ring (number of rx descriptors)? > > If you havent already done so, change that to 1024. > > I am developing a change in the RX code right now that will help > this situation, but am doing so in the 10G driver, once its solid there > I will be backporting it into the 1G drivers, it will make discards > almost unnecessary. > > Jack > > On Mon, Feb 22, 2010 at 1:43 PM, Kirk Davis wrote: > >> >> >> > -----Original Message----- >> > From: Mike Tancsa [mailto:mike@sentex.net] >> > Subject: Re: Intel em0: watchdog timeout >> > >> > At 03:46 PM 2/22/2010, Kirk Davis wrote: >> > >Does this need to be done in loader.conf? It doesn't seem >> > to take from >> > >the command line. >> > ># sysctl dev.em.2.stats=1 >> > >dev.em.2.stats: -1 -> -1 >> > > >> > ># sysctl dev.em.2.stats >> > >dev.em.2.stats: -1 >> > >> > Hi, >> > After you issue those commands, the driver will spit out a >> > lot of useful stats to syslog. It will report something like the >> > following in /var/log/messages >> > >> > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Sequence errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Defer count = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Missed Packets = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Receive errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Crc errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Alignment errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier >> > extension errors = 0 >> > Feb 22 16:06:31 offsite kernel: em0: RX overruns = 0 >> > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts = 0 >> > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 >> > LINK MSIX IRQ = 0 >> > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd = 2559032551 >> > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd = 1568751141 >> > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd = 0 >> > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed = 0 >> >> Thanks Mike and Jack. I don't know why I didn'ty notice the output in >> /var/log/messages >> >> Here is the output for the two interfaces that are causing this issue. >> >> Feb 22 13:33:52 inet-gw kernel: em0: Excessive collisions = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: Sequence errors = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: Defer count = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: Missed Packets = 24296 >> Feb 22 13:33:52 inet-gw kernel: em0: Receive No Buffers = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: Receive Length Errors = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: Receive errors = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: Crc errors = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: Alignment errors = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: Collision/Carrier extension errors >> = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: RX overruns = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: watchdog timeouts = 6 >> Feb 22 13:33:52 inet-gw kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 >> LINK MSIX IRQ = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: XON Rcvd = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: XON Xmtd = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: XOFF Rcvd = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: XOFF Xmtd = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Rcvd = 424303810 >> Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Xmtd = 576529136 >> Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Xmtd = 0 >> Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Failed = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: Excessive collisions = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: Sequence errors = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: Defer count = 20 >> Feb 22 13:34:12 inet-gw kernel: em2: Missed Packets = 68059 >> Feb 22 13:34:12 inet-gw kernel: em2: Receive No Buffers = 275612 >> Feb 22 13:34:12 inet-gw kernel: em2: Receive Length Errors = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: Receive errors = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: Crc errors = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: Alignment errors = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: Collision/Carrier extension errors >> = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: RX overruns = 17 >> Feb 22 13:34:12 inet-gw kernel: em2: watchdog timeouts = 38 >> Feb 22 13:34:12 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 >> LINK MSIX IRQ = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: XON Rcvd = 21 >> Feb 22 13:34:12 inet-gw kernel: em2: XON Xmtd = 8344 >> Feb 22 13:34:12 inet-gw kernel: em2: XOFF Rcvd = 30 >> Feb 22 13:34:12 inet-gw kernel: em2: XOFF Xmtd = 9159 >> Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Rcvd = 713607509 >> Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Xmtd = 569694020 >> Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Xmtd = 0 >> Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Failed = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: Excessive collisions = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: Sequence errors = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: Defer count = 20 >> Feb 22 13:35:10 inet-gw kernel: em2: Missed Packets = 68059 >> Feb 22 13:35:10 inet-gw kernel: em2: Receive No Buffers = 275612 >> Feb 22 13:35:10 inet-gw kernel: em2: Receive Length Errors = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: Receive errors = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: Crc errors = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: Alignment errors = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: Collision/Carrier extension errors >> = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: RX overruns = 17 >> Feb 22 13:35:10 inet-gw kernel: em2: watchdog timeouts = 38 >> Feb 22 13:35:10 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 >> LINK MSIX IRQ = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: XON Rcvd = 21 >> Feb 22 13:35:10 inet-gw kernel: em2: XON Xmtd = 8344 >> Feb 22 13:35:10 inet-gw kernel: em2: XOFF Rcvd = 30 >> Feb 22 13:35:10 inet-gw kernel: em2: XOFF Xmtd = 9159 >> Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Rcvd = 715555016 >> Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Xmtd = 571157561 >> Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Xmtd = 0 >> Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Failed = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: Excessive collisions = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: Sequence errors = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: Defer count = 20 >> Feb 22 13:39:12 inet-gw kernel: em2: Missed Packets = 68059 >> Feb 22 13:39:12 inet-gw kernel: em2: Receive No Buffers = 275612 >> Feb 22 13:39:12 inet-gw kernel: em2: Receive Length Errors = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: Receive errors = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: Crc errors = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: Alignment errors = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: Collision/Carrier extension errors >> = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: RX overruns = 17 >> Feb 22 13:39:12 inet-gw kernel: em2: watchdog timeouts = 38 >> Feb 22 13:39:12 inet-gw kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 >> LINK MSIX IRQ = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: XON Rcvd = 21 >> Feb 22 13:39:12 inet-gw kernel: em2: XON Xmtd = 8344 >> Feb 22 13:39:12 inet-gw kernel: em2: XOFF Rcvd = 30 >> Feb 22 13:39:12 inet-gw kernel: em2: XOFF Xmtd = 9159 >> Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Rcvd = 723521981 >> Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Xmtd = 577211431 >> Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Xmtd = 0 >> Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Failed = 0 >> >> >> Can this be the problem? "Receive No Buffers = 275612" >> >> ---- Kirk >> Kirk Davis >> Senior Network Analyst, ITS >> Edmonton Public Schools >> One Kingsway Ave. >> Edmonton, Alberta, Canada >> T5H 4G9 >> phone: 1-780-429-8308 >> >> >> > From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 01:10:36 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 B6065106566B for ; Tue, 23 Feb 2010 01:10:36 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from smtp.ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 233A88FC08 for ; Tue, 23 Feb 2010 01:10:35 +0000 (UTC) Received: (qmail 83095 invoked by uid 89); 23 Feb 2010 01:14:57 -0000 Received: from unknown (HELO ?192.168.1.114?) (steve@ibctech.ca@::ffff:208.70.104.100) by ::ffff:208.70.104.210 with ESMTPA; 23 Feb 2010 01:14:56 -0000 Message-ID: <4B832B14.3090406@ibctech.ca> Date: Mon, 22 Feb 2010 20:10:44 -0500 From: Steve Bertrand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Christian Ullrich References: <4B7C62AF.6000904@chrullrich.net> <4B7CA72A.4050202@ibctech.ca> <4B7CD0CB.4080105@chrullrich.net> In-Reply-To: <4B7CD0CB.4080105@chrullrich.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Routing into overlapping subnets 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, 23 Feb 2010 01:10:36 -0000 On 2010.02.18 00:31, Christian Ullrich wrote: > * Steve Bertrand wrote: > >> On 2010.02.17 16:42, Christian Ullrich wrote: > >>> send the packet. Why doesn't the kernel look up an ARP table entry by >>> both IP address and interface? >> >> That's not how the protocols were designed, and thankfully so. Imagine >> the potential for spoofing if this were allowed by default ;) > > You're right, of course. I had not considered that. > >> I have a couple of ideas, but need to understand better of your setup. >> Advise if this seems semi-accurate: >> >> - you house global resources for a bunch of clients at a central location >> - you have limited public IP addresses to do this with, or your central >> location is located within the same 'building' as all of the clients > > The latter. > >> - you have several clients with overlapping 1918 space >> - you need a method to have two instances of eg 192.168.1.110 accessing >> a single central resource, but which will be coming in on two separate >> interfaces (physical or virtual) >> - the central services (ie printer) doesn't have the capability to house >> more than a single IPv4 address >> - you do not want to be open to the potential for one client accessing >> the others networks >> - you have absolute control over the pf box >> >> is this right? > > Exactly right. Contact me off-list, and I'll see if I can help with either cleaning this up, or with a dirty hack. We'll post any positive results to the list. Steve From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 07:58: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 58DCE106568B for ; Tue, 23 Feb 2010 07:58:37 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx39.mail.ru (mx39.mail.ru [94.100.176.53]) by mx1.freebsd.org (Postfix) with ESMTP id 148A28FC12 for ; Tue, 23 Feb 2010 07:58:36 +0000 (UTC) Received: from [217.25.27.27] (port=24813 helo=[217.25.27.27]) by mx39.mail.ru with asmtp id 1Njpf9-0003qK-00; Tue, 23 Feb 2010 10:58:35 +0300 Message-ID: <4B838AAA.7080104@mail.ru> Date: Tue, 23 Feb 2010 11:58:34 +0400 From: rihad User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Luigi Rizzo References: <4B7EDD00.5080308@mail.ru> <20100220095941.GA82976@onelab2.iet.unipi.it> In-Reply-To: <20100220095941.GA82976@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: Slow speeds experienced with Dummynet 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, 23 Feb 2010 07:58:37 -0000 Luigi Rizzo wrote: > On Fri, Feb 19, 2010 at 10:48:32PM +0400, rihad wrote: >> Hi, all, >> >> Recalling my old posting "dummynet dropping too many packets" dated >> October 4, 2009, the problem isn't over just yet. This time, there are >> no interface i/o drops (just a reminder: we have 2 bce(4) GigE cards >> connected to a Cisco router, one for input, and one for output. The box >> itself does some traffic accounting and enforces speed limits w/ >> ipfw/dummynet. There are normally around 5-6k users online). > > If i remember well, the previous discussion ended when you > raised the intr_queue_maxlen (and perhaps increased HZ) to > avoid that the bursts produced by periodic invocation of > dummynet_io() could overflow that queue. > >>From the rest of your post it is not completely clear if you have > not found any working configuration, or there is some setting (e.g. > with "queue 1000" or larger) which do produce a smooth experience > for your customers. > Nope, I haven't been able to find it :( From as low as 50 to 2000 slots. I've also tried 1 and 2s worth queue sizes (in Kbytes). After about 8 p.m., when most users are online, speed problems are the most apparent. It all boils down to big differences between some subsequent "systat -if" reads, both for input and output, when dummynet is in use. It isn't normal for two reads to differ in as much as 100-150 mbps (20-25%). I can only hope that Intel's expensive 10 GigE cards have much larger tolerance to traffic load spikes, and are better suited for ISP usage patterns. > Another thing i'd like to understand is whether all of your pipes > have a /32 mask, or there are some which cover multiple hosts. > Typical TCP connections have around 50 packets in flight when the > connection is fully open (which in turn is hard to happen on a 512k > pipe) so a queue of 100-200 is unlikely to overflow. > > In fact, long queues are very detrimental for customers because > they increase the delay of the congestion control loop -- as a rule > of thumb, you should try to limit the queue size to at most 1-2s > of data. > > cheers > luigi > >> Traffic shaping is accomplished by this ipfw rule: >> pipe tablearg ip from any to table(0) out >> where table(0) contains those 5-6k IP addresses. The pipes themselves >> are GRED (or taildrop, it doesn't matter): >> ipfw pipe 512 config bw 512kbit/s mask dst-ip 0xffffffff gred >> 0.002/900/1000/0.1 queue 1000 >> Taking this template the speeds range from 512 to tens of mbps. With the >> setup as above very many users complain about very slow downloads, slow >> browsing. systat -ifstat, refreshed every 5 seconds, does reveal large >> differences between subsequent displays: if around 800-850 mbps is >> what's to be expected, it doesn't stay within those limits, also jumping >> to as low as 620+, and to somewhere in the 700's, Now imagine this: once >> I turn dummynet off (by short-circuiting a "allow ip from any to any" >> before the "pipe tablearg" rule) all user complaints stop, with traffic >> load staying stably at around 930-950 mbps. >> >> Does this have anything to do with "dummynet bursts"? How can I beat >> that? If I keep the pipe queue size at 2000 slots, the >> net.inet.ip.dummynet.io_pkt_drops sysctl stops increasing, once I start >> tweaking the value to as low as 100 slots, the value starts raising >> constantly at about 300-500 pps. I had hoped that smaller queue sizes >> would battle the negative effects of dummynet burstiness, it did so, I >> guess, but not in a very decisive manner. >> >> >> FreeBSD 7.1-RELEASE-p10 >> kern.hz=4000 >> kern.ipc.nmbclusters=111111 >> net.inet.ip.fastforwarding=1 >> net.inet.ip.dummynet.io_fast=1 >> net.isr.direct=0 >> net.inet.ip.intr_queue_maxlen=5000 >> net.inet.ip.dummynet.hash_size=512 >> net.inet.ip.dummynet.max_chain_len=16 >> >> net.inet.ip.intr_queue_drops: 0 >> systat -ip shows zero output drops at times of trouble. netstat -s's >> "output packets dropped due to no bufs, etc." is also fine. netstat -m >> shows nothing suspicious. >> >> p.s: Two "bloody expensive" Intel 10 GigE's are on their way to us to >> replace the Broadcom cards, meanwhile what should I try doing? Thanks >> for reading. >> _______________________________________________ >> 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 Tue Feb 23 10:34: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 021F61065670 for ; Tue, 23 Feb 2010 10:34:10 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 944F98FC13 for ; Tue, 23 Feb 2010 10:34:09 +0000 (UTC) Received: by mail-ww0-f54.google.com with SMTP id 22so726266wwb.13 for ; Tue, 23 Feb 2010 02:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=Xn6c+7fY3O1+n1jpCWXhZKWq9qtxueAbD69SJafQVlk=; b=cWOBoAvQVBnAPGjauHjBJ6A0BO7TJnq+tq5l0m6/tyHj372YVeA2TN03JUVK+/2nNV dxj2tNpFj1XCxiWqVdoMJxea+v02nZXqXO9kS+9RgRQiTQurFsBrYZPj0Wi07mMPoVaR o1zOgEiiF+Xkm/t+g0RW7sLXdnSDecHdUVtPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=u3rUc6rrPWMcRyTII5aIPPK0CH2wYl81En1eN58IUFV0hCnplriS8qPk+m1Ihkv1SB dhqqz1RkLyuxT9o5HsufzKHAHSML4a9cwKHX/fSdGoPz5o9gS865o+XCXYyWAsYS2Il2 UFHvvmX5z3Bbas0sjwsa0uj4ZwNDWpPRyFsLg= MIME-Version: 1.0 Received: by 10.216.87.13 with SMTP id x13mr1535094wee.12.1266921249265; Tue, 23 Feb 2010 02:34:09 -0800 (PST) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Date: Tue, 23 Feb 2010 11:33:49 +0100 Message-ID: <9a542da31002230233o24aa8db3nc77017fbe141a1fc@mail.gmail.com> To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: CSUM_TSO question... 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, 23 Feb 2010 10:34:10 -0000 Hello all, i was reading ip_output() code today and stumbled accross this http://fxr.watson.org/fxr/source/netinet/ip_output.c#L587. Can anybody shad any light on the check being done ? (m->m_pkthdr.csum_flags & ifp->if_hwassist & CSUM_TSO) != 0 || Shouldn't it be just (m->m_pkthdr.csum_flags & CSUM_TSO) != 0 || or it shold be (ifp->if_hwassist & CSUM_TSO) != 0 || while just a few lines above the following computation is done m->m_pkthdr.csum_flags &= ifp->if_hwassist; I am not sure how the compiler interprets it and it might be right though reading it is somewhat not clear what is going on. Is this correct? Regards, -- Ermal From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 11:10:58 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 AEF4F1065672 for ; Tue, 23 Feb 2010 11:10:58 +0000 (UTC) (envelope-from DAntrushin@mail.ru) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6CA8FC19 for ; Tue, 23 Feb 2010 11:10:58 +0000 (UTC) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1NBAvbR003593 for ; Tue, 23 Feb 2010 11:10:57 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYA00800JITZT00@fe-emea-09.sun.com> for freebsd-net@freebsd.org; Tue, 23 Feb 2010 11:10:52 +0000 (GMT) Received: from [129.159.126.126] ([unknown] [129.159.126.126]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYA0050XKDQB2C0@fe-emea-09.sun.com>; Tue, 23 Feb 2010 11:10:39 +0000 (GMT) Date: Tue, 23 Feb 2010 14:10:23 +0300 From: Denis Antrushin In-reply-to: <20100211125420.G27327@maildrop.int.zabbadoz.net> Sender: Denis.Antrushin@Sun.COM To: "Bjoern A. Zeeb" Message-id: <4B83B79F.102@mail.ru> References: <4B73E902.6050301@mail.ru> <20100211124756.GA9528@zeninc.net> <20100211125420.G27327@maildrop.int.zabbadoz.net> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.5) Gecko/20091202 Lightning/1.0pre Thunderbird/3.0 Cc: freebsd-net@freebsd.org Subject: Re: IPSec connection troubles 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, 23 Feb 2010 11:10:58 -0000 On 02/11/10 15:55, Bjoern A. Zeeb wrote: > On Thu, 11 Feb 2010, VANHULLEBUS Yvan wrote: > >>> How can I further debug this problem? >> >> You can check on responder that you have lots of TCP checksums errors, >> which will confirm that you would need support for NAT-OA extension of >> NAT-T RFC, as you want to do some Transport IPsec of TCP flows using >> NAT-T. >> >> Unfortunately, actually, there is no support for NAT-OA extension, >> there are just specifications on PFKey interface to send them to >> kernel. > > Him saying it works on linux - hsa ipsec-tools grown porper OA support > these days? If that would be the case the kernel would probably a > minor task. ipsec-tools understand NAT-OA payload in IKE exchange, but then simply discard it and do not send this information to kernel. In ipsec-tool mailing list archives I found mention that linux does not need this OA info, because it simply recomputes/ignore TCP checksums. Can we do the same or this is unacceptable for FreeBSD and we want NAT-OA communicated to kernel by IKEd? I made a simple patch to ipsec_common_input_cb() to ignore TCP/UDP checksums of ESP-protected packets and I happily can connect to Solaris VPN server from behind the NAT device (after working around some security policy matching issues). From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 12:00: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 85D36106566C for ; Tue, 23 Feb 2010 12:00:26 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 15A908FC0C for ; Tue, 23 Feb 2010 12:00:25 +0000 (UTC) Received: by fxm23 with SMTP id 23so3629924fxm.3 for ; Tue, 23 Feb 2010 04:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=8HC41V3DrtQyb2oYDAOk/kSuNjEfe8sJSgCtUL+IeIE=; b=QTK5IWJc9l/Qh4fSxAklCSVlJUtco7X3QhCprXBRytoXBfgfE38wkp61O2V1zBMiYm hLKQOXrYktQ5n+fpgbLE3+v6yX44ncSdcRjnKnp83QEmeYtw3TIIuqquvdy5+TVHVQFD VtKpbJMoOfexyxEIw/i0bdzcTOdyvYdP1ZtGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=cTl+1ZhOaU4wOxdgIj1EZLSb/V9U3wvn7DCEvLoe5IHForrbLek8jk5u4nByCKEaAt 0VIga6OGoncx2DVavgEeclF+3xz+af4+kfHsahpya84iSZrZ3+ItkHRMi1KWqiEBuT7D Nm/NSqgx3xWua9vaUjh0/j8wHAloxjuyUru4A= Received: by 10.103.67.25 with SMTP id u25mr5257740muk.107.1266926420042; Tue, 23 Feb 2010 04:00:20 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 23sm3188288mum.6.2010.02.23.04.00.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 04:00:18 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <0D51275610C0C04588FA911C811B687E02480269@be18.exg4.exghost.com> Date: Tue, 23 Feb 2010 12:00:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D51275610C0C04588FA911C811B687E02480269@be18.exg4.exghost.com> To: Jake Baillie X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org Subject: Re: xbox 360 + atheros 5212 connection issues 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, 23 Feb 2010 12:00:26 -0000 On 20 Feb 2010, at 21:55, Jake Baillie wrote: > Hello, >=20 > I'm having trouble getting an Xbox 360 to connect to my newly upgraded > FreeBSD based wireless access point. The Xbox 360 can successfully > locate the AP in a scan, but when trying to connect it simply fails. = If > you've never used an Xbox 360 before it is quite useless in reporting > debugging information, so all debugging will either have to come from > the FreeBSD box or perhaps another computer set to monitor mode. >=20 > I'd like to request some help in debugging this as I have no idea = where > to start. First try enabling hostapd debugging. Then use wlandebug and athdebug to help diagnosing net80211 problems and = ath problems, respectively. If that doesn't help, you need to look at the packet traces with = wireshark. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 12:01: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 CE88A106568D for ; Tue, 23 Feb 2010 12:01:37 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 5749A8FC2D for ; Tue, 23 Feb 2010 12:01:37 +0000 (UTC) Received: by fxm23 with SMTP id 23so3631478fxm.3 for ; Tue, 23 Feb 2010 04:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=ZHOgyF9bimvHnuwltlj0UTyFjjBeijk+ukrvV1jF/KE=; b=J02C98UFhPj/lVnzwwcn/QdpJZcrm9EHmUnvMWVzplGvPcIz/QdnMirY+o2xn3mrt8 DZ0BbGsOyWdNBjFatnsmB0s3bJ+gmt0OJ/94l/8nT1gkKdrriAhI65HLqnR57CIakoBd F+rO1gp5NDE9AeFC8TruRREKk4xzIf1VEnV/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=cAfBtWF9FIt4JZqGLPqEg6M3TY1SUM/H9/BfJUuLwo8xDaYXZ8C4notmF1bss5Xvji Ib7llsO2rQkNBtnN1QMp/gZBHTFh8DuNb2QlNL+ezZcAKRMLbSh1iBX2ZPvhdzAxU9pF OIH1gzQCE5x3um3aKEX0BRkRG+Dd8aoJK6vj8= Received: by 10.102.202.7 with SMTP id z7mr11658023muf.92.1266926494569; Tue, 23 Feb 2010 04:01:34 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id j2sm3174438mue.48.2010.02.23.04.01.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 04:01:30 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <2d3b7e441002210235q5c6de2bvaedfa460fcb0766e@mail.gmail.com> Date: Tue, 23 Feb 2010 12:01:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0FE9B65C-5612-411A-8EA8-24ABF57999BC@freebsd.org> References: <2d3b7e441002060028i5b1fc665p92b10fa21d77284d@mail.gmail.com> <8F5F80D8-A262-49F4-B580-781A44D3190D@freebsd.org> <2d3b7e441002060658h49712201m464dac80208db369@mail.gmail.com> <4B6DE491.8010901@errno.com> <2d3b7e441002070041waa8f968le66328ebeb7b163d@mail.gmail.com> <4B6F2A44.3010205@errno.com> <2d3b7e441002210235q5c6de2bvaedfa460fcb0766e@mail.gmail.com> To: Alexander Egorenkov X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org Subject: Re: HT rate set in net80211 not changeable for STA 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, 23 Feb 2010 12:01:37 -0000 On 21 Feb 2010, at 10:35, Alexander Egorenkov wrote: > This MCS32 HT rate causes problems with AMRR. If the connection = between a > client and an AP is very good and the AP supports MCS32, the client = keeps > increasing the Tx rate upto MCS32 and then the problems begin because = the > client starts to send with MCS32. Can you change the bitrate mask in the HTINFO information element? If = you say that you don't support MCS32, the AP shouldn't use it. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 12:12:54 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 7F9BD1065672; Tue, 23 Feb 2010 12:12:54 +0000 (UTC) (envelope-from egorenar@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id DCACA8FC15; Tue, 23 Feb 2010 12:12:53 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so846818eyd.9 for ; Tue, 23 Feb 2010 04:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IznPgTtdn/6Lh6eOkV07CESRuoXEPqVuOdKc/KSHyYM=; b=tvrA61J4/J6csRCIcBLVcHQZ3YqML0ERJ/nAuL9v7uy3OhMyPIgfE45u7OYkrme5n6 eNh7FpNf5ZgnYdAENp8Kx6AlO4YRNAvPaMa83fEB7viaUAGN0L4axRxGk6rrNsb/9UcD ayoQo/kjr7mpleQ5QhwoHR2b/0DLPU2NVDtmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rR2zPDVCmXa+1F1Ukw7trR6GXI+gch/8G5E8tG9pPiaLdTaIR357V5nqCzjmHIiXhv LtmlFvL5K/qyKFrC3TE/FnRJMozl2NsM3mCauDM8Ar1cFYOlw+1UdvSLOPZKQncbn1MM 1jazQgX7VI+hBPQoDQh2+a6kIiTUba4gHKaLk= MIME-Version: 1.0 Received: by 10.213.109.68 with SMTP id i4mr9920596ebp.43.1266927162854; Tue, 23 Feb 2010 04:12:42 -0800 (PST) In-Reply-To: <0FE9B65C-5612-411A-8EA8-24ABF57999BC@freebsd.org> References: <2d3b7e441002060028i5b1fc665p92b10fa21d77284d@mail.gmail.com> <8F5F80D8-A262-49F4-B580-781A44D3190D@freebsd.org> <2d3b7e441002060658h49712201m464dac80208db369@mail.gmail.com> <4B6DE491.8010901@errno.com> <2d3b7e441002070041waa8f968le66328ebeb7b163d@mail.gmail.com> <4B6F2A44.3010205@errno.com> <2d3b7e441002210235q5c6de2bvaedfa460fcb0766e@mail.gmail.com> <0FE9B65C-5612-411A-8EA8-24ABF57999BC@freebsd.org> Date: Tue, 23 Feb 2010 13:12:42 +0100 Message-ID: <2d3b7e441002230412n4df32e6dm872af957b368f816@mail.gmail.com> From: Alexander Egorenkov To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: HT rate set in net80211 not changeable for STA 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, 23 Feb 2010 12:12:54 -0000 The problem is not on the AP side, the client sends with MCS32 because it's the last MCS in ni_htrates array of AP and the connection is good. AMRR increases the Tx rate to AP till MCS32 and then the client sends with MCS32. I changed AMRR a bit so it would skip MCS32 and it works fine now. I had to change AMRR anyway, because ieee80211_amrr.c doesn't support HT nodes. On Tue, Feb 23, 2010 at 1:01 PM, Rui Paulo wrote: > On 21 Feb 2010, at 10:35, Alexander Egorenkov wrote: > > > This MCS32 HT rate causes problems with AMRR. If the connection between a > > client and an AP is very good and the AP supports MCS32, the client keeps > > increasing the Tx rate upto MCS32 and then the problems begin because the > > client starts to send with MCS32. > > Can you change the bitrate mask in the HTINFO information element? If you > say that you don't support MCS32, the AP shouldn't use it. > > -- > Rui Paulo > > From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 12:21:30 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 106261065692 for ; Tue, 23 Feb 2010 12:21:30 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id BC39A8FC17 for ; Tue, 23 Feb 2010 12:21:29 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id E008E2798BC; Tue, 23 Feb 2010 13:21:27 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id DEE8117050; Tue, 23 Feb 2010 13:21:27 +0100 (CET) Date: Tue, 23 Feb 2010 13:21:27 +0100 From: VANHULLEBUS Yvan To: Denis Antrushin Message-ID: <20100223122127.GA45649@zeninc.net> References: <4B73E902.6050301@mail.ru> <20100211124756.GA9528@zeninc.net> <20100211125420.G27327@maildrop.int.zabbadoz.net> <4B83B79F.102@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B83B79F.102@mail.ru> User-Agent: All mail clients suck. This one just sucks less. Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: IPSec connection troubles 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, 23 Feb 2010 12:21:30 -0000 On Tue, Feb 23, 2010 at 02:10:23PM +0300, Denis Antrushin wrote: [...] > ipsec-tools understand NAT-OA payload in IKE exchange, but then simply > discard it and do not send this information to kernel. > In ipsec-tool mailing list archives I found mention that linux does not > need this OA info, because it simply recomputes/ignore TCP checksums. Userland part is the most simple to do, as PFKey extension for NAT-OA already exists, it haven't been done so far because it's useless until someone does the big part of the kob on a kernel... > Can we do the same or this is unacceptable for FreeBSD and we want > NAT-OA communicated to kernel by IKEd? > I made a simple patch to ipsec_common_input_cb() to ignore TCP/UDP > checksums of ESP-protected packets and I happily can connect to > Solaris VPN server from behind the NAT device (after working around > some security policy matching issues). Just adding some code to always ignore such checksums sounds like a bad idea for me..... But maybe we could have at least a sysctl (disabled by default) to ignore them..... Yvan. From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 12:50: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 81928106566B; Tue, 23 Feb 2010 12:50:14 +0000 (UTC) (envelope-from DAntrushin@mail.ru) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by mx1.freebsd.org (Postfix) with ESMTP id 134A08FC1A; Tue, 23 Feb 2010 12:50:13 +0000 (UTC) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o1NCoCL8017849; Tue, 23 Feb 2010 12:50:13 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYA00300OLQFT00@fe-emea-10.sun.com>; Tue, 23 Feb 2010 12:50:12 +0000 (GMT) Received: from [129.159.126.126] ([unknown] [129.159.126.126]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYA0031GOZ968G0@fe-emea-10.sun.com>; Tue, 23 Feb 2010 12:49:58 +0000 (GMT) Date: Tue, 23 Feb 2010 15:49:42 +0300 From: Denis Antrushin In-reply-to: <20100223122127.GA45649@zeninc.net> Sender: Denis.Antrushin@Sun.COM To: VANHULLEBUS Yvan Message-id: <4B83CEE6.9040409@mail.ru> References: <4B73E902.6050301@mail.ru> <20100211124756.GA9528@zeninc.net> <20100211125420.G27327@maildrop.int.zabbadoz.net> <4B83B79F.102@mail.ru> <20100223122127.GA45649@zeninc.net> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.5) Gecko/20091202 Lightning/1.0pre Thunderbird/3.0 Cc: freebsd-net@freebsd.org Subject: Re: IPSec connection troubles 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, 23 Feb 2010 12:50:14 -0000 On 02/23/10 15:21, VANHULLEBUS Yvan wrote: > On Tue, Feb 23, 2010 at 02:10:23PM +0300, Denis Antrushin wrote: > [...] >> ipsec-tools understand NAT-OA payload in IKE exchange, but then simply >> discard it and do not send this information to kernel. >> In ipsec-tool mailing list archives I found mention that linux does not >> need this OA info, because it simply recomputes/ignore TCP checksums. > > Userland part is the most simple to do, as PFKey extension for NAT-OA > already exists, it haven't been done so far because it's useless until > someone does the big part of the kob on a kernel... Taking into account this quote: On 02/11/10 15:55, Bjoern A. Zeeb wrote: > Him saying it works on linux - has ipsec-tools grown proper OA support > these days? If that would be the case the kernel would probably a > minor task. this means that I have to come up with patches for both FreeBSD kernel and racoon at the same time. :-) May I contact you off-list with patches for both, when ready? As far as I understand, you are the one who can review both. >> Can we do the same or this is unacceptable for FreeBSD and we want >> NAT-OA communicated to kernel by IKEd? >> I made a simple patch to ipsec_common_input_cb() to ignore TCP/UDP >> checksums of ESP-protected packets and I happily can connect to >> Solaris VPN server from behind the NAT device (after working around >> some security policy matching issues). > > Just adding some code to always ignore such checksums sounds like a > bad idea for me..... > > But maybe we could have at least a sysctl (disabled by default) to > ignore them..... > > Yvan. From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 13:26: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 E47A81065670 for ; Tue, 23 Feb 2010 13:26:22 +0000 (UTC) (envelope-from voovoos-fnet@killfile.pl) Received: from mailhub.media4u.pl (mailhub.media4u.pl [194.79.24.10]) by mx1.freebsd.org (Postfix) with ESMTP id 83D9D8FC08 for ; Tue, 23 Feb 2010 13:26:22 +0000 (UTC) Received: from mail.media4u.pl ([194.79.24.11]:55772) by mailhub.media4u.pl with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NjuI6-000NF4-Rj; Tue, 23 Feb 2010 13:55:06 +0100 Received: from gw.media4u.net.pl ([194.79.25.15]:58484 helo=[192.168.9.33]) by mail.media4u.pl with esmtpa (Exim 4.63) (envelope-from ) id 1NjuI2-000JRn-Gf; Tue, 23 Feb 2010 13:55:03 +0100 Message-ID: <4B83D021.7020201@killfile.pl> Date: Tue, 23 Feb 2010 13:54:57 +0100 From: Maciej Wierzbicki Organization: =?UTF-8?B?xbt5amVteSB3IEtyYWp1IEN1ZG93bnljaCBNZXRhZm9y?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> In-Reply-To: <2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jack Vogel Subject: Re: Intel em0: watchdog timeout 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, 23 Feb 2010 13:26:23 -0000 Jack Vogel wrote on 2010-02-22 20:13: > 7.2 seems to be a stable base OS and driver, 8 is better in some respects, > but > has not been without its reported problems. I leave the choice to you. Let me sneak into this thread as I am also suffering from em watchdog timeouts. In my case there is a 7.2-release doing HAProxy LB for several webservers. But as far as I can tell, the watchdogs are not related to traffic rate: I can have low traffic rate near 50Mbps having timeouts every minute and I can have 200-300Mbps with long periods of time without timeouts, there is no visible regularity in that. em is built into kernel. Typical watchdog timeout log: Feb 22 21:21:31 CSBP kernel: em0: watchdog timeout -- resetting Feb 22 21:21:31 CSBP kernel: em0: link state changed to DOWN Feb 22 21:21:34 CSBP kernel: em0: link state changed to UP Feb 22 21:43:33 CSBP kernel: em0: watchdog timeout -- resetting Feb 22 21:43:33 CSBP kernel: em0: link state changed to DOWN Feb 22 21:43:36 CSBP kernel: em0: link state changed to UP OK, here is some data: FreeBSD 7.2-RELEASE-p5 #2: Thu Dec 10 14:21:26 CET 2009 kern.ipc.nmbclusters="262144" I never saw anything close to resource exhausting via netstat -m 5999/28441/34440 mbufs in use (current/cache/total) 3240/18468/21708/262144 mbuf clusters in use (current/cache/total/max) 3239/17881 mbuf+clusters out of packet secondary zone in use (current/cache) 2673/10297/12970/204800 4k (page size) jumbo clusters in use (current/cache/total/max) 18796K/85234K/104030K bytes allocated to network (current/cache/total) em0: port 0xa000-0xa01f mem 0xe9080000-0xe909ffff,0xe9000000-0xe907ffff,0xe90a0000-0xe90a3fff irq 16 at device 0.0 on pci2 em0: Using MSIX interrupts em1: port 0xb000-0xb01f mem 0xeb020000-0xeb03ffff,0xeb000000-0xeb01ffff irq 16 at device 0.0 on pci3 em1: Using MSI interrupt Feb 23 13:20:43 CSBP kernel: em0: Excessive collisions = 0 Feb 23 13:20:43 CSBP kernel: em0: Sequence errors = 0 Feb 23 13:20:43 CSBP kernel: em0: Defer count = 0 Feb 23 13:20:43 CSBP kernel: em0: Missed Packets = 3371167 Feb 23 13:20:43 CSBP kernel: em0: Receive No Buffers = 257 Feb 23 13:20:43 CSBP kernel: em0: Receive Length Errors = 1 Feb 23 13:20:43 CSBP kernel: em0: Receive errors = 0 Feb 23 13:20:43 CSBP kernel: em0: Crc errors = 0 Feb 23 13:20:43 CSBP kernel: em0: Alignment errors = 0 Feb 23 13:20:43 CSBP kernel: em0: Collision/Carrier extension errors = 0 Feb 23 13:20:43 CSBP kernel: em0: RX overruns = 416328 Feb 23 13:20:43 CSBP kernel: em0: watchdog timeouts = 1210 Feb 23 13:20:43 CSBP kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Feb 23 13:20:43 CSBP kernel: em0: XON Rcvd = 0 Feb 23 13:20:43 CSBP kernel: em0: XON Xmtd = 0 Feb 23 13:20:43 CSBP kernel: em0: XOFF Rcvd = 0 Feb 23 13:20:43 CSBP kernel: em0: XOFF Xmtd = 0 Feb 23 13:20:43 CSBP kernel: em0: Good Packets Rcvd = 9534885245 Feb 23 13:20:43 CSBP kernel: em0: Good Packets Xmtd = 12866598217 Feb 23 13:20:43 CSBP kernel: em0: TSO Contexts Xmtd = 3515091251 Feb 23 13:20:43 CSBP kernel: em0: TSO Contexts Failed = 0 Feb 23 13:21:14 CSBP kernel: em1: Excessive collisions = 0 Feb 23 13:21:14 CSBP kernel: em1: Sequence errors = 0 Feb 23 13:21:14 CSBP kernel: em1: Defer count = 0 Feb 23 13:21:14 CSBP kernel: em1: Missed Packets = 171 Feb 23 13:21:14 CSBP kernel: em1: Receive No Buffers = 1112 Feb 23 13:21:14 CSBP kernel: em1: Receive Length Errors = 0 Feb 23 13:21:14 CSBP kernel: em1: Receive errors = 0 Feb 23 13:21:14 CSBP kernel: em1: Crc errors = 0 Feb 23 13:21:14 CSBP kernel: em1: Alignment errors = 0 Feb 23 13:21:14 CSBP kernel: em1: Collision/Carrier extension errors = 0 Feb 23 13:21:14 CSBP kernel: em1: RX overruns = 5 Feb 23 13:21:14 CSBP kernel: em1: watchdog timeouts = 0 Feb 23 13:21:14 CSBP kernel: em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Feb 23 13:21:14 CSBP kernel: em1: XON Rcvd = 0 Feb 23 13:21:14 CSBP kernel: em1: XON Xmtd = 0 Feb 23 13:21:14 CSBP kernel: em1: XOFF Rcvd = 0 Feb 23 13:21:14 CSBP kernel: em1: XOFF Xmtd = 0 Feb 23 13:21:14 CSBP kernel: em1: Good Packets Rcvd = 11350337360 Feb 23 13:21:14 CSBP kernel: em1: Good Packets Xmtd = 9594728760 Feb 23 13:21:14 CSBP kernel: em1: TSO Contexts Xmtd = 30554321 Feb 23 13:21:14 CSBP kernel: em1: TSO Contexts Failed = 0 This is neither em0-hardware problem nor em0-type problem, because I tested both cases - I've used different em0 (the same model as my em1 above) with the same result. There is one additional thing I should write here: with current em0 card watchdog timeouts results in 1-2 minutes of non-responsive network, I mean when the watchdog occured, the box was not reachable for 1 to 2 minutes. I managed to lower 1-2 minutes of nonresponsive state to "acceptable" 2-3 seconds by this: kern.ipc.nmbjumbop=204800 When I put NIC of the same type as em1, the watchdogs still occurs, but the box is non-responsive for 2-3 seconds only "by default", without modifying kern.ipc.nmbjumbop. What else can I do (or report) to narrow the problem, or are there any patches I should try? :-) Thanks & regards -- * Maciej Wierzbicki * At paranoia's poison door * * VOO1-RIPE * From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 14:20: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 EA01A106566C for ; Tue, 23 Feb 2010 14:20:50 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id A1ED68FC13 for ; Tue, 23 Feb 2010 14:20:50 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id DDBDB2798BC; Tue, 23 Feb 2010 15:20:48 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id DEFCA1702D; Tue, 23 Feb 2010 15:20:48 +0100 (CET) Date: Tue, 23 Feb 2010 15:20:48 +0100 From: VANHULLEBUS Yvan To: Denis Antrushin Message-ID: <20100223142048.GA45899@zeninc.net> References: <4B73E902.6050301@mail.ru> <20100211124756.GA9528@zeninc.net> <20100211125420.G27327@maildrop.int.zabbadoz.net> <4B83B79F.102@mail.ru> <20100223122127.GA45649@zeninc.net> <4B83CEE6.9040409@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B83CEE6.9040409@mail.ru> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: IPSec connection troubles 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, 23 Feb 2010 14:20:51 -0000 On Tue, Feb 23, 2010 at 03:49:42PM +0300, Denis Antrushin wrote: > On 02/23/10 15:21, VANHULLEBUS Yvan wrote: [....] > Taking into account this quote: > > On 02/11/10 15:55, Bjoern A. Zeeb wrote: > > Him saying it works on linux - has ipsec-tools grown proper OA support > > these days? If that would be the case the kernel would probably a > > minor task. > > this means that I have to come up with patches for both FreeBSD kernel > and racoon at the same time. :-) > May I contact you off-list with patches for both, when ready? > As far as I understand, you are the one who can review both. Yes, but please keep Bjoern in CC of the mail, he'll probably also review at lest the kernel part. Yvan. From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 14:35:07 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 E6C9E1065679; Tue, 23 Feb 2010 14:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7A38F8FC12; Tue, 23 Feb 2010 14:35:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id DA6A541C795; Tue, 23 Feb 2010 15:35:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id T4Xw2ePbIRCt; Tue, 23 Feb 2010 15:35:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 807D341C759; Tue, 23 Feb 2010 15:35:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 48B694448EC; Tue, 23 Feb 2010 14:31:30 +0000 (UTC) Date: Tue, 23 Feb 2010 14:31:29 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: VANHULLEBUS Yvan In-Reply-To: <20100223142048.GA45899@zeninc.net> Message-ID: <20100223142839.K27327@maildrop.int.zabbadoz.net> References: <4B73E902.6050301@mail.ru> <20100211124756.GA9528@zeninc.net> <20100211125420.G27327@maildrop.int.zabbadoz.net> <4B83B79F.102@mail.ru> <20100223122127.GA45649@zeninc.net> <4B83CEE6.9040409@mail.ru> <20100223142048.GA45899@zeninc.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Denis Antrushin Subject: Re: IPSec connection troubles 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, 23 Feb 2010 14:35:08 -0000 On Tue, 23 Feb 2010, VANHULLEBUS Yvan wrote: Hi, > On Tue, Feb 23, 2010 at 03:49:42PM +0300, Denis Antrushin wrote: >> On 02/23/10 15:21, VANHULLEBUS Yvan wrote: > [....] >> Taking into account this quote: >> >> On 02/11/10 15:55, Bjoern A. Zeeb wrote: >>> Him saying it works on linux - has ipsec-tools grown proper OA support >>> these days? If that would be the case the kernel would probably a >>> minor task. >> >> this means that I have to come up with patches for both FreeBSD kernel >> and racoon at the same time. :-) >> May I contact you off-list with patches for both, when ready? >> As far as I understand, you are the one who can review both. > > Yes, but please keep Bjoern in CC of the mail, he'll probably also > review at lest the kernel part. Yeah, I should probably mention that if someone starts to generate patches, (s)he should make sure that the double-NAT scenario as described in the RFC will work as well from the beginning; else this will be kind of wasted efforts as someone would have to re-do the entire thing again. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 15:18:13 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 8D339106566B for ; Tue, 23 Feb 2010 15:18:13 +0000 (UTC) (envelope-from kirk.davis@epsb.ca) Received: from OWA01.EDU.epsb.ca (owa01.epsb.ca [198.161.119.28]) by mx1.freebsd.org (Postfix) with ESMTP id 530908FC12 for ; Tue, 23 Feb 2010 15:18:12 +0000 (UTC) Received: from Exchange26.EDU.epsb.ca ([10.0.5.123]) by OWA01.EDU.epsb.ca with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 08:18:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Feb 2010 08:18:10 -0700 Message-ID: <529374128DC1B04D9D037911B8E8F05301C17A5C@Exchange26.EDU.epsb.ca> In-Reply-To: <2a41acea1002221629vbe7548am7b5f1ba94d7efa9f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel em0: watchdog timeout Thread-Index: Acq0H09CJ2pslyrITF+rtwHvUtSTlwAe2S4A References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> <201002222107.o1ML7v3Z059734@lava.sentex.ca> <529374128DC1B04D9D037911B8E8F05301C17A56@Exchange26.EDU.epsb.ca> <2a41acea1002221444o6e449602m1830761b21837c41@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A57@Exchange26.EDU.epsb.ca> <2a41acea1002221629vbe7548am7b5f1ba94d7efa9f@mail.gmail.com> From: "Kirk Davis" To: "Jack Vogel" X-OriginalArrivalTime: 23 Feb 2010 15:18:12.0293 (UTC) FILETIME=[69E38750:01CAB49B] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: RE: Intel em0: watchdog timeout 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, 23 Feb 2010 15:18:13 -0000 The driver is static right now. I have another Dell 2950 for backup so I'm going to split the mirror on the production server and put one of the drives into the development server. Then I can do the upgrade to 7.2 and test. I don't think I will be able to get a window to switch out the production box until this weekend at the earliest. =20 How far behind is the driver in 7.2-RELEASE with any patches applied? Would this get me close enough to the latest driver? I'm not sure if I'm ready to go to 7.3-RC1 on my production server. =20 ----- Kirk ________________________________ From: Jack Vogel [mailto:jfvogel@gmail.com]=20 Sent: Monday, February 22, 2010 5:30 PM To: Kirk Davis Cc: Mike Tancsa; freebsd-net@freebsd.org Subject: Re: Intel em0: watchdog timeout =09 =09 Is your driver static, ie builtin, to the kernel, or do you load/unload it as a module? I ask because perhaps we could try a later driver, and being a module makes that easier.=20 =09 Jack =09 =09 =09 On Mon, Feb 22, 2010 at 3:37 PM, Kirk Davis wrote: =09 OK. I have the following in /boot/loader.conf (and rebooted) hw.em.rxd=3D1024 hw.em.txd=3D1024 =20 Should this be hw.em2.rxd? Is it set per interface or across all interfaces? =20 nmbcluster=3D262144 =20 # sysctl dev.em.2.stats=3D1 Feb 22 16:29:57 inet-gw kernel: em2: Defer count =3D 20 Feb 22 16:29:57 inet-gw kernel: em2: Missed Packets =3D 119947 =20 Feb 22 16:29:57 inet-gw kernel: em2: Receive No Buffers =3D 276762 Feb 22 16:29:57 inet-gw kernel: em2: Receive Length Errors =3D 0=20 Feb 22 16:29:57 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: RX overruns =3D 21 Feb 22 16:29:57 inet-gw kernel: em2: watchdog timeouts =3D 47 Feb 22 16:29:57 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: XON Rcvd =3D 22 Feb 22 16:29:57 inet-gw kernel: em2: XON Xmtd =3D 8349 Feb 22 16:29:57 inet-gw kernel: em2: XOFF Rcvd =3D 31 Feb 22 16:29:57 inet-gw kernel: em2: XOFF Xmtd =3D 15779 Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Rcvd =3D 966101852 Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Xmtd =3D 755993237 Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Failed =3D 0 =20 still seeing the watchdog timer and link up/down messages. =20 Should I try going higher than 1024 on the hw.em.rxd? I'm not sure the next time I can schedule another reboot on this production server. =20 ---- Kirk =20 Kirk Davis=20 Senior Network Analyst, ITS=20 Edmonton Public Schools=20 One Kingsway Ave.=20 Edmonton, Alberta, Canada=20 T5H 4G9=20 phone: 1-780-429-8308=20 =20 ________________________________ =09 From: Jack Vogel [mailto:jfvogel@gmail.com]=20 =09 Sent: Monday, February 22, 2010 3:45 PM To: Kirk Davis Cc: Mike Tancsa; freebsd-net@freebsd.org=20 Subject: Re: Intel em0: watchdog timeout =09 OK, so you are still failing to get mbufs in the RX side, increase the nmbcluster value, and then what size is your RX ring (number of rx descriptors)? =09 If you havent already done so, change that to 1024.=20 =09 I am developing a change in the RX code right now that will help this situation, but am doing so in the 10G driver, once its solid there I will be backporting it into the 1G drivers, it will make discards almost unnecessary. =09 Jack =09 =09 On Mon, Feb 22, 2010 at 1:43 PM, Kirk Davis wrote: =09 > -----Original Message----- > From: Mike Tancsa [mailto:mike@sentex.net] > Subject: Re: Intel em0: watchdog timeout > > At 03:46 PM 2/22/2010, Kirk Davis wrote: > >Does this need to be done in loader.conf? It doesn't seem > to take from > >the command line. > ># sysctl dev.em.2.stats=3D1 > >dev.em.2.stats: -1 -> -1 > > > ># sysctl dev.em.2.stats > >dev.em.2.stats: -1 > > Hi, > After you issue those commands, the driver will spit out a > lot of useful stats to syslog. It will report something like the > following in /var/log/messages > > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Sequence errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Defer count =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Missed Packets =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Crc errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Alignment errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier > extension errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: RX overruns =3D 0 > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts =3D 0 > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 > LINK MSIX IRQ =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd =3D 2559032551 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd =3D 1568751141 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed =3D 0 =09 =09 Thanks Mike and Jack. I don't know why I didn'ty notice the output in /var/log/messages =09 Here is the output for the two interfaces that are causing this issue. =09 Feb 22 13:33:52 inet-gw kernel: em0: Excessive collisions =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Sequence errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Defer count =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Missed Packets =3D 24296 Feb 22 13:33:52 inet-gw kernel: em0: Receive No Buffers =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive Length Errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Crc errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Alignment errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Collision/Carrier extension errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: RX overruns =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: watchdog timeouts =3D 6 Feb 22 13:33:52 inet-gw kernel: em0: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Rcvd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Rcvd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Rcvd =3D 424303810 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Xmtd =3D 576529136 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Failed =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:34:12 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:34:12 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:34:12 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:34:12 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:34:12 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:34:12 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Rcvd =3D 713607509 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Xmtd =3D 569694020 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Failed =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:35:10 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:35:10 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:35:10 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:35:10 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:35:10 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:35:10 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:35:10 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:35:10 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Rcvd =3D 715555016 Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Xmtd =3D 571157561 Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Failed =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:39:12 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:39:12 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:39:12 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:39:12 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:39:12 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:39:12 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:39:12 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:39:12 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Rcvd =3D 723521981 Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Xmtd =3D 577211431 Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Failed =3D 0 =09 =09 Can this be the problem? "Receive No Buffers =3D 275612" =09 ---- Kirk Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools One Kingsway Ave. Edmonton, Alberta, Canada T5H 4G9 =09 phone: 1-780-429-8308 =09 =09 =09 From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 17:24: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 0FF64106568D for ; Tue, 23 Feb 2010 17:24:52 +0000 (UTC) (envelope-from kirk.davis@epsb.ca) Received: from OWA01.EDU.epsb.ca (owa01.epsb.ca [198.161.119.28]) by mx1.freebsd.org (Postfix) with ESMTP id D3B7A8FC12 for ; Tue, 23 Feb 2010 17:24:51 +0000 (UTC) Received: from Exchange26.EDU.epsb.ca ([10.0.5.123]) by OWA01.EDU.epsb.ca with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 10:24:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 10:24:50 -0700 Message-ID: <529374128DC1B04D9D037911B8E8F05301C17A5D@Exchange26.EDU.epsb.ca> In-Reply-To: <4B83D021.7020201@killfile.pl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel em0: watchdog timeout Thread-Index: Acq0i9FAMUjgLyQSQjytekEtYevoFAAIBM8w References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca><2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <4B83D021.7020201@killfile.pl> From: "Kirk Davis" To: "Maciej Wierzbicki" X-OriginalArrivalTime: 23 Feb 2010 17:24:50.0928 (UTC) FILETIME=[1B073700:01CAB4AD] Cc: freebsd-net@freebsd.org, jfvogel@gmail.com Subject: RE: Intel em0: watchdog timeout 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, 23 Feb 2010 17:24:52 -0000 =20 > From: owner-freebsd-net@freebsd.org=20 >=20 > Jack Vogel wrote on 2010-02-22 20:13: >=20 > > 7.2 seems to be a stable base OS and driver, 8 is better in=20 > some respects, > > but > > has not been without its reported problems. I leave the=20 > choice to you. >=20 > Let me sneak into this thread as I am also suffering from em watchdog=20 > timeouts. In my case there is a 7.2-release doing HAProxy LB=20 > for several=20 > webservers. But as far as I can tell, the watchdogs are not=20 > related to=20 > traffic rate: I can have low traffic rate near 50Mbps having timeouts=20 > every minute and I can have 200-300Mbps with long periods of time=20 > without timeouts, there is no visible regularity in that. em is built=20 > into kernel. Typical watchdog timeout log: This doesn't sound good. I was just about to upgrade the box to 7.2 and see of the problem goes away with with the newer driver. :-/ I have come to the same conclusions about traffic rate. Since the watchdog=20 timeouts started, I have seen the problem at peak times but also in the=20 middle of the night when out traffic is very low. =20 > Feb 22 21:21:31 CSBP kernel: em0: watchdog timeout -- resetting > Feb 22 21:21:31 CSBP kernel: em0: link state changed to DOWN > Feb 22 21:21:34 CSBP kernel: em0: link state changed to UP > Feb 22 21:43:33 CSBP kernel: em0: watchdog timeout -- resetting > Feb 22 21:43:33 CSBP kernel: em0: link state changed to DOWN > Feb 22 21:43:36 CSBP kernel: em0: link state changed to UP >=20 > OK, here is some data: > FreeBSD 7.2-RELEASE-p5 #2: Thu Dec 10 14:21:26 CET 2009 > kern.ipc.nmbclusters=3D"262144" >=20 > I never saw anything close to resource exhausting via netstat -m > 5999/28441/34440 mbufs in use (current/cache/total) > 3240/18468/21708/262144 mbuf clusters in use (current/cache/total/max) > 3239/17881 mbuf+clusters out of packet secondary zone in use=20 > (current/cache) > 2673/10297/12970/204800 4k (page size) jumbo clusters in use=20 > (current/cache/total/max) > 18796K/85234K/104030K bytes allocated to network (current/cache/total) >=20 >=20 > em0: port=20 > 0xa000-0xa01f mem=20 > 0xe9080000-0xe909ffff,0xe9000000-0xe907ffff,0xe90a0000-0xe90a3 > fff irq 16=20 > at device 0.0 on pci2 > em0: Using MSIX interrupts > em1: port=20 > 0xb000-0xb01f mem=20 > 0xeb020000-0xeb03ffff,0xeb000000-0xeb01ffff irq 16 at device=20 > 0.0 on pci3 > em1: Using MSI interrupt >=20 > Feb 23 13:20:43 CSBP kernel: em0: Excessive collisions =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: Sequence errors =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: Defer count =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: Missed Packets =3D 3371167 > Feb 23 13:20:43 CSBP kernel: em0: Receive No Buffers =3D 257 > Feb 23 13:20:43 CSBP kernel: em0: Receive Length Errors =3D 1 > Feb 23 13:20:43 CSBP kernel: em0: Receive errors =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: Crc errors =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: Alignment errors =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: Collision/Carrier extension=20 > errors =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: RX overruns =3D 416328 > Feb 23 13:20:43 CSBP kernel: em0: watchdog timeouts =3D 1210 > Feb 23 13:20:43 CSBP kernel: em0: RX MSIX IRQ =3D 0 TX MSIX IRQ=20 > =3D 0 LINK=20 > MSIX IRQ =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: XON Rcvd =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: XON Xmtd =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: XOFF Rcvd =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: XOFF Xmtd =3D 0 > Feb 23 13:20:43 CSBP kernel: em0: Good Packets Rcvd =3D 9534885245 > Feb 23 13:20:43 CSBP kernel: em0: Good Packets Xmtd =3D 12866598217 > Feb 23 13:20:43 CSBP kernel: em0: TSO Contexts Xmtd =3D 3515091251 > Feb 23 13:20:43 CSBP kernel: em0: TSO Contexts Failed =3D 0 >=20 > Feb 23 13:21:14 CSBP kernel: em1: Excessive collisions =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: Sequence errors =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: Defer count =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: Missed Packets =3D 171 > Feb 23 13:21:14 CSBP kernel: em1: Receive No Buffers =3D 1112 > Feb 23 13:21:14 CSBP kernel: em1: Receive Length Errors =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: Receive errors =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: Crc errors =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: Alignment errors =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: Collision/Carrier extension=20 > errors =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: RX overruns =3D 5 > Feb 23 13:21:14 CSBP kernel: em1: watchdog timeouts =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: RX MSIX IRQ =3D 0 TX MSIX IRQ=20 > =3D 0 LINK=20 > MSIX IRQ =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: XON Rcvd =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: XON Xmtd =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: XOFF Rcvd =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: XOFF Xmtd =3D 0 > Feb 23 13:21:14 CSBP kernel: em1: Good Packets Rcvd =3D 11350337360 > Feb 23 13:21:14 CSBP kernel: em1: Good Packets Xmtd =3D 9594728760 > Feb 23 13:21:14 CSBP kernel: em1: TSO Contexts Xmtd =3D 30554321 > Feb 23 13:21:14 CSBP kernel: em1: TSO Contexts Failed =3D 0 >=20 > This is neither em0-hardware problem nor em0-type problem, because I=20 > tested both cases - I've used different em0 (the same model as my em1=20 > above) with the same result. >=20 > There is one additional thing I should write here: with=20 > current em0 card=20 > watchdog timeouts results in 1-2 minutes of non-responsive network, I=20 > mean when the watchdog occured, the box was not reachable for 1 to 2=20 > minutes. I managed to lower 1-2 minutes of nonresponsive state to=20 > "acceptable" 2-3 seconds by this: kern.ipc.nmbjumbop=3D204800 I have not tried this. Our outages are very quick, so quick in fact that the BGP instance running in the box doesn't notice. I have seen one or=20 two times that it has lasted up to a min. but most of the time it is very fast. >=20 > When I put NIC of the same type as em1, the watchdogs still=20 > occurs, but=20 > the box is non-responsive for 2-3 seconds only "by default", without=20 > modifying kern.ipc.nmbjumbop. >=20 > What else can I do (or report) to narrow the problem, or are=20 > there any=20 > patches I should try? :-) >=20 > Thanks & regards > --=20 ---- Kirk=20 From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 19:02:49 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 553C0106568B for ; Tue, 23 Feb 2010 19:02:49 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 19C198FC0C for ; Tue, 23 Feb 2010 19:02:48 +0000 (UTC) Received: from mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o1NJ6bKj013357; Tue, 23 Feb 2010 11:06:38 -0800 (PST) (envelope-from mahan@mahan.org) To: David Hayes In-reply-to: <20100219061725.GA91121@dhayes.caia.swin.edu.au> References: <20100219061725.GA91121@dhayes.caia.swin.edu.au> Comments: In-reply-to David Hayes message dated "Fri, 19 Feb 2010 17:17:25 +1100." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Tue, 23 Feb 2010 11:02:35 -0800 Message-ID: <3627.1266951755@mahan.org> From: Patrick Mahan Cc: freebsd-net@freebsd.org, grenville armitage , iccrg@cs.ucl.ac.uk, end2end-interest@postel.org, Lawrence Stewart Subject: Re: 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, 23 Feb 2010 19:02:49 -0000 > >[12] http://caia.swin.edu.au/newtcp/tools/caia_modularcc_v0.9.4_9.x.r203910.patch > >[13] http://caia.swin.edu.au/newtcp/tools/modularcc-readme-0.9.4.txt > I believe these are incorrect. I find these documents at the following URLs: [12] http://caia.swin.edu.au/urp/newtcp/tools/caia_modularcc_v0.9.4_9.x.r203910.patch [13] http://caia.swin.edu.au/urp/newtcp/tools/modularcc-readme-0.9.4.txt Thanks, Patrick From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 20:38:33 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 20A20106566B for ; Tue, 23 Feb 2010 20:38:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id C1EA78FC15 for ; Tue, 23 Feb 2010 20:38:32 +0000 (UTC) Received: (qmail 30324 invoked by uid 399); 23 Feb 2010 20:38:32 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Feb 2010 20:38:32 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B843CC7.1000700@FreeBSD.org> Date: Tue, 23 Feb 2010 12:38:31 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Apparent IPv6 bug 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, 23 Feb 2010 20:38:33 -0000 Howdy, I've had the following crash twice now when leaving my system up overnight: (kgdb) #0 doadump () at pcpu.h:246 #1 0xc05f64af in boot (howto=260) at /usr/local/src/sys/kern/kern_shutdown.c:416 #2 0xc05f6792 in panic (fmt=Variable "fmt" is not available. ) at /usr/local/src/sys/kern/kern_shutdown.c:579 #3 0xc05e7dfa in _mtx_lock_sleep (m=0xc5e69e28, tid=3314788032, opts=0, file=0xc08f2e6b "/usr/local/src/sys/netinet6/in6.c", line=827) at /usr/local/src/sys/kern/kern_mutex.c:341 #4 0xc05e7ff1 in _mtx_lock_flags (m=0xc5e69e28, opts=0, file=0xc08f2e6b "/usr/local/src/sys/netinet6/in6.c", line=827) at /usr/local/src/sys/kern/kern_mutex.c:203 #5 0xc077829d in in6_update_ifa (ifp=0xc5e69c00, ifra=0xc5606b70, ia=0xc8d41800, flags=0) at /usr/local/src/sys/netinet6/in6.c:827 #6 0xc07961ec in in6_tmpifadd (ia0=0xc5e90200, forcegen=0, delay=0) at /usr/local/src/sys/netinet6/nd6_rtr.c:2007 #7 0xc079009c in regen_tmpaddr (ia6=0xc5e90000) at /usr/local/src/sys/netinet6/nd6.c:772 #8 0xc07916d5 in nd6_timer (arg=0x0) at /usr/local/src/sys/netinet6/nd6.c:666 #9 0xc06097ea in softclock (arg=0xc0987dc0) at /usr/local/src/sys/kern/kern_timeout.c:430 #10 0xc05cfd95 in intr_event_execute_handlers (p=0xc5938aa0, ie=0xc593d600) at /usr/local/src/sys/kern/kern_intr.c:1220 #11 0xc05d0b6f in ithread_loop (arg=0xc58ddb60) at /usr/local/src/sys/kern/kern_intr.c:1233 #12 0xc05cdb28 in fork_exit (callout=0xc05d0ad0 , arg=0xc58ddb60, frame=0xc5606d38) at /usr/local/src/sys/kern/kern_fork.c:843 #13 0xc0849af0 in fork_trampoline () at /usr/local/src/sys/i386/i386/exception.s:270 (kgdb) The full core.txt.1 file is in my home dir on freefall. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 21:54: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 3D556106566B for ; Tue, 23 Feb 2010 21:54:53 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 5610A8FC12 for ; Tue, 23 Feb 2010 21:54:51 +0000 (UTC) Received: from [127.0.0.1] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id o1NLAGAp000747; Wed, 24 Feb 2010 08:10:33 +1100 Message-ID: <4B844413.6080303@swin.edu.au> Date: Wed, 24 Feb 2010 08:09:39 +1100 From: grenville armitage User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Patrick Mahan References: <20100219061725.GA91121@dhayes.caia.swin.edu.au> <3627.1266951755@mahan.org> In-Reply-To: <3627.1266951755@mahan.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Lawrence Stewart , iccrg@cs.ucl.ac.uk, David Hayes , end2end-interest@postel.org Subject: Re: 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, 23 Feb 2010 21:54:53 -0000 On 24/02/2010 6:02 AM, Patrick Mahan wrote: >> [12] http://caia.swin.edu.au/newtcp/tools/caia_modularcc_v0.9.4_9.x.r203910.patch >> >> [13] http://caia.swin.edu.au/newtcp/tools/modularcc-readme-0.9.4.txt >> > > I believe these are incorrect. I find these documents at the following URLs: > > [12] http://caia.swin.edu.au/urp/newtcp/tools/caia_modularcc_v0.9.4_9.x.r203910.patch > [13] http://caia.swin.edu.au/urp/newtcp/tools/modularcc-readme-0.9.4.txt Good catch. Very embarrassing. Since the URLs are now stored in a bunch of mailing list archives, I've linked http://caia.swin.edu.au/newtcp/ to http://caia.swin.edu.au/urp/newtcp/ to make the wrong URLs work. cheers, gja From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 22:10:07 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 310AE1065672; Tue, 23 Feb 2010 22:10:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id E41F08FC1A; Tue, 23 Feb 2010 22:10:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 5060C41C795; Tue, 23 Feb 2010 23:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id uCn6X3nswgYW; Tue, 23 Feb 2010 23:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id A958F41C75E; Tue, 23 Feb 2010 23:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 8C0BE4448EC; Tue, 23 Feb 2010 22:05:46 +0000 (UTC) Date: Tue, 23 Feb 2010 22:05:46 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Doug Barton In-Reply-To: <4B843CC7.1000700@FreeBSD.org> Message-ID: <20100223220214.V27327@maildrop.int.zabbadoz.net> References: <4B843CC7.1000700@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: Apparent IPv6 bug 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, 23 Feb 2010 22:10:07 -0000 On Tue, 23 Feb 2010, Doug Barton wrote: > Howdy, > > I've had the following crash twice now when leaving my system up overnight: > Could it be that some interface goes and comes over night? A tunnel or some such? If that's the case you may want to try: http://people.freebsd.org/~bz/20100215-10-sys-net-if_llatbl-v6.diff and in case you are using flowtable as well you may want the patches I had posted and marked with (*) in the thread "mpd has hung" on net@. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 22:15:07 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 C6D67106566B; Tue, 23 Feb 2010 22:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 846458FC1C; Tue, 23 Feb 2010 22:15:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 90E1E41C759; Tue, 23 Feb 2010 23:15:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id hHa-mM0lSFQ9; Tue, 23 Feb 2010 23:15:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E06FD41C758; Tue, 23 Feb 2010 23:15:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id DBCA34448EC; Tue, 23 Feb 2010 22:14:01 +0000 (UTC) Date: Tue, 23 Feb 2010 22:14:01 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Doug Barton In-Reply-To: <20100223220214.V27327@maildrop.int.zabbadoz.net> Message-ID: <20100223220849.F27327@maildrop.int.zabbadoz.net> References: <4B843CC7.1000700@FreeBSD.org> <20100223220214.V27327@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: Apparent IPv6 bug 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, 23 Feb 2010 22:15:07 -0000 On Tue, 23 Feb 2010, Bjoern A. Zeeb wrote: > On Tue, 23 Feb 2010, Doug Barton wrote: > >> Howdy, >> >> I've had the following crash twice now when leaving my system up overnight: >> > > Could it be that some interface goes and comes over night? > A tunnel or some such? > > If that's the case you may want to try: > > http://people.freebsd.org/~bz/20100215-10-sys-net-if_llatbl-v6.diff > > and in case you are using flowtable as well you may want the patches I > had posted and marked with (*) in the thread "mpd has hung" on net@. Baeh, just ignore me. I was looking at the wrong backtrace after I had switched desktops. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 22:26:45 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 25E77106566C for ; Tue, 23 Feb 2010 22:26:45 +0000 (UTC) (envelope-from kirk.davis@epsb.ca) Received: from Exchange22.EDU.epsb.ca (exchange22.epsb.ca [198.161.119.187]) by mx1.freebsd.org (Postfix) with ESMTP id E3DC78FC16 for ; Tue, 23 Feb 2010 22:26:44 +0000 (UTC) Received: from Exchange26.EDU.epsb.ca ([10.0.5.123]) by Exchange22.EDU.epsb.ca with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 15:26:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Feb 2010 15:26:43 -0700 Message-ID: <529374128DC1B04D9D037911B8E8F05301C17A5F@Exchange26.EDU.epsb.ca> In-Reply-To: <2a41acea1002221629vbe7548am7b5f1ba94d7efa9f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel em0: watchdog timeout Thread-Index: Acq0H09CJ2pslyrITF+rtwHvUtSTlwAtkVXw References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> <201002222107.o1ML7v3Z059734@lava.sentex.ca> <529374128DC1B04D9D037911B8E8F05301C17A56@Exchange26.EDU.epsb.ca> <2a41acea1002221444o6e449602m1830761b21837c41@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A57@Exchange26.EDU.epsb.ca> <2a41acea1002221629vbe7548am7b5f1ba94d7efa9f@mail.gmail.com> From: "Kirk Davis" To: "Jack Vogel" X-OriginalArrivalTime: 23 Feb 2010 22:26:44.0150 (UTC) FILETIME=[47598D60:01CAB4D7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, voovoos-fnet@killfile.pl, Mike Tancsa Subject: RE: Intel em0: watchdog timeout 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, 23 Feb 2010 22:26:45 -0000 Hi, Looks like I may have tracked down this problem. =20 =20 I noticed that fastforwarding ( net.inet.ip.fastforwarding=3D1 ) was turned on. I turned it off to see if that was causing the problem. Sure enough, 5 hours later and no watchdog timeouts. This is still running on FreeBSD 7.1 (I'm still planning to move to 7.2 soon). I read up on the net.inet.ip.fastforwarding sysctl and it doesn't look like it should cause any problems with the intel NIC driver. This may need to be looked at and tested by some one more knowledgeable with the networking code than I am. =20 Thanks to Jack and Mike for your help. =20 =20 ---- Kirk Kirk Davis=20 Senior Network Analyst, ITS=20 Edmonton Public Schools=20 One Kingsway Ave.=20 Edmonton, Alberta, Canada=20 T5H 4G9=20 ________________________________ From: Jack Vogel [mailto:jfvogel@gmail.com]=20 Sent: Monday, February 22, 2010 5:30 PM To: Kirk Davis Cc: Mike Tancsa; freebsd-net@freebsd.org Subject: Re: Intel em0: watchdog timeout =09 =09 Is your driver static, ie builtin, to the kernel, or do you load/unload it as a module? I ask because perhaps we could try a later driver, and being a module makes that easier.=20 =09 Jack =09 =09 =09 On Mon, Feb 22, 2010 at 3:37 PM, Kirk Davis wrote: =09 OK. I have the following in /boot/loader.conf (and rebooted) hw.em.rxd=3D1024 hw.em.txd=3D1024 =20 Should this be hw.em2.rxd? Is it set per interface or across all interfaces? =20 nmbcluster=3D262144 =20 # sysctl dev.em.2.stats=3D1 Feb 22 16:29:57 inet-gw kernel: em2: Defer count =3D 20 Feb 22 16:29:57 inet-gw kernel: em2: Missed Packets =3D 119947 =20 Feb 22 16:29:57 inet-gw kernel: em2: Receive No Buffers =3D 276762 Feb 22 16:29:57 inet-gw kernel: em2: Receive Length Errors =3D 0=20 Feb 22 16:29:57 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: RX overruns =3D 21 Feb 22 16:29:57 inet-gw kernel: em2: watchdog timeouts =3D 47 Feb 22 16:29:57 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: XON Rcvd =3D 22 Feb 22 16:29:57 inet-gw kernel: em2: XON Xmtd =3D 8349 Feb 22 16:29:57 inet-gw kernel: em2: XOFF Rcvd =3D 31 Feb 22 16:29:57 inet-gw kernel: em2: XOFF Xmtd =3D 15779 Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Rcvd =3D 966101852 Feb 22 16:29:57 inet-gw kernel: em2: Good Packets Xmtd =3D 755993237 Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 16:29:57 inet-gw kernel: em2: TSO Contexts Failed =3D 0 =20 still seeing the watchdog timer and link up/down messages. =20 Should I try going higher than 1024 on the hw.em.rxd? I'm not sure the next time I can schedule another reboot on this production server. =20 ---- Kirk =20 Kirk Davis=20 Senior Network Analyst, ITS=20 Edmonton Public Schools=20 One Kingsway Ave.=20 Edmonton, Alberta, Canada=20 T5H 4G9=20 phone: 1-780-429-8308=20 =20 ________________________________ =09 From: Jack Vogel [mailto:jfvogel@gmail.com]=20 =09 Sent: Monday, February 22, 2010 3:45 PM To: Kirk Davis Cc: Mike Tancsa; freebsd-net@freebsd.org=20 Subject: Re: Intel em0: watchdog timeout =09 OK, so you are still failing to get mbufs in the RX side, increase the nmbcluster value, and then what size is your RX ring (number of rx descriptors)? =09 If you havent already done so, change that to 1024.=20 =09 I am developing a change in the RX code right now that will help this situation, but am doing so in the 10G driver, once its solid there I will be backporting it into the 1G drivers, it will make discards almost unnecessary. =09 Jack =09 =09 On Mon, Feb 22, 2010 at 1:43 PM, Kirk Davis wrote: =09 > -----Original Message----- > From: Mike Tancsa [mailto:mike@sentex.net] > Subject: Re: Intel em0: watchdog timeout > > At 03:46 PM 2/22/2010, Kirk Davis wrote: > >Does this need to be done in loader.conf? It doesn't seem > to take from > >the command line. > ># sysctl dev.em.2.stats=3D1 > >dev.em.2.stats: -1 -> -1 > > > ># sysctl dev.em.2.stats > >dev.em.2.stats: -1 > > Hi, > After you issue those commands, the driver will spit out a > lot of useful stats to syslog. It will report something like the > following in /var/log/messages > > Feb 22 16:06:31 offsite kernel: em0: Excessive collisions =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Sequence errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Defer count =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Missed Packets =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive No Buffers =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive Length Errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Receive errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Crc errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Alignment errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Collision/Carrier > extension errors =3D 0 > Feb 22 16:06:31 offsite kernel: em0: RX overruns =3D 0 > Feb 22 16:06:31 offsite kernel: em0: watchdog timeouts =3D 0 > Feb 22 16:06:31 offsite kernel: em0: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 > LINK MSIX IRQ =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XON Rcvd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XON Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Rcvd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: XOFF Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Rcvd =3D 2559032551 > Feb 22 16:06:31 offsite kernel: em0: Good Packets Xmtd =3D 1568751141 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Xmtd =3D 0 > Feb 22 16:06:31 offsite kernel: em0: TSO Contexts Failed =3D 0 =09 =09 Thanks Mike and Jack. I don't know why I didn'ty notice the output in /var/log/messages =09 Here is the output for the two interfaces that are causing this issue. =09 Feb 22 13:33:52 inet-gw kernel: em0: Excessive collisions =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Sequence errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Defer count =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Missed Packets =3D 24296 Feb 22 13:33:52 inet-gw kernel: em0: Receive No Buffers =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive Length Errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Receive errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Crc errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Alignment errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Collision/Carrier extension errors =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: RX overruns =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: watchdog timeouts =3D 6 Feb 22 13:33:52 inet-gw kernel: em0: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Rcvd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XON Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Rcvd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: XOFF Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Rcvd =3D 424303810 Feb 22 13:33:52 inet-gw kernel: em0: Good Packets Xmtd =3D 576529136 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Xmtd =3D 0 Feb 22 13:33:52 inet-gw kernel: em0: TSO Contexts Failed =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:34:12 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:34:12 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:34:12 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:34:12 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:34:12 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:34:12 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:34:12 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Rcvd =3D 713607509 Feb 22 13:34:12 inet-gw kernel: em2: Good Packets Xmtd =3D 569694020 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:34:12 inet-gw kernel: em2: TSO Contexts Failed =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:35:10 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:35:10 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:35:10 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:35:10 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:35:10 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:35:10 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:35:10 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:35:10 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Rcvd =3D 715555016 Feb 22 13:35:10 inet-gw kernel: em2: Good Packets Xmtd =3D 571157561 Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:35:10 inet-gw kernel: em2: TSO Contexts Failed =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Excessive collisions =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Sequence errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Defer count =3D 20 Feb 22 13:39:12 inet-gw kernel: em2: Missed Packets =3D 68059 Feb 22 13:39:12 inet-gw kernel: em2: Receive No Buffers =3D 275612 Feb 22 13:39:12 inet-gw kernel: em2: Receive Length Errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Receive errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Crc errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Alignment errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: Collision/Carrier extension errors =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: RX overruns =3D 17 Feb 22 13:39:12 inet-gw kernel: em2: watchdog timeouts =3D 38 Feb 22 13:39:12 inet-gw kernel: em2: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: XON Rcvd =3D 21 Feb 22 13:39:12 inet-gw kernel: em2: XON Xmtd =3D 8344 Feb 22 13:39:12 inet-gw kernel: em2: XOFF Rcvd =3D 30 Feb 22 13:39:12 inet-gw kernel: em2: XOFF Xmtd =3D 9159 Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Rcvd =3D 723521981 Feb 22 13:39:12 inet-gw kernel: em2: Good Packets Xmtd =3D 577211431 Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Xmtd =3D 0 Feb 22 13:39:12 inet-gw kernel: em2: TSO Contexts Failed =3D 0 =09 =09 Can this be the problem? "Receive No Buffers =3D 275612" =09 ---- Kirk Kirk Davis Senior Network Analyst, ITS Edmonton Public Schools One Kingsway Ave. Edmonton, Alberta, Canada T5H 4G9 =09 phone: 1-780-429-8308 =09 =09 =09 From owner-freebsd-net@FreeBSD.ORG Tue Feb 23 22:46: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 7E3F31065692; Tue, 23 Feb 2010 22:46:11 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8FB8FC18; Tue, 23 Feb 2010 22:46:11 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1NMkA96016744; Tue, 23 Feb 2010 14:46:10 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 14:44:06 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Apparent IPv6 bug Thread-Index: Acq00CYafhiMh9asQQWgcA4Yv6vncwACY7B5 References: <4B843CC7.1000700@FreeBSD.org> From: "Li, Qing" To: "Doug Barton" , Cc: Subject: RE: Apparent IPv6 bug 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, 23 Feb 2010 22:46:11 -0000 Okay, I read through your core file and I think I see the problem now.=20 Let me try to get you a patch later tonight. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Doug Barton Sent: Tue 2/23/2010 12:38 PM To: freebsd-net@freebsd.org Subject: Apparent IPv6 bug =20 Howdy, I've had the following crash twice now when leaving my system up = overnight: (kgdb) #0 doadump () at pcpu.h:246 #1 0xc05f64af in boot (howto=3D260) at /usr/local/src/sys/kern/kern_shutdown.c:416 #2 0xc05f6792 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/local/src/sys/kern/kern_shutdown.c:579 #3 0xc05e7dfa in _mtx_lock_sleep (m=3D0xc5e69e28, tid=3D3314788032, = opts=3D0, file=3D0xc08f2e6b "/usr/local/src/sys/netinet6/in6.c", line=3D827) at /usr/local/src/sys/kern/kern_mutex.c:341 #4 0xc05e7ff1 in _mtx_lock_flags (m=3D0xc5e69e28, opts=3D0, file=3D0xc08f2e6b "/usr/local/src/sys/netinet6/in6.c", line=3D827) at /usr/local/src/sys/kern/kern_mutex.c:203 #5 0xc077829d in in6_update_ifa (ifp=3D0xc5e69c00, ifra=3D0xc5606b70, ia=3D0xc8d41800, flags=3D0) at /usr/local/src/sys/netinet6/in6.c:827 #6 0xc07961ec in in6_tmpifadd (ia0=3D0xc5e90200, forcegen=3D0, = delay=3D0) at /usr/local/src/sys/netinet6/nd6_rtr.c:2007 #7 0xc079009c in regen_tmpaddr (ia6=3D0xc5e90000) at /usr/local/src/sys/netinet6/nd6.c:772 #8 0xc07916d5 in nd6_timer (arg=3D0x0) at /usr/local/src/sys/netinet6/nd6.c:666 #9 0xc06097ea in softclock (arg=3D0xc0987dc0) at /usr/local/src/sys/kern/kern_timeout.c:430 #10 0xc05cfd95 in intr_event_execute_handlers (p=3D0xc5938aa0, = ie=3D0xc593d600) at /usr/local/src/sys/kern/kern_intr.c:1220 #11 0xc05d0b6f in ithread_loop (arg=3D0xc58ddb60) at /usr/local/src/sys/kern/kern_intr.c:1233 #12 0xc05cdb28 in fork_exit (callout=3D0xc05d0ad0 , arg=3D0xc58ddb60, frame=3D0xc5606d38) at /usr/local/src/sys/kern/kern_fork.c:843 #13 0xc0849af0 in fork_trampoline () at /usr/local/src/sys/i386/i386/exception.s:270 (kgdb) The full core.txt.1 file is in my home dir on freefall. Doug --=20 ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ 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 Feb 24 08:40:04 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 2490B106566B for ; Wed, 24 Feb 2010 08:40:04 +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 ED3388FC13 for ; Wed, 24 Feb 2010 08:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1O8e3IQ055986 for ; Wed, 24 Feb 2010 08:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1O8e3d7055985; Wed, 24 Feb 2010 08:40:03 GMT (envelope-from gnats) Date: Wed, 24 Feb 2010 08:40:03 GMT Message-Id: <201002240840.o1O8e3d7055985@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jean-Luc Richier Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jean-Luc Richier List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 08:40:04 -0000 The following reply was made to PR kern/141843; it has been noted by GNATS. From: Jean-Luc Richier To: bug-followup@FreeBSD.org, dyr@smartspb.net Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets Date: Wed, 24 Feb 2010 09:19:29 +0100 A other cause (or the same) seems that when the interface is reset (for example with a ifconfig em0 down, the chip is reset, but the last_hw_offload in the interface context is not reset I just had the following problem in FreeBSD8.0 RELEASE # ping www.google.com It works # ifconfig em0 down up # ping www.google.com It does not work # telnet -N Normal error message # ping www.google.com It works I made the following path to solve the problem (in em_stop): --- /sys/dev/e1000/if_em.c.DIST 2009-10-25 02:10:29.000000000 +0100 +++ /sys/dev/e1000/if_em.c 2010-02-23 18:22:53.000000000 +0100 @@ -2710,6 +2710,7 @@ ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); e1000_reset_hw(&adapter->hw); + adapter->last_hw_offload = 0; if (adapter->hw.mac.type >= e1000_82544) E1000_WRITE_REG(&adapter->hw, E1000_WUC, 0); } -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr) Laboratoire d'Informatique de Grenoble (LIG) Campus de Grenoble 681 rue de la Passerelle BP 72, F-38402 St Martin d'Hères Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 From owner-freebsd-net@FreeBSD.ORG Wed Feb 24 09:40: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 33168106566C for ; Wed, 24 Feb 2010 09:40:03 +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 074EE8FC08 for ; Wed, 24 Feb 2010 09:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1O9e2BF007073 for ; Wed, 24 Feb 2010 09:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1O9e2us007072; Wed, 24 Feb 2010 09:40:02 GMT (envelope-from gnats) Date: Wed, 24 Feb 2010 09:40:02 GMT Message-Id: <201002240940.o1O9e2us007072@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jean-Luc Richier Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jean-Luc Richier List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 09:40:03 -0000 The following reply was made to PR kern/141843; it has been noted by GNATS. From: Jean-Luc Richier To: bug-followup@FreeBSD.org, dyr@smartspb.net Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets Date: Wed, 24 Feb 2010 10:35:01 +0100 Jean-Luc Richier wrote: > A other cause (or the same) seems that when the interface is reset (for example with a ifconfig em0 down, the chip is reset, but the > last_hw_offload in the interface context is not reset .... > I made the following path to solve the problem (in em_stop) > --- /sys/dev/e1000/if_em.c.DIST 2009-10-25 02:10:29.000000000 +0100 > +++ /sys/dev/e1000/if_em.c 2010-02-23 18:22:53.000000000 +0100 ... > + adapter->last_hw_offload = 0; ... I tested the suggested patch http://people.freebsd.org/~yongari/em.csum_tso.20091230.patch and it also solved my problem Regards -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr) Laboratoire d'Informatique de Grenoble (LIG) Campus de Grenoble 681 rue de la Passerelle BP 72, F-38402 St Martin d'Hères Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 From owner-freebsd-net@FreeBSD.ORG Wed Feb 24 22:17: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 47A001065676; Wed, 24 Feb 2010 22:17:14 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1F8408FC18; Wed, 24 Feb 2010 22:17:13 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o1OMHDEs004320; Wed, 24 Feb 2010 14:17:13 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Feb 2010 14:17:06 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Apparent IPv6 bug Thread-Index: Acq00CYafhiMh9asQQWgcA4Yv6vncwACY7B5ADFMVIA= References: <4B843CC7.1000700@FreeBSD.org> From: "Li, Qing" To: "Doug Barton" Cc: freebsd-net@freebsd.org Subject: RE: Apparent IPv6 bug 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, 24 Feb 2010 22:17:14 -0000 Please try this patch http://people.freebsd.org/~qingli/nd6.c.diff and let me know if it works out for you. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Tuesday, February 23, 2010 2:44 PM > To: Doug Barton; freebsd-net@freebsd.org > Subject: RE: Apparent IPv6 bug >=20 >=20 > Okay, I read through your core file and I think I see the problem now. > Let me try to get you a patch later tonight. >=20 > -- Qing >=20 >=20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Doug Barton > Sent: Tue 2/23/2010 12:38 PM > To: freebsd-net@freebsd.org > Subject: Apparent IPv6 bug >=20 > Howdy, >=20 > I've had the following crash twice now when leaving my system up > overnight: >=20 > (kgdb) #0 doadump () at pcpu.h:246 > #1 0xc05f64af in boot (howto=3D260) > at /usr/local/src/sys/kern/kern_shutdown.c:416 > #2 0xc05f6792 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/local/src/sys/kern/kern_shutdown.c:579 > #3 0xc05e7dfa in _mtx_lock_sleep (m=3D0xc5e69e28, tid=3D3314788032, opts=3D0, > file=3D0xc08f2e6b "/usr/local/src/sys/netinet6/in6.c", line=3D827) > at /usr/local/src/sys/kern/kern_mutex.c:341 > #4 0xc05e7ff1 in _mtx_lock_flags (m=3D0xc5e69e28, opts=3D0, > file=3D0xc08f2e6b "/usr/local/src/sys/netinet6/in6.c", line=3D827) > at /usr/local/src/sys/kern/kern_mutex.c:203 > #5 0xc077829d in in6_update_ifa (ifp=3D0xc5e69c00, ifra=3D0xc5606b70, > ia=3D0xc8d41800, flags=3D0) at = /usr/local/src/sys/netinet6/in6.c:827 > #6 0xc07961ec in in6_tmpifadd (ia0=3D0xc5e90200, forcegen=3D0, = delay=3D0) > at /usr/local/src/sys/netinet6/nd6_rtr.c:2007 > #7 0xc079009c in regen_tmpaddr (ia6=3D0xc5e90000) > at /usr/local/src/sys/netinet6/nd6.c:772 > #8 0xc07916d5 in nd6_timer (arg=3D0x0) at > /usr/local/src/sys/netinet6/nd6.c:666 > #9 0xc06097ea in softclock (arg=3D0xc0987dc0) > at /usr/local/src/sys/kern/kern_timeout.c:430 > #10 0xc05cfd95 in intr_event_execute_handlers (p=3D0xc5938aa0, > ie=3D0xc593d600) > at /usr/local/src/sys/kern/kern_intr.c:1220 > #11 0xc05d0b6f in ithread_loop (arg=3D0xc58ddb60) > at /usr/local/src/sys/kern/kern_intr.c:1233 > #12 0xc05cdb28 in fork_exit (callout=3D0xc05d0ad0 , > arg=3D0xc58ddb60, frame=3D0xc5606d38) > at /usr/local/src/sys/kern/kern_fork.c:843 > #13 0xc0849af0 in fork_trampoline () > at /usr/local/src/sys/i386/i386/exception.s:270 > (kgdb) >=20 >=20 > The full core.txt.1 file is in my home dir on freefall. >=20 >=20 > Doug >=20 > -- >=20 > ... and that's just a little bit of history repeating. > -- Propellerheads >=20 > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ >=20 > _______________________________________________ > 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" >=20 > _______________________________________________ > 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 Feb 25 01: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 2D61C106564A; Thu, 25 Feb 2010 01:31:40 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8BF8FC16; Thu, 25 Feb 2010 01:31:39 +0000 (UTC) Received: by wwb22 with SMTP id 22so1767100wwb.13 for ; Wed, 24 Feb 2010 17:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TX5cd4n6Xsv9PpHpXaxMAExcQoFiw+bXyw7yu/GRuqs=; b=R7bkZ4ZbQH8i/v8EYcaH5uRAoP+5hsC0pbu/zqX+PuY3zzBIgMEb7SFB/j0G/MH+H5 mKlIKTy3b3kz8BiDVhaLz7TuKY1keGCxkjf7p2i6lwJX1/JcVUceLVi3WkaE4fMAwHQz L4a2ZQn3is1QaHOfRp+3jnz3Sl7IcUxkbHLEw= 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=LT1ccVNNXzTiIM+zKrR92w8SNWe9dpNl+u8LbMmeKXGa6ILMTkUAuHzONiSZjZvUSK RWIZM1jjpoNBj8qJiZHBhPr7Yb9i2BxhWzw1lqL4nnpbd73P/lBg0FfU7sYMzVFK2dro IhHdoZuJfSfDvEvauNxXdkv3pHELo7Gu8/8Ds= MIME-Version: 1.0 Received: by 10.216.158.20 with SMTP id p20mr325969wek.55.1267061493370; Wed, 24 Feb 2010 17:31:33 -0800 (PST) In-Reply-To: References: Date: Wed, 24 Feb 2010 17:31:33 -0800 Message-ID: <2a41acea1002241731w723406c3q7ab9aa79a2f92af5@mail.gmail.com> From: Jack Vogel To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8-stable crashes in vmware (possible em driver issue?) 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, 25 Feb 2010 01:31:40 -0000 Hmmm, not sure what changes are in this, what if you use the 8.0 REL driver, does it still happen? Regards, Jack On Wed, Feb 24, 2010 at 4:23 PM, Ivan Voras wrote: > Ivan Voras wrote: > >> I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 >> (amd64 guest), which apparently crashes every few days from the same causes: >> >> em0: discard frame w/o packet header >> em0: discard frame w/o packet header >> em0: discard frame w/o packet header >> Panic string: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf >> 0xffffff00490a6400 clashing >> > > In case someone is interested or has an idea - on this machine I have > multiple crashed cores with similarily strange problems all connected with > networking and/or the em driver: > > 1) > em0: watchdog timeout -- resetting > Fatal trap 12: page fault while in kernel mode > current process = 0 (em0 taskq) > > 2) > em0: watchdog timeout -- resetting > Fatal trap 9: general protection fault while in kernel mode > current process = 1219 (slapd) > > 3) > > em0: discard frame w/o packet header > panic: sbdrop > > I'm scratching my head about the #2 above - I don't think trap#9 is usual. > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Feb 25 09:20: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 6A06F106564A for ; Thu, 25 Feb 2010 09:20:03 +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 3FE0E8FC16 for ; Thu, 25 Feb 2010 09:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1P9K30j061254 for ; Thu, 25 Feb 2010 09:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1P9K2IA061246; Thu, 25 Feb 2010 09:20:02 GMT (envelope-from gnats) Date: Thu, 25 Feb 2010 09:20:02 GMT Message-Id: <201002250920.o1P9K2IA061246@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrey Zonov Cc: Subject: Re: kern/144000: [tcp] ignore set TCP_MAXSEG by setsockopt() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Zonov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 09:20:03 -0000 The following reply was made to PR kern/144000; it has been noted by GNATS. From: Andrey Zonov To: bug-followup@FreeBSD.org, jhb@freebsd.org Cc: Subject: Re: kern/144000: [tcp] ignore set TCP_MAXSEG by setsockopt() Date: Thu, 25 Feb 2010 11:49:00 +0300 --00151758b020ad57aa048068da47 Content-Type: text/plain; charset=ISO-8859-1 I have found patch at [1] and adapted for 8.0-p1 jhb, why you not added this patch in HEAD? [1] http://people.freebsd.org/~jhb/patches/tcp_maxseg.patch -- Andrey Zonov --00151758b020ad57aa048068da47 Content-Type: text/plain; charset=US-ASCII; name="tcp_maxseg_r80-p1.patch.txt" Content-Disposition: attachment; filename="tcp_maxseg_r80-p1.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g63b7nu60 LS0tIHN5cy9uZXRpbmV0L3RjcF9pbnB1dC5jLm9yaWcJMjAwOS0xMi0xNiAxNToxMjo0My4wMDAw MDAwMDAgKzAzMDAKKysrIHN5cy9uZXRpbmV0L3RjcF9pbnB1dC5jCTIwMTAtMDItMjQgMTc6MDk6 MjkuMDAwMDAwMDAwICswMzAwCkBAIC0zMTIyLDYgKzMxMjIsMTIgQEAKIAkJcmV0dXJuOwogCX0K IAorCWlmICh0cC0+dF91c2VybXNzKSB7CisJCWlmIChtYXhtdHUgPiAodHAtPnRfdXNlcm1zcyAr IG1pbl9wcm90b2gpKQorCQkJbWF4bXR1ID0gdHAtPnRfdXNlcm1zcyArIG1pbl9wcm90b2g7CisJ CWlmIChvZmZlciA+IHRwLT50X3VzZXJtc3MpCisJCQlvZmZlciA9IHRwLT50X3VzZXJtc3M7CisJ fQogCS8qIFdoYXQgaGF2ZSB3ZSBnb3Q/ICovCiAJc3dpdGNoIChvZmZlcikgewogCQljYXNlIDA6 Ci0tLSBzeXMvbmV0aW5ldC90Y3Bfb3V0cHV0LmMub3JpZwkyMDA5LTEyLTE2IDE1OjEyOjQ0LjAw MDAwMDAwMCArMDMwMAorKysgc3lzL25ldGluZXQvdGNwX291dHB1dC5jCTIwMTAtMDItMjQgMTc6 MDk6MjkuMDAwMDAwMDAwICswMzAwCkBAIC02NTksNiArNjU5LDggQEAKIAkJaWYgKGZsYWdzICYg VEhfU1lOKSB7CiAJCQl0cC0+c25kX254dCA9IHRwLT5pc3M7CiAJCQl0by50b19tc3MgPSB0Y3Bf bXNzb3B0KCZ0cC0+dF9pbnBjYi0+aW5wX2luYyk7CisJCQlpZiAodHAtPnRfdXNlcm1zcyAmJiB0 by50b19tc3MgPiB0cC0+dF91c2VybXNzKQorCQkJCXRvLnRvX21zcyA9IHRwLT50X3VzZXJtc3M7 CiAJCQl0by50b19mbGFncyB8PSBUT0ZfTVNTOwogCQl9CiAJCS8qIFdpbmRvdyBzY2FsaW5nLiAq LwotLS0gc3lzL25ldGluZXQvdGNwX3N5bmNhY2hlLmMub3JpZwkyMDA5LTEyLTE2IDE1OjEyOjQ0 LjAwMDAwMDAwMCArMDMwMAorKysgc3lzL25ldGluZXQvdGNwX3N5bmNhY2hlLmMJMjAxMC0wMi0y NCAxNzoyNzowOC4wMDAwMDAwMDAgKzAzMDAKQEAgLTk3NCw2ICs5NzQsNyBAQAogCXN0cnVjdCBt YnVmICppcG9wdHMgPSBOVUxMOwogCXVfaW50MzJfdCBmbG93dG1wOwogCWludCB3aW4sIHNiX2hp d2F0LCBpcF90dGwsIGlwX3Rvcywgbm9vcHQ7CisJdV9pbnQxNl90IHVzZXJtc3M7CiAJY2hhciAq czsKICNpZmRlZiBJTkVUNgogCWludCBhdXRvZmxvd2xhYmVsID0gMDsKQEAgLTEwMDcsNiArMTAw OCw3IEBACiAJd2luID0gc2JzcGFjZSgmc28tPnNvX3Jjdik7CiAJc2JfaGl3YXQgPSBzby0+c29f cmN2LnNiX2hpd2F0OwogCW5vb3B0ID0gKHRwLT50X2ZsYWdzICYgVEZfTk9PUFQpOworCXVzZXJt c3MgPSB0cC0+dF91c2VybXNzOwogCiAJLyogQnkgdGhlIHRpbWUgd2UgZHJvcCB0aGUgbG9jayB0 aGVzZSBzaG91bGQgbm8gbG9uZ2VyIGJlIHVzZWQuICovCiAJc28gPSBOVUxMOwpAQCAtMTE0Miw2 ICsxMTQ0LDcgQEAKIAlzYy0+c2NfaXNzID0gYXJjNHJhbmRvbSgpOwogCXNjLT5zY19mbGFncyA9 IDA7CiAJc2MtPnNjX2Zsb3dsYWJlbCA9IDA7CisJc2MtPnNjX3VzZXJtc3MgPSB1c2VybXNzOwog CiAJLyoKIAkgKiBJbml0aWFsIHJlY2VpdmUgd2luZG93OiBjbGlwIHNic3BhY2UgdG8gWzAgLi4g VENQX01BWFdJTl0uCkBAIC0xMjA2LDggKzEyMDksMTEgQEAKICNlbmRpZgogCWlmICh0by0+dG9f ZmxhZ3MgJiBUT0ZfU0FDS1BFUk0pCiAJCXNjLT5zY19mbGFncyB8PSBTQ0ZfU0FDSzsKLQlpZiAo dG8tPnRvX2ZsYWdzICYgVE9GX01TUykKKwlpZiAodG8tPnRvX2ZsYWdzICYgVE9GX01TUykgewog CQlzYy0+c2NfcGVlcl9tc3MgPSB0by0+dG9fbXNzOwkvKiBwZWVyIG1zcyBtYXkgYmUgemVybyAq LworCQlpZiAoc2MtPnNjX3VzZXJtc3MgJiYgc2MtPnNjX3BlZXJfbXNzID4gc2MtPnNjX3VzZXJt c3MpCisJCQlzYy0+c2NfcGVlcl9tc3MgPSBzYy0+c2NfdXNlcm1zczsKKwl9CiAJaWYgKG5vb3B0 KQogCQlzYy0+c2NfZmxhZ3MgfD0gU0NGX05PT1BUOwogCWlmICgodGgtPnRoX2ZsYWdzICYgKFRI X0VDRXxUSF9DV1IpKSAmJiBWX3RjcF9kb19lY24pCkBAIC0xMjgwLDYgKzEyODYsOCBAQAogCiAJ LyogRGV0ZXJtaW5lIE1TUyB3ZSBhZHZlcnRpemUgdG8gb3RoZXIgZW5kIG9mIGNvbm5lY3Rpb24u ICovCiAJbXNzb3B0ID0gdGNwX21zc29wdCgmc2MtPnNjX2luYyk7CisJaWYgKHNjLT5zY191c2Vy bXNzICYmIG1zc29wdCA+IHNjLT5zY191c2VybXNzKQorCQltc3NvcHQgPSBzYy0+c2NfdXNlcm1z czsKIAlpZiAoc2MtPnNjX3BlZXJfbXNzKQogCQltc3NvcHQgPSBtYXgoIG1pbihzYy0+c2NfcGVl cl9tc3MsIG1zc29wdCksIFZfdGNwX21pbm1zcyk7CiAKQEAgLTE2OTMsNiArMTcwMSw4IEBACiAK IAlzYy0+c2NfcnhtaXRzID0gMDsKIAlzYy0+c2NfcGVlcl9tc3MgPSB0Y3Bfc2NfbXNzdGFiW21z c107CisJaWYgKHNjLT5zY191c2VybXNzICYmIHNjLT5zY19wZWVyX21zcyA+IHNjLT5zY191c2Vy bXNzKQorCQlzYy0+c2NfcGVlcl9tc3MgPSBzYy0+c2NfdXNlcm1zczsKIAogCVRDUFNUQVRfSU5D KHRjcHNfc2NfcmVjdmNvb2tpZSk7CiAJcmV0dXJuIChzYyk7Ci0tLSBzeXMvbmV0aW5ldC90Y3Bf c3luY2FjaGUuaC5vcmlnCTIwMTAtMDItMjQgMTc6MjU6MjQuMDAwMDAwMDAwICswMzAwCisrKyBz eXMvbmV0aW5ldC90Y3Bfc3luY2FjaGUuaAkyMDEwLTAyLTI0IDE3OjI1OjAxLjAwMDAwMDAwMCAr MDMwMApAQCAtNjEsNiArNjEsNyBAQAogCXN0cnVjdAkJaW5fY29ubmluZm8gc2NfaW5jOwkvKiBh ZGRyZXNzZXMgKi8KIAlpbnQJCXNjX3J4dHRpbWU7CQkvKiByZXRyYW5zbWl0IHRpbWUgKi8KIAl1 X2ludDE2X3QJc2NfcnhtaXRzOwkJLyogcmV0cmFuc21pdCBjb3VudGVyICovCisJdV9pbnQxNl90 CXNjX3VzZXJtc3M7CQkvKiBVc2VyLXJlcXVlc3RlZCBtc3MgY2FwICovCiAJdV9pbnQzMl90CXNj X3RzcmVmbGVjdDsJCS8qIHRpbWVzdGFtcCB0byByZWZsZWN0ICovCiAJdV9pbnQzMl90CXNjX3Rz OwkJCS8qIG91ciB0aW1lc3RhbXAgdG8gc2VuZCAqLwogCXVfaW50MzJfdAlzY190c29mZjsJCS8q IHRzIG9mZnNldCB3LyBzeW5jb29raWVzICovCi0tLSBzeXMvbmV0aW5ldC90Y3BfdXNycmVxLmMu b3JpZwkyMDA5LTEyLTE2IDE1OjEyOjQ0LjAwMDAwMDAwMCArMDMwMAorKysgc3lzL25ldGluZXQv dGNwX3VzcnJlcS5jCTIwMTAtMDItMjQgMTc6MTc6MzYuMDAwMDAwMDAwICswMzAwCkBAIC0xMzM4 LDExICsxMzM4LDE4IEBACiAJCQkJcmV0dXJuIChlcnJvcik7CiAKIAkJCUlOUF9XTE9DS19SRUNI RUNLKGlucCk7Ci0JCQlpZiAob3B0dmFsID4gMCAmJiBvcHR2YWwgPD0gdHAtPnRfbWF4c2VnICYm Ci0JCQkgICAgb3B0dmFsICsgNDAgPj0gVl90Y3BfbWlubXNzKQotCQkJCXRwLT50X21heHNlZyA9 IG9wdHZhbDsKLQkJCWVsc2UKLQkJCQllcnJvciA9IEVJTlZBTDsKKwkJCWlmICgoc28tPnNvX3N0 YXRlICYgU1NfSVNDT05ORUNURUQpID09IDApIHsKKwkJCQlpZiAob3B0dmFsID4gMCAmJiBvcHR2 YWwgKyA0MCA+PSB0Y3BfbWlubXNzKQorCQkJCQl0cC0+dF91c2VybXNzID0gb3B0dmFsOworCQkJ CWVsc2UKKwkJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQl9IGVsc2UgeworCQkJCWlmIChvcHR2YWwg PiAwICYmIG9wdHZhbCA8PSB0cC0+dF9tYXhzZWcgJiYKKwkJCQkgICAgb3B0dmFsICsgNDAgPj0g dGNwX21pbm1zcykKKwkJCQkJdHAtPnRfbWF4c2VnID0gb3B0dmFsOworCQkJCWVsc2UKKwkJCQkJ ZXJyb3IgPSBFSU5WQUw7CisJCQl9CiAJCQlJTlBfV1VOTE9DSyhpbnApOwogCQkJYnJlYWs7CiAK QEAgLTEzNzUsNyArMTM4MiwxMCBAQAogCQkJZXJyb3IgPSBzb29wdGNvcHlvdXQoc29wdCwgJm9w dHZhbCwgc2l6ZW9mIG9wdHZhbCk7CiAJCQlicmVhazsKIAkJY2FzZSBUQ1BfTUFYU0VHOgotCQkJ b3B0dmFsID0gdHAtPnRfbWF4c2VnOworCQkJaWYgKChzby0+c29fc3RhdGUgJiBTU19JU0NPTk5F Q1RFRCkgPT0gMCkKKwkJCQlvcHR2YWwgPSB0cC0+dF91c2VybXNzOworCQkJZWxzZQorCQkJCW9w dHZhbCA9IHRwLT50X21heHNlZzsKIAkJCUlOUF9XVU5MT0NLKGlucCk7CiAJCQllcnJvciA9IHNv b3B0Y29weW91dChzb3B0LCAmb3B0dmFsLCBzaXplb2Ygb3B0dmFsKTsKIAkJCWJyZWFrOwotLS0g c3lzL25ldGluZXQvdGNwX3Zhci5oLm9yaWcJMjAwOS0xMi0xNiAxNToxMjo0NC4wMDAwMDAwMDAg KzAzMDAKKysrIHN5cy9uZXRpbmV0L3RjcF92YXIuaAkyMDEwLTAyLTI0IDE3OjM5OjAwLjAwMDAw MDAwMCArMDMwMApAQCAtMjAzLDYgKzIwMyw3IEBACiAJaW50CXRfaXNwYXJlOwkJLyogZXhwbGlj aXQgcGFkIGZvciA2NGJpdCBhbGlnbm1lbnQgKi8KIAl2b2lkCSp0X3BzcGFyZTJbNl07CQkvKiAy IENDIC8gNCBUQkQgKi8KIAl1aW50NjRfdCBfcGFkWzEyXTsJCS8qIDcgVVRPLCA1IFRCRCAoMS0y IENDL1JUVD8pICovCisJdV9pbnQJdF91c2VybXNzOwkJLyogVXNlciByZXF1ZXN0ZWQgdF9tYXhz ZWcgKi8KIH07CiAKIC8qCg== --00151758b020ad57aa048068da47-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 25 12:31: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 9978E106564A for ; Thu, 25 Feb 2010 12:31:50 +0000 (UTC) (envelope-from ivoras@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 2F14D8FC0C for ; Thu, 25 Feb 2010 12:31:49 +0000 (UTC) Received: by wyb40 with SMTP id 40so2018488wyb.13 for ; Thu, 25 Feb 2010 04:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=OpOSlbGHARNBVSpKQTISFVN+FQF1C9mUF9e0PoPBddg=; b=dIvLCYa3dgyrS1nFEGFeL2E/GAzhSVYrnZVMzO9cDKXl/BruSEQ4pJdVaCmxx4lMtC ndG+Sg4OXokxu4ZadTQt7E5Z8Z2ECXHDor+w9o4aEHxqA0Di8xRaTnpJkMrr+yYOYyFV CYNH9E5LPEAQBewmVQTa+6frPWMmtBpQmFPnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=rOnQrNDkDJwmPOmZ7yGCbXD1Nrmg8feABvEOujvVnCXbZLZh2ouR8TLvxz+m20Rwnx xK5Wnrk1Jr7OMNvJB1Kt4nKdRllDqamS/YzsjP7IixxVZEbLatGf7wGhjpJtsyXM0V8y 51Bw0YaE0paB9DOOT2KzNdSSX95CTXF7n3nIU= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.155.204 with SMTP id j54mr583569wek.104.1267099675294; Thu, 25 Feb 2010 04:07:55 -0800 (PST) In-Reply-To: <2a41acea1002241731w723406c3q7ab9aa79a2f92af5@mail.gmail.com> References: <2a41acea1002241731w723406c3q7ab9aa79a2f92af5@mail.gmail.com> From: Ivan Voras Date: Thu, 25 Feb 2010 13:07:35 +0100 X-Google-Sender-Auth: a8c1addb5bf31637 Message-ID: <9bbcef731002250407g776a4ca8xea944790a9572153@mail.gmail.com> To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8-stable crashes in vmware (possible em driver issue?) 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, 25 Feb 2010 12:31:50 -0000 On 25 February 2010 02:31, Jack Vogel wrote: > Hmmm,=C2=A0 not sure what changes are in this, what if you use the 8.0 RE= L > driver, does it still happen? Yes, this is why it is now running 8-STABLE. I have more FreeBSD guests on the same VMWare hosts which work fine, but this is the only 64-bit one. I don't know if this information helps. > > > On Wed, Feb 24, 2010 at 4:23 PM, Ivan Voras wrote: >> >> Ivan Voras wrote: >>> >>> I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 >>> (amd64 guest), which apparently crashes every few days from the same ca= uses: >>> >>> em0: discard frame w/o packet header >>> em0: discard frame w/o packet header >>> em0: discard frame w/o packet header >>> Panic string: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf >>> 0xffffff00490a6400 clashing >> >> In case someone is interested or has an idea - on this machine I have >> multiple crashed cores with similarily strange problems all connected wi= th >> networking and/or the em driver: >> >> 1) >> em0: watchdog timeout -- resetting >> Fatal trap 12: page fault while in kernel mode >> current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0 (em0 taskq) >> >> 2) >> em0: watchdog timeout -- resetting >> Fatal trap 9: general protection fault while in kernel mode >> current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 1219 (slapd) >> >> 3) >> em0: discard frame w/o packet header >> panic: sbdrop >> >> I'm scratching my head about the #2 above - I don't think trap#9 is usua= l. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " > > From owner-freebsd-net@FreeBSD.ORG Thu Feb 25 13:46:30 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 151721065758 for ; Thu, 25 Feb 2010 13:46:30 +0000 (UTC) (envelope-from voovoos-fnet@killfile.pl) Received: from mailhub.media4u.pl (mailhub.media4u.pl [194.79.24.10]) by mx1.freebsd.org (Postfix) with ESMTP id B9B7B8FC14 for ; Thu, 25 Feb 2010 13:46:29 +0000 (UTC) Received: from mail.media4u.pl ([194.79.24.11]:62934) by mailhub.media4u.pl with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Nke2t-000Nl2-TT; Thu, 25 Feb 2010 14:46:27 +0100 Received: from gw.media4u.net.pl ([194.79.25.15]:62541 helo=[192.168.9.33]) by mail.media4u.pl with esmtpa (Exim 4.63) (envelope-from ) id 1Nke2q-000IFq-2d; Thu, 25 Feb 2010 14:46:24 +0100 Message-ID: <4B867F29.8030005@killfile.pl> Date: Thu, 25 Feb 2010 14:46:17 +0100 From: Maciej Wierzbicki Organization: =?UTF-8?B?xbt5amVteSB3IEtyYWp1IEN1ZG93bnljaCBNZXRhZm9y?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kirk Davis References: <529374128DC1B04D9D037911B8E8F05301C17A51@Exchange26.EDU.epsb.ca> <43416_1266864062_4B82CFBE_43416_81_1_2a41acea1002221043k1b8742c9m8fb484a8e8a4fdda@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A54@Exchange26.EDU.epsb.ca> <43669_1266865888_4B82D6E0_43669_263_1_2a41acea1002221113v26804200q4f3971c3359dffab@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A55@Exchange26.EDU.epsb.ca> <201002222107.o1ML7v3Z059734@lava.sentex.ca> <529374128DC1B04D9D037911B8E8F05301C17A56@Exchange26.EDU.epsb.ca> <2a41acea1002221444o6e449602m1830761b21837c41@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A57@Exchange26.EDU.epsb.ca> <2a41acea1002221629vbe7548am7b5f1ba94d7efa9f@mail.gmail.com> <529374128DC1B04D9D037911B8E8F05301C17A5F@Exchange26.EDU.epsb.ca> In-Reply-To: <529374128DC1B04D9D037911B8E8F05301C17A5F@Exchange26.EDU.epsb.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Intel em0: watchdog timeout 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, 25 Feb 2010 13:46:30 -0000 Kirk Davis wrote on 2010-02-23 23:26: > I noticed that fastforwarding ( net.inet.ip.fastforwarding=1 ) was > turned on. I turned it off to see if that was causing the problem. > Sure enough, 5 hours later and no watchdog timeouts. This is still > running on FreeBSD 7.1 (I'm still planning to move to 7.2 soon). I read > up on the net.inet.ip.fastforwarding sysctl and it doesn't look like it > should cause any problems with the intel NIC driver. This may need to > be looked at and tested by some one more knowledgeable with the > networking code than I am. In my case fastforwarding is not being used. -- * Maciej Wierzbicki * At paranoia's poison door * * VOO1-RIPE * From owner-freebsd-net@FreeBSD.ORG Thu Feb 25 15:58: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 EBE00106564A; Thu, 25 Feb 2010 15:58:50 +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 BD4658FC13; Thu, 25 Feb 2010 15:58:50 +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 6F23946B2E; Thu, 25 Feb 2010 10:58:50 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C32D58A021; Thu, 25 Feb 2010 10:58:49 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 25 Feb 2010 07:56:49 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002250756.49757.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 25 Feb 2010 10:58:49 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: 8-stable crashes in vmware (possible em driver issue?) 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, 25 Feb 2010 15:58:51 -0000 On Wednesday 24 February 2010 7:23:44 pm Ivan Voras wrote: > Ivan Voras wrote: > > I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 > > (amd64 guest), which apparently crashes every few days from the same > > causes: > > > > em0: discard frame w/o packet header > > em0: discard frame w/o packet header > > em0: discard frame w/o packet header > > Panic string: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf > > 0xffffff00490a6400 clashing > > In case someone is interested or has an idea - on this machine I have > multiple crashed cores with similarily strange problems all connected > with networking and/or the em driver: > > 1) > em0: watchdog timeout -- resetting > Fatal trap 12: page fault while in kernel mode > current process = 0 (em0 taskq) > > 2) > em0: watchdog timeout -- resetting > Fatal trap 9: general protection fault while in kernel mode > current process = 1219 (slapd) > > 3) > em0: discard frame w/o packet header > panic: sbdrop > > I'm scratching my head about the #2 above - I don't think trap#9 is usual. Certain bad pointer values on amd64 trigger a GP# rather than a PF#, so for those you would get trap 9 instead of trap 12. Specifically, the top N bits of a pointer in amd64 have to either be all 0 or all 1. If there is a mix, then you get a GP# instead of a PF#. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Feb 25 21:46:19 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 33334106564A for ; Thu, 25 Feb 2010 21:46:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B62688FC1E for ; Thu, 25 Feb 2010 21:46:18 +0000 (UTC) Received: (qmail 25981 invoked by uid 399); 25 Feb 2010 21:46:11 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Feb 2010 21:46:11 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B86EF92.6030202@FreeBSD.org> Date: Thu, 25 Feb 2010 13:45:54 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Li, Qing" References: <4B843CC7.1000700@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Apparent IPv6 bug 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, 25 Feb 2010 21:46:19 -0000 On 02/24/10 14:17, Li, Qing wrote: > Please try this patch > > http://people.freebsd.org/~qingli/nd6.c.diff > > and let me know if it works out for you. > > Thanks, > > -- Qing Thank YOU. :) Uptime is 12 hours so far, with fairly continuous (albeit light) IPv6 traffic and so far so good. I'll leave it up for as long as I can and report back. I'm pretty sure I've made it past 12 hours before with the previous kernel, but definitely never more than 24 so by tomorrow morning California time I should have a good idea if it's fixed. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Fri Feb 26 03:55: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 A7636106566C for ; Fri, 26 Feb 2010 03:55:47 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from smtp.ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 2A0BB8FC16 for ; Fri, 26 Feb 2010 03:55:47 +0000 (UTC) Received: (qmail 22025 invoked by uid 89); 26 Feb 2010 03:54:55 -0000 Received: from unknown (HELO ?192.168.1.114?) (steve@ibctech.ca@::ffff:208.70.104.100) by ::ffff:208.70.104.210 with ESMTPA; 26 Feb 2010 03:54:55 -0000 Message-ID: <4B874654.5090900@ibctech.ca> Date: Thu, 25 Feb 2010 22:56:04 -0500 From: Steve Bertrand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Doug Barton References: <4B843CC7.1000700@FreeBSD.org> <4B86EF92.6030202@FreeBSD.org> In-Reply-To: <4B86EF92.6030202@FreeBSD.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Li, Qing" Subject: Re: Apparent IPv6 bug 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, 26 Feb 2010 03:55:47 -0000 On 2010.02.25 16:45, Doug Barton wrote: > On 02/24/10 14:17, Li, Qing wrote: >> Please try this patch >> >> http://people.freebsd.org/~qingli/nd6.c.diff >> >> and let me know if it works out for you. >> >> Thanks, >> >> -- Qing > > Thank YOU. :) Uptime is 12 hours so far, with fairly continuous (albeit > light) IPv6 traffic and so far so good. I'll leave it up for as long as > I can and report back. I'm pretty sure I've made it past 12 hours before > with the previous kernel, but definitely never more than 24 so by > tomorrow morning California time I should have a good idea if it's fixed. Do you want more v6 traffic thrown at the interface for testing? Steve From owner-freebsd-net@FreeBSD.ORG Fri Feb 26 04:03:46 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 8D3A8106566B for ; Fri, 26 Feb 2010 04:03:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0D28FC1E for ; Fri, 26 Feb 2010 04:03:45 +0000 (UTC) Received: (qmail 15752 invoked by uid 399); 26 Feb 2010 04:03:44 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Feb 2010 04:03:44 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B874814.2060908@FreeBSD.org> Date: Thu, 25 Feb 2010 20:03:32 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: Steve Bertrand References: <4B843CC7.1000700@FreeBSD.org> <4B86EF92.6030202@FreeBSD.org> <4B874654.5090900@ibctech.ca> In-Reply-To: <4B874654.5090900@ibctech.ca> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Li, Qing" Subject: Re: Apparent IPv6 bug 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, 26 Feb 2010 04:03:46 -0000 On 02/25/10 19:56, Steve Bertrand wrote: > Do you want more v6 traffic thrown at the interface for testing? Thanks for the offer, but the load I have on it now is the same as what I had when I got the crashes, so I think it will either work, or it will not work. :) 19+ hours and counting .... Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Fri Feb 26 04:16: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 D49201065674 for ; Fri, 26 Feb 2010 04:16:14 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from smtp.ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 56C968FC1D for ; Fri, 26 Feb 2010 04:16:14 +0000 (UTC) Received: (qmail 22538 invoked by uid 89); 26 Feb 2010 04:15:23 -0000 Received: from unknown (HELO ?192.168.1.114?) (steve@ibctech.ca@::ffff:208.70.104.100) by ::ffff:208.70.104.210 with ESMTPA; 26 Feb 2010 04:15:23 -0000 Message-ID: <4B874B20.2020900@ibctech.ca> Date: Thu, 25 Feb 2010 23:16:32 -0500 From: Steve Bertrand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Doug Barton References: <4B843CC7.1000700@FreeBSD.org> <4B86EF92.6030202@FreeBSD.org> <4B874654.5090900@ibctech.ca> <4B874814.2060908@FreeBSD.org> In-Reply-To: <4B874814.2060908@FreeBSD.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Li, Qing" Subject: Re: Apparent IPv6 bug 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, 26 Feb 2010 04:16:14 -0000 On 2010.02.25 23:03, Doug Barton wrote: > On 02/25/10 19:56, Steve Bertrand wrote: >> Do you want more v6 traffic thrown at the interface for testing? > > Thanks for the offer, but the load I have on it now is the same as what > I had when I got the crashes, so I think it will either work, or it will > not work. :) No sense changing the environment that broke it previously then, lest an artificial benchmark is created. > 19+ hours and counting .... Very, very nice work on the patch Qing, especially the exceptionally short time between issue and repair. Cheers, Steve From owner-freebsd-net@FreeBSD.ORG Fri Feb 26 10:02:35 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 938F7106566B; Fri, 26 Feb 2010 10:02:35 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 68E518FC0C; Fri, 26 Feb 2010 10:02:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1QA2ZVs047356; Fri, 26 Feb 2010 10:02:35 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1QA2ZkU047352; Fri, 26 Feb 2010 10:02:35 GMT (envelope-from remko) Date: Fri, 26 Feb 2010 10:02:35 GMT Message-Id: <201002261002.o1QA2ZkU047352@freefall.freebsd.org> To: shelma.box@gmail.com, remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/144315: freebsd 8-stable reboot after add ipfw rules with netgraph ng_car 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, 26 Feb 2010 10:02:35 -0000 Synopsis: freebsd 8-stable reboot after add ipfw rules with netgraph ng_car State-Changed-From-To: open->feedback State-Changed-By: remko State-Changed-When: Fri Feb 26 10:01:04 UTC 2010 State-Changed-Why: Change to feedback: Can you please check whether it's possible to get in the debugger when this happends? Consult the developers handbook on how that would be possible. That way a dump can be made and investigated. Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Feb 26 10:01:04 UTC 2010 Responsible-Changed-Why: Reassign to networking because of the netgraph module. http://www.freebsd.org/cgi/query-pr.cgi?pr=144315 From owner-freebsd-net@FreeBSD.ORG Fri Feb 26 14:25: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 2A90B106566B; Fri, 26 Feb 2010 14:25:22 +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 002768FC1C; Fri, 26 Feb 2010 14:25:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1QEPLV1081824; Fri, 26 Feb 2010 14:25:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1QEPL0f081820; Fri, 26 Feb 2010 14:25:21 GMT (envelope-from linimon) Date: Fri, 26 Feb 2010 14:25:21 GMT Message-Id: <201002261425.o1QEPL0f081820@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/144323: [ieee80211] A response management frame appears in wireshark captures before the corresponding request management frame in HOSTAP mode 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, 26 Feb 2010 14:25:22 -0000 Synopsis: [ieee80211] A response management frame appears in wireshark captures before the corresponding request management frame in HOSTAP mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 26 14:25:12 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144323 From owner-freebsd-net@FreeBSD.ORG Fri Feb 26 18:40:04 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 21715106564A for ; Fri, 26 Feb 2010 18:40:04 +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 E99B38FC18 for ; Fri, 26 Feb 2010 18:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1QIe3bR097556 for ; Fri, 26 Feb 2010 18:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1QIe3XM097555; Fri, 26 Feb 2010 18:40:03 GMT (envelope-from gnats) Date: Fri, 26 Feb 2010 18:40:03 GMT Message-Id: <201002261840.o1QIe3XM097555@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alexander Egorenkov Cc: Subject: Re: kern/144323: [ieee80211] A response management frame appears in wireshark captures before the corresponding request management frame in HOSTAP mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Egorenkov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 18:40:04 -0000 The following reply was made to PR kern/144323; it has been noted by GNATS. From: Alexander Egorenkov To: bug-followup@FreeBSD.org, egorenar@gmail.com Cc: Subject: Re: kern/144323: [ieee80211] A response management frame appears in wireshark captures before the corresponding request management frame in HOSTAP mode Date: Fri, 26 Feb 2010 19:38:17 +0100 --00c09f7d599cf93dc30480853386 Content-Type: multipart/alternative; boundary=00c09f7d599cf93dba0480853384 --00c09f7d599cf93dba0480853384 Content-Type: text/plain; charset=ISO-8859-1 Here is a patch i used on my system to fix the problem. --00c09f7d599cf93dba0480853384 Content-Type: text/html; charset=ISO-8859-1 Here is a patch i used on my system to fix the problem.
--00c09f7d599cf93dba0480853384-- --00c09f7d599cf93dc30480853386 Content-Type: application/octet-stream; name="ieee80211_hostap.c.patch" Content-Disposition: attachment; filename="ieee80211_hostap.c.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g65bqsv50 LS0tIGllZWU4MDIxMV9ob3N0YXAuYy5vcmlnCTIwMTAtMDItMjYgMTk6MjI6NDMuMDAwMDAwMDAw ICswMTAwCisrKyBpZWVlODAyMTFfaG9zdGFwLmMJMjAxMC0wMi0yNiAxOToyMjo0OS4wMDAwMDAw MDAgKzAxMDAKQEAgLTg4NCw2ICs4ODQsMTEgQEAKIAkJCXdoID0gbXRvZChtLCBzdHJ1Y3QgaWVl ZTgwMjExX2ZyYW1lICopOwogCQkJd2gtPmlfZmNbMV0gJj0gfklFRUU4MDIxMV9GQzFfV0VQOwog CQl9CisKKwkJaWYgKGllZWU4MDIxMV9yYWRpb3RhcF9hY3RpdmVfdmFwKHZhcCkpCisJCQlpZWVl ODAyMTFfcmFkaW90YXBfcngodmFwLCBtKTsKKwkJbmVlZF90YXAgPSAwOworCiAJCXZhcC0+aXZf cmVjdl9tZ210KG5pLCBtLCBzdWJ0eXBlLCByc3NpLCBuZik7CiAJCWdvdG8gb3V0OwogCg== --00c09f7d599cf93dc30480853386-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 26 19:16:17 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 913641065677 for ; Fri, 26 Feb 2010 19:16:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1FF158FC1A for ; Fri, 26 Feb 2010 19:16:16 +0000 (UTC) Received: (qmail 13542 invoked by uid 399); 26 Feb 2010 19:16:15 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Feb 2010 19:16:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B881DF5.6090600@FreeBSD.org> Date: Fri, 26 Feb 2010 11:16:05 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Li, Qing" References: <4B843CC7.1000700@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Apparent IPv6 bug 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, 26 Feb 2010 19:16:17 -0000 On 02/24/10 14:17, Li, Qing wrote: > Please try this patch > > http://people.freebsd.org/~qingli/nd6.c.diff > > and let me know if it works out for you. Ok, been up for way more than 24 hours now, I would say that this bug is fixed. :) Thanks again for your quick reply. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Sat Feb 27 01:20: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 472C41065670; Sat, 27 Feb 2010 01:20:13 +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 1D4D18FC16; Sat, 27 Feb 2010 01:20:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1R1KDJM038404; Sat, 27 Feb 2010 01:20:13 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1R1KCFu038341; Sat, 27 Feb 2010 01:20:12 GMT (envelope-from yongari) Date: Sat, 27 Feb 2010 01:20:12 GMT Message-Id: <201002270120.o1R1KCFu038341@freefall.freebsd.org> To: skylord@linkline.ru, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering 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, 27 Feb 2010 01:20:13 -0000 Synopsis: [msk] watchdog timeout (missed Tx interrupts) -- recovering State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Sat Feb 27 01:19:28 UTC 2010 State-Changed-Why: I bought DGE-560T and I can't reproduce this on CURRENT. Becasue there were a lot of changes since May 2008, would please try latest msk(4)? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Sat Feb 27 01:19:28 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=124127 From owner-freebsd-net@FreeBSD.ORG Sat Feb 27 01:22:53 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 ABBD21065672; Sat, 27 Feb 2010 01:22:53 +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 81FF38FC12; Sat, 27 Feb 2010 01:22:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1R1MrOE045703; Sat, 27 Feb 2010 01:22:53 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1R1MqZb045699; Sat, 27 Feb 2010 01:22:52 GMT (envelope-from yongari) Date: Sat, 27 Feb 2010 01:22:52 GMT Message-Id: <201002270122.o1R1MqZb045699@freefall.freebsd.org> To: dimka@dz.dn.ua, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/128884: [msk] if_msk page fault while in kernel mode 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, 27 Feb 2010 01:22:53 -0000 Synopsis: [msk] if_msk page fault while in kernel mode State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Sat Feb 27 01:22:14 UTC 2010 State-Changed-Why: Becasue there were a lot of changes since Nov 2008, would please try latest msk(4)? Also show me the output of "pciconf -lvcb" and dmesg output of your controller. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Sat Feb 27 01:22:14 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=128884 From owner-freebsd-net@FreeBSD.ORG Sat Feb 27 06:31:54 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 BCF111065673 for ; Sat, 27 Feb 2010 06:31:54 +0000 (UTC) (envelope-from hyama99@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 3A7B38FC15 for ; Sat, 27 Feb 2010 06:31:53 +0000 (UTC) Received: by fxm23 with SMTP id 23so787077fxm.3 for ; Fri, 26 Feb 2010 22:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=yf0K4vEHde3KKkJsOutvGfvLZDBobBlIaasScuCz5nM=; b=gdULvx0rLfQY3oJmtuaOioouu2qbxnDBzP3fWXFJli5T4QrIn2iZ7N7JLedk92dmWZ 8TnlIKpzrfJ9qN2I0zoy9UWw2DcjqRKsXjnj3zn/3+zAbU2Sj5r3azB3FMbsA3CIXYkD Z0oVe9uhaQyQMc4AZIL2uIy2xbFpc4/GgV0P4= 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:content-transfer-encoding; b=JRFLnYW36UV2jcsp3dYWsCRP2Iyu1venlNVe0KFK3uB9GWHecZ7wJM0EW0lryXwb0m pvU3cunv8cFbwHrJs/eDH9Z0nPwzDUhqhHcTexoTBApB11ucUO++KiQ5EzPJkLcsRtBj rwhqpzju1Ku5OgdFwodAzkN4/vm3pq/Z9jlvs= MIME-Version: 1.0 Received: by 10.239.169.20 with SMTP id m20mr155064hbe.20.1267252305683; Fri, 26 Feb 2010 22:31:45 -0800 (PST) In-Reply-To: <90dbee151002211402o52ed7cf6q352bd1ef339379bf@mail.gmail.com> References: <90dbee151002211402o52ed7cf6q352bd1ef339379bf@mail.gmail.com> Date: Sat, 27 Feb 2010 15:31:45 +0900 Message-ID: <90dbee151002262231v5d80a5cbua62786b5847c147b@mail.gmail.com> From: Hideki Yamamoto To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: IPv6 multicast packet size 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, 27 Feb 2010 06:31:54 -0000 Hi, I have found the answer to my question. The following lines resolved my problem. sock_optval=3D0; error =3D setsockopt(send_s, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &sock_optval, sizeof(sock_optval)); 2010/2/22 Hideki Yamamoto : > Hi, > > I have encountered IPv6 multicast problem. > I cannot send UDP packet longer than Shortest MTU. > It seems the bug of IPv6 multicast kernel. > I used the same application from FreeBSD 4.11. On that old version, > any problems happens. =A0When I would like to change the platform of > this application from 4.11 to 7.2 or later, I encountered this > problem. > Does anyone have any information about this problem? > > The followings are OS information I have tested, the result of > Tshark command, and source code of test program. > > Best regards, > > Hideki Yamamoto > > -------------------------------------------------------------------------= - > OS information > -------------------------------------------------------------------------= - > # sysctl -a |grep v6 > net.inet.tcp.v6mssdflt: 1024 > net.inet6.ip6.v6only: 1 > # sysctl -a |grep mtu > net.inet.tcp.path_mtu_discovery: 1 > net.inet.sctp.pmtu_raise_time: 600 > net.inet6.ip6.mcast_pmtu: 0 > # uname -a > FreeBSD tulip 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Fri Jan 15 05:25:24 > JST 2010 =A0 =A0 root@tulip:/usr/obj/usr/src/sys/tulip8 =A0i386 > tulip# > > -------------------------------------------------------------------------= - > Tshark output that shows the packets are devided into two packtet when > delivering 1400 byte lenghth packets. > -------------------------------------------------------------------------= - > # ./udp -s 1400 -o & > # tshark -VV -i fxp1 host ff3e::9800:600 |grep -v aaaaaaaaa > Capturing on fxp1 > Frame 1 (1294 bytes on wire, 1294 bytes captured) > =A0 Arrival Time: Feb 21, 2010 17:35:08.560297000 > =A0 [Time delta from previous captured frame: 0.000000000 seconds] > =A0 [Time delta from previous displayed frame: 0.000000000 seconds] > =A0 [Time since reference or first frame: 0.000000000 seconds] > =A0 Frame Number: 1 > =A0 Frame Length: 1294 bytes > =A0 Capture Length: 1294 bytes > =A0 [Frame is marked: False] > =A0 [Protocols in frame: eth:ipv6:data] > Ethernet II, Src: Intel_89:d6:d9 (00:d0:b7:89:d6:d9), Dst: > IPv6mcast_98:00:06:00 (33:33:98:00:06:00) > =A0 Destination: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) > =A0 =A0 =A0 Address: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) > =A0 =A0 =A0 .... ...1 .... .... .... .... =3D IG bit: Group address > (multicast/broadcast) > =A0 =A0 =A0 .... ..1. .... .... .... .... =3D LG bit: Locally administere= d > address (this is NOT the factory default) > =A0 Source: Intel_89:d6:d9 (00:d0:b7:89:d6:d9) > =A0 =A0 =A0 Address: Intel_89:d6:d9 (00:d0:b7:89:d6:d9) > =A0 =A0 =A0 .... ...0 .... .... .... .... =3D IG bit: Individual address = (unicast) > =A0 =A0 =A0 .... ..0. .... .... .... .... =3D LG bit: Globally unique add= ress > (factory default) > =A0 Type: IPv6 (0x86dd) > Internet Protocol Version 6 > =A0 0110 .... =3D Version: 6 > =A0 =A0 =A0 [0110 .... =3D This field makes the filter "ip.version =3D=3D= 6" possible: 6] > =A0 .... 0000 0000 .... .... .... .... .... =3D Traffic class: 0x00000000 > =A0 .... .... .... 0000 0000 0000 0000 0000 =3D Flowlabel: 0x00000000 > =A0 Payload length: 1240 > =A0 Next header: IPv6 fragment (0x2c) > =A0 Hop limit: 1 > =A0 Source: 2001:2a0:806:206:2d0:b7ff:fe89:d6d9 > (2001:2a0:806:206:2d0:b7ff:fe89:d6d9) > =A0 Destination: ff3e::9800:600 (ff3e::9800:600) > =A0 Fragmentation Header > =A0 =A0 =A0 Next header: UDP (0x11) > =A0 =A0 =A0 0000 0000 0000 0... =3D Offset: 0 (0x0000) > =A0 =A0 =A0 .... .... .... ...1 =3D More Fragment: Yes > =A0 =A0 =A0 Identification: 0xc31d92fa > Data (1232 bytes) > > 0000 =A05d 61 46 50 05 80 b0 d6 61 61 61 61 61 61 61 61 =A0 ]aFP....aaaaa= aaa > =A0 Data: 5D6146500580B0D661616161616161616161616161616161... > =A0 [Length: 1232] > > Frame 2 (238 bytes on wire, 238 bytes captured) > =A0 Arrival Time: Feb 21, 2010 17:35:08.560324000 > =A0 [Time delta from previous captured frame: 0.000027000 seconds] > =A0 [Time delta from previous displayed frame: 0.000027000 seconds] > =A0 [Time since reference or first frame: 0.000027000 seconds] > =A0 Frame Number: 2 > =A0 Frame Length: 238 bytes > =A0 Capture Length: 238 bytes > =A0 [Frame is marked: False] > =A0 [Protocols in frame: eth:ipv6:udp:data] > Ethernet II, Src: Intel_89:d6:d9 (00:d0:b7:89:d6:d9), Dst: > IPv6mcast_98:00:06:00 (33:33:98:00:06:00) > =A0 Destination: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) > =A0 =A0 =A0 Address: IPv6mcast_98:00:06:00 (33:33:98:00:06:00) > =A0 =A0 =A0 .... ...1 .... .... .... .... =3D IG bit: Group address > (multicast/broadcast) > =A0 =A0 =A0 .... ..1. .... .... .... .... =3D LG bit: Locally administere= d > address (this is NOT the factory default) > =A0 Source: Intel_89:d6:d9 (00:d0:b7:89:d6:d9) > =A0 =A0 =A0 Address: Intel_89:d6:d9 (00:d0:b7:89:d6:d9) > =A0 =A0 =A0 .... ...0 .... .... .... .... =3D IG bit: Individual address = (unicast) > =A0 =A0 =A0 .... ..0. .... .... .... .... =3D LG bit: Globally unique add= ress > (factory default) > =A0 Type: IPv6 (0x86dd) > > ------ > /********************************************************************** > udp.c (modified for MC Send Support) > ***********************************************************************/ > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > =A0// Modify send_addr to Multicast Address > char *send_addr=3D"ff3e::9800:600"; > char *send_port=3D"18000"; > > char *recv_addr=3D"2001:99::1"; > char *recv_port=3D"16000"; > int send_s; > int only_out=3D0; > int only_in=3D0; > int out_packet_size; > struct addrinfo *send_res; > > // Add for MC support > char *out_if=3D"fxp1"; > > main(ac,av) > int ac; > char **av; > { > =A0 int c; > > =A0 while ((c =3D getopt(ac, av, "s:oi")) !=3D -1) { > =A0 =A0 =A0 switch (c) { > =A0 =A0 =A0 case 'o': > =A0 =A0 =A0 =A0 =A0 only_out++; > =A0 =A0 =A0 =A0 =A0 break; > =A0 =A0 =A0 case 'i': > =A0 =A0 =A0 =A0 =A0 only_in++; > =A0 =A0 =A0 =A0 =A0 break; > =A0 =A0 =A0 case 's': > =A0 =A0 =A0 =A0 =A0 out_packet_size =3D atoi(optarg); > =A0 =A0 =A0 =A0 =A0 break; > =A0 =A0 =A0 default: > =A0 =A0 =A0 =A0 =A0 Usage(); > =A0 =A0 =A0 =A0 =A0 exit (1); > =A0 =A0 =A0 } > =A0 } > =A0 if( only_in && only_out ){ > =A0 =A0 =A0 Usage(); > =A0 =A0 =A0 exit (1); > =A0 } > > =A0 if( only_in =3D=3D 0 ){ > =A0 =A0 =A0 create_send_socket(); > =A0 =A0 =A0 send_v6_udp(); > =A0 =A0 =A0 exit; > =A0 } > =A0 recv_v6_udp(); > } > Usage() > { > =A0 printf("Usage: udpgw [-o][-i][-s output_packet_size]\n"); > > } > create_send_socket() > { > =A0 struct addrinfo hints; > =A0 int error; > =A0 struct sockaddr_in6 *sin6;// Add for MC Support > =A0 int ifindex;// Add for MC Support > > > =A0 memset(&hints, 0, sizeof(hints)); > =A0 hints.ai_family =3D PF_UNSPEC; > =A0 hints.ai_socktype =3D SOCK_DGRAM; > =A0 error =3D getaddrinfo(send_addr, send_port, &hints, &send_res); > =A0 if (error !=3D 0) errx(1, "%s", gai_strerror(error)); > =A0 send_res->ai_family =3D AF_INET6; > =A0 send_s =3D socket(send_res->ai_family, send_res->ai_socktype, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 send_res->ai_protocol); > =A0 if (send_s < 0) err(1, "socket"); > > // Add for MC support > =A0 sin6 =3D (struct sockaddr_in6 *)send_res->ai_addr; > =A0 if(IN6_IS_ADDR_MULTICAST(&(sin6->sin6_addr))) { > =A0 =A0 =A0 if ( (ifindex =3D if_nametoindex(out_if)) =3D=3D 0 ){ > =A0 =A0 =A0 =A0 =A0 err(1, "socket-MC"); > =A0 =A0 =A0 } > =A0 =A0 =A0 error =3D setsockopt(send_s, IPPROTO_IPV6, IPV6_MULTICAST_IF, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&ifindex, sizeof(ifind= ex)); > =A0 =A0 =A0 if (error < 0){ > =A0 =A0 =A0 =A0 =A0 err(1, "socket-MC"); > =A0 =A0 =A0 } > =A0 } > > } > send_v6_udp() > { > =A0 int len,cc,i; > =A0 char buf[2000]; > > =A0 for( i=3D0; i<2000 ; i++ ){ > =A0 =A0 =A0 buf[i]=3D'a'; > =A0 } > =A0 if( =A01501 > out_packet_size ){ > =A0 =A0 =A0 cc =3D out_packet_size ; > =A0 }else{ > =A0 =A0 =A0 cc =3D 1500; > =A0 } > =A0 printf("Let's send %d length packet to %s\n",cc,send_addr); > =A0 while(1){ > =A0 =A0 =A0 len =3D sendto(send_s, buf, cc, 0, send_res->ai_addr, > send_res->ai_addrlen); > =A0 =A0 =A0 sleep(1); > =A0 } > } > > recv_v6_udp() > { > =A0 int recv_s; > =A0 struct addrinfo hints, *res; > =A0 int error; > =A0 int len,cc,ccout; > =A0 char buf[2000]; > =A0 FILE *outfp=3Dstdout; > =A0 int fromlen; > =A0 struct sockaddr_in6 from6; > > =A0 memset(&hints, 0, sizeof(hints)); > =A0 hints.ai_family =3D PF_UNSPEC; > =A0 hints.ai_socktype =3D SOCK_DGRAM; > =A0 error =3D getaddrinfo(recv_addr, recv_port, &hints, &res); > =A0 if (error !=3D 0) errx(1, "%s", gai_strerror(error)); > =A0 res->ai_family =3D AF_INET6; > =A0 recv_s =3D socket(res->ai_family, res->ai_socktype, res->ai_protocol)= ; > =A0 if (recv_s < 0) err(1, "socket"); > > =A0 while(1){ > =A0 =A0 =A0 cc =3D recvfrom(recv_s, (void *)buf, sizeof(buf), 0, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (struct sockaddr *)&from6, &froml= en); > =A0 =A0 =A0 if (cc < 0) { > =A0 =A0 =A0 =A0 =A0 warn("recvfrom"); > =A0 =A0 =A0 =A0 =A0 continue; > =A0 =A0 =A0 } > =A0 =A0 =A0 if ( only_in =3D=3D 0 ){ > =A0 =A0 =A0 =A0 =A0 len =3D sendto(send_s, buf, cc, 0, send_res->ai_addr, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0send_res->ai_addrlen); > =A0 =A0 =A0 } else { > =A0 =A0 =A0 =A0 =A0 if ((ccout =3D fwrite(buf, cc, 1, outfp)) < 1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 close(recv_s); > =A0 =A0 =A0 } > > =A0 } > } > ------------- > From owner-freebsd-net@FreeBSD.ORG Sat Feb 27 09:21: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 73064106568A for ; Sat, 27 Feb 2010 09:21:34 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 06B898FC2B for ; Sat, 27 Feb 2010 09:21:32 +0000 (UTC) Received: by ewy26 with SMTP id 26so474328ewy.3 for ; Sat, 27 Feb 2010 01:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:organization:from :date:message-id:user-agent:mime-version:content-type; bh=0ou8JKVLBOl78Dq+XlfqH4sH2XYSC30RlnuS4K5U/HY=; b=heTEpJoYIEVzWf9pkQAqtFds2STrQD/Pe6LYPuEPi76U4dhBWWe0j4PPSk3HO8pJ6v gdglcA8VdzPWQ24UaRGG9N49PGvaVIP5W5HoEcGWAtuOkYVJRbGU9gM+BXc/JRywyr4l AD6OJPp6mmerFZMWBRTrSsN7Ib1LFsuZEzaOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:organization:from:date:message-id:user-agent :mime-version:content-type; b=m+y7yh7MBHLzoslLaDY5h8um2Q51fKRizGBdn/iGqwLv/1xaO+c09Zt+MAn5aIwx2E CMPJHWbYAXEBXz721HlqCOqTZxL9J5YvwOnLfUKhMo772gwGFkgohejm5BuyQQm6WHd4 mpzutcuPKsx9meltrdC18NRaxhHKdEE52Vbmw= Received: by 10.213.97.85 with SMTP id k21mr716805ebn.79.1267262481064; Sat, 27 Feb 2010 01:21:21 -0800 (PST) Received: from localhost ([95.69.170.185]) by mx.google.com with ESMTPS id 10sm4456081eyd.4.2010.02.27.01.21.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Feb 2010 01:21:19 -0800 (PST) To: freebsd-net@freebsd.org Organization: TOA Ukraine From: Mikolaj Golub Date: Sat, 27 Feb 2010 11:21:17 +0200 Message-ID: <86hbp3jape.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: kmem leakage on tun/tap device removal 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, 27 Feb 2010 09:21:34 -0000 Hi, Recently I run some tests, which create/destroy tun interface in loop, and after several hours my system panicked with "kmem_map too small". It has appeared that tun (or tap) device does not free memory after the device destroy: zhuzha:/usr/src/sys/kern% sudo vmstat -m |grep 'Type\|DEVFS1' Type InUse MemUse HighUse Requests Size(s) DEVFS1 139 35K - 157 256 zhuzha:/usr/src/sys/kern% sudo ifconfig tun0 create zhuzha:/usr/src/sys/kern% sudo vmstat -m |grep 'Type\|DEVFS1' Type InUse MemUse HighUse Requests Size(s) DEVFS1 140 35K - 159 256 zhuzha:/usr/src/sys/kern% sudo ifconfig tun0 destroy zhuzha:/usr/src/sys/kern% sudo vmstat -m |grep 'Type\|DEVFS1' Type InUse MemUse HighUse Requests Size(s) DEVFS1 140 35K - 159 256 And when running create/destroy in loop: Time Type InUse MemUse HighUse Requests Size(s) 09:20 DEVFS1 104 26K - 113 256 09:25 DEVFS1 8504 2126K - 16912 256 09:30 DEVFS1 31602 7901K - 63108 256 09:35 DEVFS1 54316 13579K - 108536 256 09:40 DEVFS1 77068 19267K - 154040 256 09:45 DEVFS1 99764 24941K - 199431 256 09:50 DEVFS1 122408 30602K - 244719 256 09:55 DEVFS1 144689 36173K - 289281 256 It looks like the problem is that tun/tap_clone_create() calls make_dev() and then dev_ref(dev). make_dev() calls itself dev_refl(), so after device creating we have si_refcount == 2. But on device removal (tun/tap_clone_destroy()) dev_rel() is never called, only destroy_dev(dev), which checks that si_refcount is still not zero and places the dev in dead_cdevsw.d_devs list. And running kgdb we can see the following picture: (kgdb) p *dead_cdevsw.d_devs.lh_first $2 = {__si_reserved = 0x0, si_flags = 0, si_atime = {tv_sec = 1267218482, tv_nsec = 0}, si_ctime = { tv_sec = 1267218482, tv_nsec = 0}, si_mtime = {tv_sec = 1267218482, tv_nsec = 0}, si_uid = 66, si_gid = 68, si_mode = 384, si_cred = 0x0, si_drv0 = 0, si_refcount = 1, si_list = { le_next = 0xcd183100, le_prev = 0xc0d90278}, si_clone = {le_next = 0x0, le_prev = 0xc5c83b50}, si_children = {lh_first = 0x0}, si_siblings = {le_next = 0x0, le_prev = 0x0}, si_parent = 0x0, si_name = 0xcaadc278 "tun0", si_drv1 = 0x0, si_drv2 = 0x0, si_devsw = 0x0, si_iosize_max = 0, si_usecount = 0, si_threadcount = 0, __si_u = {__sid_snapdata = 0x0}, __si_namebuf = "tun0", '\0' } (kgdb) p *dead_cdevsw.d_devs.lh_first->si_list.le_next $3 = {__si_reserved = 0x0, si_flags = 0, si_atime = {tv_sec = 1267218421, tv_nsec = 0}, si_ctime = { tv_sec = 1267218421, tv_nsec = 0}, si_mtime = {tv_sec = 1267218421, tv_nsec = 0}, si_uid = 66, si_gid = 68, si_mode = 384, si_cred = 0x0, si_drv0 = 0, si_refcount = 1, si_list = { le_next = 0xcd183000, le_prev = 0xcaadc238}, si_clone = {le_next = 0x0, le_prev = 0xc5c83b50}, si_children = {lh_first = 0x0}, si_siblings = {le_next = 0x0, le_prev = 0x0}, si_parent = 0x0, si_name = 0xcd183178 "tun0", si_drv1 = 0x0, si_drv2 = 0x0, si_devsw = 0x0, si_iosize_max = 0, si_usecount = 0, si_threadcount = 0, __si_u = {__sid_snapdata = 0x0}, __si_namebuf = "tun0", '\0' } ... and so on. Is dev_ref() needed in tun_clone_create() after make_dev() call? Can't it be safely removed as in the patch below? I have run some tests with the patch and it looks like it works for me. --- sys/net/if_tap.c.orig 2010-02-26 23:18:55.000000000 +0200 +++ sys/net/if_tap.c 2010-02-27 00:03:51.000000000 +0200 @@ -192,10 +192,8 @@ tap_clone_create(struct if_clone *ifc, i if (i) { dev = make_dev(&tap_cdevsw, unit | extra, UID_ROOT, GID_WHEEL, 0600, "%s%d", ifc->ifc_name, unit); - if (dev != NULL) { - dev_ref(dev); + if (dev != NULL) dev->si_flags |= SI_CHEAPCLONE; - } } tapcreate(dev); @@ -383,10 +381,8 @@ tapclone(void *arg, struct ucred *cred, *dev = make_dev(&tap_cdevsw, unit | extra, UID_ROOT, GID_WHEEL, 0600, "%s", name); - if (*dev != NULL) { - dev_ref(*dev); + if (*dev != NULL) (*dev)->si_flags |= SI_CHEAPCLONE; - } } if_clone_create(name, namelen, NULL); --- sys/net/if_tun.c.orig 2010-02-26 23:18:45.000000000 +0200 +++ sys/net/if_tun.c 2010-02-27 00:03:24.000000000 +0200 @@ -188,10 +188,8 @@ tun_clone_create(struct if_clone *ifc, i /* No preexisting struct cdev *, create one */ dev = make_dev(&tun_cdevsw, unit, UID_UUCP, GID_DIALER, 0600, "%s%d", ifc->ifc_name, unit); - if (dev != NULL) { - dev_ref(dev); + if (dev != NULL) dev->si_flags |= SI_CHEAPCLONE; - } } tuncreate(ifc->ifc_name, dev); @@ -239,10 +237,8 @@ tunclone(void *arg, struct ucred *cred, /* No preexisting struct cdev *, create one */ *dev = make_dev(&tun_cdevsw, u, UID_UUCP, GID_DIALER, 0600, "%s", name); - if (*dev != NULL) { - dev_ref(*dev); + if (*dev != NULL) (*dev)->si_flags |= SI_CHEAPCLONE; - } } if_clone_create(name, namelen, NULL); -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Sat Feb 27 15:16:31 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 B04141065674 for ; Sat, 27 Feb 2010 15:16:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6E38FC18 for ; Sat, 27 Feb 2010 15:16:30 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1RFGSFA097850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Feb 2010 17:16:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o1RFGS1q056649; Sat, 27 Feb 2010 17:16:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o1RFGQb4056648; Sat, 27 Feb 2010 17:16:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 27 Feb 2010 17:16:26 +0200 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20100227151626.GJ2489@deviant.kiev.zoral.com.ua> References: <86hbp3jape.fsf@kopusha.onet> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ed/6oDxOLijJh8b0" Content-Disposition: inline In-Reply-To: <86hbp3jape.fsf@kopusha.onet> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: kmem leakage on tun/tap device removal 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, 27 Feb 2010 15:16:31 -0000 --ed/6oDxOLijJh8b0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 27, 2010 at 11:21:17AM +0200, Mikolaj Golub wrote: > Hi, >=20 > Recently I run some tests, which create/destroy tun interface in loop, and > after several hours my system panicked with "kmem_map too small". It has > appeared that tun (or tap) device does not free memory after the device > destroy: >=20 > zhuzha:/usr/src/sys/kern% sudo vmstat -m |grep 'Type\|DEVFS1' > Type InUse MemUse HighUse Requests Size(s) > DEVFS1 139 35K - 157 256 > zhuzha:/usr/src/sys/kern% sudo ifconfig tun0 create =20 > zhuzha:/usr/src/sys/kern% sudo vmstat -m |grep 'Type\|DEVFS1' > Type InUse MemUse HighUse Requests Size(s) > DEVFS1 140 35K - 159 256 > zhuzha:/usr/src/sys/kern% sudo ifconfig tun0 destroy =20 > zhuzha:/usr/src/sys/kern% sudo vmstat -m |grep 'Type\|DEVFS1' > Type InUse MemUse HighUse Requests Size(s) > DEVFS1 140 35K - 159 256 >=20 > And when running create/destroy in loop: >=20 > Time Type InUse MemUse HighUse Requests Size(s) > 09:20 DEVFS1 104 26K - 113 256 > 09:25 DEVFS1 8504 2126K - 16912 256 > 09:30 DEVFS1 31602 7901K - 63108 256 > 09:35 DEVFS1 54316 13579K - 108536 256 > 09:40 DEVFS1 77068 19267K - 154040 256 > 09:45 DEVFS1 99764 24941K - 199431 256 > 09:50 DEVFS1 122408 30602K - 244719 256 > 09:55 DEVFS1 144689 36173K - 289281 256 >=20 > It looks like the problem is that tun/tap_clone_create() calls make_dev()= and > then dev_ref(dev). make_dev() calls itself dev_refl(), so after device cr= eating > we have si_refcount =3D=3D 2. But on device removal (tun/tap_clone_destro= y()) > dev_rel() is never called, only destroy_dev(dev), which checks that > si_refcount is still not zero and places the dev in dead_cdevsw.d_devs li= st. >=20 > And running kgdb we can see the following picture: >=20 > (kgdb) p *dead_cdevsw.d_devs.lh_first > $2 =3D {__si_reserved =3D 0x0, si_flags =3D 0, si_atime =3D {tv_sec =3D 1= 267218482, tv_nsec =3D 0}, si_ctime =3D { > tv_sec =3D 1267218482, tv_nsec =3D 0}, si_mtime =3D {tv_sec =3D 12672= 18482, tv_nsec =3D 0}, si_uid =3D 66,=20 > si_gid =3D 68, si_mode =3D 384, si_cred =3D 0x0, si_drv0 =3D 0, si_refc= ount =3D 1, si_list =3D { > le_next =3D 0xcd183100, le_prev =3D 0xc0d90278}, si_clone =3D {le_nex= t =3D 0x0, le_prev =3D 0xc5c83b50},=20 > si_children =3D {lh_first =3D 0x0}, si_siblings =3D {le_next =3D 0x0, l= e_prev =3D 0x0}, si_parent =3D 0x0,=20 > si_name =3D 0xcaadc278 "tun0", si_drv1 =3D 0x0, si_drv2 =3D 0x0, si_dev= sw =3D 0x0, si_iosize_max =3D 0,=20 > si_usecount =3D 0, si_threadcount =3D 0, __si_u =3D {__sid_snapdata =3D= 0x0},=20 > __si_namebuf =3D "tun0", '\0' } > (kgdb) p *dead_cdevsw.d_devs.lh_first->si_list.le_next > $3 =3D {__si_reserved =3D 0x0, si_flags =3D 0, si_atime =3D {tv_sec =3D 1= 267218421, tv_nsec =3D 0}, si_ctime =3D { > tv_sec =3D 1267218421, tv_nsec =3D 0}, si_mtime =3D {tv_sec =3D 12672= 18421, tv_nsec =3D 0}, si_uid =3D 66,=20 > si_gid =3D 68, si_mode =3D 384, si_cred =3D 0x0, si_drv0 =3D 0, si_refc= ount =3D 1, si_list =3D { > le_next =3D 0xcd183000, le_prev =3D 0xcaadc238}, si_clone =3D {le_nex= t =3D 0x0, le_prev =3D 0xc5c83b50},=20 > si_children =3D {lh_first =3D 0x0}, si_siblings =3D {le_next =3D 0x0, l= e_prev =3D 0x0}, si_parent =3D 0x0,=20 > si_name =3D 0xcd183178 "tun0", si_drv1 =3D 0x0, si_drv2 =3D 0x0, si_dev= sw =3D 0x0, si_iosize_max =3D 0,=20 > si_usecount =3D 0, si_threadcount =3D 0, __si_u =3D {__sid_snapdata =3D= 0x0},=20 > __si_namebuf =3D "tun0", '\0' } > ... and so on. >=20 > Is dev_ref() needed in tun_clone_create() after make_dev() call? Can't it= be > safely removed as in the patch below? I have run some tests with the patc= h and > it looks like it works for me. CHEAPCLONE is unused too. Besides this, there are two races in the clone handling. First is that dev_clone handlers shall use make_dev_credf(MAKEDEV_REF) instead of make_dev/dev_ref. Second is that module unload shall drain clone events. Please test the patch below. diff --git a/sys/net/if_tap.c b/sys/net/if_tap.c index 950e96c..93801f1 100644 --- a/sys/net/if_tap.c +++ b/sys/net/if_tap.c @@ -192,10 +192,6 @@ tap_clone_create(struct if_clone *ifc, int unit, caddr= _t params) if (i) { dev =3D make_dev(&tap_cdevsw, unit | extra, UID_ROOT, GID_WHEEL, 0600, "%s%d", ifc->ifc_name, unit); - if (dev !=3D NULL) { - dev_ref(dev); - dev->si_flags |=3D SI_CHEAPCLONE; - } } =20 tapcreate(dev); @@ -300,6 +296,7 @@ tapmodevent(module_t mod, int type, void *data) EVENTHANDLER_DEREGISTER(dev_clone, eh_tag); if_clone_detach(&tap_cloner); if_clone_detach(&vmnet_cloner); + drain_dev_clone_events(); =20 mtx_lock(&tapmtx); while ((tp =3D SLIST_FIRST(&taphead)) !=3D NULL) { @@ -381,12 +378,8 @@ tapclone(void *arg, struct ucred *cred, char *name, in= t namelen, struct cdev **d name =3D devname; } =20 - *dev =3D make_dev(&tap_cdevsw, unit | extra, - UID_ROOT, GID_WHEEL, 0600, "%s", name); - if (*dev !=3D NULL) { - dev_ref(*dev); - (*dev)->si_flags |=3D SI_CHEAPCLONE; - } + *dev =3D make_dev_credf(MAKEDEV_REF, &tap_cdevsw, unit | extra, + cred, UID_ROOT, GID_WHEEL, 0600, "%s", name); } =20 if_clone_create(name, namelen, NULL); diff --git a/sys/net/if_tun.c b/sys/net/if_tun.c index 37b5e70..1fa02ac 100644 --- a/sys/net/if_tun.c +++ b/sys/net/if_tun.c @@ -188,10 +188,6 @@ tun_clone_create(struct if_clone *ifc, int unit, caddr= _t params) /* No preexisting struct cdev *, create one */ dev =3D make_dev(&tun_cdevsw, unit, UID_UUCP, GID_DIALER, 0600, "%s%d", ifc->ifc_name, unit); - if (dev !=3D NULL) { - dev_ref(dev); - dev->si_flags |=3D SI_CHEAPCLONE; - } } tuncreate(ifc->ifc_name, dev); =20 @@ -237,12 +233,8 @@ tunclone(void *arg, struct ucred *cred, char *name, in= t namelen, name =3D devname; } /* No preexisting struct cdev *, create one */ - *dev =3D make_dev(&tun_cdevsw, u, + *dev =3D make_dev_credf(MAKEDEV_REF, &tun_cdevsw, u, cred, UID_UUCP, GID_DIALER, 0600, "%s", name); - if (*dev !=3D NULL) { - dev_ref(*dev); - (*dev)->si_flags |=3D SI_CHEAPCLONE; - } } =20 if_clone_create(name, namelen, NULL); @@ -303,6 +295,7 @@ tunmodevent(module_t mod, int type, void *data) case MOD_UNLOAD: if_clone_detach(&tun_cloner); EVENTHANDLER_DEREGISTER(dev_clone, tag); + drain_dev_clone_events(); =20 mtx_lock(&tunmtx); while ((tp =3D TAILQ_FIRST(&tunhead)) !=3D NULL) { --ed/6oDxOLijJh8b0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuJN0oACgkQC3+MBN1Mb4jMaACg0vYhY36hmXXIrc8I8vVhZE5W KqAAoIvy6vSk4nScFqS6zEqXlmGybXFb =CAa/ -----END PGP SIGNATURE----- --ed/6oDxOLijJh8b0--