From owner-freebsd-net@FreeBSD.ORG Sun Oct 2 12:16:24 2011 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 007791065670 for ; Sun, 2 Oct 2011 12:16:24 +0000 (UTC) (envelope-from adhocrocker@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id CF75C8FC0A for ; Sun, 2 Oct 2011 12:16:23 +0000 (UTC) Received: by pzk32 with SMTP id 32so19895512pzk.3 for ; Sun, 02 Oct 2011 05:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+Kq2otVs71askzN6DDiuPrgb/BCGm1slxz9cKIqAcMk=; b=nAZ/1IBGkLSdZaYXLCHnlGNlQiwPevq1sjGoIapkrzqrI5Vxpr1tNxZWj8jwQ7eh1B eBb5LI8+KLrJjCufOqOFdbD7XZwCI3KdkbtkZehv/R1agrvhfZa+VpNBBIVRQRumH1Lj gt6zf80TfeKkOiJcuxwLcsymTc6eqdIJ77Ef0= MIME-Version: 1.0 Received: by 10.68.35.97 with SMTP id g1mr12467415pbj.38.1317556298553; Sun, 02 Oct 2011 04:51:38 -0700 (PDT) Received: by 10.68.60.165 with HTTP; Sun, 2 Oct 2011 04:51:38 -0700 (PDT) In-Reply-To: <4E8798C2.1010107@zonov.org> References: <4E8798C2.1010107@zonov.org> Date: Sun, 2 Oct 2011 13:51:38 +0200 Message-ID: From: Johannes To: Andrey Zonov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Intel NIC stops working 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, 02 Oct 2011 12:16:24 -0000 Hi, thanks for the replies, I was very busy and lost the focus on this issue. However, the last weeks the temperatures were lower and the problem did not show up again. So I think the problem was triggered by the high temperatures, and my cooling (still) seems to be inadequate. Sorry for answering so late. But thanks for the pointers, I did not know about kern.ipc.nmbjumbo9 and its connection to the NIC jumbo frames, will have a look. Kind regards Johannes 2011/10/2 Andrey Zonov : > Hi, > > I see that you use MTU 9000, have you tried to increase kern.ipc.nmbjumbo= 9? > Can you also show output of `vmstat -z | grep mbuf'? > > -- > Andrey Zonov > > > 16.08.2011 0:10, Johannes =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >> Hi, >> >> I use an Intel dual nic for my home server. About two weeks ago, it >> started to randomly stop >> working. A reboot solved this problem. Today it did not even work >> after a reboot. >> >> Since the cooling of my server was insufficient for this summers heat, >> it might be a hardware >> issue. >> >> I already checked the cable, that seems to be fine. I also ran the >> Intel diagnostics (on windows) >> on the cable and on the card, which showed that everything is ok. >> >> Any idea what the reason might be is appreciated :) >> >> See debug infos below. What is especially strange is >> dev.em.1.debug: -1. I cannot change this, it will stay at -1. Also, >> the error count numbers from >> sysctl are mostly the same, which is very strange. >> >> uname -a >> FreeBSD frege.fritz.box 8.2-STABLE FreeBSD 8.2-STABLE #15: Tue Aug =C2= =A09 >> 00:00:57 CEST 2011 =C2=A0 =C2=A0 root@frege.fritz.box:/usr/obj/usr/src/s= ys/FREGE >> =C2=A0amd64 >> >> netstat -i >> Name =C2=A0 =C2=A0Mtu Network =C2=A0 =C2=A0 =C2=A0 Address =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ipkts Ierrs Idrop >> Opkts Oerrs =C2=A0Coll >> em1 =C2=A0 =C2=A09000 =C2=A0 =C2=A0 =C2=A0 00:15:17:51:b4:8f =C2= =A0 =C2=A0 =C2=A0 69 45908905416340 >> =C2=A00 =C2=A0 =C2=A0 =C2=A0 61 13116830118930 6558415059465 >> >> pciconf -lv >> em0@pci0:1:0:0: class=3D0x020000 card=3D0x125e8086 chip=3D0x105e8086 rev= =3D0x06 >> hdr=3D0x00 >> =C2=A0 =C2=A0 vendor =C2=A0 =C2=A0 =3D 'Intel Corporation' >> =C2=A0 =C2=A0 device =C2=A0 =C2=A0 =3D 'HP NC360T PCIe DP Gigabit Server= Adapter (n1e5132)' >> =C2=A0 =C2=A0 class =C2=A0 =C2=A0 =C2=A0=3D network >> =C2=A0 =C2=A0 subclass =C2=A0 =3D ethernet >> em1@pci0:1:0:1: class=3D0x020000 card=3D0x125e8086 chip=3D0x105e8086 rev= =3D0x06 >> hdr=3D0x00 >> =C2=A0 =C2=A0 vendor =C2=A0 =C2=A0 =3D 'Intel Corporation' >> =C2=A0 =C2=A0 device =C2=A0 =C2=A0 =3D 'HP NC360T PCIe DP Gigabit Server= Adapter (n1e5132)' >> =C2=A0 =C2=A0 class =C2=A0 =C2=A0 =C2=A0=3D network >> =C2=A0 =C2=A0 subclass =C2=A0 =3D ethernet >> >> sysctl dev.em.1 >> dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 >> dev.em.1.%driver: em >> dev.em.1.%location: slot=3D0 function=3D1 >> dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x105e subvendor=3D0x8086 >> subdevice=3D0x125e class=3D0x020000 >> dev.em.1.%parent: pci1 >> dev.em.1.nvm: -1 >> dev.em.1.debug: -1 >> dev.em.1.rx_int_delay: 0 >> dev.em.1.tx_int_delay: 66 >> dev.em.1.rx_abs_int_delay: 66 >> dev.em.1.tx_abs_int_delay: 66 >> dev.em.1.rx_processing_limit: 100 >> dev.em.1.flow_control: 3 >> dev.em.1.eee_control: 0 >> dev.em.1.link_irq: 0 >> dev.em.1.mbuf_alloc_fail: 0 >> dev.em.1.cluster_alloc_fail: 0 >> dev.em.1.dropped: 0 >> dev.em.1.tx_dma_fail: 0 >> dev.em.1.rx_overruns: 0 >> dev.em.1.watchdog_timeouts: 0 >> dev.em.1.device_control: 4294967295 >> dev.em.1.rx_control: 4294967295 >> dev.em.1.fc_high_water: 55296 >> dev.em.1.fc_low_water: 53796 >> dev.em.1.queue0.txd_head: 4294967295 >> dev.em.1.queue0.txd_tail: 4294967295 >> dev.em.1.queue0.tx_irq: 0 >> dev.em.1.queue0.no_desc_avail: 0 >> dev.em.1.queue0.rxd_head: 4294967295 >> dev.em.1.queue0.rxd_tail: 4294967295 >> dev.em.1.queue0.rx_irq: 0 >> dev.em.1.mac_stats.excess_coll: 4947802323840 >> dev.em.1.mac_stats.single_coll: 4947802323840 >> dev.em.1.mac_stats.multiple_coll: 4947802323840 >> dev.em.1.mac_stats.late_coll: 4947802323840 >> dev.em.1.mac_stats.collision_count: 4947802323840 >> dev.em.1.mac_stats.symbol_errors: 4947802323840 >> dev.em.1.mac_stats.sequence_errors: 4947802323840 >> dev.em.1.mac_stats.defer_count: 4947802323840 >> dev.em.1.mac_stats.missed_packets: 4947802323925 >> dev.em.1.mac_stats.recv_no_buff: 4947802323840 >> dev.em.1.mac_stats.recv_undersize: 4947802323840 >> dev.em.1.mac_stats.recv_fragmented: 4947802323840 >> dev.em.1.mac_stats.recv_oversize: 4947802323840 >> dev.em.1.mac_stats.recv_jabber: 4947802323840 >> dev.em.1.mac_stats.recv_errs: 4947802323840 >> dev.em.1.mac_stats.crc_errs: 4947802323840 >> dev.em.1.mac_stats.alignment_errs: 4947802323840 >> dev.em.1.mac_stats.coll_ext_errs: 4947802323840 >> dev.em.1.mac_stats.xon_recvd: 4947802323840 >> dev.em.1.mac_stats.xon_txd: 4947802323840 >> dev.em.1.mac_stats.xoff_recvd: -1152 >> dev.em.1.mac_stats.xoff_txd: 4947802323840 >> dev.em.1.mac_stats.total_pkts_recvd: 4947802324218 >> dev.em.1.mac_stats.good_pkts_recvd: 4947802324133 >> dev.em.1.mac_stats.bcast_pkts_recvd: 4947802323919 >> dev.em.1.mac_stats.mcast_pkts_recvd: 4947802324054 >> dev.em.1.mac_stats.rx_frames_64: 4947802323840 >> dev.em.1.mac_stats.rx_frames_65_127: 4947802323985 >> dev.em.1.mac_stats.rx_frames_128_255: 4947802323879 >> dev.em.1.mac_stats.rx_frames_256_511: 4947802323949 >> dev.em.1.mac_stats.rx_frames_512_1023: 4947802323840 >> dev.em.1.mac_stats.rx_frames_1024_1522: 4947802323840 >> dev.em.1.mac_stats.good_octets_recvd: 60519 >> dev.em.1.mac_stats.good_octets_txd: 4643 >> dev.em.1.mac_stats.total_pkts_txd: 4947802323860 >> dev.em.1.mac_stats.good_pkts_txd: 4947802323860 >> dev.em.1.mac_stats.bcast_pkts_txd: 4947802323840 >> dev.em.1.mac_stats.mcast_pkts_txd: 4947802323860 >> dev.em.1.mac_stats.tx_frames_64: 4947802323840 >> dev.em.1.mac_stats.tx_frames_65_127: 4947802323848 >> dev.em.1.mac_stats.tx_frames_128_255: 4947802323846 >> dev.em.1.mac_stats.tx_frames_256_511: 4947802323843 >> dev.em.1.mac_stats.tx_frames_512_1023: 4947802323843 >> dev.em.1.mac_stats.tx_frames_1024_1522: 4947802323840 >> dev.em.1.mac_stats.tso_txd: 4947802323840 >> dev.em.1.mac_stats.tso_ctx_fail: 4952097291135 >> dev.em.1.interrupts.asserts: 4947802323925 >> dev.em.1.interrupts.rx_pkt_timer: 4947802323840 >> dev.em.1.interrupts.rx_abs_timer: 4947802323840 >> dev.em.1.interrupts.tx_pkt_timer: 4947802323840 >> dev.em.1.interrupts.tx_abs_timer: 4947802323840 >> dev.em.1.interrupts.tx_queue_empty: 4947802323840 >> dev.em.1.interrupts.tx_queue_min_thresh: 4947802323840 >> dev.em.1.interrupts.rx_desc_min_thresh: 4947802323840 >> dev.em.1.interrupts.rx_overrun: 4947802323840 >> _______________________________________________ >> 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 Sun Oct 2 16:08:09 2011 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 B56BB1065678 for ; Sun, 2 Oct 2011 16:08:09 +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 4D10F8FC14 for ; Sun, 2 Oct 2011 16:08:08 +0000 (UTC) Received: by wyj26 with SMTP id 26so3301113wyj.13 for ; Sun, 02 Oct 2011 09:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eJuqRJeuTz9oP3Rum4wJc3X957lyeulnWNeyFBApYwI=; b=a65PfProDNksCchjcPJ+i4N70FJS4zAMJsuYxiCPryEnkOxOUa0Ez5JYxpZGuyViSB I4L+RZubVZKz6meOUcrbn5F7dIjKpg1FSASgVXosziR2thShv2cH53TlGNJIm356QzAG KwT2NBFNlcHJdDB0bv85R/P8J7c/HBvWNQsQI= MIME-Version: 1.0 Received: by 10.227.42.136 with SMTP id s8mr749955wbe.28.1317571688189; Sun, 02 Oct 2011 09:08:08 -0700 (PDT) Received: by 10.180.106.35 with HTTP; Sun, 2 Oct 2011 09:08:08 -0700 (PDT) In-Reply-To: <4E886A3B.7000502@sepehrs.com> References: <4E886A3B.7000502@sepehrs.com> Date: Sun, 2 Oct 2011 09:08:08 -0700 Message-ID: From: Jack Vogel To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: Re: em(4) high latency w/o msix 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, 02 Oct 2011 16:08:09 -0000 On what hardware? Jack On Sun, Oct 2, 2011 at 6:42 AM, Hooman Fazaeli wrote: > > Latest em(4) driver from HEAD seems to have high latency > when MSIX is disabled. > > With MSIX enabled (hw.em.enable_msix=1): > > # ping -c5 192.168.1.83 > PING 192.168.1.83 (192.168.1.83): 56 data bytes > 64 bytes from 192.168.1.83: icmp_seq=0 ttl=64 time=0.055 ms > 64 bytes from 192.168.1.83: icmp_seq=1 ttl=64 time=0.076 ms > 64 bytes from 192.168.1.83: icmp_seq=2 ttl=64 time=0.066 ms > 64 bytes from 192.168.1.83: icmp_seq=3 ttl=64 time=0.051 ms > 64 bytes from 192.168.1.83: icmp_seq=4 ttl=64 time=0.063 ms > > --- 192.168.1.83 ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.051/0.062/0.076/0.009 ms > > With MSIX disabled: > > # ping -c5 192.168.1.83 > PING 192.168.1.83 (192.168.1.83): 56 data bytes > 64 bytes from 192.168.1.83: icmp_seq=0 ttl=64 time=0.180 ms > 64 bytes from 192.168.1.83: icmp_seq=1 ttl=64 time=0.164 ms > 64 bytes from 192.168.1.83: icmp_seq=2 ttl=64 time=0.169 ms > 64 bytes from 192.168.1.83: icmp_seq=3 ttl=64 time=0.172 ms > 64 bytes from 192.168.1.83: icmp_seq=4 ttl=64 time=0.167 ms > > --- 192.168.1.83 ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.164/0.170/0.180/0.005 ms > > As you see, w/o MSIX, RTT increases by a factor of 3. > > I also tested the following drivers: > - igb(4) from HEAD: OK. > - Stock 7.3-RELEASE: OK. > - Stock 7.4-RELEASE: problem exist. > > Any ideas? > > > > > From owner-freebsd-net@FreeBSD.ORG Mon Oct 3 00:29:45 2011 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 267A0106566C for ; Mon, 3 Oct 2011 00:29:45 +0000 (UTC) (envelope-from lacombar@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 AF44C8FC12 for ; Mon, 3 Oct 2011 00:29:44 +0000 (UTC) Received: by wyj26 with SMTP id 26so3568630wyj.13 for ; Sun, 02 Oct 2011 17:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EpHnlbYLErZtuApuoziA6WRkR5nDHrbYRiUK4vNx3xw=; b=kgAtPUgkWQfQwpGCSdQoxn1DmCKegEu4XpdRAqA4kbe8i54jSWVt8WRXIPqrtrwWbr b5QO92frLS8/5eZ5sJ86NyFcstBIa+0Wm6jktWBWZb7hCEJfEbiyJRTet23KbrgkvDV4 f4wiU5A9Ae1W60++C8xy2x7v+vuTdmGN+FaxM= MIME-Version: 1.0 Received: by 10.227.175.77 with SMTP id w13mr2224116wbz.36.1317601783091; Sun, 02 Oct 2011 17:29:43 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Sun, 2 Oct 2011 17:29:43 -0700 (PDT) In-Reply-To: References: <4E886A3B.7000502@sepehrs.com> Date: Sun, 2 Oct 2011 20:29:43 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Hooman Fazaeli Subject: Re: em(4) high latency w/o msix 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, 03 Oct 2011 00:29:45 -0000 Hi, On Sun, Oct 2, 2011 at 12:08 PM, Jack Vogel wrote: > On what hardware? > Only the 82574 is using em(4)'s MSI-X. - Arnaud > Jack > > > On Sun, Oct 2, 2011 at 6:42 AM, Hooman Fazaeli wrot= e: > >> >> Latest em(4) driver from HEAD seems to have high latency >> when MSIX is disabled. >> >> With MSIX enabled (hw.em.enable_msix=3D1): >> >> # ping -c5 192.168.1.83 >> PING 192.168.1.83 (192.168.1.83): 56 data bytes >> 64 bytes from 192.168.1.83: icmp_seq=3D0 ttl=3D64 time=3D0.055 ms >> 64 bytes from 192.168.1.83: icmp_seq=3D1 ttl=3D64 time=3D0.076 ms >> 64 bytes from 192.168.1.83: icmp_seq=3D2 ttl=3D64 time=3D0.066 ms >> 64 bytes from 192.168.1.83: icmp_seq=3D3 ttl=3D64 time=3D0.051 ms >> 64 bytes from 192.168.1.83: icmp_seq=3D4 ttl=3D64 time=3D0.063 ms >> >> --- 192.168.1.83 ping statistics --- >> 5 packets transmitted, 5 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev =3D 0.051/0.062/0.076/0.009 ms >> >> With MSIX disabled: >> >> # ping -c5 192.168.1.83 >> PING 192.168.1.83 (192.168.1.83): 56 data bytes >> 64 bytes from 192.168.1.83: icmp_seq=3D0 ttl=3D64 time=3D0.180 ms >> 64 bytes from 192.168.1.83: icmp_seq=3D1 ttl=3D64 time=3D0.164 ms >> 64 bytes from 192.168.1.83: icmp_seq=3D2 ttl=3D64 time=3D0.169 ms >> 64 bytes from 192.168.1.83: icmp_seq=3D3 ttl=3D64 time=3D0.172 ms >> 64 bytes from 192.168.1.83: icmp_seq=3D4 ttl=3D64 time=3D0.167 ms >> >> --- 192.168.1.83 ping statistics --- >> 5 packets transmitted, 5 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev =3D 0.164/0.170/0.180/0.005 ms >> >> As you see, w/o MSIX, RTT increases by a factor of 3. >> >> I also tested the following drivers: >> =A0 =A0- igb(4) from HEAD: OK. >> =A0 =A0- Stock 7.3-RELEASE: OK. >> =A0 =A0- Stock 7.4-RELEASE: problem exist. >> >> Any ideas? >> >> >> >> >> > _______________________________________________ > 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 Oct 3 00:50:11 2011 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 BE207106564A for ; Mon, 3 Oct 2011 00:50:11 +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 482DF8FC15 for ; Mon, 3 Oct 2011 00:50:10 +0000 (UTC) Received: by wyj26 with SMTP id 26so3578586wyj.13 for ; Sun, 02 Oct 2011 17:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1VuE5twOx4AIqh4Us8JHb0IZWs5a88wj6jlt1zAT5Yw=; b=RlBnRBsLDCvj0Kf93zYYMljC7sOccyq8f/FolNpwlsXa7qS9jnW7i973yAvAnS8itd y5hzqGDwppdiCEgSn3lE2scVKgDdWOefg6sJe13CwaMqKgbLIX+ZTia+Z/iuQ5HXi9cH 3I3ucRejrLUDUuIEzChCb7Mmi3a7zJ3rLDslQ= MIME-Version: 1.0 Received: by 10.227.13.84 with SMTP id b20mr2341161wba.13.1317603010034; Sun, 02 Oct 2011 17:50:10 -0700 (PDT) Received: by 10.180.106.35 with HTTP; Sun, 2 Oct 2011 17:50:10 -0700 (PDT) In-Reply-To: References: <4E886A3B.7000502@sepehrs.com> Date: Sun, 2 Oct 2011 17:50:10 -0700 Message-ID: From: Jack Vogel To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Hooman Fazaeli Subject: Re: em(4) high latency w/o msix 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, 03 Oct 2011 00:50:11 -0000 There are differences between adapter and LOM, furthermore, someone could toggle the variable on hardware not using it... SO my question stands, I want to know hardware details. Jack On Sun, Oct 2, 2011 at 5:29 PM, Arnaud Lacombe wrote: > Hi, > > On Sun, Oct 2, 2011 at 12:08 PM, Jack Vogel wrote: > > On what hardware? > > > Only the 82574 is using em(4)'s MSI-X. > > - Arnaud > > > Jack > > > > > > On Sun, Oct 2, 2011 at 6:42 AM, Hooman Fazaeli > wrote: > > > >> > >> Latest em(4) driver from HEAD seems to have high latency > >> when MSIX is disabled. > >> > >> With MSIX enabled (hw.em.enable_msix=1): > >> > >> # ping -c5 192.168.1.83 > >> PING 192.168.1.83 (192.168.1.83): 56 data bytes > >> 64 bytes from 192.168.1.83: icmp_seq=0 ttl=64 time=0.055 ms > >> 64 bytes from 192.168.1.83: icmp_seq=1 ttl=64 time=0.076 ms > >> 64 bytes from 192.168.1.83: icmp_seq=2 ttl=64 time=0.066 ms > >> 64 bytes from 192.168.1.83: icmp_seq=3 ttl=64 time=0.051 ms > >> 64 bytes from 192.168.1.83: icmp_seq=4 ttl=64 time=0.063 ms > >> > >> --- 192.168.1.83 ping statistics --- > >> 5 packets transmitted, 5 packets received, 0.0% packet loss > >> round-trip min/avg/max/stddev = 0.051/0.062/0.076/0.009 ms > >> > >> With MSIX disabled: > >> > >> # ping -c5 192.168.1.83 > >> PING 192.168.1.83 (192.168.1.83): 56 data bytes > >> 64 bytes from 192.168.1.83: icmp_seq=0 ttl=64 time=0.180 ms > >> 64 bytes from 192.168.1.83: icmp_seq=1 ttl=64 time=0.164 ms > >> 64 bytes from 192.168.1.83: icmp_seq=2 ttl=64 time=0.169 ms > >> 64 bytes from 192.168.1.83: icmp_seq=3 ttl=64 time=0.172 ms > >> 64 bytes from 192.168.1.83: icmp_seq=4 ttl=64 time=0.167 ms > >> > >> --- 192.168.1.83 ping statistics --- > >> 5 packets transmitted, 5 packets received, 0.0% packet loss > >> round-trip min/avg/max/stddev = 0.164/0.170/0.180/0.005 ms > >> > >> As you see, w/o MSIX, RTT increases by a factor of 3. > >> > >> I also tested the following drivers: > >> - igb(4) from HEAD: OK. > >> - Stock 7.3-RELEASE: OK. > >> - Stock 7.4-RELEASE: problem exist. > >> > >> Any ideas? > >> > >> > >> > >> > >> > > _______________________________________________ > > 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 Oct 3 01:39:55 2011 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 B8203106566C for ; Mon, 3 Oct 2011 01:39:55 +0000 (UTC) (envelope-from lacombar@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 46C6A8FC08 for ; Mon, 3 Oct 2011 01:39:54 +0000 (UTC) Received: by wyj26 with SMTP id 26so3604942wyj.13 for ; Sun, 02 Oct 2011 18:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1NLgMroqNBM9FEB2hqPpyiOBTL4Qj+0jWn9kI2a5oRU=; b=HtP0jOa02XLGyQtJshltnWNT7oc7X3PkWVavz/kc/lplb0rKdlZshtM6qUXB4smSCb +/ZUNxdQ0XO5yv3jAYUFNq6z/9GmxAVaYIujJXWzbJCloEz4upTA4iZ1HouuIcQ4p+8H qyNUV5TUofgf1dSknVeGDCdQ5ARnl0e4Y47x4= MIME-Version: 1.0 Received: by 10.227.153.211 with SMTP id l19mr181113wbw.51.1317605993809; Sun, 02 Oct 2011 18:39:53 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Sun, 2 Oct 2011 18:39:53 -0700 (PDT) In-Reply-To: References: <4E886A3B.7000502@sepehrs.com> Date: Sun, 2 Oct 2011 21:39:53 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Hooman Fazaeli Subject: Re: em(4) high latency w/o msix 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, 03 Oct 2011 01:39:55 -0000 Hi, On Sun, Oct 2, 2011 at 8:29 PM, Arnaud Lacombe wrote: > Hi, > > On Sun, Oct 2, 2011 at 12:08 PM, Jack Vogel wrote: >> On what hardware? >> > Only the 82574 is using em(4)'s MSI-X. > FWIW, I'm not seeing this issue on a 82574 box I've access to: result of the following command: # ping -nqt 30 -f The two box are connected on an old 10/100 switch MSI-X enabled: 239361 packets transmitted, 239358 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 0.090/0.117/2.488/0.027 ms MSI-X disabled: 233122 packets transmitted, 233119 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 0.096/0.120/2.589/0.027 ms On another interface (same boxes involved, but through a 10/100/1000 switch= ): MSI-X enabled: 240080 packets transmitted, 240079 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 0.090/0.116/0.175/0.008 ms MSI-X disabled: 207310 packets transmitted, 207309 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 0.095/0.136/0.310/0.044 ms However, there seem to be a performance drop with MSI-X disabled and Gigabit link. - Arnaud >> Jack >> >> >> On Sun, Oct 2, 2011 at 6:42 AM, Hooman Fazaeli wro= te: >> >>> >>> Latest em(4) driver from HEAD seems to have high latency >>> when MSIX is disabled. >>> >>> With MSIX enabled (hw.em.enable_msix=3D1): >>> >>> # ping -c5 192.168.1.83 >>> PING 192.168.1.83 (192.168.1.83): 56 data bytes >>> 64 bytes from 192.168.1.83: icmp_seq=3D0 ttl=3D64 time=3D0.055 ms >>> 64 bytes from 192.168.1.83: icmp_seq=3D1 ttl=3D64 time=3D0.076 ms >>> 64 bytes from 192.168.1.83: icmp_seq=3D2 ttl=3D64 time=3D0.066 ms >>> 64 bytes from 192.168.1.83: icmp_seq=3D3 ttl=3D64 time=3D0.051 ms >>> 64 bytes from 192.168.1.83: icmp_seq=3D4 ttl=3D64 time=3D0.063 ms >>> >>> --- 192.168.1.83 ping statistics --- >>> 5 packets transmitted, 5 packets received, 0.0% packet loss >>> round-trip min/avg/max/stddev =3D 0.051/0.062/0.076/0.009 ms >>> >>> With MSIX disabled: >>> >>> # ping -c5 192.168.1.83 >>> PING 192.168.1.83 (192.168.1.83): 56 data bytes >>> 64 bytes from 192.168.1.83: icmp_seq=3D0 ttl=3D64 time=3D0.180 ms >>> 64 bytes from 192.168.1.83: icmp_seq=3D1 ttl=3D64 time=3D0.164 ms >>> 64 bytes from 192.168.1.83: icmp_seq=3D2 ttl=3D64 time=3D0.169 ms >>> 64 bytes from 192.168.1.83: icmp_seq=3D3 ttl=3D64 time=3D0.172 ms >>> 64 bytes from 192.168.1.83: icmp_seq=3D4 ttl=3D64 time=3D0.167 ms >>> >>> --- 192.168.1.83 ping statistics --- >>> 5 packets transmitted, 5 packets received, 0.0% packet loss >>> round-trip min/avg/max/stddev =3D 0.164/0.170/0.180/0.005 ms >>> >>> As you see, w/o MSIX, RTT increases by a factor of 3. >>> >>> I also tested the following drivers: >>> =A0 =A0- igb(4) from HEAD: OK. >>> =A0 =A0- Stock 7.3-RELEASE: OK. >>> =A0 =A0- Stock 7.4-RELEASE: problem exist. >>> >>> Any ideas? >>> >>> >>> >>> >>> >> _______________________________________________ >> 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 Oct 3 08:20:46 2011 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 10A2A106564A for ; Mon, 3 Oct 2011 08:20:46 +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 859E88FC0A for ; Mon, 3 Oct 2011 08:20:45 +0000 (UTC) Received: by wyj26 with SMTP id 26so3867737wyj.13 for ; Mon, 03 Oct 2011 01:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e3CWFvVGrX7aYKxJn4X+pHaaOeL8SUPIeSIKVGxIKn0=; b=jtnizmInOehAL+MOpPwDdkLZpt2c6O2CsyIafv+4xi+tvmOU0V2WpU6mKNrSGzmZzn ilhEwjQjK9PWp14czTWajGyod7DO5HntLUlK3O9DhrHnEWMn3DiJllVXd1OYymcKaztG pSGCEyLSO+/vwY95Ro/YaSbVHG8CWTLtTwzR8= MIME-Version: 1.0 Received: by 10.227.42.136 with SMTP id s8mr1492169wbe.28.1317630044400; Mon, 03 Oct 2011 01:20:44 -0700 (PDT) Received: by 10.180.106.35 with HTTP; Mon, 3 Oct 2011 01:20:44 -0700 (PDT) In-Reply-To: <4E896999.3020001@sepehrs.com> References: <4E886A3B.7000502@sepehrs.com> <4E896999.3020001@sepehrs.com> Date: Mon, 3 Oct 2011 01:20:44 -0700 Message-ID: From: Jack Vogel To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: Re: em(4) high latency w/o msix 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, 03 Oct 2011 08:20:46 -0000 Can you try the driver in 8.2 and possibly stable/8 to see the behavior there. And, just curious, why are you disabling MSIX? Jack On Mon, Oct 3, 2011 at 12:51 AM, Hooman Fazaeli wrote: > ** > Hi Jack > > The hardware is a PCIe network appliance with 3 port modules. The ports I > have > used in the test are 82574L residing on a 4 port module. Anyway, as I noted > in last mail, the stock 7.3-RELEASE driver does not expose this problem on > the same hardware. > > > On 10/2/2011 7:38 PM, Jack Vogel wrote: > > On what hardware? > > Jack > > > On Sun, Oct 2, 2011 at 6:42 AM, Hooman Fazaeli wrote: > >> >> Latest em(4) driver from HEAD seems to have high latency >> when MSIX is disabled. >> >> With MSIX enabled (hw.em.enable_msix=1): >> >> # ping -c5 192.168.1.83 >> PING 192.168.1.83 (192.168.1.83): 56 data bytes >> 64 bytes from 192.168.1.83: icmp_seq=0 ttl=64 time=0.055 ms >> 64 bytes from 192.168.1.83: icmp_seq=1 ttl=64 time=0.076 ms >> 64 bytes from 192.168.1.83: icmp_seq=2 ttl=64 time=0.066 ms >> 64 bytes from 192.168.1.83: icmp_seq=3 ttl=64 time=0.051 ms >> 64 bytes from 192.168.1.83: icmp_seq=4 ttl=64 time=0.063 ms >> >> --- 192.168.1.83 ping statistics --- >> 5 packets transmitted, 5 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.051/0.062/0.076/0.009 ms >> >> With MSIX disabled: >> >> # ping -c5 192.168.1.83 >> PING 192.168.1.83 (192.168.1.83): 56 data bytes >> 64 bytes from 192.168.1.83: icmp_seq=0 ttl=64 time=0.180 ms >> 64 bytes from 192.168.1.83: icmp_seq=1 ttl=64 time=0.164 ms >> 64 bytes from 192.168.1.83: icmp_seq=2 ttl=64 time=0.169 ms >> 64 bytes from 192.168.1.83: icmp_seq=3 ttl=64 time=0.172 ms >> 64 bytes from 192.168.1.83: icmp_seq=4 ttl=64 time=0.167 ms >> >> --- 192.168.1.83 ping statistics --- >> 5 packets transmitted, 5 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.164/0.170/0.180/0.005 ms >> >> As you see, w/o MSIX, RTT increases by a factor of 3. >> >> I also tested the following drivers: >> - igb(4) from HEAD: OK. >> - Stock 7.3-RELEASE: OK. >> - Stock 7.4-RELEASE: problem exist. >> >> Any ideas? >> >> >> >> >> > From owner-freebsd-net@FreeBSD.ORG Mon Oct 3 10:21:57 2011 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 B4B4B106566B for ; Mon, 3 Oct 2011 10:21:57 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1568FC0C for ; Mon, 3 Oct 2011 10:21:57 +0000 (UTC) Received: by iadk27 with SMTP id k27so7099941iad.13 for ; Mon, 03 Oct 2011 03:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QnIo/fiDnWBDX9WquGafmUJWhSRkkbSB0lhT+0Rgojw=; b=q21+4HksjBm/sVR/Ht3hW9x10sqvLv1slnmgAjBCkeyAM3ZwhCLi6GTuwqlAmYomu8 sPOP0DLaZ8WiPM1ylG1G+e30L2zT6Xf9Km3GOfqh/N99/WCs2AnSfwq805KWVrqTYWNJ Y83hLurYiCAE+SKO74WfhKzZ9TcX00dO6r/eQ= MIME-Version: 1.0 Received: by 10.231.46.66 with SMTP id i2mr9956956ibf.0.1317637316813; Mon, 03 Oct 2011 03:21:56 -0700 (PDT) Received: by 10.231.12.138 with HTTP; Mon, 3 Oct 2011 03:21:56 -0700 (PDT) In-Reply-To: References: <4E886A3B.7000502@sepehrs.com> <4E896999.3020001@sepehrs.com> Date: Mon, 3 Oct 2011 13:21:56 +0300 Message-ID: From: Sami Halabi To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Hooman Fazaeli Subject: Re: em(4) high latency w/o msix 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, 03 Oct 2011 10:21:57 -0000 Hi, Sorry for the questuion. what are the benefits of MSIX ? i don't have on my FREEBSD 8.1-R a sysctl hw.em.msix ... i have em card 82751EB. is msix NIX related? Thanks in advance, Sami On Mon, Oct 3, 2011 at 11:20 AM, Jack Vogel wrote: > Can you try the driver in 8.2 and possibly stable/8 to see the behavior > there. > > And, just curious, why are you disabling MSIX? > > Jack > > > On Mon, Oct 3, 2011 at 12:51 AM, Hooman Fazaeli > wrote: > > > ** > > Hi Jack > > > > The hardware is a PCIe network appliance with 3 port modules. The ports I > > have > > used in the test are 82574L residing on a 4 port module. Anyway, as I > noted > > in last mail, the stock 7.3-RELEASE driver does not expose this problem > on > > the same hardware. > > > > > > On 10/2/2011 7:38 PM, Jack Vogel wrote: > > > > On what hardware? > > > > Jack > > > > > > On Sun, Oct 2, 2011 at 6:42 AM, Hooman Fazaeli >wrote: > > > >> > >> Latest em(4) driver from HEAD seems to have high latency > >> when MSIX is disabled. > >> > >> With MSIX enabled (hw.em.enable_msix=1): > >> > >> # ping -c5 192.168.1.83 > >> PING 192.168.1.83 (192.168.1.83): 56 data bytes > >> 64 bytes from 192.168.1.83: icmp_seq=0 ttl=64 time=0.055 ms > >> 64 bytes from 192.168.1.83: icmp_seq=1 ttl=64 time=0.076 ms > >> 64 bytes from 192.168.1.83: icmp_seq=2 ttl=64 time=0.066 ms > >> 64 bytes from 192.168.1.83: icmp_seq=3 ttl=64 time=0.051 ms > >> 64 bytes from 192.168.1.83: icmp_seq=4 ttl=64 time=0.063 ms > >> > >> --- 192.168.1.83 ping statistics --- > >> 5 packets transmitted, 5 packets received, 0.0% packet loss > >> round-trip min/avg/max/stddev = 0.051/0.062/0.076/0.009 ms > >> > >> With MSIX disabled: > >> > >> # ping -c5 192.168.1.83 > >> PING 192.168.1.83 (192.168.1.83): 56 data bytes > >> 64 bytes from 192.168.1.83: icmp_seq=0 ttl=64 time=0.180 ms > >> 64 bytes from 192.168.1.83: icmp_seq=1 ttl=64 time=0.164 ms > >> 64 bytes from 192.168.1.83: icmp_seq=2 ttl=64 time=0.169 ms > >> 64 bytes from 192.168.1.83: icmp_seq=3 ttl=64 time=0.172 ms > >> 64 bytes from 192.168.1.83: icmp_seq=4 ttl=64 time=0.167 ms > >> > >> --- 192.168.1.83 ping statistics --- > >> 5 packets transmitted, 5 packets received, 0.0% packet loss > >> round-trip min/avg/max/stddev = 0.164/0.170/0.180/0.005 ms > >> > >> As you see, w/o MSIX, RTT increases by a factor of 3. > >> > >> I also tested the following drivers: > >> - igb(4) from HEAD: OK. > >> - Stock 7.3-RELEASE: OK. > >> - Stock 7.4-RELEASE: problem exist. > >> > >> Any ideas? > >> > >> > >> > >> > >> > > > _______________________________________________ > 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" > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Mon Oct 3 11:07:12 2011 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 3D9361065679 for ; Mon, 3 Oct 2011 11:07:12 +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 2BA058FC17 for ; Mon, 3 Oct 2011 11:07:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p93B7CC3033836 for ; Mon, 3 Oct 2011 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p93B7B4G033834 for freebsd-net@FreeBSD.org; Mon, 3 Oct 2011 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Oct 2011 11:07:11 GMT Message-Id: <201110031107.p93B7B4G033834@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, 03 Oct 2011 11:07:12 -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/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159602 net [netinet] [patch] arp_ifscrub() is called even if IFF_ o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/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/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] 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/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 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti 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/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 p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) 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/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/138620 net [lagg] [patch] lagg port bpf-writes blocked 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 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i 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/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t 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/135502 net [periodic] Warning message raised by rtfree function i 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/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c 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/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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network 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 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/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 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 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/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() 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/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection 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/125442 net [carp] [lagg] CARP combined with LAGG causes system pa 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/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one 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 conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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 f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge 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/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 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net 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/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module 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 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/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/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/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack 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 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 s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if 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 a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong 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/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps 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 f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 386 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 3 15:36:54 2011 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 5BFAC106564A for ; Mon, 3 Oct 2011 15:36:54 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 2DBC58FC0A for ; Mon, 3 Oct 2011 15:36:54 +0000 (UTC) Received: from [127.0.0.1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p93FadV1067956 for ; Mon, 3 Oct 2011 08:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1317656200; bh=tfRC3076VZMs2U6gPHJqkSQFXH0u1OFZ+R26hAS6IdQ=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version: Content-Transfer-Encoding; b=kFUgm7ZJ4KqfPKnhHVYMnHW14YSOeTBKknE3wW6HKyPd8tfXtvkLEAhBupqjJ09F7 hxe22A/lx+idJ7gb1N3wE4h+CG8j3aKzTlDCui1RYYgZQXTXGHYnbKTiVP5gloG6nh cj/PSv7090/rLPk7qY7q67t78EmRBK4U5v96GYfY= From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Mon, 03 Oct 2011 08:36:39 -0700 Message-ID: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Subject: Broadcom Docs 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, 03 Oct 2011 15:36:54 -0000 Didn't realize this until my ride to work today, but Broadcom has their programming spec/docs up on a public page. Just thought folks would like to know. http://www.broadcom.com/support/ethernet_nic/open_source.php Sean From owner-freebsd-net@FreeBSD.ORG Mon Oct 3 18:33:03 2011 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 DB4941065670 for ; Mon, 3 Oct 2011 18:33:03 +0000 (UTC) (envelope-from lacombar@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 6E23F8FC08 for ; Mon, 3 Oct 2011 18:33:03 +0000 (UTC) Received: by wyj26 with SMTP id 26so4689007wyj.13 for ; Mon, 03 Oct 2011 11:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Xht2V7uYhEWOFh2GMwg09yn/+JeNfyq+zWSwDVlZauk=; b=O7wFCsQfEWbohqe6IdZHgu0k72Lw2jb2L4uWla2ffzN/JvQOXwfbUmKwDK+6idQEu8 spWsxaLqCfhOVC5yGnGD2sZRbsLTEdSWXq3KWlhH9eFkYLiUFnhF+qvHzZuk9IoOUa+i WQq735QTYTnrd8Uw74tqYYhp9ZMn62toipc54= MIME-Version: 1.0 Received: by 10.227.175.77 with SMTP id w13mr297220wbz.36.1317666782097; Mon, 03 Oct 2011 11:33:02 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Mon, 3 Oct 2011 11:33:02 -0700 (PDT) In-Reply-To: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> Date: Mon, 3 Oct 2011 14:33:02 -0400 Message-ID: From: Arnaud Lacombe To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" Subject: Re: Broadcom Docs 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, 03 Oct 2011 18:33:03 -0000 Hi, On Mon, Oct 3, 2011 at 11:36 AM, Sean Bruno wrote: > Didn't realize this until my ride to work today, but Broadcom has their > programming spec/docs up on a public page. =A0Just thought folks would > like to know. > > http://www.broadcom.com/support/ethernet_nic/open_source.php > That is a very useful information, thanks Sean. This might re-qualify in the future broadcom NICs in my head, and eventually compete with Intel NICs. - Arnaud > Sean > > _______________________________________________ > 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 Oct 3 19:06:44 2011 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 7D3481065678 for ; Mon, 3 Oct 2011 19:06:44 +0000 (UTC) (envelope-from graudeejs@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0BFEE8FC0A for ; Mon, 3 Oct 2011 19:06:43 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so6781940bkb.13 for ; Mon, 03 Oct 2011 12:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=TND/4e3bilEr7v7QDSLsfFGUr3RjgvW9cT3LJlylI34=; b=AOMHwRgbJUtgMoVmvxGqOi0m9URc/hLLXQ+r8koinMUzbmKJ6yUD25U3FR1YAukqq3 M8z6f3/1q/cQanxl74HHqwM+3R5Ix+bSnvNVM651zsscJN0Bb/u/SZeOEeffzRAjB7pN b/W6FrvW98xByH/G7b9zDNhh6FsL3M6dJ+bPk= Received: by 10.204.153.23 with SMTP id i23mr163779bkw.128.1317667062402; Mon, 03 Oct 2011 11:37:42 -0700 (PDT) Received: from desktop.pc (mpe-11-155.mpe.lv. [83.241.11.155]) by mx.google.com with ESMTPS id l15sm14097757bkw.9.2011.10.03.11.37.41 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 11:37:42 -0700 (PDT) Date: Mon, 3 Oct 2011 21:37:09 +0300 From: Aldis Berjoza Cc: freebsd-net@freebsd.org Message-ID: <20111003213709.692183a8@desktop.pc> In-Reply-To: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/e8NABl7p.gJG5ac1VSaeBl+"; protocol="application/pgp-signature" Subject: Re: Broadcom Docs 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, 03 Oct 2011 19:06:44 -0000 --Sig_/e8NABl7p.gJG5ac1VSaeBl+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 03 Oct 2011 08:36:39 -0700 Sean Bruno wrote: > Didn't realize this until my ride to work today, but Broadcom has > their programming spec/docs up on a public page. Just thought folks > would like to know. >=20 > http://www.broadcom.com/support/ethernet_nic/open_source.php Thanks for this precious info --=20 Aldis Berjoza http://www.bsdroot.lv/ --Sig_/e8NABl7p.gJG5ac1VSaeBl+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJOigDyAAoJECrA2xnMujn6HekH/3OuoHqPQwlQhuzXqvK2UJhK v+240Ae4cwvVKRS+elWiXh6+rNs3+SePZQNRpAZMK0qTnJEVmvDcNeOqvYsNdoW0 TRF3MkvRJSWwyRmvMgRYGjQY21Ycadkb/GBxYFbag+6bo7/vpEf9S+5gXRW2vOzk +3TvzolYj6DshMzkuk5m4OY0DlMFR7bs807OxEM+VeLLEpzOR/guiZ1rzKRvlgv1 utF6WOGOPfCPrurBiykhjOKV1iRSD+VObR6A9dCiP5ksVRMg5Iyjuw+7AhHB9jvG irSrwV/uJ/6lmzd6vZljgwzGRYiOkjJY/3FRRzpaGhHlLE9pCNYUIxs4C6iS6ss= =p06K -----END PGP SIGNATURE----- --Sig_/e8NABl7p.gJG5ac1VSaeBl+-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 3 20:43:01 2011 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 1DC08106566B for ; Mon, 3 Oct 2011 20:43:01 +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 026AF8FC0A for ; Mon, 3 Oct 2011 20:43:00 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p93KgvDG012831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Oct 2011 13:42:57 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Mon, 3 Oct 2011 13:42:52 -0700 From: "Li, Qing" To: Matt Smith , "freebsd-net@freebsd.org" Thread-Topic: gif interface not passing IPv6 packets Thread-Index: AQHMfDK/mwfhA1dz/UeEmS2mO8Ay5pVrIOAw Date: Mon, 3 Oct 2011 20:42:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: gif interface not passing IPv6 packets 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, 03 Oct 2011 20:43:01 -0000 Hi, I saw the thread but I was traveling the whole of last week, did not=20 have a system to work on. The problem you encountered on gif was due to a bug in the IPv6 code. I believe have a patch but I need to do more testing. I will post it shortl= y. --Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Matt Smith > Sent: Monday, September 26, 2011 2:28 AM > To: freebsd-net@freebsd.org > Subject: gif interface not passing IPv6 packets >=20 > I have a very strange problem with a gif interface that has been > confusing me all weekend. For the last six months I have had a gif > tunnel setup to an ipv6 tunnel broker which has worked without any > issues. On Friday I had a power cut. The power returned, the server > restarted, and the tunnel has been down since. I have checked and > rechecked the configuration and it all looks identical to what I would > expect. I've even gone as far as running a buildworld/kernel in case > the power outage corrupted something. >=20 > The problem is that the gif interface doesn't appear to be processing > any IPv6 packets at all, though it works fine with IPv4. I can't ping > my side of the tunnel. For example: >=20 > root@tao[~]# ifconfig gif0 > gif0: flags=3D8051 metric 0 mtu 1280 > tunnel inet 192.168.1.2 --> 77.75.104.126 > inet6 fe80::240:63ff:fee8:793e%gif0 prefixlen 64 scopeid 0x5 > inet6 2a01:348:6:45c::2 --> 2a01:348:6:45c::1 prefixlen 128 > deprecated > nd6 options=3D3 > options=3D1 >=20 > root@tao[~]# ping6 2a01:348:6:45c::2 > PING6(56=3D40+8+8 bytes) 2a01:348:6:45c::2 --> 2a01:348:6:45c::2 >=20 > root@tao[~]# tcpdump -i gif0 > listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes > 10:15:12.545930 IP6 cl-1117.lon-02.gb.sixxs.net > > cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 0, length 16 > 10:15:13.546316 IP6 cl-1117.lon-02.gb.sixxs.net > > cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 1, length 16 > 10:15:14.546220 IP6 cl-1117.lon-02.gb.sixxs.net > > cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 2, length 16 >=20 > I've deleted other lines from the tcpdump like neighbour solicitation > and only shown the pings. But there is no ping response, only the > request. >=20 > Traceroute shows similar: >=20 > root@tao[~]# traceroute6 2a01:348:6:45c::2 > traceroute6 to 2a01:348:6:45c::2 (2a01:348:6:45c::2) from > 2a01:348:6:45c::2, 64 hops max, 12 byte packets > 1 * * * >=20 > If I create an entire new interface, same problem, but as you can see > works fine with IPv4: >=20 > root@tao[~]# ifconfig gif1 create > root@tao[~]# ifconfig gif1 tunnel 192.168.1.2 1.2.3.4 > root@tao[~]# ifconfig gif1 inet6 2abc::2 2abc::1 prefixlen 128 > root@tao[~]# ping6 2abc::2 > PING6(56=3D40+8+8 bytes) 2abc::2 --> 2abc::2 > ^C > --- 2abc::2 ping6 statistics --- > 3 packets transmitted, 0 packets received, 100.0% packet loss >=20 > root@tao[~]# ifconfig gif1 10.1.1.1 10.1.1.2 > root@tao[~]# ping 10.1.1.1 > PING 10.1.1.1 (10.1.1.1): 56 data bytes > 64 bytes from 10.1.1.1: icmp_seq=3D0 ttl=3D64 time=3D0.105 ms > 64 bytes from 10.1.1.1: icmp_seq=3D1 ttl=3D64 time=3D0.084 ms > 64 bytes from 10.1.1.1: icmp_seq=3D2 ttl=3D64 time=3D0.098 ms > ^C > --- 10.1.1.1 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 0.084/0.096/0.105/0.009 ms > root@tao[~]# ifconfig gif1 destroy >=20 > I'm running FreeBSD 8.2-RELEASE-p2. ipfw is compiled in the kernel > however even if I flush all the rules so that it's just left with a > default allow rule the same thing happens. And as I said before unless > I'm being really blind and missed something obvious this config worked > fine before my power outage! >=20 > Here is my routing table for gif0: >=20 > root@tao[~]# netstat -rn | grep gif0 > default 2a01:348:6:45c::1 UGS > gif0 > 2a01:348:6:45c::1 2a01:348:6:45c::2 UH > gif0 > fe80::%gif0/64 link#5 U > gif0 > fe80::240:63ff:fee8:793e%gif0 link#5 UHS > lo0 > ff01:5::/32 fe80::240:63ff:fee8:793e%gif0 U > gif0 > ff02::%gif0/32 fe80::240:63ff:fee8:793e%gif0 U > gif0 >=20 > And here are my firewall rules to prove it's flushed: >=20 > root@tao[~]# ipfw list > 65535 allow ip from any to any >=20 > Thanks for any help or suggestions, Regards Matt. > _______________________________________________ > 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 Oct 3 20:58:24 2011 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 810A5106564A for ; Mon, 3 Oct 2011 20:58:24 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 392618FC1B for ; Mon, 3 Oct 2011 20:58:24 +0000 (UTC) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id 22CAAB07543 for ; Mon, 3 Oct 2011 21:58:20 +0100 (BST) Received: by vws11 with SMTP id 11so4524185vws.13 for ; Mon, 03 Oct 2011 13:58:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.29.46 with SMTP id g14mr391807vdh.295.1317675498773; Mon, 03 Oct 2011 13:58:18 -0700 (PDT) Received: by 10.52.159.103 with HTTP; Mon, 3 Oct 2011 13:58:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Oct 2011 21:58:18 +0100 Message-ID: From: Matt Smith To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" Subject: Re: gif interface not passing IPv6 packets 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, 03 Oct 2011 20:58:24 -0000 On 3 October 2011 21:42, Li, Qing wrote: > > Hi, > > I saw the thread but I was traveling the whole of last week, did not > have a system to work on. > > The problem you encountered on gif was due to a bug in the IPv6 code. > > I believe have a patch but I need to do more testing. I will post it shortly. > > --Qing Just to let you know that I was doing a lot of testing off of the mailing list with Hiroki Sato and we basically discovered that I was missing an alias on my lo0 interface. He first advised me to try testing with adding a /126 to gif0 rather than a /128 which worked successfully. Then he advised me to go back to the original configuration but also run ifconfig lo0 2a01:348:6:45c::2/128 alias which added the correct routes and resolved the problem. Whilst this is a workaround it obviously doesn't resolve the actual root cause so thank you if you come up with a patch. I'm still really confused though why it worked before my power failure and failed afterwards when as far as I'm aware nothing has changed on the system. I'll await the patch and test it out when you post it. Regards, Matt. From owner-freebsd-net@FreeBSD.ORG Mon Oct 3 21:33:19 2011 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 9F76D1065672 for ; Mon, 3 Oct 2011 21:33:19 +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 67CD78FC14 for ; Mon, 3 Oct 2011 21:33:19 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (sai-rp.bluecoat.com [10.2.2.126] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p93LXISc029937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Oct 2011 14:33:18 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Mon, 3 Oct 2011 14:33:13 -0700 From: "Li, Qing" To: Matt Smith Thread-Topic: gif interface not passing IPv6 packets Thread-Index: AQHMgg8yZV0c+F5nhEi3jhFEMbgUgJVrHidg Date: Mon, 3 Oct 2011 21:33:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: gif interface not passing IPv6 packets 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, 03 Oct 2011 21:33:19 -0000 >=20 > Just to let you know that I was doing a lot of testing off of the > mailing list with Hiroki Sato and we basically discovered that I was > missing an alias on my lo0 interface. He first advised me to try > testing with adding a /126 to gif0 rather than a /128 which worked > successfully. Then he advised me to go back to the original > configuration but also run ifconfig lo0 2a01:348:6:45c::2/128 alias > which added the correct routes and resolved the problem. Whilst this > is a workaround it obviously doesn't resolve the actual root cause so > thank you if you come up with a patch. >=20 You don't need any aliases to make this configuration work.=20 Adding the interface alias triggers the code that installs the=20 proper routing entry for the local end of the gif tunnel. The suggested workaround (wrt configuring aliases and lo0 manipulation) is no different from doing the following: ifconfig gif create ifconfig gif0 inet6 -ifdisabled 2a01:348:6:45c::2 ifconfig gif0 inet6 2a01:348:6:45c::2 2a01:348:6:45c::1 > > I'm still really confused though why it worked before my power failure > and failed afterwards when as far as I'm aware nothing has changed on > the system. >=20 > I'll await the patch and test it out when you post it. > The root cause is in the use of "IFA_ROUTE" and "IFA_RTSELF" flags. For any IFF_POINTOPOINT interface, the IFA_ROUTE is an indication both end of the tunnel has been specified and the proper route has been installed. IFA_RTSELF is a flag that indicates a route over the lo0 interface=20 has been appropriated for the interface address.=20 Please give the following patch a try and let me know how it works out for you. http://people.freebsd.org/~qingli/in6.c.diff --Qing From owner-freebsd-net@FreeBSD.ORG Mon Oct 3 23:06:42 2011 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 212E8106566B; Mon, 3 Oct 2011 23:06:42 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id CBCAF8FC16; Mon, 3 Oct 2011 23:06:41 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p93N6JCc041089; Mon, 3 Oct 2011 16:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1317683179; bh=6Jpol+jfrYMOBllc7LNR3zt7nnL1HDQk9+tDqJJ2ajg=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=CA9OZNgXeJJWWvHRFM2h4KrvC+FxXc3CMCRYWAq9PLs2JP2QT+rwVThBdqz2GlKaW Vjm+cOnQuWjbECaXLxrub0gn7u89vclaBMQzOnq8JuGFoAxbo6ke4jxyw+UGf+vZH9 wt2EuByPhEgNoLst7aM37fowkJOs1J+r1FejiDUc= From: Sean Bruno To: David Christensen In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 03 Oct 2011 16:06:18 -0700 Message-ID: <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "davidch@freebsd.org" , Pyun YongHyeon Subject: RE: bce(4) with IPMI 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, 03 Oct 2011 23:06:42 -0000 On Mon, 2011-10-03 at 15:30 -0700, David Christensen wrote: > > > > I should probably say, this is freebsd7. So I'll peruse the > > changelogs > > > > and see if 7 is missing something here. > > > > > > > > sean > > > > > > commenting this change out seems to be helping quite a bit with my > > > issue. I think that this behavior may be wrong in the IPMI shared/nic > > > case. Thoughts? > > > > > > > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210261&r2=210263 > > > > The main reason bce(4) needs to coordinate with NC-SI/IPMI > firmware is to make sure only one software entity manipulates > PHY registers. When bce(4) is loaded it will have priority > over firmware (e.g. autoneg, speed, and duplex settings will > be set by the host). If you don't bring up the interface in > the host the firmware isn't authorized to do so, which sounds > like your problem. > > Current bce(4) behavior notifies firmware that host driver > is running when resetting the device in bce_attach(). We > tell firmware that host driver is still running through > bce_pulse(). Not sure how to handle the FreeBSD model where > the driver load doesn't immediately bring the link up. > > Dave > Hrm, understood. What are your thoughts on noting that the IPMI f/w is running and leaving the interface up? I'm poking around trying to find the right register bits at initialization to see that this is the case. What's even more strange is that our freebsd6 instances don't have this problem. Sean From owner-freebsd-net@FreeBSD.ORG Mon Oct 3 23:29:42 2011 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 C3686106564A for ; Mon, 3 Oct 2011 23:29:42 +0000 (UTC) (envelope-from lacombar@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 59D3D8FC08 for ; Mon, 3 Oct 2011 23:29:42 +0000 (UTC) Received: by wyj26 with SMTP id 26so5029700wyj.13 for ; Mon, 03 Oct 2011 16:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n44OV5ELBOOkMngFLnuk5pZ8iNrLjoWCHv3+ivqiB/0=; b=YZLQSP0pp7AjcrAOD+VteD+Ufo1rsu0I6jqNAsVFqucKEW4P4GeUUiTL5dvn/r++FJ SpbCFTUCE0h4CaCjpCKvcMrk1FLUcBNp0x8IiNFvv7J+rf6dGvtVGV+sn5ZIjsNdcfBH M3DfKA0zeFD3OjSwjWObFkgNhRF8tqFx9Jryg= MIME-Version: 1.0 Received: by 10.227.135.130 with SMTP id n2mr557883wbt.51.1317684581240; Mon, 03 Oct 2011 16:29:41 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Mon, 3 Oct 2011 16:29:41 -0700 (PDT) In-Reply-To: References: <4E428B34.7020205@tutus.se> Date: Mon, 3 Oct 2011 19:29:41 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Tomas Svensson Subject: Re: em driver support for Intel 82579LM still buggy in FreeBSD 9.0-BETA1 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, 03 Oct 2011 23:29:42 -0000 Hi, On Wed, Aug 10, 2011 at 12:23 PM, Jack Vogel wrote: > I have limited access to this hardware, I am told I will tomorrow, and will > repro > and test a fix that I have in mind, so stay tuned. I just noticed this bug > is at > a low priority, it should be higher than that. > After 2 months, what the status on this issue ? Thanks, - Arnaud > Jack > > > On Wed, Aug 10, 2011 at 6:44 AM, Tomas Svensson wrote: > >> Hi, >> >> I sent a pr (kern/157418) that the em driver seems to be buggy for Intel >> 82579LM Gigabit Network Connection which passed unnoticed. I now tried >> it in FreeBSD 9.0-BETA1 and the problem is still present. >> >> Does anyone else have this problem or have any ideas on how to fix it? I >> assume that the initialization code for this chip is buggy, since the >> driver locks up depending on if you build it with debug symbols or not. >> The kernel also reports 'acquiring duplicate lock of same type: "network >> driver"' only for this chip. >> >> -Tomas >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 00:00:25 2011 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 3C087106566C for ; Tue, 4 Oct 2011 00:00:25 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 694728FC15 for ; Tue, 4 Oct 2011 00:00:24 +0000 (UTC) Received: from alph.allbsd.org (p1023-ipbf1601funabasi.chiba.ocn.ne.jp [123.220.25.23]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p93Nxu0f080917; Tue, 4 Oct 2011 09:00:06 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p93Nxmr1007337; Tue, 4 Oct 2011 08:59:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 04 Oct 2011 08:59:35 +0900 (JST) Message-Id: <20111004.085935.2022185336256720622.hrs@allbsd.org> To: qing.li@bluecoat.com From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Oct__4_08_59_35_2011_336)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Tue, 04 Oct 2011 09:00:12 +0900 (JST) X-Spam-Status: No, score=-95.8 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, DIRECTOCNDYN, DYN_PBL, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org, matt@xtaz.co.uk Subject: Re: gif interface not passing IPv6 packets 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, 04 Oct 2011 00:00:25 -0000 ----Security_Multipart(Tue_Oct__4_08_59_35_2011_336)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Li, Qing" wrote in : qi> > qi> > Just to let you know that I was doing a lot of testing off of the qi> > mailing list with Hiroki Sato and we basically discovered that I was qi> > missing an alias on my lo0 interface. He first advised me to try qi> > testing with adding a /126 to gif0 rather than a /128 which worked qi> > successfully. Then he advised me to go back to the original qi> > configuration but also run ifconfig lo0 2a01:348:6:45c::2/128 alias qi> > which added the correct routes and resolved the problem. Whilst this qi> > is a workaround it obviously doesn't resolve the actual root cause so qi> > thank you if you come up with a patch. qi> > qi> qi> You don't need any aliases to make this configuration work. qi> qi> Adding the interface alias triggers the code that installs the qi> proper routing entry for the local end of the gif tunnel. qi> qi> The suggested workaround (wrt configuring aliases and lo0 manipulation) qi> is no different from doing the following: Correct, but doing configuration on the same interface multiple times except for adding aliases in our rc.conf framework is trickier so I suggested adding an alias to lo0. It is not the best way, of course. -- Hiroki ----Security_Multipart(Tue_Oct__4_08_59_35_2011_336)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6KTGcACgkQTyzT2CeTzy0WzgCgqi/cvzvVq68g+T/AlapU+uJN ro8An0gNNxwtCFJPFGcoCFKYWRwe/63d =qIYc -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Oct__4_08_59_35_2011_336)---- From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 00:57:26 2011 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 E3F9E106564A for ; Tue, 4 Oct 2011 00:57:26 +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 C99DB8FC14 for ; Tue, 4 Oct 2011 00:57:26 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p940vN59001210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Oct 2011 17:57:23 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Mon, 3 Oct 2011 17:57:18 -0700 From: "Li, Qing" To: Rainer Bredehorn , "freebsd-net@freebsd.org" Thread-Topic: IPv6 multicast listener discovery Thread-Index: AQHMfqenOAPZZJYAZUKcZ9p0f7u9qJVrYpdw Date: Tue, 4 Oct 2011 00:57:17 +0000 Message-ID: References: <20110929123201.282750@gmx.net> In-Reply-To: <20110929123201.282750@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Subject: RE: IPv6 multicast listener discovery 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, 04 Oct 2011 00:57:27 -0000 SGksDQoNClRoaXMgYWRkcmVzcyBpcyBmb3IgSVB2NiBOb2RlIEluZm9ybWF0aW9uIFF1ZXJ5LCBj YWxsZWQgdGhlIE5JIEdyb3VwIEFkZHJlc3MuDQoNCkZvciBleGFtcGxlLCB5b3UgY2FuIGlzc3Vl IHRoZSBjb21tYW5kDQoNCglwaW5nNiAtdyBmZTgwOjoyNTA6ZmNmZjpmZWI4OjU0NDMlcmwwDQoN CnlvdSBjYW4gZ2V0IHlvdXIgaG9zdG5hbWUgYmFjay4NCg0KLS1RaW5nDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1mcmVlYnNkLW5ldEBmcmVlYnNkLm9y ZyBbbWFpbHRvOm93bmVyLWZyZWVic2QtDQo+IG5ldEBmcmVlYnNkLm9yZ10gT24gQmVoYWxmIE9m IFJhaW5lciBCcmVkZWhvcm4NCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyOSwgMjAxMSA1 OjMyIEFNDQo+IFRvOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZw0KPiBTdWJqZWN0OiBJUHY2IG11 bHRpY2FzdCBsaXN0ZW5lciBkaXNjb3ZlcnkNCj4gDQo+IEhpIQ0KPiANCj4gVGhlIEZyZWVCU0Qg OC4yIHNlbmRzIHNldmFyYWwgTUxEdjIgbGlzdGVuZXIgcmVwb3J0cyBkdXJpbmcgc3RhcnR1cC4N Cj4gVGhlIHN5c3RlbSBzZW5kcyBvbmUgbGlzdGVuZXIgcmVwb3J0IHdpdGggaXRzIHNvbGljaXRl ZCBtdWx0aWNhc3QNCj4gYWRkcmVzcyB3aGljaCBjb21lcyBmcm9tIHRoZSBhdXRvbWF0aWNhbGx5 IGdlbmVyYXRlZCBsaW5rIGxvY2FsIGFkZHJlc3MuDQo+IEJ1dCBJIGNhbiBzZWUgYW5vdGhlciBN TEQyIGxpc3RlbmVyIHJlcG9ydCB3aXRoIDIgcmVjb3Jkcy4gT25lIGlzIHRoZQ0KPiBtZW50aW9u ZWQgc29saWNpdGVkIG11bHRpY2FzdCBhZGRyZXNzLg0KPiBUaGUgb3RoZXIgb25lIGlzIGUuZy4g ZmYwMjo6MjoyZDc1OmYyYjguDQo+IA0KPiBJJ3ZlIG5vIGlkZWFkIHdoZXJlIGl0IGNvbWVzIGZy b20uIFRoZSBpbnRlcmZhY2UgaGFzIG9ubHkgb24gbGluayBsb2NhbA0KPiBhZGRyZXNzLg0KPiBJ dCBtaWdodCBiZSBhIGJ1ZyBpbiBGcmVlQlNEIDguMg0KPiANCj4gQmVzdCByZWdhcmRzLCBSYWlu ZXIuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGZyZWVic2QtbmV0QGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiBodHRwOi8vbGlzdHMuZnJl ZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLW5ldA0KPiBUbyB1bnN1YnNjcmliZSwg c2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1uZXQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo= From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 06:44:54 2011 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 B0B9D106566C for ; Tue, 4 Oct 2011 06:44:54 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0428FC13 for ; Tue, 4 Oct 2011 06:44:54 +0000 (UTC) Received: from [93.104.82.195] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RAxo7-0007Fw-7t; Tue, 04 Oct 2011 07:44:47 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id p945ijtq010349; Tue, 4 Oct 2011 07:44:45 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id p945iixd010348; Tue, 4 Oct 2011 07:44:44 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 4 Oct 2011 07:44:44 +0200 From: Matthias Apitz To: Arnaud Lacombe Message-ID: <20111004054444.GA10311@tinyCurrent> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Originating-IP: 93.104.82.195 Cc: "freebsd-net@freebsd.org" , Sean Bruno Subject: Re: Broadcom Docs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 06:44:54 -0000 El día Monday, October 03, 2011 a las 02:33:02PM -0400, Arnaud Lacombe escribió: > Hi, > > On Mon, Oct 3, 2011 at 11:36 AM, Sean Bruno wrote: > > Didn't realize this until my ride to work today, but Broadcom has their > > programming spec/docs up on a public page.  Just thought folks would > > like to know. > > > > http://www.broadcom.com/support/ethernet_nic/open_source.php > > > That is a very useful information, thanks Sean. This might re-qualify > in the future broadcom NICs in my head, and eventually compete with > Intel NICs. I have a laptop Acer Aspire One D250 running 9-CURRENT r214444 (from October 2010). The laptop comes with as Wifi chip: none2@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 USB Controller' class = network I have to use NDIS to make it working and it seems that the 4310 does not show up in their page. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 07:34:47 2011 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 BDA9A106566B for ; Tue, 4 Oct 2011 07:34:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7E83E8FC14 for ; Tue, 4 Oct 2011 07:34:47 +0000 (UTC) Received: by yxk36 with SMTP id 36so249815yxk.13 for ; Tue, 04 Oct 2011 00:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=a/pxhI+QELB1yfBw5Goh7liaERVHGmCyq2dx+Dw5U2U=; b=gPjPJla855ZtyUETvzjX8ynA5KRgk/aD0dSSOlK6Aq5SLEsLswGHJEz+YLWGM8Cr7P VzXCwYt7dMeQPMgJ9JHgrti/0pbNZve3Ug4yVkoQi/2GKqEUy0a+6fhcrTdPoveQxZJa XB/E+B6KnCLQOrqwvdubrnN97JV2WgJ0PEgO8= MIME-Version: 1.0 Received: by 10.236.79.72 with SMTP id h48mr4878042yhe.4.1317713686874; Tue, 04 Oct 2011 00:34:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Tue, 4 Oct 2011 00:34:46 -0700 (PDT) In-Reply-To: <20111004054444.GA10311@tinyCurrent> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> <20111004054444.GA10311@tinyCurrent> Date: Tue, 4 Oct 2011 15:34:46 +0800 X-Google-Sender-Auth: E7jeipUNDaH-aVBiGZH1XKZRyz4 Message-ID: From: Adrian Chadd To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Sean Bruno , Arnaud Lacombe Subject: Re: Broadcom Docs 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, 04 Oct 2011 07:34:47 -0000 That's because it's a wifi chip, not an ethernet chip. We sorely need someone to step up and update the broadcom wifi support. :) adrian From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 08:36:38 2011 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 BD36F106566B for ; Tue, 4 Oct 2011 08:36:38 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 77F878FC19 for ; Tue, 4 Oct 2011 08:36:38 +0000 (UTC) Received: from [82.113.99.174] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RB0UK-0006LQ-KF; Tue, 04 Oct 2011 10:36:34 +0200 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id p948bEeT001069; Tue, 4 Oct 2011 10:37:15 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id p948bB1i001068; Tue, 4 Oct 2011 10:37:11 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Tue, 4 Oct 2011 10:37:10 +0200 From: Matthias Apitz To: Adrian Chadd Message-ID: <20111004083710.GA1054@tiny> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> <20111004054444.GA10311@tinyCurrent> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 82.113.99.174 Cc: "freebsd-net@freebsd.org" , Sean Bruno , Arnaud Lacombe Subject: Re: Broadcom Docs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 08:36:38 -0000 El día Tuesday, October 04, 2011 a las 03:34:46PM +0800, Adrian Chadd escribió: > That's because it's a wifi chip, not an ethernet chip. Yes, I know and I looked around in their pages; there are no Wifi chips; so my question was: why is this? > We sorely need someone to step up and update the broadcom wifi support. :) yes; but with good datasheets this would be more easy; matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 09:48:35 2011 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 22664106566C for ; Tue, 4 Oct 2011 09:48:35 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id C88878FC12 for ; Tue, 4 Oct 2011 09:48:34 +0000 (UTC) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id 0394DB07530 for ; Tue, 4 Oct 2011 10:48:32 +0100 (BST) Received: by vws11 with SMTP id 11so266438vws.13 for ; Tue, 04 Oct 2011 02:48:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.18 with SMTP id i18mr957473vdf.27.1317721710799; Tue, 04 Oct 2011 02:48:30 -0700 (PDT) Received: by 10.52.159.103 with HTTP; Tue, 4 Oct 2011 02:48:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Oct 2011 10:48:30 +0100 Message-ID: From: Matt Smith To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" Subject: Re: gif interface not passing IPv6 packets 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, 04 Oct 2011 09:48:35 -0000 On 3 October 2011 22:33, Li, Qing wrote: > Please give the following patch a try and let me know how it > works out for you. > > =A0 =A0 =A0 =A0http://people.freebsd.org/~qingli/in6.c.diff I have just applied the patch, recompiled the kernel, and rebooted with my original configuration in rc.conf and all interfaces have come up as expected now. The routes are there, I can ping everything, and I can connect to everything as expected. I don't know if this is going to affect 9.0? But if it does could it get committed into that tree to make it into the release? Matt. From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 10:33:26 2011 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 35A151065673 for ; Tue, 4 Oct 2011 10:33:26 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id DF8228FC13 for ; Tue, 4 Oct 2011 10:33:25 +0000 (UTC) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id CB658B07530 for ; Tue, 4 Oct 2011 11:33:24 +0100 (BST) Received: by vcbf13 with SMTP id f13so296518vcb.13 for ; Tue, 04 Oct 2011 03:33:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.69.177 with SMTP id f17mr980601vdu.161.1317724403241; Tue, 04 Oct 2011 03:33:23 -0700 (PDT) Received: by 10.52.159.103 with HTTP; Tue, 4 Oct 2011 03:33:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Oct 2011 11:33:23 +0100 Message-ID: From: Matt Smith To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" Subject: Re: gif interface not passing IPv6 packets 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, 04 Oct 2011 10:33:26 -0000 On 4 October 2011 10:48, Matt Smith wrote: > I have just applied the patch, recompiled the kernel, and rebooted > with my original configuration in rc.conf and all interfaces have come > up as expected now. The routes are there, I can ping everything, and I > can connect to everything as expected. Actually saying that. I've found a problem meaning some of my software is broken now. Just noticed that lo0 doesn't have a ::1 address: lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 If I try and add one I get this: root@tao[~]# ifconfig lo0 inet6 ::1 prefixlen 128 ifconfig: ioctl (SIOCAIFADDR): File exists From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 12:28:03 2011 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 BE8171065674 for ; Tue, 4 Oct 2011 12:28:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE748FC1A for ; Tue, 4 Oct 2011 12:28:03 +0000 (UTC) Received: by ywp17 with SMTP id 17so524113ywp.13 for ; Tue, 04 Oct 2011 05:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4TV3he6yMFUT6mAGN7T+lZfccjmZDfXW0dFqIgOVbrA=; b=ggZOlNxt1hFEfubk5PbaYowkIUFPnEIS5NxZK1Rwxz/iPKPGVpgA7oAi5vJDr/xuFb PZLwvoCkCiNxd6h0nczEnBVpdszpa+dGgp8zFF6zldLJxjIc1DjM7IXDuTr89BUjpbZo BmTosjIrgmOrObpcB7i5uWFKC+dlVRjQOySo4= MIME-Version: 1.0 Received: by 10.236.157.161 with SMTP id o21mr6140784yhk.72.1317731282701; Tue, 04 Oct 2011 05:28:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Tue, 4 Oct 2011 05:28:02 -0700 (PDT) In-Reply-To: <20111004083710.GA1054@tiny> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> <20111004054444.GA10311@tinyCurrent> <20111004083710.GA1054@tiny> Date: Tue, 4 Oct 2011 20:28:02 +0800 X-Google-Sender-Auth: fFfQsXhK-PmUotghNoKYofSRWQI Message-ID: From: Adrian Chadd To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Sean Bruno , Arnaud Lacombe Subject: Re: Broadcom Docs 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, 04 Oct 2011 12:28:03 -0000 On 4 October 2011 16:37, Matthias Apitz wrote: > > yes; but with good datasheets this would be more easy; There's working code for the later chips in Linux and likely (via Linux) OpenBSD. Linux has b43 and brcm drivers. The source is there - what's missing is someone choosing one and porting it to FreeBSD. Both b43 (via reverse engineering) and brcm (via broadcom developers) is getting active development. It'd be nice to have datasheets but you don't need them to port the code over. Adrian From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 12:01:30 2011 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 857AD106564A for ; Tue, 4 Oct 2011 12:01:30 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F0B738FC25 for ; Tue, 4 Oct 2011 12:01:29 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so685653bkb.13 for ; Tue, 04 Oct 2011 05:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=rJ4fgeUeJxsS5S7bCEF8AW0CIFc0R+OKrq49jbUeYEo=; b=eDUyGRUhkr6Myzs3DFMh7f1UxTAMgroscroCjdkgwaXWiXFVxfD3pkz1bF4dKnPtCN fqxo8mCjgd/lmYo/znhvj8naHEXjEwcV0LYB2BdQYlqMF0VKXy/cKiutCaNTi3GU5yeX zLV3BHUue1Aop19e3i9nxUVxGB6SVO/FGMHyw= Received: by 10.204.4.71 with SMTP id 7mr666331bkq.106.1317728206106; Tue, 04 Oct 2011 04:36:46 -0700 (PDT) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id k26sm12587952bks.1.2011.10.04.04.36.43 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 04:36:45 -0700 (PDT) Message-ID: <4E8AEFC5.8050103@gmail.com> Date: Tue, 04 Oct 2011 15:06:37 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , Jack Vogel X-Mailman-Approved-At: Tue, 04 Oct 2011 12:34:11 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: em(4) high latency w/o msix 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, 04 Oct 2011 12:01:30 -0000 8.2-RELEASE and stable/8 have the same problem. Ping RTT triples when MSIX is disabled. On 10/3/2011 11:50 AM, Jack Vogel wrote: > Can you try the driver in 8.2 and possibly stable/8 to see the behavior there. > > And, just curious, why are you disabling MSIX? > > Jack > > > On Mon, Oct 3, 2011 at 12:51 AM, Hooman Fazaeli > wrote: > > Hi Jack > > The hardware is a PCIe network appliance with 3 port modules. The ports I have > used in the test are 82574L residing on a 4 port module. Anyway, as I noted > in last mail, the stock 7.3-RELEASE driver does not expose this problem on > the same hardware. > > > On 10/2/2011 7:38 PM, Jack Vogel wrote: >> On what hardware? >> >> Jack >> >> >> On Sun, Oct 2, 2011 at 6:42 AM, Hooman Fazaeli > wrote: >> >> >> Latest em(4) driver from HEAD seems to have high latency >> when MSIX is disabled. >> >> With MSIX enabled (hw.em.enable_msix=1): >> >> # ping -c5 192.168.1.83 >> PING 192.168.1.83 (192.168.1.83): 56 data bytes >> 64 bytes from 192.168.1.83 : icmp_seq=0 ttl=64 time=0.055 ms >> 64 bytes from 192.168.1.83 : icmp_seq=1 ttl=64 time=0.076 ms >> 64 bytes from 192.168.1.83 : icmp_seq=2 ttl=64 time=0.066 ms >> 64 bytes from 192.168.1.83 : icmp_seq=3 ttl=64 time=0.051 ms >> 64 bytes from 192.168.1.83 : icmp_seq=4 ttl=64 time=0.063 ms >> >> --- 192.168.1.83 ping statistics --- >> 5 packets transmitted, 5 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.051/0.062/0.076/0.009 ms >> >> With MSIX disabled: >> >> # ping -c5 192.168.1.83 >> PING 192.168.1.83 (192.168.1.83): 56 data bytes >> 64 bytes from 192.168.1.83 : icmp_seq=0 ttl=64 time=0.180 ms >> 64 bytes from 192.168.1.83 : icmp_seq=1 ttl=64 time=0.164 ms >> 64 bytes from 192.168.1.83 : icmp_seq=2 ttl=64 time=0.169 ms >> 64 bytes from 192.168.1.83 : icmp_seq=3 ttl=64 time=0.172 ms >> 64 bytes from 192.168.1.83 : icmp_seq=4 ttl=64 time=0.167 ms >> >> --- 192.168.1.83 ping statistics --- >> 5 packets transmitted, 5 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.164/0.170/0.180/0.005 ms >> >> As you see, w/o MSIX, RTT increases by a factor of 3. >> >> I also tested the following drivers: >> - igb(4) from HEAD: OK. >> - Stock 7.3-RELEASE: OK. >> - Stock 7.4-RELEASE: problem exist. >> >> Any ideas? >> >> >> >> >> > From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 13:49:30 2011 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 6445E1065670; Tue, 4 Oct 2011 13:49:30 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 568DE8FC15; Tue, 4 Oct 2011 13:49:29 +0000 (UTC) Received: by eyg7 with SMTP id 7so671275eyg.13 for ; Tue, 04 Oct 2011 06:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=+EkGuB1UoP8wjwElWNSbF4XWzHfJ2Q4tba2j5wNmID8=; b=ByqzUMZ6YhR7Rqdg38CtexzHAqD9wJtHBFlvOHMRvAyvTIok6JAw4su1aoOIurgL4S /S0Nbbompz/KDY6fsLoJoCbfNH7ngvqmzYTHjR70tOobomEPvPy8D6TQsv5wzgxMXNiX IhV8GWc9FCRCPoIYDLjju09HyaeX8SFPsOsHQ= Received: by 10.223.26.210 with SMTP id f18mr1797655fac.51.1317736168342; Tue, 04 Oct 2011 06:49:28 -0700 (PDT) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id n12sm25556725fan.9.2011.10.04.06.49.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 06:49:25 -0700 (PDT) From: Mikolaj Golub To: dave jones Organization: TOA Ukraine References: <8662kcigif.fsf@kopusha.home.net> Sender: Mikolaj Golub Date: Tue, 04 Oct 2011 16:49:23 +0300 In-Reply-To: (dave jones's message of "Sat, 1 Oct 2011 14:15:45 +0800") Message-ID: <86y5x0ooik.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Robert Watson , "K. Macy" , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 04 Oct 2011 13:49:30 -0000 --=-=-= Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit On Sat, 1 Oct 2011 14:15:45 +0800 dave jones wrote: dj> On Fri, Sep 30, 2011 at 9:41 PM, Robert Watson wrote: >> >> On Wed, 28 Sep 2011, Mikolaj Golub wrote: >> >>> On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: >>> >>> KM> Sorry, didn't look at the images (limited bw), I've seen something KM> >>> like this before in timewait. This "can't happen" with UDP so will be KM> >>> interested in learning more about the bug. >>> >>> The panic can be easily triggered by this: >> >> Hi: >> >> Just catching up on this thread. šI think the analysis here is generally >> right: in 9.0, you're much more likely to see an inpcb with its in_socket >> pointer cleared in the hash list than in prior releases, and >> in_pcbbind_setup() trips over this. >> >> However, at least on first glance (and from the perspective of invariants >> here), I think the bug is actualy that in_pcbbind_setup() is asking >> in_pcblookup_local() for an inpcb and then access the returned inpcb's >> in_socket pointer without acquiring a lock on the inpcb. šStructurally, it >> can't acquire this lock for lock order reasons -- it already holds the lock >> on its own inpcb. šTherefore, we should only access fields that are safe to >> follow in an inpcb when you hold a reference via the hash lock and not a >> lock on the inpcb itself, which appears generally OK (+/-) for all the >> fields in that clause but the t->inp_socket->so_options dereference. >> >> A preferred fix would cache the SO_REUSEPORT flag in an inpcb-layer field, >> such as inp_flags2, giving us access to its value without having to walk >> into the attached (or not) socket. >> >> This raises another structural question, which is whether we need a new >> inp_foo flags field that is protected explicitly by the hash lock, and not >> by the inpcb lock, which could hold fields relevant to address binding. šI >> don't think we need to solve that problem in this context, as a slightly >> race on SO_REUSEPORT is likely acceptable. >> >> The suggested fix does perform the desired function of explicitly detaching >> the inpcb from the hash list before the socket is disconnected from the >> inpcb. However, it's incomplete in that the invariant that's being broken is >> also relied on for other protocols (such as raw sockets). šThe correct >> invariant is that inp_socket is safe to follow unconditionally if an inpcb >> is locked and INP_DROPPED isn't set -- the bug is in "locked" not in >> "INP_DROPPED", which is why I think this is the wrong fix, even though it >> prevents a panic :-). dj> Hello Robert, dj> Thank you for taking your valuable time to find out the problem. dj> Since I don't have idea about network internals, would you have a patch dj> about this? I'd be glad to test it, thanks again. Here is the patch that implements what Robert suggests. Dave, could you test it? >> Robert dj> Best regards, dj> Dave. -- Mikolaj Golub --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=in_pcb.REUSEPORT.patch Index: sys/netinet/in_pcb.c =================================================================== --- sys/netinet/in_pcb.c (revision 225885) +++ sys/netinet/in_pcb.c (working copy) @@ -575,8 +575,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockadd ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || ntohl(t->inp_laddr.s_addr) != INADDR_ANY || - (t->inp_socket->so_options & - SO_REUSEPORT) == 0) && + (t->inp_flags2 & INP_REUSEPORT) == 0) && (inp->inp_cred->cr_uid != t->inp_cred->cr_uid)) return (EADDRINUSE); @@ -595,14 +594,15 @@ in_pcbbind_setup(struct inpcb *inp, struct sockadd (reuseport & tw->tw_so_options) == 0) return (EADDRINUSE); } else if (t && - (reuseport & t->inp_socket->so_options) == 0) { + (reuseport == 0 || + (t->inp_flags2 & INP_REUSEPORT) == 0)) { #ifdef INET6 if (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || ntohl(t->inp_laddr.s_addr) != INADDR_ANY || - INP_SOCKAF(so) == - INP_SOCKAF(t->inp_socket)) + (inp->inp_vflag & INP_IPV6PROTO) == 0 || + (t->inp_vflag & INP_IPV6PROTO) == 0) #endif return (EADDRINUSE); } @@ -1867,6 +1867,11 @@ in_pcbinshash_internal(struct inpcb *inp, int do_p KASSERT((inp->inp_flags & INP_INHASHLIST) == 0, ("in_pcbinshash: INP_INHASHLIST")); + if ((inp->inp_socket->so_options & SO_REUSEPORT) != 0 || + (IN_MULTICAST(ntohl(inp->inp_laddr.s_addr)) && + (inp->inp_socket->so_options & SO_REUSEADDR) != 0)) + inp->inp_flags2 |= INP_REUSEPORT; + #ifdef INET6 if (inp->inp_vflag & INP_IPV6) hashkey_faddr = inp->in6p_faddr.s6_addr32[3] /* XXX */; Index: sys/netinet/in_pcb.h =================================================================== --- sys/netinet/in_pcb.h (revision 225885) +++ sys/netinet/in_pcb.h (working copy) @@ -540,6 +540,7 @@ void inp_4tuple_get(struct inpcb *inp, uint32_t * #define INP_LLE_VALID 0x00000001 /* cached lle is valid */ #define INP_RT_VALID 0x00000002 /* cached rtentry is valid */ #define INP_PCBGROUPWILD 0x00000004 /* in pcbgroup wildcard list */ +#define INP_REUSEPORT 0x00000008 /* socket SO_REUSEPORT option is set */ /* * Flags passed to in_pcblookup*() functions. --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 14:01:15 2011 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 C0E3F106564A for ; Tue, 4 Oct 2011 14:01:15 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9234B8FC13 for ; Tue, 4 Oct 2011 14:01:15 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RB5YY-000Nid-Mc; Tue, 04 Oct 2011 10:01:14 -0400 Date: Tue, 4 Oct 2011 10:01:14 -0400 From: Gary Palmer To: Matthias Apitz Message-ID: <20111004140114.GA38162@in-addr.com> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> <20111004054444.GA10311@tinyCurrent> <20111004083710.GA1054@tiny> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111004083710.GA1054@tiny> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: "freebsd-net@freebsd.org" Subject: Re: Broadcom Docs 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, 04 Oct 2011 14:01:15 -0000 On Tue, Oct 04, 2011 at 10:37:10AM +0200, Matthias Apitz wrote: > El d?a Tuesday, October 04, 2011 a las 03:34:46PM +0800, Adrian Chadd escribi?: > > > That's because it's a wifi chip, not an ethernet chip. > > Yes, I know and I looked around in their pages; there are no Wifi chips; > so my question was: why is this? Most radios in WiFi chips are software based these days and companies are using the FCC regulations as a reason to prevent their release since if you had the programming information for the radios you could operate the device outside its licensed range, and they claim that the FCC would hold them responsible. Without a test case we'll never know if that is is the case or not Gary From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 14:39:32 2011 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 3CF02106564A; Tue, 4 Oct 2011 14:39:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id DAC088FC19; Tue, 4 Oct 2011 14:39:31 +0000 (UTC) Received: by gyf2 with SMTP id 2so693209gyf.13 for ; Tue, 04 Oct 2011 07:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vI0XAo5Ui8GjQV+Azk20L12MRKaKu1tyoZ+XCFY5V0M=; b=jMXi0G+0LIYZDU4GaQN1VUPBqnpag9L0embXPy13zOwo+ffVQt2K2CiM2umjnDpddU g0r5ZOM17TXkeDWABTSma+E9aXRPnsA3qqRNwreywfKLWGK17w1q53vzw1bbe6HCzFqV ynK0TQ9s6i2X5pTgXQIxhoBIiAKqDYwfrJe14= MIME-Version: 1.0 Received: by 10.236.193.72 with SMTP id j48mr7274168yhn.21.1317739171248; Tue, 04 Oct 2011 07:39:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Tue, 4 Oct 2011 07:39:31 -0700 (PDT) In-Reply-To: <20111004140114.GA38162@in-addr.com> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> <20111004054444.GA10311@tinyCurrent> <20111004083710.GA1054@tiny> <20111004140114.GA38162@in-addr.com> Date: Tue, 4 Oct 2011 22:39:31 +0800 X-Google-Sender-Auth: ckfRnoNwUgMo0B_ZFttNI52ZSkU Message-ID: From: Adrian Chadd To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Matthias Apitz Subject: Re: Broadcom Docs 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, 04 Oct 2011 14:39:32 -0000 The non-embedded atheros NICs (ie, not the ath6k series stuff) is all run by the host CPU. There's no firmware that runs on the NIC. This was why the HAL was binary for so long. Note it is no longer binary and hasn't been for a few years. So I think we can ignore the whole "binary firmware" problem. There's working code for these NICs for one or more of NetBSD, OpenBSD and Linux. All we need are people with some time and motivation to get it all working on FreeBSD. I'll commit whatever stuff people come up with. (And in the meantime, I'll continue chipping away at 11n support in ath(4)/ath_hal(4).) Adrian From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 15:14:23 2011 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 0FF11106566B; Tue, 4 Oct 2011 15:14:23 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 713708FC18; Tue, 4 Oct 2011 15:14:22 +0000 (UTC) Received: by wwe3 with SMTP id 3so903137wwe.31 for ; Tue, 04 Oct 2011 08:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hucFAbUOi8BHgu5ya0/HWC8Yuu14KzuYIb49a5vqSWc=; b=mXwSbw9TBzkoqYak6dkIRuCXeBNH+8intvOw9AL6tuMN14LM6XUJIEOReHhMBEq+TT HNrGi2NWmc305cobH3iJ4bLJdxi+mpr8bEXEa4Mvwc4yLeDd1z5R+thJih4f6MDTfOOH pXhJIAjQP47FgpVBmBCJ18MeJdPMw0mtSsoGU= MIME-Version: 1.0 Received: by 10.227.195.13 with SMTP id ea13mr1554711wbb.36.1317741260611; Tue, 04 Oct 2011 08:14:20 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 4 Oct 2011 08:14:20 -0700 (PDT) In-Reply-To: References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> <20111004054444.GA10311@tinyCurrent> <20111004083710.GA1054@tiny> Date: Tue, 4 Oct 2011 11:14:20 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Matthias Apitz , Sean Bruno Subject: Re: Broadcom Docs 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, 04 Oct 2011 15:14:23 -0000 Hi, On Tue, Oct 4, 2011 at 8:28 AM, Adrian Chadd wrote: > On 4 October 2011 16:37, Matthias Apitz wrote: >> >> yes; but with good datasheets this would be more easy; > > There's working code for the later chips in Linux and likely (via > Linux) OpenBSD. > > Linux has b43 and brcm drivers. The source is there - what's missing > is someone choosing one and porting it to FreeBSD. > Unless error of my part, the bcrm driver, while being released with an ISC-like licence, do no support that chip (cf [0]). However, the b43 driver do support that chip, but is GPL... > Both b43 (via reverse engineering) and brcm (via broadcom developers) > is getting active development. It'd be nice to have datasheets but you > don't need them to port the code over. > There was an article recently on lwn.net describing the situation where both the b43 and brcm supported the same chip, and the issue raised that there was no point in brcm being mainlined in that state[1]... I'm not sure what the outcome was. - Arnaud [0]: http://linuxwireless.org/en/users/Drivers/brcm80211 [1]: http://lwn.net/Articles/456762/ > > Adrian > From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 15:16:54 2011 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 A419D106566C; Tue, 4 Oct 2011 15:16:54 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 12C3E8FC13; Tue, 4 Oct 2011 15:16:53 +0000 (UTC) Received: by wwe3 with SMTP id 3so907248wwe.31 for ; Tue, 04 Oct 2011 08:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=brkTdgwHsKrJCNyIDTdLP8XiI/0xNebbBniJbGmtAlw=; b=lDW4FsNl3/0b2scSWWaJmFJeOtZCib7QoRR+USrchgXH1pqpsXghFCwFEvv61KAVdP qUUI+LRuiQiAQEFacl9DFC1IYbIAt2Jjd7hC+P60ViZy2VWLYmdrgZXzIueJyaLeorrQ UeTkqC0FSCzAoxPTJhpXwnzzV+SuKw5RcTGGU= MIME-Version: 1.0 Received: by 10.227.153.211 with SMTP id l19mr1583730wbw.51.1317741412890; Tue, 04 Oct 2011 08:16:52 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 4 Oct 2011 08:16:52 -0700 (PDT) In-Reply-To: References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> <20111004054444.GA10311@tinyCurrent> <20111004083710.GA1054@tiny> <20111004140114.GA38162@in-addr.com> Date: Tue, 4 Oct 2011 11:16:52 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Matthias Apitz Subject: Re: Broadcom Docs 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, 04 Oct 2011 15:16:54 -0000 Hi, On Tue, Oct 4, 2011 at 10:39 AM, Adrian Chadd wrote: > The non-embedded atheros NICs (ie, not the ath6k series stuff) is all > run by the host CPU. There's no firmware that runs on the NIC. > This was why the HAL was binary for so long. Note it is no longer > binary and hasn't been for a few years. > OOTH, AFAIK, Linux folks never used the binary HAL, and had it working, but it was GPL licensed from the beginning. - Arnaud > So I think we can ignore the whole "binary firmware" problem. There's > working code for these NICs for one or more of NetBSD, OpenBSD and > Linux. > All we need are people with some time and motivation to get it all > working on FreeBSD. I'll commit whatever stuff people come up with. > > (And in the meantime, I'll continue chipping away at 11n support in > ath(4)/ath_hal(4).) > > > Adrian > _______________________________________________ > 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 Oct 4 15:22:57 2011 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 6CEAC106564A for ; Tue, 4 Oct 2011 15:22:57 +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 30D478FC0C for ; Tue, 4 Oct 2011 15:22:56 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (sai-rp.bluecoat.com [10.2.2.126] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p94FMrEE020858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Oct 2011 08:22:53 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 4 Oct 2011 08:22:48 -0700 From: "Li, Qing" To: Matt Smith Thread-Topic: gif interface not passing IPv6 packets Thread-Index: AQHMgnrKjCHytA/Lp0KCU6v51XthQZVscniA///YAa4= Date: Tue, 4 Oct 2011 15:22:47 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: gif interface not passing IPv6 packets 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, 04 Oct 2011 15:22:57 -0000 I believe there is actually another bug needs fixing. Let me confirm and wi= ll provide=0A= another patch later.=0A= =0A= --Qing=0A= =0A= ________________________________________=0A= From: Matt Smith [matt@xtaz.co.uk]=0A= Sent: Tuesday, October 04, 2011 3:33 AM=0A= To: Li, Qing=0A= Cc: freebsd-net@freebsd.org=0A= Subject: Re: gif interface not passing IPv6 packets=0A= =0A= On 4 October 2011 10:48, Matt Smith wrote:=0A= > I have just applied the patch, recompiled the kernel, and rebooted=0A= > with my original configuration in rc.conf and all interfaces have come=0A= > up as expected now. The routes are there, I can ping everything, and I=0A= > can connect to everything as expected.=0A= =0A= Actually saying that. I've found a problem meaning some of my software=0A= is broken now.=0A= =0A= Just noticed that lo0 doesn't have a ::1 address:=0A= =0A= lo0: flags=3D8049 metric 0 mtu 16384=0A= options=3D3=0A= inet 127.0.0.1 netmask 0xff000000=0A= =0A= If I try and add one I get this:=0A= =0A= root@tao[~]# ifconfig lo0 inet6 ::1 prefixlen 128=0A= ifconfig: ioctl (SIOCAIFADDR): File exists=0A= From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 18:17:34 2011 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 35600106566B for ; Tue, 4 Oct 2011 18:17:34 +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 EB3038FC18 for ; Tue, 4 Oct 2011 18:17:32 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (sai-rp.bluecoat.com [10.2.2.126] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p94IHRdw006426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Oct 2011 11:17:27 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 4 Oct 2011 11:17:21 -0700 From: "Li, Qing" To: "Li, Qing" , Matt Smith Thread-Topic: gif interface not passing IPv6 packets Thread-Index: AQHMgnrKjCHytA/Lp0KCU6v51XthQZVscniA///YAa6AADMWAA== Date: Tue, 4 Oct 2011 18:17:21 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: gif interface not passing IPv6 packets 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, 04 Oct 2011 18:17:34 -0000 Hi, Please download the newer patch from http://people.freebsd.org/~qingli/in6.c.diff This patch ought to fix both problems. --Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Tuesday, October 04, 2011 8:23 AM > To: Matt Smith > Cc: freebsd-net@freebsd.org > Subject: RE: gif interface not passing IPv6 packets >=20 > I believe there is actually another bug needs fixing. Let me confirm > and will provide > another patch later. >=20 > --Qing >=20 > ________________________________________ > From: Matt Smith [matt@xtaz.co.uk] > Sent: Tuesday, October 04, 2011 3:33 AM > To: Li, Qing > Cc: freebsd-net@freebsd.org > Subject: Re: gif interface not passing IPv6 packets >=20 > On 4 October 2011 10:48, Matt Smith wrote: > > I have just applied the patch, recompiled the kernel, and rebooted > > with my original configuration in rc.conf and all interfaces have > come > > up as expected now. The routes are there, I can ping everything, and > I > > can connect to everything as expected. >=20 > Actually saying that. I've found a problem meaning some of my software > is broken now. >=20 > Just noticed that lo0 doesn't have a ::1 address: >=20 > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D3 > inet 127.0.0.1 netmask 0xff000000 >=20 > If I try and add one I get this: >=20 > root@tao[~]# ifconfig lo0 inet6 ::1 prefixlen 128 > ifconfig: ioctl (SIOCAIFADDR): File exists > _______________________________________________ > 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 Oct 4 19:20:42 2011 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 8516A106567D for ; Tue, 4 Oct 2011 19:20:42 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3418D8FC31 for ; Tue, 4 Oct 2011 19:20:42 +0000 (UTC) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id A75EFB0752B for ; Tue, 4 Oct 2011 20:20:39 +0100 (BST) Received: by vws11 with SMTP id 11so989030vws.13 for ; Tue, 04 Oct 2011 12:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.67.113 with SMTP id m17mr1450091vdt.496.1317756037744; Tue, 04 Oct 2011 12:20:37 -0700 (PDT) Received: by 10.52.159.103 with HTTP; Tue, 4 Oct 2011 12:20:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Oct 2011 20:20:37 +0100 Message-ID: From: Matt Smith To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" Subject: Re: gif interface not passing IPv6 packets 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, 04 Oct 2011 19:20:42 -0000 On 4 October 2011 19:17, Li, Qing wrote: > Hi, > > Please download the newer patch from > > =A0 =A0 =A0 =A0http://people.freebsd.org/~qingli/in6.c.diff > > This patch ought to fix both problems. Just applied this patch. Yes, this fixes both problems. As far as I can see now everything is working. So the other question was is this going to affect 9.0, and if it does could the patch get committed to the tree before RC1 is created? Thank you for your help! From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 19:51:46 2011 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 40B5F106566B for ; Tue, 4 Oct 2011 19:51:46 +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 1B7268FC1D for ; Tue, 4 Oct 2011 19:51:45 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p94JpikB011030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Oct 2011 12:51:44 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Tue, 4 Oct 2011 12:51:40 -0700 From: "Li, Qing" To: Matt Smith Thread-Topic: gif interface not passing IPv6 packets Thread-Index: AQHMgsqyjCHytA/Lp0KCU6v51XthQZVsl/AA Date: Tue, 4 Oct 2011 19:51:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: gif interface not passing IPv6 packets 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, 04 Oct 2011 19:51:46 -0000 Hi, Yes, I believe this patch will be part of RC1. I just need to follow through with the release process. I will let you know once confirmed. --Qing > -----Original Message----- > From: Matt Smith [mailto:matt@xtaz.co.uk] > Sent: Tuesday, October 04, 2011 12:21 PM > To: Li, Qing > Cc: freebsd-net@freebsd.org > Subject: Re: gif interface not passing IPv6 packets >=20 > On 4 October 2011 19:17, Li, Qing wrote: > > Hi, > > > > Please download the newer patch from > > > > =A0 =A0 =A0 =A0http://people.freebsd.org/~qingli/in6.c.diff > > > > This patch ought to fix both problems. >=20 > Just applied this patch. Yes, this fixes both problems. As far as I > can see now everything is working. So the other question was is this > going to affect 9.0, and if it does could the patch get committed to > the tree before RC1 is created? >=20 > Thank you for your help! From owner-freebsd-net@FreeBSD.ORG Tue Oct 4 20:50:52 2011 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 3F87A106567B for ; Tue, 4 Oct 2011 20:50:52 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp05.sth.basefarm.net (ch-smtp05.sth.basefarm.net [80.76.153.6]) by mx1.freebsd.org (Postfix) with ESMTP id B96F28FC13 for ; Tue, 4 Oct 2011 20:50:51 +0000 (UTC) Received: from c83-255-51-20.bredband.comhem.se ([83.255.51.20]:36375 helo=falcon.midgard.homeip.net) by ch-smtp05.sth.basefarm.net with esmtp (Exim 4.76) (envelope-from ) id 1RBBk7-0001lD-II for freebsd-net@freebsd.org; Tue, 04 Oct 2011 22:37:37 +0200 Received: (qmail 72635 invoked from network); 4 Oct 2011 22:37:32 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 4 Oct 2011 22:37:32 +0200 Received: (qmail 30221 invoked by uid 1001); 4 Oct 2011 22:37:32 +0200 Date: Tue, 4 Oct 2011 22:37:32 +0200 From: Erik Trulsson To: Arnaud Lacombe Message-ID: <20111004203732.GA30189@owl.midgard.homeip.net> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> <20111004054444.GA10311@tinyCurrent> <20111004083710.GA1054@tiny> <20111004140114.GA38162@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: 83.255.51.20 X-Scan-Result: No virus found in message 1RBBk7-0001lD-II. X-Scan-Signature: ch-smtp05.sth.basefarm.net 1RBBk7-0001lD-II b91685bf1060356a038e9acc66469a53 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Matthias Apitz Subject: Re: Broadcom Docs 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, 04 Oct 2011 20:50:52 -0000 On Tue, Oct 04, 2011 at 11:16:52AM -0400, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 4, 2011 at 10:39 AM, Adrian Chadd wrote: > > The non-embedded atheros NICs (ie, not the ath6k series stuff) is all > > run by the host CPU. There's no firmware that runs on the NIC. > > This was why the HAL was binary for so long. Note it is no longer > > binary and hasn't been for a few years. > > > OOTH, AFAIK, Linux folks never used the binary HAL, and had it > working, but it was GPL licensed from the beginning. For Atheros wireless controllers Linux people used to use the madwifi driver which did use the binary HAL and otherwise was dual-licensed (BSD/GPL). Nowadays Linux people use the ath5k/ath9k drivers which do not use the binary HAL and which had just about reached the level of actually being usable when source code for the HAL was released. (The madwifi driver was never included in the standard Linux kernel, mostly due to the binary HAL. The ath5k/ath9k drivers are nowadays included in the Linux kernel.) -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 01:01:02 2011 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 304E2106566C for ; Wed, 5 Oct 2011 01:01:02 +0000 (UTC) (envelope-from lacombar@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 B593E8FC0C for ; Wed, 5 Oct 2011 01:01:01 +0000 (UTC) Received: by wyj26 with SMTP id 26so1558396wyj.13 for ; Tue, 04 Oct 2011 18:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yAR1k+9TFwa3DKKiIz+W75fBueOB3LrJJM1vyX0DvyI=; b=Ys+TiApaALKD+56KxNlMMkZfuLWHpL8qMDA38IFMPxCGJXf336wiuSlnizQx9evJuf iCUZVlWI1/JNlakix/2g0c3u/l0ef6kIb1LA7jkmbIRRHV8kTMybdwamTSedjd5K5ChD a0+DVVADqH1UhWDZxAKwaX2ph26QNrDOV4RUU= MIME-Version: 1.0 Received: by 10.227.153.211 with SMTP id l19mr2254150wbw.51.1317776460371; Tue, 04 Oct 2011 18:01:00 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 4 Oct 2011 18:01:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Oct 2011 21:01:00 -0400 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: em(4) hang [Was: Re: igb(4) won't start with "igb0: Could not setup receive structures"] 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, 05 Oct 2011 01:01:02 -0000 Hi, On Thu, Mar 31, 2011 at 9:51 AM, Arnaud Lacombe wrote: > Hi > > [let's start a new thread :)] > > On Wed, Mar 30, 2011 at 2:22 PM, Jack Vogel wrote: >> Read the code in HEAD, em_local_timer() has a test of ALL the rx queues and >> will schedule a task that refreshes mbufs if they are empty. This has >> exactly the >> same effect as checking for some interrupt cause, a cause that is not >> available >> when using MSIX on 82574, but this approach works for everything. >> > ok, it took me a long time to reproduce the issue with em(4) version > 7.1.9, about 3h rather than a few minutes a month ago and only got > ~875 allocations failure vs. several thousand before, here are some > stats: > > # sysctl -a | grep missed > dev.em.0.mac_stats.missed_packets: 1917112 > dev.em.1.mac_stats.missed_packets: 0 > dev.em.2.mac_stats.missed_packets: 0 > dev.em.3.mac_stats.missed_packets: 0 > dev.em.4.mac_stats.missed_packets: 0 > dev.em.5.mac_stats.missed_packets: 0 > For the record, we had this issue at a customer today; the system was still using the driver from 7-STABLE. Fortunately, it should just be a matter of upgrading to the driver from HEAD, which we already know to be good, to fix the issue. Regards, - Arnaud From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 01:16:53 2011 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 DF9CB106564A for ; Wed, 5 Oct 2011 01:16:53 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id A0FD18FC12 for ; Wed, 5 Oct 2011 01:16:53 +0000 (UTC) Received: by gyf2 with SMTP id 2so1382360gyf.13 for ; Tue, 04 Oct 2011 18:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=VZ2AgmiN79XIyTbwT+75pBmGS3zdg+/E4kdhpidcjgo=; b=EKqnU4qG9xzptBpevmytcWpsP1+yuHdj5bj798nLDi2RkGLk67f6kRnMQG2QOnvu/z pPheNrA7UOFik9UKMUy4gTWCmO6aY9B9UPOaTLU5VgSoQFPIWIW4z2T31pHchDX0/thD EGjG8vrWLzQLT7uF3SCaaZyziAnFZWI3cCROU= Received: by 10.150.48.29 with SMTP id v29mr1834194ybv.423.1317776978302; Tue, 04 Oct 2011 18:09:38 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id g38sm49330124ann.4.2011.10.04.18.09.37 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 18:09:37 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Tue, 4 Oct 2011 20:08:48 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201110042008.48915.break19@gmail.com> Subject: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 01:16:54 -0000 have a Netgear WG111v2 - which is a RealTek 8187 based usb 802.11G dongle, and which uses the if_urtw module. At random intervals, my internet connection just dies, I cannot ping the AP, am told "Network is down" by ping. The LED light on the adapter will have also gone out, and in dmesg, I get "wlan: link state changed to DOWN" and nothing I can do will restart the connection. Killing wpa_supplicant and restarting it does nothing. I've even destroyed and recreated the wlan0 device and still nothing. The card is effectively off, and non-responsive. What's worse is, I cannot remove and reinsert the adapter, because doing so causes a kernel panic. kldunload if_urtw -also- causes a kernel panic. I've had this issue since 8.0 was released, and I've also tried -current with no success at resolving this issue. As a point of note, this adapter is stable under OpenBSD, Linux, and Windows. It is only under FreeBSD and Solaris(OI, OSOL, and SolExpress10/11) that this issue exists... If anyone has any ideas for things to try, I am willing to try pretty much anything to get this resolved. From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 01:29:48 2011 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 725D6106566B for ; Wed, 5 Oct 2011 01:29:48 +0000 (UTC) (envelope-from chuck@thesouthernlibertarian.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 387E58FC08 for ; Wed, 5 Oct 2011 01:29:47 +0000 (UTC) Received: by yxk36 with SMTP id 36so1388260yxk.13 for ; Tue, 04 Oct 2011 18:29:47 -0700 (PDT) Received: by 10.147.52.18 with SMTP id e18mr734387yak.34.1317776471051; Tue, 04 Oct 2011 18:01:11 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id s19sm49186969anm.20.2011.10.04.18.01.09 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 18:01:09 -0700 (PDT) From: Chuck Burns Organization: The Southern Libertarian To: freebsd-net@freebsd.org Date: Tue, 4 Oct 2011 20:00:20 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201110042000.20789.chuck@thesouthernlibertarian.com> Subject: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 01:29:48 -0000 I have a Netgear WG111v2 - which is a RealTek 8187 based usb 802.11G dongle, and which uses the if_urtw module. At random intervals, my internet connection just dies, I cannot ping the AP, am told "Network is down" by ping. The LED light on the adapter will have also gone out, and in dmesg, I get "wlan: link state changed to DOWN" and nothing I can do will restart the connection. Killing wpa_supplicant and restarting it does nothing. I've even destroyed and recreated the wlan0 device and still nothing. The card is effectively off. From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 01:31:04 2011 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 4803F106566C for ; Wed, 5 Oct 2011 01:31:04 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id CD8838FC18 for ; Wed, 5 Oct 2011 01:31:03 +0000 (UTC) Received: by wwe3 with SMTP id 3so1649629wwe.31 for ; Tue, 04 Oct 2011 18:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yK9YY2WIpumbQ6Dkg6+azqhzU23C1rpjKGbf+cqI+Ak=; b=WJ/A6ZXXTqFqA1kCrnpYDpYfeeSDDs9lJHGce3unaoqfOlKdMsuGC3n+vYGQWxRaRf efJKS8GJ8uNu/ARaiOwqxSXANFcOtL0/J4KrNh3VSCQwqbU8CYtSGjfFIU5ZYwUYH7Rj 3ESs9NvHFHLQLOXnA8s2folJ0DBwBVuWFWsC4= MIME-Version: 1.0 Received: by 10.227.175.77 with SMTP id w13mr2288824wbz.36.1317778262236; Tue, 04 Oct 2011 18:31:02 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 4 Oct 2011 18:31:02 -0700 (PDT) In-Reply-To: <201110042008.48915.break19@gmail.com> References: <201110042008.48915.break19@gmail.com> Date: Tue, 4 Oct 2011 21:31:02 -0400 Message-ID: From: Arnaud Lacombe To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Weongyo Jeong Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 01:31:04 -0000 Hi, [Added driver author, Weongyo Jeong , to the CC: list] On Tue, Oct 4, 2011 at 9:08 PM, Chuck Burns wrote: > =A0have a Netgear WG111v2 - which is a RealTek 8187 based usb 802.11G don= gle, > and which uses the if_urtw module. > > At random intervals, my internet connection just dies, I cannot ping the = AP, > am told "Network is down" by ping. > > The LED light on the adapter will have also gone out, and in dmesg, I get > "wlan: link state changed to DOWN" and nothing I can do will restart the > connection. > > Killing wpa_supplicant and restarting it does nothing. > > I've even destroyed and recreated the wlan0 device and still nothing. =A0= The > card is effectively off, and non-responsive. > > What's worse is, I cannot remove and reinsert the adapter, because doing = so > causes a kernel panic. > > kldunload if_urtw -also- causes a kernel panic. =A0I've had this issue si= nce 8.0 > was released, and I've also tried -current with no success at resolving t= his > issue. > could you report that panic, please ? > As a point of note, this adapter is stable under OpenBSD, Linux, and Wind= ows. > It is only under FreeBSD and Solaris(OI, OSOL, and SolExpress10/11) that = this > issue exists... > > If anyone has any ideas for things to try, I am willing to try pretty muc= h > anything to get this resolved. > can you try to rebuild the module with URTW_DEBUG enabled, then set hw.usb.urtw.debug to any of the state in the following enum: enum { URTW_DEBUG_XMIT =3D 0x00000001, /* basic xmit operation */ URTW_DEBUG_RECV =3D 0x00000002, /* basic recv operation */ URTW_DEBUG_RESET =3D 0x00000004, /* reset processing */ URTW_DEBUG_TX_PROC =3D 0x00000008, /* tx ISR proc */ URTW_DEBUG_RX_PROC =3D 0x00000010, /* rx ISR proc */ URTW_DEBUG_STATE =3D 0x00000020, /* 802.11 state transitions */ URTW_DEBUG_STAT =3D 0x00000040, /* statistic */ URTW_DEBUG_INIT =3D 0x00000080, /* initialization of dev */ URTW_DEBUG_TXSTATUS =3D 0x00000100, /* tx status */ URTW_DEBUG_ANY =3D 0xffffffff }; to see if anything useful pops up ? Thanks, - Arnaud > _______________________________________________ > 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 Oct 5 01:38:12 2011 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 3AC471065672 for ; Wed, 5 Oct 2011 01:38:12 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id EDE0E8FC0C for ; Wed, 5 Oct 2011 01:38:11 +0000 (UTC) Received: by ggeq3 with SMTP id q3so650495gge.13 for ; Tue, 04 Oct 2011 18:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; bh=rtcTKeusYydcojRaa0e9zkTID6I6Nf7iIBNAxHT2AGs=; b=DjSmpartakY/NdwladEFGm0Q/b8/vIba2b+icucFnG5Rkzcnc3ubn1vwKEbwdWoPKy yIWSMDOyiNC9Sl4rQ26QV8GVRuEufYlXsV/WsFtyWk0VQHkwR9YaKB1DxlwbzX0CWN+1 gIqM7LSDa7td19HMLqdj+hn4tcxPrD3S3IH6A= Received: by 10.150.170.5 with SMTP id s5mr1893132ybe.25.1317776808903; Tue, 04 Oct 2011 18:06:48 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id w16sm49320668anl.2.2011.10.04.18.06.48 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 18:06:48 -0700 (PDT) From: Chuck Burns Organization: The Southern Libertarian To: freebsd-net@freebsd.org Date: Tue, 4 Oct 2011 20:05:59 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201110042005.59896.chuck@thesouthernlibertarian.com> Subject: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 01:38:12 -0000 I have a Netgear WG111v2 - which is a RealTek 8187 based usb 802.11G dongle, and which uses the if_urtw module. At random intervals, my internet connection just dies, I cannot ping the AP, am told "Network is down" by ping. The LED light on the adapter will have also gone out, and in dmesg, I get "wlan: link state changed to DOWN" and nothing I can do will restart the connection. Killing wpa_supplicant and restarting it does nothing. I've even destroyed and recreated the wlan0 device and still nothing. The card is effectively off, and non-responsive. What's worse is, I cannot remove and reinsert the adapter, because doing so causes a kernel panic. kldunload if_urtw -also- causes a kernel panic. I've had this issue since 8.0 was released, and I've also tried -current with no success at resolving this issue. As a point of note, this adapter is stable under OpenBSD, Linux, and Windows. It is only under FreeBSD and Solaris(OI, OSOL, and SolExpress10/11) that this issue exists... If anyone has any ideas for things to try, I am willing to try pretty much anything to get this resolved. From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 02:03:53 2011 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 CEAF6106564A for ; Wed, 5 Oct 2011 02:03:53 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 865608FC0A for ; Wed, 5 Oct 2011 02:03:53 +0000 (UTC) Received: by ywp17 with SMTP id 17so1416264ywp.13 for ; Tue, 04 Oct 2011 19:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=resent-from:resent-to:resent-date:resent-message-id:from:to:subject :date:user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=dVeLN5JFLkQQhrR+gUshxjiVEzhBP50xIdnysT7nNB8=; b=Kwst8Fl25BdaYt3ltNAf2ifkcv7aJyJ/kr48NOmxrsGekwnaNiRZDgi3mXyikLTO3Y dSPJySNZYUMULcRDiiI2AibOV0nn8inpCg7ph/GreRi1G2xaGfAL9cJ8BQLxPf5xsguE jmdabb/xH4kJCz549AVZS1VFx8Wd532Z0qlRw= Received: by 10.236.176.166 with SMTP id b26mr10908058yhm.60.1317780232913; Tue, 04 Oct 2011 19:03:52 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id l31sm91837yhi.15.2011.10.04.19.03.52 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 19:03:52 -0700 (PDT) Resent-From: Chuck Burns Resent-To: freebsd-net@freebsd.org Resent-Date: Tue, 4 Oct 2011 21:03:04 -0500 Resent-Message-ID: <201110042103.04675.break19@gmail.com> From: Chuck Burns To: Arnaud Lacombe Date: Tue, 4 Oct 2011 20:54:33 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110042054.33599.break19@gmail.com> Cc: Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 02:03:53 -0000 On Tuesday, October 04, 2011 8:31:02 PM you wrote: > Hi, > could you report that panic, please ? Well.. if I could get the dump to actually happen, I could report it correctly, as it is, I will likely just have to take a picture of the screen when it happens again, although the last few times the driver dies, I simply restart the machine, so no panic, but I'll let it panic the next time, and take a picture with a digital camera if I have to.. > can you try to rebuild the module with URTW_DEBUG enabled, then set > hw.usb.urtw.debug to any of the state in the following enum: > > enum { > URTW_DEBUG_XMIT = 0x00000001, /* basic xmit operation */ > URTW_DEBUG_RECV = 0x00000002, /* basic recv operation */ > URTW_DEBUG_RESET = 0x00000004, /* reset processing */ > URTW_DEBUG_TX_PROC = 0x00000008, /* tx ISR proc */ > URTW_DEBUG_RX_PROC = 0x00000010, /* rx ISR proc */ > URTW_DEBUG_STATE = 0x00000020, /* 802.11 state transitions */ > URTW_DEBUG_STAT = 0x00000040, /* statistic */ > URTW_DEBUG_INIT = 0x00000080, /* initialization of dev */ > URTW_DEBUG_TXSTATUS = 0x00000100, /* tx status */ > URTW_DEBUG_ANY = 0xffffffff > }; > > to see if anything useful pops up ? > I'm not sure how to rebuild just the module with that option URTW_DEBUG enabled.. I'm being told by some to just add the device to my kernel config along with the line "option URTW_DEBUG" .. but if there's a better way, let me know please. Also, I suppose that means if I want the "any" I sysctl hw.usb.urtw.debug=0xffffffff right? Still a bit green with regards to debugging. Thanks, Chuck From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 02:30:44 2011 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 7E191106564A for ; Wed, 5 Oct 2011 02:30:44 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA998FC0A for ; Wed, 5 Oct 2011 02:30:44 +0000 (UTC) Received: by gyf2 with SMTP id 2so1442158gyf.13 for ; Tue, 04 Oct 2011 19:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=DpYdcHtdx/9j9I7JUywKPJnKIBvQcvds/JbcIotAZE8=; b=FWYhmYyzU3qjvlVzPa8wGHp5Ri5OGY27s7+MwHADs/BTZiq1O9JTx1auuq5o8e6yKp yGjMPn8N4g2VxHebpCCHAnKZedf8uLzPf6RAZ5Q+hPkR6mPkEU3rI5x6sbunkiSjrBlg 4ni2AwxZ/LTwPHce6f1A+ICPZ2rcXTtQG6l3o= Received: by 10.147.59.11 with SMTP id m11mr1657867yak.12.1317781843625; Tue, 04 Oct 2011 19:30:43 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id n8sm461169and.1.2011.10.04.19.30.43 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 19:30:43 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Tue, 4 Oct 2011 21:29:54 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201110042129.54770.break19@gmail.com> Subject: Apologies for the recent spam... 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, 05 Oct 2011 02:30:44 -0000 My mail client gave no indication that the emails had been sent.. Won't happen again. From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 02:33:42 2011 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 B6C94106566C for ; Wed, 5 Oct 2011 02:33:42 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 736AA8FC12 for ; Wed, 5 Oct 2011 02:33:42 +0000 (UTC) Received: by yxk36 with SMTP id 36so1438786yxk.13 for ; Tue, 04 Oct 2011 19:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=OwsKLtqT0Gib6+x99eKgLLf5eeWVwP0VHz3o0dvOVSQ=; b=us43TDcMUdEMn+QXz4Rg173LpCHYkYs+z+w2IRxvhi1rUKyth+qVRYvYoYjj0ntCOf 9hgt6i2hGb7BYEvMtLATalm4uTx7kVRxmGGZWsz1uQjtxe5blcEbEtt0A0mQCVlBPr4d OpjTUQpbB/a41udKR5E/u5JednQvd3pV0eMFo= Received: by 10.101.194.26 with SMTP id w26mr41420anp.135.1317782021808; Tue, 04 Oct 2011 19:33:41 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id g38sm455852ann.4.2011.10.04.19.33.40 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 19:33:41 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Tue, 4 Oct 2011 21:32:52 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <201110042054.33599.break19@gmail.com> In-Reply-To: <201110042054.33599.break19@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110042132.52788.break19@gmail.com> Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 02:33:42 -0000 On Tuesday, October 04, 2011 8:54:33 PM Chuck Burns wrote: > I'm not sure how to rebuild just the module with that option URTW_DEBUG > enabled.. I'm being told by some to just add the device to my kernel config > along with the line "option URTW_DEBUG" .. but if there's a better way, let > me know please. > > Also, I suppose that means if I want the "any" I sysctl > hw.usb.urtw.debug=0xffffffff right? Still a bit green with regards to > debugging. I wound up adding "#define URTW_DEBUG" to the top of the if_urtw.c file and make install'ing the module from the proper subdirectory.. Also, upon setting the sysctl to 0xffffffff, it shows that it set the value to -1, is this correct? Chuck From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 02:41:24 2011 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 86EC8106566B for ; Wed, 5 Oct 2011 02:41:24 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1EFB38FC12 for ; Wed, 5 Oct 2011 02:41:23 +0000 (UTC) Received: by wwe3 with SMTP id 3so1700070wwe.31 for ; Tue, 04 Oct 2011 19:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3PE5O73avrWFVtPSoKlpeMg4JRpZDLa1UN397xtN88Y=; b=Gme93ZHOaRnl1iQkeO6dWxgPtTdiZdRO5hIcnb0xCwF7VSOl210k2oYjrLHRJqBJlJ +eID9Ip/IGAd48g7tZURwWYGrTc7KzHzPPM+pYB+oXQjyDhm2i9W+HrqPeB7T9U8NdjE sgUwn7QCMjxILG6jF0//J0MI61ngaqkomQnSg= MIME-Version: 1.0 Received: by 10.227.153.211 with SMTP id l19mr2346617wbw.51.1317782483031; Tue, 04 Oct 2011 19:41:23 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 4 Oct 2011 19:41:22 -0700 (PDT) In-Reply-To: <201110042132.52788.break19@gmail.com> References: <201110042008.48915.break19@gmail.com> <201110042054.33599.break19@gmail.com> <201110042132.52788.break19@gmail.com> Date: Tue, 4 Oct 2011 22:41:22 -0400 Message-ID: From: Arnaud Lacombe To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 02:41:24 -0000 Hi, On Tue, Oct 4, 2011 at 10:32 PM, Chuck Burns wrote: > On Tuesday, October 04, 2011 8:54:33 PM Chuck Burns wrote: > >> I'm not sure how to rebuild just the module with that option URTW_DEBUG >> enabled.. I'm being told by some to just add the device to my kernel config >> along with the line "option URTW_DEBUG" .. but if there's a better way, let >> me know please. >> >> Also, I suppose that means if I want the "any" I sysctl >> hw.usb.urtw.debug=0xffffffff right? Still a bit green with regards to >> debugging. > > I wound up adding "#define URTW_DEBUG" to the top of the if_urtw.c file and > make install'ing the module from the proper subdirectory.. > that's correct too :) > Also, upon setting the sysctl to 0xffffffff, it shows that it set the value to > -1, is this correct? > yes, the variable is exposed as being signed (-1 is encoded 0xffffffff on 32bit platform using two's complement), but accessed as a bitfield. You should now have message on the console, don't you ? Thanks, - Arnaud > Chuck > _______________________________________________ > 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 Oct 5 03:04:02 2011 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 09EDA1065674 for ; Wed, 5 Oct 2011 03:04:02 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id BBF2C8FC12 for ; Wed, 5 Oct 2011 03:04:01 +0000 (UTC) Received: by ywp17 with SMTP id 17so1462845ywp.13 for ; Tue, 04 Oct 2011 20:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=6VTYDESpMYu6Tzg90oNZAYkzEkKM4oEpknO2fRSOHtQ=; b=IutTQ/tRf+Z0dU0GLR5+ubnmkiI/S7z2Zkp9qlpCGfKVL9dA1ri6+vVnAYQzTlBEUw dR/i5jnrFZaAYLKVSy4yq6w53qU+gsO4X4345R5mmUmfXy0kO96tt2vw554C5dXBiE5N 6+0FDDt4vdg8CGgGkAvigA/FRTjhTkEbUMhYY= Received: by 10.236.79.230 with SMTP id i66mr10998167yhe.52.1317783841194; Tue, 04 Oct 2011 20:04:01 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id d5sm324756yhl.19.2011.10.04.20.04.00 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 20:04:00 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Tue, 4 Oct 2011 22:03:12 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <201110042132.52788.break19@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110042203.12082.break19@gmail.com> Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 03:04:02 -0000 On Tuesday, October 04, 2011 9:41:22 PM Arnaud Lacombe wrote: > > You should now have message on the console, don't you ? > Actually. I'm not getting any more messages on my console than I have been getting before.. Some more information: FreeBSD blackbeast.local 8.2-STABLE FreeBSD 8.2-STABLE #2: Tue Oct 4 19:57:10 CDT 2011 root@blackbeast.local:/usr/obj/usr/src/sys/BLACKBEAST amd64 sysctl -a | grep urtw: net.wlan.0.%parent: urtw0 hw.usb.urtw.preamble_mode: 2 hw.usb.urtw.debug: -1 dev.urtw.0.%desc: vendor 0x0846 product 0x6a00, class 0/0, rev 2.00/1.00, addr 2 dev.urtw.0.%driver: urtw dev.urtw.0.%location: bus=1 hubaddr=5 port=5 devaddr=2 interface=0 dev.urtw.0.%pnpinfo: vendor=0x0846 product=0x6a00 devclass=0x00 devsubclass=0x00 sernum="" release=0x0100 mode=host intclass=0x00 intsubclass=0x00 intprotocol=0x00 dev.urtw.0.%parent: uhub5 dev.urtw.0.stats.tx.1m: 0 dev.urtw.0.stats.tx.2m: 19 dev.urtw.0.stats.tx.5.5m: 0 dev.urtw.0.stats.tx.6m: 0 dev.urtw.0.stats.tx.9m: 0 dev.urtw.0.stats.tx.11m: 19 dev.urtw.0.stats.tx.12m: 69 dev.urtw.0.stats.tx.18m: 140 dev.urtw.0.stats.tx.24m: 196 dev.urtw.0.stats.tx.36m: 4989 dev.urtw.0.stats.tx.48m: 5788 dev.urtw.0.stats.tx.54m: 21513 usbconfig show_ifdrv: ugen5.2: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen5.2.0: urtw0: usbconfig dump_all_config_desc: Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0027 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0004 bmAttributes = 0x0080 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0003 bInterfaceClass = 0x0000 bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0000 iInterface = 0x0005 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0003 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 03:34:57 2011 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 ECC6D1065675 for ; Wed, 5 Oct 2011 03:34:57 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 848208FC16 for ; Wed, 5 Oct 2011 03:34:57 +0000 (UTC) Received: by wwe3 with SMTP id 3so1733540wwe.31 for ; Tue, 04 Oct 2011 20:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=J2bywY/vJCOuWwSpUegpIN3/SsFDtT9khVFWgbfEvvA=; b=YxOJIgJET5Qeysw5GJuJZn+Dg79SY/LFWrXi2TWcyrtKS/ty6b4NUaLDmTeJPjOGkV 1Hk29e7KqsjPugBCwpefHVU0dsOLTvZW5S40gVmvor72RqCmfR6Oc7D/tj03Cum1acjk 2jXPHQ2yPhnlfNWrOHMMRDMlY3EAoF9w0u+uk= MIME-Version: 1.0 Received: by 10.227.135.130 with SMTP id n2mr2331999wbt.51.1317785696343; Tue, 04 Oct 2011 20:34:56 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 4 Oct 2011 20:34:56 -0700 (PDT) In-Reply-To: <201110042203.12082.break19@gmail.com> References: <201110042008.48915.break19@gmail.com> <201110042132.52788.break19@gmail.com> <201110042203.12082.break19@gmail.com> Date: Tue, 4 Oct 2011 23:34:56 -0400 Message-ID: From: Arnaud Lacombe To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 03:34:58 -0000 Hi, On Tue, Oct 4, 2011 at 11:03 PM, Chuck Burns wrote: > On Tuesday, October 04, 2011 9:41:22 PM Arnaud Lacombe wrote: > >> >> You should now have message on the console, don't you ? >> > > > Actually. I'm not getting any more messages on my console than I have bee= n > getting before.. > Looking closer in the driver, DPRINTF() is only used 6 time and only URTW_DEBUG_TXSTATUS, URTW_DEBUG_INIT, URTW_DEBUG_STATE and URTW_DEBUG_XMIT are actually used... I'd say to wait until the hang re-occur to see if there is anything printed= . - Arnaud > Some more information: > > FreeBSD blackbeast.local 8.2-STABLE FreeBSD 8.2-STABLE #2: Tue Oct =A04 1= 9:57:10 > CDT 2011 =A0 =A0 root@blackbeast.local:/usr/obj/usr/src/sys/BLACKBEAST = =A0amd64 > > sysctl -a | grep urtw: > > net.wlan.0.%parent: urtw0 > hw.usb.urtw.preamble_mode: 2 > hw.usb.urtw.debug: -1 > dev.urtw.0.%desc: vendor 0x0846 product 0x6a00, class 0/0, rev 2.00/1.00,= addr > 2 > dev.urtw.0.%driver: urtw > dev.urtw.0.%location: bus=3D1 hubaddr=3D5 port=3D5 devaddr=3D2 interface= =3D0 > dev.urtw.0.%pnpinfo: vendor=3D0x0846 product=3D0x6a00 devclass=3D0x00 > devsubclass=3D0x00 sernum=3D"" release=3D0x0100 mode=3Dhost intclass=3D0x= 00 > intsubclass=3D0x00 intprotocol=3D0x00 > dev.urtw.0.%parent: uhub5 > dev.urtw.0.stats.tx.1m: 0 > dev.urtw.0.stats.tx.2m: 19 > dev.urtw.0.stats.tx.5.5m: 0 > dev.urtw.0.stats.tx.6m: 0 > dev.urtw.0.stats.tx.9m: 0 > dev.urtw.0.stats.tx.11m: 19 > dev.urtw.0.stats.tx.12m: 69 > dev.urtw.0.stats.tx.18m: 140 > dev.urtw.0.stats.tx.24m: 196 > dev.urtw.0.stats.tx.36m: 4989 > dev.urtw.0.stats.tx.48m: 5788 > dev.urtw.0.stats.tx.54m: 21513 > > usbconfig show_ifdrv: > > ugen5.2: at usbus5, cfg=3D0 md=3DHOST spd= =3DHIGH > (480Mbps) pwr=3DON > ugen5.2.0: urtw0: addr 2> > > usbconfig dump_all_config_desc: > > =A0Configuration index 0 > > =A0 =A0bLength =3D 0x0009 > =A0 =A0bDescriptorType =3D 0x0002 > =A0 =A0wTotalLength =3D 0x0027 > =A0 =A0bNumInterfaces =3D 0x0001 > =A0 =A0bConfigurationValue =3D 0x0001 > =A0 =A0iConfiguration =3D 0x0004 =A0 > =A0 =A0bmAttributes =3D 0x0080 > =A0 =A0bMaxPower =3D 0x00fa > > =A0 =A0Interface 0 > =A0 =A0 =A0bLength =3D 0x0009 > =A0 =A0 =A0bDescriptorType =3D 0x0004 > =A0 =A0 =A0bInterfaceNumber =3D 0x0000 > =A0 =A0 =A0bAlternateSetting =3D 0x0000 > =A0 =A0 =A0bNumEndpoints =3D 0x0003 > =A0 =A0 =A0bInterfaceClass =3D 0x0000 > =A0 =A0 =A0bInterfaceSubClass =3D 0x0000 > =A0 =A0 =A0bInterfaceProtocol =3D 0x0000 > =A0 =A0 =A0iInterface =3D 0x0005 =A0 > > =A0 =A0 Endpoint 0 > =A0 =A0 =A0 =A0bLength =3D 0x0007 > =A0 =A0 =A0 =A0bDescriptorType =3D 0x0005 > =A0 =A0 =A0 =A0bEndpointAddress =3D 0x0081 =A0 > =A0 =A0 =A0 =A0bmAttributes =3D 0x0002 =A0 > =A0 =A0 =A0 =A0wMaxPacketSize =3D 0x0200 > =A0 =A0 =A0 =A0bInterval =3D 0x0000 > =A0 =A0 =A0 =A0bRefresh =3D 0x0000 > =A0 =A0 =A0 =A0bSynchAddress =3D 0x0000 > > =A0 =A0 Endpoint 1 > =A0 =A0 =A0 =A0bLength =3D 0x0007 > =A0 =A0 =A0 =A0bDescriptorType =3D 0x0005 > =A0 =A0 =A0 =A0bEndpointAddress =3D 0x0002 =A0 > =A0 =A0 =A0 =A0bmAttributes =3D 0x0002 =A0 > =A0 =A0 =A0 =A0wMaxPacketSize =3D 0x0200 > =A0 =A0 =A0 =A0bInterval =3D 0x0000 > =A0 =A0 =A0 =A0bRefresh =3D 0x0000 > =A0 =A0 =A0 =A0bSynchAddress =3D 0x0000 > > =A0 =A0 Endpoint 2 > =A0 =A0 =A0 =A0bLength =3D 0x0007 > =A0 =A0 =A0 =A0bDescriptorType =3D 0x0005 > =A0 =A0 =A0 =A0bEndpointAddress =3D 0x0003 =A0 > =A0 =A0 =A0 =A0bmAttributes =3D 0x0002 =A0 > =A0 =A0 =A0 =A0wMaxPacketSize =3D 0x0200 > =A0 =A0 =A0 =A0bInterval =3D 0x0000 > =A0 =A0 =A0 =A0bRefresh =3D 0x0000 > =A0 =A0 =A0 =A0bSynchAddress =3D 0x0000 > > _______________________________________________ > 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 Oct 5 03:55:56 2011 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 7AF13106566C; Wed, 5 Oct 2011 03:55:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 240358FC14; Wed, 5 Oct 2011 03:55:55 +0000 (UTC) Received: by vws11 with SMTP id 11so1392057vws.13 for ; Tue, 04 Oct 2011 20:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hiQ3bsNLctiRelscy8onu0EUrmGzh88+JSCf+sXF4cI=; b=BXfc8wJAjAWO5l2KMtnPckCJTIkcWrRpPEcSVIVuCePy59IQEvAFIOItNJBfqr7Cz0 lJgDpFCvip/3viGALS8M6susG0l9eZ/dPnYrO16NcH7pAtpd9SVjqJZ6yd2ttJXNRrs5 61smB+165mW5WvyDp198ktVlJbxn+deq0Qohs= MIME-Version: 1.0 Received: by 10.52.72.16 with SMTP id z16mr1863364vdu.395.1317786955335; Tue, 04 Oct 2011 20:55:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.161.138 with HTTP; Tue, 4 Oct 2011 20:55:55 -0700 (PDT) In-Reply-To: References: <201110042008.48915.break19@gmail.com> <201110042132.52788.break19@gmail.com> <201110042203.12082.break19@gmail.com> Date: Wed, 5 Oct 2011 11:55:55 +0800 X-Google-Sender-Auth: sf1JxDvLKTWAspQpEPSWh1iQUTo Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-wireless@freebsd.org, Chuck Burns Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 03:55:56 -0000 I'd also like to see the crash information. Does it crash when you remove the adapter _always_? Or just when it stops functioning? adrian From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 04:44:51 2011 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 A26E9106564A; Wed, 5 Oct 2011 04:44:51 +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 798148FC13; Wed, 5 Oct 2011 04:44:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p954ipmU044584; Wed, 5 Oct 2011 04:44:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p954ipBc044579; Wed, 5 Oct 2011 04:44:51 GMT (envelope-from linimon) Date: Wed, 5 Oct 2011 04:44:51 GMT Message-Id: <201110050444.p954ipBc044579@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/161277: [em] [patch] BMC cannot receive IPMI traffic after loading or enabling the if_em driver 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, 05 Oct 2011 04:44:51 -0000 Old Synopsis: [patch][if_em] BMC cannot receive IPMI traffic after loading or enabling the if_em driver New Synopsis: [em] [patch] BMC cannot receive IPMI traffic after loading or enabling the if_em driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 5 04:44:35 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=161277 From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 06:20:34 2011 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 4EC4E10657C4 for ; Wed, 5 Oct 2011 06:20:34 +0000 (UTC) (envelope-from sol289@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 216A38FC0C for ; Wed, 5 Oct 2011 06:20:33 +0000 (UTC) Received: by iadk27 with SMTP id k27so2058107iad.13 for ; Tue, 04 Oct 2011 23:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=dhlr2P2x5Phg54gzEaP71cIy7KJPFHa8NvTMJbXscHU=; b=mXUlwCELNbjdztph57VbodvwZOqdjx/i6O8jlEq/twUMoMBzQbVeO87fsL/SGwARUf UwVZrp8utd2vGi/NlXnriBNcYElTUerpDrjpZpCjdD28kJcgI9bnaWaTuRk7cxo/gJFD vjNN2SVjiBx0yK0iEOoe0DqKAtOq+u+O5oFss= Received: by 10.42.144.200 with SMTP id c8mr1276682icv.118.1317794019091; Tue, 04 Oct 2011 22:53:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.229.135 with HTTP; Tue, 4 Oct 2011 22:53:19 -0700 (PDT) From: alexander lunyov Date: Wed, 5 Oct 2011 09:53:19 +0400 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: carp on bridge interface: INIT 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, 05 Oct 2011 06:20:34 -0000 I need to make work a scheme like this: http://i.imgur.com/1xsXX.png So, i have 3 servers: in, out1 and out2; out1 and out2 plugged into one switched environment, so they can see each other on layer 2, which is bad for me, because they can make a switching loop in some case. out1 and out2 connects with openvpn to "in" in bridged configuration, tap interfaces have no addresses. Then i make bridge interfaces on all servers and adding only tap0 interfaces to bridge0 on each server, make each bridge0 interface configured with address from 10.0.0.0/24 subnet. On this moment everything is working and servers pinging each other 10.0.0.0/24 address. Then i want to make carp work on out1 and out2 on bridge0-tap0 pair, but if i config carp0 interface to work in 10.0.0.0/24 subnet, it stays in INIT state forever - so this is my first question - why carp won't work on bridge0-tap0 interface? If i bridge tap0 and em0 interfaces on out1 and out2, then carp on both servers get into MASTER state, i get switching loop and when i use tcpdump on bridge0 interfaces (-i bridge0 net 10.0.0.0/24), on out1 i see ONLY vrrp advertisements from out2 (no advertisements from out1), on out2 bridge0 i see ONLY advertisements from out1, and on "in" bridge0 i see advertisements from both servers, and nothing is working. So, here's the second question - how to make things work in this case? STP? But how to configure it, what interfaces put into STP? And will my precious carp work with STP? Thank you for your attention. -- your sweet isn't ready yet From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 12:10:05 2011 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 C1CAC1065670 for ; Wed, 5 Oct 2011 12:10:05 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6658FC16 for ; Wed, 5 Oct 2011 12:10:05 +0000 (UTC) Received: by yxk36 with SMTP id 36so1882945yxk.13 for ; Wed, 05 Oct 2011 05:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=Zoz+qXviMN8lvuYa1ZXa9RgGNvwnL2akwUw1jvAd+DQ=; b=vCV7ZzDiVjhy/eie8gUFamRZHVp6d8eH2VwVpQjK4fm7OHva5ccWO6HXbfPRPrpqEn UpMJ+kPMe/W61j3wWBrVSmP5k3/S9f1twB1SLZVwz40T3lDukBPL02Tbcj71Af08eVTO gqTlQHmCiAMcYE0GA2+h0ptpC987KOzPfRf3k= Received: by 10.236.173.231 with SMTP id v67mr12929848yhl.48.1317816604577; Wed, 05 Oct 2011 05:10:04 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id r30sm2018615yhj.20.2011.10.05.05.10.03 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 05:10:03 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Wed, 5 Oct 2011 07:09:17 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110050709.17944.break19@gmail.com> Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 12:10:05 -0000 On Tuesday, October 04, 2011 10:55:55 PM Adrian Chadd wrote: > I'd also like to see the crash information. Does it crash when you > remove the adapter _always_? Or just when it stops functioning? > > > adrian I tried to get it to crash last night, by removing and reinserting the adapter, and apparently it only does so when it stops working. Chuck Burns From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 12:41:52 2011 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 D9521106566C for ; Wed, 5 Oct 2011 12:41:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 970908FC0C for ; Wed, 5 Oct 2011 12:41:52 +0000 (UTC) Received: by vcbf13 with SMTP id f13so1735725vcb.13 for ; Wed, 05 Oct 2011 05:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wA8S4iXmcSHYSMdE61X9e/EpMuv6rzYF5q6N4dmjRGU=; b=b+ai6Gtf3NyAm/m/XACqr+x/jS6FqSCEarL6CSjKbeBoUIKQfbWnmRFYjYlY0FZN5Y roAoZu/+pTj86bS1EWQwej/vZOgbjE0hqkvtK7l9FrQttIbhlkB0RvwYqmbQwJIKLHUK teHfGOs7NMKiUsedsNnLL7v5pCcudO+CazO18= MIME-Version: 1.0 Received: by 10.52.69.200 with SMTP id g8mr2416486vdu.127.1317818511728; Wed, 05 Oct 2011 05:41:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.161.138 with HTTP; Wed, 5 Oct 2011 05:41:51 -0700 (PDT) In-Reply-To: <201110050709.17944.break19@gmail.com> References: <201110042008.48915.break19@gmail.com> <201110050709.17944.break19@gmail.com> Date: Wed, 5 Oct 2011 20:41:51 +0800 X-Google-Sender-Auth: fOT-fv28ISYsR8c5qrPAQS-udp8 Message-ID: From: Adrian Chadd To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 12:41:52 -0000 On 5 October 2011 20:09, Chuck Burns wrote: > I tried to get it to crash last night, by removing and reinserting the > adapter, and apparently it only does so when it stops working. Please post the crash information? adrian From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 12:50:36 2011 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 5C5C51065672 for ; Wed, 5 Oct 2011 12:50:36 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 18C098FC15 for ; Wed, 5 Oct 2011 12:50:35 +0000 (UTC) Received: by ywp17 with SMTP id 17so1924952ywp.13 for ; Wed, 05 Oct 2011 05:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=KQCCQtL4VWU6vTrV1MyOf4D7RNcwngIecIOIElt6v4E=; b=ImhLxPCVZ/gUeEnloDeftw1kTVf1aReV3RHXldYM+ZwnlOYcSl1w3/iDJsmvRde7Ex OS5aTCvLLon0Foo7y8Xg5FPnDQ9uQQAqeGByUpc6TxkoEq/93aacOvkybc6HC/MZazOf IbIYAqOJjZ7MOwdVwYHiALY6FSj0TT/El8SLM= Received: by 10.150.237.14 with SMTP id k14mr2310475ybh.317.1317819035396; Wed, 05 Oct 2011 05:50:35 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id 16sm3224881ant.10.2011.10.05.05.50.34 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 05:50:34 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Wed, 5 Oct 2011 07:49:49 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <201110050709.17944.break19@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110050749.49139.break19@gmail.com> Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 12:50:36 -0000 On Wednesday, October 05, 2011 7:41:51 AM Adrian Chadd wrote: > On 5 October 2011 20:09, Chuck Burns wrote: > > I tried to get it to crash last night, by removing and reinserting the > > adapter, and apparently it only does so when it stops working. > > Please post the crash information? > > > > adrian When it crashes again, I will.. It's a random interval. Sometimes it will go for a few days, sometimes only an hour or so.. Rest assured, as soon as it crashes again, I will post. :) Chuck Burns From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 13:09:37 2011 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 93C33106566B for ; Wed, 5 Oct 2011 13:09:37 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 651888FC0A for ; Wed, 5 Oct 2011 13:09:37 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RBRE8-0000de-C3; Wed, 05 Oct 2011 09:09:36 -0400 Date: Wed, 5 Oct 2011 09:09:36 -0400 From: Gary Palmer To: Chuck Burns Message-ID: <20111005130936.GB38162@in-addr.com> References: <201110042008.48915.break19@gmail.com> <201110042054.33599.break19@gmail.com> <201110042132.52788.break19@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110042132.52788.break19@gmail.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 13:09:37 -0000 On Tue, Oct 04, 2011 at 09:32:52PM -0500, Chuck Burns wrote: > On Tuesday, October 04, 2011 8:54:33 PM Chuck Burns wrote: > > > I'm not sure how to rebuild just the module with that option URTW_DEBUG > > enabled.. I'm being told by some to just add the device to my kernel config > > along with the line "option URTW_DEBUG" .. but if there's a better way, let > > me know please. > > > > Also, I suppose that means if I want the "any" I sysctl > > hw.usb.urtw.debug=0xffffffff right? Still a bit green with regards to > > debugging. > > I wound up adding "#define URTW_DEBUG" to the top of the if_urtw.c file and > make install'ing the module from the proper subdirectory.. Just wanted to make sure that you unloaded and reloaded the module after the "make install"? Gary From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 14:52:23 2011 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 D7684106564A; Wed, 5 Oct 2011 14:52:23 +0000 (UTC) (envelope-from lacombar@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 43C5F8FC12; Wed, 5 Oct 2011 14:52:22 +0000 (UTC) Received: by wyj26 with SMTP id 26so2408231wyj.13 for ; Wed, 05 Oct 2011 07:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=93gU+76VR4l3MZLMKBJ6QfvSlieyjxcQICLgUhw+DBA=; b=TrMHKPFZZiFUCxkC/ONEwBjIS4KNm8B4tcLNuIKtjFXfve0aP1ov7EWhubrLL9GmiY 3eKyU2DJ/J+Vn3LGEPosYdC/PDql/PXWwgd8A2zTe623RGu0PvElcUBw0fyvOIyJPXYg PykEYMKgRamDqbL2lPMGNTfzTJ3LbJago1n0Q= MIME-Version: 1.0 Received: by 10.227.153.211 with SMTP id l19mr3123129wbw.51.1317826341598; Wed, 05 Oct 2011 07:52:21 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Wed, 5 Oct 2011 07:52:21 -0700 (PDT) In-Reply-To: <20111005130936.GB38162@in-addr.com> References: <201110042008.48915.break19@gmail.com> <201110042054.33599.break19@gmail.com> <201110042132.52788.break19@gmail.com> <20111005130936.GB38162@in-addr.com> Date: Wed, 5 Oct 2011 10:52:21 -0400 Message-ID: From: Arnaud Lacombe To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Chuck Burns Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 14:52:23 -0000 Hi, On Wed, Oct 5, 2011 at 9:09 AM, Gary Palmer wrote: > On Tue, Oct 04, 2011 at 09:32:52PM -0500, Chuck Burns wrote: >> On Tuesday, October 04, 2011 8:54:33 PM Chuck Burns wrote: >> >> > I'm not sure how to rebuild just the module with that option URTW_DEBUG >> > enabled.. I'm being told by some to just add the device to my kernel config >> > along with the line "option URTW_DEBUG" .. but if there's a better way, let >> > me know please. >> > >> > Also, I suppose that means if I want the "any" I sysctl >> > hw.usb.urtw.debug=0xffffffff right? Still a bit green with regards to >> > debugging. >> >> I wound up adding "#define URTW_DEBUG" to the top of the if_urtw.c file and >> make install'ing the module from the proper subdirectory.. > > Just wanted to make sure that you unloaded and reloaded the module after > the "make install"? > actually, it is more tricky than that. The sysctl `hw.usb.urtw.debug' only exist when URTW_DEBUG is defined, but the backing variable, `urtw_debug' is only used during attach to initialize `sc->sc_debug'. So setting the sysctl afterward is useless, the only real possibility is either to use the tunable, or directly use the sysctl's variable in DPRINTF(): diff --git a/sys/dev/usb/wlan/if_urtw.c b/sys/dev/usb/wlan/if_urtw.c index 6ae7e16..af8cd79 100644 --- a/sys/dev/usb/wlan/if_urtw.c +++ b/sys/dev/usb/wlan/if_urtw.c @@ -80,7 +80,7 @@ enum { URTW_DEBUG_ANY = 0xffffffff }; #define DPRINTF(sc, m, fmt, ...) do { \ - if (sc->sc_debug & (m)) \ + if (urtw_debug & (m)) \ printf(fmt, __VA_ARGS__); \ } while (0) - Arnaud > Gary > _______________________________________________ > 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 Oct 5 16:59:07 2011 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 83E4710656D3 for ; Wed, 5 Oct 2011 16:59:07 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0538FC16 for ; Wed, 5 Oct 2011 16:59:07 +0000 (UTC) Received: by ggeq3 with SMTP id q3so1120898gge.13 for ; Wed, 05 Oct 2011 09:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=C4XFmkhBj8+Z5zvodtdvWYypbXkyaiUoVnbD3GeQxNw=; b=tv3p1PxCrmEpn8D+QjDENTNQFxX0li+abWm4x1vYj6VyYJmBXdP+p3qi8+bEbtYFOM Si1TJs5zK9o0FGL+abKb91bNaFuh7C/XOJTpPh8WhFLmoV32XY9KoDp5om1793XWKr2R aB/2eaph39b1dSDy+9T/PxxoVtA9ociC1O1+w= Received: by 10.150.213.7 with SMTP id l7mr2620099ybg.424.1317833946648; Wed, 05 Oct 2011 09:59:06 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id w16sm6456777anl.2.2011.10.05.09.59.05 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 09:59:05 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Wed, 5 Oct 2011 11:58:21 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <20111005130936.GB38162@in-addr.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110051158.21747.break19@gmail.com> Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 16:59:07 -0000 On Wednesday, October 05, 2011 9:52:21 AM Arnaud Lacombe wrote: > Hi, > > On Wed, Oct 5, 2011 at 9:09 AM, Gary Palmer wrote: > > On Tue, Oct 04, 2011 at 09:32:52PM -0500, Chuck Burns wrote: > >> On Tuesday, October 04, 2011 8:54:33 PM Chuck Burns wrote: > >> > >> > >> > I'm not sure how to rebuild just the module with that option > >> > URTW_DEBUG enabled.. I'm being told by some to just add the device to > >> > my kernel config along with the line "option URTW_DEBUG" .. but if > >> > there's a better way, let me know please. > >> > > >> > Also, I suppose that means if I want the "any" I sysctl > >> > hw.usb.urtw.debug=0xffffffff right? Still a bit green with regards to > >> > debugging. > >> > >> I wound up adding "#define URTW_DEBUG" to the top of the if_urtw.c file > >> and make install'ing the module from the proper subdirectory.. > > > > Just wanted to make sure that you unloaded and reloaded the module after > > the "make install"? > > actually, it is more tricky than that. > > The sysctl `hw.usb.urtw.debug' only exist when URTW_DEBUG is defined, > but the backing variable, `urtw_debug' is only used during attach to > initialize `sc->sc_debug'. So setting the sysctl afterward is useless, > the only real possibility is either to use the tunable, or directly > use the sysctl's variable in DPRINTF(): > I rebooted since the make install. :) Chuck Burns From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 17:40:14 2011 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 A7520106566B for ; Wed, 5 Oct 2011 17:40:14 +0000 (UTC) (envelope-from sol289@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 764928FC0C for ; Wed, 5 Oct 2011 17:40:14 +0000 (UTC) Received: by iadk27 with SMTP id k27so3019456iad.13 for ; Wed, 05 Oct 2011 10:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=L5dZ7acZzYx+hC6EVHC6HfaylSqLJTizmt2wdwfpnJA=; b=m2X1YMm8V7DpNMdU73h9Vqo09TjH7loyv7TX17O9cpcV5/zormbhAlhKDbCc5ynqk3 6z2ihUp0Gs5RzrRSy0nJRVoL6noSAQEXPmU+I8DgI4czS6c4y0pwDyBeGfoIrmg33w+Y B7dWvIziyFPSZjyV7V+tbpb3EyamFFAtBPzAg= Received: by 10.43.130.136 with SMTP id hm8mr863507icc.202.1317836414115; Wed, 05 Oct 2011 10:40:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.239.73 with HTTP; Wed, 5 Oct 2011 10:39:54 -0700 (PDT) In-Reply-To: References: From: alexander lunyov Date: Wed, 5 Oct 2011 21:39:54 +0400 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: carp on bridge interface: INIT 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, 05 Oct 2011 17:40:14 -0000 On Wed, Oct 5, 2011 at 9:53 AM, alexander lunyov wrote: > I need to make work a scheme like this: > > http://i.imgur.com/1xsXX.png > > So, i have 3 servers: in, out1 and out2; out1 and out2 plugged into > one switched environment, so they can see each other on layer 2, which > is bad for me, because they can make a switching loop in some case. > > out1 and out2 connects with openvpn to "in" in bridged configuration, > tap interfaces have no addresses. > > Then i make bridge interfaces on all servers and adding only tap0 > interfaces to bridge0 on each server, make each bridge0 interface > configured with address from 10.0.0.0/24 subnet. On this moment > everything is working and servers pinging each other 10.0.0.0/24 > address. > > Then i want to make carp work on out1 and out2 on bridge0-tap0 pair, > but if i config carp0 interface to work in 10.0.0.0/24 subnet, it > stays in INIT state forever - so this is my first question - why carp > won't work on bridge0-tap0 interface? > > If i bridge tap0 and em0 interfaces on out1 and out2, then carp on > both servers get into MASTER state, i get switching loop and when i > use tcpdump on bridge0 interfaces (-i bridge0 net 10.0.0.0/24), on > out1 i see ONLY vrrp advertisements from out2 (no advertisements from > out1), on out2 bridge0 i see ONLY advertisements from out1, and on > "in" bridge0 i see advertisements from both servers, and nothing is > working. > > So, here's the second question - how to make things work in this case? > STP? But how to configure it, what interfaces put into STP? And will > my precious carp work with STP? > > > Thank you for your attention. i create carp0 interface with commands: /sbin/ifconfig carp0 create /sbin/ifconfig carp0 vhid 1 advskew 10 pass jkbsvdreg 10.0.0.10/24 /sbin/sysctl net.inet.carp.preempt=1 /sbin/sysctl net.inet.carp.drop_echoed=1 then i see in log: Oct 5 17:11:49 220 kernel: bridge0: promiscuous mode enabled carp interface is: carp0: flags=8 metric 0 mtu 1500 inet 10.0.0.10 netmask 0xffffff00 carp: INIT vhid 1 advbase 1 advskew 10 if i do "ifconfig carp0 up" i see this error in /var/log/messages: Oct 5 17:15:13 220 kernel: ifa_add_loopback_route: insertion failed and carp interface become up carp0: flags=9 metric 0 mtu 1500 inet 10.0.0.10 netmask 0xffffff00 carp: INIT vhid 1 advbase 1 advskew 10 And beside this i don't see any carp log messages. here's sysctls: # sysctl -a | grep carp net.inet.ip.same_prefix_carp_only: 0 net.inet.carp.allow: 1 net.inet.carp.preempt: 1 net.inet.carp.log: 2 net.inet.carp.arpbalance: 0 net.inet.carp.drop_echoed: 1 net.inet.carp.suppress_preempt: 1 system is 8.2-R Interfaces on out1/2 em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:25:90:06:a7:ee inet x.x.x.220 netmask 0xffffff00 broadcast x.x.x.255 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8943 metric 0 mtu 1500 options=2098 ether 00:25:90:06:a7:ef media: Ethernet autoselect status: no carrier lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3 tap0: flags=8943 metric 0 mtu 1500 options=80000 ether 00:bd:39:50:01:00 Opened by PID 1521 bridge0: flags=8943 metric 0 mtu 1500 ether 56:7e:c1:dc:ff:2f inet 10.0.0.20 netmask 0xff000000 broadcast 10.255.255.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 2000000 carp0: flags=8 metric 0 mtu 1500 inet 10.0.0.10 netmask 0xffffff00 carp: INIT vhid 1 advbase 1 advskew 10 -- your sweet isn't ready yet > > -- > your sweet isn't ready yet > From owner-freebsd-net@FreeBSD.ORG Wed Oct 5 23:51:50 2011 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 2F951106566B for ; Wed, 5 Oct 2011 23:51:50 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id E04008FC21 for ; Wed, 5 Oct 2011 23:51:49 +0000 (UTC) Received: by yxk36 with SMTP id 36so2661247yxk.13 for ; Wed, 05 Oct 2011 16:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=JPo85TGelulI33RxZwCX7AasfVc1ksro9B9fGbrfx8Y=; b=C/g3xkYo/HwoHKVMwAZMJ1pis1V3ds9Rnj+jgPQ09xtDIojiJ9/rtaJpJv5d4UNF2O tUCfIQPb9jk6SGs5hEVk2/79MWVEUhwE6gizOU1E/9NxWdaLn/0gyiqXwxq+ASWA8mc1 i+nfwhKdjAAxbV9rddkOTh0C/CjiIMcBrFW4I= Received: by 10.236.190.130 with SMTP id e2mr181489yhn.107.1317858709055; Wed, 05 Oct 2011 16:51:49 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id l42sm4818648yhj.12.2011.10.05.16.51.47 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 16:51:48 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Wed, 5 Oct 2011 18:50:58 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <201110050749.49139.break19@gmail.com> In-Reply-To: <201110050749.49139.break19@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110051850.58888.break19@gmail.com> Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 05 Oct 2011 23:51:50 -0000 On Wednesday, October 05, 2011 7:49:49 AM Chuck Burns wrote: > On Wednesday, October 05, 2011 7:41:51 AM Adrian Chadd wrote: > > On 5 October 2011 20:09, Chuck Burns wrote: > > > I tried to get it to crash last night, by removing and reinserting the > > > adapter, and apparently it only does so when it stops working. > > > > Please post the crash information? > > > > > > > > adrian > > When it crashes again, I will.. It's a random interval. Sometimes it will > go for a few days, sometimes only an hour or so.. Rest assured, as soon > as it crashes again, I will post. :) > > Chuck Burns Ok, it crashed this evening.. Got a snapshot of it with my wife's digital camera.. http://imageshack.us/photo/my-images/851/kernelcrash.jpg/ There is a small "flash dot" as the camera's flash went off, but 99% of it is readable. (thought I'd turned off the flash). Also, as a side note, the machine has a large enough swapfile for a crash dump.. and it didnt reboot reboot on it's own even though it says it will.. From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 00:27:35 2011 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 F18DE106566B for ; Thu, 6 Oct 2011 00:27:35 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B414B8FC0A for ; Thu, 6 Oct 2011 00:27:35 +0000 (UTC) Received: by yxk36 with SMTP id 36so2687092yxk.13 for ; Wed, 05 Oct 2011 17:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=TUHgVjNdlXIHf3m94l1qQhg5vfMtT2iadzugM7Kjj2M=; b=uGwbea4UNOjBRZIqI7yST272/vY+bMeZ1Q2R4q8WWvOuU+knQj2kroWpT9+aO68VH/ 703/qtmXaLql/AeekW1itWuYKVx1eWtIz5WzME+BfazCvoajxntHUkPUNxOA73uHEdVn PhqRSI3SuScCGzV6HmYU03yr4TCyeIZOvTJLs= Received: by 10.150.210.9 with SMTP id i9mr111208ybg.120.1317860854975; Wed, 05 Oct 2011 17:27:34 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id n8sm9742778and.1.2011.10.05.17.27.34 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 17:27:34 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Wed, 5 Oct 2011 19:26:45 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201110051926.45430.break19@gmail.com> Subject: [driver port request] OpenBSD's otus driver. 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, 06 Oct 2011 00:27:36 -0000 The OpenBSD's otus driver supports my TP-Link TL-WN821N (ar9170) usb device quite well, Anyone who is bored want to check into feasibility of porting this driver over to FreeBSD ? I also put in a PR about it a few days ago.. 161251 Chuck Burns From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 04:47:02 2011 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 34BBC106564A for ; Thu, 6 Oct 2011 04:47:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E2C438FC14 for ; Thu, 6 Oct 2011 04:47:01 +0000 (UTC) Received: by ggeq3 with SMTP id q3so1730817gge.13 for ; Wed, 05 Oct 2011 21:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AiyKlyCgBwkRDCoxLFztn9MkbrfNoTuuujeeQu4uDwk=; b=qsTaVlVcS6gh0nCIfHXLPH3IG8Mdbu9yDxfa0oafLj3MrnSBZ8VSh+OUKPSMCj6kJo tfqfgPz7bNFsKaWMgDXKLGqE0y8BP6HR6pRJ351nD8TQLvedmODoVY/vj8NhTNNkG6s5 ID4BFs0PzQ86lYkR/ymdf5a0WQ7JYDIFxuStU= MIME-Version: 1.0 Received: by 10.236.197.104 with SMTP id s68mr1221935yhn.20.1317876421187; Wed, 05 Oct 2011 21:47:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Wed, 5 Oct 2011 21:47:01 -0700 (PDT) In-Reply-To: <201110051850.58888.break19@gmail.com> References: <201110042008.48915.break19@gmail.com> <201110050749.49139.break19@gmail.com> <201110051850.58888.break19@gmail.com> Date: Thu, 6 Oct 2011 12:47:01 +0800 X-Google-Sender-Auth: iemdWTgN9DsoU9-ATwDs4bsEHf4 Message-ID: From: Adrian Chadd To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 06 Oct 2011 04:47:02 -0000 On 6 October 2011 07:50, Chuck Burns wrote: > Ok, it crashed this evening.. Got a snapshot of it with my wife's digital > camera.. > > http://imageshack.us/photo/my-images/851/kernelcrash.jpg/ > > There is a small "flash dot" as the camera's flash went off, but 99% of it is > readable. (thought I'd turned off the flash). > > Also, as a side note, the machine has a large enough swapfile for a crash > dump.. and it didnt reboot reboot on it's own even though it says it will.. So it didn't crashdump? Unless data[] is completely invalid (eg NULL), I can't see how that function would panic.. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 04:57:33 2011 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 964D3106566B for ; Thu, 6 Oct 2011 04:57:33 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 523E48FC14 for ; Thu, 6 Oct 2011 04:57:33 +0000 (UTC) Received: by ggeq3 with SMTP id q3so1735762gge.13 for ; Wed, 05 Oct 2011 21:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=yDZl5G0E9qq4EcEeYeVW0VMZ1MrEBOA3wtRy8mzWxHI=; b=Eq2j7sQFsHWJLcCdHCzo5TdmL4VYa31CMxk14I2fo41oDeHbh+GvoziJ3o7RFKwmQg lUEw7FbnVqV2nuNRvtWwRJVxNXKF6MHgWrZeCPx+JJQ7/V3fm1m4Hps1TZYAppSQ9Unh /T84tZLv8lkdtU8693SnYGtRd23m4pLAHgp1I= Received: by 10.236.190.67 with SMTP id d43mr1123293yhn.78.1317877052645; Wed, 05 Oct 2011 21:57:32 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id v28sm6012747yhi.11.2011.10.05.21.57.31 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 21:57:31 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Wed, 5 Oct 2011 23:56:41 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <201110051850.58888.break19@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110052356.41724.break19@gmail.com> Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 06 Oct 2011 04:57:33 -0000 On Wednesday, October 05, 2011 11:47:01 PM Adrian Chadd wrote: > On 6 October 2011 07:50, Chuck Burns wrote: > > Ok, it crashed this evening.. Got a snapshot of it with my wife's digital > > camera.. > > > > http://imageshack.us/photo/my-images/851/kernelcrash.jpg/ > > > > There is a small "flash dot" as the camera's flash went off, but 99% of > > it is readable. (thought I'd turned off the flash). > > > > Also, as a side note, the machine has a large enough swapfile for a crash > > dump.. and it didnt reboot reboot on it's own even though it says it > > will.. > > So it didn't crashdump? > > Unless data[] is completely invalid (eg NULL), I can't see how that > function would panic.. > > > Adrian No.. it claimed there was no valid dump device configured.. I have a swap partition, that is 6G, and my box has 4G of ram. Also, later this evening, it apparently panic'd again, but my screen was off, and I couldnt get it to do anything without a hard reboot.. and it appeared to have -attempted- to savecore, but said "permission denied" even though /var/crash exists and was writeable by root. I have since created another directory, chown'd it 777 and set it as the dumpdir. From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 05:02:42 2011 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 7BC24106566C for ; Thu, 6 Oct 2011 05:02:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3D0428FC15 for ; Thu, 6 Oct 2011 05:02:41 +0000 (UTC) Received: by ywp17 with SMTP id 17so2859008ywp.13 for ; Wed, 05 Oct 2011 22:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TkhG1B6duwuRokCdYLmBX8TCLjSp3vNwkLZu2LVjhio=; b=Nvw/JDbflrk+ZD+RvpmViGqqCbuO1/UGIanAuluQMnnMBAJ766QaIHRzTEYGgEejT+ Vj1uz3+yb4lIFwtWXZOs4HnU+7VjueUPzVFz22PVp7cdPCi5Y1B3mRrxvYOqzOpPPrLj nhMWj+wRFT1XOTrNsth9CmU8g336e34TBqL78= MIME-Version: 1.0 Received: by 10.236.201.200 with SMTP id b48mr1089675yho.105.1317877361498; Wed, 05 Oct 2011 22:02:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Wed, 5 Oct 2011 22:02:41 -0700 (PDT) In-Reply-To: <201110052356.41724.break19@gmail.com> References: <201110042008.48915.break19@gmail.com> <201110051850.58888.break19@gmail.com> <201110052356.41724.break19@gmail.com> Date: Thu, 6 Oct 2011 13:02:41 +0800 X-Google-Sender-Auth: OM0NdKOfsdHeSpBWQR9IR4UxyYI Message-ID: From: Adrian Chadd To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 06 Oct 2011 05:02:42 -0000 Can you please do some changes: * reconfigure the console to be 80x50 or 80x60? That way we can see the whole panic message * can you please add some printfs() ? Just so we know the value of the parameters being passed into that function? It sounds like once the NIC goes into a "funny" state, it's corrupting something (which may be the symptom; may be the problem) and free'ing the TX/RX buffer ring contents is failing. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 06:46:51 2011 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 28A0F1065670; Thu, 6 Oct 2011 06:46:51 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id A78E28FC08; Thu, 6 Oct 2011 06:46:50 +0000 (UTC) Received: from [89.204.153.167] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RBhjA-0006Ky-Pb; Thu, 06 Oct 2011 08:46:46 +0200 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id p966kZ33001146; Thu, 6 Oct 2011 08:46:36 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id p966kWFn001145; Thu, 6 Oct 2011 08:46:32 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Thu, 6 Oct 2011 08:46:32 +0200 From: Matthias Apitz To: Arnaud Lacombe Message-ID: <20111006064631.GA1087@tiny> References: <1317656199.15510.5.camel@hitfishpass-lx.corp.yahoo.com> <20111004054444.GA10311@tinyCurrent> <20111004083710.GA1054@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 89.204.153.167 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Sean Bruno Subject: b43 driver (was: Re: Broadcom Docs) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 06:46:51 -0000 El día Tuesday, October 04, 2011 a las 11:14:20AM -0400, Arnaud Lacombe escribió: > > Both b43 (via reverse engineering) and brcm (via broadcom developers) > > is getting active development. It'd be nice to have datasheets but you > > don't need them to port the code over. > > > There was an article recently on lwn.net describing the situation > where both the b43 and brcm supported the same chip, and the issue > raised that there was no point in brcm being mainlined in that > state[1]... I'm not sure what the outcome was. > > - Arnaud > > [0]: http://linuxwireless.org/en/users/Drivers/brcm80211 > > ... Hello Arnaud, I read the page http://linuxwireless.org/en/users/Drivers/b43 to see what I could do and if this (porting the driver to FreeBSD) is something matching my knowledge... My chip says: none2@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 USB Controller' class = network I understand this as PCI-ID 14e4:4315 and 4315 seems to be supported by Linux b43 driver. But, on the other hand the page says: Caveats ... If you have an Broadcom USB device, please use the rndis_wlan driver. The b43/b43legacy driver is not meant to support this device. ... So I'm not sure. Or is the above string "BCM4310 USB Controller" just because the FreeBSD kernel does not detect the chip correctly. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 08:15:07 2011 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 277D0106566C for ; Thu, 6 Oct 2011 08:15:07 +0000 (UTC) (envelope-from Bredehorn@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id BA45E8FC15 for ; Thu, 6 Oct 2011 08:15:06 +0000 (UTC) Received: (qmail 6446 invoked by uid 0); 6 Oct 2011 08:15:04 -0000 Received: from 93.159.253.120 by rms-de005.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Thu, 06 Oct 2011 10:15:03 +0200 From: "Rainer Bredehorn" Message-ID: <20111006081503.312020@gmx.net> MIME-Version: 1.0 To: freebsd-net@FreeBSD.org X-Authenticated: #168415 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: sVa/dtVKPjl+FuqlNDU2nA87MTE2NUmr Cc: Subject: Re: IPv6 multicast listener discovery 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, 06 Oct 2011 08:15:07 -0000 >  Thank you. I could not reproduce this on several 8.2 boxes around me >  yet, but do you have a ping response from ff02::2:2d75:f2b8%rl0? Yes I can ping this address from another node and its link local address. From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 08:28:29 2011 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 83E41106564A for ; Thu, 6 Oct 2011 08:28:28 +0000 (UTC) (envelope-from Bredehorn@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id CE0428FC08 for ; Thu, 6 Oct 2011 08:28:27 +0000 (UTC) Received: (qmail 31349 invoked by uid 0); 6 Oct 2011 08:28:26 -0000 Received: from 93.159.253.120 by rms-de007.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Thu, 06 Oct 2011 10:28:24 +0200 From: "Rainer Bredehorn" Message-ID: <20111006082824.311990@gmx.net> MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Authenticated: #168415 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: xxPkfZI3eWUkRq33a29nKysjL0tsZg02 Subject: RE: IPv6 multicast listener discovery 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, 06 Oct 2011 08:28:29 -0000 > ----- Ursprüngliche Nachricht ----- > This address is for IPv6 Node Information Query, called the NI Group Address. > > > > For example, you can issue the command > > > > ping6 -w fe80::250:fcff:feb8:5443%rl0 > > > > you can get your hostname back. I see! So a node gets a multicast address for Node Information Queries. This is obviously the case when a hostname is given in the rc.conf. I would like to recalculate the lower address part. Which part of a hostname like "test1.test.de" do I have to use to calculate the MD5 hash? Do we have more from the RFC experimental stuff for IPv6 implemented in FreeBSD? Rainer. From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 08:33:07 2011 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 A0FEE106564A for ; Thu, 6 Oct 2011 08:33:07 +0000 (UTC) (envelope-from Bredehorn@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 3FCA68FC14 for ; Thu, 6 Oct 2011 08:33:06 +0000 (UTC) Received: (qmail 27217 invoked by uid 0); 6 Oct 2011 08:33:05 -0000 Received: from 93.159.253.120 by rms-de002.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Thu, 06 Oct 2011 10:33:05 +0200 From: "Rainer Bredehorn" Message-ID: <20111006083305.312020@gmx.net> MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Authenticated: #168415 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: iSHrJIoPaHItQqXDJCUlASViamdhZETl Subject: RE: IPv6 multicast listener discovery 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, 06 Oct 2011 08:33:07 -0000 Node Information Query: FF02:0:0:0:0:2:FF00::/104. Where is the 2:FF in my address?? ff02::2:2d75:f2b8 Rainer. From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 12:25:31 2011 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 1E11A1065678 for ; Thu, 6 Oct 2011 12:25:31 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id D0F808FC23 for ; Thu, 6 Oct 2011 12:25:30 +0000 (UTC) Received: by ywp17 with SMTP id 17so3180420ywp.13 for ; Thu, 06 Oct 2011 05:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=MeZx3pkjhS+2Yyie/MHID7IePDOpEEQBoU1u+jn8lM4=; b=NP1SmivjZu9/UlO57ms8nbsRFS3tfC3D3QSG9elPK1tIDq8Q35Qghx7eJSg+7Ti/Hx NefsAX+6PXU45M2TT1L3vGexpAke5bcYtNd/tMBXsg60KXJ1d4usYR9JN2/FGE0FC8Hs b0I9JeeYlEuFAYnE4mHQ70W+Ug9RutdmUI79c= Received: by 10.236.155.170 with SMTP id j30mr2815988yhk.19.1317903930326; Thu, 06 Oct 2011 05:25:30 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id n80sm7296974yhh.7.2011.10.06.05.25.28 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 05:25:29 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Thu, 6 Oct 2011 07:24:38 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <201110052356.41724.break19@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110060724.38890.break19@gmail.com> Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 06 Oct 2011 12:25:31 -0000 On Thursday, October 06, 2011 12:02:41 AM you wrote: > * reconfigure the console to be 80x50 or 80x60? That way we can see > the whole panic message This is now done. > * can you please add some printfs() ? Just so we know the value of the > parameters being passed into that function? > > It sounds like once the NIC goes into a "funny" state, it's corrupting > something (which may be the symptom; may be the problem) and free'ing > the TX/RX buffer ring contents is failing. I have no idea where to put these. I am not really any sort of coder. I can -sometimes- parse source, but usually only when it's fairly documented, but as far as anything else goes.. I'm at a loss. Chuck Burns From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 18:52:53 2011 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 DB4661065670 for ; Thu, 6 Oct 2011 18:52:53 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id AD9188FC0C for ; Thu, 6 Oct 2011 18:52:53 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RBt3s-0003tK-K7; Thu, 06 Oct 2011 14:52:52 -0400 Date: Thu, 6 Oct 2011 14:52:52 -0400 From: Gary Palmer To: Chuck Burns Message-ID: <20111006185252.GD38162@in-addr.com> References: <201110042008.48915.break19@gmail.com> <201110051850.58888.break19@gmail.com> <201110052356.41724.break19@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110052356.41724.break19@gmail.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 06 Oct 2011 18:52:53 -0000 On Wed, Oct 05, 2011 at 11:56:41PM -0500, Chuck Burns wrote: > On Wednesday, October 05, 2011 11:47:01 PM Adrian Chadd wrote: > > On 6 October 2011 07:50, Chuck Burns wrote: > > > Ok, it crashed this evening.. Got a snapshot of it with my wife's digital > > > camera.. > > > > > > http://imageshack.us/photo/my-images/851/kernelcrash.jpg/ > > > > > > There is a small "flash dot" as the camera's flash went off, but 99% of > > > it is readable. (thought I'd turned off the flash). > > > > > > Also, as a side note, the machine has a large enough swapfile for a crash > > > dump.. and it didnt reboot reboot on it's own even though it says it > > > will.. > > > > So it didn't crashdump? > > > > Unless data[] is completely invalid (eg NULL), I can't see how that > > function would panic.. > > > > > > Adrian > No.. it claimed there was no valid dump device configured.. Do you have a /dev/dumpdev symbolic link pointing to a swap partition? If not, the dump device may not have been configured. Also, apologies if you said this earlier, but which version of FreeBSD are you running? Gary From owner-freebsd-net@FreeBSD.ORG Thu Oct 6 23:44:59 2011 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 AA666106566C for ; Thu, 6 Oct 2011 23:44:59 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D2B4D8FC1C for ; Thu, 6 Oct 2011 23:44:58 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so4838522bkb.13 for ; Thu, 06 Oct 2011 16:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LHKQ3RXswWJV7G4654e9EkiLLdMZN4n2IIch+nA4sQ0=; b=vpe0V7apsUTsMK08BSPGOqaKJUduSX/ZpEinh4pQjlSmUSO3RnxQbGi2QCPTYl7MZc GIHZex/kOgGuFpglr6arBXwersI1pXyp0DvGzW7CgVNSxYRaLi08I9SanuoBfQ7POLiw NXE0irOIz9NQH8IrxRpt/dXD8twwk4bKKjiyE= MIME-Version: 1.0 Received: by 10.223.7.83 with SMTP id c19mr6587157fac.16.1317942958954; Thu, 06 Oct 2011 16:15:58 -0700 (PDT) Received: by 10.152.36.102 with HTTP; Thu, 6 Oct 2011 16:15:58 -0700 (PDT) Date: Thu, 6 Oct 2011 16:15:58 -0700 Message-ID: From: Jason Wolfe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 06 Oct 2011 23:44:59 -0000 I'm seeing the interface wedge on a good number of systems with Intel 82574L chips under FBSD8.2 _only when MSI-X is enabled_, running either 7.1.9 from 8.2-RELEASE or 7.2.3 from 8.2-STABLE. I have em0 and em1 in a lagg, but only one side would fail, and a few systems that didn't have a lagg also saw the issue. Higher traffic did seem to increase the likely hood of it cropping up, but lower traffic server also showed the same issues (anywhere from 200Mb/s -> 1.8Gb/s). This wedging on the Intel chips has been discussed in many threads over the past year, though some have turned out to be various other issues. I haven't seen reports of it being fixed by disabling MSI-X via loader.conf, hw.em.enable_msix=0, so I figured I'd start a fresh one. The band aid for me was throwing a quick script into cron that watched for incrementing drops and static outgoing packet counts from netstat, then just bounced the interface with ifconfig down/up. Prior to the bounce I had it emailing me the output of the following commands: vmstat -i netstat -m netstat -ndi sysctl dev.em.X.debug=1 sysctl net.inet.ip.intr_queue_maxlen net.inet.ip.intr_queue_drops dev.em I have ~300 reports from over the course of a week or so while I played with various bits before finding MSI-X to be the culprit. These were all collected about a month ago, but as I'm seeing now the increased latency with MSI-X disabled (as discussed in another thread) I'm more interested in seeing we can tackle this. I can bounce them over to anyone interested. Random one, follow by pciconf output: I bounced em1 because dropped packets incremented 3175498 to 3175688 and the interface is not incrementing packets out. interrupt total rate irq3: uart1 94210 0 cpu0: timer 8536176695 2000 irq256: em0:rx 0 24657925778 5777 irq257: em0:tx 0 18016438387 4221 irq258: em0:link 1096 0 irq259: em1:rx 0 49440830 11 irq260: em1:tx 0 17831558454 4177 irq261: em1:link 3 0 irq262: mps0 971428418 227 cpu1: timer 8536168686 2000 cpu2: timer 8536168739 2000 cpu3: timer 8536168715 2000 Total 95671570011 22415 43620/31830/75450 mbufs in use (current/cache/total) 8457/1825/10282/6192924 mbuf clusters in use (current/cache/total/max) 8457/1490 mbuf+clusters out of packet secondary zone in use (current/cache) 32620/3569/36189/3096461 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) 158299K/25883K/184182K 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 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:25:90:2c:a8:c8 70347342717 2290 0 53256848932 0 0 1209615 em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 5 - - - em1 1500 00:25:90:2c:a8:c8 49440879 0 0 50500079972 0 0 3176057 em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 2 - - - lagg0 1500 00:25:90:2c:a8:c8 70396711726 0 0 103748441456 4385672 0 0 lagg0 1500 117.121.249.0 117.121.249.76 46351366311 - - 103757765366 - - - lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 607 - - 674 - - - lagg0 1500 2402:6800:730 2402:6800:730:12: 136847 - - 142450 - - - Aug 30 23:05:04 cds56 kernel: Interface is RUNNING and INACTIVE Aug 30 23:05:04 cds56 kernel: em0: hw tdh = 371, hw tdt = 376 Aug 30 23:05:04 cds56 kernel: em0: hw rdh = 923, hw rdt = 922 Aug 30 23:05:04 cds56 kernel: em0: Tx Queue Status = 0 Aug 30 23:05:04 cds56 kernel: em0: TX descriptors avail = 1014 Aug 30 23:05:04 cds56 kernel: em0: Tx Descriptors avail failure = 0 Aug 30 23:05:04 cds56 kernel: em0: RX discarded packets = 0 Aug 30 23:05:04 cds56 kernel: em0: RX Next to Check = 986 Aug 30 23:05:04 cds56 kernel: em0: RX Next to Refresh = 994 Aug 30 23:05:04 cds56 kernel: Interface is RUNNING and INACTIVE Aug 30 23:05:04 cds56 kernel: em1: hw tdh = 78, hw tdt = 78 Aug 30 23:05:04 cds56 kernel: em1: hw rdh = 88, hw rdt = 87 Aug 30 23:05:04 cds56 kernel: em1: Tx Queue Status = 0 Aug 30 23:05:04 cds56 kernel: em1: TX descriptors avail = 1024 Aug 30 23:05:04 cds56 kernel: em1: Tx Descriptors avail failure = 0 Aug 30 23:05:04 cds56 kernel: em1: RX discarded packets = 0 Aug 30 23:05:04 cds56 kernel: em1: RX Next to Check = 88 Aug 30 23:05:04 cds56 kernel: em1: RX Next to Refresh = 88 net.inet.ip.intr_queue_maxlen: 512 net.inet.ip.intr_queue_drops: 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.link_irq: 1096 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1477444168 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 923 dev.em.0.queue0.txd_tail: 923 dev.em.0.queue0.tx_irq: 18016443069 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 620 dev.em.0.queue0.rxd_tail: 619 dev.em.0.queue0.rx_irq: 24617484192 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 2290 dev.em.0.mac_stats.recv_no_buff: 2063 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 34 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 2281 dev.em.0.mac_stats.total_pkts_recvd: 70347571042 dev.em.0.mac_stats.good_pkts_recvd: 70347568752 dev.em.0.mac_stats.bcast_pkts_recvd: 49354826 dev.em.0.mac_stats.mcast_pkts_recvd: 21430 dev.em.0.mac_stats.rx_frames_64: 24097227332 dev.em.0.mac_stats.rx_frames_65_127: 26282000524 dev.em.0.mac_stats.rx_frames_128_255: 117491895 dev.em.0.mac_stats.rx_frames_256_511: 397131263 dev.em.0.mac_stats.rx_frames_512_1023: 1048868288 dev.em.0.mac_stats.rx_frames_1024_1522: 18404849450 dev.em.0.mac_stats.good_octets_recvd: 32288605684532 dev.em.0.mac_stats.good_octets_txd: 59508100377248 dev.em.0.mac_stats.total_pkts_txd: 53257111032 dev.em.0.mac_stats.good_pkts_txd: 53257108716 dev.em.0.mac_stats.bcast_pkts_txd: 21098 dev.em.0.mac_stats.mcast_pkts_txd: 28465 dev.em.0.mac_stats.tx_frames_64: 1243827849 dev.em.0.mac_stats.tx_frames_65_127: 12126816593 dev.em.0.mac_stats.tx_frames_128_255: 260192405 dev.em.0.mac_stats.tx_frames_256_511: 196901153 dev.em.0.mac_stats.tx_frames_512_1023: 565384449 dev.em.0.mac_stats.tx_frames_1024_1522: 38863986268 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 571 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 dev.em.1.%parent: pci2 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.flow_control: 3 dev.em.1.link_irq: 3 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1477444168 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 78 dev.em.1.queue0.txd_tail: 78 dev.em.1.queue0.tx_irq: 17831483878 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 104 dev.em.1.queue0.rxd_tail: 103 dev.em.1.queue0.rx_irq: 49440805 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 0 dev.em.1.mac_stats.recv_no_buff: 0 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 49440891 dev.em.1.mac_stats.good_pkts_recvd: 49440891 dev.em.1.mac_stats.bcast_pkts_recvd: 49419308 dev.em.1.mac_stats.mcast_pkts_recvd: 21444 dev.em.1.mac_stats.rx_frames_64: 49419319 dev.em.1.mac_stats.rx_frames_65_127: 21536 dev.em.1.mac_stats.rx_frames_128_255: 1 dev.em.1.mac_stats.rx_frames_256_511: 11 dev.em.1.mac_stats.rx_frames_512_1023: 13 dev.em.1.mac_stats.rx_frames_1024_1522: 11 dev.em.1.mac_stats.good_octets_recvd: 3165480294 dev.em.1.mac_stats.good_octets_txd: 58735098276348 dev.em.1.mac_stats.total_pkts_txd: 50500079972 dev.em.1.mac_stats.good_pkts_txd: 50500079972 dev.em.1.mac_stats.bcast_pkts_txd: 0 dev.em.1.mac_stats.mcast_pkts_txd: 5 dev.em.1.mac_stats.tx_frames_64: 1267032327 dev.em.1.mac_stats.tx_frames_65_127: 9722353368 dev.em.1.mac_stats.tx_frames_128_255: 265847363 dev.em.1.mac_stats.tx_frames_256_511: 198177596 dev.em.1.mac_stats.tx_frames_512_1023: 568826323 dev.em.1.mac_stats.tx_frames_1024_1522: 38477842995 dev.em.1.mac_stats.tso_txd: 0 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 4 dev.em.1.interrupts.rx_pkt_timer: 0 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 0 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 0 hostb0@pci0:0:0:0: class=0x060000 card=0x00008086 chip=0x34068086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub to ESI Port' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x00008086 chip=0x34088086 rev=0x22 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 1' class = bridge subclass = PCI-PCI pcib2@pci0:0:2:0: class=0x060400 card=0x00008086 chip=0x34098086 rev=0x22 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 2' class = bridge subclass = PCI-PCI pcib3@pci0:0:3:0: class=0x060400 card=0x00008086 chip=0x340a8086 rev=0x22 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 3' class = bridge subclass = PCI-PCI pcib4@pci0:0:5:0: class=0x060400 card=0x00008086 chip=0x340c8086 rev=0x22 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 5' class = bridge subclass = PCI-PCI pcib5@pci0:0:7:0: class=0x060400 card=0x00008086 chip=0x340e8086 rev=0x22 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 7' class = bridge subclass = PCI-PCI ioapic0@pci0:0:19:0: class=0x080020 card=0x00000000 chip=0x342d8086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub I/OxAPIC Interrupt Controller' class = base peripheral subclass = interrupt controller bar [10] = type Memory, range 32, base 0xfec8a000, size 4096, enabled none0@pci0:0:20:0: class=0x080000 card=0x00000000 chip=0x342e8086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub System Management Registers' class = base peripheral subclass = interrupt controller none1@pci0:0:20:1: class=0x080000 card=0x00000000 chip=0x34228086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub GPIO and Scratch Pad Registers' class = base peripheral subclass = interrupt controller none2@pci0:0:20:2: class=0x080000 card=0x00000000 chip=0x34238086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub Control Status and RAS Registers' class = base peripheral subclass = interrupt controller none3@pci0:0:20:3: class=0x080000 card=0x00000000 chip=0x34388086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub Throttle Registers' class = base peripheral subclass = interrupt controller none4@pci0:0:22:0: class=0x088000 card=0x000715d9 chip=0x34308086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral bar [10] = type Memory, range 64, base 0xfbed8000, size 16384, enabled none5@pci0:0:22:1: class=0x088000 card=0x000715d9 chip=0x34318086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral bar [10] = type Memory, range 64, base 0xfbedc000, size 16384, enabled none6@pci0:0:22:2: class=0x088000 card=0x000715d9 chip=0x34328086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral bar [10] = type Memory, range 64, base 0xfbee0000, size 16384, enabled none7@pci0:0:22:3: class=0x088000 card=0x000715d9 chip=0x34338086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral bar [10] = type Memory, range 64, base 0xfbee4000, size 16384, enabled none8@pci0:0:22:4: class=0x088000 card=0x000715d9 chip=0x34298086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral bar [10] = type Memory, range 64, base 0xfbee8000, size 16384, enabled none9@pci0:0:22:5: class=0x088000 card=0x000715d9 chip=0x342a8086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral bar [10] = type Memory, range 64, base 0xfbeec000, size 16384, enabled none10@pci0:0:22:6: class=0x088000 card=0x000715d9 chip=0x342b8086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral bar [10] = type Memory, range 64, base 0xfbef0000, size 16384, enabled none11@pci0:0:22:7: class=0x088000 card=0x000715d9 chip=0x342c8086 rev=0x22 hdr=0x00 vendor = 'Intel Corporation' device = 'DMA Engine' class = base peripheral bar [10] = type Memory, range 64, base 0xfbef4000, size 16384, enabled none12@pci0:0:26:0: class=0x0c0300 card=0x000715d9 chip=0x3a378086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *4' class = serial bus subclass = USB none13@pci0:0:26:1: class=0x0c0300 card=0x000715d9 chip=0x3a388086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *5' class = serial bus subclass = USB none14@pci0:0:26:2: class=0x0c0300 card=0x000715d9 chip=0x3a398086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *6' class = serial bus subclass = USB none15@pci0:0:26:7: class=0x0c0320 card=0x000715d9 chip=0x3a3c8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB EHCI Controller *2' class = serial bus subclass = USB none16@pci0:0:29:0: class=0x0c0300 card=0x000715d9 chip=0x3a348086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *1' class = serial bus subclass = USB none17@pci0:0:29:1: class=0x0c0300 card=0x000715d9 chip=0x3a358086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *2' class = serial bus subclass = USB none18@pci0:0:29:2: class=0x0c0300 card=0x000715d9 chip=0x3a368086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *3' class = serial bus subclass = USB none19@pci0:0:29:7: class=0x0c0320 card=0x000715d9 chip=0x3a3a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB EHCI Controller *1' class = serial bus subclass = USB pcib6@pci0:0:30:0: class=0x060401 card=0x000715d9 chip=0x244e8086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x000715d9 chip=0x3a188086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:2: class=0x01018f card=0x000715d9 chip=0x3a208086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'SATA2(4Port2) (ICH10 Family)' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xbc00, size 8, enabled bar [14] = type I/O Port, range 32, base 0xb880, size 4, enabled bar [18] = type I/O Port, range 32, base 0xb800, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xb480, size 4, enabled bar [20] = type I/O Port, range 32, base 0xb400, size 16, enabled bar [24] = type I/O Port, range 32, base 0xb080, size 16, enabled none20@pci0:0:31:3: class=0x0c0500 card=0x000715d9 chip=0x3a308086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'SMB controller (50011458)' class = serial bus subclass = SMBus bar [10] = type Memory, range 64, base 0xfbefa000, size 256, enabled bar [20] = type I/O Port, range 32, base 0x400, size 32, enabled atapci1@pci0:0:31:5: class=0x010185 card=0x000715d9 chip=0x3a268086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'SATA2(2Port2) (ICH10 Family)' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xac00, size 8, enabled bar [14] = type I/O Port, range 32, base 0xa880, size 4, enabled bar [18] = type I/O Port, range 32, base 0xa800, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xa480, size 4, enabled bar [20] = type I/O Port, range 32, base 0xa400, size 16, enabled bar [24] = type I/O Port, range 32, base 0xa080, size 16, enabled em0@pci0:1:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfbbe0000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xcc00, size 32, enabled bar [1c] = type Memory, range 32, base 0xfbbdc000, size 16384, enabled em1@pci0:2:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfbce0000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled bar [1c] = type Memory, range 32, base 0xfbcdc000, size 16384, enabled mps0@pci0:4:0:0: class=0x010700 card=0x040015d9 chip=0x00721000 rev=0x02 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class = mass storage subclass = SAS bar [10] = type I/O Port, range 32, base 0xe000, size 256, enabled bar [14] = type Memory, range 64, base 0xfbd3c000, size 16384, enabled bar [1c] = type Memory, range 64, base 0xfbd40000, size 262144, enabled vgapci0@pci0:6:1:0: class=0x030000 card=0x000715d9 chip=0x0532102b rev=0x0a hdr=0x00 vendor = 'Matrox Electronic Systems Ltd.' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 32, base 0xf9000000, size 16777216, enabled bar [14] = type Memory, range 32, base 0xfaffc000, size 16384, enabled bar [18] = type Memory, range 32, base 0xfb000000, size 8388608, enabled hostb1@pci0:255:0:0: class=0x060000 card=0x80868086 chip=0x2c708086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb2@pci0:255:0:1: class=0x060000 card=0x80868086 chip=0x2d818086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb3@pci0:255:2:0: class=0x060000 card=0x80868086 chip=0x2d908086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb4@pci0:255:2:1: class=0x060000 card=0x80868086 chip=0x2d918086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb5@pci0:255:2:2: class=0x060000 card=0x80868086 chip=0x2d928086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb6@pci0:255:2:3: class=0x060000 card=0x80868086 chip=0x2d938086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb7@pci0:255:2:4: class=0x060000 card=0x80868086 chip=0x2d948086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb8@pci0:255:2:5: class=0x060000 card=0x80868086 chip=0x2d958086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb9@pci0:255:3:0: class=0x060000 card=0x80868086 chip=0x2d988086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb10@pci0:255:3:1: class=0x060000 card=0x80868086 chip=0x2d998086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb11@pci0:255:3:2: class=0x060000 card=0x80868086 chip=0x2d9a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb12@pci0:255:3:4: class=0x060000 card=0x80868086 chip=0x2d9c8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb13@pci0:255:4:0: class=0x060000 card=0x80868086 chip=0x2da08086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb14@pci0:255:4:1: class=0x060000 card=0x80868086 chip=0x2da18086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb15@pci0:255:4:2: class=0x060000 card=0x80868086 chip=0x2da28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb16@pci0:255:4:3: class=0x060000 card=0x80868086 chip=0x2da38086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb17@pci0:255:5:0: class=0x060000 card=0x80868086 chip=0x2da88086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb18@pci0:255:5:1: class=0x060000 card=0x80868086 chip=0x2da98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb19@pci0:255:5:2: class=0x060000 card=0x80868086 chip=0x2daa8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb20@pci0:255:5:3: class=0x060000 card=0x80868086 chip=0x2dab8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb21@pci0:255:6:0: class=0x060000 card=0x80868086 chip=0x2db08086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb22@pci0:255:6:1: class=0x060000 card=0x80868086 chip=0x2db18086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb23@pci0:255:6:2: class=0x060000 card=0x80868086 chip=0x2db28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI hostb24@pci0:255:6:3: class=0x060000 card=0x80868086 chip=0x2db38086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI Thank you in advance sirs! Jason Wolfe From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 00:02:53 2011 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 70916106566B for ; Fri, 7 Oct 2011 00:02:53 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F34468FC14 for ; Fri, 7 Oct 2011 00:02:52 +0000 (UTC) Received: by vws11 with SMTP id 11so3857002vws.13 for ; Thu, 06 Oct 2011 17:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RC+hZuNhOeV8QFG33o9OH8V/FYis8nHmDIlGRw6QhOU=; b=YhyXKISZ5PtKlw3rjGL5XOnNpKSNpyOayoagJRkDpdovnKcnbxneQiH+yIT1s2FK6u ulDm2tknixiAZMsjcJ8Sdu7+aaaGfrVIcxY0QSpc2G6gEeLsOVvQdeMmLRlKWtsWRj9N zRN9oABJbbHqInxY9RalMeb3pLCShd0/TbDmc= MIME-Version: 1.0 Received: by 10.52.182.198 with SMTP id eg6mr288174vdc.16.1317945772064; Thu, 06 Oct 2011 17:02:52 -0700 (PDT) Received: by 10.220.155.147 with HTTP; Thu, 6 Oct 2011 17:02:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Oct 2011 17:02:51 -0700 Message-ID: From: Jack Vogel To: Jason Wolfe 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 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 00:02:53 -0000 There are plenty other users using the 574 with MSI-X without issue, so its likely more complicated than just that 1 variable. The issue discussed was like last year, it has to do with getting stuck in low power state, and my driver has code that addresses that. There was rigorous testing done at the performance center in Canada, got to the point of having a hang once in maybe 3 weeks, and then that was fixed. I have not heard of a problem from Mike since. So, I'd say something else must be coming into play here, I'll stare at the data a bit when I get a chance and see if anything jumps out at me. Jack On Thu, Oct 6, 2011 at 4:15 PM, Jason Wolfe wrote: > I'm seeing the interface wedge on a good number of systems with Intel > 82574L > chips under FBSD8.2 _only when MSI-X is enabled_, running either 7.1.9 from > 8.2-RELEASE or 7.2.3 from 8.2-STABLE. I have em0 and em1 in a lagg, but > only one side would fail, and a few systems that didn't have a lagg also > saw > the issue. Higher traffic did seem to increase the likely hood of it > cropping up, but lower traffic server also showed the same issues (anywhere > from 200Mb/s -> 1.8Gb/s). This wedging on the Intel chips has been > discussed in many threads over the past year, though some have turned out > to > be various other issues. I haven't seen reports of it being fixed by > disabling MSI-X via loader.conf, hw.em.enable_msix=0, so I figured I'd > start > a fresh one. > > The band aid for me was throwing a quick script into cron that watched for > incrementing drops and static outgoing packet counts from netstat, then > just > bounced the interface with ifconfig down/up. Prior to the bounce I had it > emailing me the output of the following commands: > > vmstat -i > netstat -m > netstat -ndi > sysctl dev.em.X.debug=1 > sysctl net.inet.ip.intr_queue_maxlen net.inet.ip.intr_queue_drops dev.em > > I have ~300 reports from over the course of a week or so while I played > with > various bits before finding MSI-X to be the culprit. These were all > collected about a month ago, but as I'm seeing now the increased latency > with MSI-X disabled (as discussed in another thread) I'm more interested in > seeing we can tackle this. I can bounce them over to anyone interested. > Random one, follow by pciconf output: > > I bounced em1 because dropped packets incremented 3175498 to 3175688 and > the > interface is not incrementing packets out. > > interrupt total rate > irq3: uart1 94210 0 > cpu0: timer 8536176695 2000 > irq256: em0:rx 0 24657925778 5777 > irq257: em0:tx 0 18016438387 4221 > irq258: em0:link 1096 0 > irq259: em1:rx 0 49440830 11 > irq260: em1:tx 0 17831558454 4177 > irq261: em1:link 3 0 > irq262: mps0 971428418 227 > cpu1: timer 8536168686 2000 > cpu2: timer 8536168739 2000 > cpu3: timer 8536168715 2000 > Total 95671570011 22415 > > 43620/31830/75450 mbufs in use (current/cache/total) > 8457/1825/10282/6192924 mbuf clusters in use (current/cache/total/max) > 8457/1490 mbuf+clusters out of packet secondary zone in use (current/cache) > 32620/3569/36189/3096461 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) > 158299K/25883K/184182K 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 > > Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop > em0 1500 00:25:90:2c:a8:c8 70347342717 2290 0 53256848932 0 0 > 1209615 > em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 5 - - - > em1 1500 00:25:90:2c:a8:c8 49440879 0 0 50500079972 0 0 3176057 > em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 2 - - - > lagg0 1500 00:25:90:2c:a8:c8 70396711726 0 0 103748441456 4385672 > 0 > 0 > lagg0 1500 117.121.249.0 117.121.249.76 46351366311 - - 103757765366 - - - > lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 607 - - 674 - - - > lagg0 1500 2402:6800:730 2402:6800:730:12: 136847 - - 142450 - - - > > Aug 30 23:05:04 cds56 kernel: Interface is RUNNING and INACTIVE > Aug 30 23:05:04 cds56 kernel: em0: hw tdh = 371, hw tdt = 376 > Aug 30 23:05:04 cds56 kernel: em0: hw rdh = 923, hw rdt = 922 > Aug 30 23:05:04 cds56 kernel: em0: Tx Queue Status = 0 > Aug 30 23:05:04 cds56 kernel: em0: TX descriptors avail = 1014 > Aug 30 23:05:04 cds56 kernel: em0: Tx Descriptors avail failure = 0 > Aug 30 23:05:04 cds56 kernel: em0: RX discarded packets = 0 > Aug 30 23:05:04 cds56 kernel: em0: RX Next to Check = 986 > Aug 30 23:05:04 cds56 kernel: em0: RX Next to Refresh = 994 > Aug 30 23:05:04 cds56 kernel: Interface is RUNNING and INACTIVE > Aug 30 23:05:04 cds56 kernel: em1: hw tdh = 78, hw tdt = 78 > Aug 30 23:05:04 cds56 kernel: em1: hw rdh = 88, hw rdt = 87 > Aug 30 23:05:04 cds56 kernel: em1: Tx Queue Status = 0 > Aug 30 23:05:04 cds56 kernel: em1: TX descriptors avail = 1024 > Aug 30 23:05:04 cds56 kernel: em1: Tx Descriptors avail failure = 0 > Aug 30 23:05:04 cds56 kernel: em1: RX discarded packets = 0 > Aug 30 23:05:04 cds56 kernel: em1: RX Next to Check = 88 > Aug 30 23:05:04 cds56 kernel: em1: RX Next to Refresh = 88 > > net.inet.ip.intr_queue_maxlen: 512 > net.inet.ip.intr_queue_drops: 0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 > subdevice=0x10d3 class=0x020000 > dev.em.0.%parent: pci1 > dev.em.0.nvm: -1 > dev.em.0.debug: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.0.flow_control: 3 > dev.em.0.link_irq: 1096 > dev.em.0.mbuf_alloc_fail: 0 > dev.em.0.cluster_alloc_fail: 0 > dev.em.0.dropped: 0 > dev.em.0.tx_dma_fail: 0 > dev.em.0.rx_overruns: 0 > dev.em.0.watchdog_timeouts: 0 > dev.em.0.device_control: 1477444168 > dev.em.0.rx_control: 67141634 > dev.em.0.fc_high_water: 18432 > dev.em.0.fc_low_water: 16932 > dev.em.0.queue0.txd_head: 923 > dev.em.0.queue0.txd_tail: 923 > dev.em.0.queue0.tx_irq: 18016443069 > dev.em.0.queue0.no_desc_avail: 0 > dev.em.0.queue0.rxd_head: 620 > dev.em.0.queue0.rxd_tail: 619 > dev.em.0.queue0.rx_irq: 24617484192 > dev.em.0.mac_stats.excess_coll: 0 > dev.em.0.mac_stats.single_coll: 0 > dev.em.0.mac_stats.multiple_coll: 0 > dev.em.0.mac_stats.late_coll: 0 > dev.em.0.mac_stats.collision_count: 0 > dev.em.0.mac_stats.symbol_errors: 0 > dev.em.0.mac_stats.sequence_errors: 0 > dev.em.0.mac_stats.defer_count: 0 > dev.em.0.mac_stats.missed_packets: 2290 > dev.em.0.mac_stats.recv_no_buff: 2063 > dev.em.0.mac_stats.recv_undersize: 0 > dev.em.0.mac_stats.recv_fragmented: 0 > dev.em.0.mac_stats.recv_oversize: 0 > dev.em.0.mac_stats.recv_jabber: 0 > dev.em.0.mac_stats.recv_errs: 0 > dev.em.0.mac_stats.crc_errs: 0 > dev.em.0.mac_stats.alignment_errs: 0 > dev.em.0.mac_stats.coll_ext_errs: 0 > dev.em.0.mac_stats.xon_recvd: 0 > dev.em.0.mac_stats.xon_txd: 34 > dev.em.0.mac_stats.xoff_recvd: 0 > dev.em.0.mac_stats.xoff_txd: 2281 > dev.em.0.mac_stats.total_pkts_recvd: 70347571042 > dev.em.0.mac_stats.good_pkts_recvd: 70347568752 > dev.em.0.mac_stats.bcast_pkts_recvd: 49354826 > dev.em.0.mac_stats.mcast_pkts_recvd: 21430 > dev.em.0.mac_stats.rx_frames_64: 24097227332 > dev.em.0.mac_stats.rx_frames_65_127: 26282000524 > dev.em.0.mac_stats.rx_frames_128_255: 117491895 > dev.em.0.mac_stats.rx_frames_256_511: 397131263 > dev.em.0.mac_stats.rx_frames_512_1023: 1048868288 > dev.em.0.mac_stats.rx_frames_1024_1522: 18404849450 > dev.em.0.mac_stats.good_octets_recvd: 32288605684532 > dev.em.0.mac_stats.good_octets_txd: 59508100377248 > dev.em.0.mac_stats.total_pkts_txd: 53257111032 > dev.em.0.mac_stats.good_pkts_txd: 53257108716 > dev.em.0.mac_stats.bcast_pkts_txd: 21098 > dev.em.0.mac_stats.mcast_pkts_txd: 28465 > dev.em.0.mac_stats.tx_frames_64: 1243827849 > dev.em.0.mac_stats.tx_frames_65_127: 12126816593 > dev.em.0.mac_stats.tx_frames_128_255: 260192405 > dev.em.0.mac_stats.tx_frames_256_511: 196901153 > dev.em.0.mac_stats.tx_frames_512_1023: 565384449 > dev.em.0.mac_stats.tx_frames_1024_1522: 38863986268 > dev.em.0.mac_stats.tso_txd: 0 > dev.em.0.mac_stats.tso_ctx_fail: 0 > dev.em.0.interrupts.asserts: 571 > dev.em.0.interrupts.rx_pkt_timer: 0 > dev.em.0.interrupts.rx_abs_timer: 0 > dev.em.0.interrupts.tx_pkt_timer: 0 > dev.em.0.interrupts.tx_abs_timer: 0 > dev.em.0.interrupts.tx_queue_empty: 0 > dev.em.0.interrupts.tx_queue_min_thresh: 0 > dev.em.0.interrupts.rx_desc_min_thresh: 0 > dev.em.0.interrupts.rx_overrun: 0 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 > dev.em.1.%driver: em > dev.em.1.%location: slot=0 function=0 > dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 > subdevice=0x10d3 class=0x020000 > dev.em.1.%parent: pci2 > dev.em.1.nvm: -1 > dev.em.1.debug: -1 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 100 > dev.em.1.flow_control: 3 > dev.em.1.link_irq: 3 > dev.em.1.mbuf_alloc_fail: 0 > dev.em.1.cluster_alloc_fail: 0 > dev.em.1.dropped: 0 > dev.em.1.tx_dma_fail: 0 > dev.em.1.rx_overruns: 0 > dev.em.1.watchdog_timeouts: 0 > dev.em.1.device_control: 1477444168 > dev.em.1.rx_control: 67141634 > dev.em.1.fc_high_water: 18432 > dev.em.1.fc_low_water: 16932 > dev.em.1.queue0.txd_head: 78 > dev.em.1.queue0.txd_tail: 78 > dev.em.1.queue0.tx_irq: 17831483878 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 104 > dev.em.1.queue0.rxd_tail: 103 > dev.em.1.queue0.rx_irq: 49440805 > dev.em.1.mac_stats.excess_coll: 0 > dev.em.1.mac_stats.single_coll: 0 > dev.em.1.mac_stats.multiple_coll: 0 > dev.em.1.mac_stats.late_coll: 0 > dev.em.1.mac_stats.collision_count: 0 > dev.em.1.mac_stats.symbol_errors: 0 > dev.em.1.mac_stats.sequence_errors: 0 > dev.em.1.mac_stats.defer_count: 0 > dev.em.1.mac_stats.missed_packets: 0 > dev.em.1.mac_stats.recv_no_buff: 0 > dev.em.1.mac_stats.recv_undersize: 0 > dev.em.1.mac_stats.recv_fragmented: 0 > dev.em.1.mac_stats.recv_oversize: 0 > dev.em.1.mac_stats.recv_jabber: 0 > dev.em.1.mac_stats.recv_errs: 0 > dev.em.1.mac_stats.crc_errs: 0 > dev.em.1.mac_stats.alignment_errs: 0 > dev.em.1.mac_stats.coll_ext_errs: 0 > dev.em.1.mac_stats.xon_recvd: 0 > dev.em.1.mac_stats.xon_txd: 0 > dev.em.1.mac_stats.xoff_recvd: 0 > dev.em.1.mac_stats.xoff_txd: 0 > dev.em.1.mac_stats.total_pkts_recvd: 49440891 > dev.em.1.mac_stats.good_pkts_recvd: 49440891 > dev.em.1.mac_stats.bcast_pkts_recvd: 49419308 > dev.em.1.mac_stats.mcast_pkts_recvd: 21444 > dev.em.1.mac_stats.rx_frames_64: 49419319 > dev.em.1.mac_stats.rx_frames_65_127: 21536 > dev.em.1.mac_stats.rx_frames_128_255: 1 > dev.em.1.mac_stats.rx_frames_256_511: 11 > dev.em.1.mac_stats.rx_frames_512_1023: 13 > dev.em.1.mac_stats.rx_frames_1024_1522: 11 > dev.em.1.mac_stats.good_octets_recvd: 3165480294 > dev.em.1.mac_stats.good_octets_txd: 58735098276348 > dev.em.1.mac_stats.total_pkts_txd: 50500079972 > dev.em.1.mac_stats.good_pkts_txd: 50500079972 > dev.em.1.mac_stats.bcast_pkts_txd: 0 > dev.em.1.mac_stats.mcast_pkts_txd: 5 > dev.em.1.mac_stats.tx_frames_64: 1267032327 > dev.em.1.mac_stats.tx_frames_65_127: 9722353368 > dev.em.1.mac_stats.tx_frames_128_255: 265847363 > dev.em.1.mac_stats.tx_frames_256_511: 198177596 > dev.em.1.mac_stats.tx_frames_512_1023: 568826323 > dev.em.1.mac_stats.tx_frames_1024_1522: 38477842995 > dev.em.1.mac_stats.tso_txd: 0 > dev.em.1.mac_stats.tso_ctx_fail: 0 > dev.em.1.interrupts.asserts: 4 > dev.em.1.interrupts.rx_pkt_timer: 0 > dev.em.1.interrupts.rx_abs_timer: 0 > dev.em.1.interrupts.tx_pkt_timer: 0 > dev.em.1.interrupts.tx_abs_timer: 0 > dev.em.1.interrupts.tx_queue_empty: 0 > dev.em.1.interrupts.tx_queue_min_thresh: 0 > dev.em.1.interrupts.rx_desc_min_thresh: 0 > dev.em.1.interrupts.rx_overrun: 0 > > hostb0@pci0:0:0:0: class=0x060000 card=0x00008086 chip=0x34068086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub to ESI Port' > class = bridge > subclass = HOST-PCI > pcib1@pci0:0:1:0: class=0x060400 card=0x00008086 chip=0x34088086 rev=0x22 > hdr=0x01 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub PCI Express Root Port 1' > class = bridge > subclass = PCI-PCI > pcib2@pci0:0:2:0: class=0x060400 card=0x00008086 chip=0x34098086 rev=0x22 > hdr=0x01 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub PCI Express Root Port 2' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:3:0: class=0x060400 card=0x00008086 chip=0x340a8086 rev=0x22 > hdr=0x01 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub PCI Express Root Port 3' > class = bridge > subclass = PCI-PCI > pcib4@pci0:0:5:0: class=0x060400 card=0x00008086 chip=0x340c8086 rev=0x22 > hdr=0x01 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub PCI Express Root Port 5' > class = bridge > subclass = PCI-PCI > pcib5@pci0:0:7:0: class=0x060400 card=0x00008086 chip=0x340e8086 rev=0x22 > hdr=0x01 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub PCI Express Root Port 7' > class = bridge > subclass = PCI-PCI > ioapic0@pci0:0:19:0: class=0x080020 card=0x00000000 chip=0x342d8086 > rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub I/OxAPIC Interrupt Controller' > class = base peripheral > subclass = interrupt controller > bar [10] = type Memory, range 32, base 0xfec8a000, size 4096, enabled > none0@pci0:0:20:0: class=0x080000 card=0x00000000 chip=0x342e8086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub System Management Registers' > class = base peripheral > subclass = interrupt controller > none1@pci0:0:20:1: class=0x080000 card=0x00000000 chip=0x34228086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub GPIO and Scratch Pad Registers' > class = base peripheral > subclass = interrupt controller > none2@pci0:0:20:2: class=0x080000 card=0x00000000 chip=0x34238086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub Control Status and RAS Registers' > class = base peripheral > subclass = interrupt controller > none3@pci0:0:20:3: class=0x080000 card=0x00000000 chip=0x34388086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'QuickPath Architecture I/O Hub Throttle Registers' > class = base peripheral > subclass = interrupt controller > none4@pci0:0:22:0: class=0x088000 card=0x000715d9 chip=0x34308086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'DMA Engine' > class = base peripheral > bar [10] = type Memory, range 64, base 0xfbed8000, size 16384, enabled > none5@pci0:0:22:1: class=0x088000 card=0x000715d9 chip=0x34318086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'DMA Engine' > class = base peripheral > bar [10] = type Memory, range 64, base 0xfbedc000, size 16384, enabled > none6@pci0:0:22:2: class=0x088000 card=0x000715d9 chip=0x34328086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'DMA Engine' > class = base peripheral > bar [10] = type Memory, range 64, base 0xfbee0000, size 16384, enabled > none7@pci0:0:22:3: class=0x088000 card=0x000715d9 chip=0x34338086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'DMA Engine' > class = base peripheral > bar [10] = type Memory, range 64, base 0xfbee4000, size 16384, enabled > none8@pci0:0:22:4: class=0x088000 card=0x000715d9 chip=0x34298086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'DMA Engine' > class = base peripheral > bar [10] = type Memory, range 64, base 0xfbee8000, size 16384, enabled > none9@pci0:0:22:5: class=0x088000 card=0x000715d9 chip=0x342a8086 rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'DMA Engine' > class = base peripheral > bar [10] = type Memory, range 64, base 0xfbeec000, size 16384, enabled > none10@pci0:0:22:6: class=0x088000 card=0x000715d9 chip=0x342b8086 > rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'DMA Engine' > class = base peripheral > bar [10] = type Memory, range 64, base 0xfbef0000, size 16384, enabled > none11@pci0:0:22:7: class=0x088000 card=0x000715d9 chip=0x342c8086 > rev=0x22 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'DMA Engine' > class = base peripheral > bar [10] = type Memory, range 64, base 0xfbef4000, size 16384, enabled > none12@pci0:0:26:0: class=0x0c0300 card=0x000715d9 chip=0x3a378086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'USB UHCI Controller *4' > class = serial bus > subclass = USB > none13@pci0:0:26:1: class=0x0c0300 card=0x000715d9 chip=0x3a388086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'USB UHCI Controller *5' > class = serial bus > subclass = USB > none14@pci0:0:26:2: class=0x0c0300 card=0x000715d9 chip=0x3a398086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'USB UHCI Controller *6' > class = serial bus > subclass = USB > none15@pci0:0:26:7: class=0x0c0320 card=0x000715d9 chip=0x3a3c8086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'USB EHCI Controller *2' > class = serial bus > subclass = USB > none16@pci0:0:29:0: class=0x0c0300 card=0x000715d9 chip=0x3a348086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'USB UHCI Controller *1' > class = serial bus > subclass = USB > none17@pci0:0:29:1: class=0x0c0300 card=0x000715d9 chip=0x3a358086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'USB UHCI Controller *2' > class = serial bus > subclass = USB > none18@pci0:0:29:2: class=0x0c0300 card=0x000715d9 chip=0x3a368086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'USB UHCI Controller *3' > class = serial bus > subclass = USB > none19@pci0:0:29:7: class=0x0c0320 card=0x000715d9 chip=0x3a3a8086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'USB EHCI Controller *1' > class = serial bus > subclass = USB > pcib6@pci0:0:30:0: class=0x060401 card=0x000715d9 chip=0x244e8086 rev=0x90 > hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI > Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 card=0x000715d9 chip=0x3a188086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'LPC Interface Controller' > class = bridge > subclass = PCI-ISA > atapci0@pci0:0:31:2: class=0x01018f card=0x000715d9 chip=0x3a208086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'SATA2(4Port2) (ICH10 Family)' > class = mass storage > subclass = ATA > bar [10] = type I/O Port, range 32, base 0xbc00, size 8, enabled > bar [14] = type I/O Port, range 32, base 0xb880, size 4, enabled > bar [18] = type I/O Port, range 32, base 0xb800, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0xb480, size 4, enabled > bar [20] = type I/O Port, range 32, base 0xb400, size 16, enabled > bar [24] = type I/O Port, range 32, base 0xb080, size 16, enabled > none20@pci0:0:31:3: class=0x0c0500 card=0x000715d9 chip=0x3a308086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'SMB controller (50011458)' > class = serial bus > subclass = SMBus > bar [10] = type Memory, range 64, base 0xfbefa000, size 256, enabled > bar [20] = type I/O Port, range 32, base 0x400, size 32, enabled > atapci1@pci0:0:31:5: class=0x010185 card=0x000715d9 chip=0x3a268086 > rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'SATA2(2Port2) (ICH10 Family)' > class = mass storage > subclass = ATA > bar [10] = type I/O Port, range 32, base 0xac00, size 8, enabled > bar [14] = type I/O Port, range 32, base 0xa880, size 4, enabled > bar [18] = type I/O Port, range 32, base 0xa800, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0xa480, size 4, enabled > bar [20] = type I/O Port, range 32, base 0xa400, size 16, enabled > bar [24] = type I/O Port, range 32, base 0xa080, size 16, enabled > em0@pci0:1:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xfbbe0000, size 131072, enabled > bar [18] = type I/O Port, range 32, base 0xcc00, size 32, enabled > bar [1c] = type Memory, range 32, base 0xfbbdc000, size 16384, enabled > em1@pci0:2:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xfbce0000, size 131072, enabled > bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled > bar [1c] = type Memory, range 32, base 0xfbcdc000, size 16384, enabled > mps0@pci0:4:0:0: class=0x010700 card=0x040015d9 chip=0x00721000 rev=0x02 > hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > class = mass storage > subclass = SAS > bar [10] = type I/O Port, range 32, base 0xe000, size 256, enabled > bar [14] = type Memory, range 64, base 0xfbd3c000, size 16384, enabled > bar [1c] = type Memory, range 64, base 0xfbd40000, size 262144, enabled > vgapci0@pci0:6:1:0: class=0x030000 card=0x000715d9 chip=0x0532102b > rev=0x0a > hdr=0x00 > vendor = 'Matrox Electronic Systems Ltd.' > class = display > subclass = VGA > bar [10] = type Prefetchable Memory, range 32, base 0xf9000000, size > 16777216, enabled > bar [14] = type Memory, range 32, base 0xfaffc000, size 16384, enabled > bar [18] = type Memory, range 32, base 0xfb000000, size 8388608, enabled > hostb1@pci0:255:0:0: class=0x060000 card=0x80868086 chip=0x2c708086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb2@pci0:255:0:1: class=0x060000 card=0x80868086 chip=0x2d818086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb3@pci0:255:2:0: class=0x060000 card=0x80868086 chip=0x2d908086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb4@pci0:255:2:1: class=0x060000 card=0x80868086 chip=0x2d918086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb5@pci0:255:2:2: class=0x060000 card=0x80868086 chip=0x2d928086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb6@pci0:255:2:3: class=0x060000 card=0x80868086 chip=0x2d938086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb7@pci0:255:2:4: class=0x060000 card=0x80868086 chip=0x2d948086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb8@pci0:255:2:5: class=0x060000 card=0x80868086 chip=0x2d958086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb9@pci0:255:3:0: class=0x060000 card=0x80868086 chip=0x2d988086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb10@pci0:255:3:1: class=0x060000 card=0x80868086 chip=0x2d998086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb11@pci0:255:3:2: class=0x060000 card=0x80868086 chip=0x2d9a8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb12@pci0:255:3:4: class=0x060000 card=0x80868086 chip=0x2d9c8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb13@pci0:255:4:0: class=0x060000 card=0x80868086 chip=0x2da08086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb14@pci0:255:4:1: class=0x060000 card=0x80868086 chip=0x2da18086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb15@pci0:255:4:2: class=0x060000 card=0x80868086 chip=0x2da28086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb16@pci0:255:4:3: class=0x060000 card=0x80868086 chip=0x2da38086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb17@pci0:255:5:0: class=0x060000 card=0x80868086 chip=0x2da88086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb18@pci0:255:5:1: class=0x060000 card=0x80868086 chip=0x2da98086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb19@pci0:255:5:2: class=0x060000 card=0x80868086 chip=0x2daa8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb20@pci0:255:5:3: class=0x060000 card=0x80868086 chip=0x2dab8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb21@pci0:255:6:0: class=0x060000 card=0x80868086 chip=0x2db08086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb22@pci0:255:6:1: class=0x060000 card=0x80868086 chip=0x2db18086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb23@pci0:255:6:2: class=0x060000 card=0x80868086 chip=0x2db28086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > hostb24@pci0:255:6:3: class=0x060000 card=0x80868086 chip=0x2db38086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > > Thank you in advance sirs! > Jason Wolfe > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 00:03:12 2011 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 311A410656D0 for ; Fri, 7 Oct 2011 00:03:12 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7BBB8FC08 for ; Fri, 7 Oct 2011 00:03:11 +0000 (UTC) Received: by gyf2 with SMTP id 2so4008455gyf.13 for ; Thu, 06 Oct 2011 17:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=xExQGzjzJGs//b/tYwBYYTAfWtMsOxFUlMcwjICzqiM=; b=CCnMkAit24iiIWO4Nf7jsc+NMGkX3s3+NLY2CnRZyZ7StiBFFNeOeGptjOlWrkeeYk HD2VwvV8py6vcG+pIt0vnyOX85DbBvd3dNgMpEVcv1CBsmlpHjymxIK9+l9ThfkqsVFM Dlt5XrW4QnCUwTEhEDr2MuQXgBBrfb2FQw5LU= Received: by 10.236.143.69 with SMTP id k45mr6550330yhj.115.1317945790002; Thu, 06 Oct 2011 17:03:10 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id v4sm10182883yhk.3.2011.10.06.17.03.06 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 17:03:08 -0700 (PDT) From: Chuck Burns To: Gary Palmer Date: Thu, 6 Oct 2011 19:02:15 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <201110052356.41724.break19@gmail.com> <20111006185252.GD38162@in-addr.com> In-Reply-To: <20111006185252.GD38162@in-addr.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110061902.15838.break19@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 07 Oct 2011 00:03:12 -0000 > Do you have a /dev/dumpdev symbolic link pointing to a swap partition? > If not, the dump device may not have been configured. > > Also, apologies if you said this earlier, but which version of FreeBSD > are you running? > > Gary I didn't have that link, but I just linked it to my 6G swap partition (I have 4G of ram) at /dev/ada0p2 - using GPT, and zfs-on-root. I hope the following information is more than enough. :) Latest kernel panic, with all of the info on the screen. http://imageshack.us/photo/my-images/707/newcrashw.png/ My filesystems: zfs list && mount NAME USED AVAIL REFER MOUNTPOINT zroot 72.6G 376G 875M /zroot zroot/tmp 301K 376G 301K /tmp zroot/usr 71.6G 376G 6.99G /usr zroot/usr/home 61.7G 376G 61.7G /usr/home zroot/usr/ports 2.54G 376G 241M /usr/ports zroot/usr/ports/distfiles 2.30G 376G 2.30G /usr/ports/distfiles zroot/usr/ports/packages 3.16M 376G 3.16M /usr/ports/packages zroot/usr/src 314M 376G 314M /usr/src zroot/var 137M 376G 7.95M /var zroot/var/crash 22.5K 376G 22.5K /var/crash zroot/var/db 111M 376G 98.1M /var/db zroot/var/db/pkg 12.8M 376G 12.8M /var/db/pkg zroot/var/empty 21K 376G 21K /var/empty zroot/var/log 175K 376G 175K /var/log zroot/var/mail 30K 376G 30K /var/mail zroot/var/run 87K 376G 87K /var/run zroot/var/tmp 17.9M 376G 17.9M /var/tmp zroot on / (zfs, local, nfsv4acls) devfs on /dev (devfs, local, multilabel) procfs on /proc (procfs, local) zroot/tmp on /tmp (zfs, local, nosuid, nfsv4acls) zroot/usr on /usr (zfs, local, nfsv4acls) zroot/usr/home on /usr/home (zfs, local, nfsv4acls) zroot/usr/ports on /usr/ports (zfs, local, nosuid, nfsv4acls) zroot/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noexec, nosuid, nfsv4acls) zroot/usr/ports/packages on /usr/ports/packages (zfs, local, noexec, nosuid, nfsv4acls) zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) zroot/var on /var (zfs, local, nfsv4acls) zroot/var/crash on /var/crash (zfs, local, noexec, nosuid, nfsv4acls) zroot/var/db on /var/db (zfs, local, noexec, nosuid, nfsv4acls) zroot/var/db/pkg on /var/db/pkg (zfs, local, nosuid, nfsv4acls) zroot/var/empty on /var/empty (zfs, local, noexec, nosuid, read-only, nfsv4acls) zroot/var/log on /var/log (zfs, local, noexec, nosuid, nfsv4acls) zroot/var/mail on /var/mail (zfs, local, noexec, nosuid, nfsv4acls) zroot/var/run on /var/run (zfs, local, noexec, nosuid, nfsv4acls) zroot/var/tmp on /var/tmp (zfs, local, nosuid, nfsv4acls) linprocfs on /usr/compat/linux/proc (linprocfs, local) ----- uname -a: FreeBSD blackbeast.local 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Oct 5 22:17:21 CDT 2011 root@blackbeast.local:/usr/obj/usr/src/sys/BLACKBEAST amd64 my kernel config (as you can see, I tried to enable URTW_DEBUG by placing it into kernel config, but make buildkernel said the option didnt exist, so I instead modified my urtw.c file to include "#define URTW_DEBUG" at the top) # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig- config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.18 2011/09/16 18:41:19 jhb Exp $ cpu HAMMER ident BLACKBEAST # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env "GENERIC.env" makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel options KDB # Kernel debugger related code options KDB_TRACE # Print a stack trace for a panic #options KDB_UNATTENDED # Reboot on panic # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion device mps # LSI-Logic MPT-Fusion 2 #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID #XXX it is not 64-bit clean, -scottl #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da device puc # Multi I/O cards and multi-channel UARTs # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 Gigabit Ethernet Family device igb # Intel PRO/1000 PCIE Server Gigabit Family device ixgbe # Intel PRO/10GbE PCIE Ethernet Family device le # AMD Am7900 LANCE and Am79C9xx PCnet device ti # Alteon Networks Tigon I/II gigabit Ethernet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device ae # Attansic/Atheros L2 FastEthernet device age # Attansic/Atheros L1 Gigabit Ethernet device alc # Atheros AR8131/AR8132 Ethernet device ale # Atheros AR8121/AR8113/AR8114 Ethernet device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device et # Agere ET1310 10/100/Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sge # Silicon Integrated Systems SiS190/191 device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # pci/cardbus chip support options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player # USB Serial devices device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet device udav # Davicom DM9601E USB # USB Wireless device rum # Ralink Technology RT2501USB wireless NICs device uath # Atheros AR5523 wireless NICs device ural # Ralink Technology RT2500USB wireless NICs device zyd # ZyDAS zb1211/zb1211b wireless NICs # FireWire support device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons device urtw # urtw #options URTW_DEBUG # enable debugging for urtw device ahci device sound device snd_hda ----- dmesg output: Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #4: Wed Oct 5 22:17:21 CDT 2011 root@blackbeast.local:/usr/obj/usr/src/sys/BLACKBEAST amd64 module urtw already present! Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) II X2 550 Processor (3833.36-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f43 Family = 10 Model = 4 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4076732416 (3887 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfbf0000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 18 at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xef00-0xef7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 18 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] pcib2: irq 18 at device 10.0 on pci0 pci2: on pcib2 re0: port 0xde00-0xdeff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 18 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX- FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:24:1d:d4:96:90 re0: [ITHREAD] ahci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] hdac0: mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 fwohci0: mem 0xfdeff000-0xfdeff7ff,0xfdef8000-0xfdefbfff irq 22 at device 14.0 on pci3 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:4f:08:f8:00:00:24:1d fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x3b0c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:4f:08:00:24:1d fwe0: Ethernet address: 02:4f:08:00:24:1d fwip0: on firewire0 fwip0: Firewire address: 00:4f:08:f8:00:00:24:1d @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: [ITHREAD] usbus6: on ohci4 acpi_hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x73 on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range hwpstate0: on cpu0 ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ad0: 76319MB at ata0-master UDMA100 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 hdac0: HDA Codec #0: Realtek ALC888 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered ugen1.2: at usbus1 uhid0: on usbus1 ugen5.2: at usbus5 urtw0: on usbus5 urtw0: unknown RTL8187L type: 0x8000000 ugen1.3: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ums0: on usbus1 ums0: 16 buttons and [XYZT] coordinates ID=2 uhid1: on usbus1 urtw0: rtl8187l rf rtl8225u hwrev none ugen4.2: at usbus4 uhub7: on usbus4 uhub7: 4 ports with 2 removable, bus powered ugen4.3: at usbus4 ukbd1: on usbus4 kbd3 at ukbd1 uhid2: on usbus4 ugen4.4: at usbus4 uhid3: on usbus4 ahcich5: Timeout on slot 0 port 0 ahcich5: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 180 serr 00000000 cmd 0000e017 ada0 at ahcich4 bus 0 scbus4 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! cd0 at ahcich5 bus 0 scbus5 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from zfs:zroot wlan0: Ethernet address: 00:1b:2f:92:56:00 wlan0: link state changed to UP ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:6:0:-1: Attached to scbus6 da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 7643MB (15652864 512 byte sectors: 255H 63S/T 974C) GEOM: da0: partition 1 does not start on a track boundary. GEOM: da0: partition 1 does not end on a track boundary. ugen3.2: at usbus3 (disconnected) umass0: at uhub3, port 2, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry linux: pid 2526 (npviewer.bin): syscall inotify_init not implemented ------- From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 00:30:47 2011 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 933F5106566B for ; Fri, 7 Oct 2011 00:30:47 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 658748FC15 for ; Fri, 7 Oct 2011 00:30:47 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RByKs-0004FM-K5; Thu, 06 Oct 2011 20:30:46 -0400 Date: Thu, 6 Oct 2011 20:30:46 -0400 From: Gary Palmer To: Chuck Burns Message-ID: <20111007003046.GE38162@in-addr.com> References: <201110042008.48915.break19@gmail.com> <201110052356.41724.break19@gmail.com> <20111006185252.GD38162@in-addr.com> <201110061902.15838.break19@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110061902.15838.break19@gmail.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 07 Oct 2011 00:30:47 -0000 On Thu, Oct 06, 2011 at 07:02:15PM -0500, Chuck Burns wrote: > > Do you have a /dev/dumpdev symbolic link pointing to a swap partition? > > If not, the dump device may not have been configured. > > > > Also, apologies if you said this earlier, but which version of FreeBSD > > are you running? > > > > Gary > > I didn't have that link, but I just linked it to my 6G swap partition (I have > 4G of ram) at /dev/ada0p2 - using GPT, and zfs-on-root. Actually, that won't be enough. Sorry if I gave that idea. If you check /etc/rc.d/dumpon then you'll see that if the script succeeds in telling the kernel to dump on a given swap partition then it creates the symlink in the /dev directory. I couldn't see any other easy way to check if your kernel had been configured to dump to the swap partition or not. Do you have a dumpdev setting in /etc/rc.conf? Does /etc/fstab list /dev/ada0p2 as a swap partition? Thanks for the configuration info. Gary From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 00:40:35 2011 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 2C7D8106564A for ; Fri, 7 Oct 2011 00:40:35 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id DDFC98FC0C for ; Fri, 7 Oct 2011 00:40:34 +0000 (UTC) Received: by yxk36 with SMTP id 36so4007622yxk.13 for ; Thu, 06 Oct 2011 17:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=8fszG1frYnbLwxSa2iNiRxitE3ibyT8Yi7uOQWSujGw=; b=G0J6nXLpX7Z/weDEocxy3/IOajfk2hkbh7gktvjPFh+kaAvoGzr+Hu0aghqoZsD3cl q/wFqrhWDAAtF3kFV17kSjvymsEJYhJ1VNgsMGyIh0XcJQL8q5KdxOnqHPSf76QA4LZ7 udz28xJpcnCTySVvaYHOC71mXy8UrryrfeyZ4= Received: by 10.236.128.236 with SMTP id f72mr6948018yhi.13.1317948034188; Thu, 06 Oct 2011 17:40:34 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id n67sm10310207yhi.9.2011.10.06.17.40.33 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 17:40:33 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Thu, 6 Oct 2011 19:39:42 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <201110061902.15838.break19@gmail.com> <20111007003046.GE38162@in-addr.com> In-Reply-To: <20111007003046.GE38162@in-addr.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110061939.42854.break19@gmail.com> Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 07 Oct 2011 00:40:35 -0000 On Thursday, October 06, 2011 7:30:46 PM Gary Palmer wrote: > Actually, that won't be enough. Sorry if I gave that idea. If you check > /etc/rc.d/dumpon then you'll see that if the script succeeds in telling > the kernel to dump on a given swap partition then it creates the > symlink in the /dev directory. I couldn't see any other easy way to > check if your kernel had been configured to dump to the swap partition or > not. > > Do you have a dumpdev setting in /etc/rc.conf? Does /etc/fstab list > /dev/ada0p2 as a swap partition? > > Thanks for the configuration info. > > Gary Just added the dumpdev line, here is my rc.conf # cat /etc/rc.conf sshd_enable="YES" wlans_urtw0="wlan0" ifconfig_wlan0="WPA DHCP" zfs_enable="YES" hostname="blackbeast.local" linux_enable="YES" powerd_enable='YES' dbus_enable="YES" hald_enable="YES" avahi_daemon_enable="YES" avahi_dnsconfd_enable="YES" mdnsd_enable="YES" kdm4_enable="YES" local_startup="/usr/local/kde4/etc/rc.d /usr/local/etc/rc.d" devfs_system_ruleset="system" quasselcore_enable="YES" font8x8="iso-8x8" allscreens_flags="VGA_80x60" dumpdev="/dev/ada0p2" and here is my fstab (I disabled geli several reboots/crashes ago, thinking that may be what was preventing the crash dumps, as well as changed the swap line to point directly to the partition, rather than the gpt label) # cat /etc/fstab /dev/ada0p2 none swap sw 0 0 #/dev/gpt/swap0.eli none swap sw 0 0 proc /proc procfs rw 0 0 linproc /compat/linux/proc linprocfs rw,late 0 0 From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 01:12:38 2011 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 6DBAE106564A; Fri, 7 Oct 2011 01:12:38 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B642A8FC08; Fri, 7 Oct 2011 01:12:37 +0000 (UTC) Received: by vcbf13 with SMTP id f13so3879365vcb.13 for ; Thu, 06 Oct 2011 18:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4hXn8v5lEBADsBNYiWgRZmkTl+ShK0zrMoxepMpR9zs=; b=LsoiAKW2GPeaaaWeI38YTc59eYbBPNnaj9u1Ih1A9guFBsXUA6g6LP9C9Z7VxL4u87 7M4GzFHyrvFbwvE214w35TiHyfNZmXhXqAMDDU1jFma93XmePhQoFBgfN2xOhYfa40qr SzKkRchroOKpYOSh0M8i1Q9xcvq5172NLD2KQ= MIME-Version: 1.0 Received: by 10.52.31.41 with SMTP id x9mr449285vdh.42.1317949956922; Thu, 06 Oct 2011 18:12:36 -0700 (PDT) Received: by 10.52.184.135 with HTTP; Thu, 6 Oct 2011 18:12:36 -0700 (PDT) In-Reply-To: <86y5x0ooik.fsf@in138.ua3> References: <8662kcigif.fsf@kopusha.home.net> <86y5x0ooik.fsf@in138.ua3> Date: Fri, 7 Oct 2011 09:12:36 +0800 Message-ID: From: dave jones To: Mikolaj Golub Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Robert Watson , "K. Macy" , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 07 Oct 2011 01:12:38 -0000 2011/10/4 Mikolaj Golub : > > On Sat, 1 Oct 2011 14:15:45 +0800 dave jones wrote: > > =A0dj> On Fri, Sep 30, 2011 at 9:41 PM, Robert Watson wrote: > =A0>> > =A0>> On Wed, 28 Sep 2011, Mikolaj Golub wrote: > =A0>> > =A0>>> On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: > =A0>>> > =A0>>> KM> Sorry, didn't look at the images (limited bw), I've seen somet= hing KM> > =A0>>> like this before in timewait. This "can't happen" with UDP so will= be KM> > =A0>>> interested in learning more about the bug. > =A0>>> > =A0>>> The panic can be easily triggered by this: > =A0>> > =A0>> Hi: > =A0>> > =A0>> Just catching up on this thread. =A0I think the analysis here is ge= nerally > =A0>> right: in 9.0, you're much more likely to see an inpcb with its in_= socket > =A0>> pointer cleared in the hash list than in prior releases, and > =A0>> in_pcbbind_setup() trips over this. > =A0>> > =A0>> However, at least on first glance (and from the perspective of inva= riants > =A0>> here), I think the bug is actualy that in_pcbbind_setup() is asking > =A0>> in_pcblookup_local() for an inpcb and then access the returned inpc= b's > =A0>> in_socket pointer without acquiring a lock on the inpcb. =A0Structu= rally, it > =A0>> can't acquire this lock for lock order reasons -- it already holds = the lock > =A0>> on its own inpcb. =A0Therefore, we should only access fields that a= re safe to > =A0>> follow in an inpcb when you hold a reference via the hash lock and = not a > =A0>> lock on the inpcb itself, which appears generally OK (+/-) for all = the > =A0>> fields in that clause but the t->inp_socket->so_options dereference= . > =A0>> > =A0>> A preferred fix would cache the SO_REUSEPORT flag in an inpcb-layer= field, > =A0>> such as inp_flags2, giving us access to its value without having to= walk > =A0>> into the attached (or not) socket. > =A0>> > =A0>> This raises another structural question, which is whether we need a= new > =A0>> inp_foo flags field that is protected explicitly by the hash lock, = and not > =A0>> by the inpcb lock, which could hold fields relevant to address bind= ing. =A0I > =A0>> don't think we need to solve that problem in this context, as a sli= ghtly > =A0>> race on SO_REUSEPORT is likely acceptable. > =A0>> > =A0>> The suggested fix does perform the desired function of explicitly d= etaching > =A0>> the inpcb from the hash list before the socket is disconnected from= the > =A0>> inpcb. However, it's incomplete in that the invariant that's being = broken is > =A0>> also relied on for other protocols (such as raw sockets). =A0The co= rrect > =A0>> invariant is that inp_socket is safe to follow unconditionally if a= n inpcb > =A0>> is locked and INP_DROPPED isn't set -- the bug is in "locked" not i= n > =A0>> "INP_DROPPED", which is why I think this is the wrong fix, even tho= ugh it > =A0>> prevents a panic :-). > > =A0dj> Hello Robert, > > =A0dj> Thank you for taking your valuable time to find out the problem. > =A0dj> Since I don't have idea about network internals, would you have a = patch > =A0dj> about this? I'd be glad to test it, thanks again. > > Here is the patch that implements what Robert suggests. > > Dave, could you test it? Sure. Thanks for cooking the patch. Machines have been running two days now without panic. > -- > Mikolaj Golub Best regards, Dave. From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 01:57:44 2011 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 48CC71065672; Fri, 7 Oct 2011 01:57:44 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 2D09F8FC08; Fri, 7 Oct 2011 01:57:43 +0000 (UTC) Received: from [127.0.0.1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p971vVV1053090; Thu, 6 Oct 2011 18:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1317952652; bh=w/p1eFrsF4CVpvFUx5eWXeYrVAUNL0ZbXQtWWDWULc0=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=DyZoRAfPZvHH3EYn7k89TmcItOE3vnKjo0oQOGJRD4vC3H+JvWtjDs/RpA1pAhOKk 44qEy1Eg5grzsIohNSodDrklBVXMjDyG5Rxt7+sCT/o1xiqkDTgXtIb/H9Scbe0mbf YD66W3XXx76xnf+6hSawHY8LIjhLKnhrv8A/nyfo= From: Sean Bruno To: "freebsd-net@freebsd.org" In-Reply-To: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 06 Oct 2011 18:57:31 -0700 Message-ID: <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: David Christensen , Pyun YongHyeon Subject: Re: bce(4) with IPMI [puzzling and puzzling] 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, 07 Oct 2011 01:57:44 -0000 On Thu, 2011-09-29 at 10:01 -0700, Sean Bruno wrote: > We've been getting reports of odd behavior on our Dell R410 machines > when trying to use IPMI. The servers have two NIC's that we have > assigned as the IPMI interface(bce0) and production interface(bce1) > respectively. > > Since we don't actually configure bce0 in FreeBSD, we've found that the > IPMI interface deactivated when bce(4) loads. I assume that the driver > is not initializing the interface correctly in this case and the default > case is to turn the interface off. Does it make sense to completely > turn off the interface when there is an active link on the port, but no > configuration assigned? > > Sean > > p.s. Dell's IPMI implementation is ... um ... more difficult than it > needs to be. Whoa ... ok, so now I've run into something horrible. According to dmidecode, a Dell R410 has a Broadcom 5716 chipset on it. On Board Device 2 Information Type: Ethernet Status: Enabled Description: Embedded Broadcom 5716 NIC 1 On Board Device 3 Information Type: Ethernet Status: Enabled Description: Embedded Broadcom 5716 NIC 2 However, when I ask the chipset what type it is via: if_bcereg.h:#define BCE_CHIP_NUM(sc) It clearly indicates that it is a 5709???? What on earth is going on here? The following patch, yeilds the following output: === //depot/yahoo/ybsd_7/src/sys/dev/bce/if_bce.c#26 - /home/seanbru/ybsd_7/sys/dev/bce/if_bce.c ==== 5855c5855,5861 < if ((ifp->if_flags & IFF_UP) == 0) { --- > if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716) > printf("%s: BCE_CHIP_NUM_5716 found\n", __func__); > else > printf("%s: huh, what's this? 0x%8x\n", __func__, BCE_CHIP_NUM(sc)); > > if (((ifp->if_flags & IFF_UP) == 0) && > !(BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { bce_ifmedia_sts: huh, what's this? 0x57090000 bce0@pci0:1:0:0: class=0x020000 card=0x028c1028 chip=0x163b14e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet bce1@pci0:1:0:1: class=0x020000 card=0x028c1028 chip=0x163b14e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet bce0: mem 0xd8000000-0xd9ffffff irq 36 at device 0.0 on pci1 bce0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xd8000000 bce0: attempting to allocate 1 MSI vectors (16 supported) bce0: using IRQ 256 for MSI miibus0: on bce0 bce0: bpf attached bce0: Ethernet address: a4:ba:db:2b:6d:58 bce0: [MPSAFE] bce0: [ITHREAD] bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); Flags (MSI|MFW); MFW (NCSI 2.0.8) From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 02:34:59 2011 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 9BDF7106566C for ; Fri, 7 Oct 2011 02:34:59 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFF68FC0A for ; Fri, 7 Oct 2011 02:34:59 +0000 (UTC) Received: by vcbf13 with SMTP id f13so3924162vcb.13 for ; Thu, 06 Oct 2011 19:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=c2C8WvdsfB1M81o8RAm7i2cH7Tb25uynFqEfhJuiSa4=; b=VXTaD670y/bBaf1lO9z5s0oO5AjP9qKYVxoT+UvwkpsQIQWEQFtgXjEtwzf801MMOw sJjtHKq3e68WP49mYMcuSbe94JtZz09Et4btvFVIkOG113JmndQSVMzMPMxVLS/LG7s8 iT9XLfjXN9d5419c8urfPXrF1qWIYqOwul3Jo= MIME-Version: 1.0 Received: by 10.52.91.11 with SMTP id ca11mr640805vdb.8.1317954898517; Thu, 06 Oct 2011 19:34:58 -0700 (PDT) Received: by 10.52.184.135 with HTTP; Thu, 6 Oct 2011 19:34:58 -0700 (PDT) Date: Fri, 7 Oct 2011 10:34:58 +0800 Message-ID: From: dave jones To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Question about GPIO bitbang MII 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, 07 Oct 2011 02:34:59 -0000 Hi, Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using gpio-bitbang mii that I can refer to? Thanks. It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, and it's useful for porting embedded devices. Best regards, Dave. From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 08:19:09 2011 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 E4BDB106566B for ; Fri, 7 Oct 2011 08:19:08 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7438FC08 for ; Fri, 7 Oct 2011 08:19:08 +0000 (UTC) Received: from [192.168.99.1] (helo=terran.dlink.ua) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1RC5Kj-0005O0-Jl; Fri, 07 Oct 2011 10:59:05 +0300 Date: Fri, 7 Oct 2011 11:00:28 +0300 From: Aleksandr Rybalko To: dave jones Message-Id: <20111007110028.bae63f84.ray@dlink.ua> In-Reply-To: References: Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Question about GPIO bitbang MII 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, 07 Oct 2011 08:19:09 -0000 On Fri, 7 Oct 2011 10:34:58 +0800 dave jones wrote: >> Hi, >> >> Does FreeBSD have gpio bitbang api for MII? If not, any driver in >> tree using gpio-bitbang mii that I can refer to? Thanks. >> It seems like OpenBSD, NetBSD and Linux have added support to gpio >> bitbang mii, and it's useful for porting embedded devices. >> >> Best regards, >> Dave. Hi Dave, you can try my script for now :) (Attached as text) then we will do something with that problem. I'm not sure that script works fine, because i was use it for detect is attached device MDIO controlled or I2C. BTW, which device use MDIO attached to GPIO? And this is PHY or switch, if second take a look on http://zrouter.org/hg/FreeBSD/head/file/03dd18c85162/head/sys/dev/switch ######################### bitbanged MDIO #!/bin/sh mdc="x" mdio="x" lmdc="x" lmdio="x" phy=$1 reg=$2 DATA=7 CLOCK=6 out=0; append() { local c=$1 local d=$2 if [ ${c} = "X" ]; then c=${lmdc}; fi if [ ${d} = "X" ]; then d=${lmdio}; fi mdc="${mdc}${c}" mdio="${mdio}${d}" lmdc="${c}" lmdio="${d}" } alias gp='gpioctl -q -f /dev/gpioc0' alias d0='gp ${DATA} 0 > /dev/null; append X _' alias d1='gp ${DATA} 1 > /dev/null; append X T' alias c0='gp ${CLOCK} 0 > /dev/null; append _ X' alias c1='gp ${CLOCK} 1 > /dev/null; append T X' alias dIN='gp -c ${DATA} IN > /dev/null; append X "<"' alias dOUT='gp -c ${DATA} OUT > /dev/null; append X ">"' alias cIN='gp -c ${CLOCK} IN > /dev/null; append ">" X' alias cOUT='gp -c ${CLOCK} OUT > /dev/null; append ">" X' alias dget='gp -g ${DATA}' #SMI send 1 SMI_1() { d1; c1; c0; } #SMI send 0 SMI_0() { d0; c1; c0; } ReadMSIO() { local phyad=$1; local regad=$2; i=0 while true; do SMI_1; i=$(( ${i} + 1)) if [ ${i} -gt 31 ]; then break fi done # 01 # send start SMI_0; SMI_1; # 10 # opcode SMI_1; SMI_0; i=0x10 while true; do if [ $(( ${phyad} & ${i} )) = 0 ]; then SMI_0; else SMI_1; fi i=$(( ${i} >> 1 )) if [ ${i} = 0 ]; then break fi done i=0x10 while true; do if [ $(( ${regad} & ${i} )) = 0 ]; then SMI_0; else SMI_1; fi i=$(( ${i} >> 1 )) if [ ${i} = 0 ]; then break fi done # #10 # send turn around SMI_1; SMI_0; i=15 out=0 dIN; while true; do c1; dinput=`gp -q -g ${DATA}`; append X ${dinput} append X '<' c0; out=$(( ${out} | (${dinput} << ${i}) )) if [ ${i} = 0 ]; then break fi i=$(( ${i} - 1 )) done dOUT; } dump() { echo echo echo " mdc pin${CLOCK} ${mdc}" echo "mdio pin${DATA} ${mdio}" echo echo echo echo } cOUT; c0; dOUT; d0; out=0 ReadMDIO ${phy} ${reg} printf "P=0x%02x R=0x%02x: 0x%04x\n" ${phy} ${reg} ${out} dIN; cIN; dump ######################### END bitbanged MDIO >> _______________________________________________ >> 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" WBW -- Alexandr Rybalko aka Alex RAY From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 09:24:41 2011 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 677CA106566C for ; Fri, 7 Oct 2011 09:24:41 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0908FC17 for ; Fri, 7 Oct 2011 09:24:39 +0000 (UTC) Received: by vws11 with SMTP id 11so4182713vws.13 for ; Fri, 07 Oct 2011 02:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=neMBln+dpQMbjqFmUAdBDJTvCMNwTWCAAA+1Fwpi3M0=; b=KSOWU4oU970TXnYb41uRcxCTlSSxWB5CK3ro/GkKZuHGXjlRsBfmzlUfYOJiq1C+w9 07gHzp3ZXRkGIDJHxJ/i54zTU93Li6CXQameKaeG1LvYW/c6uJuH1VzcivbBvOt2UL00 X8rmTuD1CxjF2dPq3/0FjL2imrOjuz/4d9pxI= MIME-Version: 1.0 Received: by 10.52.23.106 with SMTP id l10mr1692386vdf.127.1317979479140; Fri, 07 Oct 2011 02:24:39 -0700 (PDT) Received: by 10.52.184.135 with HTTP; Fri, 7 Oct 2011 02:24:39 -0700 (PDT) In-Reply-To: <20111007110028.bae63f84.ray@dlink.ua> References: <20111007110028.bae63f84.ray@dlink.ua> Date: Fri, 7 Oct 2011 17:24:39 +0800 Message-ID: From: dave jones To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Question about GPIO bitbang MII 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, 07 Oct 2011 09:24:41 -0000 On Fri, Oct 7, 2011 at 4:00 PM, Aleksandr Rybalko wrote: > On Fri, 7 Oct 2011 10:34:58 +0800 > dave jones wrote: > >>> Hi, >>> >>> Does FreeBSD have gpio bitbang api for MII? If not, any driver in >>> tree using gpio-bitbang mii that I can refer to? Thanks. >>> It seems like OpenBSD, NetBSD and Linux have added support to gpio >>> bitbang mii, and it's useful for porting embedded devices. >>> >>> Best regards, >>> Dave. > > Hi Dave, Hi, Alex, > you can try my script for now :) (Attached as text) > then we will do something with that problem. > I'm not sure that script works fine, because i was use it for detect is > attached device MDIO controlled or I2C. > > BTW, which device use MDIO attached to GPIO? Thanks for the script. Mine is pxa255 with SMSC LAN91C110. Since I have trouble mounting filesystem via NFS, I can't run your script. > And this is PHY or switch, if second take a look on > http://zrouter.org/hg/FreeBSD/head/file/03dd18c85162/head/sys/dev/switch This is PHY. > WBW > -- > Alexandr Rybalko > aka Alex RAY Best regards, Dave. From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 09:58:33 2011 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 5AF741065670 for ; Fri, 7 Oct 2011 09:58:33 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E77BC8FC13 for ; Fri, 7 Oct 2011 09:58:32 +0000 (UTC) Received: by wwe3 with SMTP id 3so5293627wwe.31 for ; Fri, 07 Oct 2011 02:58:31 -0700 (PDT) Received: by 10.227.129.5 with SMTP id m5mr2261172wbs.67.1317980088065; Fri, 07 Oct 2011 02:34:48 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.199.140 with HTTP; Fri, 7 Oct 2011 02:34:28 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Fri, 7 Oct 2011 02:34:28 -0700 X-Google-Sender-Auth: _wW4PfxXChyd3KAmZEpI5AqHMIE Message-ID: To: dave jones Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: Question about GPIO bitbang MII 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, 07 Oct 2011 09:58:33 -0000 On Thu, Oct 6, 2011 at 19:34, dave jones wrote: > Hi, > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > gpio-bitbang mii that I can refer to? Thanks. > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > and it's useful for porting embedded devices. FreeBSD has a GPIO API and MACs can use whatever mechanism they like to attach MII (or similar, as in the case of devices like switches that sort of use MDIO but aren't exactly like Ethernet PHYs on an MII bus.) Or do you not want to do this within a driver for a particular MAC, but just make the MII bus available for poking and prodding to userland, backed by GPIO? Can you give an example of an OpenBSD driver that uses the API you're talking about? I've worked with some drivers for FreeBSD which have used GPIO bit-banging to expose an MII bus, but adding the abstraction of the GPIO layer hasn't typically been worthwhile for those as they're an SoC with dedicated GPIO for networking devices or similar. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 15:06:51 2011 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 D8F1F1065674 for ; Fri, 7 Oct 2011 15:06:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 88DD88FC14 for ; Fri, 7 Oct 2011 15:06:51 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id p97F6kIJ009463; Fri, 7 Oct 2011 11:06:46 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E8F157A.40702@sentex.net> Date: Fri, 07 Oct 2011 11:06:34 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jason Wolfe References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 15:06:51 -0000 On 10/6/2011 7:15 PM, Jason Wolfe wrote: > I'm seeing the interface wedge on a good number of systems with Intel 82574L > chips under FBSD8.2 _only when MSI-X is enabled_, running either 7.1.9 from > 8.2-RELEASE or 7.2.3 from 8.2-STABLE. I have em0 and em1 in a lagg, but > only one side would fail, and a few systems that didn't have a lagg also saw > the issue. Higher traffic did seem to increase the likely hood of it > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 Hi, This sure sounds like the issue I was seeing with the 7.1.9 driver... However, it has been fixed for me by going to 7.2.3, which is in RELENG_8. Is it possible you have a couple of issues going on since you are using lagg as well ? Another problem some folks have reported is that in the BIOS, if you have an option for ASPM, make sure its disabled. Google around for ASPM and 82574L for a discussion about it. If I recall correctly, disabling MSI-X just reduces the chance of the problem happening, but its been a while since I ran into this issue. But for sure you want to be running 7.2.3 from stable This server used to see this issue dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0x34ec class=0x020000 dev.em.1.%parent: pci11 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.flow_control: 3 dev.em.1.eee_control: 0 dev.em.1.link_irq: 0 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1209008712 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 754 dev.em.1.queue0.txd_tail: 754 dev.em.1.queue0.tx_irq: 251430977 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 304 dev.em.1.queue0.rxd_tail: 303 dev.em.1.queue0.rx_irq: 295670362 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 0 dev.em.1.mac_stats.recv_no_buff: 0 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 712410384 dev.em.1.mac_stats.good_pkts_recvd: 712410384 dev.em.1.mac_stats.bcast_pkts_recvd: 52263 dev.em.1.mac_stats.mcast_pkts_recvd: 24921 dev.em.1.mac_stats.rx_frames_64: 170050 dev.em.1.mac_stats.rx_frames_65_127: 32571360 dev.em.1.mac_stats.rx_frames_128_255: 19796510 dev.em.1.mac_stats.rx_frames_256_511: 6283830 dev.em.1.mac_stats.rx_frames_512_1023: 7922330 dev.em.1.mac_stats.rx_frames_1024_1522: 645666304 dev.em.1.mac_stats.good_octets_recvd: 988128549661 dev.em.1.mac_stats.good_octets_txd: 48849605092 dev.em.1.mac_stats.total_pkts_txd: 501680484 dev.em.1.mac_stats.good_pkts_txd: 501680484 dev.em.1.mac_stats.bcast_pkts_txd: 4266 dev.em.1.mac_stats.mcast_pkts_txd: 8 dev.em.1.mac_stats.tx_frames_64: 134256137 dev.em.1.mac_stats.tx_frames_65_127: 291152180 dev.em.1.mac_stats.tx_frames_128_255: 67219002 dev.em.1.mac_stats.tx_frames_256_511: 5935140 dev.em.1.mac_stats.tx_frames_512_1023: 812920 dev.em.1.mac_stats.tx_frames_1024_1522: 2305105 dev.em.1.mac_stats.tso_txd: 366978 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 2 dev.em.1.interrupts.rx_pkt_timer: 0 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 0 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 0 interrupt total rate irq4: uart0 44896 0 irq16: bge0 19753077 32 irq18: arcmsr0 37518694 62 irq19: twa0 556664 0 irq21: ehci0 2149928 3 irq23: ehci1 1209435 2 cpu0: timer 1209274084 2000 irq256: siis0 65793731 108 irq257: em0 504313285 834 irq258: em1:rx 0 295681170 489 irq259: em1:tx 0 251430780 415 irq261: ahci0 71285304 117 cpu1: timer 1209264969 2000 cpu3: timer 1209266038 2000 cpu2: timer 1209265460 2000 Total 6086807515 10067 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xb4100000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled bar [1c] = type Memory, range 32, base 0xb4120000, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffffed68a4 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 15:56:36 2011 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 6541B106564A for ; Fri, 7 Oct 2011 15:56:36 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0013C8FC08 for ; Fri, 7 Oct 2011 15:56:35 +0000 (UTC) Received: by wwe3 with SMTP id 3so5792641wwe.31 for ; Fri, 07 Oct 2011 08:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=rAzegvysnLAfgapRxNTst7wyGIWbfH8lZFv2e2y59Xk=; b=cSgBot4FIG0C2O9cLpYMKgGaChVc0a98WkaTZkxv3Ia//y5iFYc7NmcWGGQVbE5s5X szNsYVhuaURyUZPYWSYHC/FkpTlrg1gyO58KK9PrW7huhYEyQSr+uGUiBHE0CNKiifxu pFMFemJ31OQq5BjFZYq/+4pf3mKqaGarThl1o= MIME-Version: 1.0 Received: by 10.216.132.210 with SMTP id o60mr959148wei.92.1318002883619; Fri, 07 Oct 2011 08:54:43 -0700 (PDT) Received: by 10.180.96.104 with HTTP; Fri, 7 Oct 2011 08:54:43 -0700 (PDT) Date: Fri, 7 Oct 2011 11:54:43 -0400 Message-ID: From: Ryan Stone To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: [PATCH] Don't have ICMP Echo Replies copy fragmentation flags from Echo Request 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, 07 Oct 2011 15:56:36 -0000 Currently when FreeBSD responds to a ICMP Echo Request, it takes the original mbuf, rewrites a couple of fields (like the src/dst IP and the ICMP type), and then sends that mbuf back. As things are currently implemented, the Don't Fragment bit is kept in the ICMP replay. This can cause problems for large ICMP Echo Requests if the MTU on the return route is less than the MTU on the incoming route and the DF bit is set(Linux's ping command sets it by default). Is it intended that the DF bit from the Request be copied into the Reply? If not, this patch fixes the issue for me: --- ip_icmp.c 2011-10-06 14:54:14.000000000 -0400 +++ ip_icmp.c 2011-10-06 15:12:27.000000000 -0400 @@ -767,6 +767,7 @@ #endif ip->ip_src = t; ip->ip_ttl = V_ip_defttl; + ip->ip_off = 0; if (optlen > 0) { register u_char *cp; From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 16:24:04 2011 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 92C77106564A; Fri, 7 Oct 2011 16:24:04 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 4C59A8FC08; Fri, 7 Oct 2011 16:24:04 +0000 (UTC) Received: from [127.0.0.1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p97GNVcb087935; Fri, 7 Oct 2011 09:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318004611; bh=evlZJNRc55UDfmnVvPYzj3C0iBQqJTF34aHLp2YqQwY=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=n8U9u+Y2Dqlw0JVw3LP81nHIRAyI+36E6M9xKKti4lSWnKW8upbLQUVTKM/6usHNf KHrOEWMugO5mtNKENuhjgThAOYpt0KGdR2Z541VhobvblQug1n+tEpyECcPqSeiFP/ kjdrYKE193XsJR1qnUZocnRlhG3r69C+z2SL8ICo= From: Sean Bruno To: "freebsd-net@freebsd.org" In-Reply-To: <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 Oct 2011 09:23:30 -0700 Message-ID: <1318004610.27029.1.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: David Christensen , Pyun YongHyeon Subject: Re: bce(4) with IPMI [puzzling and puzzling] 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, 07 Oct 2011 16:24:04 -0000 > > bce0@pci0:1:0:0: class=0x020000 card=0x028c1028 chip=0x163b14e4 > rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet > bce1@pci0:1:0:1: class=0x020000 card=0x028c1028 chip=0x163b14e4 > rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet > > > > > bce0: mem > 0xd8000000-0xd9ffffff irq 36 at device 0.0 on pci1 > bce0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xd8000000 > bce0: attempting to allocate 1 MSI vectors (16 supported) > bce0: using IRQ 256 for MSI > miibus0: on bce0 > bce0: bpf attached > bce0: Ethernet address: a4:ba:db:2b:6d:58 > bce0: [MPSAFE] > bce0: [ITHREAD] > bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); > Flags (MSI|MFW); MFW (NCSI 2.0.8) > > > _______________________________________________ so, I cracked open my R410 this morning to see what the Ethernet chipset had for a indentification mark. It is definitely stamped as a BCM5716, so I'm confused. bce(4) has code to handle the 5716 chipset, but its never being executed AFAIK. What's going on here? Sean From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 17:02:25 2011 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 E0019106564A for ; Fri, 7 Oct 2011 17:02:25 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id A36BB8FC13 for ; Fri, 7 Oct 2011 17:02:25 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id p97H2LL8036122; Fri, 7 Oct 2011 13:02:22 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E8F3091.6040106@sentex.net> Date: Fri, 07 Oct 2011 13:02:09 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ryan Stone References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net Subject: Re: [PATCH] Don't have ICMP Echo Replies copy fragmentation flags from Echo Request 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, 07 Oct 2011 17:02:26 -0000 On 10/7/2011 11:54 AM, Ryan Stone wrote: > Currently when FreeBSD responds to a ICMP Echo Request, it takes the > original mbuf, rewrites a couple of fields (like the src/dst IP and > the ICMP type), and then sends that mbuf back. As things are > currently implemented, the Don't Fragment bit is kept in the ICMP > replay. This can cause problems for large ICMP Echo Requests if the > MTU on the return route is less than the MTU on the incoming route and > the DF bit is set(Linux's ping command sets it by default). Not sure, but would this not be a "good thing" in some cases ? Having ping behave in this manner would help you discover such PMTU issues no ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 17:09:16 2011 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 9A764106564A for ; Fri, 7 Oct 2011 17:09:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 014A18FC12 for ; Fri, 7 Oct 2011 17:09:15 +0000 (UTC) Received: (qmail 98385 invoked from network); 7 Oct 2011 15:24:45 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Oct 2011 15:24:45 -0000 Message-ID: <4E8F2BFA.7020002@freebsd.org> Date: Fri, 07 Oct 2011 18:42:34 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ryan Stone References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: [PATCH] Don't have ICMP Echo Replies copy fragmentation flags from Echo Request 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, 07 Oct 2011 17:09:16 -0000 On 07.10.2011 17:54, Ryan Stone wrote: > Currently when FreeBSD responds to a ICMP Echo Request, it takes the > original mbuf, rewrites a couple of fields (like the src/dst IP and > the ICMP type), and then sends that mbuf back. As things are > currently implemented, the Don't Fragment bit is kept in the ICMP > replay. This can cause problems for large ICMP Echo Requests if the > MTU on the return route is less than the MTU on the incoming route and > the DF bit is set(Linux's ping command sets it by default). Is it > intended that the DF bit from the Request be copied into the Reply? Yes, this is intended. It allows you to test asymmetric paths. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 17:53:39 2011 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 BD4B2106564A; Fri, 7 Oct 2011 17:53:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 248EC8FC18; Fri, 7 Oct 2011 17:53:38 +0000 (UTC) Received: by wwe3 with SMTP id 3so5948589wwe.31 for ; Fri, 07 Oct 2011 10:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=E01PblROk2NFr7O+cw6Ez/WxfxVKMyFlw8+uS7F663M=; b=EjOIyP1ENaWmzqsATqlCF/FpCpqbhgVr4Sl0u1lZIHRUo4AatJBGF5IkvZoaNVjIFc 4rjZ/ETbuzzprQgc0w0Uwwb+taFCWtMx4g5XQg+GB9VDU5aE+vY0FuwtIvr43FUySXWt OLTwnRZIQW7kXpiGoa7ettNRHCOOz2DqHY9/Y= Received: by 10.216.136.3 with SMTP id v3mr1171967wei.39.1318010018078; Fri, 07 Oct 2011 10:53:38 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id fy13sm17299165wbb.18.2011.10.07.10.53.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 10:53:36 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Oct 2011 10:51:37 -0700 From: YongHyeon PYUN Date: Fri, 7 Oct 2011 10:51:37 -0700 To: Sean Bruno Message-ID: <20111007175137.GA11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> <1318004610.27029.1.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1318004610.27029.1.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , Pyun YongHyeon Subject: Re: bce(4) with IPMI [puzzling and puzzling] 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: Fri, 07 Oct 2011 17:53:39 -0000 On Fri, Oct 07, 2011 at 09:23:30AM -0700, Sean Bruno wrote: > > > > > bce0@pci0:1:0:0: class=0x020000 card=0x028c1028 chip=0x163b14e4 > > rev=0x20 hdr=0x00 > > vendor = 'Broadcom Corporation' > > class = network > > subclass = ethernet > > bce1@pci0:1:0:1: class=0x020000 card=0x028c1028 chip=0x163b14e4 > > rev=0x20 hdr=0x00 > > vendor = 'Broadcom Corporation' > > class = network > > subclass = ethernet > > > > > > > > > > bce0: mem > > 0xd8000000-0xd9ffffff irq 36 at device 0.0 on pci1 > > bce0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xd8000000 > > bce0: attempting to allocate 1 MSI vectors (16 supported) > > bce0: using IRQ 256 for MSI > > miibus0: on bce0 > > bce0: bpf attached > > bce0: Ethernet address: a4:ba:db:2b:6d:58 > > bce0: [MPSAFE] > > bce0: [ITHREAD] > > bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); > > Flags (MSI|MFW); MFW (NCSI 2.0.8) > > > > > > _______________________________________________ > > so, I cracked open my R410 this morning to see what the Ethernet chipset > had for a indentification mark. It is definitely stamped as a BCM5716, > so I'm confused. > > bce(4) has code to handle the 5716 chipset, but its never being executed > AFAIK. What's going on here? > I guess BCE_CHIP_NUM() returns 0x5709 for 5709 and 5716 controllers. I don't know why bce(4) explicitly checks 5716 from the BCE_MISC_ID register. Public data sheet indicates CHIP_NUM bits have 0x5909 for 5716(NetXtremeII-PG203-R pp229). To me 5716 is virtually the same as 5709 except for not supporting TOE and iSCSI offloading. > Sean > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 18:10:05 2011 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 23251106566B for ; Fri, 7 Oct 2011 18:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 130688FC12 for ; Fri, 7 Oct 2011 18:10:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p97IA4op000570 for ; Fri, 7 Oct 2011 18:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p97IA4RI000569; Fri, 7 Oct 2011 18:10:04 GMT (envelope-from gnats) Date: Fri, 7 Oct 2011 18:10:04 GMT Message-Id: <201110071810.p97IA4RI000569@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159601: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 18:10:05 -0000 The following reply was made to PR kern/159601; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159601: commit references a PR Date: Fri, 7 Oct 2011 18:01:51 +0000 (UTC) Author: qingli Date: Fri Oct 7 18:01:34 2011 New Revision: 226114 URL: http://svn.freebsd.org/changeset/base/226114 Log: Remove the reference held on the loopback route when the interface address is being deleted. Only the last reference holder deletes the loopback route. All other delete operations just clear the IFA_RTSELF flag. PR: kern/159601 Submitted by: pluknet Reviewed by: discussed on net@ MFC after: 3 days Modified: head/sys/netinet/in.c Modified: head/sys/netinet/in.c ============================================================================== --- head/sys/netinet/in.c Fri Oct 7 16:39:03 2011 (r226113) +++ head/sys/netinet/in.c Fri Oct 7 18:01:34 2011 (r226114) @@ -1126,8 +1126,10 @@ in_scrubprefix(struct in_ifaddr *target, RT_LOCK(ia_ro.ro_rt); if (ia_ro.ro_rt->rt_refcnt <= 1) freeit = 1; - else + else if (flags & LLE_STATIC) { RT_REMREF(ia_ro.ro_rt); + target->ia_flags &= ~IFA_RTSELF; + } RTFREE_LOCKED(ia_ro.ro_rt); } if (freeit && (flags & LLE_STATIC)) { _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 18:17:37 2011 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 A0781106566C for ; Fri, 7 Oct 2011 18:17:37 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 35D5F8FC12 for ; Fri, 7 Oct 2011 18:17:36 +0000 (UTC) Received: by wwe3 with SMTP id 3so5979042wwe.31 for ; Fri, 07 Oct 2011 11:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KeTv33ad5r91IRryp3YCHrba8LQugkWWqvoXa0tPFIE=; b=wvGLVqvv3QrvnJcbLyvQRHi8UdecDs6e2pZ7U2/tiXlmwSlO9DZNPWTGB2jB6DKpG9 0rIAetLWWQo58OfGrKV6YbNhbAYxCnnMwwSfmlm/cgWcTxLCfOJw68S8H2Wh+EMtWlED sdiR7VqsMpllfAgYUre6M05g1u3IYcvNXxCH0= MIME-Version: 1.0 Received: by 10.216.170.204 with SMTP id p54mr1146631wel.51.1318011455763; Fri, 07 Oct 2011 11:17:35 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Fri, 7 Oct 2011 11:17:35 -0700 (PDT) In-Reply-To: <201110071810.p97IA4RI000569@freefall.freebsd.org> References: <201110071810.p97IA4RI000569@freefall.freebsd.org> Date: Fri, 7 Oct 2011 14:17:35 -0400 Message-ID: From: Arnaud Lacombe To: dfilter service Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/159601: commit references a PR 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, 07 Oct 2011 18:17:37 -0000 Hi, On Fri, Oct 7, 2011 at 2:10 PM, dfilter service wrote= : > The following reply was made to PR kern/159601; it has been noted by GNAT= S. > > From: dfilter@FreeBSD.ORG (dfilter service) > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/159601: commit references a PR > Date: Fri, =A07 Oct 2011 18:01:51 +0000 (UTC) > > =A0Author: qingli > =A0Date: Fri Oct =A07 18:01:34 2011 > =A0New Revision: 226114 > =A0URL: http://svn.freebsd.org/changeset/base/226114 > > =A0Log: > =A0 Remove the reference held on the loopback route when the interface > =A0 address is being deleted. Only the last reference holder deletes the > =A0 loopback route. All other delete operations just clear the IFA_RTSELF > =A0 flag. > > =A0 PR: =A0 =A0 =A0 =A0 =A0kern/159601 > =A0 Submitted by: =A0 =A0 =A0 =A0pluknet > =A0 Reviewed by: discussed on net@ Can you point me in which thread ? Thanks, - Arnaud > =A0 MFC after: =A0 3 days > > =A0Modified: > =A0 head/sys/netinet/in.c > > =A0Modified: head/sys/netinet/in.c > =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > =A0--- head/sys/netinet/in.c =A0 =A0 =A0Fri Oct =A07 16:39:03 2011 =A0 = =A0 =A0 =A0(r226113) > =A0+++ head/sys/netinet/in.c =A0 =A0 =A0Fri Oct =A07 18:01:34 2011 =A0 = =A0 =A0 =A0(r226114) > =A0@@ -1126,8 +1126,10 @@ in_scrubprefix(struct in_ifaddr *target, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0RT_LOCK(ia_ro.ro_rt); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (ia_ro.ro_rt->rt_refcnt= <=3D 1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0freeit =3D= 1; > =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > =A0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (flags & LLE_STAT= IC) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0RT_REMREF(= ia_ro.ro_rt); > =A0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target->i= a_flags &=3D ~IFA_RTSELF; > =A0+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0RTFREE_LOCKED(ia_ro.ro_rt)= ; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (freeit && (flags & LLE_STATIC)) { > =A0_______________________________________________ > =A0svn-src-all@freebsd.org mailing list > =A0http://lists.freebsd.org/mailman/listinfo/svn-src-all > =A0To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 18:30:29 2011 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 8A7AC1065675 for ; Fri, 7 Oct 2011 18:30:29 +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 6C2818FC12 for ; Fri, 7 Oct 2011 18:30:29 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p97IUSoC018388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Oct 2011 11:30:29 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Fri, 7 Oct 2011 11:30:23 -0700 From: "Li, Qing" To: Arnaud Lacombe , dfilter service Thread-Topic: kern/159601: commit references a PR Thread-Index: AQHMhRxpXeb1s9tAAk66Ta4D5oP2hpVxpeaA//+Mpc0= Date: Fri, 7 Oct 2011 18:30:23 +0000 Message-ID: References: <201110071810.p97IA4RI000569@freefall.freebsd.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: kern/159601: commit references a PR 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, 07 Oct 2011 18:30:29 -0000 =0A= The important thing is if you have questions, just ask me.=0A= =0A= You can start from this email thread. =0A= =0A= http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026423.ht= ml=0A= =0A= --Qing=0A= =0A= ________________________________________=0A= From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on beha= lf of Arnaud Lacombe [lacombar@gmail.com]=0A= Sent: Friday, October 07, 2011 11:17 AM=0A= To: dfilter service=0A= Cc: freebsd-net@freebsd.org=0A= Subject: Re: kern/159601: commit references a PR=0A= =0A= Hi,=0A= =0A= On Fri, Oct 7, 2011 at 2:10 PM, dfilter service wrote= :=0A= > The following reply was made to PR kern/159601; it has been noted by GNAT= S.=0A= >=0A= > From: dfilter@FreeBSD.ORG (dfilter service)=0A= > To: bug-followup@FreeBSD.org=0A= > Cc:=0A= > Subject: Re: kern/159601: commit references a PR=0A= > Date: Fri, 7 Oct 2011 18:01:51 +0000 (UTC)=0A= >=0A= > Author: qingli=0A= > Date: Fri Oct 7 18:01:34 2011=0A= > New Revision: 226114=0A= > URL: http://svn.freebsd.org/changeset/base/226114=0A= >=0A= > Log:=0A= > Remove the reference held on the loopback route when the interface=0A= > address is being deleted. Only the last reference holder deletes the=0A= > loopback route. All other delete operations just clear the IFA_RTSELF= =0A= > flag.=0A= >=0A= > PR: kern/159601=0A= > Submitted by: pluknet=0A= > Reviewed by: discussed on net@=0A= Can you point me in which thread ?=0A= =0A= Thanks,=0A= - Arnaud=0A= =0A= > MFC after: 3 days=0A= >=0A= > Modified:=0A= > head/sys/netinet/in.c=0A= >=0A= > Modified: head/sys/netinet/in.c=0A= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A= > --- head/sys/netinet/in.c Fri Oct 7 16:39:03 2011 (r226113)= =0A= > +++ head/sys/netinet/in.c Fri Oct 7 18:01:34 2011 (r226114)= =0A= > @@ -1126,8 +1126,10 @@ in_scrubprefix(struct in_ifaddr *target,=0A= > RT_LOCK(ia_ro.ro_rt);=0A= > if (ia_ro.ro_rt->rt_refcnt <=3D 1)=0A= > freeit =3D 1;=0A= > - else=0A= > + else if (flags & LLE_STATIC) {=0A= > RT_REMREF(ia_ro.ro_rt);=0A= > + target->ia_flags &=3D ~IFA_RTSELF;=0A= > + }=0A= > RTFREE_LOCKED(ia_ro.ro_rt);=0A= > }=0A= > if (freeit && (flags & LLE_STATIC)) {=0A= > _______________________________________________=0A= > svn-src-all@freebsd.org mailing list=0A= > http://lists.freebsd.org/mailman/listinfo/svn-src-all=0A= > To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"= =0A= >=0A= > _______________________________________________=0A= > freebsd-net@freebsd.org mailing list=0A= > http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= >=0A= _______________________________________________=0A= freebsd-net@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 18:35:49 2011 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 02F65106566B for ; Fri, 7 Oct 2011 18:35:49 +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 D97538FC0A for ; Fri, 7 Oct 2011 18:35:48 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p97IZmU9019867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Oct 2011 11:35:48 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Fri, 7 Oct 2011 11:35:43 -0700 From: "Li, Qing" To: Arnaud Lacombe Thread-Topic: kern/159601: commit references a PR Thread-Index: AQHMhRxpXeb1s9tAAk66Ta4D5oP2hpVxpeaA//+Mpc2AAALdTw== Date: Fri, 7 Oct 2011 18:35:42 +0000 Message-ID: References: <201110071810.p97IA4RI000569@freefall.freebsd.org>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: kern/159601: commit references a PR 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, 07 Oct 2011 18:35:49 -0000 Here is one of my specific responses to the PRs.=0A= =0A= http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026506.= html=0A= =0A= -- Qing=0A= =0A= ________________________________________=0A= From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on beha= lf of Li, Qing=0A= Sent: Friday, October 07, 2011 11:30 AM=0A= To: Arnaud Lacombe; dfilter service=0A= Cc: freebsd-net@freebsd.org=0A= Subject: RE: kern/159601: commit references a PR=0A= =0A= The important thing is if you have questions, just ask me.=0A= =0A= You can start from this email thread.=0A= =0A= http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026423.ht= ml=0A= =0A= --Qing=0A= =0A= ________________________________________=0A= From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on beha= lf of Arnaud Lacombe [lacombar@gmail.com]=0A= Sent: Friday, October 07, 2011 11:17 AM=0A= To: dfilter service=0A= Cc: freebsd-net@freebsd.org=0A= Subject: Re: kern/159601: commit references a PR=0A= =0A= Hi,=0A= =0A= On Fri, Oct 7, 2011 at 2:10 PM, dfilter service wrote= :=0A= > The following reply was made to PR kern/159601; it has been noted by GNAT= S.=0A= >=0A= > From: dfilter@FreeBSD.ORG (dfilter service)=0A= > To: bug-followup@FreeBSD.org=0A= > Cc:=0A= > Subject: Re: kern/159601: commit references a PR=0A= > Date: Fri, 7 Oct 2011 18:01:51 +0000 (UTC)=0A= >=0A= > Author: qingli=0A= > Date: Fri Oct 7 18:01:34 2011=0A= > New Revision: 226114=0A= > URL: http://svn.freebsd.org/changeset/base/226114=0A= >=0A= > Log:=0A= > Remove the reference held on the loopback route when the interface=0A= > address is being deleted. Only the last reference holder deletes the=0A= > loopback route. All other delete operations just clear the IFA_RTSELF= =0A= > flag.=0A= >=0A= > PR: kern/159601=0A= > Submitted by: pluknet=0A= > Reviewed by: discussed on net@=0A= Can you point me in which thread ?=0A= =0A= Thanks,=0A= - Arnaud=0A= =0A= > MFC after: 3 days=0A= >=0A= > Modified:=0A= > head/sys/netinet/in.c=0A= >=0A= > Modified: head/sys/netinet/in.c=0A= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A= > --- head/sys/netinet/in.c Fri Oct 7 16:39:03 2011 (r226113)= =0A= > +++ head/sys/netinet/in.c Fri Oct 7 18:01:34 2011 (r226114)= =0A= > @@ -1126,8 +1126,10 @@ in_scrubprefix(struct in_ifaddr *target,=0A= > RT_LOCK(ia_ro.ro_rt);=0A= > if (ia_ro.ro_rt->rt_refcnt <=3D 1)=0A= > freeit =3D 1;=0A= > - else=0A= > + else if (flags & LLE_STATIC) {=0A= > RT_REMREF(ia_ro.ro_rt);=0A= > + target->ia_flags &=3D ~IFA_RTSELF;=0A= > + }=0A= > RTFREE_LOCKED(ia_ro.ro_rt);=0A= > }=0A= > if (freeit && (flags & LLE_STATIC)) {=0A= > _______________________________________________=0A= > svn-src-all@freebsd.org mailing list=0A= > http://lists.freebsd.org/mailman/listinfo/svn-src-all=0A= > To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"= =0A= >=0A= > _______________________________________________=0A= > freebsd-net@freebsd.org mailing list=0A= > http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= >=0A= _______________________________________________=0A= freebsd-net@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= _______________________________________________=0A= freebsd-net@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 18:57:34 2011 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 E99691065676 for ; Fri, 7 Oct 2011 18:57:34 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2238FC13 for ; Fri, 7 Oct 2011 18:57:33 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so6063633bkb.13 for ; Fri, 07 Oct 2011 11:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bBQTVpyAWQiMsXB6KvAsRrJ2ZLpFFqv8JGta9wTk1G4=; b=j4klhWE8id+cgvzAvVj+FNYXkO29XMELWXo4qlo/Oj8RxnxnlcGCEAg5pP3abpkjve tWHptXnQfqeWzpjOZGDdOWjOMyDYy3x8oLJTi3LMl5a8owidpQTreaIdWxbxP/eW/APn aSOmIqNcRUSOMbV8u8l0ZeSEWhPzUogS/ALLc= MIME-Version: 1.0 Received: by 10.223.58.83 with SMTP id f19mr12479986fah.36.1318013852152; Fri, 07 Oct 2011 11:57:32 -0700 (PDT) Received: by 10.152.36.102 with HTTP; Fri, 7 Oct 2011 11:57:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Oct 2011 11:57:32 -0700 Message-ID: From: Jason Wolfe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 18:57:35 -0000 Jack, Entirely possible there are multiple moving pieces here, the only bit I know for certain is it's related to the different operation when running with MSI vs MSI-X. Here is also my loader.conf for reference. I'm currently running the modular congestion control stuff with cubic in use, but these issues predate those changes also. Just to give you a scope of it though, it was somewhat 'rare' for them to wedge. Out of a pool of ~2000 servers running with the 82574L doing ~800Mb/s average, there were ~220 reports in a week. So with some fuzzy math to put it in the same terms you were talking in, a server in particular would hang about once every 9 weeks. net.inet.tcp.cc.available: cubic, newreno net.inet.tcp.cc.algorithm: cubic loader.conf: hw.pci.do_power_nodriver="3" net.link.ifqmaxlen="1024" net.inet.tcp.tcbhashsize="4096" net.inet.tcp.syncache.hashsize="1024" net.inet.tcp.syncache.bucketlimit="512" net.inet.tcp.syncache.cachelimit="65536" net.inet.tcp.hostcache.hashsize="1024" net.inet.tcp.hostcache.bucketlimit="512" net.inet.tcp.hostcache.cachelimit="65536" hw.em.enable_msix="0" hw.em.rxd="2048" hw.em.txd="2048" cc_cubic_load="YES" Thanks again for looking into it. Jason On Thu, Oct 6, 2011 at 5:02 PM, Jack Vogel wrote: > There are plenty other users using the 574 with MSI-X without issue, so its > likely > more complicated than just that 1 variable. The issue discussed was like > last year, > it has to do with getting stuck in low power state, and my driver has code > that addresses > that. There was rigorous testing done at the performance center in Canada, > got to > the point of having a hang once in maybe 3 weeks, and then that was fixed. > I have > not heard of a problem from Mike since. > > So, I'd say something else must be coming into play here, I'll stare at the > data > a bit when I get a chance and see if anything jumps out at me. > > Jack > > > On Thu, Oct 6, 2011 at 4:15 PM, Jason Wolfe wrote: > >> I'm seeing the interface wedge on a good number of systems with Intel >> 82574L >> chips under FBSD8.2 _only when MSI-X is enabled_, running either 7.1.9 >> from >> 8.2-RELEASE or 7.2.3 from 8.2-STABLE. I have em0 and em1 in a lagg, but >> only one side would fail, and a few systems that didn't have a lagg also >> saw >> the issue. Higher traffic did seem to increase the likely hood of it >> cropping up, but lower traffic server also showed the same issues >> (anywhere >> from 200Mb/s -> 1.8Gb/s). This wedging on the Intel chips has been >> discussed in many threads over the past year, though some have turned out >> to >> be various other issues. I haven't seen reports of it being fixed by >> disabling MSI-X via loader.conf, hw.em.enable_msix=0, so I figured I'd >> start >> a fresh one. >> >> The band aid for me was throwing a quick script into cron that watched for >> incrementing drops and static outgoing packet counts from netstat, then >> just >> bounced the interface with ifconfig down/up. Prior to the bounce I had it >> emailing me the output of the following commands: >> >> vmstat -i >> netstat -m >> netstat -ndi >> sysctl dev.em.X.debug=1 >> sysctl net.inet.ip.intr_queue_maxlen net.inet.ip.intr_queue_drops dev.em >> >> I have ~300 reports from over the course of a week or so while I played >> with >> various bits before finding MSI-X to be the culprit. These were all >> collected about a month ago, but as I'm seeing now the increased latency >> with MSI-X disabled (as discussed in another thread) I'm more interested >> in >> seeing we can tackle this. I can bounce them over to anyone interested. >> Random one, follow by pciconf output: >> >> I bounced em1 because dropped packets incremented 3175498 to 3175688 and >> the >> interface is not incrementing packets out. >> >> interrupt total rate >> irq3: uart1 94210 0 >> cpu0: timer 8536176695 2000 >> irq256: em0:rx 0 24657925778 5777 >> irq257: em0:tx 0 18016438387 4221 >> irq258: em0:link 1096 0 >> irq259: em1:rx 0 49440830 11 >> irq260: em1:tx 0 17831558454 4177 >> irq261: em1:link 3 0 >> irq262: mps0 971428418 227 >> cpu1: timer 8536168686 2000 >> cpu2: timer 8536168739 2000 >> cpu3: timer 8536168715 2000 >> Total 95671570011 22415 >> >> 43620/31830/75450 mbufs in use (current/cache/total) >> 8457/1825/10282/6192924 mbuf clusters in use (current/cache/total/max) >> 8457/1490 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> 32620/3569/36189/3096461 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) >> 158299K/25883K/184182K 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 >> >> Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop >> em0 1500 00:25:90:2c:a8:c8 70347342717 2290 0 53256848932 0 0 >> 1209615 >> em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 5 - - - >> em1 1500 00:25:90:2c:a8:c8 49440879 0 0 50500079972 0 0 3176057 >> em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 2 - - - >> lagg0 1500 00:25:90:2c:a8:c8 70396711726 0 0 103748441456 4385672 >> 0 >> 0 >> lagg0 1500 117.121.249.0 117.121.249.76 46351366311 - - 103757765366 - - - >> lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 607 - - 674 - - - >> lagg0 1500 2402:6800:730 2402:6800:730:12: 136847 - - 142450 - - - >> >> Aug 30 23:05:04 cds56 kernel: Interface is RUNNING and INACTIVE >> Aug 30 23:05:04 cds56 kernel: em0: hw tdh = 371, hw tdt = 376 >> Aug 30 23:05:04 cds56 kernel: em0: hw rdh = 923, hw rdt = 922 >> Aug 30 23:05:04 cds56 kernel: em0: Tx Queue Status = 0 >> Aug 30 23:05:04 cds56 kernel: em0: TX descriptors avail = 1014 >> Aug 30 23:05:04 cds56 kernel: em0: Tx Descriptors avail failure = 0 >> Aug 30 23:05:04 cds56 kernel: em0: RX discarded packets = 0 >> Aug 30 23:05:04 cds56 kernel: em0: RX Next to Check = 986 >> Aug 30 23:05:04 cds56 kernel: em0: RX Next to Refresh = 994 >> Aug 30 23:05:04 cds56 kernel: Interface is RUNNING and INACTIVE >> Aug 30 23:05:04 cds56 kernel: em1: hw tdh = 78, hw tdt = 78 >> Aug 30 23:05:04 cds56 kernel: em1: hw rdh = 88, hw rdt = 87 >> Aug 30 23:05:04 cds56 kernel: em1: Tx Queue Status = 0 >> Aug 30 23:05:04 cds56 kernel: em1: TX descriptors avail = 1024 >> Aug 30 23:05:04 cds56 kernel: em1: Tx Descriptors avail failure = 0 >> Aug 30 23:05:04 cds56 kernel: em1: RX discarded packets = 0 >> Aug 30 23:05:04 cds56 kernel: em1: RX Next to Check = 88 >> Aug 30 23:05:04 cds56 kernel: em1: RX Next to Refresh = 88 >> >> net.inet.ip.intr_queue_maxlen: 512 >> net.inet.ip.intr_queue_drops: 0 >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 >> dev.em.0.%driver: em >> dev.em.0.%location: slot=0 function=0 >> dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 >> subdevice=0x10d3 class=0x020000 >> dev.em.0.%parent: pci1 >> dev.em.0.nvm: -1 >> dev.em.0.debug: -1 >> dev.em.0.rx_int_delay: 0 >> dev.em.0.tx_int_delay: 66 >> dev.em.0.rx_abs_int_delay: 66 >> dev.em.0.tx_abs_int_delay: 66 >> dev.em.0.rx_processing_limit: 100 >> dev.em.0.flow_control: 3 >> dev.em.0.link_irq: 1096 >> dev.em.0.mbuf_alloc_fail: 0 >> dev.em.0.cluster_alloc_fail: 0 >> dev.em.0.dropped: 0 >> dev.em.0.tx_dma_fail: 0 >> dev.em.0.rx_overruns: 0 >> dev.em.0.watchdog_timeouts: 0 >> dev.em.0.device_control: 1477444168 >> dev.em.0.rx_control: 67141634 >> dev.em.0.fc_high_water: 18432 >> dev.em.0.fc_low_water: 16932 >> dev.em.0.queue0.txd_head: 923 >> dev.em.0.queue0.txd_tail: 923 >> dev.em.0.queue0.tx_irq: 18016443069 >> dev.em.0.queue0.no_desc_avail: 0 >> dev.em.0.queue0.rxd_head: 620 >> dev.em.0.queue0.rxd_tail: 619 >> dev.em.0.queue0.rx_irq: 24617484192 >> dev.em.0.mac_stats.excess_coll: 0 >> dev.em.0.mac_stats.single_coll: 0 >> dev.em.0.mac_stats.multiple_coll: 0 >> dev.em.0.mac_stats.late_coll: 0 >> dev.em.0.mac_stats.collision_count: 0 >> dev.em.0.mac_stats.symbol_errors: 0 >> dev.em.0.mac_stats.sequence_errors: 0 >> dev.em.0.mac_stats.defer_count: 0 >> dev.em.0.mac_stats.missed_packets: 2290 >> dev.em.0.mac_stats.recv_no_buff: 2063 >> dev.em.0.mac_stats.recv_undersize: 0 >> dev.em.0.mac_stats.recv_fragmented: 0 >> dev.em.0.mac_stats.recv_oversize: 0 >> dev.em.0.mac_stats.recv_jabber: 0 >> dev.em.0.mac_stats.recv_errs: 0 >> dev.em.0.mac_stats.crc_errs: 0 >> dev.em.0.mac_stats.alignment_errs: 0 >> dev.em.0.mac_stats.coll_ext_errs: 0 >> dev.em.0.mac_stats.xon_recvd: 0 >> dev.em.0.mac_stats.xon_txd: 34 >> dev.em.0.mac_stats.xoff_recvd: 0 >> dev.em.0.mac_stats.xoff_txd: 2281 >> dev.em.0.mac_stats.total_pkts_recvd: 70347571042 >> dev.em.0.mac_stats.good_pkts_recvd: 70347568752 >> dev.em.0.mac_stats.bcast_pkts_recvd: 49354826 >> dev.em.0.mac_stats.mcast_pkts_recvd: 21430 >> dev.em.0.mac_stats.rx_frames_64: 24097227332 >> dev.em.0.mac_stats.rx_frames_65_127: 26282000524 >> dev.em.0.mac_stats.rx_frames_128_255: 117491895 >> dev.em.0.mac_stats.rx_frames_256_511: 397131263 >> dev.em.0.mac_stats.rx_frames_512_1023: 1048868288 >> dev.em.0.mac_stats.rx_frames_1024_1522: 18404849450 >> dev.em.0.mac_stats.good_octets_recvd: 32288605684532 >> dev.em.0.mac_stats.good_octets_txd: 59508100377248 >> dev.em.0.mac_stats.total_pkts_txd: 53257111032 >> dev.em.0.mac_stats.good_pkts_txd: 53257108716 >> dev.em.0.mac_stats.bcast_pkts_txd: 21098 >> dev.em.0.mac_stats.mcast_pkts_txd: 28465 >> dev.em.0.mac_stats.tx_frames_64: 1243827849 >> dev.em.0.mac_stats.tx_frames_65_127: 12126816593 >> dev.em.0.mac_stats.tx_frames_128_255: 260192405 >> dev.em.0.mac_stats.tx_frames_256_511: 196901153 >> dev.em.0.mac_stats.tx_frames_512_1023: 565384449 >> dev.em.0.mac_stats.tx_frames_1024_1522: 38863986268 >> dev.em.0.mac_stats.tso_txd: 0 >> dev.em.0.mac_stats.tso_ctx_fail: 0 >> dev.em.0.interrupts.asserts: 571 >> dev.em.0.interrupts.rx_pkt_timer: 0 >> dev.em.0.interrupts.rx_abs_timer: 0 >> dev.em.0.interrupts.tx_pkt_timer: 0 >> dev.em.0.interrupts.tx_abs_timer: 0 >> dev.em.0.interrupts.tx_queue_empty: 0 >> dev.em.0.interrupts.tx_queue_min_thresh: 0 >> dev.em.0.interrupts.rx_desc_min_thresh: 0 >> dev.em.0.interrupts.rx_overrun: 0 >> dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 >> dev.em.1.%driver: em >> dev.em.1.%location: slot=0 function=0 >> dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 >> subdevice=0x10d3 class=0x020000 >> dev.em.1.%parent: pci2 >> dev.em.1.nvm: -1 >> dev.em.1.debug: -1 >> dev.em.1.rx_int_delay: 0 >> dev.em.1.tx_int_delay: 66 >> dev.em.1.rx_abs_int_delay: 66 >> dev.em.1.tx_abs_int_delay: 66 >> dev.em.1.rx_processing_limit: 100 >> dev.em.1.flow_control: 3 >> dev.em.1.link_irq: 3 >> dev.em.1.mbuf_alloc_fail: 0 >> dev.em.1.cluster_alloc_fail: 0 >> dev.em.1.dropped: 0 >> dev.em.1.tx_dma_fail: 0 >> dev.em.1.rx_overruns: 0 >> dev.em.1.watchdog_timeouts: 0 >> dev.em.1.device_control: 1477444168 >> dev.em.1.rx_control: 67141634 >> dev.em.1.fc_high_water: 18432 >> dev.em.1.fc_low_water: 16932 >> dev.em.1.queue0.txd_head: 78 >> dev.em.1.queue0.txd_tail: 78 >> dev.em.1.queue0.tx_irq: 17831483878 >> dev.em.1.queue0.no_desc_avail: 0 >> dev.em.1.queue0.rxd_head: 104 >> dev.em.1.queue0.rxd_tail: 103 >> dev.em.1.queue0.rx_irq: 49440805 >> dev.em.1.mac_stats.excess_coll: 0 >> dev.em.1.mac_stats.single_coll: 0 >> dev.em.1.mac_stats.multiple_coll: 0 >> dev.em.1.mac_stats.late_coll: 0 >> dev.em.1.mac_stats.collision_count: 0 >> dev.em.1.mac_stats.symbol_errors: 0 >> dev.em.1.mac_stats.sequence_errors: 0 >> dev.em.1.mac_stats.defer_count: 0 >> dev.em.1.mac_stats.missed_packets: 0 >> dev.em.1.mac_stats.recv_no_buff: 0 >> dev.em.1.mac_stats.recv_undersize: 0 >> dev.em.1.mac_stats.recv_fragmented: 0 >> dev.em.1.mac_stats.recv_oversize: 0 >> dev.em.1.mac_stats.recv_jabber: 0 >> dev.em.1.mac_stats.recv_errs: 0 >> dev.em.1.mac_stats.crc_errs: 0 >> dev.em.1.mac_stats.alignment_errs: 0 >> dev.em.1.mac_stats.coll_ext_errs: 0 >> dev.em.1.mac_stats.xon_recvd: 0 >> dev.em.1.mac_stats.xon_txd: 0 >> dev.em.1.mac_stats.xoff_recvd: 0 >> dev.em.1.mac_stats.xoff_txd: 0 >> dev.em.1.mac_stats.total_pkts_recvd: 49440891 >> dev.em.1.mac_stats.good_pkts_recvd: 49440891 >> dev.em.1.mac_stats.bcast_pkts_recvd: 49419308 >> dev.em.1.mac_stats.mcast_pkts_recvd: 21444 >> dev.em.1.mac_stats.rx_frames_64: 49419319 >> dev.em.1.mac_stats.rx_frames_65_127: 21536 >> dev.em.1.mac_stats.rx_frames_128_255: 1 >> dev.em.1.mac_stats.rx_frames_256_511: 11 >> dev.em.1.mac_stats.rx_frames_512_1023: 13 >> dev.em.1.mac_stats.rx_frames_1024_1522: 11 >> dev.em.1.mac_stats.good_octets_recvd: 3165480294 >> dev.em.1.mac_stats.good_octets_txd: 58735098276348 >> dev.em.1.mac_stats.total_pkts_txd: 50500079972 >> dev.em.1.mac_stats.good_pkts_txd: 50500079972 >> dev.em.1.mac_stats.bcast_pkts_txd: 0 >> dev.em.1.mac_stats.mcast_pkts_txd: 5 >> dev.em.1.mac_stats.tx_frames_64: 1267032327 >> dev.em.1.mac_stats.tx_frames_65_127: 9722353368 >> dev.em.1.mac_stats.tx_frames_128_255: 265847363 >> dev.em.1.mac_stats.tx_frames_256_511: 198177596 >> dev.em.1.mac_stats.tx_frames_512_1023: 568826323 >> dev.em.1.mac_stats.tx_frames_1024_1522: 38477842995 >> dev.em.1.mac_stats.tso_txd: 0 >> dev.em.1.mac_stats.tso_ctx_fail: 0 >> dev.em.1.interrupts.asserts: 4 >> dev.em.1.interrupts.rx_pkt_timer: 0 >> dev.em.1.interrupts.rx_abs_timer: 0 >> dev.em.1.interrupts.tx_pkt_timer: 0 >> dev.em.1.interrupts.tx_abs_timer: 0 >> dev.em.1.interrupts.tx_queue_empty: 0 >> dev.em.1.interrupts.tx_queue_min_thresh: 0 >> dev.em.1.interrupts.rx_desc_min_thresh: 0 >> dev.em.1.interrupts.rx_overrun: 0 >> >> hostb0@pci0:0:0:0: class=0x060000 card=0x00008086 chip=0x34068086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub to ESI Port' >> class = bridge >> subclass = HOST-PCI >> pcib1@pci0:0:1:0: class=0x060400 card=0x00008086 chip=0x34088086 rev=0x22 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub PCI Express Root Port 1' >> class = bridge >> subclass = PCI-PCI >> pcib2@pci0:0:2:0: class=0x060400 card=0x00008086 chip=0x34098086 rev=0x22 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub PCI Express Root Port 2' >> class = bridge >> subclass = PCI-PCI >> pcib3@pci0:0:3:0: class=0x060400 card=0x00008086 chip=0x340a8086 rev=0x22 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub PCI Express Root Port 3' >> class = bridge >> subclass = PCI-PCI >> pcib4@pci0:0:5:0: class=0x060400 card=0x00008086 chip=0x340c8086 rev=0x22 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub PCI Express Root Port 5' >> class = bridge >> subclass = PCI-PCI >> pcib5@pci0:0:7:0: class=0x060400 card=0x00008086 chip=0x340e8086 rev=0x22 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub PCI Express Root Port 7' >> class = bridge >> subclass = PCI-PCI >> ioapic0@pci0:0:19:0: class=0x080020 card=0x00000000 chip=0x342d8086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub I/OxAPIC Interrupt Controller' >> class = base peripheral >> subclass = interrupt controller >> bar [10] = type Memory, range 32, base 0xfec8a000, size 4096, enabled >> none0@pci0:0:20:0: class=0x080000 card=0x00000000 chip=0x342e8086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub System Management Registers' >> class = base peripheral >> subclass = interrupt controller >> none1@pci0:0:20:1: class=0x080000 card=0x00000000 chip=0x34228086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub GPIO and Scratch Pad Registers' >> class = base peripheral >> subclass = interrupt controller >> none2@pci0:0:20:2: class=0x080000 card=0x00000000 chip=0x34238086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub Control Status and RAS Registers' >> class = base peripheral >> subclass = interrupt controller >> none3@pci0:0:20:3: class=0x080000 card=0x00000000 chip=0x34388086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'QuickPath Architecture I/O Hub Throttle Registers' >> class = base peripheral >> subclass = interrupt controller >> none4@pci0:0:22:0: class=0x088000 card=0x000715d9 chip=0x34308086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'DMA Engine' >> class = base peripheral >> bar [10] = type Memory, range 64, base 0xfbed8000, size 16384, enabled >> none5@pci0:0:22:1: class=0x088000 card=0x000715d9 chip=0x34318086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'DMA Engine' >> class = base peripheral >> bar [10] = type Memory, range 64, base 0xfbedc000, size 16384, enabled >> none6@pci0:0:22:2: class=0x088000 card=0x000715d9 chip=0x34328086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'DMA Engine' >> class = base peripheral >> bar [10] = type Memory, range 64, base 0xfbee0000, size 16384, enabled >> none7@pci0:0:22:3: class=0x088000 card=0x000715d9 chip=0x34338086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'DMA Engine' >> class = base peripheral >> bar [10] = type Memory, range 64, base 0xfbee4000, size 16384, enabled >> none8@pci0:0:22:4: class=0x088000 card=0x000715d9 chip=0x34298086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'DMA Engine' >> class = base peripheral >> bar [10] = type Memory, range 64, base 0xfbee8000, size 16384, enabled >> none9@pci0:0:22:5: class=0x088000 card=0x000715d9 chip=0x342a8086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'DMA Engine' >> class = base peripheral >> bar [10] = type Memory, range 64, base 0xfbeec000, size 16384, enabled >> none10@pci0:0:22:6: class=0x088000 card=0x000715d9 chip=0x342b8086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'DMA Engine' >> class = base peripheral >> bar [10] = type Memory, range 64, base 0xfbef0000, size 16384, enabled >> none11@pci0:0:22:7: class=0x088000 card=0x000715d9 chip=0x342c8086 >> rev=0x22 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'DMA Engine' >> class = base peripheral >> bar [10] = type Memory, range 64, base 0xfbef4000, size 16384, enabled >> none12@pci0:0:26:0: class=0x0c0300 card=0x000715d9 chip=0x3a378086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'USB UHCI Controller *4' >> class = serial bus >> subclass = USB >> none13@pci0:0:26:1: class=0x0c0300 card=0x000715d9 chip=0x3a388086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'USB UHCI Controller *5' >> class = serial bus >> subclass = USB >> none14@pci0:0:26:2: class=0x0c0300 card=0x000715d9 chip=0x3a398086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'USB UHCI Controller *6' >> class = serial bus >> subclass = USB >> none15@pci0:0:26:7: class=0x0c0320 card=0x000715d9 chip=0x3a3c8086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'USB EHCI Controller *2' >> class = serial bus >> subclass = USB >> none16@pci0:0:29:0: class=0x0c0300 card=0x000715d9 chip=0x3a348086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'USB UHCI Controller *1' >> class = serial bus >> subclass = USB >> none17@pci0:0:29:1: class=0x0c0300 card=0x000715d9 chip=0x3a358086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'USB UHCI Controller *2' >> class = serial bus >> subclass = USB >> none18@pci0:0:29:2: class=0x0c0300 card=0x000715d9 chip=0x3a368086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'USB UHCI Controller *3' >> class = serial bus >> subclass = USB >> none19@pci0:0:29:7: class=0x0c0320 card=0x000715d9 chip=0x3a3a8086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'USB EHCI Controller *1' >> class = serial bus >> subclass = USB >> pcib6@pci0:0:30:0: class=0x060401 card=0x000715d9 chip=0x244e8086 >> rev=0x90 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI >> Bridge' >> class = bridge >> subclass = PCI-PCI >> isab0@pci0:0:31:0: class=0x060100 card=0x000715d9 chip=0x3a188086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'LPC Interface Controller' >> class = bridge >> subclass = PCI-ISA >> atapci0@pci0:0:31:2: class=0x01018f card=0x000715d9 chip=0x3a208086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'SATA2(4Port2) (ICH10 Family)' >> class = mass storage >> subclass = ATA >> bar [10] = type I/O Port, range 32, base 0xbc00, size 8, enabled >> bar [14] = type I/O Port, range 32, base 0xb880, size 4, enabled >> bar [18] = type I/O Port, range 32, base 0xb800, size 8, enabled >> bar [1c] = type I/O Port, range 32, base 0xb480, size 4, enabled >> bar [20] = type I/O Port, range 32, base 0xb400, size 16, enabled >> bar [24] = type I/O Port, range 32, base 0xb080, size 16, enabled >> none20@pci0:0:31:3: class=0x0c0500 card=0x000715d9 chip=0x3a308086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'SMB controller (50011458)' >> class = serial bus >> subclass = SMBus >> bar [10] = type Memory, range 64, base 0xfbefa000, size 256, enabled >> bar [20] = type I/O Port, range 32, base 0x400, size 32, enabled >> atapci1@pci0:0:31:5: class=0x010185 card=0x000715d9 chip=0x3a268086 >> rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'SATA2(2Port2) (ICH10 Family)' >> class = mass storage >> subclass = ATA >> bar [10] = type I/O Port, range 32, base 0xac00, size 8, enabled >> bar [14] = type I/O Port, range 32, base 0xa880, size 4, enabled >> bar [18] = type I/O Port, range 32, base 0xa800, size 8, enabled >> bar [1c] = type I/O Port, range 32, base 0xa480, size 4, enabled >> bar [20] = type I/O Port, range 32, base 0xa400, size 16, enabled >> bar [24] = type I/O Port, range 32, base 0xa080, size 16, enabled >> em0@pci0:1:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' >> class = network >> subclass = ethernet >> bar [10] = type Memory, range 32, base 0xfbbe0000, size 131072, enabled >> bar [18] = type I/O Port, range 32, base 0xcc00, size 32, enabled >> bar [1c] = type Memory, range 32, base 0xfbbdc000, size 16384, enabled >> em1@pci0:2:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' >> class = network >> subclass = ethernet >> bar [10] = type Memory, range 32, base 0xfbce0000, size 131072, enabled >> bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled >> bar [1c] = type Memory, range 32, base 0xfbcdc000, size 16384, enabled >> mps0@pci0:4:0:0: class=0x010700 card=0x040015d9 chip=0x00721000 rev=0x02 >> hdr=0x00 >> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >> class = mass storage >> subclass = SAS >> bar [10] = type I/O Port, range 32, base 0xe000, size 256, enabled >> bar [14] = type Memory, range 64, base 0xfbd3c000, size 16384, enabled >> bar [1c] = type Memory, range 64, base 0xfbd40000, size 262144, enabled >> vgapci0@pci0:6:1:0: class=0x030000 card=0x000715d9 chip=0x0532102b >> rev=0x0a >> hdr=0x00 >> vendor = 'Matrox Electronic Systems Ltd.' >> class = display >> subclass = VGA >> bar [10] = type Prefetchable Memory, range 32, base 0xf9000000, size >> 16777216, enabled >> bar [14] = type Memory, range 32, base 0xfaffc000, size 16384, enabled >> bar [18] = type Memory, range 32, base 0xfb000000, size 8388608, enabled >> hostb1@pci0:255:0:0: class=0x060000 card=0x80868086 chip=0x2c708086 >> rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb2@pci0:255:0:1: class=0x060000 card=0x80868086 chip=0x2d818086 >> rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb3@pci0:255:2:0: class=0x060000 card=0x80868086 chip=0x2d908086 >> rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb4@pci0:255:2:1: class=0x060000 card=0x80868086 chip=0x2d918086 >> rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb5@pci0:255:2:2: class=0x060000 card=0x80868086 chip=0x2d928086 >> rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb6@pci0:255:2:3: class=0x060000 card=0x80868086 chip=0x2d938086 >> rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb7@pci0:255:2:4: class=0x060000 card=0x80868086 chip=0x2d948086 >> rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb8@pci0:255:2:5: class=0x060000 card=0x80868086 chip=0x2d958086 >> rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb9@pci0:255:3:0: class=0x060000 card=0x80868086 chip=0x2d988086 >> rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb10@pci0:255:3:1: class=0x060000 card=0x80868086 chip=0x2d998086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb11@pci0:255:3:2: class=0x060000 card=0x80868086 chip=0x2d9a8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb12@pci0:255:3:4: class=0x060000 card=0x80868086 chip=0x2d9c8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb13@pci0:255:4:0: class=0x060000 card=0x80868086 chip=0x2da08086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb14@pci0:255:4:1: class=0x060000 card=0x80868086 chip=0x2da18086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb15@pci0:255:4:2: class=0x060000 card=0x80868086 chip=0x2da28086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb16@pci0:255:4:3: class=0x060000 card=0x80868086 chip=0x2da38086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb17@pci0:255:5:0: class=0x060000 card=0x80868086 chip=0x2da88086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb18@pci0:255:5:1: class=0x060000 card=0x80868086 chip=0x2da98086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb19@pci0:255:5:2: class=0x060000 card=0x80868086 chip=0x2daa8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb20@pci0:255:5:3: class=0x060000 card=0x80868086 chip=0x2dab8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb21@pci0:255:6:0: class=0x060000 card=0x80868086 chip=0x2db08086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb22@pci0:255:6:1: class=0x060000 card=0x80868086 chip=0x2db18086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb23@pci0:255:6:2: class=0x060000 card=0x80868086 chip=0x2db28086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> hostb24@pci0:255:6:3: class=0x060000 card=0x80868086 chip=0x2db38086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> class = bridge >> subclass = HOST-PCI >> >> Thank you in advance sirs! >> Jason Wolfe >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 18:59:16 2011 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 549D6106564A for ; Fri, 7 Oct 2011 18:59:16 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0A37E8FC12 for ; Fri, 7 Oct 2011 18:59:15 +0000 (UTC) Received: by ywp17 with SMTP id 17so4939029ywp.13 for ; Fri, 07 Oct 2011 11:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XYnP3i3cQgR+DF5PtWct4pbrc5K5qjI8/UNSf25pp50=; b=o/w4bct5f74ghDIyfImf6KFFslVh1Jym/wUPPSGazAqQ/CJPrDpTjte5vwr8c7CLC3 cofXPUHGnV8c1nT753aMhLbW+0A28ObwzH9VPmws2Pfz5nwsbQpvZBFTFUqJri1XUdWK c6Wf2Zf6w3hOKbKeRzYDzI3rgiGr/+b0noqtk= MIME-Version: 1.0 Received: by 10.223.16.131 with SMTP id o3mr12469599faa.11.1318013954579; Fri, 07 Oct 2011 11:59:14 -0700 (PDT) Received: by 10.152.36.102 with HTTP; Fri, 7 Oct 2011 11:59:14 -0700 (PDT) In-Reply-To: <4E8F157A.40702@sentex.net> References: <4E8F157A.40702@sentex.net> Date: Fri, 7 Oct 2011 11:59:14 -0700 Message-ID: From: Jason Wolfe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 18:59:16 -0000 Mike, I had a large pool of servers running 7.2.3 with MSI-X enabled during my testing, but it didn't resolve the issue. I just pulled back the sys/dev/e1000 directory from 8-STABLE and ran it on 8-RELEASE-p2 though, so if there were changes made outside of the actual driver code that helped I may have not seen the benefit. It's possible the lagg is adding some complication, but when one of the interfaces wedge the lagg continues to operate over the other link (though half of the traffic simply fails). It appears the interface just runs out of one of its buffers, and is helpless to resolve it without a bounce. I do recall coming across the ASPM threads, but my Supermicro boards didn't have the option and many people claimed it didn't resolve it, so I didn't follow through. I'll do a bit more digging there, thanks. Disabling MSI-X has without a doubt completely resolved my problem though. I would receive about 30 reports/failures a day from my servers when I was running with it, since disabling it I haven't received a single one in ~40 days. The servers are currently running with the 7.2.3 driver also, so if nothing jumps out from my original email I'm happy to re enable it on a handful of servers and collect some fresh reports. Jason On Fri, Oct 7, 2011 at 8:06 AM, Mike Tancsa wrote: > On 10/6/2011 7:15 PM, Jason Wolfe wrote: > > I'm seeing the interface wedge on a good number of systems with Intel > 82574L > > chips under FBSD8.2 _only when MSI-X is enabled_, running either 7.1.9 > from > > 8.2-RELEASE or 7.2.3 from 8.2-STABLE. I have em0 and em1 in a lagg, but > > only one side would fail, and a few systems that didn't have a lagg also > saw > > the issue. Higher traffic did seem to increase the likely hood of it > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 > > > Hi, > This sure sounds like the issue I was seeing with the 7.1.9 > driver... > However, it has been fixed for me by going to 7.2.3, which is in > RELENG_8. Is it possible you have a couple of issues going on since you > are using lagg as well ? Another problem some folks have reported is > that in the BIOS, if you have an option for ASPM, make sure its disabled. > > Google around for ASPM and 82574L for a discussion about it. > > If I recall correctly, disabling MSI-X just reduces the chance of the > problem happening, but its been a while since I ran into this issue. > > But for sure you want to be running 7.2.3 from stable > > This server used to see this issue > > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.1.%driver: em > dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART > dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 > subdevice=0x34ec class=0x020000 > dev.em.1.%parent: pci11 > dev.em.1.nvm: -1 > dev.em.1.debug: -1 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 100 > dev.em.1.flow_control: 3 > dev.em.1.eee_control: 0 > dev.em.1.link_irq: 0 > dev.em.1.mbuf_alloc_fail: 0 > dev.em.1.cluster_alloc_fail: 0 > dev.em.1.dropped: 0 > dev.em.1.tx_dma_fail: 0 > dev.em.1.rx_overruns: 0 > dev.em.1.watchdog_timeouts: 0 > dev.em.1.device_control: 1209008712 > dev.em.1.rx_control: 67141634 > dev.em.1.fc_high_water: 18432 > dev.em.1.fc_low_water: 16932 > dev.em.1.queue0.txd_head: 754 > dev.em.1.queue0.txd_tail: 754 > dev.em.1.queue0.tx_irq: 251430977 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 304 > dev.em.1.queue0.rxd_tail: 303 > dev.em.1.queue0.rx_irq: 295670362 > dev.em.1.mac_stats.excess_coll: 0 > dev.em.1.mac_stats.single_coll: 0 > dev.em.1.mac_stats.multiple_coll: 0 > dev.em.1.mac_stats.late_coll: 0 > dev.em.1.mac_stats.collision_count: 0 > dev.em.1.mac_stats.symbol_errors: 0 > dev.em.1.mac_stats.sequence_errors: 0 > dev.em.1.mac_stats.defer_count: 0 > dev.em.1.mac_stats.missed_packets: 0 > dev.em.1.mac_stats.recv_no_buff: 0 > dev.em.1.mac_stats.recv_undersize: 0 > dev.em.1.mac_stats.recv_fragmented: 0 > dev.em.1.mac_stats.recv_oversize: 0 > dev.em.1.mac_stats.recv_jabber: 0 > dev.em.1.mac_stats.recv_errs: 0 > dev.em.1.mac_stats.crc_errs: 0 > dev.em.1.mac_stats.alignment_errs: 0 > dev.em.1.mac_stats.coll_ext_errs: 0 > dev.em.1.mac_stats.xon_recvd: 0 > dev.em.1.mac_stats.xon_txd: 0 > dev.em.1.mac_stats.xoff_recvd: 0 > dev.em.1.mac_stats.xoff_txd: 0 > dev.em.1.mac_stats.total_pkts_recvd: 712410384 > dev.em.1.mac_stats.good_pkts_recvd: 712410384 > dev.em.1.mac_stats.bcast_pkts_recvd: 52263 > dev.em.1.mac_stats.mcast_pkts_recvd: 24921 > dev.em.1.mac_stats.rx_frames_64: 170050 > dev.em.1.mac_stats.rx_frames_65_127: 32571360 > dev.em.1.mac_stats.rx_frames_128_255: 19796510 > dev.em.1.mac_stats.rx_frames_256_511: 6283830 > dev.em.1.mac_stats.rx_frames_512_1023: 7922330 > dev.em.1.mac_stats.rx_frames_1024_1522: 645666304 > dev.em.1.mac_stats.good_octets_recvd: 988128549661 > dev.em.1.mac_stats.good_octets_txd: 48849605092 > dev.em.1.mac_stats.total_pkts_txd: 501680484 > dev.em.1.mac_stats.good_pkts_txd: 501680484 > dev.em.1.mac_stats.bcast_pkts_txd: 4266 > dev.em.1.mac_stats.mcast_pkts_txd: 8 > dev.em.1.mac_stats.tx_frames_64: 134256137 > dev.em.1.mac_stats.tx_frames_65_127: 291152180 > dev.em.1.mac_stats.tx_frames_128_255: 67219002 > dev.em.1.mac_stats.tx_frames_256_511: 5935140 > dev.em.1.mac_stats.tx_frames_512_1023: 812920 > dev.em.1.mac_stats.tx_frames_1024_1522: 2305105 > dev.em.1.mac_stats.tso_txd: 366978 > dev.em.1.mac_stats.tso_ctx_fail: 0 > dev.em.1.interrupts.asserts: 2 > dev.em.1.interrupts.rx_pkt_timer: 0 > dev.em.1.interrupts.rx_abs_timer: 0 > dev.em.1.interrupts.tx_pkt_timer: 0 > dev.em.1.interrupts.tx_abs_timer: 0 > dev.em.1.interrupts.tx_queue_empty: 0 > dev.em.1.interrupts.tx_queue_min_thresh: 0 > dev.em.1.interrupts.rx_desc_min_thresh: 0 > dev.em.1.interrupts.rx_overrun: 0 > > interrupt total rate > irq4: uart0 44896 0 > irq16: bge0 19753077 32 > irq18: arcmsr0 37518694 62 > irq19: twa0 556664 0 > irq21: ehci0 2149928 3 > irq23: ehci1 1209435 2 > cpu0: timer 1209274084 2000 > irq256: siis0 65793731 108 > irq257: em0 504313285 834 > irq258: em1:rx 0 295681170 489 > irq259: em1:tx 0 251430780 415 > irq261: ahci0 71285304 117 > cpu1: timer 1209264969 2000 > cpu3: timer 1209266038 2000 > cpu2: timer 1209265460 2000 > Total 6086807515 10067 > > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xb4100000, size 131072, > enabled > bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled > bar [1c] = type Memory, range 32, base 0xb4120000, size 16384, enabled > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected > ecap 0003[140] = Serial 1 001517ffffed68a4 > > > ---Mike > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 19:08:50 2011 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 46D1C1065673; Fri, 7 Oct 2011 19:08:50 +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 201368FC1F; Fri, 7 Oct 2011 19:08:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p97J8nX4013873; Fri, 7 Oct 2011 19:08:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p97J8nkX013867; Fri, 7 Oct 2011 19:08:49 GMT (envelope-from linimon) Date: Fri, 7 Oct 2011 19:08:49 GMT Message-Id: <201110071908.p97J8nkX013867@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/161381: [re] RTL8169SC - re0: PHY write failed 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, 07 Oct 2011 19:08:50 -0000 Old Synopsis: RTL8169SC - re0: PHY write failed New Synopsis: [re] RTL8169SC - re0: PHY write failed Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 7 19:08:35 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=161381 From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 19:13:58 2011 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 2A69C106566B; Fri, 7 Oct 2011 19:13:58 +0000 (UTC) (envelope-from pyunyh@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 57DD18FC12; Fri, 7 Oct 2011 19:13:57 +0000 (UTC) Received: by wyj26 with SMTP id 26so5796112wyj.13 for ; Fri, 07 Oct 2011 12:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=xQb+X0tjRKYsLS0oTiweSmHMdAoP7pTfIjJ4DjFPL8s=; b=td1RAApwTRV8gF3GCRCJmwcBgO9KaGKLCY0l01mmhL8To5ajYlb6Dss12pYskyCaLs dZlY5HfpA+XrwnbRgbKu07aoGs7racqMdydbnfxyqYDTOGgNh05A9vNd/GPCwBGEc6sV A89dsyg3CPI895iW9/yKNmSVdGfhQ5LyGp4HI= Received: by 10.216.134.217 with SMTP id s67mr2709372wei.101.1318014836246; Fri, 07 Oct 2011 12:13:56 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id ei16sm17639913wbb.21.2011.10.07.12.13.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 12:13:54 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Oct 2011 12:11:54 -0700 From: YongHyeon PYUN Date: Fri, 7 Oct 2011 12:11:54 -0700 To: Sean Bruno Message-ID: <20111007191154.GB11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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: Fri, 07 Oct 2011 19:13:58 -0000 On Mon, Oct 03, 2011 at 04:06:18PM -0700, Sean Bruno wrote: > On Mon, 2011-10-03 at 15:30 -0700, David Christensen wrote: > > > > > I should probably say, this is freebsd7. So I'll peruse the > > > changelogs > > > > > and see if 7 is missing something here. > > > > > > > > > > sean > > > > > > > > commenting this change out seems to be helping quite a bit with my > > > > issue. I think that this behavior may be wrong in the IPMI shared/nic > > > > case. Thoughts? > > > > > > > > > > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210261&r2=210263 > > > > > > > The main reason bce(4) needs to coordinate with NC-SI/IPMI > > firmware is to make sure only one software entity manipulates > > PHY registers. When bce(4) is loaded it will have priority > > over firmware (e.g. autoneg, speed, and duplex settings will > > be set by the host). If you don't bring up the interface in > > the host the firmware isn't authorized to do so, which sounds > > like your problem. > > > > Current bce(4) behavior notifies firmware that host driver > > is running when resetting the device in bce_attach(). We > > tell firmware that host driver is still running through > > bce_pulse(). Not sure how to handle the FreeBSD model where > > the driver load doesn't immediately bring the link up. > > > > Dave > > > > Hrm, understood. > > What are your thoughts on noting that the IPMI f/w is running and > leaving the interface up? I'm poking around trying to find the right > register bits at initialization to see that this is the case. > How about disabling bce_pulse() for IPMI interface? I guess this may result in not sending heart beat from driver to firmware such that firmware may take over control back from driver. The problem of the approach would be we don't know whether IPMI is active in driver at attach time and we may need some way to take control back from firmware once admin changed his/her mind to use the controller as a normal interface. > What's even more strange is that our freebsd6 instances don't have this > problem. > Can't explain either but probably stable/6 bce(4) may have used old firmware. > Sean > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 19:24:21 2011 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 29E47106566B for ; Fri, 7 Oct 2011 19:24:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id E10038FC0A for ; Fri, 7 Oct 2011 19:24:20 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id p97JOHZQ063139; Fri, 7 Oct 2011 15:24:17 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E8F51D4.1060509@sentex.net> Date: Fri, 07 Oct 2011 15:24:04 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jason Wolfe References: <4E8F157A.40702@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 19:24:21 -0000 On 10/7/2011 2:59 PM, Jason Wolfe wrote: > Mike, > > I had a large pool of servers running 7.2.3 with MSI-X enabled during my > testing, but it didn't resolve the issue. I just pulled back the > sys/dev/e1000 directory from 8-STABLE and ran it on 8-RELEASE-p2 though, so > if there were changes made outside of the actual driver code that helped I > may have not seen the benefit. It's possible the lagg is adding some > complication, but when one of the interfaces wedge the lagg continues to > operate over the other link (though half of the traffic simply fails). It > appears the interface just runs out of one of its buffers, and is helpless > to resolve it without a bounce. > > I do recall coming across the ASPM threads, but my Supermicro boards didn't > have the option and many people claimed it didn't resolve it, so I didn't > follow through. I'll do a bit more digging there, thanks. > > Disabling MSI-X has without a doubt completely resolved my problem though. I > would receive about 30 reports/failures a day from my servers when I was > running with it, since disabling it I haven't received a single one in ~40 > days. The servers are currently running with the 7.2.3 driver also, so if > nothing jumps out from my original email I'm happy to re enable it on a > handful of servers and collect some fresh reports. Hi Jason, This sounds like a real drag :( You certainly have WAY more servers to sample from than I do/did (a couple). The problem on my boxes were not very frequent to start with, so it would take a while. But the symptoms were very similar in that I would see queue overruns in the stats when things were wedged. I have other em nics (non 82574) that get the odd overrun when they are busy, but they seem to recover from the situation just fine. The 82574 did not. When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the board, or you disable multi-queue for the NIC, so it uses just one interrupt, rather than separate ones for xmit and recv ? Also, what is the purpose of hw.pci.do_power_nodriver=3 vs 0 (3 means put absolutely everything in D3 state.) net.link.ifqmaxlen 1024 vs 50 (does anything else need to be adjusted of this value is increased?) hw.em.rxd="2048" hw.em.txd="2048" Have you tried leaving these two at the default on 7.2.3 ? if_em.h implies 1024 for each. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 19:24:46 2011 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 085AE106566B for ; Fri, 7 Oct 2011 19:24:46 +0000 (UTC) (envelope-from lacombar@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 3B8548FC19 for ; Fri, 7 Oct 2011 19:24:44 +0000 (UTC) Received: by wyj26 with SMTP id 26so5807642wyj.13 for ; Fri, 07 Oct 2011 12:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Uq+N+o4+6nks+ZjmPsljCdf99jRHQCV4m5LbZGZ5H4o=; b=Izu1nRixVmkENUm6g5WKoG8sPu2k4Scvkbk5SUDPznr6N2LGLbL/bODSVTWgkRVzd6 V+53rhWO9GfSUSdGBLf3wQbfhwgUY7bB+PyaoRrYiBN6DtvT5mBnZVLDovTuD7csQGp9 eXJr3K9CGQSsU2qA1TGN2gTJ8RTW9AzB05SJU= MIME-Version: 1.0 Received: by 10.227.195.13 with SMTP id ea13mr2822370wbb.36.1318015483601; Fri, 07 Oct 2011 12:24:43 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Fri, 7 Oct 2011 12:24:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Oct 2011 15:24:43 -0400 Message-ID: From: Arnaud Lacombe To: Jason Wolfe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 19:24:46 -0000 Hi, On Fri, Oct 7, 2011 at 2:57 PM, Jason Wolfe wrote: > Jack, > > Entirely possible there are multiple moving pieces here, the only bit I k= now > for certain is it's related to the different operation when running with = MSI > vs MSI-X. Here is also my loader.conf for reference. I'm currently runnin= g > the modular congestion control stuff with cubic in use, but these issues > predate those changes also. Just to give you a scope of it though, it was > somewhat 'rare' for them to wedge. Out of a pool of ~2000 servers running > with the 82574L doing ~800Mb/s average, there were ~220 reports in a week= . > So with some fuzzy math to put it in the same terms you were talking in, = a > server in particular would hang about once every 9 weeks. > Just a two questions out of my mind: Are the failing server evenly distributed, or always the same are failing ? Did you collect the uptime and the kernel msgbuf of the server when the issue triggered ? Thanks, - Arnaud > net.inet.tcp.cc.available: cubic, newreno > net.inet.tcp.cc.algorithm: cubic > > loader.conf: > hw.pci.do_power_nodriver=3D"3" > net.link.ifqmaxlen=3D"1024" > net.inet.tcp.tcbhashsize=3D"4096" > net.inet.tcp.syncache.hashsize=3D"1024" > net.inet.tcp.syncache.bucketlimit=3D"512" > net.inet.tcp.syncache.cachelimit=3D"65536" > net.inet.tcp.hostcache.hashsize=3D"1024" > net.inet.tcp.hostcache.bucketlimit=3D"512" > net.inet.tcp.hostcache.cachelimit=3D"65536" > hw.em.enable_msix=3D"0" > hw.em.rxd=3D"2048" > hw.em.txd=3D"2048" > cc_cubic_load=3D"YES" > > Thanks again for looking into it. > > Jason > > On Thu, Oct 6, 2011 at 5:02 PM, Jack Vogel wrote: > >> There are plenty other users using the 574 with MSI-X without issue, so = its >> likely >> more complicated than just that 1 variable. The issue discussed was like >> last year, >> it has to do with getting stuck in low power state, and my driver has co= de >> that addresses >> that. There was rigorous testing done at the performance center in Canad= a, >> got to >> the point of having a hang once in maybe 3 weeks, and then that was fixe= d. >> I have >> not heard of a problem from Mike since. >> >> So, I'd say something else must be coming into play here, I'll stare at = the >> data >> a bit when I get a chance and see if anything jumps out at me. >> >> Jack >> >> >> On Thu, Oct 6, 2011 at 4:15 PM, Jason Wolfe wrote= : >> >>> I'm seeing the interface wedge on a good number of systems with Intel >>> 82574L >>> chips under FBSD8.2 _only when MSI-X is enabled_, running either 7.1.9 >>> from >>> 8.2-RELEASE or 7.2.3 from 8.2-STABLE. =A0I have em0 and em1 in a lagg, = but >>> only one side would fail, and a few systems that didn't have a lagg als= o >>> saw >>> the issue. =A0Higher traffic did seem to increase the likely hood of it >>> cropping up, but lower traffic server also showed the same issues >>> (anywhere >>> from 200Mb/s -> 1.8Gb/s). =A0This wedging on the Intel chips has been >>> discussed in many threads over the past year, though some have turned o= ut >>> to >>> be various other issues. =A0I haven't seen reports of it being fixed by >>> disabling MSI-X via loader.conf, hw.em.enable_msix=3D0, so I figured I'= d >>> start >>> a fresh one. >>> >>> The band aid for me was throwing a quick script into cron that watched = for >>> incrementing drops and static outgoing packet counts from netstat, then >>> just >>> bounced the interface with ifconfig down/up. =A0Prior to the bounce I h= ad it >>> emailing me the output of the following commands: >>> >>> vmstat -i >>> netstat -m >>> netstat -ndi >>> sysctl dev.em.X.debug=3D1 >>> sysctl net.inet.ip.intr_queue_maxlen net.inet.ip.intr_queue_drops dev.e= m >>> >>> I have ~300 reports from over the course of a week or so while I played >>> with >>> various bits before finding MSI-X to be the culprit. =A0These were all >>> collected about a month ago, but as I'm seeing now the increased latenc= y >>> with MSI-X disabled (as discussed in another thread) I'm more intereste= d >>> in >>> seeing we can tackle this. =A0I can bounce them over to anyone interest= ed. >>> Random one, follow by pciconf output: >>> >>> I bounced em1 because dropped packets incremented 3175498 to 3175688 an= d >>> the >>> interface is not incrementing packets out. >>> >>> interrupt total rate >>> irq3: uart1 94210 0 >>> cpu0: timer 8536176695 2000 >>> irq256: em0:rx 0 24657925778 5777 >>> irq257: em0:tx 0 18016438387 4221 >>> irq258: em0:link 1096 0 >>> irq259: em1:rx 0 49440830 11 >>> irq260: em1:tx 0 17831558454 4177 >>> irq261: em1:link 3 0 >>> irq262: mps0 971428418 227 >>> cpu1: timer 8536168686 2000 >>> cpu2: timer 8536168739 2000 >>> cpu3: timer 8536168715 2000 >>> Total 95671570011 22415 >>> >>> 43620/31830/75450 mbufs in use (current/cache/total) >>> 8457/1825/10282/6192924 mbuf clusters in use (current/cache/total/max) >>> 8457/1490 mbuf+clusters out of packet secondary zone in use >>> (current/cache) >>> 32620/3569/36189/3096461 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) >>> 158299K/25883K/184182K 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 >>> >>> Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop >>> em0 1500 00:25:90:2c:a8:c8 70347342717 2290 0 53256848932 0 0 >>> 1209615 >>> em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 5 - - - >>> em1 1500 00:25:90:2c:a8:c8 49440879 0 0 50500079972 0 0 317605= 7 >>> em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 2 - - - >>> lagg0 1500 00:25:90:2c:a8:c8 70396711726 0 0 103748441456 4385= 672 >>> 0 >>> 0 >>> lagg0 1500 117.121.249.0 117.121.249.76 46351366311 - - 103757765366 - = - - >>> lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 607 - - 674 - - - >>> lagg0 1500 2402:6800:730 2402:6800:730:12: 136847 - - 142450 - - - >>> >>> Aug 30 23:05:04 cds56 kernel: Interface is RUNNING and INACTIVE >>> Aug 30 23:05:04 cds56 kernel: em0: hw tdh =3D 371, hw tdt =3D 376 >>> Aug 30 23:05:04 cds56 kernel: em0: hw rdh =3D 923, hw rdt =3D 922 >>> Aug 30 23:05:04 cds56 kernel: em0: Tx Queue Status =3D 0 >>> Aug 30 23:05:04 cds56 kernel: em0: TX descriptors avail =3D 1014 >>> Aug 30 23:05:04 cds56 kernel: em0: Tx Descriptors avail failure =3D 0 >>> Aug 30 23:05:04 cds56 kernel: em0: RX discarded packets =3D 0 >>> Aug 30 23:05:04 cds56 kernel: em0: RX Next to Check =3D 986 >>> Aug 30 23:05:04 cds56 kernel: em0: RX Next to Refresh =3D 994 >>> Aug 30 23:05:04 cds56 kernel: Interface is RUNNING and INACTIVE >>> Aug 30 23:05:04 cds56 kernel: em1: hw tdh =3D 78, hw tdt =3D 78 >>> Aug 30 23:05:04 cds56 kernel: em1: hw rdh =3D 88, hw rdt =3D 87 >>> Aug 30 23:05:04 cds56 kernel: em1: Tx Queue Status =3D 0 >>> Aug 30 23:05:04 cds56 kernel: em1: TX descriptors avail =3D 1024 >>> Aug 30 23:05:04 cds56 kernel: em1: Tx Descriptors avail failure =3D 0 >>> Aug 30 23:05:04 cds56 kernel: em1: RX discarded packets =3D 0 >>> Aug 30 23:05:04 cds56 kernel: em1: RX Next to Check =3D 88 >>> Aug 30 23:05:04 cds56 kernel: em1: RX Next to Refresh =3D 88 >>> >>> net.inet.ip.intr_queue_maxlen: 512 >>> net.inet.ip.intr_queue_drops: 0 >>> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 >>> dev.em.0.%driver: em >>> dev.em.0.%location: slot=3D0 function=3D0 >>> dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x15d9 >>> subdevice=3D0x10d3 class=3D0x020000 >>> dev.em.0.%parent: pci1 >>> dev.em.0.nvm: -1 >>> dev.em.0.debug: -1 >>> dev.em.0.rx_int_delay: 0 >>> dev.em.0.tx_int_delay: 66 >>> dev.em.0.rx_abs_int_delay: 66 >>> dev.em.0.tx_abs_int_delay: 66 >>> dev.em.0.rx_processing_limit: 100 >>> dev.em.0.flow_control: 3 >>> dev.em.0.link_irq: 1096 >>> dev.em.0.mbuf_alloc_fail: 0 >>> dev.em.0.cluster_alloc_fail: 0 >>> dev.em.0.dropped: 0 >>> dev.em.0.tx_dma_fail: 0 >>> dev.em.0.rx_overruns: 0 >>> dev.em.0.watchdog_timeouts: 0 >>> dev.em.0.device_control: 1477444168 >>> dev.em.0.rx_control: 67141634 >>> dev.em.0.fc_high_water: 18432 >>> dev.em.0.fc_low_water: 16932 >>> dev.em.0.queue0.txd_head: 923 >>> dev.em.0.queue0.txd_tail: 923 >>> dev.em.0.queue0.tx_irq: 18016443069 >>> dev.em.0.queue0.no_desc_avail: 0 >>> dev.em.0.queue0.rxd_head: 620 >>> dev.em.0.queue0.rxd_tail: 619 >>> dev.em.0.queue0.rx_irq: 24617484192 >>> dev.em.0.mac_stats.excess_coll: 0 >>> dev.em.0.mac_stats.single_coll: 0 >>> dev.em.0.mac_stats.multiple_coll: 0 >>> dev.em.0.mac_stats.late_coll: 0 >>> dev.em.0.mac_stats.collision_count: 0 >>> dev.em.0.mac_stats.symbol_errors: 0 >>> dev.em.0.mac_stats.sequence_errors: 0 >>> dev.em.0.mac_stats.defer_count: 0 >>> dev.em.0.mac_stats.missed_packets: 2290 >>> dev.em.0.mac_stats.recv_no_buff: 2063 >>> dev.em.0.mac_stats.recv_undersize: 0 >>> dev.em.0.mac_stats.recv_fragmented: 0 >>> dev.em.0.mac_stats.recv_oversize: 0 >>> dev.em.0.mac_stats.recv_jabber: 0 >>> dev.em.0.mac_stats.recv_errs: 0 >>> dev.em.0.mac_stats.crc_errs: 0 >>> dev.em.0.mac_stats.alignment_errs: 0 >>> dev.em.0.mac_stats.coll_ext_errs: 0 >>> dev.em.0.mac_stats.xon_recvd: 0 >>> dev.em.0.mac_stats.xon_txd: 34 >>> dev.em.0.mac_stats.xoff_recvd: 0 >>> dev.em.0.mac_stats.xoff_txd: 2281 >>> dev.em.0.mac_stats.total_pkts_recvd: 70347571042 >>> dev.em.0.mac_stats.good_pkts_recvd: 70347568752 >>> dev.em.0.mac_stats.bcast_pkts_recvd: 49354826 >>> dev.em.0.mac_stats.mcast_pkts_recvd: 21430 >>> dev.em.0.mac_stats.rx_frames_64: 24097227332 >>> dev.em.0.mac_stats.rx_frames_65_127: 26282000524 >>> dev.em.0.mac_stats.rx_frames_128_255: 117491895 >>> dev.em.0.mac_stats.rx_frames_256_511: 397131263 >>> dev.em.0.mac_stats.rx_frames_512_1023: 1048868288 >>> dev.em.0.mac_stats.rx_frames_1024_1522: 18404849450 >>> dev.em.0.mac_stats.good_octets_recvd: 32288605684532 >>> dev.em.0.mac_stats.good_octets_txd: 59508100377248 >>> dev.em.0.mac_stats.total_pkts_txd: 53257111032 >>> dev.em.0.mac_stats.good_pkts_txd: 53257108716 >>> dev.em.0.mac_stats.bcast_pkts_txd: 21098 >>> dev.em.0.mac_stats.mcast_pkts_txd: 28465 >>> dev.em.0.mac_stats.tx_frames_64: 1243827849 >>> dev.em.0.mac_stats.tx_frames_65_127: 12126816593 >>> dev.em.0.mac_stats.tx_frames_128_255: 260192405 >>> dev.em.0.mac_stats.tx_frames_256_511: 196901153 >>> dev.em.0.mac_stats.tx_frames_512_1023: 565384449 >>> dev.em.0.mac_stats.tx_frames_1024_1522: 38863986268 >>> dev.em.0.mac_stats.tso_txd: 0 >>> dev.em.0.mac_stats.tso_ctx_fail: 0 >>> dev.em.0.interrupts.asserts: 571 >>> dev.em.0.interrupts.rx_pkt_timer: 0 >>> dev.em.0.interrupts.rx_abs_timer: 0 >>> dev.em.0.interrupts.tx_pkt_timer: 0 >>> dev.em.0.interrupts.tx_abs_timer: 0 >>> dev.em.0.interrupts.tx_queue_empty: 0 >>> dev.em.0.interrupts.tx_queue_min_thresh: 0 >>> dev.em.0.interrupts.rx_desc_min_thresh: 0 >>> dev.em.0.interrupts.rx_overrun: 0 >>> dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 >>> dev.em.1.%driver: em >>> dev.em.1.%location: slot=3D0 function=3D0 >>> dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x15d9 >>> subdevice=3D0x10d3 class=3D0x020000 >>> dev.em.1.%parent: pci2 >>> dev.em.1.nvm: -1 >>> dev.em.1.debug: -1 >>> dev.em.1.rx_int_delay: 0 >>> dev.em.1.tx_int_delay: 66 >>> dev.em.1.rx_abs_int_delay: 66 >>> dev.em.1.tx_abs_int_delay: 66 >>> dev.em.1.rx_processing_limit: 100 >>> dev.em.1.flow_control: 3 >>> dev.em.1.link_irq: 3 >>> dev.em.1.mbuf_alloc_fail: 0 >>> dev.em.1.cluster_alloc_fail: 0 >>> dev.em.1.dropped: 0 >>> dev.em.1.tx_dma_fail: 0 >>> dev.em.1.rx_overruns: 0 >>> dev.em.1.watchdog_timeouts: 0 >>> dev.em.1.device_control: 1477444168 >>> dev.em.1.rx_control: 67141634 >>> dev.em.1.fc_high_water: 18432 >>> dev.em.1.fc_low_water: 16932 >>> dev.em.1.queue0.txd_head: 78 >>> dev.em.1.queue0.txd_tail: 78 >>> dev.em.1.queue0.tx_irq: 17831483878 >>> dev.em.1.queue0.no_desc_avail: 0 >>> dev.em.1.queue0.rxd_head: 104 >>> dev.em.1.queue0.rxd_tail: 103 >>> dev.em.1.queue0.rx_irq: 49440805 >>> dev.em.1.mac_stats.excess_coll: 0 >>> dev.em.1.mac_stats.single_coll: 0 >>> dev.em.1.mac_stats.multiple_coll: 0 >>> dev.em.1.mac_stats.late_coll: 0 >>> dev.em.1.mac_stats.collision_count: 0 >>> dev.em.1.mac_stats.symbol_errors: 0 >>> dev.em.1.mac_stats.sequence_errors: 0 >>> dev.em.1.mac_stats.defer_count: 0 >>> dev.em.1.mac_stats.missed_packets: 0 >>> dev.em.1.mac_stats.recv_no_buff: 0 >>> dev.em.1.mac_stats.recv_undersize: 0 >>> dev.em.1.mac_stats.recv_fragmented: 0 >>> dev.em.1.mac_stats.recv_oversize: 0 >>> dev.em.1.mac_stats.recv_jabber: 0 >>> dev.em.1.mac_stats.recv_errs: 0 >>> dev.em.1.mac_stats.crc_errs: 0 >>> dev.em.1.mac_stats.alignment_errs: 0 >>> dev.em.1.mac_stats.coll_ext_errs: 0 >>> dev.em.1.mac_stats.xon_recvd: 0 >>> dev.em.1.mac_stats.xon_txd: 0 >>> dev.em.1.mac_stats.xoff_recvd: 0 >>> dev.em.1.mac_stats.xoff_txd: 0 >>> dev.em.1.mac_stats.total_pkts_recvd: 49440891 >>> dev.em.1.mac_stats.good_pkts_recvd: 49440891 >>> dev.em.1.mac_stats.bcast_pkts_recvd: 49419308 >>> dev.em.1.mac_stats.mcast_pkts_recvd: 21444 >>> dev.em.1.mac_stats.rx_frames_64: 49419319 >>> dev.em.1.mac_stats.rx_frames_65_127: 21536 >>> dev.em.1.mac_stats.rx_frames_128_255: 1 >>> dev.em.1.mac_stats.rx_frames_256_511: 11 >>> dev.em.1.mac_stats.rx_frames_512_1023: 13 >>> dev.em.1.mac_stats.rx_frames_1024_1522: 11 >>> dev.em.1.mac_stats.good_octets_recvd: 3165480294 >>> dev.em.1.mac_stats.good_octets_txd: 58735098276348 >>> dev.em.1.mac_stats.total_pkts_txd: 50500079972 >>> dev.em.1.mac_stats.good_pkts_txd: 50500079972 >>> dev.em.1.mac_stats.bcast_pkts_txd: 0 >>> dev.em.1.mac_stats.mcast_pkts_txd: 5 >>> dev.em.1.mac_stats.tx_frames_64: 1267032327 >>> dev.em.1.mac_stats.tx_frames_65_127: 9722353368 >>> dev.em.1.mac_stats.tx_frames_128_255: 265847363 >>> dev.em.1.mac_stats.tx_frames_256_511: 198177596 >>> dev.em.1.mac_stats.tx_frames_512_1023: 568826323 >>> dev.em.1.mac_stats.tx_frames_1024_1522: 38477842995 >>> dev.em.1.mac_stats.tso_txd: 0 >>> dev.em.1.mac_stats.tso_ctx_fail: 0 >>> dev.em.1.interrupts.asserts: 4 >>> dev.em.1.interrupts.rx_pkt_timer: 0 >>> dev.em.1.interrupts.rx_abs_timer: 0 >>> dev.em.1.interrupts.tx_pkt_timer: 0 >>> dev.em.1.interrupts.tx_abs_timer: 0 >>> dev.em.1.interrupts.tx_queue_empty: 0 >>> dev.em.1.interrupts.tx_queue_min_thresh: 0 >>> dev.em.1.interrupts.rx_desc_min_thresh: 0 >>> dev.em.1.interrupts.rx_overrun: 0 >>> >>> hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x00008086 chip=3D0x34068086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub to ESI Port' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x00008086 chip=3D0x34088086 = rev=3D0x22 >>> hdr=3D0x01 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub PCI Express Root Port 1' >>> class =3D bridge >>> subclass =3D PCI-PCI >>> pcib2@pci0:0:2:0: class=3D0x060400 card=3D0x00008086 chip=3D0x34098086 = rev=3D0x22 >>> hdr=3D0x01 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub PCI Express Root Port 2' >>> class =3D bridge >>> subclass =3D PCI-PCI >>> pcib3@pci0:0:3:0: class=3D0x060400 card=3D0x00008086 chip=3D0x340a8086 = rev=3D0x22 >>> hdr=3D0x01 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub PCI Express Root Port 3' >>> class =3D bridge >>> subclass =3D PCI-PCI >>> pcib4@pci0:0:5:0: class=3D0x060400 card=3D0x00008086 chip=3D0x340c8086 = rev=3D0x22 >>> hdr=3D0x01 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub PCI Express Root Port 5' >>> class =3D bridge >>> subclass =3D PCI-PCI >>> pcib5@pci0:0:7:0: class=3D0x060400 card=3D0x00008086 chip=3D0x340e8086 = rev=3D0x22 >>> hdr=3D0x01 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub PCI Express Root Port 7' >>> class =3D bridge >>> subclass =3D PCI-PCI >>> ioapic0@pci0:0:19:0: class=3D0x080020 card=3D0x00000000 chip=3D0x342d80= 86 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub I/OxAPIC Interrupt Controlle= r' >>> class =3D base peripheral >>> subclass =3D interrupt controller >>> bar [10] =3D type Memory, range 32, base 0xfec8a000, size 4096, enabled >>> none0@pci0:0:20:0: class=3D0x080000 card=3D0x00000000 chip=3D0x342e8086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub System Management Registers' >>> class =3D base peripheral >>> subclass =3D interrupt controller >>> none1@pci0:0:20:1: class=3D0x080000 card=3D0x00000000 chip=3D0x34228086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub GPIO and Scratch Pad Registe= rs' >>> class =3D base peripheral >>> subclass =3D interrupt controller >>> none2@pci0:0:20:2: class=3D0x080000 card=3D0x00000000 chip=3D0x34238086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub Control Status and RAS Regis= ters' >>> class =3D base peripheral >>> subclass =3D interrupt controller >>> none3@pci0:0:20:3: class=3D0x080000 card=3D0x00000000 chip=3D0x34388086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'QuickPath Architecture I/O Hub Throttle Registers' >>> class =3D base peripheral >>> subclass =3D interrupt controller >>> none4@pci0:0:22:0: class=3D0x088000 card=3D0x000715d9 chip=3D0x34308086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'DMA Engine' >>> class =3D base peripheral >>> bar [10] =3D type Memory, range 64, base 0xfbed8000, size 16384, enable= d >>> none5@pci0:0:22:1: class=3D0x088000 card=3D0x000715d9 chip=3D0x34318086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'DMA Engine' >>> class =3D base peripheral >>> bar [10] =3D type Memory, range 64, base 0xfbedc000, size 16384, enable= d >>> none6@pci0:0:22:2: class=3D0x088000 card=3D0x000715d9 chip=3D0x34328086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'DMA Engine' >>> class =3D base peripheral >>> bar [10] =3D type Memory, range 64, base 0xfbee0000, size 16384, enable= d >>> none7@pci0:0:22:3: class=3D0x088000 card=3D0x000715d9 chip=3D0x34338086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'DMA Engine' >>> class =3D base peripheral >>> bar [10] =3D type Memory, range 64, base 0xfbee4000, size 16384, enable= d >>> none8@pci0:0:22:4: class=3D0x088000 card=3D0x000715d9 chip=3D0x34298086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'DMA Engine' >>> class =3D base peripheral >>> bar [10] =3D type Memory, range 64, base 0xfbee8000, size 16384, enable= d >>> none9@pci0:0:22:5: class=3D0x088000 card=3D0x000715d9 chip=3D0x342a8086 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'DMA Engine' >>> class =3D base peripheral >>> bar [10] =3D type Memory, range 64, base 0xfbeec000, size 16384, enable= d >>> none10@pci0:0:22:6: class=3D0x088000 card=3D0x000715d9 chip=3D0x342b808= 6 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'DMA Engine' >>> class =3D base peripheral >>> bar [10] =3D type Memory, range 64, base 0xfbef0000, size 16384, enable= d >>> none11@pci0:0:22:7: class=3D0x088000 card=3D0x000715d9 chip=3D0x342c808= 6 >>> rev=3D0x22 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'DMA Engine' >>> class =3D base peripheral >>> bar [10] =3D type Memory, range 64, base 0xfbef4000, size 16384, enable= d >>> none12@pci0:0:26:0: class=3D0x0c0300 card=3D0x000715d9 chip=3D0x3a37808= 6 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'USB UHCI Controller *4' >>> class =3D serial bus >>> subclass =3D USB >>> none13@pci0:0:26:1: class=3D0x0c0300 card=3D0x000715d9 chip=3D0x3a38808= 6 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'USB UHCI Controller *5' >>> class =3D serial bus >>> subclass =3D USB >>> none14@pci0:0:26:2: class=3D0x0c0300 card=3D0x000715d9 chip=3D0x3a39808= 6 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'USB UHCI Controller *6' >>> class =3D serial bus >>> subclass =3D USB >>> none15@pci0:0:26:7: class=3D0x0c0320 card=3D0x000715d9 chip=3D0x3a3c808= 6 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'USB EHCI Controller *2' >>> class =3D serial bus >>> subclass =3D USB >>> none16@pci0:0:29:0: class=3D0x0c0300 card=3D0x000715d9 chip=3D0x3a34808= 6 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'USB UHCI Controller *1' >>> class =3D serial bus >>> subclass =3D USB >>> none17@pci0:0:29:1: class=3D0x0c0300 card=3D0x000715d9 chip=3D0x3a35808= 6 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'USB UHCI Controller *2' >>> class =3D serial bus >>> subclass =3D USB >>> none18@pci0:0:29:2: class=3D0x0c0300 card=3D0x000715d9 chip=3D0x3a36808= 6 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'USB UHCI Controller *3' >>> class =3D serial bus >>> subclass =3D USB >>> none19@pci0:0:29:7: class=3D0x0c0320 card=3D0x000715d9 chip=3D0x3a3a808= 6 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'USB EHCI Controller *1' >>> class =3D serial bus >>> subclass =3D USB >>> pcib6@pci0:0:30:0: class=3D0x060401 card=3D0x000715d9 chip=3D0x244e8086 >>> rev=3D0x90 >>> hdr=3D0x01 >>> vendor =3D 'Intel Corporation' >>> device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to = PCI >>> Bridge' >>> class =3D bridge >>> subclass =3D PCI-PCI >>> isab0@pci0:0:31:0: class=3D0x060100 card=3D0x000715d9 chip=3D0x3a188086 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'LPC Interface Controller' >>> class =3D bridge >>> subclass =3D PCI-ISA >>> atapci0@pci0:0:31:2: class=3D0x01018f card=3D0x000715d9 chip=3D0x3a2080= 86 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'SATA2(4Port2) (ICH10 Family)' >>> class =3D mass storage >>> subclass =3D ATA >>> bar [10] =3D type I/O Port, range 32, base 0xbc00, size 8, enabled >>> bar [14] =3D type I/O Port, range 32, base 0xb880, size 4, enabled >>> bar [18] =3D type I/O Port, range 32, base 0xb800, size 8, enabled >>> bar [1c] =3D type I/O Port, range 32, base 0xb480, size 4, enabled >>> bar [20] =3D type I/O Port, range 32, base 0xb400, size 16, enabled >>> bar [24] =3D type I/O Port, range 32, base 0xb080, size 16, enabled >>> none20@pci0:0:31:3: class=3D0x0c0500 card=3D0x000715d9 chip=3D0x3a30808= 6 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'SMB controller (50011458)' >>> class =3D serial bus >>> subclass =3D SMBus >>> bar [10] =3D type Memory, range 64, base 0xfbefa000, size 256, enabled >>> bar [20] =3D type I/O Port, range 32, base 0x400, size 32, enabled >>> atapci1@pci0:0:31:5: class=3D0x010185 card=3D0x000715d9 chip=3D0x3a2680= 86 >>> rev=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'SATA2(2Port2) (ICH10 Family)' >>> class =3D mass storage >>> subclass =3D ATA >>> bar [10] =3D type I/O Port, range 32, base 0xac00, size 8, enabled >>> bar [14] =3D type I/O Port, range 32, base 0xa880, size 4, enabled >>> bar [18] =3D type I/O Port, range 32, base 0xa800, size 8, enabled >>> bar [1c] =3D type I/O Port, range 32, base 0xa480, size 4, enabled >>> bar [20] =3D type I/O Port, range 32, base 0xa400, size 16, enabled >>> bar [24] =3D type I/O Port, range 32, base 0xa080, size 16, enabled >>> em0@pci0:1:0:0: class=3D0x020000 card=3D0x10d315d9 chip=3D0x10d38086 re= v=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'Intel 82574L Gigabit Ethernet Controller (82574L)' >>> class =3D network >>> subclass =3D ethernet >>> bar [10] =3D type Memory, range 32, base 0xfbbe0000, size 131072, enabl= ed >>> bar [18] =3D type I/O Port, range 32, base 0xcc00, size 32, enabled >>> bar [1c] =3D type Memory, range 32, base 0xfbbdc000, size 16384, enable= d >>> em1@pci0:2:0:0: class=3D0x020000 card=3D0x10d315d9 chip=3D0x10d38086 re= v=3D0x00 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> device =3D 'Intel 82574L Gigabit Ethernet Controller (82574L)' >>> class =3D network >>> subclass =3D ethernet >>> bar [10] =3D type Memory, range 32, base 0xfbce0000, size 131072, enabl= ed >>> bar [18] =3D type I/O Port, range 32, base 0xdc00, size 32, enabled >>> bar [1c] =3D type Memory, range 32, base 0xfbcdc000, size 16384, enable= d >>> mps0@pci0:4:0:0: class=3D0x010700 card=3D0x040015d9 chip=3D0x00721000 r= ev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'LSI Logic (Was: Symbios Logic, NCR)' >>> class =3D mass storage >>> subclass =3D SAS >>> bar [10] =3D type I/O Port, range 32, base 0xe000, size 256, enabled >>> bar [14] =3D type Memory, range 64, base 0xfbd3c000, size 16384, enable= d >>> bar [1c] =3D type Memory, range 64, base 0xfbd40000, size 262144, enabl= ed >>> vgapci0@pci0:6:1:0: class=3D0x030000 card=3D0x000715d9 chip=3D0x0532102= b >>> rev=3D0x0a >>> hdr=3D0x00 >>> vendor =3D 'Matrox Electronic Systems Ltd.' >>> class =3D display >>> subclass =3D VGA >>> bar [10] =3D type Prefetchable Memory, range 32, base 0xf9000000, size >>> 16777216, enabled >>> bar [14] =3D type Memory, range 32, base 0xfaffc000, size 16384, enable= d >>> bar [18] =3D type Memory, range 32, base 0xfb000000, size 8388608, enab= led >>> hostb1@pci0:255:0:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2c7080= 86 >>> rev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb2@pci0:255:0:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2d8180= 86 >>> rev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb3@pci0:255:2:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2d9080= 86 >>> rev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb4@pci0:255:2:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2d9180= 86 >>> rev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb5@pci0:255:2:2: class=3D0x060000 card=3D0x80868086 chip=3D0x2d9280= 86 >>> rev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb6@pci0:255:2:3: class=3D0x060000 card=3D0x80868086 chip=3D0x2d9380= 86 >>> rev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb7@pci0:255:2:4: class=3D0x060000 card=3D0x80868086 chip=3D0x2d9480= 86 >>> rev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb8@pci0:255:2:5: class=3D0x060000 card=3D0x80868086 chip=3D0x2d9580= 86 >>> rev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb9@pci0:255:3:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2d9880= 86 >>> rev=3D0x02 >>> hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb10@pci0:255:3:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2d998= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb11@pci0:255:3:2: class=3D0x060000 card=3D0x80868086 chip=3D0x2d9a8= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb12@pci0:255:3:4: class=3D0x060000 card=3D0x80868086 chip=3D0x2d9c8= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb13@pci0:255:4:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2da08= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb14@pci0:255:4:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2da18= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb15@pci0:255:4:2: class=3D0x060000 card=3D0x80868086 chip=3D0x2da28= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb16@pci0:255:4:3: class=3D0x060000 card=3D0x80868086 chip=3D0x2da38= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb17@pci0:255:5:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2da88= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb18@pci0:255:5:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2da98= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb19@pci0:255:5:2: class=3D0x060000 card=3D0x80868086 chip=3D0x2daa8= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb20@pci0:255:5:3: class=3D0x060000 card=3D0x80868086 chip=3D0x2dab8= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb21@pci0:255:6:0: class=3D0x060000 card=3D0x80868086 chip=3D0x2db08= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb22@pci0:255:6:1: class=3D0x060000 card=3D0x80868086 chip=3D0x2db18= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb23@pci0:255:6:2: class=3D0x060000 card=3D0x80868086 chip=3D0x2db28= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> hostb24@pci0:255:6:3: class=3D0x060000 card=3D0x80868086 chip=3D0x2db38= 086 >>> rev=3D0x02 hdr=3D0x00 >>> vendor =3D 'Intel Corporation' >>> class =3D bridge >>> subclass =3D HOST-PCI >>> >>> Thank you in advance sirs! >>> Jason Wolfe >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 19:55:50 2011 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 DF6D2106566B for ; Fri, 7 Oct 2011 19:55:50 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2CE8FC0A for ; Fri, 7 Oct 2011 19:55:50 +0000 (UTC) Received: by wwe3 with SMTP id 3so6095083wwe.31 for ; Fri, 07 Oct 2011 12:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HT0GK/YOSyljzCrowpXBjjWuSsc2dXc74cg7yDmpC4M=; b=jggbTwOOtXQ5ZzykJ2MaTMoTs4inblrEKamKEBqjqTU5UeD/Ee3G6TIko5izfYYzrt Y/Ew8y1uKddcp8u/p/ciQsZcYea1Zj0NORyAl6noyl6TFX9GARninrVb3AZx9vgWuQZi Zj5kNYcPsM9N/xobe6Bfqc33n24m1x2M83Moc= MIME-Version: 1.0 Received: by 10.227.195.13 with SMTP id ea13mr2851371wbb.36.1318017349142; Fri, 07 Oct 2011 12:55:49 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Fri, 7 Oct 2011 12:55:49 -0700 (PDT) In-Reply-To: <4E8F51D4.1060509@sentex.net> References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> Date: Fri, 7 Oct 2011 15:55:49 -0400 Message-ID: From: Arnaud Lacombe To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 19:55:51 -0000 Hi, On Fri, Oct 7, 2011 at 3:24 PM, Mike Tancsa wrote: > On 10/7/2011 2:59 PM, Jason Wolfe wrote: >> Mike, >> >> I had a large pool of servers running 7.2.3 with MSI-X enabled during my >> testing, but it didn't resolve the issue. I just pulled back the >> sys/dev/e1000 directory from 8-STABLE and ran it on 8-RELEASE-p2 though,= so >> if there were changes made outside of the actual driver code that helped= I >> may have not seen the benefit. It's possible the lagg is adding some >> complication, but when one of the interfaces wedge the lagg continues to >> operate over the other link (though half of the traffic simply fails). I= t >> appears the interface just runs out of one of its buffers, and is helple= ss >> to resolve it without a bounce. >> >> I do recall coming across the ASPM threads, but my Supermicro boards did= n't >> have the option and many people claimed it didn't resolve it, so I didn'= t >> follow through. I'll do a bit more digging there, thanks. >> >> Disabling MSI-X has without a doubt completely resolved my problem thoug= h. I >> would receive about 30 reports/failures a day from my servers when I was >> running with it, since disabling it I haven't received a single one in ~= 40 >> days. =A0The servers are currently running with the 7.2.3 driver also, s= o if >> nothing jumps out from my original email I'm happy to re enable it on a >> handful of servers and collect some fresh reports. > > Hi Jason, > =A0 =A0 =A0 =A0This sounds like a real drag :( =A0You certainly have WAY = more servers to > sample from than I do/did (a couple). The problem on my boxes were not > very frequent to start with, so it would take a while. But the symptoms > were very similar in that I would see queue overruns in the stats when > things were wedged. =A0I have other em nics (non 82574) that get the odd > overrun when they are busy, but they seem to recover from the situation > just fine. The 82574 did not. > > When you disable MSI-X, you mean via hw.pci.enable_msix=3D0 across the > board, or you disable multi-queue for the NIC, so it uses just one > interrupt, rather than separate ones for xmit and recv ? > em(4)'s multiqueue is misleading. By default, with MSI-X enabled, before AFAIK, April 2010 it used 2 (RX+TX) queue + 1, ie. 5 MSI-X vectors[0]. After April 2010, it uses 1 * (RX+TX) queue + 1, ie. 3 MSI-X vectors. There is no logic for the driver to use 1 vector with MSI-X enabled. As a side note, the only gain of EM_MULTIQUEUE, now, is to allow the driver to use the buf_ring(9) lockless queue API, compared to the locked ifq. Today, em(4) should waste about 16k of memory for when !EM_MULTIQUEUE. This is the memory, 4096 * sizeof(void *), allocated for the buf_ring(9) structure which is not used in the !EM_MULTIQUEUE case. > Also, what is the purpose of > hw.pci.do_power_nodriver=3D3 vs 0 (3 means put absolutely everything > in D3 state.) > > net.link.ifqmaxlen 1024 vs 50 (does anything else need to be adjusted of > this value is increased?) > He might as well try to enable EM_MULTIQUEUE. > hw.em.rxd=3D"2048" > hw.em.txd=3D"2048" > As it starts to be well known here, I am not a fan of bumping a limit to hide a bug. So I'd rather lower this to 512 or 256, and hope it triggers the issue more often, so that it could be diagnosticed and fixed for good. - Arnaud [0]: actually it depends on a field in the chip NVM, which can be up to 4 (0 based accounting, this would translate in 5 vectors), but happened to be 2 (3 vector) in 82574 I've got access to. Last time I checked, this setting could not be seen with the standard NVM dump sysctl, which limit the output's size. On those chip, the pre-April-2010 code would falls back on MSI even if 3 were available. > Have you tried leaving these two at the default on 7.2.3 ? > if_em.h implies 1024 for each. > > =A0 =A0 =A0 =A0---Mike > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada =A0 http://www.tancsa.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 Fri Oct 7 20:09:37 2011 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 1CE881065670 for ; Fri, 7 Oct 2011 20:09:37 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9E5D68FC08 for ; Fri, 7 Oct 2011 20:09:35 +0000 (UTC) Received: by wwe3 with SMTP id 3so6110749wwe.31 for ; Fri, 07 Oct 2011 13:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CtlW0YxKidBwcyty2yMeXtFmQ1QN8agRtnVSLB5biGY=; b=Q1YIL2OljbNd0h5CNy1ldLUaQnECyrWBPjXaEVU8q+Q2/IsXDUwMTl2ebiqKD7r31y DeAB9FSUHsbSUi1Bk1qHUFI1bm+arhqgTlyXUW9R2Ifs9VwYjZ/KGD4sIrPJWxAhl5PK u+s4YNr/8qDzO1dyOzmoYGfivu1Nb3VMzVnTM= MIME-Version: 1.0 Received: by 10.216.21.74 with SMTP id q52mr1250717weq.36.1318018174330; Fri, 07 Oct 2011 13:09:34 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Fri, 7 Oct 2011 13:09:34 -0700 (PDT) In-Reply-To: <20111007191154.GB11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> Date: Fri, 7 Oct 2011 16:09:34 -0400 Message-ID: From: Arnaud Lacombe To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , David Christensen , Pyun YongHyeon , Sean Bruno , "davidch@freebsd.org" Subject: Re: bce(4) with IPMI 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, 07 Oct 2011 20:09:37 -0000 Hi, On Fri, Oct 7, 2011 at 3:11 PM, YongHyeon PYUN wrote: > On Mon, Oct 03, 2011 at 04:06:18PM -0700, Sean Bruno wrote: >> On Mon, 2011-10-03 at 15:30 -0700, David Christensen wrote: >> > > > > I should probably say, this is freebsd7. =A0So I'll peruse the >> > > changelogs >> > > > > and see if 7 is missing something here. >> > > > > >> > > > > sean >> > > > >> > > > commenting this change out seems to be helping quite a bit with my >> > > > issue. =A0I think that this behavior may be wrong in the IPMI shar= ed/nic >> > > > case. =A0Thoughts? >> > > > >> > > > >> > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=3D210261= &r2=3D210263 >> > > >> > >> > The main reason bce(4) needs to coordinate with NC-SI/IPMI >> > firmware is to make sure only one software entity manipulates >> > PHY registers. =A0When bce(4) is loaded it will have priority >> > over firmware (e.g. autoneg, speed, and duplex settings will >> > be set by the host). =A0If you don't bring up the interface in >> > the host the firmware isn't authorized to do so, which sounds >> > like your problem. >> > >> > Current bce(4) behavior notifies firmware that host driver >> > is running when resetting the device in bce_attach(). =A0We >> > tell firmware that host driver is still running through >> > bce_pulse(). =A0Not sure how to handle the FreeBSD model where >> > the driver load doesn't immediately bring the link up. >> > >> > Dave >> > >> >> Hrm, understood. >> >> What are your thoughts on noting that the IPMI f/w is running and >> leaving the interface up? =A0I'm poking around trying to find the right >> register bits at initialization to see that this is the case. >> > > How about disabling bce_pulse() for IPMI interface? I guess this > may result in not sending heart beat from driver to firmware such > that firmware may take over control back from driver. > The problem of the approach would be we don't know whether IPMI is > active in driver at attach time and we may need some way to take > control back from firmware once admin changed his/her mind to use > the controller as a normal interface. > >> What's even more strange is that our freebsd6 instances don't have this >> problem. >> > > Can't explain either but probably stable/6 bce(4) may have used old > firmware. > I may look ignorant, but shouldn't the link between the BCM and the MAC/PHY be totally independent from any OS involvement ? The BCM should still be able to communicate with the outer world even if the OS badly screw the NIC configuration, as long as the BCM is alive. - Arnaud From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 20:12:40 2011 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 3F209106566B for ; Fri, 7 Oct 2011 20:12:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id DAA198FC12 for ; Fri, 7 Oct 2011 20:12:39 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id p97KCaMG071927; Fri, 7 Oct 2011 16:12:36 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E8F5D28.2050109@sentex.net> Date: Fri, 07 Oct 2011 16:12:24 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 20:12:40 -0000 On 10/7/2011 3:55 PM, Arnaud Lacombe wrote: >> When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the >> board, or you disable multi-queue for the NIC, so it uses just one >> interrupt, rather than separate ones for xmit and recv ? >> > em(4)'s multiqueue is misleading. By default, with MSI-X enabled, > before AFAIK, April 2010 it used 2 (RX+TX) queue + 1, ie. 5 MSI-X > vectors[0]. After April 2010, it uses 1 * (RX+TX) queue + 1, ie. 3 > MSI-X vectors. There is no logic for the driver to use 1 vector with > MSI-X enabled. Hi, Very poor choice of wording on my part. I meant to say separate interrupts for the xmit and recv, as opposed to multiqueue which is quite different. On the server I used to see the issue with, it has 2 onboard NICs em0: port 0x4040-0x405f mem 0xb4500000-0xb451ffff,0xb4525000-0xb4525fff irq 16 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:ed:68:a5 em1: port 0x2000-0x201f mem 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:ed:68:a4 irq257: em0 506496667 813 irq258: em1:rx 0 296438098 476 irq259: em1:tx 0 252033695 404 Actually, I see it in Jason's email now that I re-read it. hw.em.enable_msix="0" However, with 7.1.9 this setting did not help me. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 20:15:29 2011 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 D43C41065741; Fri, 7 Oct 2011 20:15:29 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 9357A8FC13; Fri, 7 Oct 2011 20:15:29 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p97KBoV5011917; Fri, 7 Oct 2011 13:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318018311; bh=fXm8m94+WD1M0MRrCwz+8qByJKvMffJSYHFYTQPnVH0=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=Vt8EAbAK+Byy3Zs1InxLYbVJVWxv5uoZ/CqAxAd6SdatIJgxoPRfhZ6oparMMm4xB AuXjcVjnQ8hsI1W57RrtcXwjpajxm3D2PkufpDF3KKEZ0FvRyZPHehO9cvNyQ93ZB0 4zN+0LxUAMaycVOmQd1YbrzXf1KFIDmgZmaUiveM= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20111007191154.GB11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 Oct 2011 13:11:50 -0700 Message-ID: <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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, 07 Oct 2011 20:15:29 -0000 On Fri, 2011-10-07 at 12:11 -0700, YongHyeon PYUN wrote: > > What's even more strange is that our freebsd6 instances don't have > this > > problem. > > > > Can't explain either but probably stable/6 bce(4) may have used old > firmware. Ok, I can once again reach the IPMI controller if I remove this: http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210263&r2=210262&pathrev=210263 Since the driver has control over the interface, not "upping" the interface media causes the IPMI controller to not be able to access the network. Ugh. Sean From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 20:26:36 2011 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 97B2D106566B for ; Fri, 7 Oct 2011 20:26:36 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 302988FC08 for ; Fri, 7 Oct 2011 20:26:35 +0000 (UTC) Received: by wwe3 with SMTP id 3so6131309wwe.31 for ; Fri, 07 Oct 2011 13:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ipWcgC1TQfH6X6Ku07aEMbcDhSfE9ZbcBodnoMhnAaU=; b=GoQOi7C+3/32xQXsDykyJpt4yAhF4I2kL3iyeMv87iCTBW/T4XuU7TYjSV8kKlHZ5/ UDaHMW4V1Ed30A8cO+8UCxsnfQ99r3z1aITAPctBxoUTr2xqWJ1/WceyH5PpkoNo5Q6g z9cBXakNJWSmHFlx4xkhVv/aGVDJ4G/NRGrIc= MIME-Version: 1.0 Received: by 10.227.153.211 with SMTP id l19mr2913414wbw.51.1318019195230; Fri, 07 Oct 2011 13:26:35 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Fri, 7 Oct 2011 13:26:35 -0700 (PDT) In-Reply-To: <4E8F5D28.2050109@sentex.net> References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4E8F5D28.2050109@sentex.net> Date: Fri, 7 Oct 2011 16:26:35 -0400 Message-ID: From: Arnaud Lacombe To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 20:26:36 -0000 Hi, On Fri, Oct 7, 2011 at 4:12 PM, Mike Tancsa wrote: > On 10/7/2011 3:55 PM, Arnaud Lacombe wrote: >>> When you disable MSI-X, you mean via hw.pci.enable_msix=3D0 across the >>> board, or you disable multi-queue for the NIC, so it uses just one >>> interrupt, rather than separate ones for xmit and recv ? >>> >> em(4)'s multiqueue is misleading. By default, with MSI-X enabled, >> before AFAIK, April 2010 it used 2 (RX+TX) queue + 1, ie. 5 MSI-X >> vectors[0]. After April 2010, it uses 1 * (RX+TX) queue + =A01, ie. 3 >> MSI-X vectors. There is no logic for the driver to use 1 vector with >> MSI-X enabled. > > Hi, > =A0 =A0 =A0 =A0Very poor choice of wording on my part. I meant to say sep= arate > interrupts for the xmit and recv, as opposed to multiqueue which is > quite different. > > On the server I used to see the issue with, it has 2 onboard NICs > > em0: port 0x4040-0x405f mem > 0xb4500000-0xb451ffff,0xb4525000-0xb4525fff irq 16 at device 25.0 on pci0 > em0: Using an MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:ed:68:a5 > > em1: port 0x2000-0x201f mem > 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci11 > em1: Using MSIX interrupts with 3 vectors > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: Ethernet address: 00:15:17:ed:68:a4 > I'd assume that `em0' is not a 82574, whereas `em1' is. - Arnaud > irq257: em0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0506496667 =A0 =A0 =A0 = =A0813 > irq258: em1:rx 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 296438098 =A0 =A0 =A0 =A0476 > irq259: em1:tx 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 252033695 =A0 =A0 =A0 =A0404 > > Actually, I see it in Jason's email now that I re-read it. > hw.em.enable_msix=3D"0" > > However, with 7.1.9 this setting did not help me. > > > =A0 =A0 =A0 =A0---Mike > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada =A0 http://www.tancsa.com/ > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 20:36:28 2011 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 B10E61065672 for ; Fri, 7 Oct 2011 20:36:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 702698FC0A for ; Fri, 7 Oct 2011 20:36:28 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id p97KaOSx075616; Fri, 7 Oct 2011 16:36:25 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E8F62BC.1030802@sentex.net> Date: Fri, 07 Oct 2011 16:36:12 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4E8F5D28.2050109@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 20:36:28 -0000 On 10/7/2011 4:26 PM, Arnaud Lacombe wrote: >> em0: port 0x4040-0x405f mem >> 0xb4500000-0xb451ffff,0xb4525000-0xb4525fff irq 16 at device 25.0 on pci0 >> em0: Using an MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:15:17:ed:68:a5 >> >> em1: port 0x2000-0x201f mem >> 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci11 >> em1: Using MSIX interrupts with 3 vectors >> em1: [ITHREAD] >> em1: [ITHREAD] >> em1: [ITHREAD] >> em1: Ethernet address: 00:15:17:ed:68:a4 >> > I'd assume that `em0' is not a 82574, whereas `em1' is. Correct. It was em1 that used to wedge for me. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 20:46:38 2011 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 3FD4C1065670 for ; Fri, 7 Oct 2011 20:46:38 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3B5F28FC0A for ; Fri, 7 Oct 2011 20:46:37 +0000 (UTC) Received: by eyz10 with SMTP id 10so2560099eyz.13 for ; Fri, 07 Oct 2011 13:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=coXeA/dl7SNWjrSElTq+unz7XuCoEnbn9iI2ijwoKnM=; b=eRhGkAWx1FWQecVnPCtUYxT0onAAxikRas2vY07vX1/ZS2a93Q+wrQhiQzNvZlwAkI zLtp5Cqy/4bhCKHhZq1jyrhYE9GjTxGB3bhXVgBFA10WDuuvc0hGVcv7pFhUPk7ko3R2 NQit6W66hso4R2AlHLdbP3IrV0dJ7vkUNSPOY= MIME-Version: 1.0 Received: by 10.223.58.83 with SMTP id f19mr13046211fah.36.1318020396263; Fri, 07 Oct 2011 13:46:36 -0700 (PDT) Received: by 10.152.36.102 with HTTP; Fri, 7 Oct 2011 13:46:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Oct 2011 13:46:36 -0700 Message-ID: From: Jason Wolfe To: Arnaud Lacombe 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 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 20:46:38 -0000 On Fri, Oct 7, 2011 at 12:24 PM, Arnaud Lacombe wrote: > Hi, > > On Fri, Oct 7, 2011 at 2:57 PM, Jason Wolfe wrote: > > Jack, > > > > Entirely possible there are multiple moving pieces here, the only bit I > know > > for certain is it's related to the different operation when running with > MSI > > vs MSI-X. Here is also my loader.conf for reference. I'm currently > running > > the modular congestion control stuff with cubic in use, but these issues > > predate those changes also. Just to give you a scope of it though, it was > > somewhat 'rare' for them to wedge. Out of a pool of ~2000 servers running > > with the 82574L doing ~800Mb/s average, there were ~220 reports in a > week. > > So with some fuzzy math to put it in the same terms you were talking in, > a > > server in particular would hang about once every 9 weeks. > > > Just a two questions out of my mind: > > Are the failing server evenly distributed, or always the same are failing ? > > Did you collect the uptime and the kernel msgbuf of the server when > the issue triggered ? > > Thanks, > - Arnaud > Arnaud, The failures were pretty random, though there were a handful of servers that did fail a couple times. It didn't seem attributable to a certain batch or physical location. The uptime was not collected, but most were in the ballpark of 30-90 days. I was tailing /var/log/messages, but didn't save kern.msgbuf no. I've added both of these to the collections and pulled a couple that did fail more than once and will be re enabling MSI-X on them later today. Jason From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 20:54:56 2011 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 463841065687; Fri, 7 Oct 2011 20:54:56 +0000 (UTC) (envelope-from pyunyh@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 7734A8FC0C; Fri, 7 Oct 2011 20:54:55 +0000 (UTC) Received: by wyj26 with SMTP id 26so5907275wyj.13 for ; Fri, 07 Oct 2011 13:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=cl6jY3s8zUxj0DHRNO0HM/oaXFqlK62nI4eZQun67vs=; b=BqmAniR62r5xmLPOKI4EMDenrGnuDjzGl0+KnvxpaUMJNk2REBJ3M9cgT/8lqghptt t5JyFeE17SomTbX3VbYp1TTUWDxdZByRIsZ8RhKCOYR1VWjf4+luP+eXVI8PfgLWjZyc YNmoeOTRWtShWTXQ0+2Zr2bZI4Nu9LSD4nmr0= Received: by 10.216.137.84 with SMTP id x62mr1236433wei.107.1318020894457; Fri, 07 Oct 2011 13:54:54 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id es5sm18104950wbb.11.2011.10.07.13.54.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 13:54:53 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Oct 2011 13:52:54 -0700 From: YongHyeon PYUN Date: Fri, 7 Oct 2011 13:52:54 -0700 To: Sean Bruno Message-ID: <20111007205254.GC11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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: Fri, 07 Oct 2011 20:54:56 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 07, 2011 at 01:11:50PM -0700, Sean Bruno wrote: > On Fri, 2011-10-07 at 12:11 -0700, YongHyeon PYUN wrote: > > > What's even more strange is that our freebsd6 instances don't have > > this > > > problem. > > > > > > > Can't explain either but probably stable/6 bce(4) may have used old > > firmware. > > Ok, I can once again reach the IPMI controller if I remove this: > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210263&r2=210262&pathrev=210263 > > Since the driver has control over the interface, not "upping" the > interface media causes the IPMI controller to not be able to access the > network. Ugh. > Hmm, it seems the firmware relies on driver to establish a link such that blindly disabling PHY access in DOWN state seem to make firmware believe that there is a no established link. Could you try attached patch? > Sean > --0OAP2g/MAC+5xKAE Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bce.mfm.diff" Index: sys/dev/bce/if_bce.c =================================================================== --- sys/dev/bce/if_bce.c (revision 226114) +++ sys/dev/bce/if_bce.c (working copy) @@ -6180,7 +6180,8 @@ BCE_LOCK(sc); - if ((ifp->if_flags & IFF_UP) == 0) { + if ((ifp->if_flags & IFF_UP) == 0 && + (sc->bce_flags & BCE_MFW_ENABLE_FLAG) == 0) { BCE_UNLOCK(sc); return; } --0OAP2g/MAC+5xKAE-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 20:57:13 2011 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 97445106566B; Fri, 7 Oct 2011 20:57:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id BD6588FC0C; Fri, 7 Oct 2011 20:57:12 +0000 (UTC) Received: by wwn22 with SMTP id 22so1465175wwn.1 for ; Fri, 07 Oct 2011 13:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=ghvu2UWPuGiPxpZqYRs68yC8TKLEqJr5F2tLNNd/tIs=; b=umnrDAY8FCnma7Re2uBCr5/WuOF211EPbL6Kb08CRPxZnSD5K3yefu4NWEHv4eY+yC EM1Revzp70Bof4Otbyu5Da+QchgGt7HyGLe0UqErdSQ2sHFZ3wR1DnkFNtYTKni0kYvC 3U3IszC1aw83BtdP/EBG0qTJLJrbA3vHsmgKU= Received: by 10.216.9.216 with SMTP id 66mr1360106wet.7.1318021031507; Fri, 07 Oct 2011 13:57:11 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id fo7sm18076386wbb.20.2011.10.07.13.57.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 13:57:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Oct 2011 13:55:10 -0700 From: YongHyeon PYUN Date: Fri, 7 Oct 2011 13:55:10 -0700 To: Arnaud Lacombe Message-ID: <20111007205510.GD11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , Pyun YongHyeon , Sean Bruno , "davidch@freebsd.org" Subject: Re: bce(4) with IPMI 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: Fri, 07 Oct 2011 20:57:13 -0000 On Fri, Oct 07, 2011 at 04:09:34PM -0400, Arnaud Lacombe wrote: > Hi, > > On Fri, Oct 7, 2011 at 3:11 PM, YongHyeon PYUN wrote: > > On Mon, Oct 03, 2011 at 04:06:18PM -0700, Sean Bruno wrote: > >> On Mon, 2011-10-03 at 15:30 -0700, David Christensen wrote: > >> > > > > I should probably say, this is freebsd7. ?So I'll peruse the > >> > > changelogs > >> > > > > and see if 7 is missing something here. > >> > > > > > >> > > > > sean > >> > > > > >> > > > commenting this change out seems to be helping quite a bit with my > >> > > > issue. ?I think that this behavior may be wrong in the IPMI shared/nic > >> > > > case. ?Thoughts? > >> > > > > >> > > > > >> > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210261&r2=210263 > >> > > > >> > > >> > The main reason bce(4) needs to coordinate with NC-SI/IPMI > >> > firmware is to make sure only one software entity manipulates > >> > PHY registers. ?When bce(4) is loaded it will have priority > >> > over firmware (e.g. autoneg, speed, and duplex settings will > >> > be set by the host). ?If you don't bring up the interface in > >> > the host the firmware isn't authorized to do so, which sounds > >> > like your problem. > >> > > >> > Current bce(4) behavior notifies firmware that host driver > >> > is running when resetting the device in bce_attach(). ?We > >> > tell firmware that host driver is still running through > >> > bce_pulse(). ?Not sure how to handle the FreeBSD model where > >> > the driver load doesn't immediately bring the link up. > >> > > >> > Dave > >> > > >> > >> Hrm, understood. > >> > >> What are your thoughts on noting that the IPMI f/w is running and > >> leaving the interface up? ?I'm poking around trying to find the right > >> register bits at initialization to see that this is the case. > >> > > > > How about disabling bce_pulse() for IPMI interface? I guess this > > may result in not sending heart beat from driver to firmware such > > that firmware may take over control back from driver. > > The problem of the approach would be we don't know whether IPMI is > > active in driver at attach time and we may need some way to take > > control back from firmware once admin changed his/her mind to use > > the controller as a normal interface. > > > >> What's even more strange is that our freebsd6 instances don't have this > >> problem. > >> > > > > Can't explain either but probably stable/6 bce(4) may have used old > > firmware. > > > I may look ignorant, but shouldn't the link between the BCM and the > MAC/PHY be totally independent from any OS involvement ? The BCM > should still be able to communicate with the outer world even if the > OS badly screw the NIC configuration, as long as the BCM is alive. > Correct. I just wanted to know the effect of bce_pulse() because I don't have bce(4) controllers with management firmware. > - Arnaud > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 21:06:47 2011 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 94E76106564A for ; Fri, 7 Oct 2011 21:06:47 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 505168FC08 for ; Fri, 7 Oct 2011 21:06:47 +0000 (UTC) Received: by ggeq3 with SMTP id q3so3943596gge.13 for ; Fri, 07 Oct 2011 14:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=r2Sbj6L/ZuiVQPgxozREOYrCpcetrYQv9nfjUrmN1OM=; b=OpvWAHEtTDpelR75syTSxcb0KJ2+G8wkmKRcgLyJVLmlXLTLGIf43+vNYoIrEp0LzP H1wSz714bo9zSZ2KOp9HcAaanZ2kWGaJm0pEDPZcs6JvIiU6zU4aFCNiWDfB9DNUp071 Ss2xCIYNHs9n42Na6FsKNa+L+yHVuy0hGSb4I= MIME-Version: 1.0 Received: by 10.223.5.139 with SMTP id 11mr13139117fav.21.1318021606067; Fri, 07 Oct 2011 14:06:46 -0700 (PDT) Received: by 10.152.36.102 with HTTP; Fri, 7 Oct 2011 14:06:45 -0700 (PDT) In-Reply-To: References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> Date: Fri, 7 Oct 2011 14:06:45 -0700 Message-ID: From: Jason Wolfe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 21:06:47 -0000 On Fri, Oct 7, 2011 at 12:55 PM, Arnaud Lacombe wrote: > Hi, > > On Fri, Oct 7, 2011 at 3:24 PM, Mike Tancsa wrote: > > When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the > > board, or you disable multi-queue for the NIC, so it uses just one > > interrupt, rather than separate ones for xmit and recv ? > As noticed it was the prior, all were disabled via hw.em.enable_msix=0 em(4)'s multiqueue is misleading. By default, with MSI-X enabled, > before AFAIK, April 2010 it used 2 (RX+TX) queue + 1, ie. 5 MSI-X > vectors[0]. After April 2010, it uses 1 * (RX+TX) queue + 1, ie. 3 > MSI-X vectors. There is no logic for the driver to use 1 vector with > MSI-X enabled. > > As a side note, the only gain of EM_MULTIQUEUE, now, is to allow the > driver to use the buf_ring(9) lockless queue API, compared to the > locked ifq. Today, em(4) should waste about 16k of memory for when > !EM_MULTIQUEUE. This is the memory, 4096 * sizeof(void *), allocated > for the buf_ring(9) structure which is not used in the !EM_MULTIQUEUE > case. > > > Also, what is the purpose of > > hw.pci.do_power_nodriver=3 vs 0 (3 means put absolutely everything > > in D3 state.) > 0 is the default state and means no 'power management' is done. My stripped down kernels don't have usb support so '3' just reduces the consumption by not powering those devices. If you load up the modules power will be supplied and the devices function. > > > > net.link.ifqmaxlen 1024 vs 50 (does anything else need to be adjusted of > > this value is increased?) > I haven't seen any evidence that there are other supporting adjustments for this, this was actually something I stumbled across while researching the issue. > > He might as well try to enable EM_MULTIQUEUE. > > > hw.em.rxd="2048" > > hw.em.txd="2048" > > > As it starts to be well known here, I am not a fan of bumping a limit > to hide a bug. So I'd rather lower this to 512 or 256, and hope it > triggers the issue more often, so that it could be diagnosticed and > fixed for good. > > - Arnaud > > [0]: actually it depends on a field in the chip NVM, which can be up > to 4 (0 based accounting, this would translate in 5 vectors), but > happened to be 2 (3 vector) in 82574 I've got access to. Last time I > checked, this setting could not be seen with the standard NVM dump > sysctl, which limit the output's size. On those chip, the > pre-April-2010 code would falls back on MSI even if 3 were available. > > > Have you tried leaving these two at the default on 7.2.3 ? > > if_em.h implies 1024 for each. > > > > ---Mike > Bumping rx/tx descriptors to 2048 was actually for performance reasons and not to try to get around the issue. I did some fairly in depth testing and found under heavy load it performed the best with those settings. As mentioned on the other thread I'll re enable MSI-X on a few servers here and collect uptime and the kernel msgbuf in addition. I'll bump the descriptors down to 512 to try and increase our chances and compile the driver with EM_MULTIQUEUE also. Jason From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 21:14:54 2011 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 84F341065678 for ; Fri, 7 Oct 2011 21:14:54 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07B918FC0A for ; Fri, 7 Oct 2011 21:14:53 +0000 (UTC) Received: by eyz10 with SMTP id 10so2588449eyz.13 for ; Fri, 07 Oct 2011 14:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PWh9CYKNNP3Ej9k+j/P1/zLD/GnUyMYJcQxoEN8BBSQ=; b=kLMT+UMTecpcI1+M/AyMcaR43kLHQDEt3JgVO6TTChVVpzc2JaceCrk5DjExDQdPTt hKQh1vReMM0E75ZqwTkggHp7rYlOtmjSIGRGzY2KEB64JlNAgQE/Nx4BkZTncgIlYo4V FvH8tAKCWhagvjFxF497Av+Ro8bk2MyxgNN9I= MIME-Version: 1.0 Received: by 10.223.76.11 with SMTP id a11mr8142487fak.1.1318022092759; Fri, 07 Oct 2011 14:14:52 -0700 (PDT) Received: by 10.152.36.102 with HTTP; Fri, 7 Oct 2011 14:14:52 -0700 (PDT) In-Reply-To: References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> Date: Fri, 7 Oct 2011 14:14:52 -0700 Message-ID: From: Jason Wolfe To: Mike Tancsa , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Oct 2011 21:14:54 -0000 On Fri, Oct 7, 2011 at 12:55 PM, Arnaud Lacombe wrote: > Hi, > > On Fri, Oct 7, 2011 at 3:24 PM, Mike Tancsa wrote: > > When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the > > board, or you disable multi-queue for the NIC, so it uses just one > > interrupt, rather than separate ones for xmit and recv ? > > > As noticed it was the prior, all were disabled via hw.em.enable_msix=0 > em(4)'s multiqueue is misleading. By default, with MSI-X enabled, > before AFAIK, April 2010 it used 2 (RX+TX) queue + 1, ie. 5 MSI-X > vectors[0]. After April 2010, it uses 1 * (RX+TX) queue + 1, ie. 3 > MSI-X vectors. There is no logic for the driver to use 1 vector with > MSI-X enabled. > > As a side note, the only gain of EM_MULTIQUEUE, now, is to allow the > driver to use the buf_ring(9) lockless queue API, compared to the > locked ifq. Today, em(4) should waste about 16k of memory for when > !EM_MULTIQUEUE. This is the memory, 4096 * sizeof(void *), allocated > for the buf_ring(9) structure which is not used in the !EM_MULTIQUEUE > case. > > > Also, what is the purpose of > > hw.pci.do_power_nodriver=3 vs 0 (3 means put absolutely everything > > in D3 state.) > 0 is the default state and means no 'power management' is done. My stripped down kernels don't have usb support so '3' just reduces the consumption by not powering those devices. If you load up the modules power will be supplied and the devices function. > > > > net.link.ifqmaxlen 1024 vs 50 (does anything else need to be adjusted of > > this value is increased?) > I haven't seen any evidence that there are other supporting adjustments for this, this was actually something I stumbled across while researching the issue. > > > He might as well try to enable EM_MULTIQUEUE. > > > hw.em.rxd="2048" > > hw.em.txd="2048" > > > As it starts to be well known here, I am not a fan of bumping a limit > to hide a bug. So I'd rather lower this to 512 or 256, and hope it > triggers the issue more often, so that it could be diagnosticed and > fixed for good. > > - Arnaud > > [0]: actually it depends on a field in the chip NVM, which can be up > to 4 (0 based accounting, this would translate in 5 vectors), but > happened to be 2 (3 vector) in 82574 I've got access to. Last time I > checked, this setting could not be seen with the standard NVM dump > sysctl, which limit the output's size. On those chip, the > pre-April-2010 code would falls back on MSI even if 3 were available. > > > Have you tried leaving these two at the default on 7.2.3 ? > > if_em.h implies 1024 for each. > > > > ---Mike > Bumping rx/tx descriptors to 2048 was actually for performance reasons and not to try to get around the issue. I did some fairly in depth testing and found under heavy load it performed the best with those settings. As mentioned on the other thread I'll re enable MSI-X on a few servers here and collect uptime and the kernel msgbuf in addition. I'll bump the descriptors down to 512 to try and increase our chances and compile the driver with EM_MULTIQUEUE also. Jason From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 21:22:39 2011 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 014A9106566C; Fri, 7 Oct 2011 21:22:39 +0000 (UTC) (envelope-from kwm@rainbow-runner.nl) Received: from cpsmtpb-lite02.kpnxchange.com (cpsmtpb-lite02.kpnxchange.com [213.75.38.72]) by mx1.freebsd.org (Postfix) with ESMTP id 468378FC17; Fri, 7 Oct 2011 21:22:37 +0000 (UTC) Received: from cpbrm-lite02.kpnxchange.com ([10.94.80.88]) by cpsmtpb-lite02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 23:05:33 +0200 Received: from mailrelay.hotspotsvankpn.com ([82.94.177.187]) by cpbrm-lite02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 23:05:32 +0200 X-Virus-Scanned: amavisd-new at hotspotsvankpn.com Received: from [212.238.113.178] (ip212-238-113-178.hotspotsvankpn.com [212.238.113.178]) by mailrelay.hotspotsvankpn.com (Postfix) with ESMTP id 2FC6512080EC; Fri, 7 Oct 2011 23:05:32 +0200 (CEST) Message-ID: <1318021531.2596.6.camel@crashalot.rainbow-runner.nl> From: Koop Mast To: Adrian Chadd Date: Fri, 07 Oct 2011 23:05:31 +0200 Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.2.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-OriginalArrivalTime: 07 Oct 2011 21:05:32.0911 (UTC) FILETIME=[D9FFB7F0:01CC8534] X-RcptDomain: FreeBSD.org Cc: freebsd-net@freebsd.org Subject: wireless lor with ath chip. 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, 07 Oct 2011 21:22:39 -0000 Hello, I don't know if this is a atheros problem or a more general problem. But since it happens with my atheros chip, here it goes. I don't have any problem with normal operation. But when I run "sh /etc/rc.d/netif restart" I get the lor below. (the wierd freebsd version is because 10.0 breaks a lot of ports. but yes it is head.) -Koop FreeBSD crashalot.rainbow-runner.nl 9.99-CURRENT FreeBSD 9.99-CURRENT #24 r226046M: Fri Oct 7 00:40:56 CEST 2011 root@crashalot.rainbow-runner.nl:/usr/obj/usr/src/sys/Sparkel amd64 lock order reversal: 1st 0xfffffe000600fbc0 if_afdata (if_afdata) @ /usr/src/sys/netinet/if_ether.c:312 2nd 0xfffffe0004d5b8f8 radix node head (radix node head) @ /usr/src/sys/net/route.c:354 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff802c31da = db_trace_self_wrapper +0x2a kdb_backtrace() at 0xffffffff804ada57 = kdb_backtrace+0x37 _witness_debugger() at 0xffffffff804c3e1e = _witness_debugger+0x2e witness_checkorder() at 0xffffffff804c50c7 = witness_checkorder+0x807 _rw_rlock() at 0xffffffff8047419d = _rw_rlock+0x6d rtalloc1_fib() at 0xffffffff80542c3c = rtalloc1_fib+0x11c in_lltable_lookup() at 0xffffffff8058b4fd = in_lltable_lookup+0xbd arpresolve() at 0xffffffff805848fb = arpresolve+0x1eb ether_output() at 0xffffffff80535e8f = ether_output+0x25f ip_output() at 0xffffffff805a03f2 = ip_output+0xc42 udp_send() at 0xffffffff806182f6 = udp_send+0x496 sosend_dgram() at 0xffffffff804e957e = sosend_dgram+0x21e kern_sendit() at 0xffffffff804f089f = kern_sendit+0x1af sendit() at 0xffffffff804f0afc = sendit+0xdc sys_sendto() at 0xffffffff804f0bed = sys_sendto+0x4d amd64_syscall() at 0xffffffff80706a88 = amd64_syscall+0x478 Xfast_syscall() at 0xffffffff806f1697 = Xfast_syscall+0xf7 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x2cf523cc, rsp = 0x7fffffffb448, rbp = 0x2d1bb8f4 --- From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 21:23:24 2011 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 7A5FF106578E for ; Fri, 7 Oct 2011 21:23:24 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 2CD868FC16 for ; Fri, 7 Oct 2011 21:23:23 +0000 (UTC) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 Oct 2011 14:30:12 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Fri, 7 Oct 2011 14:23:12 -0700 From: "David Christensen" To: "pyunyh@gmail.com" , "Sean Bruno" Date: Fri, 7 Oct 2011 14:23:10 -0700 Thread-Topic: bce(4) with IPMI [puzzling and puzzling] Thread-Index: AcyFGhZ36KagjITUQLqTNNWcYW1qhQAHR3+Q Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F35B561B@IRVEXCHCCR01.corp.ad.broadcom.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> <1318004610.27029.1.camel@hitfishpass-lx.corp.yahoo.com> <20111007175137.GA11808@michelle.cdnetworks.com> In-Reply-To: <20111007175137.GA11808@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6291B0EE3JW2527661-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Pyun YongHyeon Subject: RE: bce(4) with IPMI [puzzling and puzzling] 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, 07 Oct 2011 21:23:24 -0000 > > so, I cracked open my R410 this morning to see what the Ethernet > chipset > > had for a indentification mark. It is definitely stamped as a > BCM5716, > > so I'm confused. > > > > bce(4) has code to handle the 5716 chipset, but its never being > executed > > AFAIK. What's going on here? > > >=20 > I guess BCE_CHIP_NUM() returns 0x5709 for 5709 and 5716 > controllers. I don't know why bce(4) explicitly checks 5716 from > the BCE_MISC_ID register. Public data sheet indicates CHIP_NUM bits > have 0x5909 for 5716(NetXtremeII-PG203-R pp229). > To me 5716 is virtually the same as 5709 except for not supporting > TOE and iSCSI offloading. >=20 That's a typo then, 5709 and 5716 share the same ASIC ID. Dave From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 21:23:44 2011 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 8B870106564A for ; Fri, 7 Oct 2011 21:23:44 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6C88FC12 for ; Fri, 7 Oct 2011 21:23:44 +0000 (UTC) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 Oct 2011 14:23:21 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Fri, 7 Oct 2011 14:17:08 -0700 From: "David Christensen" To: "Sean Bruno" , "pyunyh@gmail.com" Date: Fri, 7 Oct 2011 14:17:06 -0700 Thread-Topic: bce(4) with IPMI Thread-Index: AcyFLeH5qoqSZ1CiQhCAMwEmJweiXAAB6eBw Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F35B5613@IRVEXCHCCR01.corp.ad.broadcom.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6291B2433KO28556028-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: "freebsd-net@freebsd.org" , "davidch@freebsd.org" , Pyun YongHyeon Subject: RE: bce(4) with IPMI 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, 07 Oct 2011 21:23:44 -0000 PiA+IENhbid0IGV4cGxhaW4gZWl0aGVyIGJ1dCBwcm9iYWJseSBzdGFibGUvNiBiY2UoNCkgbWF5 IGhhdmUgdXNlZCBvbGQNCj4gPiBmaXJtd2FyZS4NCj4gDQo+IE9rLCBJIGNhbiBvbmNlIGFnYWlu IHJlYWNoIHRoZSBJUE1JIGNvbnRyb2xsZXIgaWYgSSByZW1vdmUgdGhpczoNCj4gDQo+IGh0dHA6 Ly9zdm53ZWIuZnJlZWJzZC5vcmcvYmFzZS9oZWFkL3N5cy9kZXYvYmNlL2lmX2JjZS5jP3IxPTIx MDI2MyZyMj0yMQ0KPiAwMjYyJnBhdGhyZXY9MjEwMjYzDQo+IA0KPiBTaW5jZSB0aGUgZHJpdmVy IGhhcyBjb250cm9sIG92ZXIgdGhlIGludGVyZmFjZSwgbm90ICJ1cHBpbmciIHRoZQ0KPiBpbnRl cmZhY2UgbWVkaWEgY2F1c2VzIHRoZSBJUE1JIGNvbnRyb2xsZXIgdG8gbm90IGJlIGFibGUgdG8g YWNjZXNzIHRoZQ0KPiBuZXR3b3JrLiAgVWdoLg0KPiANCg0KVGhhdCdzIHRoZSBjdXJyZW50IGRl c2lnbi4gIFdlIGNvdWxkIHRyeSBtb3ZpbmcgYmNlX3B1bHNlKCkgDQppbml0aWFsaXphdGlvbiBm cm9tIGJjZV9hdHRhY2goKSB0byBiY2VfaW5pdCgpIHNvIHRoZSBkcml2ZXIgb25seSANCnRha2Vz IGNvbnRyb2wgd2hlbiB5b3UgInVwIiB0aGUgaW50ZXJmYWNlLg0KDQpEYXZlDQo= From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 21:24:09 2011 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 5FE50106564A for ; Fri, 7 Oct 2011 21:24:09 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 36D0E8FC13 for ; Fri, 7 Oct 2011 21:24:09 +0000 (UTC) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 Oct 2011 14:27:52 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 7 Oct 2011 14:21:15 -0700 From: "David Christensen" To: "Sean Bruno" , "freebsd-net@freebsd.org" Date: Fri, 7 Oct 2011 14:21:37 -0700 Thread-Topic: bce(4) with IPMI [puzzling and puzzling] Thread-Index: AcyElIZIy/mtVm+WRbiVCpZ/rH2vfwAogSAA Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F35B5619@IRVEXCHCCR01.corp.ad.broadcom.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6291B1523KO28556814-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: Pyun YongHyeon Subject: RE: bce(4) with IPMI [puzzling and puzzling] 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, 07 Oct 2011 21:24:09 -0000 PiBXaG9hIC4uLiBvaywgc28gbm93IEkndmUgcnVuIGludG8gc29tZXRoaW5nIGhvcnJpYmxlLg0K PiANCj4gQWNjb3JkaW5nIHRvIGRtaWRlY29kZSwgYSBEZWxsIFI0MTAgaGFzIGEgQnJvYWRjb20g NTcxNiBjaGlwc2V0IG9uIGl0Lg0KPiBPbiBCb2FyZCBEZXZpY2UgMiBJbmZvcm1hdGlvbg0KPiAg ICAgICAgIFR5cGU6IEV0aGVybmV0DQo+ICAgICAgICAgU3RhdHVzOiBFbmFibGVkDQo+ICAgICAg ICAgRGVzY3JpcHRpb246IEVtYmVkZGVkIEJyb2FkY29tIDU3MTYgTklDIDENCj4gT24gQm9hcmQg RGV2aWNlIDMgSW5mb3JtYXRpb24NCj4gICAgICAgICBUeXBlOiBFdGhlcm5ldA0KPiAgICAgICAg IFN0YXR1czogRW5hYmxlZA0KPiAgICAgICAgIERlc2NyaXB0aW9uOiBFbWJlZGRlZCBCcm9hZGNv bSA1NzE2IE5JQyAyDQo+IA0KPiANCj4gSG93ZXZlciwgd2hlbiBJIGFzayB0aGUgY2hpcHNldCB3 aGF0IHR5cGUgaXQgaXMgdmlhOg0KPiAgaWZfYmNlcmVnLmg6I2RlZmluZSBCQ0VfQ0hJUF9OVU0o c2MpDQo+IA0KPiBJdCBjbGVhcmx5IGluZGljYXRlcyB0aGF0IGl0IGlzIGEgNTcwOT8/Pz8gDQoN Ck5vdCBob3JyaWJsZSwgZXhwZWN0ZWQuICBUaGUgdHdvIGNoaXBzIGFyZSB2aXJ0dWFsbHkgDQpp bmRpc3Rpbmd1aXNoYWJsZSBieSBzb2Z0d2FyZSBleGNlcHQgZm9yIHRoZSBQQ0kgZGV2aWNlDQpJ RC4gIFRoZSB0d28gY2hpcHMgZGlmZmVyIGluIHRoYXQgQkNNNTcwOSBzdXBwb3J0cw0KVENQL0lQ IGFuZCBpU0NTSSBvZmZsb2FkIGluIFdpbmRvd3Mgd2hpbGUgdGhlIEJDTTU3MTYNCmRvZXNu4oCZ dC4gIEZvciB0aGUgRnJlZUJTRCBkcml2ZXIgdGhhdCByZWFsbHkgb25seQ0KbWVhbnMgYSBkaWZm ZXJlbnQgc3RyaW5nIGlzIHByaW50ZWQgb3V0LCBhbGwgb3RoZXINCmNvZGUgcmVtYWlucyB0aGUg c2FtZS4NCg0KRGF2ZQ0KDQoNCg0KDQo= From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 22:30:07 2011 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 B0339106564A for ; Fri, 7 Oct 2011 22:30:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD5A8FC08 for ; Fri, 7 Oct 2011 22:30:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p97MU7Le014157 for ; Fri, 7 Oct 2011 22:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p97MU7NA014149; Fri, 7 Oct 2011 22:30:07 GMT (envelope-from gnats) Date: Fri, 7 Oct 2011 22:30:07 GMT Message-Id: <201110072230.p97MU7NA014149@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159602: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 22:30:07 -0000 The following reply was made to PR kern/159602; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159602: commit references a PR Date: Fri, 7 Oct 2011 22:22:29 +0000 (UTC) Author: qingli Date: Fri Oct 7 22:22:19 2011 New Revision: 226120 URL: http://svn.freebsd.org/changeset/base/226120 Log: Do not try removing an ARP entry associated with a given interface address if that interface does not support ARP. Otherwise the system will generate error messages unnecessarily due to the missing entry. PR: kern/159602 Submitted by: pluknet MFC after: 3 days Modified: head/sys/netinet/in.c Modified: head/sys/netinet/in.c ============================================================================== --- head/sys/netinet/in.c Fri Oct 7 22:14:18 2011 (r226119) +++ head/sys/netinet/in.c Fri Oct 7 22:22:19 2011 (r226120) @@ -1138,7 +1138,8 @@ in_scrubprefix(struct in_ifaddr *target, if (error == 0) target->ia_flags &= ~IFA_RTSELF; } - if (flags & LLE_STATIC) + if ((flags & LLE_STATIC) && + !(target->ia_ifp->if_flags & IFF_NOARP)) /* remove arp cache */ arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr); } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 22:35:02 2011 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 87545106566B; Fri, 7 Oct 2011 22:35:02 +0000 (UTC) (envelope-from pyunyh@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 B98E78FC14; Fri, 7 Oct 2011 22:35:01 +0000 (UTC) Received: by wyj26 with SMTP id 26so5996984wyj.13 for ; Fri, 07 Oct 2011 15:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=7HzRaBzEyHQ7g8/y2HoqSgXZhKrhbwpfIlBKDUekLKA=; b=gCvb7PBbGM1BnqRVBuMKH59tLQh8LkF62U4bPqfyEvltLdGcvMuJgA6NpXlMdMfxtw 0qa+bF8Ntyym0Bi6HVMAj5yZDXam+soRxe15FnUJTfeQuUI6nGWIZsqUVblnv5div3Tm 1jIXQkewp2gp0Lbz9IIp0wwYK4oS7WRViOjxU= Received: by 10.227.38.66 with SMTP id a2mr3039340wbe.43.1318026900427; Fri, 07 Oct 2011 15:35:00 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id i29sm18424467wbp.22.2011.10.07.15.34.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 15:34:59 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Oct 2011 15:33:00 -0700 From: YongHyeon PYUN Date: Fri, 7 Oct 2011 15:33:00 -0700 To: David Christensen Message-ID: <20111007223300.GE11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B5613@IRVEXCHCCR01.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385F35B5613@IRVEXCHCCR01.corp.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , Pyun YongHyeon , Sean Bruno , "davidch@freebsd.org" Subject: Re: bce(4) with IPMI 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: Fri, 07 Oct 2011 22:35:02 -0000 On Fri, Oct 07, 2011 at 02:17:06PM -0700, David Christensen wrote: > > > Can't explain either but probably stable/6 bce(4) may have used old > > > firmware. > > > > Ok, I can once again reach the IPMI controller if I remove this: > > > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210263&r2=21 > > 0262&pathrev=210263 > > > > Since the driver has control over the interface, not "upping" the > > interface media causes the IPMI controller to not be able to access the > > network. Ugh. > > > > That's the current design. We could try moving bce_pulse() > initialization from bce_attach() to bce_init() so the driver only > takes control when you "up" the interface. > Because driver already initialized CPUs and context I thought moving bce_pulse() to bce_init() was too late. If that's doable it would be more correct way to address this issue. > Dave > From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 22:46:01 2011 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 B5A201065670; Fri, 7 Oct 2011 22:46:01 +0000 (UTC) (envelope-from pyunyh@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 111178FC15; Fri, 7 Oct 2011 22:46:00 +0000 (UTC) Received: by wyj26 with SMTP id 26so6004935wyj.13 for ; Fri, 07 Oct 2011 15:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=qhA0dXl2luauyywUgmIJ/Pz6arSTzB9Cq1gMB4iJGCE=; b=SkN9m0Q/emWZyjNPdClleF8a2Qs2jbk+qecD/w//3UYBDESrXaxCY2nl4ZZMi4iSUo koqYXdXnqGwuf2V5TLIJv/ejlJxTJDnqEAhQvboQ+V5qFgo6JnMRx92gCPJrRzlmiF5u pyRjwWLwDmRwaiUAJoV6OzbsNeUqwbxvfyF3s= Received: by 10.227.201.130 with SMTP id fa2mr3225013wbb.13.1318027559946; Fri, 07 Oct 2011 15:45:59 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id y10sm18502295wbm.14.2011.10.07.15.45.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 15:45:58 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Oct 2011 15:43:59 -0700 From: YongHyeon PYUN Date: Fri, 7 Oct 2011 15:43:59 -0700 To: David Christensen Message-ID: <20111007224359.GF11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> <1318004610.27029.1.camel@hitfishpass-lx.corp.yahoo.com> <20111007175137.GA11808@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F35B561B@IRVEXCHCCR01.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="JP+T4n/bALQSJXh8" Content-Disposition: inline In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385F35B561B@IRVEXCHCCR01.corp.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , Sean Bruno , Pyun YongHyeon Subject: Re: bce(4) with IPMI [puzzling and puzzling] 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: Fri, 07 Oct 2011 22:46:01 -0000 --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 07, 2011 at 02:23:10PM -0700, David Christensen wrote: > > > so, I cracked open my R410 this morning to see what the Ethernet > > chipset > > > had for a indentification mark. It is definitely stamped as a > > BCM5716, > > > so I'm confused. > > > > > > bce(4) has code to handle the 5716 chipset, but its never being > > executed > > > AFAIK. What's going on here? > > > > > > > I guess BCE_CHIP_NUM() returns 0x5709 for 5709 and 5716 > > controllers. I don't know why bce(4) explicitly checks 5716 from > > the BCE_MISC_ID register. Public data sheet indicates CHIP_NUM bits > > have 0x5909 for 5716(NetXtremeII-PG203-R pp229). > > To me 5716 is virtually the same as 5709 except for not supporting > > TOE and iSCSI offloading. > > > > That's a typo then, 5709 and 5716 share the same ASIC ID. > Thanks for confirmation. Could you review the attached patch? > Dave > > --JP+T4n/bALQSJXh8 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bce.5716.diff" Index: sys/dev/bce/if_bce.c =================================================================== --- sys/dev/bce/if_bce.c (revision 226114) +++ sys/dev/bce/if_bce.c (working copy) @@ -1112,8 +1112,7 @@ DBPRINT(sc, BCE_INFO_LOAD, "%s(): Using MSI " "interrupt.\n", __FUNCTION__); sc->bce_flags |= BCE_USING_MSI_FLAG; - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) sc->bce_flags |= BCE_ONE_SHOT_MSI_FLAG; sc->bce_irq_rid = 1; sc->bce_intr = bce_intr; @@ -1730,8 +1729,7 @@ offset = ctx_offset + cid_addr; - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { REG_WR(sc, BCE_CTX_CTX_CTRL, (offset | BCE_CTX_CTX_CTRL_READ_REQ)); @@ -1783,8 +1781,7 @@ BCE_PRINTF("%s(): Invalid CID address: 0x%08X.\n", __FUNCTION__, cid_addr)); - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { REG_WR(sc, BCE_CTX_CTX_DATA, ctx_val); REG_WR(sc, BCE_CTX_CTX_CTRL, (offset | BCE_CTX_CTX_CTRL_WRITE_REQ)); @@ -2469,8 +2466,7 @@ DBENTER(BCE_VERBOSE_NVRAM); - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { sc->bce_flash_info = &flash_5709; goto bce_init_nvram_get_flash_size; } @@ -3224,8 +3220,7 @@ /* Free, unmap and destroy all context memory pages. */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { for (i = 0; i < sc->ctx_pages; i++ ) { if (sc->ctx_block[i] != NULL) { bus_dmamem_free( @@ -3564,8 +3559,7 @@ __FUNCTION__, (uintmax_t) sc->stats_block_paddr); /* BCM5709 uses host memory as cache for context memory. */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { sc->ctx_pages = 0x2000 / BCM_PAGE_SIZE; if (sc->ctx_pages == 0) sc->ctx_pages = 1; @@ -4206,8 +4200,7 @@ cpu_reg.spad_base = BCE_RXP_SCRATCH; cpu_reg.mips_view_base = 0x8000000; - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { fw.ver_major = bce_RXP_b09FwReleaseMajor; fw.ver_minor = bce_RXP_b09FwReleaseMinor; fw.ver_fix = bce_RXP_b09FwReleaseFix; @@ -4305,8 +4298,7 @@ cpu_reg.spad_base = BCE_TXP_SCRATCH; cpu_reg.mips_view_base = 0x8000000; - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { fw.ver_major = bce_TXP_b09FwReleaseMajor; fw.ver_minor = bce_TXP_b09FwReleaseMinor; fw.ver_fix = bce_TXP_b09FwReleaseFix; @@ -4403,8 +4395,7 @@ cpu_reg.spad_base = BCE_TPAT_SCRATCH; cpu_reg.mips_view_base = 0x8000000; - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { fw.ver_major = bce_TPAT_b09FwReleaseMajor; fw.ver_minor = bce_TPAT_b09FwReleaseMinor; fw.ver_fix = bce_TPAT_b09FwReleaseFix; @@ -4501,8 +4492,7 @@ cpu_reg.spad_base = BCE_CP_SCRATCH; cpu_reg.mips_view_base = 0x8000000; - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { fw.ver_major = bce_CP_b09FwReleaseMajor; fw.ver_minor = bce_CP_b09FwReleaseMinor; fw.ver_fix = bce_CP_b09FwReleaseFix; @@ -4599,8 +4589,7 @@ cpu_reg.spad_base = BCE_COM_SCRATCH; cpu_reg.mips_view_base = 0x8000000; - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { fw.ver_major = bce_COM_b09FwReleaseMajor; fw.ver_minor = bce_COM_b09FwReleaseMinor; fw.ver_fix = bce_COM_b09FwReleaseFix; @@ -4683,8 +4672,7 @@ { DBENTER(BCE_VERBOSE_RESET); - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { if ((BCE_CHIP_REV(sc) == BCE_CHIP_REV_Ax)) { bce_load_rv2p_fw(sc, bce_xi90_rv2p_proc1, @@ -4732,8 +4720,7 @@ rc = 0; DBENTER(BCE_VERBOSE_RESET | BCE_VERBOSE_CTX); - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { retry_cnt = CTX_INIT_RETRY_COUNT; DBPRINT(sc, BCE_INFO_CTX, "Initializing 5709 context.\n"); @@ -4960,8 +4947,7 @@ DELAY(5); /* Disable DMA */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { val = REG_RD(sc, BCE_MISC_NEW_CORE_CTL); val &= ~BCE_MISC_NEW_CORE_CTL_DMA_ENABLE; REG_WR(sc, BCE_MISC_NEW_CORE_CTL, val); @@ -4983,8 +4969,7 @@ val = REG_RD(sc, BCE_MISC_ID); /* Chip reset. */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { REG_WR(sc, BCE_MISC_COMMAND, BCE_MISC_COMMAND_SW_RESET); REG_RD(sc, BCE_MISC_COMMAND); DELAY(5); @@ -5113,8 +5098,7 @@ val |= BCE_MQ_CONFIG_KNL_BYP_BLK_SIZE_256; /* Enable bins used on the 5709. */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { val |= BCE_MQ_CONFIG_BIN_MQ_MODE; if (BCE_CHIP_ID(sc) == BCE_CHIP_ID_5709_A1) val |= BCE_MQ_CONFIG_HALT_DIS; @@ -5268,8 +5252,7 @@ } /* Enable DMA */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { val = REG_RD(sc, BCE_MISC_NEW_CORE_CTL); val |= BCE_MISC_NEW_CORE_CTL_DMA_ENABLE; REG_WR(sc, BCE_MISC_NEW_CORE_CTL, val); @@ -5293,8 +5276,7 @@ } /* Enable all remaining blocks in the MAC. */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) REG_WR(sc, BCE_MISC_ENABLE_SET_BITS, BCE_MISC_ENABLE_DEFAULT_XI); else @@ -5565,8 +5547,7 @@ DBENTER(BCE_VERBOSE_RESET | BCE_VERBOSE_SEND | BCE_VERBOSE_CTX); /* Initialize the context ID for an L2 TX chain. */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { /* Set the CID type to support an L2 connection. */ val = BCE_L2CTX_TX_TYPE_TYPE_L2_XI | BCE_L2CTX_TX_TYPE_SIZE_L2_XI; @@ -5729,8 +5710,7 @@ * when pause frames can be stopped (the high * watermark). */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { u32 lo_water, hi_water; if (sc->bce_flags & BCE_USING_TX_FLOW_CONTROL) { @@ -5764,8 +5744,7 @@ CTX_WR(sc, GET_CID_ADDR(RX_CID), BCE_L2CTX_RX_CTX_TYPE, val); /* Setup the MQ BIN mapping for l2_ctx_host_bseq. */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { val = REG_RD(sc, BCE_MQ_MAP_L2_5); REG_WR(sc, BCE_MQ_MAP_L2_5, val | BCE_MQ_MAP_L2_5_ARM); } @@ -5983,8 +5962,7 @@ } /* Setup the MQ BIN mapping for host_pg_bidx. */ - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) REG_WR(sc, BCE_MQ_MAP_L2_3, BCE_MQ_MAP_L2_3_DEFAULT); CTX_WR(sc, GET_CID_ADDR(RX_CID), BCE_L2CTX_RX_PG_BUF_SIZE, 0); @@ -9912,8 +9890,7 @@ "consumer index\n", CTX_RD(sc, GET_CID_ADDR(cid), BCE_L2CTX_RX_NX_PG_BDIDX)); } else if (cid == TX_CID) { - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { BCE_PRINTF(" 0x%08X - (L2CTX_TX_TYPE_XI) ctx type\n", CTX_RD(sc, GET_CID_ADDR(cid), BCE_L2CTX_TX_TYPE_XI)); @@ -10175,8 +10152,7 @@ (BCE_HC_STAT_GEN_SEL_0_GEN_SEL_0_CPQ_VALID_CNT << 8) | (BCE_HC_STAT_GEN_SEL_0_GEN_SEL_0_MGMQ_VALID_CNT); - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) + if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) val = val | (BCE_HC_STAT_GEN_SEL_0_GEN_SEL_0_RV2PCSQ_VALID_CNT_XI << 24); @@ -10209,8 +10185,7 @@ BCE_PRINTF(" CS 0x%08X 0x%08X 0x%08X 0x%08X 0x%08X\n", cmd, ctl, cur_depth, max_depth, valid_cnt); - if ((BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) || - (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5716)) { + if (BCE_CHIP_NUM(sc) == BCE_CHIP_NUM_5709) { /* Input queue to the RV2P Command Scheduler */ cmd = REG_RD(sc, BCE_RV2PCSR_FTQ_CMD); ctl = REG_RD(sc, BCE_RV2PCSR_FTQ_CTL); Index: sys/dev/bce/if_bcereg.h =================================================================== --- sys/dev/bce/if_bcereg.h (revision 226114) +++ sys/dev/bce/if_bcereg.h (working copy) @@ -576,7 +576,6 @@ #define BCE_CHIP_NUM_5706 0x57060000 #define BCE_CHIP_NUM_5708 0x57080000 #define BCE_CHIP_NUM_5709 0x57090000 -#define BCE_CHIP_NUM_5716 0x57160000 #define BCE_CHIP_REV(sc) (((sc)->bce_chipid) & 0x0000f000) #define BCE_CHIP_REV_Ax 0x00000000 @@ -601,7 +600,6 @@ #define BCE_CHIP_ID_5709_B1 0x57091010 #define BCE_CHIP_ID_5709_B2 0x57091020 #define BCE_CHIP_ID_5709_C0 0x57092000 -#define BCE_CHIP_ID_5716_C0 0x57162000 #define BCE_CHIP_BOND_ID(sc) (((sc)->bce_chipid) & 0xf) --JP+T4n/bALQSJXh8-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 23:08:12 2011 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 98962106566B; Fri, 7 Oct 2011 23:08:12 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 5A95B8FC0A; Fri, 7 Oct 2011 23:08:12 +0000 (UTC) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 Oct 2011 16:07:35 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 7 Oct 2011 16:00:58 -0700 From: "David Christensen" To: "pyunyh@gmail.com" Date: Fri, 7 Oct 2011 16:01:00 -0700 Thread-Topic: bce(4) with IPMI Thread-Index: AcyFQWH4G4VEmFU8QkGW3aj8ylWcIwAAWLNQ Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F35B568B@IRVEXCHCCR01.corp.ad.broadcom.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B5613@IRVEXCHCCR01.corp.ad.broadcom.com> <20111007223300.GE11808@michelle.cdnetworks.com> In-Reply-To: <20111007223300.GE11808@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: t3k= Cc2v KrEZ KvgA LC4+ OqCT WKAy ac+K dy7D hWYx iNo9 osJT rQmT sHjO ujF6 5Bfs; 5; ZABhAHYAaQBkAGMAaABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA7AGYAcgBlAGUAYgBzAGQALQBuAGUAdABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA7AHAAeQB1AG4AeQBoAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBzAGUAYQBuAGIAcgB1AEAAeQBhAGgAbwBvAC0AaQBuAGMALgBjAG8AbQA7AHkAbwBuAGcAYQByAGkAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {B41B642E-50B1-4B1F-BFC8-AB0F07727E40}; ZABhAHYAaQBkAGMAaABAAGIAcgBvAGEAZABjAG8AbQAuAGMAbwBtAA==; Fri, 07 Oct 2011 23:01:00 GMT;UgBFADoAIABiAGMAZQAoADQAKQAgAHcAaQB0AGgAIABJAFAATQBJAA== x-cr-puzzleid: {B41B642E-50B1-4B1F-BFC8-AB0F07727E40} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 629159BD3KO28579565-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Pyun YongHyeon , Sean Bruno , "davidch@freebsd.org" Subject: RE: bce(4) with IPMI 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, 07 Oct 2011 23:08:12 -0000 > Because driver already initialized CPUs and context I thought > moving bce_pulse() to bce_init() was too late. If that's doable it > would be more correct way to address this issue. >=20 Moving bce_pulse() is a minimum. It might be necessary to move some other code out of bce_attach()/bce_detach() and relocate it=20 to bce_init()/bce_stop() so that RX/TX MAC operations aren't=20 interrupted. I've not seen it done that way in other Broadcom=20 drivers so I wouldn't expect it to be a trivial effort. Dave From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 23:17:03 2011 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 5D273106564A; Fri, 7 Oct 2011 23:17:03 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB4258FC0A; Fri, 7 Oct 2011 23:17:02 +0000 (UTC) Received: by ggeq3 with SMTP id q3so4036792gge.13 for ; Fri, 07 Oct 2011 16:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:cc :mime-version:content-type:content-transfer-encoding:message-id; bh=i55japl0maxFtL5Kr33SZv1/BhWgwBNZvxhYpanhWhE=; b=pdCKt7vVFLq9HoNLtj9Ib+epzP0V9oLwZlGoxSjTFbNNBFUKyIPFHM4baJF/jatbH6 +maJzjO5aSfhizGte7PcpTmi+vcF1wCqS6szDlMJvJeslR1F8KhnAl5jPQK7BAClIznR zYg7dLIc84lxPtB+AgOD+9ssWLd9UOVPlrzOI= Received: by 10.236.129.228 with SMTP id h64mr13343099yhi.101.1318029422156; Fri, 07 Oct 2011 16:17:02 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id w50sm15216016yhi.2.2011.10.07.16.17.00 (version=SSLv3 cipher=OTHER); Fri, 07 Oct 2011 16:17:01 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Fri, 7 Oct 2011 18:16:17 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> In-Reply-To: <201110042008.48915.break19@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110071816.17335.break19@gmail.com> Cc: Adrian Chadd , Arnaud Lacombe Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 07 Oct 2011 23:17:03 -0000 This is the latest kernel panic screenshot.. http://imageshack.us/photo/my-images/707/newcrashw.png/ Thanks, Chuck Burns From owner-freebsd-net@FreeBSD.ORG Fri Oct 7 23:26:10 2011 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 738F0106564A; Fri, 7 Oct 2011 23:26:10 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4DB8FC17; Fri, 7 Oct 2011 23:26:10 +0000 (UTC) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 Oct 2011 16:32:10 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 7 Oct 2011 16:25:33 -0700 From: "David Christensen" To: "pyunyh@gmail.com" Date: Fri, 7 Oct 2011 16:25:56 -0700 Thread-Topic: bce(4) with IPMI [puzzling and puzzling] Thread-Index: AcyFQurkPUQ3f60WRxqRB5FTzYBW8QABUKgw Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F35B56AF@IRVEXCHCCR01.corp.ad.broadcom.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> <1318004610.27029.1.camel@hitfishpass-lx.corp.yahoo.com> <20111007175137.GA11808@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F35B561B@IRVEXCHCCR01.corp.ad.broadcom.com> <20111007224359.GF11808@michelle.cdnetworks.com> In-Reply-To: <20111007224359.GF11808@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 629154703KO28584273-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Sean Bruno , Pyun YongHyeon Subject: RE: bce(4) with IPMI [puzzling and puzzling] 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, 07 Oct 2011 23:26:10 -0000 > > That's a typo then, 5709 and 5716 share the same ASIC ID. > > >=20 > Thanks for confirmation. > Could you review the attached patch? Looks good. ASIC ID matches my Dell R210 system: bce0: mem 0xda000000-0xdbff= ffff irq 16 at device 0.0 on pci2 miibus0: on bce0 bce0: Ethernet address: b8:ac:6f:87:95:f1 bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); Buf= s (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.8) Dave From owner-freebsd-net@FreeBSD.ORG Sat Oct 8 00:07:04 2011 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 CB564106566B; Sat, 8 Oct 2011 00:07:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 303CC8FC08; Sat, 8 Oct 2011 00:07:03 +0000 (UTC) Received: by wwe3 with SMTP id 3so6325059wwe.31 for ; Fri, 07 Oct 2011 17:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=x/m+FIzGs04t+i+uKesgrnCb+usM8Nf2c07nHV1Jpc8=; b=QR/zcwETw53ktC0T9Ig55+V6HXpC7Y19KsnzuMJx4h8ahGWtFGkqDtLIGXJAxZg5dz YXfIIxgq7h0qcvWsyPborA3V6Ze8L4tZv7hWxskt2ZeUyurISgdlUFoM/FKrtU5xu5Jl loeJ/jgRT84jVVK4qUt9pkONZrosk0n9JV6BM= Received: by 10.216.143.222 with SMTP id l72mr3174688wej.46.1318032423113; Fri, 07 Oct 2011 17:07:03 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l9sm18807378wba.5.2011.10.07.17.06.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 17:07:02 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Oct 2011 17:05:03 -0700 From: YongHyeon PYUN Date: Fri, 7 Oct 2011 17:05:03 -0700 To: David Christensen Message-ID: <20111008000503.GG11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> <1318004610.27029.1.camel@hitfishpass-lx.corp.yahoo.com> <20111007175137.GA11808@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F35B561B@IRVEXCHCCR01.corp.ad.broadcom.com> <20111007224359.GF11808@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F35B56AF@IRVEXCHCCR01.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Bu8it7iiRSEf40bY" Content-Disposition: inline In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385F35B56AF@IRVEXCHCCR01.corp.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , Sean Bruno , Pyun YongHyeon Subject: Re: bce(4) with IPMI [puzzling and puzzling] 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: Sat, 08 Oct 2011 00:07:05 -0000 --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 07, 2011 at 04:25:56PM -0700, David Christensen wrote: > > > That's a typo then, 5709 and 5716 share the same ASIC ID. > > > > > > > Thanks for confirmation. > > Could you review the attached patch? > > Looks good. ASIC ID matches my Dell R210 system: > > bce0: mem 0xda000000-0xdbffffff irq 16 at device 0.0 on pci2 > miibus0: on bce0 > bce0: Ethernet address: b8:ac:6f:87:95:f1 > bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.8) > Thanks for testing. Committed with r226123. I also noticed that bce(4) may support BCM5716S because brgphy(4) already supports BCM5709S. Can you test attached patch on BCM5716S? > Dave > > --Bu8it7iiRSEf40bY Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bce.5716S.diff" Index: sys/dev/bce/if_bce.c =================================================================== --- sys/dev/bce/if_bce.c (revision 226123) +++ sys/dev/bce/if_bce.c (working copy) @@ -154,6 +154,10 @@ { BRCM_VENDORID, BRCM_DEVICEID_BCM5716, PCI_ANY_ID, PCI_ANY_ID, "Broadcom NetXtreme II BCM5716 1000Base-T" }, + /* BCM5716S controllers and OEM boards. */ + { BRCM_VENDORID, BRCM_DEVICEID_BCM5716S, PCI_ANY_ID, PCI_ANY_ID, + "Broadcom NetXtreme II BCM5716S 1000Base-SX" }, + { 0, 0, 0, 0, NULL } }; Index: sys/dev/bce/if_bcereg.h =================================================================== --- sys/dev/bce/if_bcereg.h (revision 226123) +++ sys/dev/bce/if_bcereg.h (working copy) @@ -565,6 +565,7 @@ #define BRCM_DEVICEID_BCM5709 0x1639 #define BRCM_DEVICEID_BCM5709S 0x163A #define BRCM_DEVICEID_BCM5716 0x163B +#define BRCM_DEVICEID_BCM5716S 0x163C #define HP_VENDORID 0x103C --Bu8it7iiRSEf40bY-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 8 00:26:39 2011 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 DBC5D1065672; Sat, 8 Oct 2011 00:26:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 876388FC12; Sat, 8 Oct 2011 00:26:39 +0000 (UTC) Received: by gyf2 with SMTP id 2so5239620gyf.13 for ; Fri, 07 Oct 2011 17:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uAVIHsMvKp14z6ayo+JuX8MFqdCzj9MWEIzjDEtb8B4=; b=fRui6vTytw9fuhfdKuluhoGg8VfLCzSiJX7USthGuScVJHz2VHkpkkYEfpM+q8e8fJ k0pAk3z8KkfOuTv8v/Gfz6o2LXVFMB/WL1L8RVgsmpCkx4Ne9fqsWzVoQKAC1OUju706 QMwYUEGol248HehmXKFXIycrWhZEOh8GtSfa0= MIME-Version: 1.0 Received: by 10.236.197.104 with SMTP id s68mr13849771yhn.20.1318033597758; Fri, 07 Oct 2011 17:26:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Fri, 7 Oct 2011 17:26:37 -0700 (PDT) In-Reply-To: <201110071816.17335.break19@gmail.com> References: <201110042008.48915.break19@gmail.com> <201110071816.17335.break19@gmail.com> Date: Sat, 8 Oct 2011 08:26:37 +0800 X-Google-Sender-Auth: HOaxnn3Rvew7Bm4dsEzaqielgoI Message-ID: From: Adrian Chadd To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Arnaud Lacombe Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 08 Oct 2011 00:26:39 -0000 On 8 October 2011 07:16, Chuck Burns wrote: > This is the latest kernel panic screenshot.. > > http://imageshack.us/photo/my-images/707/newcrashw.png/ Hm, it's crashing when calling ieee80211_process_callback(). Is data->ni == NULL ? Adrian From owner-freebsd-net@FreeBSD.ORG Sat Oct 8 00:31:11 2011 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 AFC07106564A for ; Sat, 8 Oct 2011 00:31:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 70D438FC08 for ; Sat, 8 Oct 2011 00:31:11 +0000 (UTC) Received: by gyf2 with SMTP id 2so5241637gyf.13 for ; Fri, 07 Oct 2011 17:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=M0bYbpDDOIfA3qtPf7jTGUXtWalBNEIlovVEY38A+Js=; b=UlCXi8e2uNfffuS6Dcf5O1Iq0lo6Q4N+RkJzS61o5Ez+JbUkR90D6kaJ8iMJLcyoMO vQbKfJJyTiurTzxS0DOpwOtntnd1EWqjBsivMxXXxd3d6ltz3jTDBLWnN1z5AItT1ERM 6VN8TKOht6vBZtExdvN+49wWQxDfWxk73F6Io= MIME-Version: 1.0 Received: by 10.236.197.104 with SMTP id s68mr13858904yhn.20.1318033870792; Fri, 07 Oct 2011 17:31:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Fri, 7 Oct 2011 17:31:10 -0700 (PDT) In-Reply-To: <1318021531.2596.6.camel@crashalot.rainbow-runner.nl> References: <1318021531.2596.6.camel@crashalot.rainbow-runner.nl> Date: Sat, 8 Oct 2011 08:31:10 +0800 X-Google-Sender-Auth: TpnLqn33yC30PLG8ExCyYRgN2Lg Message-ID: From: Adrian Chadd To: Koop Mast Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: wireless lor with ath chip. 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, 08 Oct 2011 00:31:11 -0000 That looks like a more general problem. None of those locks are net80211/ath locks. Adrian From owner-freebsd-net@FreeBSD.ORG Sat Oct 8 00:37:52 2011 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 5CE92106566B; Sat, 8 Oct 2011 00:37:52 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E496A8FC12; Sat, 8 Oct 2011 00:37:51 +0000 (UTC) Received: by ggeq3 with SMTP id q3so4073771gge.13 for ; Fri, 07 Oct 2011 17:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=uqdju6EkcsXtFmPyv6ck2E1H2EQOuBZLd9kz6m7TNxw=; b=HXzq0twhRyAtvQ/3MkY+ueo7l/eQb/xog0WKZB4WeFZ+gCGcQZwwX5hZFJags1KwIV NTf1vhSVX0D5R62OiVI2prI2ddQVzabJLYXL1v10QhqMk5dEeHgVCL3GNoNVgbgwubRJ RE5MCWnMsbkJCTpQOC75cd8IaMoonmKlRgtqU= Received: by 10.150.69.18 with SMTP id r18mr17058yba.10.1318034271192; Fri, 07 Oct 2011 17:37:51 -0700 (PDT) Received: from blackbeast.local (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id g38sm29433077ann.4.2011.10.07.17.37.46 (version=SSLv3 cipher=OTHER); Fri, 07 Oct 2011 17:37:50 -0700 (PDT) From: Chuck Burns To: freebsd-net@freebsd.org Date: Fri, 7 Oct 2011 19:36:49 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> <201110071816.17335.break19@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110071936.50071.break19@gmail.com> Cc: Adrian Chadd , Arnaud Lacombe Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 08 Oct 2011 00:37:52 -0000 On Friday, October 07, 2011 7:26:37 PM Adrian Chadd wrote: > On 8 October 2011 07:16, Chuck Burns wrote: > > This is the latest kernel panic screenshot.. > > > > http://imageshack.us/photo/my-images/707/newcrashw.png/ > > Hm, it's crashing when calling ieee80211_process_callback(). > Is data->ni == NULL ? > > > Adrian I don't know what that means really. I consider myself a fairly advanced user, but nothing more, really. Chuck Burns From owner-freebsd-net@FreeBSD.ORG Sat Oct 8 00:45:21 2011 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 C81C5106566B; Sat, 8 Oct 2011 00:45:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 718528FC0C; Sat, 8 Oct 2011 00:45:21 +0000 (UTC) Received: by ggeq3 with SMTP id q3so4076692gge.13 for ; Fri, 07 Oct 2011 17:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J1pZ/Yllix+TyCACjbWQbkl+2frvEmLMhs5iSarxrrM=; b=s6O5dA2wPfOsarwU6u7b1Qhuco5vXLmWcnPCA4EoVHB5nYCv6W08Fi6JP5FLWJ16GD 7JoUgpYoaheWBS89w1Tn40XMHrZGCh/DmOWLNJyq/IUlTf6C37W9BW/u452LrrRCCS1L UjT+wUCsJz8cM7lyuu0/9ShBIYN+Om5wFW0Uw= MIME-Version: 1.0 Received: by 10.236.161.10 with SMTP id v10mr13338974yhk.88.1318034720887; Fri, 07 Oct 2011 17:45:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Fri, 7 Oct 2011 17:45:20 -0700 (PDT) In-Reply-To: <201110071936.50071.break19@gmail.com> References: <201110042008.48915.break19@gmail.com> <201110071816.17335.break19@gmail.com> <201110071936.50071.break19@gmail.com> Date: Sat, 8 Oct 2011 08:45:20 +0800 X-Google-Sender-Auth: IKjZXRGngZ_eb6qk_sZXWlAR6VI Message-ID: From: Adrian Chadd To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Arnaud Lacombe Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 08 Oct 2011 00:45:21 -0000 On 8 October 2011 08:36, Chuck Burns wrote: > I don't know what that means really. =A0I consider myself a fairly advanc= ed > user, but nothing more, really. I'm going to need some help to help Chuck here. :) Any takers? Adrian From owner-freebsd-net@FreeBSD.ORG Sat Oct 8 01:05:20 2011 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 498EE106566C; Sat, 8 Oct 2011 01:05:20 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 19F378FC14; Sat, 8 Oct 2011 01:05:19 +0000 (UTC) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 Oct 2011 18:09:58 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Fri, 7 Oct 2011 18:02:58 -0700 From: "David Christensen" To: "pyunyh@gmail.com" Date: Fri, 7 Oct 2011 18:02:56 -0700 Thread-Topic: bce(4) with IPMI [puzzling and puzzling] Thread-Index: AcyFTjtMztwy7oEHTIu+10IvuX0xXgAB6VFA Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F35B56FC@IRVEXCHCCR01.corp.ad.broadcom.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317952651.9892.19.camel@hitfishpass-lx.corp.yahoo.com> <1318004610.27029.1.camel@hitfishpass-lx.corp.yahoo.com> <20111007175137.GA11808@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F35B561B@IRVEXCHCCR01.corp.ad.broadcom.com> <20111007224359.GF11808@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F35B56AF@IRVEXCHCCR01.corp.ad.broadcom.com> <20111008000503.GG11808@michelle.cdnetworks.com> In-Reply-To: <20111008000503.GG11808@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62917D6C3JW2579804-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Sean Bruno , Pyun YongHyeon Subject: RE: bce(4) with IPMI [puzzling and puzzling] 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, 08 Oct 2011 01:05:20 -0000 > Thanks for testing. > Committed with r226123. > I also noticed that bce(4) may support BCM5716S because brgphy(4) > already supports BCM5709S. Can you test attached patch on BCM5716S? I don't have a 5716S system or NIC for testing. Dave