From owner-freebsd-net@FreeBSD.ORG Sun Jan 30 06:40: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 2FF591065674 for ; Sun, 30 Jan 2011 06:40:52 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id A74E98FC1A for ; Sun, 30 Jan 2011 06:40:50 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id p0U6eng6046327 for ; Sun, 30 Jan 2011 08:40:49 +0200 (EET) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id p0U6emxx046326 for freebsd-net@freebsd.org; Sun, 30 Jan 2011 08:40:48 +0200 (EET) Date: Sun, 30 Jan 2011 08:40:48 +0200 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20110130064048.GA14888@relay.ibs.dn.ua> Mail-Followup-To: freebsd-net@freebsd.org References: <20101112070759.GA36248@relay.ibs.dn.ua> <20101112230000.GD22460@michelle.cdnetworks.com> <20110121125917.GA48950@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110121125917.GA48950@relay.ibs.dn.ua> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus@ibs.dn.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 06:40:52 -0000 another detail for this nic dmidecode Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: AT5NM10-I Version: Rev x.0x Serial Number: MT7006K15200322 uname -a FreeBSD 8.2-PRERELEASE amd64 system was cvsup-ed 2011.01.20 if_re.c,v 1.160.2.17 2011/01/15 00:32:15 yongari dmesg rgephy0: PHY 1 on miibus0 rgephy0: 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: 20:cf:30:89:5e:95 re0: [FILTER] pciconf -lv re0@pci0:2:0:0: class=0x020000 card=0x83a31043 chip=0x816810ec rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet while connected directly NIC <-> NIC they flaps too so, the issue with switch related causes can be excluded i believe -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Sun Jan 30 14:03:22 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 0C2A0106564A for ; Sun, 30 Jan 2011 14:03:22 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id C10578FC13 for ; Sun, 30 Jan 2011 14:03:21 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sun, 30 Jan 2011 14:51:50 +0100 id 00033C0C.4D456CF6.00010E79 From: Milan Obuch To: freebsd-net@freebsd.org, zeus@ibs.dn.ua Date: Sun, 30 Jan 2011 14:53:15 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.5; i386; ; ) References: <20110121125917.GA48950@relay.ibs.dn.ua> <20110130064048.GA14888@relay.ibs.dn.ua> In-Reply-To: <20110130064048.GA14888@relay.ibs.dn.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201101301453.18500.freebsd-net@dino.sk> Cc: Subject: Re: Problem with re0 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, 30 Jan 2011 14:03:22 -0000 On Sunday 30 January 2011 07:40:48 Zeus V Panchenko wrote: > another detail for this nic > > dmidecode > Base Board Information > Manufacturer: ASUSTeK Computer INC. > Product Name: AT5NM10-I > Version: Rev x.0x > Serial Number: MT7006K15200322 > I did not followed this thread closely, but I checked my new board and it is the same. > uname -a > FreeBSD 8.2-PRERELEASE amd64 > > system was cvsup-ed 2011.01.20 > > if_re.c,v 1.160.2.17 2011/01/15 00:32:15 yongari > > dmesg > rgephy0: PHY 1 on miibus0 > rgephy0: 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: 20:cf:30:89:5e:95 > re0: [FILTER] > > pciconf -lv > re0@pci0:2:0:0: class=0x020000 card=0x83a31043 chip=0x816810ec rev=0x03 > hdr=0x00 vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet > All details are the same for my board (modulo serial number and MAC, of course), and in my case it works with no problem, but only in 100 Mb switch port. In 1 Gb port I have no link. I must verify my cables, port on switch itself works just fine with another 1 Gb (intel) card. > > while connected directly NIC <-> NIC they flaps too > I will try this against another 1 Gb card too, just to see what happens... in 100 Mb mode it works just fine, as I mentioned already - running flood ping with 1472 bytes packets for more than an hour I see only four responses missing in more than 21 millions tries... Regards, Milan From owner-freebsd-net@FreeBSD.ORG Sun Jan 30 16:07: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 700AE106566B for ; Sun, 30 Jan 2011 16:07:42 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 2372D8FC14 for ; Sun, 30 Jan 2011 16:07:41 +0000 (UTC) Received: from mx1.psconsult.nl (psc11.adsl.iaf.nl [80.89.238.138]) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id p0UG7Z8w091238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 30 Jan 2011 17:07:40 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id p0UG7ZqV091237 for freebsd-net@freebsd.org; Sun, 30 Jan 2011 17:07:35 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Sun, 30 Jan 2011 17:07:35 +0100 From: Paul Schenkeveld To: freebsd-net@freebsd.org Message-ID: <20110130160735.GA81067@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: rtadvd and carp 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, 30 Jan 2011 16:07:42 -0000 Hi, I'm trying to enable IPv6 troughout the whole network here but I'm stuck on configuring rtadvd on my redundant firewall. The firewall consists of two Soekris net5501 (with 4 additional network interfaces each). Sis0 is connected to a LAN where I'd like to use IPv6, carp0 is my virtual interface. If I enable rtadvd on sis0 on both firewalls I see they both advertise the autoconf address of sis0 as the default gateway. I'd like the IPv6 address of carp0 to be advertised, can rtadvd do that or should I go for an IPv6 enable DHCP server? Thanks. Paul Schenkeveld From owner-freebsd-net@FreeBSD.ORG Sun Jan 30 22:00:19 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 EC5A1106566B for ; Sun, 30 Jan 2011 22:00:19 +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 CEB6B8FC16 for ; Sun, 30 Jan 2011 22:00:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0UM0JAW012685 for ; Sun, 30 Jan 2011 22:00:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0UM0JZ8012684; Sun, 30 Jan 2011 22:00:19 GMT (envelope-from gnats) Date: Sun, 30 Jan 2011 22:00:19 GMT Message-Id: <201101302200.p0UM0JZ8012684@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Juergen Lock Cc: Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Juergen Lock List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 22:00:20 -0000 The following reply was made to PR kern/153938; it has been noted by GNATS. From: Juergen Lock To: PseudoCylon Cc: bug-followup@freebsd.org, Juergen Lock Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic Date: Sun, 30 Jan 2011 22:50:42 +0100 On Sat, Jan 22, 2011 at 11:35:14PM -0800, PseudoCylon wrote: > >panic > > > > It's possible this was triggered by the first DPRINTFN() in > > run_node_cleanup() (that I turned into a device_printf() and meanwhile > > have disabled, maybe it caused a taskswitch) > > Your bt says no. > I was more thinking the printf might have allowed the other thread to run and grab the lock... > > #5 0xffffffff8117839b in run_node_cleanup (ni=0xffffff8000f83000) > > at > >/data2v/home/nox/src-r81/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:1719 > > > > 1719 RUN_LOCK(sc); > > (kgdb) l > > > run_node_cleanup() was called with node lock held. Happens all the time. > Ok but this time RUN_LOCK was held by the same thread that slept on the node lock and thus there was deadlock... > > - but in any case I'd > > say this is not safe i.e. needs to be fixed. :) > > > > Yes. Here is fix. This one shall work. > http://gitorious.org/run/run/trees/fifo_fix/dev/usb/wlan Anyway, I have been testing this version for maybe a week now and it seems to work at least no worse than the previous one, minus the deadlock. :) So it probably can go in. Thanx! Juergen From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 01:15: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 25C241065674 for ; Mon, 31 Jan 2011 01:15:20 +0000 (UTC) (envelope-from pyunyh@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 CF23A8FC13 for ; Mon, 31 Jan 2011 01:15:19 +0000 (UTC) Received: by gyf3 with SMTP id 3so1904392gyf.13 for ; Sun, 30 Jan 2011 17:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=WTIhlrh9EvsL2Fz4f7PlusTzT1pGxW82gOjDILvvNN8=; b=ZFlZAcrhqypUuJNulO8hYpcyg8fVshlNNFlfOOT2IZh+TsGkhFYJIEPwKqhQD1Re3n mtMxks8HwY/gOTMmPhdq5JbY9hn1HB3M+JWY3pmAV0dETQX30midt4F4mZ4CfAbsgrvU btF78Y40YVxwk3zr6DiSJw41WTx4adXatta+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BKUosZnVMJKe8LB8o6v9v7xLfSByHgfhys0dFk0r/pgXWlF/VRS78LWvymnVzXV2jv cL8f33j1y0QYHP3AmdcRgliTJ+TssIcWhKv/hxMzG3aXECh23JyU+yOlnCbkB/pfQDCA ciGLoHp7zKhkfUc7Nyj0EfvKlkbJCIUPCRR6I= Received: by 10.150.182.9 with SMTP id e9mr4499066ybf.160.1296436512062; Sun, 30 Jan 2011 17:15:12 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id r24sm1590238yba.6.2011.01.30.17.15.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 17:15:09 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 30 Jan 2011 17:15:10 -0800 From: Pyun YongHyeon Date: Sun, 30 Jan 2011 17:15:10 -0800 To: Milan Obuch Message-ID: <20110131011510.GC1323@michelle.cdnetworks.com> References: <20110121125917.GA48950@relay.ibs.dn.ua> <20110130064048.GA14888@relay.ibs.dn.ua> <201101301453.18500.freebsd-net@dino.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201101301453.18500.freebsd-net@dino.sk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, zeus@ibs.dn.ua Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 01:15:20 -0000 On Sun, Jan 30, 2011 at 02:53:15PM +0100, Milan Obuch wrote: > On Sunday 30 January 2011 07:40:48 Zeus V Panchenko wrote: > > another detail for this nic > > > > dmidecode > > Base Board Information > > Manufacturer: ASUSTeK Computer INC. > > Product Name: AT5NM10-I > > Version: Rev x.0x > > Serial Number: MT7006K15200322 > > > > I did not followed this thread closely, but I checked my new board and it is > the same. > > > uname -a > > FreeBSD 8.2-PRERELEASE amd64 > > > > system was cvsup-ed 2011.01.20 > > > > if_re.c,v 1.160.2.17 2011/01/15 00:32:15 yongari > > > > dmesg > > rgephy0: PHY 1 on miibus0 > > rgephy0: 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: 20:cf:30:89:5e:95 > > re0: [FILTER] > > > > pciconf -lv > > re0@pci0:2:0:0: class=0x020000 card=0x83a31043 chip=0x816810ec rev=0x03 > > hdr=0x00 vendor = 'Realtek Semiconductor' > > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > > class = network > > subclass = ethernet > > > > All details are the same for my board (modulo serial number and MAC, of > course), and in my case it works with no problem, but only in 100 Mb switch > port. In 1 Gb port I have no link. I must verify my cables, port on switch > itself works just fine with another 1 Gb (intel) card. > Would you try a patch at the following URL? http://people.freebsd.org/~yongari/re/rgephy.link.patch3 > > > > while connected directly NIC <-> NIC they flaps too > > > > I will try this against another 1 Gb card too, just to see what happens... in > 100 Mb mode it works just fine, as I mentioned already - running flood ping > with 1472 bytes packets for more than an hour I see only four responses > missing in more than 21 millions tries... > > Regards, > Milan From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 01:20: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 9598D1065674 for ; Mon, 31 Jan 2011 01:20:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 65BFF8FC19 for ; Mon, 31 Jan 2011 01:20:33 +0000 (UTC) Received: by pzk32 with SMTP id 32so889309pzk.13 for ; Sun, 30 Jan 2011 17:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=2jfp99fP6kNBq943hD8i2aHK5kZ+3tiyuJpGJ9TMkzE=; b=E93oVAl9/3MH5mZ9fVqqmrHZBMWJwSbTiDH0TATZP5y1kHf0p5KsRuKcKOzkS3Jkdz VtAyZCSFwaHnTiqtP/NOASoSAI43kpeGxZMDwYU2wwewaAWztNu8L3q/x7xVO5V0Wf9+ ffuVwPKNLtd6FIB/NsweRSA00FluiLHA7JWqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=NwZQF68eVkrRfZ/QmSfYXb9m0mxXExaqg56xuf/U+bIqSvnD8I2CxreNkevEqvuqvI TGMkRUm2WLZx+CDdmSaSFuHBKxvKrKa1oYJ7frqHI9MyZXb566Tp+0KAi3/431XxWrXP JGam1ihW0VxHOo+ipvRa+Z3TA745CXPlm1R5c= Received: by 10.142.223.3 with SMTP id v3mr5467788wfg.20.1296436832672; Sun, 30 Jan 2011 17:20:32 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id f5sm17716192wfo.4.2011.01.30.17.20.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 17:20:31 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 30 Jan 2011 17:20:32 -0800 From: Pyun YongHyeon Date: Sun, 30 Jan 2011 17:20:32 -0800 To: freebsd-net@freebsd.org Message-ID: <20110131012032.GD1323@michelle.cdnetworks.com> References: <20101112070759.GA36248@relay.ibs.dn.ua> <20101112230000.GD22460@michelle.cdnetworks.com> <20110121125917.GA48950@relay.ibs.dn.ua> <20110130064048.GA14888@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110130064048.GA14888@relay.ibs.dn.ua> User-Agent: Mutt/1.4.2.3i Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 01:20:33 -0000 On Sun, Jan 30, 2011 at 08:40:48AM +0200, Zeus V Panchenko wrote: > another detail for this nic > > dmidecode > Base Board Information > Manufacturer: ASUSTeK Computer INC. > Product Name: AT5NM10-I > Version: Rev x.0x > Serial Number: MT7006K15200322 > > uname -a > FreeBSD 8.2-PRERELEASE amd64 > > system was cvsup-ed 2011.01.20 > > if_re.c,v 1.160.2.17 2011/01/15 00:32:15 yongari > > dmesg > rgephy0: PHY 1 on miibus0 > rgephy0: 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: 20:cf:30:89:5e:95 > re0: [FILTER] > > pciconf -lv > re0@pci0:2:0:0: class=0x020000 card=0x83a31043 chip=0x816810ec rev=0x03 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet > > > while connected directly NIC <-> NIC they flaps too > > so, the issue with switch related causes can be excluded i believe > The RTL8168/8111D sample board I have does not show this kind of issue. This happens only when established link is 1000baseT, right? I slightly changed PHY's link detection code so would you try that patch at the following URL? http://people.freebsd.org/~yongari/re/rgephy.link.patch3 From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 02: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 A51691065672 for ; Mon, 31 Jan 2011 02:07:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 737948FC0C for ; Mon, 31 Jan 2011 02:07:04 +0000 (UTC) Received: by pzk32 with SMTP id 32so894489pzk.13 for ; Sun, 30 Jan 2011 18:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=A+Tj6uUZImjsNzeNESfxGX7pqUgorbUPEm3tmWwLeds=; b=dEybCQRWmCYahm7J/bWOzHlAkW5yde8pr5iXdvGfoeBWhNT4lHqX5uvX+F2asj7Zoa fWlMUmEsEPi0XxowRYND97LTN99JAj3xHGxlNEDd73Kd3Gyibo/BU7NPT/NmJLEGkZ/J vhSMesqTm07XZFg4wJrbS5lbfyyKtOeOxaSq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=q+PxpuBndMseTv0/0OFTA+pFkeNp6niLcrhDLIcnUvRhGhZEpq1gSnBXjLldMscRTg td4C5sn8eAn5zarX99xFJuQ5IpuNrh4zmIEhfMXvuf2gg4wY6HGFWZZj4Kz1/4wTGZCm kA98gLtM+q2rvK9VSICqt3ES0JM2fQy2wNlZo= Received: by 10.142.125.18 with SMTP id x18mr5477027wfc.352.1296439622578; Sun, 30 Jan 2011 18:07:02 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v19sm27571620wfh.12.2011.01.30.18.07.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 18:07:01 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 30 Jan 2011 18:07:02 -0800 From: Pyun YongHyeon Date: Sun, 30 Jan 2011 18:07:02 -0800 To: Milan Obuch Message-ID: <20110131020702.GA1229@michelle.cdnetworks.com> References: <20110121125917.GA48950@relay.ibs.dn.ua> <20110130064048.GA14888@relay.ibs.dn.ua> <201101301453.18500.freebsd-net@dino.sk> <20110131011510.GC1323@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110131011510.GC1323@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, zeus@ibs.dn.ua Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 02:07:04 -0000 On Sun, Jan 30, 2011 at 05:15:10PM -0800, Pyun YongHyeon wrote: > On Sun, Jan 30, 2011 at 02:53:15PM +0100, Milan Obuch wrote: > > On Sunday 30 January 2011 07:40:48 Zeus V Panchenko wrote: > > > another detail for this nic > > > > > > dmidecode > > > Base Board Information > > > Manufacturer: ASUSTeK Computer INC. > > > Product Name: AT5NM10-I > > > Version: Rev x.0x > > > Serial Number: MT7006K15200322 > > > > > > > I did not followed this thread closely, but I checked my new board and it is > > the same. > > > > > uname -a > > > FreeBSD 8.2-PRERELEASE amd64 > > > > > > system was cvsup-ed 2011.01.20 > > > > > > if_re.c,v 1.160.2.17 2011/01/15 00:32:15 yongari > > > > > > dmesg > > > rgephy0: PHY 1 on miibus0 > > > rgephy0: 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: 20:cf:30:89:5e:95 > > > re0: [FILTER] > > > > > > pciconf -lv > > > re0@pci0:2:0:0: class=0x020000 card=0x83a31043 chip=0x816810ec rev=0x03 > > > hdr=0x00 vendor = 'Realtek Semiconductor' > > > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > > > class = network > > > subclass = ethernet > > > > > > > All details are the same for my board (modulo serial number and MAC, of > > course), and in my case it works with no problem, but only in 100 Mb switch > > port. In 1 Gb port I have no link. I must verify my cables, port on switch > > itself works just fine with another 1 Gb (intel) card. > > > > Would you try a patch at the following URL? > http://people.freebsd.org/~yongari/re/rgephy.link.patch3 > Previous one had a bug, please use updated one. http://people.freebsd.org/~yongari/re/rgephy.link.patch4 > > > > > > while connected directly NIC <-> NIC they flaps too > > > > > > > I will try this against another 1 Gb card too, just to see what happens... in > > 100 Mb mode it works just fine, as I mentioned already - running flood ping > > with 1472 bytes packets for more than an hour I see only four responses > > missing in more than 21 millions tries... > > > > Regards, > > Milan From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 02:07: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 74691106566C for ; Mon, 31 Jan 2011 02:07:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42C418FC1B for ; Mon, 31 Jan 2011 02:07:20 +0000 (UTC) Received: by pwi10 with SMTP id 10so1119229pwi.13 for ; Sun, 30 Jan 2011 18:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=4QLAYQh5Z9sW+mZ1zrnmTHtYg55K83BsPzesUtm5+vw=; b=lXddwgbREdKEL6WhJJKu6vZ71JYVh3iYSABsXeHT643ds/GEZZmjfsHNRYvlksfd5o VwYwebJRKFxEuocC/BDYmnVMfY3K+cfG+f4da0/eAvEFsnRpHCU2nwQZJGTzTCih84Ia /NPzu160B+9aV2vfpqb/g0IHrE/DzSJtdGZng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Q922mxDf4C1jwAWXbRCWgm7CaBP1x8wc2N0OV7vLDFwux28GvfseS07U4w3rzRTIvu 0wZAaYYBrdF9nDPUzWWGs6gKl6Txs0BzOx0MLv6+ALvC0kGZF8dLmHVPLBU4LlRG+Uph vsTFK+XHV/WvgKJoO4ND6g29HI7fE2Lsz5h+0= Received: by 10.142.185.17 with SMTP id i17mr5503822wff.389.1296439639456; Sun, 30 Jan 2011 18:07:19 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w14sm27570043wfd.6.2011.01.30.18.07.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 18:07:18 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 30 Jan 2011 18:07:20 -0800 From: Pyun YongHyeon Date: Sun, 30 Jan 2011 18:07:20 -0800 To: freebsd-net@freebsd.org Message-ID: <20110131020720.GB1229@michelle.cdnetworks.com> References: <20101112070759.GA36248@relay.ibs.dn.ua> <20101112230000.GD22460@michelle.cdnetworks.com> <20110121125917.GA48950@relay.ibs.dn.ua> <20110130064048.GA14888@relay.ibs.dn.ua> <20110131012032.GD1323@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110131012032.GD1323@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 02:07:20 -0000 On Sun, Jan 30, 2011 at 05:20:32PM -0800, Pyun YongHyeon wrote: > On Sun, Jan 30, 2011 at 08:40:48AM +0200, Zeus V Panchenko wrote: > > another detail for this nic > > > > dmidecode > > Base Board Information > > Manufacturer: ASUSTeK Computer INC. > > Product Name: AT5NM10-I > > Version: Rev x.0x > > Serial Number: MT7006K15200322 > > > > uname -a > > FreeBSD 8.2-PRERELEASE amd64 > > > > system was cvsup-ed 2011.01.20 > > > > if_re.c,v 1.160.2.17 2011/01/15 00:32:15 yongari > > > > dmesg > > rgephy0: PHY 1 on miibus0 > > rgephy0: 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: 20:cf:30:89:5e:95 > > re0: [FILTER] > > > > pciconf -lv > > re0@pci0:2:0:0: class=0x020000 card=0x83a31043 chip=0x816810ec rev=0x03 hdr=0x00 > > vendor = 'Realtek Semiconductor' > > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > > class = network > > subclass = ethernet > > > > > > while connected directly NIC <-> NIC they flaps too > > > > so, the issue with switch related causes can be excluded i believe > > > > The RTL8168/8111D sample board I have does not show this kind of > issue. This happens only when established link is 1000baseT, right? > I slightly changed PHY's link detection code so would you try that > patch at the following URL? > http://people.freebsd.org/~yongari/re/rgephy.link.patch3 Previous one had a bug, please update one. http://people.freebsd.org/~yongari/re/rgephy.link.patch4 From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 06:32:08 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 786A4106566C; Mon, 31 Jan 2011 06:32:08 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id E27CE8FC17; Mon, 31 Jan 2011 06:32:07 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0V6VxfC048545; Mon, 31 Jan 2011 12:31:59 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D46575A.802@rdtc.ru> Date: Mon, 31 Jan 2011 12:31:54 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> In-Reply-To: <201101141437.55421.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Przemyslaw Frasunek , Mike Tancsa Subject: Re: panic: bufwrite: buffer is not busy??? 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, 31 Jan 2011 06:32:08 -0000 On 15.01.2011 01:37, John Baldwin wrote: > On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote: >> On 14.01.2011 18:46, Mike Tancsa wrote: >> >>>> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE >>>> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and >>>> runs FreeBSD 7.3-RELEASE. >>>> >>>> I'm experiencing stability issues related to Netgraph. None of above routers can >>>> survive more than 20-30 days of uptime under typical load. There are different >>>> flavors of kernel panics, but all are somehow related to netgraph. Typical >>>> backtraces follow >>> >>> I also have stability issues on RELENG_8. >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=153497 >> >> And for one of my servers (8.2-PRERELEASE/amd64 with 4GB RAM) I just cannot obtain crashdump, >> it cannot finish to write it. For example, it happened an hour ago: >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 2; apic id = 04 >> fault virtual address = 0x200000040 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff803cc979 > > Assuming your kernel is built with debug symbols (which is the default), one > thing you can do to aid in debugging is this: > > gdb /boot/kernel/kernel > (gdb) l *0xffffffff803cc979 > > Where the 0xfff bit is the part of the 'instruction pointer' value > above after the colon (:) and then send the output of that in your e-mail to > the list. This allows us to the source line at which the fault occurred. > Yesterday I've got another kernel panic of this kind with RELENG_8 updated 20 January and it still could not finish writing of crashdump: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x200000030 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803c1315 stack pointer = 0x28:0xffffff8000130780 frame pointer = 0x28:0xffffff80001307a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq259: em1:rx 0) trap number = 12 panic: page fault cpuid = 1 Uptime: 19h41m8s Dumping 4087 MB (3 chunks) chunk 0: 1MB (150 pages) ... ok chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? cpuid = 1 Uptime: 19h41m9s Automatic reboot in 15 seconds - press a key on the console to abort This time I have all debug symbols handy: # gdb kernel GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... (gdb) l *0xffffffff803c1315 0xffffffff803c1315 is in ng_address_hook (/home/src/sys/netgraph/ng_base.c:3504). 3499 * Quick sanity check.. 3500 * Since a hook holds a reference on it's node, once we know 3501 * that the peer is still connected (even if invalid,) we know 3502 * that the peer node is present, though maybe invalid. 3503 */ 3504 if ((hook == NULL) || 3505 NG_HOOK_NOT_VALID(hook) || 3506 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || 3507 NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { 3508 NG_FREE_ITEM(item); From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 08:56: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 9C4351065709; Mon, 31 Jan 2011 08:56:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id E31C78FC14; Mon, 31 Jan 2011 08:56:24 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p0V8KEPe040540 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 00:20:16 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D4670C2.4050500@freebsd.org> Date: Mon, 31 Jan 2011 00:20:18 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eugene Grosbein References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> In-Reply-To: <4D46575A.802@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Przemyslaw Frasunek , John Baldwin , Mike Tancsa Subject: Re: panic: bufwrite: buffer is not busy??? 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, 31 Jan 2011 08:56:25 -0000 On 1/30/11 10:31 PM, Eugene Grosbein wrote: > On 15.01.2011 01:37, John Baldwin wrote: >> On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote: >>> On 14.01.2011 18:46, Mike Tancsa wrote: >>> >>>>> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE >>>>> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and >>>>> runs FreeBSD 7.3-RELEASE. >>>>> >>>>> I'm experiencing stability issues related to Netgraph. None of above routers can >>>>> survive more than 20-30 days of uptime under typical load. There are different >>>>> flavors of kernel panics, but all are somehow related to netgraph. Typical >>>>> backtraces follow >>>> I also have stability issues on RELENG_8. >>>> >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=153497 >>> And for one of my servers (8.2-PRERELEASE/amd64 with 4GB RAM) I just cannot obtain crashdump, >>> it cannot finish to write it. For example, it happened an hour ago: >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 2; apic id = 04 >>> fault virtual address = 0x200000040 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0xffffffff803cc979 >> Assuming your kernel is built with debug symbols (which is the default), one >> thing you can do to aid in debugging is this: >> >> gdb /boot/kernel/kernel >> (gdb) l *0xffffffff803cc979 >> >> Where the 0xfff bit is the part of the 'instruction pointer' value >> above after the colon (:) and then send the output of that in your e-mail to >> the list. This allows us to the source line at which the fault occurred. >> > Yesterday I've got another kernel panic of this kind with RELENG_8 updated 20 January > and it still could not finish writing of crashdump: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 02 > fault virtual address = 0x200000030 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff803c1315 > stack pointer = 0x28:0xffffff8000130780 > frame pointer = 0x28:0xffffff80001307a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq259: em1:rx 0) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 19h41m8s > Dumping 4087 MB (3 chunks) > chunk 0: 1MB (150 pages) ... ok > chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? > cpuid = 1 > Uptime: 19h41m9s > Automatic reboot in 15 seconds - press a key on the console to abort > > This time I have all debug symbols handy: > > > # gdb kernel > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > (gdb) l *0xffffffff803c1315 > 0xffffffff803c1315 is in ng_address_hook (/home/src/sys/netgraph/ng_base.c:3504). > 3499 * Quick sanity check.. > 3500 * Since a hook holds a reference on it's node, once we know > 3501 * that the peer is still connected (even if invalid,) we know > 3502 * that the peer node is present, though maybe invalid. > 3503 */ > 3504 if ((hook == NULL) || > 3505 NG_HOOK_NOT_VALID(hook) || > 3506 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || > 3507 NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { > 3508 NG_FREE_ITEM(item); replace with: 3504 if ((hook == NULL) || 3505 NG_HOOK_NOT_VALID(hook) || ((peer = NG_HOOK_PEER(hook)) == NULL) || 3506 NG_HOOK_NOT_VALID(peer) || ((peernode = NG_PEER_NODE(hook)) == NULL) || 3507 NG_NODE_NOT_VALID(peernode)) { if (peer) kassert((peernode != NULL), ("peer node NULL wile peer hook exists")); 3508 NG_FREE_ITEM(item); > _______________________________________________ > 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 Jan 31 09:49: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 94269106566C for ; Mon, 31 Jan 2011 09:49:29 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id C86718FC08 for ; Mon, 31 Jan 2011 09:49:28 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0V9nPKW049602; Mon, 31 Jan 2011 15:49:26 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D4685A0.6040400@rdtc.ru> Date: Mon, 31 Jan 2011 15:49:20 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Julian Elischer References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> In-Reply-To: <4D4670C2.4050500@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: panic: bufwrite: buffer is not busy??? 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, 31 Jan 2011 09:49:29 -0000 On 31.01.2011 14:20, Julian Elischer wrote: >> # gdb kernel >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd"... >> (gdb) l *0xffffffff803c1315 >> 0xffffffff803c1315 is in ng_address_hook (/home/src/sys/netgraph/ng_base.c:3504). >> 3499 * Quick sanity check.. >> 3500 * Since a hook holds a reference on it's node, once we know >> 3501 * that the peer is still connected (even if invalid,) we know >> 3502 * that the peer node is present, though maybe invalid. >> 3503 */ >> 3504 if ((hook == NULL) || >> 3505 NG_HOOK_NOT_VALID(hook) || >> 3506 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || >> 3507 NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { >> 3508 NG_FREE_ITEM(item); > > > replace with: > > 3504 if ((hook == NULL) || > 3505 NG_HOOK_NOT_VALID(hook) || > ((peer = NG_HOOK_PEER(hook)) == NULL) || > 3506 NG_HOOK_NOT_VALID(peer) || > ((peernode = NG_PEER_NODE(hook)) == NULL) || > 3507 NG_NODE_NOT_VALID(peernode)) { > if (peer) > kassert((peernode != NULL), ("peer node NULL wile peer hook exists")); > 3508 NG_FREE_ITEM(item); > It does not compile: /home/src/sys/netgraph/ng_base.c: In function 'ng_address_hook': /home/src/sys/netgraph/ng_base.c:3511: warning: implicit declaration of function 'kassert' /home/src/sys/netgraph/ng_base.c:3511: warning: nested extern declaration of 'kassert' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 11:07: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 CE9F61065696 for ; Mon, 31 Jan 2011 11:07:05 +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 BD0BB8FC2D for ; Mon, 31 Jan 2011 11:07: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 p0VB75cW091836 for ; Mon, 31 Jan 2011 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0VB75LO091834 for freebsd-net@FreeBSD.org; Mon, 31 Jan 2011 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Jan 2011 11:07:05 GMT Message-Id: <201101311107.p0VB75LO091834@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, 31 Jan 2011 11:07:05 -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/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154284 net [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface 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/154006 net [tcp] [patch] tcp "window probe" bug on 64bit o kern/153951 net [ixgbe] Intel 10GBase-LR Ethernet card detected as 10G o kern/153938 net [run] [panic] [patch] Workaround for use-after-free pa 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/153671 net [em] [panic] 8.2-PRERELEASE repeatable kernel in if_em 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/153255 net [panic] 8.2-PRERELEASE repeatable kernel panic under h 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/152360 net [dummynet] [panic] Crash related to dummynet. o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] encapsulate vlan in ng_ether before output to i 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 bin/150642 net netstat(1) doesn't print anything for SCTP sockets 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 kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x 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/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall 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/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning 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 o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/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/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. o kern/144987 net [wpi] [panic] injecting packets with wlaninject using 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/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout 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 conf/143079 net hostapd(8) startup missing multi wlan functionality 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/140796 net [ath] [panic] privileged instruction fault 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/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/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 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/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/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o 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/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/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 conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic o kern/125501 net [ath] atheros cardbus driver hangs f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/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 kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo 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/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/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 p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! 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] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working 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/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi 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 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/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if 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/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 371 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 12:15: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 C0985106566B for ; Mon, 31 Jan 2011 12:15:12 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 38CC38FC12 for ; Mon, 31 Jan 2011 12:15:11 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id p0VCF95L021991; Mon, 31 Jan 2011 14:15:09 +0200 (EET) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id p0VCF99n021990; Mon, 31 Jan 2011 14:15:09 +0200 (EET) Date: Mon, 31 Jan 2011 14:15:09 +0200 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20110131121509.GE14888@relay.ibs.dn.ua> Mail-Followup-To: freebsd-net@freebsd.org, Pyun YongHyeon References: <20101112070759.GA36248@relay.ibs.dn.ua> <20101112230000.GD22460@michelle.cdnetworks.com> <20110121125917.GA48950@relay.ibs.dn.ua> <20110130064048.GA14888@relay.ibs.dn.ua> <20110131012032.GD1323@michelle.cdnetworks.com> <20110131020720.GB1229@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110131020720.GB1229@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Cc: Pyun YongHyeon Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus@ibs.dn.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 12:15:12 -0000 Pyun YongHyeon (pyunyh@gmail.com) [11.01.31 04:08] wrote: > > The RTL8168/8111D sample board I have does not show this kind of > > issue. This happens only when established link is 1000baseT, right? > > I slightly changed PHY's link detection code so would you try that > > patch at the following URL? > > http://people.freebsd.org/~yongari/re/rgephy.link.patch3 > > Previous one had a bug, please update one. > http://people.freebsd.org/~yongari/re/rgephy.link.patch4 no change :( interface continues to flap -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 12:35:08 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 00B79106566C; Mon, 31 Jan 2011 12:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 83DEA8FC1A; Mon, 31 Jan 2011 12:35:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 88D4B41C705; Mon, 31 Jan 2011 13:35:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id l3Um-DzJWLjd; Mon, 31 Jan 2011 13:35:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id AAD6641C710; Mon, 31 Jan 2011 13:35:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 97B084448F3; Mon, 31 Jan 2011 12:32:15 +0000 (UTC) Date: Mon, 31 Jan 2011 12:32:15 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Eugene Grosbein In-Reply-To: <4D4685A0.6040400@rdtc.ru> Message-ID: <20110131122926.C39951@maildrop.int.zabbadoz.net> References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D4685A0.6040400@rdtc.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: panic: bufwrite: buffer is not busy??? 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, 31 Jan 2011 12:35:08 -0000 On Mon, 31 Jan 2011, Eugene Grosbein wrote: > On 31.01.2011 14:20, Julian Elischer wrote: > >>> # gdb kernel >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and you are >>> welcome to change it and/or distribute copies of it under certain conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for details. >>> This GDB was configured as "amd64-marcel-freebsd"... >>> (gdb) l *0xffffffff803c1315 >>> 0xffffffff803c1315 is in ng_address_hook (/home/src/sys/netgraph/ng_base.c:3504). >>> 3499 * Quick sanity check.. >>> 3500 * Since a hook holds a reference on it's node, once we know >>> 3501 * that the peer is still connected (even if invalid,) we know >>> 3502 * that the peer node is present, though maybe invalid. >>> 3503 */ >>> 3504 if ((hook == NULL) || >>> 3505 NG_HOOK_NOT_VALID(hook) || >>> 3506 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || >>> 3507 NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { >>> 3508 NG_FREE_ITEM(item); >> >> >> replace with: which is essentially what I had suggested in the formerly mentioned PR already (just remove the first printf macro). >> 3504 if ((hook == NULL) || >> 3505 NG_HOOK_NOT_VALID(hook) || >> ((peer = NG_HOOK_PEER(hook)) == NULL) || >> 3506 NG_HOOK_NOT_VALID(peer) || >> ((peernode = NG_PEER_NODE(hook)) == NULL) || >> 3507 NG_NODE_NOT_VALID(peernode)) { >> if (peer) >> kassert((peernode != NULL), ("peer node NULL wile peer hook exists")); >> 3508 NG_FREE_ITEM(item); >> The problem is that it will not help to fix the race; if you go up in the same file you'll find another similar one of these checks with a scary rev 1.1. (I think) comment (that you, Julian, should know very well;-) The solution that this needs is: proper locking. > It does not compile: > > /home/src/sys/netgraph/ng_base.c: In function 'ng_address_hook': > /home/src/sys/netgraph/ng_base.c:3511: warning: implicit declaration of function 'kassert' > /home/src/sys/netgraph/ng_base.c:3511: warning: nested extern declaration of 'kassert' yeah KASSERT is upper case. > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > _______________________________________________ > 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" > -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 12:52: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 B4B1D1065693; Mon, 31 Jan 2011 12:52:31 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 82AC88FC12; Mon, 31 Jan 2011 12:52:30 +0000 (UTC) Received: by qwj9 with SMTP id 9so5286257qwj.13 for ; Mon, 31 Jan 2011 04:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Tw3Sv0zglsAU1lsKvFiuI5HPDRQPZzRLp254oM0gdjg=; b=r67arro8ZcGY2s55eKzLUdqoXyGKNugTBTqA1cmpX8+vCZysfgH+HPVgvuFQLNO6yB RtTtCzBX07xzmXFhamtE+r10tt3hA5aF0j2MqJkZxCwPDZE1gVTvWvvzbFMXZvxY+37J tjYcnH16gAvtfHZFp02SMYG6a/rMG8nXDIvKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=YpGrw4OlPeO6vKO1X4Aav1GDXrOqwxtz2sg40cNfw4D8AoKfxBiOGp5H0LAi0vPm8z v53xAE2+pl1ewDRDit93Go8lW5GzitVnWgf3P03FQORWjnuIZnQcgwjDB33/jwPyXG03 RsN5s+JpfglhIS7Qz1fIp5zy6gOvs/lbmuiyw= Received: by 10.229.82.14 with SMTP id z14mr4059691qck.257.1296478349631; Mon, 31 Jan 2011 04:52:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.193.9 with HTTP; Mon, 31 Jan 2011 04:52:09 -0800 (PST) In-Reply-To: <4D437B13.1070405@FreeBSD.org> References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> <4D437B13.1070405@FreeBSD.org> From: Ivo Vachkov Date: Mon, 31 Jan 2011 14:52:09 +0200 Message-ID: To: Doug Barton Content-Type: multipart/mixed; boundary=00163646d5be7d227c049b23e38f Cc: FreeBSD Net , bz@freebsd.org Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 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, 31 Jan 2011 12:52:31 -0000 --00163646d5be7d227c049b23e38f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I attach the latest version of the port randomization code as a patch against RELENG_8. Changelog: 1) sysctl variable names are changed to: - 'net.inet.ip.portrange.randomalg.version' - representing the algorithm of choice. - 'net.inet.ip.portrange.randomalg.alg5_tradeoff' - representing the Algorithm 5 computational tradeoff value (the 'N' value in the Algorithm 5 description in the RFC 6056). 2) Code comments are synchronized with the current variable names. Ivo Vachkov On Sat, Jan 29, 2011 at 4:27 AM, Doug Barton wrote: > On 01/28/2011 11:57, Ivo Vachkov wrote: >> >> On Fri, Jan 28, 2011 at 9:00 PM, Doug Barton =C2=A0wr= ote: > >>> How does net.inet.ip.portrange.randomalg sound? I would also suggest th= at >>> the second sysctl be named net.inet.ip.portrange.randomalg.alg5_tradeof= f >>> so >>> that one could do 'sysctl net.inet.ip.portrange.randomalg' and see both >>> values. But I won't quibble on that. :) >>> >> >> I have no objections with this. Since this is my first attempt to >> contribute something back to the community I decided to see how it's >> done before. So I found: >> net.inet.tcp.rfc1323 >> net.inet.tcp.rfc3465 >> net.inet.tcp.rfc3390 >> net.inet.tcp.rfc3042 >> which probably led me in a wrong direction :) > > Yeah, I had actually intended to say something to the effect of "there ar= e > plenty of unfortunate examples in the tree already so your doing it that = way > is totally understandable" but I trimmed it. > >> I understand your point and agree with it. However, my somewhat >> limited understanding of the sysctl internal organization is telling >> me that tree node does not support values. Am I wrong? > > You are likely correct. :) =C2=A0It's an inconvenient fact that often for= get > because that's not the sandbox that I usually play in. > >> If my reasoning >> is correct, maybe I can create the sysctl variables with the following >> names: >> - net.inet.ip.portrange.randomalg (Tree Node) >> - net.inet.ip.portrange.randomalg.alg[orithm] (Leaf Node, to store the >> selected algorithm) > > I would go with "version" to increase the visual distinctiveness. I searc= hed > the current tree and there doesn't seem to be a clear winner for how to > portray "this is the current N/M that is in use" but "version" seems to h= ave > the most representatives. > >> - net.inet.ip.portrange.randomalg.alg5_tradeoff (Leaf Node, to store >> the Algorithm 5 trade-off value) > > I'm assuming this is the "N" value mentioned in the RFC. If so, I commend > you on your choice of "tradeoff" to represent it. :) > > > hth, > > Doug > > -- > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Nothin' ever doesn't change, but nothin' chang= es much. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0-- OK Go > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Breadth of IT experience, and depth of knowled= ge in the DNS. > =C2=A0 =C2=A0 =C2=A0 =C2=A0Yours for the right price. =C2=A0:) =C2=A0http= ://SupersetSolutions.com/ > > --=20 "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie --00163646d5be7d227c049b23e38f Content-Type: text/x-patch; charset=US-ASCII; name="20110131-freebsd-RELENG_8-rfc6056.patch" Content-Disposition: attachment; filename="20110131-freebsd-RELENG_8-rfc6056.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gjldn5a20 ZGlmZiAtciAwZDY3ZjljOTgyZjcgc3JjL3N5cy9uZXRpbmV0L2luX3BjYi5jCi0tLSBhL3NyYy9z eXMvbmV0aW5ldC9pbl9wY2IuYwlNb24gSmFuIDMxIDExOjM1OjI0IDIwMTEgKzAyMDAKKysrIGIv c3JjL3N5cy9uZXRpbmV0L2luX3BjYi5jCU1vbiBKYW4gMzEgMTQ6Mjk6NTIgMjAxMSArMDIwMApA QCAtODEsNiArODEsOCBAQAogI2luY2x1ZGUgPG5ldGlwc2VjL2tleS5oPgogI2VuZGlmIC8qIElQ U0VDICovCiAKKyNpbmNsdWRlIDxzeXMvbWQ1Lmg+CQorCiAjaW5jbHVkZSA8c2VjdXJpdHkvbWFj L21hY19mcmFtZXdvcmsuaD4KIAogLyoKQEAgLTEwOSw2ICsxMTEsOCBAQAogVk5FVF9ERUZJTkUo aW50LCBpcHBvcnRfc3RvcHJhbmRvbSk7CQkvKiB0b2dnbGVkIGJ5IGlwcG9ydF90aWNrICovCiBW TkVUX0RFRklORShpbnQsIGlwcG9ydF90Y3BhbGxvY3MpOwogc3RhdGljIFZORVRfREVGSU5FKGlu dCwgaXBwb3J0X3RjcGxhc3Rjb3VudCk7CitWTkVUX0RFRklORSh1X2ludCwgaXBwb3J0X3JhbmRv bWFsZ192ZXIpID0gMTsJLyogdXNlciBjb250cm9sbGVkIHZpYSBzeXNjdGwgKi8KK1ZORVRfREVG SU5FKHVfaW50LCBpcHBvcnRfcmFuZG9tYWxnX2FsZzVfdHJhZGVvZmYpID0gNTAwOwkvKiB1c2Vy IGNvbnRyb2xsZWQgdmlhIHN5c2N0bCAqLwogCiAjZGVmaW5lCVZfaXBwb3J0X3RjcGxhc3Rjb3Vu dAkJVk5FVChpcHBvcnRfdGNwbGFzdGNvdW50KQogCkBAIC0xNDEsNyArMTQ1LDY4IEBACiAKICN1 bmRlZiBSQU5HRUNISwogCisvKgorICogVXBkYXRlcyBWX2lwcG9ydF9yYW5kb21hbGdfdmVyIHRv IHRoZSBwcm92aWRlZCB2YWx1ZQorICogYW5kIGVuc3VyZXMgaXQgaXMgaW4gdGhlIHN1cHBvcnRl ZCByYW5nZSAoMSAtIDUpCisgKi8KK3N0YXRpYyBpbnQKK3N5c2N0bF9uZXRfcmFuZG9tYWxnX3Zl cnNpb25fY2hlY2soU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwl1X2ludCBhbGdvcml0aG0gPSAq KHVfaW50ICopYXJnMTsKKwlpbnQgZXJyb3I7CisKKyNpZmRlZiBWSU1BR0UKKwllcnJvciA9IHZu ZXRfc3lzY3RsX2hhbmRsZV91aW50KG9pZHAsICZhbGdvcml0aG0sIDAsIHJlcSk7CisjZWxzZQor CWVycm9yID0gc3lzY3RsX2hhbmRsZV9pbnQob2lkcCwgJmFsZ29yaXRobSwgMCwgcmVxKTsKKyNl bmRpZgorCisJaWYgKGVycm9yID09IDApIHsKKwkJc3dpdGNoIChhbGdvcml0aG0pIHsKKwkJY2Fz ZSBJTlBfUkZDNjA1Nl9BTEdfMToKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfMjoKKwkJY2FzZSBJ TlBfUkZDNjA1Nl9BTEdfMzoKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfNDoKKwkJY2FzZSBJTlBf UkZDNjA1Nl9BTEdfNToKKwkJCVZfaXBwb3J0X3JhbmRvbWFsZ192ZXIgPSBhbGdvcml0aG07CisJ CQlicmVhazsKKwkJZGVmYXVsdDoKKwkJCXJldHVybiAoRUlOVkFMKTsKKwkJfQorCX0gCQorCisJ cmV0dXJuIChlcnJvcik7Cit9CisKKy8qCisgKiBVcGRhdGVzIFZfaXBwb3J0X3JhbmRvbWFsZ19h bGc1X3RyYWRlb2ZmIHRvIHByb3ZpZGVkIHZhbHVlCisgKiBhbmQgZW5zdXJlcyBpdCBpcyBpbiB0 aGUgc3VwcG9ydGVkIHJhbmdlICgxIC0gNjU1MzYpCisgKi8KK3N0YXRpYyBpbnQKK3N5c2N0bF9u ZXRfcmFuZG9tYWxnX2FsZzVfdHJhZGVvZmZfY2hlY2soU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sK Kwl1X2ludCB0cmFkZW9mZiA9ICoodV9pbnQgKilhcmcxOworCWludCBlcnJvcjsKKworI2lmZGVm IFZJTUFHRQorCWVycm9yID0gdm5ldF9zeXNjdGxfaGFuZGxlX3VpbnQob2lkcCwgJnRyYWRlb2Zm LCAwLCByZXEpOworI2Vsc2UKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVfaW50KG9pZHAsICZ0cmFk ZW9mZiwgMCwgcmVxKTsKKyNlbmRpZgorCisJaWYgKGVycm9yID09IDApIHsKKwkJaWYgKHRyYWRl b2ZmIDwgMSB8fCB0cmFkZW9mZiA+IDY1NTM2KQorCQkJcmV0dXJuIChFSU5WQUwpOworCQllbHNl CisJCQlWX2lwcG9ydF9yYW5kb21hbGdfYWxnNV90cmFkZW9mZiA9IHRyYWRlb2ZmOworCX0KKwor CXJldHVybiAoZXJyb3IpOworfQorCiBTWVNDVExfTk9ERShfbmV0X2luZXRfaXAsIElQUFJPVE9f SVAsIHBvcnRyYW5nZSwgQ1RMRkxBR19SVywgMCwgIklQIFBvcnRzIik7CitTWVNDVExfTk9ERShf bmV0X2luZXRfaXBfcG9ydHJhbmdlLCBJUFBST1RPX0lQLCByYW5kb21hbGcsIENUTEZMQUdfUlcs IDAsIAorCSJQb3J0IFJhbmRvbWl6YXRpb24gQWxnb3JpdGhtcyIpOwogCiBTWVNDVExfVk5FVF9Q Uk9DKF9uZXRfaW5ldF9pcF9wb3J0cmFuZ2UsIE9JRF9BVVRPLCBsb3dmaXJzdCwKIAlDVExUWVBF X0lOVHxDVExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwcG9ydF9sb3dmaXJzdGF1dG8pLCAwLApAQCAt MTc0LDYgKzIzOSwxNSBAQAogCSZWTkVUX05BTUUoaXBwb3J0X3JhbmRvbXRpbWUpLCAwLAogCSJN aW5pbXVtIHRpbWUgdG8ga2VlcCBzZXF1ZW50YWwgcG9ydCAiCiAJImFsbG9jYXRpb24gYmVmb3Jl IHN3aXRjaGluZyB0byBhIHJhbmRvbSBvbmUiKTsKK1NZU0NUTF9WTkVUX1BST0MoX25ldF9pbmV0 X2lwX3BvcnRyYW5nZV9yYW5kb21hbGcsIE9JRF9BVVRPLCB2ZXJzaW9uLAorCUNUTFRZUEVfVUlO VHxDVExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwcG9ydF9yYW5kb21hbGdfdmVyKSwgMCwKKwkmc3lz Y3RsX25ldF9yYW5kb21hbGdfdmVyc2lvbl9jaGVjaywgIklVIiwgCisJIlJGQyA2MDU2IFBvcnQg cmFuZG9taXphdGlvbiBhbGdvcml0aG0iKTsKK1NZU0NUTF9WTkVUX1BST0MoX25ldF9pbmV0X2lw X3BvcnRyYW5nZV9yYW5kb21hbGcsIE9JRF9BVVRPLAorCWFsZzVfdHJhZGVvZmYsIENUTFRZUEVf VUlOVHxDVExGTEFHX1JXLAorCSZWTkVUX05BTUUoaXBwb3J0X3JhbmRvbWFsZ19hbGc1X3RyYWRl b2ZmKSwgMCwKKwkmc3lzY3RsX25ldF9yYW5kb21hbGdfYWxnNV90cmFkZW9mZl9jaGVjaywgIklV IiwKKwkiUkZDIDYwNTYgQWxnb3JpdGhtIDUgY29tcHV0YXRpb25hbCB0cmFkZS1vZmYiKTsKIAog LyoKICAqIGluX3BjYi5jOiBtYW5hZ2UgdGhlIFByb3RvY29sIENvbnRyb2wgQmxvY2tzLgpAQCAt NDY4LDIxICs1NDIsMTc3IEBACiAJCQlsYXN0ID0gYXV4OwogCQl9CiAKLQkJaWYgKGRvcmFuZG9t KQotCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKwotCQkJCSAgICAoYXJjNHJhbmRvbSgpICUgKGxhc3Qg LSBmaXJzdCkpOwotCiAJCWNvdW50ID0gbGFzdCAtIGZpcnN0OwogCi0JCWRvIHsKLQkJCWlmIChj b3VudC0tIDwgMCkJLyogY29tcGxldGVseSB1c2VkPyAqLwotCQkJCXJldHVybiAoRUFERFJOT1RB VkFJTCk7Ci0JCQkrKypsYXN0cG9ydDsKLQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFz dHBvcnQgPiBsYXN0KQotCQkJCSpsYXN0cG9ydCA9IGZpcnN0OwotCQkJbHBvcnQgPSBodG9ucygq bGFzdHBvcnQpOwotCQl9IHdoaWxlIChpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywgbGFkZHIs Ci0JCSAgICBscG9ydCwgd2lsZCwgY3JlZCkpOworCQkvKiAKKwkJICogQWNjb3JkaW5nIHRvIFJG QyA2MDU2IHRoZXJlIGFyZSA1IChmaXZlKSBwb3NzaWJsZSBhbGdvcml0aG1zCisJCSAqIGZvciBy YW5kb20gcG9ydCBhbGxvY2F0aW9uLiBVc2FnZSBvZiBhIHBhcnRpY3VsYXIgYWxnb3JpdGhtCisJ CSAqIGlzIHNwZWNpZmllZCB3aXRoIHRoZSAnbmV0LmluZXQuaXAucG9ydHJhbmdlLnJhbmRvbWFs Zy52ZXJzaW9uJworCQkgKiBzeXNjdGwgdmFyaWFibGUuIERlZmF1bHQgdmFsdWUgaXMgMSwgd2hp Y2ggcmVwcmVzZW50cyB0aGUKKwkJICogbGVnYWN5IHJhbmRvbSBwb3J0IGFsbG9jYXRpb24gYWxn b3JpdGhtIGluIEZyZWVCU0QuCisJCSAqLworCQlpZiAoZG9yYW5kb20pIHsKKwkJCXN3aXRjaCAo Vl9pcHBvcnRfcmFuZG9tYWxnX3ZlcikgeworCQkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfNToJLyog UmFuZG9tLUluY3JlbWVudHMgUG9ydCBTZWxlY3Rpb24gKi8KKwkJCQlkbyB7CisJCQkJCWlmIChj b3VudC0tIDwgMCkJLyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCQkJcmV0dXJuIChFQUREUk5P VEFWQUlMKTsKKworCQkJCQkqbGFzdHBvcnQgPSBmaXJzdCArICgoYXJjNHJhbmRvbSgpICUgNjU1 MzYpICsgCisJCQkJCSAgICAoYXJjNHJhbmRvbSgpICUgVl9pcHBvcnRfcmFuZG9tYWxnX2FsZzVf dHJhZGVvZmYpICsgMSk7CisKKwkJCQkJaWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9y dCA+IGxhc3QpCisJCQkJCQkqbGFzdHBvcnQgPSBmaXJzdDsKKwkJCQkJbHBvcnQgPSBodG9ucygq bGFzdHBvcnQpOworCQkJCX0gd2hpbGUgKGluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRk ciwKKwkJCQkgICAgbHBvcnQsIHdpbGQsIGNyZWQpKTsKKwkJCQlicmVhazsKKwkJCWNhc2UgSU5Q X1JGQzYwNTZfQUxHXzQ6CS8qIERvdWJsZS1IYXNoIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAq LworCQkJCXsKKwkJCQkJTUQ1X0NUWCBmX2N0eDsKKwkJCQkJTUQ1X0NUWCBnX2N0eDsKKwkJCQkJ dV9pbnQzMl90IEZbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQkJdV9pbnQzMl90IEdbNF0gPSB7 IDAsIDAsIDAsIDAgfTsKKwkJCQkJdV9pbnQzMl90IHNlY3JldF9mWzRdID0geyAwLCAwLCAwLCAw IH07CisJCQkJCXVfaW50MzJfdCBzZWNyZXRfZ1s0XSA9IHsgMCwgMCwgMCwgMCB9OworCQkJCQl1 X2ludDE2X3QgdGFibGVbMTZdOyAKKwkJCQkJdV9pbnQzMl90IGluZGV4ID0gMDsKKwkJCQkJdV9p bnQzMl90IG9mZnNldCA9IDA7CisKKwkJCQkJc2VjcmV0X2ZbMF0gPSBhcmM0cmFuZG9tKCk7CisJ CQkJCXNlY3JldF9mWzFdID0gYXJjNHJhbmRvbSgpOworCQkJCQlzZWNyZXRfZlsyXSA9IGFyYzRy YW5kb20oKTsKKwkJCQkJc2VjcmV0X2ZbM10gPSBhcmM0cmFuZG9tKCk7CisKKwkJCQkJc2VjcmV0 X2dbMF0gPSBhcmM0cmFuZG9tKCk7CisJCQkJCXNlY3JldF9nWzFdID0gYXJjNHJhbmRvbSgpOwor CQkJCQlzZWNyZXRfZ1syXSA9IGFyYzRyYW5kb20oKTsKKwkJCQkJc2VjcmV0X2dbM10gPSBhcmM0 cmFuZG9tKCk7CisKKwkJCQkJZm9yIChpbmRleCA9IDA7IGluZGV4IDwgc2l6ZW9mKHRhYmxlKTsg aW5kZXgrKykKKwkJCQkJCXRhYmxlW2luZGV4XSA9IGFyYzRyYW5kb20oKSAlIDY1NTM2OworCisJ CQkJCU1ENUluaXQoJmZfY3R4KTsKKwkJCQkJTUQ1VXBkYXRlKCZmX2N0eCwgKHVfY2hhciAqKSZp bnAtPmlucF9sYWRkciwKKwkJCQkJICAgIHNpemVvZihpbnAtPmlucF9sYWRkcikpOworCQkJCQlN RDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW5wX2ZhZGRyLAorCQkJCQkgICAgc2l6 ZW9mKGlucC0+aW5wX2ZhZGRyKSk7CisJCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2NoYXIgKikm aW5wLT5pbnBfZnBvcnQsCisJCQkJCSAgICBzaXplb2YoaW5wLT5pbnBfZnBvcnQpKTsKKwkJCQkJ TUQ1VXBkYXRlKCZmX2N0eCwgKHVfY2hhciAqKXNlY3JldF9mLAorCQkJCQkgICAgc2l6ZW9mKHNl Y3JldF9mKSk7CisJCQkJCU1ENUZpbmFsKCh1X2NoYXIgKikmRiwgJmZfY3R4KTsKKworCQkJCQlv ZmZzZXQgPSAoKEZbMF0gXiBGWzFdKSBeIChGWzJdIF4gRlszXSkpOworCisJCQkJCU1ENUluaXQo JmdfY3R4KTsKKwkJCQkJTUQ1VXBkYXRlKCZnX2N0eCwgKHVfY2hhciAqKSZpbnAtPmlucF9sYWRk ciwKKwkJCQkJICAgIHNpemVvZihpbnAtPmlucF9sYWRkcikpOworCQkJCQlNRDVVcGRhdGUoJmdf Y3R4LCAodV9jaGFyICopJmlucC0+aW5wX2ZhZGRyLAorCQkJCQkgICAgc2l6ZW9mKGlucC0+aW5w X2ZhZGRyKSk7CisJCQkJCU1ENVVwZGF0ZSgmZ19jdHgsICh1X2NoYXIgKikmaW5wLT5pbnBfZnBv cnQsCisJCQkJCSAgICBzaXplb2YoaW5wLT5pbnBfZnBvcnQpKTsKKwkJCQkJTUQ1VXBkYXRlKCZn X2N0eCwgKHVfY2hhciAqKXNlY3JldF9nLAorCQkJCQkgICAgc2l6ZW9mKHNlY3JldF9nKSk7CisJ CQkJCU1ENUZpbmFsKCh1X2NoYXIgKikmRywgJmdfY3R4KTsKKworCQkJCQlpbmRleCA9ICgoR1sw XSBeIEdbMV0pIF4gKEdbMl0gXiBHWzNdKSkgJSBzaXplb2YodGFibGUpOworCisJCQkJCWRvIHsK KwkJCQkJCWlmIChjb3VudC0tIDwgMCkJLyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCQkJCXJl dHVybiAoRUFERFJOT1RBVkFJTCk7CisKKwkJCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsgCisJCQkJ CQkgICAgKG9mZnNldCArIHRhYmxlW2luZGV4XSsrKSAlIGNvdW50OworCisJCQkJCQlpZiAoKmxh c3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkJCQkqbGFzdHBvcnQgPSBm aXJzdDsKKwkJCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJCQkJfSB3aGlsZSAoaW5f cGNibG9va3VwX2xvY2FsKHBjYmluZm8sIGxhZGRyLAorCQkJCQkgICAgbHBvcnQsIHdpbGQsIGNy ZWQpKTsKKwkJCQl9CisJCQkJYnJlYWs7CisJCQljYXNlIElOUF9SRkM2MDU2X0FMR18zOgkvKiBT aW1wbGUgSGFzaC1CYXNlZCBQb3J0IFNlbGVjdGlvbiBBbGdvcml0aG0gKi8KKwkJCQl7CisJCQkJ CU1ENV9DVFggZl9jdHg7CisJCQkJCXVfaW50MzJfdCBGWzRdID0geyAwLCAwLCAwLCAwIH07CisJ CQkJCXVfaW50MzJfdCBzZWNyZXRfZls0XSA9IHsgMCwgMCwgMCwgMCB9OworCQkJCQl1X2ludDMy X3Qgb2Zmc2V0ID0gMDsKKworCQkJCQlzZWNyZXRfZlswXSA9IGFyYzRyYW5kb20oKTsKKwkJCQkJ c2VjcmV0X2ZbMV0gPSBhcmM0cmFuZG9tKCk7CisJCQkJCXNlY3JldF9mWzJdID0gYXJjNHJhbmRv bSgpOworCQkJCQlzZWNyZXRfZlszXSA9IGFyYzRyYW5kb20oKTsKKworCQkJCQlNRDVJbml0KCZm X2N0eCk7CisJCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2NoYXIgKikmaW5wLT5pbnBfbGFkZHIs CisJCQkJCSAgICBzaXplb2YoaW5wLT5pbnBfbGFkZHIpKTsKKwkJCQkJTUQ1VXBkYXRlKCZmX2N0 eCwgKHVfY2hhciAqKSZpbnAtPmlucF9mYWRkciwKKwkJCQkJICAgIHNpemVvZihpbnAtPmlucF9m YWRkcikpOworCQkJCQlNRDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW5wX2Zwb3J0 LAorCQkJCQkgICAgc2l6ZW9mKGlucC0+aW5wX2Zwb3J0KSk7CisJCQkJCU1ENVVwZGF0ZSgmZl9j dHgsICh1X2NoYXIgKilzZWNyZXRfZiwKKwkJCQkJICAgIHNpemVvZihzZWNyZXRfZikpOworCQkJ CQlNRDVGaW5hbCgodV9jaGFyICopJkYsICZmX2N0eCk7CisKKwkJCQkJb2Zmc2V0ID0gKChGWzBd IF4gRlsxXSkgXiAoRlsyXSBeIEZbM10pKTsKKworCQkJCQlkbyB7CisJCQkJCQlpZiAoY291bnQt LSA8IDApCS8qIGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZB SUwpOworCisJCQkJCQkqbGFzdHBvcnQgPSBmaXJzdCArICgoYXJjNHJhbmRvbSgpICUgNjU1MzYp ICsgCisJCQkJCQkgICAgKG9mZnNldCAlIDY1NTM2KSkgJSBjb3VudDsKKworCQkJCQkJaWYgKCps YXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3QpCisJCQkJCQkJKmxhc3Rwb3J0ID0g Zmlyc3Q7CisJCQkJCQlscG9ydCA9IGh0b25zKCpsYXN0cG9ydCk7CisJCQkJCX0gd2hpbGUgKGlu X3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwKKwkJCQkJICAgIGxwb3J0LCB3aWxkLCBj cmVkKSk7CQkJCQorCQkJCX0KKwkJCQlicmVhazsKKwkJCWNhc2UgSU5QX1JGQzYwNTZfQUxHXzI6 CS8qIFNpbXBsZSBQb3J0IFJhbmRvbWl6YXRpb24gQWxnb3JpdGhtIElJICovCisJCQkJZG8gewor CQkJCQlpZiAoY291bnQtLSA8IDApCS8qIGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkJCXJldHVy biAoRUFERFJOT1RBVkFJTCk7CisKKwkJCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKyAoYXJjNHJhbmRv bSgpICUgKGxhc3QgLSBmaXJzdCkpOworCisJCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAq bGFzdHBvcnQgPiBsYXN0KQorCQkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJCWxwb3J0ID0g aHRvbnMoKmxhc3Rwb3J0KTsKKwkJCQl9IHdoaWxlIChpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5m bywgbGFkZHIsCisJCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJCQkJYnJlYWs7CisJCQlj YXNlIElOUF9SRkM2MDU2X0FMR18xOgkvKiBTaW1wbGUgUG9ydCBSYW5kb21pemF0aW9uIEFsZ29y aXRobSBJICovCisJCQlkZWZhdWx0OgorCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsgKGFyYzRyYW5k b20oKSAlIChsYXN0IC0gZmlyc3QpKTsKKworCQkJCWRvIHsKKwkJCQkJaWYgKGNvdW50LS0gPCAw KQkvKiBjb21wbGV0ZWx5IHVzZWQ/ICovCisJCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOwor CisJCQkJCSsrKmxhc3Rwb3J0OworCisJCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFz dHBvcnQgPiBsYXN0KQorCQkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJCWxwb3J0ID0gaHRv bnMoKmxhc3Rwb3J0KTsKKwkJCQl9IHdoaWxlIChpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywg bGFkZHIsCisJCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJCQl9CisJCX0gZWxzZSB7CisJ CQlkbyB7CisJCQkJaWYgKGNvdW50LS0gPCAwKSAgICAgICAgLyogY29tcGxldGVseSB1c2VkPyAq LworCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOworCQorCQkJCSsrKmxhc3Rwb3J0OworCisJ CQkJaWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3QpCisJCQkJCSpsYXN0 cG9ydCA9IGZpcnN0OworCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJCX0gd2hpbGUg KGluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwKKwkJCSAgICBscG9ydCwgd2lsZCwg Y3JlZCkpOworCQl9CiAJfQogCSpsYWRkcnAgPSBsYWRkci5zX2FkZHI7CiAJKmxwb3J0cCA9IGxw b3J0OwpkaWZmIC1yIDBkNjdmOWM5ODJmNyBzcmMvc3lzL25ldGluZXQvaW5fcGNiLmgKLS0tIGEv c3JjL3N5cy9uZXRpbmV0L2luX3BjYi5oCU1vbiBKYW4gMzEgMTE6MzU6MjQgMjAxMSArMDIwMAor KysgYi9zcmMvc3lzL25ldGluZXQvaW5fcGNiLmgJTW9uIEphbiAzMSAxNDoyOTo1MiAyMDExICsw MjAwCkBAIC00NTIsNiArNDUyLDE1IEBACiAKICNkZWZpbmUJSU5QX0NIRUNLX1NPQ0tBRihzbywg YWYpCShJTlBfU09DS0FGKHNvKSA9PSBhZikKIAorLyoKKyAqIFJGQzYwNTYgUG9ydCBSYW5kb21p emF0aW9uIEFsZ29yaXRobXMKKyAqLworI2RlZmluZQlJTlBfUkZDNjA1Nl9BTEdfMQkxCS8qIFNp bXBsZSBQb3J0IFJhbmRvbWl6YXRpb24gQWxnb3JpdGhtIEkgKi8KKyNkZWZpbmUJSU5QX1JGQzYw NTZfQUxHXzIJMgkvKiBTaW1wbGUgUG9ydCBSYW5kb21pemF0aW9uIEFsZ29yaXRobSBJSSAqLwor I2RlZmluZQlJTlBfUkZDNjA1Nl9BTEdfMwkzCS8qIFNpbXBsZSBIYXNoLUJhc2VkIFBvcnQgU2Vs ZWN0aW9uIEFsZ29yaXRobSAqLworI2RlZmluZQlJTlBfUkZDNjA1Nl9BTEdfNAk0CS8qIERvdWJs ZS1IYXNoIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAqLworI2RlZmluZQlJTlBfUkZDNjA1Nl9B TEdfNQk1CS8qIFJhbmRvbS1JbmNyZW1lbnRzIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAqLwor CiAjaWZkZWYgX0tFUk5FTAogVk5FVF9ERUNMQVJFKGludCwgaXBwb3J0X3Jlc2VydmVkaGlnaCk7 CiBWTkVUX0RFQ0xBUkUoaW50LCBpcHBvcnRfcmVzZXJ2ZWRsb3cpOwpAQCAtNDY2LDYgKzQ3NSw4 IEBACiBWTkVUX0RFQ0xBUkUoaW50LCBpcHBvcnRfcmFuZG9tdGltZSk7CiBWTkVUX0RFQ0xBUkUo aW50LCBpcHBvcnRfc3RvcHJhbmRvbSk7CiBWTkVUX0RFQ0xBUkUoaW50LCBpcHBvcnRfdGNwYWxs b2NzKTsKK1ZORVRfREVDTEFSRSh1X2ludCwgaXBwb3J0X3JhbmRvbWFsZ192ZXIpOworVk5FVF9E RUNMQVJFKHVfaW50LCBpcHBvcnRfcmFuZG9tYWxnX2FsZzVfdHJhZGVvZmYpOwogCiAjZGVmaW5l CVZfaXBwb3J0X3Jlc2VydmVkaGlnaAlWTkVUKGlwcG9ydF9yZXNlcnZlZGhpZ2gpCiAjZGVmaW5l CVZfaXBwb3J0X3Jlc2VydmVkbG93CVZORVQoaXBwb3J0X3Jlc2VydmVkbG93KQpAQCAtNDgwLDYg KzQ5MSw4IEBACiAjZGVmaW5lCVZfaXBwb3J0X3JhbmRvbXRpbWUJVk5FVChpcHBvcnRfcmFuZG9t dGltZSkKICNkZWZpbmUJVl9pcHBvcnRfc3RvcHJhbmRvbQlWTkVUKGlwcG9ydF9zdG9wcmFuZG9t KQogI2RlZmluZQlWX2lwcG9ydF90Y3BhbGxvY3MJVk5FVChpcHBvcnRfdGNwYWxsb2NzKQorI2Rl ZmluZSBWX2lwcG9ydF9yYW5kb21hbGdfdmVyCVZORVQoaXBwb3J0X3JhbmRvbWFsZ192ZXIpCisj ZGVmaW5lIFZfaXBwb3J0X3JhbmRvbWFsZ19hbGc1X3RyYWRlb2ZmCVZORVQoaXBwb3J0X3JhbmRv bWFsZ19hbGc1X3RyYWRlb2ZmKQogCiBleHRlcm4gc3RydWN0IGNhbGxvdXQgaXBwb3J0X3RpY2tf Y2FsbG91dDsKIApkaWZmIC1yIDBkNjdmOWM5ODJmNyBzcmMvc3lzL25ldGluZXQ2L2luNl9zcmMu YwotLS0gYS9zcmMvc3lzL25ldGluZXQ2L2luNl9zcmMuYwlNb24gSmFuIDMxIDExOjM1OjI0IDIw MTEgKzAyMDAKKysrIGIvc3JjL3N5cy9uZXRpbmV0Ni9pbjZfc3JjLmMJTW9uIEphbiAzMSAxNDoy OTo1MiAyMDExICswMjAwCkBAIC0xMDgsNiArMTA4LDggQEAKICNpbmNsdWRlIDxuZXRpbmV0Ni9z Y29wZTZfdmFyLmg+CiAjaW5jbHVkZSA8bmV0aW5ldDYvbmQ2Lmg+CiAKKyNpbmNsdWRlIDxzeXMv bWQ1Lmg+CisKIHN0YXRpYyBzdHJ1Y3QgbXR4IGFkZHJzZWxfbG9jazsKICNkZWZpbmUJQUREUlNF TF9MT0NLX0lOSVQoKQltdHhfaW5pdCgmYWRkcnNlbF9sb2NrLCAiYWRkcnNlbF9sb2NrIiwgTlVM TCwgTVRYX0RFRikKICNkZWZpbmUJQUREUlNFTF9MT0NLKCkJCW10eF9sb2NrKCZhZGRyc2VsX2xv Y2spCkBAIC05MTksMjMgKzkyMSwxOTUgQEAKIAkJbGFzdCA9IGF1eDsKIAl9CiAKLQlpZiAoZG9y YW5kb20pCi0JCSpsYXN0cG9ydCA9IGZpcnN0ICsgKGFyYzRyYW5kb20oKSAlIChsYXN0IC0gZmly c3QpKTsKLQogCWNvdW50ID0gbGFzdCAtIGZpcnN0OwogCi0JZG8gewotCQlpZiAoY291bnQtLSA8 IDApIHsJLyogY29tcGxldGVseSB1c2VkPyAqLwotCQkJLyogVW5kbyBhbiBhZGRyZXNzIGJpbmQg dGhhdCBtYXkgaGF2ZSBvY2N1cnJlZC4gKi8KLQkJCWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJf YW55OwotCQkJcmV0dXJuIChFQUREUk5PVEFWQUlMKTsKKwkvKgorCSAqIEFjY29yZGluZyB0byBS RkMgNjA1NiB0aGVyZSBhcmUgNSAoZml2ZSkgcG9zc2libGUgYWxnb3JpdGhtcworCSAqIGZvciBy YW5kb20gcG9ydCBhbGxvY2F0aW9uLiBVc2FnZSBvZiBhIHBhcnRpY3VsYXIgYWxnb3JpdGhtCisJ ICogaXMgc3BlY2lmaWVkIHdpdGggdGhlICduZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmFuZG9tYWxn LnZlcnNpb24nCisJICogc3lzY3RsIHZhcmlhYmxlLiBEZWZhdWx0IHZhbHVlIGlzIDEsIHdoaWNo IHJlcHJlc2VudHMgdGhlCisJICogbGVnYWN5IHJhbmRvbSBwb3J0IGFsbG9jYXRpb24gYWxnb3Jp dGhtIGluIEZyZWVCU0QuCisJICovCisJaWYgKGRvcmFuZG9tKSB7CisJCXN3aXRjaCAoVl9pcHBv cnRfcmFuZG9tYWxnX3ZlcikgeworCQljYXNlIElOUF9SRkM2MDU2X0FMR181OgkvKiBSYW5kb20t SW5jcmVtZW50cyBQb3J0IFNlbGVjdGlvbiAqLworCQkJZG8geworCQkJCWlmIChjb3VudC0tIDwg MCkgewkvKiBjb21wbGV0ZWx5IHVzZWQ/ICovCisJCQkJCS8qIFVuZG8gYW4gYWRkcmVzcyBiaW5k IHRoYXQgbWF5IGhhdmUgb2NjdXJyZWQuICovCisJCQkJCWlucC0+aW42cF9sYWRkciA9IGluNmFk ZHJfYW55OworCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOworCQkJCX0KKworCQkJCSpsYXN0 cG9ydCA9IGZpcnN0ICsgKChhcmM0cmFuZG9tKCkgJSA2NTUzNikgKworCQkJCSAgICAoYXJjNHJh bmRvbSgpICUgVl9pcHBvcnRfcmFuZG9tYWxnX2FsZzVfdHJhZGVvZmYpICsgMSk7CisKKwkJCQlp ZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkJKmxhc3Rwb3J0 ID0gZmlyc3Q7CisJCQkJbHBvcnQgPSBodG9ucygqbGFzdHBvcnQpOworCQkJfSB3aGlsZSAoaW42 X3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCAmaW5wLT5pbjZwX2xhZGRyLAorCQkJICAgIGxwb3J0 LCB3aWxkLCBjcmVkKSk7CisJCQlicmVhazsKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfNDogLyog RG91YmxlLUhhc2ggUG9ydCBTZWxlY3Rpb24gQWxnb3JpdGhtICovCisJCQl7CisJCQkJTUQ1X0NU WCBmX2N0eDsKKwkJCQlNRDVfQ1RYIGdfY3R4OworCQkJCXVfaW50MzJfdCBGWzRdID0geyAwLCAw LCAwLCAwIH07CisJCQkJdV9pbnQzMl90IEdbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2lu dDMyX3Qgc2VjcmV0X2ZbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2ludDMyX3Qgc2VjcmV0 X2dbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2ludDE2X3QgdGFibGVbMTZdOworCQkJCXVf aW50MzJfdCBpbmRleCA9IDA7CisJCQkJdV9pbnQzMl90IG9mZnNldCA9IDA7CisKKwkJCQlzZWNy ZXRfZlswXSA9IGFyYzRyYW5kb20oKTsKKwkJCQlzZWNyZXRfZlsxXSA9IGFyYzRyYW5kb20oKTsK KwkJCQlzZWNyZXRfZlsyXSA9IGFyYzRyYW5kb20oKTsKKwkJCQlzZWNyZXRfZlszXSA9IGFyYzRy YW5kb20oKTsKKworCQkJCXNlY3JldF9nWzBdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9n WzFdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9nWzJdID0gYXJjNHJhbmRvbSgpOworCQkJ CXNlY3JldF9nWzNdID0gYXJjNHJhbmRvbSgpOworCisJCQkJZm9yIChpbmRleCA9IDA7IGluZGV4 IDwgc2l6ZW9mKHRhYmxlKTsgaW5kZXgrKykKKwkJCQkJdGFibGVbaW5kZXhdID0gYXJjNHJhbmRv bSgpICUgNjU1MzY7CisKKwkJCQlNRDVJbml0KCZmX2N0eCk7CisJCQkJTUQ1VXBkYXRlKCZmX2N0 eCwgKHVfY2hhciAqKSZpbnAtPmluNnBfbGFkZHIsCisJCQkJICAgIHNpemVvZihpbnAtPmluNnBf bGFkZHIpKTsKKwkJCQlNRDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW42cF9mYWRk ciwKKwkJCQkgICAgc2l6ZW9mKGlucC0+aW42cF9mYWRkcikpOworCQkJCU1ENVVwZGF0ZSgmZl9j dHgsICh1X2NoYXIgKikmaW5wLT5pbnBfZnBvcnQsCisJCQkJICAgIHNpemVvZihpbnAtPmlucF9m cG9ydCkpOworCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2NoYXIgKilzZWNyZXRfZiwKKwkJCQkg ICAgc2l6ZW9mKHNlY3JldF9mKSk7CisJCQkJTUQ1RmluYWwoKHVfY2hhciAqKSZGLCAmZl9jdHgp OworCisJCQkJb2Zmc2V0ID0gKChGWzBdIF4gRlsxXSkgXiAoRlsyXSBeIEZbM10pKTsKKworCQkJ CU1ENUluaXQoJmdfY3R4KTsKKwkJCQlNRDVVcGRhdGUoJmdfY3R4LCAodV9jaGFyICopJmlucC0+ aW42cF9sYWRkciwKKwkJCQkgICAgc2l6ZW9mKGlucC0+aW42cF9sYWRkcikpOworCQkJCU1ENVVw ZGF0ZSgmZ19jdHgsICh1X2NoYXIgKikmaW5wLT5pbjZwX2ZhZGRyLAorCQkJCSAgICBzaXplb2Yo aW5wLT5pbjZwX2ZhZGRyKSk7CisJCQkJTUQ1VXBkYXRlKCZnX2N0eCwgKHVfY2hhciAqKSZpbnAt PmlucF9mcG9ydCwKKwkJCQkgICAgc2l6ZW9mKGlucC0+aW5wX2Zwb3J0KSk7CisJCQkJTUQ1VXBk YXRlKCZnX2N0eCwgKHVfY2hhciAqKXNlY3JldF9nLAorCQkJCSAgICBzaXplb2Yoc2VjcmV0X2cp KTsKKwkJCQlNRDVGaW5hbCgodV9jaGFyICopJkcsICZnX2N0eCk7CisKKwkJCQlpbmRleCA9ICgo R1swXSBeIEdbMV0pIF4gKEdbMl0gXiBHWzNdKSkgJSBzaXplb2YodGFibGUpOworCisJCQkJZG8g eworCQkJCQlpZiAoY291bnQtLSA8IDApIHsJLyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCQkJ LyogVW5kbyBhbiBhZGRyZXNzIGJpbmQgdGhhdCBtYXkgaGF2ZSBvY2N1cnJlZC4gKi8KKwkJCQkJ CWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJfYW55OworCQkJCQkJcmV0dXJuIChFQUREUk5PVEFW QUlMKTsKKwkJCQkJfQorCisJCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsKKwkJCQkJICAgIChvZmZz ZXQgKyB0YWJsZVtpbmRleF0rKykgJSBjb3VudDsKKworCQkJCQlpZiAoKmxhc3Rwb3J0IDwgZmly c3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkJCSpsYXN0cG9ydCA9IGZpcnN0OworCQkJCQls cG9ydCA9IGh0b25zKCpsYXN0cG9ydCk7CisJCQkJfSB3aGlsZSAoaW42X3BjYmxvb2t1cF9sb2Nh bChwY2JpbmZvLCAmaW5wLT5pbjZwX2xhZGRyLAorCQkJCSAgICBscG9ydCwgd2lsZCwgY3JlZCkp OworCQkJfQorCQkJYnJlYWs7CisJCWNhc2UgSU5QX1JGQzYwNTZfQUxHXzM6IC8qIFNpbXBsZSBI YXNoLUJhc2VkIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAqLworCQkJeworCQkJCU1ENV9DVFgg Zl9jdHg7CisJCQkJdV9pbnQzMl90IEZbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2ludDMy X3Qgc2VjcmV0X2ZbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQl1X2ludDMyX3Qgb2Zmc2V0ID0g MDsKKworCQkJCXNlY3JldF9mWzBdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9mWzFdID0g YXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9mWzJdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3Jl dF9mWzNdID0gYXJjNHJhbmRvbSgpOworCisJCQkJTUQ1SW5pdCgmZl9jdHgpOworCQkJCU1ENVVw ZGF0ZSgmZl9jdHgsICh1X2NoYXIgKikmaW5wLT5pbjZwX2xhZGRyLAorCQkJCSAgICBzaXplb2Yo aW5wLT5pbjZwX2xhZGRyKSk7CisJCQkJTUQ1VXBkYXRlKCZmX2N0eCwgKHVfY2hhciAqKSZpbnAt PmluNnBfZmFkZHIsCisJCQkJICAgIHNpemVvZihpbnAtPmluNnBfZmFkZHIpKTsKKwkJCQlNRDVV cGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW5wX2Zwb3J0LAorCQkJCSAgICBzaXplb2Yo aW5wLT5pbnBfZnBvcnQpKTsKKwkJCQlNRDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopc2VjcmV0 X2YsCisJCQkJICAgIHNpemVvZihzZWNyZXRfZikpOworCQkJCU1ENUZpbmFsKCh1X2NoYXIgKikm RiwgJmZfY3R4KTsKKworCQkJCW9mZnNldCA9ICgoRlswXSBeIEZbMV0pIF4gKEZbMl0gXiBGWzNd KSk7CisKKwkJCQlkbyB7CisJCQkJCWlmIChjb3VudC0tIDwgMCkgewkvKiBjb21wbGV0ZWx5IHVz ZWQ/ICovCisJCQkJCQkvKiBVbmRvIGFuIGFkZHJlc3MgYmluZCB0aGF0IG1heSBoYXZlIG9jY3Vy cmVkLiAqLworCQkJCQkJaW5wLT5pbjZwX2xhZGRyID0gaW42YWRkcl9hbnk7CisJCQkJCQlyZXR1 cm4gKEVBRERSTk9UQVZBSUwpOworCQkJCQl9CisKKwkJCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKyAo KGFyYzRyYW5kb20oKSAlIDY1NTM2KSArCisJCQkJCSAgICAob2Zmc2V0ICUgNjU1MzYpKSAlIGNv dW50OworCisJCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0KQor CQkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsK KwkJCQl9IHdoaWxlIChpbjZfcGNibG9va3VwX2xvY2FsKHBjYmluZm8sICZpbnAtPmluNnBfbGFk ZHIsCisJCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJCQl9CisJCQlicmVhazsKKwkJY2Fz ZSBJTlBfUkZDNjA1Nl9BTEdfMjoJLyogU2ltcGxlIFBvcnQgUmFuZG9taXphdGlvbiBBbGdvcml0 aG0gSUkgKi8KKwkJCWRvIHsKKwkJCQlpZiAoY291bnQtLSA8IDApIHsJLyogY29tcGxldGVseSB1 c2VkPyAqLworCQkJCQkvKiBVbmRvIGFuIGFkZHJlc3MgYmluZCB0aGF0IG1heSBoYXZlIG9jY3Vy cmVkLiAqLworCQkJCQlpbnAtPmluNnBfbGFkZHIgPSBpbjZhZGRyX2FueTsKKwkJCQkJcmV0dXJu IChFQUREUk5PVEFWQUlMKTsKKwkJCQl9CisKKwkJCQkqbGFzdHBvcnQgPSBmaXJzdCArIChhcmM0 cmFuZG9tKCkgJSAobGFzdCAtIGZpcnN0KSk7CisKKwkJCQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3Qg fHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJbHBvcnQg PSBodG9ucygqbGFzdHBvcnQpOworCQkJfSB3aGlsZSAoaW42X3BjYmxvb2t1cF9sb2NhbChwY2Jp bmZvLCAmaW5wLT5pbjZwX2xhZGRyLAorCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJCQli cmVhazsKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfMToJLyogU2ltcGxlIFBvcnQgUmFuZG9taXph dGlvbiBBbGdvcml0aG0gSSAqLworCQlkZWZhdWx0OgorCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKyAo YXJjNHJhbmRvbSgpICUgKGxhc3QgLSBmaXJzdCkpOworCisJCQlkbyB7CisJCQkJaWYgKGNvdW50 LS0gPCAwKSB7CS8qIGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkJLyogVW5kbyBhbiBhZGRyZXNz IGJpbmQgdGhhdCBtYXkgaGF2ZSBvY2N1cnJlZC4gKi8KKwkJCQkJaW5wLT5pbjZwX2xhZGRyID0g aW42YWRkcl9hbnk7CisJCQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7CisJCQkJfQorCisJCQkJ KysqbGFzdHBvcnQ7CisKKwkJCQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4g bGFzdCkKKwkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJbHBvcnQgPSBodG9ucygqbGFzdHBv cnQpOworCQkJfSB3aGlsZSAoaW42X3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCAmaW5wLT5pbjZw X2xhZGRyLAorCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CiAJCX0KLQkJKysqbGFzdHBvcnQ7 Ci0JCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0KQotCQkJKmxhc3Rw b3J0ID0gZmlyc3Q7Ci0JCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKLQl9IHdoaWxlIChpbjZf cGNibG9va3VwX2xvY2FsKHBjYmluZm8sICZpbnAtPmluNnBfbGFkZHIsCi0JICAgIGxwb3J0LCB3 aWxkLCBjcmVkKSk7CisJfSBlbHNlIHsKKwkJZG8geworCQkJaWYgKGNvdW50LS0gPCAwKSB7CS8q IGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkvKiBVbmRvIGFuIGFkZHJlc3MgYmluZCB0aGF0IG1h eSBoYXZlIG9jY3VycmVkLiAqLworCQkJCWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJfYW55Owor CQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7CisJCQl9CisKKwkJCSsrKmxhc3Rwb3J0OworCisJ CQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkqbGFzdHBv cnQgPSBmaXJzdDsKKwkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJfSB3aGlsZSAoaW42 X3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCAmaW5wLT5pbjZwX2xhZGRyLAorCQkgICAgbHBvcnQs IHdpbGQsIGNyZWQpKTsKKwl9CiAKIAlpbnAtPmlucF9scG9ydCA9IGxwb3J0OwogCWlmIChpbl9w Y2JpbnNoYXNoKGlucCkgIT0gMCkgewo= --00163646d5be7d227c049b23e38f-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 13:24: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 51F9210656AB for ; Mon, 31 Jan 2011 13:24:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 891338FC1F for ; Mon, 31 Jan 2011 13:24:38 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p0VCsesU089679; Mon, 31 Jan 2011 15:54:40 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p0VCseuH089678; Mon, 31 Jan 2011 15:54:40 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 31 Jan 2011 15:54:40 +0300 From: Gleb Smirnoff To: Przemyslaw Frasunek Message-ID: <20110131125440.GK62007@FreeBSD.org> References: <4D3011DB.9050900@frasunek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4D3011DB.9050900@frasunek.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:24:40 -0000 On Fri, Jan 14, 2011 at 10:05:31AM +0100, Przemyslaw Frasunek wrote: P> Hello, P> P> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE P> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and P> runs FreeBSD 7.3-RELEASE. P> P> I'm experiencing stability issues related to Netgraph. None of above routers can P> survive more than 20-30 days of uptime under typical load. There are different P> flavors of kernel panics, but all are somehow related to netgraph. Typical P> backtraces follow: P> P> (kgdb) bt P> #1 0xc0836ac7 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 P> #2 0xc0836d99 in panic (fmt=Variable "fmt" is not available. P> ) at ../../../kern/kern_shutdown.c:574 P> #3 0xc0b5ef1c in trap_fatal (frame=0xe7ce6820, eva=152) P> at ../../../i386/i386/trap.c:950 P> #4 0xc0b5f1a0 in trap_pfault (frame=0xe7ce6820, usermode=0, eva=152) P> at ../../../i386/i386/trap.c:863 P> #5 0xc0b5fb95 in trap (frame=0xe7ce6820) at ../../../i386/i386/trap.c:541 P> #6 0xc0b42e7b in calltrap () at ../../../i386/i386/exception.s:166 P> #7 0xc5f486b9 in ng_name2noderef (here=0xc62a0b80, name=0xe7ce6894 "ng366") P> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:896 P> #8 0xc5f488cc in ng_path2noderef (here=0xc62a0b80, P> address=0xcc4c2110 "ng366:", destp=0xe7ce6ac8, lasthook=0xe7ce6ac4) P> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1673 P> #9 0xc5f48cc0 in ng_address_path (here=0xc62a0b80, item=0xc5e42ae0, P> address=0xcc4c2110 "ng366:", retaddr=0) P> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3488 P> #10 0xc5f431d3 in ngc_send (so=0xc5b53340, flags=0, m=0xd4c6cb00, P> addr=0xccac9780, control=0x0, td=0xc65a2b40) P> at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:288 P> #11 0xc0894bfa in sosend_generic (so=0xc5b53340, addr=0xccac9780, P> uio=0xe7ce6be8, top=0xd4c6cb00, control=0x0, flags=0, td=0xc65a2b40) P> at ../../../kern/uipc_socket.c:1243 P> #12 0xc0890a3f in sosend (so=0xc5b53340, addr=0xccac9780, uio=0xe7ce6be8, P> top=0x0, control=0x0, flags=0, td=0xc65a2b40) P> at ../../../kern/uipc_socket.c:1285 P> #13 0xc0897fa6 in kern_sendit (td=0xc65a2b40, s=5, mp=0xe7ce6c64, flags=0, P> control=0x0, segflg=UIO_USERSPACE) at ../../../kern/uipc_syscalls.c:805 P> #14 0xc089b181 in sendit (td=0xc65a2b40, s=5, mp=0xe7ce6c64, flags=0) P> at ../../../kern/uipc_syscalls.c:742 P> #15 0xc089b298 in sendto (td=0xc65a2b40, uap=0xe7ce6cfc) P> at ../../../kern/uipc_syscalls.c:857 P> #16 0xc0b5f4f5 in syscall (frame=0xe7ce6d38) at ../../../i386/i386/trap.c:1101 P> #17 0xc0b42ee0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:262 P> #18 0x00000033 in ?? () P> (kgdb) frame 7 P> #7 0xc5f486b9 in ng_name2noderef (here=0xc62a0b80, name=0xe7ce6894 "ng366") P> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:896 P> 896 LIST_FOREACH(node, &ng_name_hash[hash], nd_nodes) { P> (kgdb) list P> 891 } P> 892 P> 893 /* Find node by name */ P> 894 NG_NAMEHASH(name, hash); P> 895 mtx_lock(&ng_namehash_mtx); P> 896 LIST_FOREACH(node, &ng_name_hash[hash], nd_nodes) { P> 897 if (NG_NODE_IS_VALID(node) && P> 898 (strcmp(NG_NODE_NAME(node), name) == 0)) { P> 899 break; P> 900 } P> (kgdb) print node P> $1 = 0x74 P> (kgdb) print ng_name_hash P> $3 = {{lh_first = 0xcbab6200}, {lh_first = 0x0}, {lh_first = 0xc6538300}, { P> lh_first = 0xc67e6400}, {lh_first = 0xc6538700}, {lh_first = 0xca2abc00}, { P> lh_first = 0xc66d5000}, {lh_first = 0xca8f9200}, {lh_first = 0xca815580}, { P> lh_first = 0xc62a2180}, {lh_first = 0xca2ab180}, {lh_first = 0xc6af7d00}, { P> lh_first = 0xcbe09a00}, {lh_first = 0xca81b800}, {lh_first = 0xc5b4e980}, { P> lh_first = 0xcbc1f080}, {lh_first = 0xca2a5480}, {lh_first = 0xc672b580}, { P> lh_first = 0xcbdb1e80}, {lh_first = 0xcc772c00}, {lh_first = 0xc6a99980}, { P> lh_first = 0xc629d600}, {lh_first = 0xc6733000}, {lh_first = 0xca967800}, { P> lh_first = 0xc5b3b780}, {lh_first = 0xc629c280}, {lh_first = 0xc6396980}, { P> lh_first = 0xc6a5f300}, {lh_first = 0xc5bf2280}, {lh_first = 0xcc5ebe80}, { P> lh_first = 0xc5e0a400}, {lh_first = 0xc6608100}, {lh_first = 0xc6520e00}, { P> lh_first = 0xc6642680}, {lh_first = 0xca8f7b80}, {lh_first = 0xcbd9ce80}, { P> lh_first = 0xca81b380}, {lh_first = 0x0} , { P> lh_first = 0xc67b8080}, {lh_first = 0xc6455c80}, {lh_first = 0xc652a380}, { P> lh_first = 0xc6a74780}, {lh_first = 0xc62d8400}, {lh_first = 0xcc154400}, { P> lh_first = 0xca852b80}, {lh_first = 0xcc351580}, {lh_first = 0xc6396a80}, { P> lh_first = 0xc66f9580}, {lh_first = 0xc58c8e00}, {lh_first = 0xcc01a000}, { P> lh_first = 0xc6614e80}, {lh_first = 0xc6750800}, {lh_first = 0xcc154e80}, { P> lh_first = 0xcc32f080}, {lh_first = 0xcbb10e80}, {lh_first = 0xcc1e3700}, { P> lh_first = 0xcc020280}, {lh_first = 0xcc75ad00}, {lh_first = 0xca901b00}, { P> lh_first = 0xcc3c8380}, {lh_first = 0xcbd90580}, {lh_first = 0xcbb0c480}, { P> lh_first = 0xcbed1300}, {lh_first = 0xc6644480}, {lh_first = 0xcc02ca80}, { P> lh_first = 0xcc0d1980}, {lh_first = 0xcc35e200}, {lh_first = 0xcc0dc200}, { P> lh_first = 0xca9dc200}, {lh_first = 0xcbecf880}, {lh_first = 0xcc065080}, { P> lh_first = 0xcc47b280}, {lh_first = 0xcc722a80}, {lh_first = 0xcc28cd80}, { P> lh_first = 0xcbd73400}, {lh_first = 0xcbf76b00}, {lh_first = 0xcbbfc280}, { P> lh_first = 0xc629c800}, {lh_first = 0xc6700200}, {lh_first = 0x0}, { P> lh_first = 0x0}, {lh_first = 0xc5e0b700}, {lh_first = 0xc672a200}, { P> lh_first = 0xc62a2080}, {lh_first = 0x0}, {lh_first = 0xc673fc80}, { P> lh_first = 0xc5bf2600}, {lh_first = 0xca969800}, {lh_first = 0xc6aa6700}, { P> lh_first = 0xc6750b80}, {lh_first = 0xcc0bc200}, {lh_first = 0xcbeead80}, { P> lh_first = 0xcc484e00}, {lh_first = 0xcbae6900}, {lh_first = 0xcbbef800}, { P> lh_first = 0xcc797500}, {lh_first = 0xc65f3d80}, {lh_first = 0xcbe95900}, { P> lh_first = 0xcba8fb80}, {lh_first = 0xcbdb1580}, {lh_first = 0xcc75b080}, { P> lh_first = 0xcbd7fb80}, {lh_first = 0xcc75db80}, {lh_first = 0xc5e59500}, { P> lh_first = 0xcbd6fb00}, {lh_first = 0xc6a7ed00}, {lh_first = 0xcbe0bc80}, { P> lh_first = 0xcc3c1180}, {lh_first = 0xc7486d00}, {lh_first = 0xcba93880}, { P> lh_first = 0xcc0c6000}, {lh_first = 0x0}, {lh_first = 0x0}, { P> lh_first = 0x0}, {lh_first = 0x0}, {lh_first = 0x0}} In this dump, can we seek for where did 0x74 came from? Can you look at ng_name_hash[hash]? Hash is 116, so probably the interested node is at 0xcbd6fb00. If a counted rows correctly. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 13:40: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 121441065670; Mon, 31 Jan 2011 13:40:59 +0000 (UTC) (envelope-from przemyslaw@frasunek.com) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2a02:2928:a::3]) by mx1.freebsd.org (Postfix) with ESMTP id 99BD38FC13; Mon, 31 Jan 2011 13:40:58 +0000 (UTC) Received: from [IPv6:2a02:2928:a:ffff:c42d:e325:61d:9d63] (unknown [IPv6:2a02:2928:a:ffff:c42d:e325:61d:9d63]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id 2753523944A; Mon, 31 Jan 2011 14:40:57 +0100 (CET) Message-ID: <4D46BBE7.7040006@frasunek.com> Date: Mon, 31 Jan 2011 14:40:55 +0100 From: Przemyslaw Frasunek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gleb Smirnoff References: <4D3011DB.9050900@frasunek.com> <20110131125440.GK62007@FreeBSD.org> In-Reply-To: <20110131125440.GK62007@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:40:59 -0000 > In this dump, can we seek for where did 0x74 came from? Can you look at > ng_name_hash[hash]? (kgdb) print hash No symbol "hash" in current context. (kgdb) info all eax 0xffffff9a -102 ecx 0xe7ce6895 -405903211 edx 0xffffff9a -102 ebx 0x74 116 esp 0xcc28c380 0xcc28c380 ebp 0xe7ce6878 0xe7ce6878 esi 0xe7ce6894 -405903212 edi 0xe7ce6ac8 -405902648 [...] (kgdb) print ng_name_hash[116] $4 = {lh_first = 0xcbd6fb00} (kgdb) print *ng_name_hash[116].lh_first $5 = {nd_name = "ng357", '\0' , nd_type = 0xc61871a0, nd_flags = 0, nd_refs = 1, nd_numhooks = 0, nd_private = 0xcc3b5e80, nd_ID = 454681, nd_hooks = {lh_first = 0x0}, nd_nodes = { le_next = 0xcbbf7900, le_prev = 0xc5f4fad0}, nd_idnodes = { le_next = 0xcc061680, le_prev = 0xc5f4f744}, nd_work = {tqe_next = 0x0, tqe_prev = 0x0}, nd_input_queue = {q_flags = 0, q_mtx = {lock_object = { lo_name = 0xc5f4e986 "ng_node", lo_type = 0xc5f4e986 "ng_node", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, queue = 0x0, last = 0xcbd6fb70, q_node = 0xcbd6fb00}} From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 13:48: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 F40461065670 for ; Mon, 31 Jan 2011 13:48:20 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 619B18FC1D for ; Mon, 31 Jan 2011 13:48:19 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p0VDmHml090224; Mon, 31 Jan 2011 16:48:17 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p0VDmHYA090223; Mon, 31 Jan 2011 16:48:17 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 31 Jan 2011 16:48:17 +0300 From: Gleb Smirnoff To: Przemyslaw Frasunek Message-ID: <20110131134817.GM62007@glebius.int.ru> References: <4D3011DB.9050900@frasunek.com> <20110131125440.GK62007@FreeBSD.org> <4D46BBE7.7040006@frasunek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4D46BBE7.7040006@frasunek.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:48:21 -0000 On Mon, Jan 31, 2011 at 02:40:55PM +0100, Przemyslaw Frasunek wrote: P> > In this dump, can we seek for where did 0x74 came from? Can you look at P> > ng_name_hash[hash]? P> P> (kgdb) print hash P> No symbol "hash" in current context. P> (kgdb) info all P> eax 0xffffff9a -102 P> ecx 0xe7ce6895 -405903211 P> edx 0xffffff9a -102 P> ebx 0x74 116 P> esp 0xcc28c380 0xcc28c380 P> ebp 0xe7ce6878 0xe7ce6878 P> esi 0xe7ce6894 -405903212 P> edi 0xe7ce6ac8 -405902648 P> [...] P> (kgdb) print ng_name_hash[116] P> $4 = {lh_first = 0xcbd6fb00} P> (kgdb) print *ng_name_hash[116].lh_first P> $5 = {nd_name = "ng357", '\0' , nd_type = 0xc61871a0, P> nd_flags = 0, nd_refs = 1, nd_numhooks = 0, nd_private = 0xcc3b5e80, P> nd_ID = 454681, nd_hooks = {lh_first = 0x0}, nd_nodes = { P> le_next = 0xcbbf7900, le_prev = 0xc5f4fad0}, nd_idnodes = { P> le_next = 0xcc061680, le_prev = 0xc5f4f744}, nd_work = {tqe_next = 0x0, P> tqe_prev = 0x0}, nd_input_queue = {q_flags = 0, q_mtx = {lock_object = { P> lo_name = 0xc5f4e986 "ng_node", lo_type = 0xc5f4e986 "ng_node", P> lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, P> lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, queue = 0x0, P> last = 0xcbd6fb70, q_node = 0xcbd6fb00}} Thanks. Yep, "ng357" also has hash of 116. Can we look at ng_name_hash[116].lh_first->nd_nodes.le_next and further? Which one does point to 0x74? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 13:53:13 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A951106566C for ; Mon, 31 Jan 2011 13:53:13 +0000 (UTC) (envelope-from frase@frase.id.au) Received: from bacardi.wooloowin.frase.id.au (60-242-254-5.static.tpgi.com.au [60.242.254.5]) by mx1.freebsd.org (Postfix) with ESMTP id 68B558FC1A for ; Mon, 31 Jan 2011 13:53:11 +0000 (UTC) Received: from bacardi.wooloowin.frase.id.au (localhost [127.0.0.1]) by bacardi.wooloowin.frase.id.au (8.14.4/8.14.4) with ESMTP id p0VDE2Ze006763 for ; Mon, 31 Jan 2011 23:14:02 +1000 (EST) (envelope-from frase@frase.id.au) Received: (from Fraser@localhost) by bacardi.wooloowin.frase.id.au (8.14.4/8.14.4/Submit) id p0VDE1UD006680 for net@freebsd.org; Mon, 31 Jan 2011 23:14:01 +1000 (EST) (envelope-from frase@frase.id.au) X-Authentication-Warning: bacardi.wooloowin.frase.id.au: Fraser set sender to frase@frase.id.au using -f Date: Mon, 31 Jan 2011 23:14:01 +1000 From: Fraser Tweedale To: net@freebsd.org Message-ID: <20110131131400.GA71793@bacardi.wooloowin.frase.id.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: bwn(4) support for BCM4322 (MacBook WiFi) 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, 31 Jan 2011 13:53:13 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I might be fighting a losing battle, but any advice on getting the Broadcom BCM4322 802.11a/b/g/n working? This chip is found in Apple's MacBook and probably elsewhere. I'm currently running amd64 8.2-RC2. As best as I can see, HEAD has nothing that RELENG_8_2 doesn't have, as far as bwn(4) is concerned. As per the bwn(4) man page, I installed the net/bwn-firmware-kmod port. The firmware failed to load, giving a "firmware table full" error. Seems that others had this issue. Bumping the firmware table size FIRMWARE_MAX in sys/kern/subr_firmware.c was the suggested workaround; both modules provided by the port - bwn_v4_lp_ucode.ko and bwn_v4_ucode.ko - now load without error. Loading if_bwn.ko yeilds the following on console: siba_bwn0: mem 0x93100000-0x93103fff irq 18 at device 0.0 on pci3 siba_bwn0: warn: multiple PCI(E) cores siba_bwn0: unsupported coreid (USB 2.0 Device) siba_bwn0: unsupported coreid (unknown) siba_bwn0: unsupported coreid (Internal Memory) siba_bwn0: unknown chipid 0x4322 for PLL & PMU init bwn0 on siba_bwn0 bwn0: unsupported PHY type (4) device_attach: bwn0 attach returned 6 siba_bwn0 appears in devinfo(8) output but bwn(4) is nowhere to be found. Any suggestions on how to get the card working? Regards, Fraser --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk1GtZgACgkQPw/2FZbemTXi9wCgrWjhCEmD2YBE8yqIGZ389FQd +P8AnRk1YzjV5l2Jolb1SX+UdAQenwOZ =H8se -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 14:23: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 11BCD1065670 for ; Mon, 31 Jan 2011 14:23:50 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8B08FC17 for ; Mon, 31 Jan 2011 14:23:49 +0000 (UTC) Received: by bwz12 with SMTP id 12so5350449bwz.13 for ; Mon, 31 Jan 2011 06:23:48 -0800 (PST) Received: by 10.204.123.140 with SMTP id p12mr5325390bkr.176.1296483828157; Mon, 31 Jan 2011 06:23:48 -0800 (PST) Received: from jessie.localnet (p5B2EC39D.dip0.t-ipconnect.de [91.46.195.157]) by mx.google.com with ESMTPS id x38sm10285022bkj.1.2011.01.31.06.23.45 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 06:23:46 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Fraser Tweedale Date: Mon, 31 Jan 2011 15:23:35 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-28-generic; KDE/4.4.5; i686; ; ) References: <20110131131400.GA71793@bacardi.wooloowin.frase.id.au> In-Reply-To: <20110131131400.GA71793@bacardi.wooloowin.frase.id.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201101311523.36269.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: bwn(4) support for BCM4322 (MacBook WiFi) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 14:23:50 -0000 On Monday, January 31, 2011 14:14:01 Fraser Tweedale wrote: > I might be fighting a losing battle, but any advice on getting the > Broadcom BCM4322 802.11a/b/g/n working? This chip is found in > Apple's MacBook and probably elsewhere. > > I'm currently running amd64 8.2-RC2. As best as I can see, HEAD has > nothing that RELENG_8_2 doesn't have, as far as bwn(4) is concerned. > > As per the bwn(4) man page, I installed the net/bwn-firmware-kmod > port. The firmware failed to load, giving a "firmware table full" > error. Seems that others had this issue. Bumping the firmware > table size FIRMWARE_MAX in sys/kern/subr_firmware.c was the > suggested workaround; both modules provided by the port - > bwn_v4_lp_ucode.ko and bwn_v4_ucode.ko - now load without error. > > Loading if_bwn.ko yeilds the following on console: > > siba_bwn0: mem 0x93100000-0x93103fff irq 18 at device 0.0 > on pci3 siba_bwn0: warn: multiple PCI(E) cores > siba_bwn0: unsupported coreid (USB 2.0 Device) > siba_bwn0: unsupported coreid (unknown) > siba_bwn0: unsupported coreid (Internal Memory) > siba_bwn0: unknown chipid 0x4322 for PLL & PMU init > bwn0 on siba_bwn0 > bwn0: unsupported PHY type (4) > device_attach: bwn0 attach returned 6 > > siba_bwn0 appears in devinfo(8) output but bwn(4) is nowhere to be > found. > > Any suggestions on how to get the card working? I guess you're out of luck here. Neither bwn(4) nor bwi(4) support the bcm4322 variant afaik (Please correct me if I'm wrong..). The only option left is ndis(4). -- Bernhard From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 15:05: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 EE068106564A; Mon, 31 Jan 2011 15:05:16 +0000 (UTC) (envelope-from przemyslaw@frasunek.com) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2a02:2928:a::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8B38FC0A; Mon, 31 Jan 2011 15:05:16 +0000 (UTC) Received: from [IPv6:2a02:2928:a:ffff:c42d:e325:61d:9d63] (unknown [IPv6:2a02:2928:a:ffff:c42d:e325:61d:9d63]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id AB88823944A; Mon, 31 Jan 2011 16:05:15 +0100 (CET) Message-ID: <4D46CFA9.5050500@frasunek.com> Date: Mon, 31 Jan 2011 16:05:13 +0100 From: Przemyslaw Frasunek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gleb Smirnoff References: <4D3011DB.9050900@frasunek.com> <20110131125440.GK62007@FreeBSD.org> <4D46BBE7.7040006@frasunek.com> In-Reply-To: <4D46BBE7.7040006@frasunek.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:05:17 -0000 > (kgdb) print *ng_name_hash[116].lh_first It looks like this one is corrupted: (kgdb) print *ng_name_hash[116].lh_first.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next $19 = {nd_name = "ng258", '\0' , nd_type = 0xc61871a0, nd_flags = 0, nd_refs = 1, nd_numhooks = 0, nd_private = 0xccabdbc0, nd_ID = 454433, nd_hooks = {lh_first = 0x0}, nd_nodes = { le_next = 0xcc28c380, le_prev = 0xcbadadbc}, nd_idnodes = { le_next = 0xcc410400, le_prev = 0xc5f4f764}, nd_work = {tqe_next = 0x0, tqe_prev = 0x0}, nd_input_queue = {q_flags = 0, q_mtx = {lock_object = { lo_name = 0xc5f4e986 "ng_node", lo_type = 0xc5f4e986 "ng_node", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, queue = 0x0, last = 0xc69e16f0, q_node = 0xc69e1680}} nd_nodes->le_prev is 0xcbadadbc (kgdb) print *ng_name_hash[116].lh_first.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next $20 = { nd_name = "\b\000\000\000 \000\000\000\005\000\000\000\000\000\000\000\220_q\001\036QĆCcmd5\000\000\000", nd_type = 0x0, nd_flags = 0, nd_refs = 0, nd_numhooks = 0, nd_private = 0x0, nd_ID = 0, nd_hooks = { lh_first = 0x68676972}, nd_nodes = {le_next = 0x74, le_prev = 0x0}, nd_idnodes = {le_next = 0x0, le_prev = 0x0}, nd_work = {tqe_next = 0x0, tqe_prev = 0x0}, nd_input_queue = {q_flags = 0, q_mtx = {lock_object = { lo_name = 0x0, lo_type = 0x0, lo_flags = 1, lo_witness_data = { lod_list = {stqe_next = 0x6}, lod_witness = 0x6}}, mtx_lock = 0, mtx_recurse = 0}, queue = 0x0, last = 0xcc28c3f0, q_node = 0xcc28c380}} (kgdb) print *ng_name_hash[116].lh_first.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next Cannot access memory at address 0x74 From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 15:13: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 3E027106564A; Mon, 31 Jan 2011 15:13:33 +0000 (UTC) (envelope-from przemyslaw@frasunek.com) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2a02:2928:a::3]) by mx1.freebsd.org (Postfix) with ESMTP id F265A8FC08; Mon, 31 Jan 2011 15:13:32 +0000 (UTC) Received: from [IPv6:2a02:2928:a:ffff:c42d:e325:61d:9d63] (unknown [IPv6:2a02:2928:a:ffff:c42d:e325:61d:9d63]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id 3BD6323944A; Mon, 31 Jan 2011 16:13:32 +0100 (CET) Message-ID: <4D46D19A.7000508@frasunek.com> Date: Mon, 31 Jan 2011 16:13:30 +0100 From: Przemyslaw Frasunek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gleb Smirnoff References: <4D3011DB.9050900@frasunek.com> <20110131144223.GN62007@FreeBSD.org> In-Reply-To: <20110131144223.GN62007@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:13:33 -0000 > And in this one, can you please show *hook->hk_peer ? (kgdb) print *hook->hk_peer $2 = { hk_name = "\b\000\000\000 \000\000\000\004\000\000\000\001\000\000\000ÅRí\003\003ö\0248cmd4\000\000\000", hk_private = 0x0, hk_flags = 0, hk_refs = 0, hk_type = 0, hk_peer = 0x0, hk_node = 0x0, hk_hooks = {le_next = 0x566226, le_prev = 0x99e79c03}, hk_rcvmsg = 0x38ef45, hk_rcvdata = 0x28d6a8a1} From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 15:31:08 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 10309106564A for ; Mon, 31 Jan 2011 15:31:08 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 834C68FC0A for ; Mon, 31 Jan 2011 15:31:06 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Mon, 31 Jan 2011 16:29:36 +0100 id 00033C0D.4D46D560.000166B4 From: Milan Obuch To: freebsd-net@freebsd.org, pyunyh@gmail.com Date: Mon, 31 Jan 2011 16:29:50 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.5; i386; ; ) References: <20110131011510.GC1323@michelle.cdnetworks.com> <20110131020702.GA1229@michelle.cdnetworks.com> In-Reply-To: <20110131020702.GA1229@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101311630.03924.freebsd-net@dino.sk> Cc: zeus@ibs.dn.ua Subject: Re: Problem with re0 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, 31 Jan 2011 15:31:08 -0000 On Monday 31 January 2011 03:07:02 Pyun YongHyeon wrote: > On Sun, Jan 30, 2011 at 05:15:10PM -0800, Pyun YongHyeon wrote: > > On Sun, Jan 30, 2011 at 02:53:15PM +0100, Milan Obuch wrote: > > > On Sunday 30 January 2011 07:40:48 Zeus V Panchenko wrote: > > > > another detail for this nic > > > > > > > > dmidecode > > > > Base Board Information > > > > > > > > Manufacturer: ASUSTeK Computer INC. > > > > Product Name: AT5NM10-I > > > > Version: Rev x.0x > > > > Serial Number: MT7006K15200322 > > > > > > I did not followed this thread closely, but I checked my new board and > > > it is the same. > > > > > > > uname -a > > > > FreeBSD 8.2-PRERELEASE amd64 > > > > > > > > system was cvsup-ed 2011.01.20 > > > > > > > > if_re.c,v 1.160.2.17 2011/01/15 00:32:15 yongari > > > > > > > > dmesg > > > > rgephy0: PHY 1 on miibus0 > > > > rgephy0: 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: > > > > 20:cf:30:89:5e:95 > > > > re0: [FILTER] > > > > > > > > pciconf -lv > > > > re0@pci0:2:0:0: class=0x020000 card=0x83a31043 chip=0x816810ec > > > > rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' > > > > > > > > device = 'Gigabit Ethernet NIC(NDIS 6.0) > > > > (RTL8168/8111/8111c)' class = network > > > > subclass = ethernet > > > > > > All details are the same for my board (modulo serial number and MAC, of > > > course), and in my case it works with no problem, but only in 100 Mb > > > switch port. In 1 Gb port I have no link. I must verify my cables, > > > port on switch itself works just fine with another 1 Gb (intel) card. > > > > Would you try a patch at the following URL? > > http://people.freebsd.org/~yongari/re/rgephy.link.patch3 > > Previous one had a bug, please use updated one. > http://people.freebsd.org/~yongari/re/rgephy.link.patch4 > > > > > while connected directly NIC <-> NIC they flaps too > > > > > > I will try this against another 1 Gb card too, just to see what > > > happens... in 100 Mb mode it works just fine, as I mentioned already - > > > running flood ping with 1472 bytes packets for more than an hour I see > > > only four responses missing in more than 21 millions tries... > > > > > > Regards, > > > Milan > I checked my cables and one of them had bad pairing. Worked in 100 Mb mode, but not in 1 Gb mode. After I replaced it I check with flood ping, 1472 bytes packets again and no sign of problem here - one reply missing in almost 21 millions tries. How are your flaps 'visible'? What fails? Ping test is simple, so I could overlooked something, but now it works for in 1 Gb mode, too... Regards, Milan From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 15:50: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 7E794106564A for ; Mon, 31 Jan 2011 15:50:32 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id EC8798FC15 for ; Mon, 31 Jan 2011 15:50:31 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id p0VFoUuO031668 for ; Mon, 31 Jan 2011 17:50:30 +0200 (EET) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id p0VFoTDO031665 for freebsd-net@freebsd.org; Mon, 31 Jan 2011 17:50:29 +0200 (EET) Date: Mon, 31 Jan 2011 17:50:29 +0200 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20110131155029.GF14888@relay.ibs.dn.ua> Mail-Followup-To: freebsd-net@freebsd.org References: <20110131011510.GC1323@michelle.cdnetworks.com> <20110131020702.GA1229@michelle.cdnetworks.com> <201101311630.03924.freebsd-net@dino.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201101311630.03924.freebsd-net@dino.sk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus@ibs.dn.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:50:32 -0000 Milan Obuch (freebsd-net@dino.sk) [11.01.31 17:31] wrote: > > I checked my cables and one of them had bad pairing. Worked in 100 Mb mode, > but not in 1 Gb mode. After I replaced it I check with flood ping, 1472 bytes > packets again and no sign of problem here - one reply missing in almost 21 > millions tries. How are your flaps 'visible'? What fails? Ping test is simple, > so I could overlooked something, but now it works for in 1 Gb mode, too... > while NIC flaps i see switch port on/off and in dmesg: ... re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP ... -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 16:52: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 E39AA106564A for ; Mon, 31 Jan 2011 16:52:51 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B0A3E8FC08 for ; Mon, 31 Jan 2011 16:52:51 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p0VGqjbg043425 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 08:52:49 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D46E8E0.2030300@freebsd.org> Date: Mon, 31 Jan 2011 08:52:48 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D4685A0.6040400@rdtc.ru> <20110131122926.C39951@maildrop.int.zabbadoz.net> In-Reply-To: <20110131122926.C39951@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Eugene Grosbein , Mike Tancsa Subject: Re: panic: bufwrite: buffer is not busy??? 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, 31 Jan 2011 16:52:52 -0000 On 1/31/11 4:32 AM, Bjoern A. Zeeb wrote: > On Mon, 31 Jan 2011, Eugene Grosbein wrote: > >> On 31.01.2011 14:20, Julian Elischer wrote: >> >>>> # gdb kernel >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, >>>> and you are >>>> welcome to change it and/or distribute copies of it under certain >>>> conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" >>>> for details. >>>> This GDB was configured as "amd64-marcel-freebsd"... >>>> (gdb) l *0xffffffff803c1315 >>>> 0xffffffff803c1315 is in ng_address_hook >>>> (/home/src/sys/netgraph/ng_base.c:3504). >>>> 3499 * Quick sanity check.. >>>> 3500 * Since a hook holds a reference on it's node, >>>> once we know >>>> 3501 * that the peer is still connected (even if >>>> invalid,) we know >>>> 3502 * that the peer node is present, though maybe >>>> invalid. >>>> 3503 */ >>>> 3504 if ((hook == NULL) || >>>> 3505 NG_HOOK_NOT_VALID(hook) || >>>> 3506 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || >>>> 3507 NG_NODE_NOT_VALID(peernode = >>>> NG_PEER_NODE(hook))) { >>>> 3508 NG_FREE_ITEM(item); >>> >>> >>> replace with: > > which is essentially what I had suggested in the formerly mentioned PR > already (just remove the first printf macro). > > >>> 3504 if ((hook == NULL) || >>> 3505 NG_HOOK_NOT_VALID(hook) || >>> ((peer = NG_HOOK_PEER(hook)) == NULL) || >>> 3506 NG_HOOK_NOT_VALID(peer) || >>> ((peernode = NG_PEER_NODE(hook)) == NULL) || >>> 3507 NG_NODE_NOT_VALID(peernode)) { >>> if (peer) >>> kassert((peernode != NULL), ("peer >>> node NULL wile peer hook exists")); >>> 3508 NG_FREE_ITEM(item); >>> > > > The problem is that it will not help to fix the race; if you go > up in the same file you'll find another similar one of these checks > with a scary rev 1.1. (I think) comment (that you, Julian, should know > very well;-) > > The solution that this needs is: proper locking. > > >> It does not compile: >> >> /home/src/sys/netgraph/ng_base.c: In function 'ng_address_hook': >> /home/src/sys/netgraph/ng_base.c:3511: warning: implicit >> declaration of function 'kassert' >> /home/src/sys/netgraph/ng_base.c:3511: warning: nested extern >> declaration of 'kassert' > > yeah KASSERT is upper case. slaps head... kassert is at work.... > > >> *** Error code 1 >> 1 error >> *** Error code 2 >> 1 error >> *** Error code 2 >> 1 error >> _______________________________________________ >> 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 Jan 31 16:58: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 A6AED106564A for ; Mon, 31 Jan 2011 16:58:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 77DBB8FC16 for ; Mon, 31 Jan 2011 16:58:09 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p0VGw226043450 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 08:58:04 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D46EA1E.4020000@freebsd.org> Date: Mon, 31 Jan 2011 08:58:06 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Przemyslaw Frasunek References: <4D3011DB.9050900@frasunek.com> <20110131144223.GN62007@FreeBSD.org> <4D46D19A.7000508@frasunek.com> In-Reply-To: <4D46D19A.7000508@frasunek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:58:09 -0000 On 1/31/11 7:13 AM, Przemyslaw Frasunek wrote: >> And in this one, can you please show *hook->hk_peer ? > (kgdb) print *hook->hk_peer > $2 = { > hk_name = "\b\000\000\000 > \000\000\000\004\000\000\000\001\000\000\000ÅRí\003\003ö\0248cmd4\000\000\000", > hk_private = 0x0, hk_flags = 0, hk_refs = 0, > hk_type = 0, hk_peer = 0x0, hk_node = 0x0, hk_hooks = {le_next = 0x566226, > le_prev = 0x99e79c03}, hk_rcvmsg = 0x38ef45, hk_rcvdata = 0x28d6a8a1} that's not supposed to be able to happen. It's supposed to point to SOMETHING, even if it's the "dead" hook. does the dead hook point to itself? itprobably should if it doesn't. (and it should have a name of 'dead' if it doesn't already). > _______________________________________________ > 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 Jan 31 17:10:22 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 86FDD1065675; Mon, 31 Jan 2011 17:10:22 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 15DCA8FC0C; Mon, 31 Jan 2011 17:10:22 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p0VHAHU8043513 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 09:10:18 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D46ECFD.2070700@freebsd.org> Date: Mon, 31 Jan 2011 09:10:21 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Przemyslaw Frasunek References: <4D3011DB.9050900@frasunek.com> <20110131144223.GN62007@FreeBSD.org> <4D46D19A.7000508@frasunek.com> <4D46EA1E.4020000@freebsd.org> In-Reply-To: <4D46EA1E.4020000@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Alexander Motin Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:10:22 -0000 On 1/31/11 8:58 AM, Julian Elischer wrote: > On 1/31/11 7:13 AM, Przemyslaw Frasunek wrote: >>> And in this one, can you please show *hook->hk_peer ? >> (kgdb) print *hook->hk_peer >> $2 = { >> hk_name = "\b\000\000\000 >> \000\000\000\004\000\000\000\001\000\000\000ÅRí\003\003ö\0248cmd4\000\000\000", >> >> hk_private = 0x0, hk_flags = 0, hk_refs = 0, >> hk_type = 0, hk_peer = 0x0, hk_node = 0x0, hk_hooks = {le_next = >> 0x566226, >> le_prev = 0x99e79c03}, hk_rcvmsg = 0x38ef45, hk_rcvdata = >> 0x28d6a8a1} > > that's not supposed to be able to happen. > It's supposed to point to SOMETHING, even if it's the "dead" hook. > does the dead hook point to itself? itprobably should if it doesn't. > (and it should have a name of 'dead' if it doesn't already). Replying to self.. all these things are in fact true, (just looked at source) so this is not a pointer to the dead node. So, how do we get a NULL peer? unless the hook is destroyed by another thread while we are accessing it, but I think from memory that that should set it to 'dead' not NULL. > > >> _______________________________________________ >> 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 Mon Jan 31 17:49: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 417A61065670; Mon, 31 Jan 2011 17:49:23 +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 EEB5C8FC0C; Mon, 31 Jan 2011 17:49:22 +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.4/8.14.4) with ESMTP id p0VHnIIA016792 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 12:49:18 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D46F61B.5060907@sentex.net> Date: Mon, 31 Jan 2011 12:49:15 -0500 From: Mike Tancsa 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: Julian Elischer References: <4D3011DB.9050900@frasunek.com> <20110131144223.GN62007@FreeBSD.org> <4D46D19A.7000508@frasunek.com> <4D46EA1E.4020000@freebsd.org> <4D46ECFD.2070700@freebsd.org> In-Reply-To: <4D46ECFD.2070700@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Alexander Motin , Przemyslaw Frasunek Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:49:23 -0000 On 1/31/2011 12:10 PM, Julian Elischer wrote: > On 1/31/11 8:58 AM, Julian Elischer wrote: >> On 1/31/11 7:13 AM, Przemyslaw Frasunek wrote: >>>> And in this one, can you please show *hook->hk_peer ? >>> (kgdb) print *hook->hk_peer >>> $2 = { >>> hk_name = "\b\000\000\000 >>> \000\000\000\004\000\000\000\001\000\000\000ÅRí\003\003ö\0248cmd4\000\000\000", >>> >>> hk_private = 0x0, hk_flags = 0, hk_refs = 0, >>> hk_type = 0, hk_peer = 0x0, hk_node = 0x0, hk_hooks = {le_next = >>> 0x566226, >>> le_prev = 0x99e79c03}, hk_rcvmsg = 0x38ef45, hk_rcvdata = >>> 0x28d6a8a1} >> >> that's not supposed to be able to happen. >> It's supposed to point to SOMETHING, even if it's the "dead" hook. >> does the dead hook point to itself? itprobably should if it doesn't. >> (and it should have a name of 'dead' if it doesn't already). > > Replying to self.. all these things are in fact true, (just looked at > source) so this is not a pointer > to the dead node. So, how do we get a NULL peer? > unless the hook is destroyed by another thread while we are accessing it, > but I think from memory that that should set it to 'dead' not NULL. If there is extra debugging code you would like me to add, it does not take too long for this to happen on my one LNS... 4-5 days. ---Mike From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 20:43: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 6F52510656A3 for ; Mon, 31 Jan 2011 20:43:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 421018FC0A for ; Mon, 31 Jan 2011 20:43:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DE5D546B0C; Mon, 31 Jan 2011 15:43:46 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D9ADD8A01D; Mon, 31 Jan 2011 15:43:45 -0500 (EST) From: John Baldwin To: Eugene Grosbein Date: Mon, 31 Jan 2011 11:46:42 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D3011DB.9050900@frasunek.com> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> In-Reply-To: <4D46575A.802@rdtc.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101311146.43119.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 31 Jan 2011 15:43:46 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=2.1 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06, MAY_BE_FORGED,RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-net@freebsd.org, Przemyslaw Frasunek , Mike Tancsa Subject: Re: panic: bufwrite: buffer is not busy??? 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, 31 Jan 2011 20:43:47 -0000 On Monday, January 31, 2011 1:31:54 am Eugene Grosbein wrote: > On 15.01.2011 01:37, John Baldwin wrote: > > On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote: > >> On 14.01.2011 18:46, Mike Tancsa wrote: > >> > >>>> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE > >>>> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and > >>>> runs FreeBSD 7.3-RELEASE. > >>>> > >>>> I'm experiencing stability issues related to Netgraph. None of above routers can > >>>> survive more than 20-30 days of uptime under typical load. There are different > >>>> flavors of kernel panics, but all are somehow related to netgraph. Typical > >>>> backtraces follow > >>> > >>> I also have stability issues on RELENG_8. > >>> > >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=153497 > >> > >> And for one of my servers (8.2-PRERELEASE/amd64 with 4GB RAM) I just cannot obtain crashdump, > >> it cannot finish to write it. For example, it happened an hour ago: > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 2; apic id = 04 > >> fault virtual address = 0x200000040 > >> fault code = supervisor read data, page not present > >> instruction pointer = 0x20:0xffffffff803cc979 > > > > Assuming your kernel is built with debug symbols (which is the default), one > > thing you can do to aid in debugging is this: > > > > gdb /boot/kernel/kernel > > (gdb) l *0xffffffff803cc979 > > > > Where the 0xfff bit is the part of the 'instruction pointer' value > > above after the colon (:) and then send the output of that in your e-mail to > > the list. This allows us to the source line at which the fault occurred. > > > > Yesterday I've got another kernel panic of this kind with RELENG_8 updated 20 January > and it still could not finish writing of crashdump: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 02 > fault virtual address = 0x200000030 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff803c1315 > stack pointer = 0x28:0xffffff8000130780 > frame pointer = 0x28:0xffffff80001307a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq259: em1:rx 0) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 19h41m8s > Dumping 4087 MB (3 chunks) > chunk 0: 1MB (150 pages) ... ok > chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? > cpuid = 1 > Uptime: 19h41m9s > Automatic reboot in 15 seconds - press a key on the console to abort > > This time I have all debug symbols handy: > > > # gdb kernel > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > (gdb) l *0xffffffff803c1315 > 0xffffffff803c1315 is in ng_address_hook (/home/src/sys/netgraph/ng_base.c:3504). > 3499 * Quick sanity check.. > 3500 * Since a hook holds a reference on it's node, once we know > 3501 * that the peer is still connected (even if invalid,) we know > 3502 * that the peer node is present, though maybe invalid. > 3503 */ > 3504 if ((hook == NULL) || > 3505 NG_HOOK_NOT_VALID(hook) || > 3506 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || > 3507 NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { > 3508 NG_FREE_ITEM(item); Hmmm. I think you might have a hardware problem. Notice the fault address, it is 0x200000030. Can you do 'x/i '? I suspect it is doing a memory access from that has a constant offset of 0x30, in which case the original pointer was 0x200000000, meaning it would be NULL except it has a single-bit error. That would likely be caused by a hardware issue such as failing RAM, etc. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 20:43:51 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C966410656F1 for ; Mon, 31 Jan 2011 20:43:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB008FC0C for ; Mon, 31 Jan 2011 20:43:51 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0EF0646B39 for ; Mon, 31 Jan 2011 15:43:51 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F2B2C8A02A for ; Mon, 31 Jan 2011 15:43:49 -0500 (EST) From: John Baldwin To: net@freebsd.org Date: Mon, 31 Jan 2011 12:17:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201101311217.07073.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 31 Jan 2011 15:43:50 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Flag: YES X-Spam-Status: Yes, score=8.4 required=4.2 tests=BAYES_00, DATE_IN_PAST_03_06, MAY_BE_FORGED, RDNS_DYNAMIC, TO_NO_BRKTS_DIRECT, TO_NO_BRKTS_DYNIP autolearn=no version=3.3.1 X-Spam-Report: * 1.6 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.0 RDNS_DYNAMIC Delivered to internal network by host with * dynamic-looking rDNS * 1.4 MAY_BE_FORGED Relay IP's reverse DNS does not resolve to IP * 2.6 TO_NO_BRKTS_DIRECT To: misformatted and direct-to-MX * 3.7 TO_NO_BRKTS_DYNIP To: misformatted and dynamic rDNS X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Bogus KASSERT() in tcp_output()? 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, 31 Jan 2011 20:43:51 -0000 Somewhat related fallout to the bug reported on security@ recently, I think this KASSERT() in tcp_output() is bogus: KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL), ("%s: mbuf chain shorter than expected", __func__)); Specifically, just a few lines earlier in tcp_output() we set the packet header length to just 'len + hdrlen': /* * Put TCP length in extended header, and then * checksum extended header and data. */ m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */ Also, the ipoptions are stored in a separate mbuf chain in the in pcb (inp_options) that is passed as a separate argument to ip_output(). Given that, I would think that m_length() should not reflect ipoptlen since it should not include IP options in that chain? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 21:13: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 F2BD0106566C for ; Mon, 31 Jan 2011 21:13:49 +0000 (UTC) (envelope-from pyunyh@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 B218F8FC17 for ; Mon, 31 Jan 2011 21:13:49 +0000 (UTC) Received: by iyb26 with SMTP id 26so5407656iyb.13 for ; Mon, 31 Jan 2011 13:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=CgV62o0VdmUQuxy8gRquHoqn6/3LzWiY+wLPAul/mc4=; b=jB+WWgbbdr6s9aKQNnGc5Qvtth9cFow8wtfsTeHt5cUhcy/e9NAfjvcYn/O7PT2ZsM k4sP5gb+aem770y2zURUD1y+R0x5q/wvmycpN9ctHWOrB0eSL3VzDbFeH80crDK9qwxq yodG3QFLCosCr7hQZiNBxUikbjaOgyNWZ67xY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=SGDUQ+843WN9AUnmbsEpGtR4zABiBF0kCRPkt9zQqqUoGqjct9q+ghsH+sl2PxSrUh W8fiW70zUEtV7/NCNaF8aUKdfPX3dDZBUOJvphfvj9qlKx0DcNQWviLFqHGM7Wu5x1tZ xDFNf4TOyvd6qLKUklFaYnsEH42qlMalCSXYU= Received: by 10.42.230.1 with SMTP id jk1mr8601047icb.67.1296508427982; Mon, 31 Jan 2011 13:13:47 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id y8sm16393311ica.2.2011.01.31.13.13.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 13:13:45 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 31 Jan 2011 13:13:46 -0800 From: Pyun YongHyeon Date: Mon, 31 Jan 2011 13:13:46 -0800 To: freebsd-net@freebsd.org Message-ID: <20110131211346.GD1275@michelle.cdnetworks.com> References: <20101112070759.GA36248@relay.ibs.dn.ua> <20101112230000.GD22460@michelle.cdnetworks.com> <20110121125917.GA48950@relay.ibs.dn.ua> <20110130064048.GA14888@relay.ibs.dn.ua> <20110131012032.GD1323@michelle.cdnetworks.com> <20110131020720.GB1229@michelle.cdnetworks.com> <20110131121509.GE14888@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110131121509.GE14888@relay.ibs.dn.ua> User-Agent: Mutt/1.4.2.3i Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:13:50 -0000 On Mon, Jan 31, 2011 at 02:15:09PM +0200, Zeus V Panchenko wrote: > Pyun YongHyeon (pyunyh@gmail.com) [11.01.31 04:08] wrote: > > > The RTL8168/8111D sample board I have does not show this kind of > > > issue. This happens only when established link is 1000baseT, right? > > > I slightly changed PHY's link detection code so would you try that > > > patch at the following URL? > > > http://people.freebsd.org/~yongari/re/rgephy.link.patch3 > > > > Previous one had a bug, please update one. > > http://people.freebsd.org/~yongari/re/rgephy.link.patch4 > > no change :( > interface continues to flap > Then I have no idea. Does other OS work with your hardware without issues? As last resort, could you try vendor's FreeBSD driver? The vendor's driver applies a bunch of magic DSP fixups which re(4) does not have. I don't know whether it makes difference or not but it would be worth a try. Note, vendor's driver treat your controller as old 8139 such that it disables all offload features and does not work on non-x86 architectures. From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 21:39:49 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 3C94F106566C; Mon, 31 Jan 2011 21:39:49 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 132C18FC13; Mon, 31 Jan 2011 21:39:49 +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 p0VLdmtM072911; Mon, 31 Jan 2011 21:39:48 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0VLdme9072907; Mon, 31 Jan 2011 21:39:48 GMT (envelope-from yongari) Date: Mon, 31 Jan 2011 21:39:48 GMT Message-Id: <201101312139.p0VLdme9072907@freefall.freebsd.org> To: wolffire_fl@yahoo.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/123429: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-RELEASE and 7.0-STABLE-042008 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, 31 Jan 2011 21:39:49 -0000 Synopsis: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-RELEASE and 7.0-STABLE-042008 State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Jan 31 21:38:47 UTC 2011 State-Changed-Why: Is it still issue on more recent FreeBSD release? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Jan 31 21:38:47 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=123429 From owner-freebsd-net@FreeBSD.ORG Mon Jan 31 23:30:11 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 2256A106566B for ; Mon, 31 Jan 2011 23:30:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9228FC13 for ; Mon, 31 Jan 2011 23:30:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0VNUAqY089324 for ; Mon, 31 Jan 2011 23:30:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0VNUAuI089320; Mon, 31 Jan 2011 23:30:10 GMT (envelope-from gnats) Date: Mon, 31 Jan 2011 23:30:10 GMT Message-Id: <201101312330.p0VNUAuI089320@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: PseudoCylon Cc: Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: PseudoCylon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:30:11 -0000 The following reply was made to PR kern/153938; it has been noted by GNATS. From: PseudoCylon To: Juergen Lock Cc: bug-followup@freebsd.org, Juergen Lock Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic Date: Mon, 31 Jan 2011 15:28:25 -0800 (PST) ----- Original Message ---- > From: Juergen Lock > To: PseudoCylon > Cc: bug-followup@freebsd.org; Juergen Lock > Sent: Sun, January 30, 2011 2:50:42 PM > Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free >panic > > On Sat, Jan 22, 2011 at 11:35:14PM -0800, PseudoCylon wrote: > > > Anyway, I have been testing this version for maybe a week now and it > seems to work at least no worse than the previous one, minus the > deadlock. :) So it probably can go in. > > Thanx! > Juergen > Thanks for testing. I'll submit the patch. AK From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 02:58:32 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66485106566C for ; Tue, 1 Feb 2011 02:58:32 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 2860E8FC16 for ; Tue, 1 Feb 2011 02:58:31 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id E41A47E84A; Tue, 1 Feb 2011 13:40:12 +1100 (EST) Message-ID: <4D477289.8040901@freebsd.org> Date: Tue, 01 Feb 2011 13:40:09 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101215 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <201101311217.07073.jhb@freebsd.org> In-Reply-To: <201101311217.07073.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: "Bjoern A. Zeeb" , Andre Oppermann , net@freebsd.org Subject: Re: Bogus KASSERT() in tcp_output()? 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, 01 Feb 2011 02:58:32 -0000 On 02/01/11 04:17, John Baldwin wrote: > Somewhat related fallout to the bug reported on security@ recently, I think > this KASSERT() in tcp_output() is bogus: > > > KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL), > ("%s: mbuf chain shorter than expected", __func__)); > > Specifically, just a few lines earlier in tcp_output() we set the packet > header length to just 'len + hdrlen': > > /* > * Put TCP length in extended header, and then > * checksum extended header and data. > */ > m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */ > > Also, the ipoptions are stored in a separate mbuf chain in the in pcb > (inp_options) that is passed as a separate argument to ip_output(). Given > that, I would think that m_length() should not reflect ipoptlen since it > should not include IP options in that chain? > There is some relevant prior discussion on src-committers@ for r212803 between Andre and Bjoern. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 03:05:13 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 843D4106564A; Tue, 1 Feb 2011 03:05:13 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id D0B358FC13; Tue, 1 Feb 2011 03:05:12 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3992E41C7A5; Tue, 1 Feb 2011 04:05:11 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id xofwUQ24sbcT; Tue, 1 Feb 2011 04:05:10 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 9C64941C7B0; Tue, 1 Feb 2011 04:05:10 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 2CC1B444900; Tue, 1 Feb 2011 03:02:06 +0000 (UTC) Date: Tue, 1 Feb 2011 03:02:06 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Lawrence Stewart In-Reply-To: <4D477289.8040901@freebsd.org> Message-ID: <20110201025227.J43179@maildrop.int.zabbadoz.net> References: <201101311217.07073.jhb@freebsd.org> <4D477289.8040901@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , John Baldwin , net@freebsd.org Subject: Re: Bogus KASSERT() in tcp_output()? 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, 01 Feb 2011 03:05:13 -0000 On Tue, 1 Feb 2011, Lawrence Stewart wrote: > On 02/01/11 04:17, John Baldwin wrote: >> Somewhat related fallout to the bug reported on security@ recently, I think >> this KASSERT() in tcp_output() is bogus: >> >> >> KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL), >> ("%s: mbuf chain shorter than expected", __func__)); >> >> Specifically, just a few lines earlier in tcp_output() we set the packet >> header length to just 'len + hdrlen': >> >> /* >> * Put TCP length in extended header, and then >> * checksum extended header and data. >> */ >> m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */ >> >> Also, the ipoptions are stored in a separate mbuf chain in the in pcb >> (inp_options) that is passed as a separate argument to ip_output(). Given >> that, I would think that m_length() should not reflect ipoptlen since it >> should not include IP options in that chain? >> > > There is some relevant prior discussion on src-committers@ for r212803 > between Andre and Bjoern. Yeah and I still have the temporary workaround from http://p4web.freebsd.org/@@185095?ac=10 I think you are specifically refering to http://lists.freebsd.org/pipermail/svn-src-head/2010-October/021814.html I had been pinging people back then, but I am happy to see the discussion about these TCP changes finally happing now. I'll have to swap thing back in completly - it's been more than three months. Let me see later today. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 05:53: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 D30E81065675; Tue, 1 Feb 2011 05:53:44 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD098FC0A; Tue, 1 Feb 2011 05:53:43 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p115rfgF056439; Tue, 1 Feb 2011 11:53:41 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D479FE0.70809@rdtc.ru> Date: Tue, 01 Feb 2011 11:53:36 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D3011DB.9050900@frasunek.com> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <201101311146.43119.jhb@freebsd.org> In-Reply-To: <201101311146.43119.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: panic: bufwrite: buffer is not busy??? 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, 01 Feb 2011 05:53:44 -0000 On 31.01.2011 22:46, John Baldwin wrote: >># gdb kernel >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain > conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd"... >> (gdb) l *0xffffffff803c1315 >> 0xffffffff803c1315 is in ng_address_hook > (/home/src/sys/netgraph/ng_base.c:3504). >> 3499 * Quick sanity check.. >> 3500 * Since a hook holds a reference on it's node, once we know >> 3501 * that the peer is still connected (even if invalid,) we > know >> 3502 * that the peer node is present, though maybe invalid. >> 3503 */ >> 3504 if ((hook == NULL) || >> 3505 NG_HOOK_NOT_VALID(hook) || >> 3506 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || >> 3507 NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { >> 3508 NG_FREE_ITEM(item); > > Hmmm. I think you might have a hardware problem. Notice the fault address, > it is 0x200000030. Can you do 'x/i '? (gdb) x/i 0xffffffff803c1315 0xffffffff803c1315 : testb $0x1,0x28(%rdx) (gdb) x/i *0xffffffff803c1315 0x12842f6: Cannot access memory at address 0x12842f6 > I suspect it is > doing a memory access from that has a constant offset of 0x30, in which case > the original pointer was 0x200000000, meaning it would be NULL except it has a > single-bit error. That would likely be caused by a hardware issue such as > failing RAM, etc. This is SuperMicro server with ECC RAM. I've already tested it with memtest86+ during long time, no memory problems found. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 06:25: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 D352C106566B for ; Tue, 1 Feb 2011 06:25:37 +0000 (UTC) (envelope-from lijimlee@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 66A628FC0C for ; Tue, 1 Feb 2011 06:25:36 +0000 (UTC) Received: by eyf6 with SMTP id 6so3084619eyf.13 for ; Mon, 31 Jan 2011 22:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=vaI/+LOAd9CipPy4AFDpyJXc/1sZTuuvR0BePGQ7fS0=; b=ock+V+z0duvRxePEnKgpa2B/nvbWM2Gib+GES18p85yggzLjkU1VulglodhJpymszf JoRgorVgqOSVAS4XrECCb4OsO+5/je5GrwgAiJYl+6KLxUnv2qZH51ncjVW6+tozWY3u DiyOLMbC74DdGpPajgdSQAsNX7V255hXIPSEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=JGVe7GA/RW2yC7GFngIfLiftdVKqNruAT0fwgUULP/tCIoAKAj+lQpx0hiC6DRoHt6 wJYgcBeC2e7ijt+GOJNRWi2WfMuLhPX0udIVyL22NtJjIV/ymOrMpI9AnCD+aw5OrKGE 9nzpNAtNXqt/fzQSDlh4uI7PT7ZWMxOYPiehA= MIME-Version: 1.0 Received: by 10.14.127.137 with SMTP id d9mr915267eei.2.1296539673188; Mon, 31 Jan 2011 21:54:33 -0800 (PST) Sender: lijimlee@gmail.com Received: by 10.14.53.72 with HTTP; Mon, 31 Jan 2011 21:54:33 -0800 (PST) Date: Mon, 31 Jan 2011 21:54:33 -0800 X-Google-Sender-Auth: CNwyy3Wi34Vs4RI2l67iCcBacjA Message-ID: From: Jim To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: why use INP_WLOCK instead of INP_RLOCK 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, 01 Feb 2011 06:25:37 -0000 Hi All, I am not sure if anybody has asked it before. I could not find answer by doing rough search on Internet, if it is duplicate question, sorry in advance. My question is that, for getting socket options in tcp_ctloutput() in tcp_usrreq.c, why do we need to do lock with INP_WLOCK(inp) as setting socket options does. Why do we just use INP_RLOCK(inp), as it looks not changing anything in tcp control block? Thank you for your kindly answer. Jim From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 07:10:24 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72E5D106564A for ; Tue, 1 Feb 2011 07:10:24 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 590258FC18 for ; Tue, 1 Feb 2011 07:10:24 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PkANb-000J5O-KC for net@freebsd.org; Tue, 01 Feb 2011 07:10:23 +0000 Date: Tue, 01 Feb 2011 16:10:22 +0900 Message-ID: From: Randy Bush To: FreeBSD Net User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: taps in rc.config 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, 01 Feb 2011 07:10:24 -0000 i want to run a whole bunch of dynamips virtualized ciscos inside a fbsd 8.x server. i want the virtual routers to have some interfaces which are externally visible. so i think i do something like ifconfig tap0 147.28.224.41/30 ifconfig tap1 147.28.224.45/30 ifconfig tap2 147.28.224.49/30 ifconfig tap3 147.28.224.53/30 ifconfig tap4 147.28.224.57/30 ifconfig tap5 147.28.224.61/30 ifconfig tap6 147.28.224.65/30 ifconfig tap7 147.28.224.69/30 ifconfig tap8 147.28.224.73/30 ifconfig tap9 147.28.224.77/30 and then bridge them on to the external ether. but i am a bit confuddled. can someone tell me how to do from command line, and then also how to code in /etc/rc.conf? thanks. randy clueless in tokyo From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 07:43:42 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23787106564A; Tue, 1 Feb 2011 07:43:42 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1548FC0A; Tue, 1 Feb 2011 07:43:42 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PkAtp-000JAX-Ij; Tue, 01 Feb 2011 07:43:41 +0000 Date: Tue, 01 Feb 2011 16:43:40 +0900 Message-ID: From: Randy Bush To: Julian Elischer In-Reply-To: <4D47B924.5070403@freebsd.org> References: <4D47B924.5070403@freebsd.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Net Subject: Re: taps in rc.config 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, 01 Feb 2011 07:43:42 -0000 > 1/ wow does that (dynamips ciscos) actually run on BSD? yep > 2/ "why?" so we can have a routing research topology testbed of real cisco and real juniper code. > first you need to create them right? > ifconfig tap0 create 192.168.3.1/28 up > > I think you do: > in rc.conf: > cloned_interfaces="tap0 tap1 tap2 tap3" > ifconfig_tap0=192.168.3.1/28 > ifconfig_tap1=192.168.4.1/28 > ifconfig_tap2=192.168.5.1/28 > ifconfig_tap3=192.168.6.1/28 > > but I may not be remembering right. thanks. and what binds them to a particular ether so they respond to arp? randy From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 07:56:26 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E0C8106566C for ; Tue, 1 Feb 2011 07:56:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id C7B718FC08 for ; Tue, 1 Feb 2011 07:56:25 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p117fLYM046309 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 23:41:32 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D47B924.5070403@freebsd.org> Date: Mon, 31 Jan 2011 23:41:24 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: taps in rc.config 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, 01 Feb 2011 07:56:26 -0000 On 1/31/11 11:10 PM, Randy Bush wrote: > i want to run a whole bunch of dynamips virtualized ciscos inside a fbsd > 8.x server. i want the virtual routers to have some interfaces which > are externally visible. > > so i think i do something like > > ifconfig tap0 147.28.224.41/30 > ifconfig tap1 147.28.224.45/30 > ifconfig tap2 147.28.224.49/30 > ifconfig tap3 147.28.224.53/30 > ifconfig tap4 147.28.224.57/30 > ifconfig tap5 147.28.224.61/30 > ifconfig tap6 147.28.224.65/30 > ifconfig tap7 147.28.224.69/30 > ifconfig tap8 147.28.224.73/30 > ifconfig tap9 147.28.224.77/30 > > and then bridge them on to the external ether. but i am a bit > confuddled. can someone tell me how to do from command line, and then > also how to code in /etc/rc.conf? 1/ wow does that (dynamips ciscos) actually run on BSD? 2/ "why?" first you need to create them right? ifconfig tap0 create 192.168.3.1/28 up I think you do: in rc.conf: cloned_interfaces="tap0 tap1 tap2 tap3" ifconfig_tap0=192.168.3.1/28 ifconfig_tap1=192.168.4.1/28 ifconfig_tap2=192.168.5.1/28 ifconfig_tap3=192.168.6.1/28 but I may not be remembering right. if you just need the functionality and not specifically the ciscos, use vimage based routers. > thanks. > > randy > clueless in tokyo > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 08:19:41 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B0E410656BD; Tue, 1 Feb 2011 08:19:41 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6EF8FC1E; Tue, 1 Feb 2011 08:19:41 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PkBSe-000JHn-Dj; Tue, 01 Feb 2011 08:19:40 +0000 Date: Tue, 01 Feb 2011 17:19:38 +0900 Message-ID: From: Randy Bush To: batcilla itself In-Reply-To: References: <4D47B924.5070403@freebsd.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Net Subject: Re: taps in rc.config 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, 01 Feb 2011 08:19:41 -0000 cloned_interfaces="tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9" ifconfig_tap0=147.28.224.41/30 ifconfig_tap1=147.28.224.45/30 ifconfig_tap2=147.28.224.49/30 ifconfig_tap3=147.28.224.53/30 ifconfig_tap4=147.28.224.57/30 ifconfig_tap5=147.28.224.61/30 ifconfig_tap6=147.28.224.65/30 ifconfig_tap7=147.28.224.69/30 ifconfig_tap8=147.28.224.73/30 ifconfig_tap9=147.28.224.77/30 autobridge_interfaces=bridge0 autobridge_bridge0="tap* igb0" gets me no bridge. do i need a cloned interface for it? igb0: flags=8843 metric 0 mtu 1500 options=13b ether 00:30:48:d6:6c:22 inet 198.180.152.11 netmask 0xffffffc0 broadcast 198.180.152.63 inet 198.180.152.30 netmask 0xffffffff broadcast 198.180.152.30 inet 198.180.152.31 netmask 0xffffffff broadcast 198.180.152.31 inet 198.180.152.32 netmask 0xffffffff broadcast 198.180.152.32 inet 198.180.152.33 netmask 0xffffffff broadcast 198.180.152.33 inet 198.180.152.34 netmask 0xffffffff broadcast 198.180.152.34 inet 198.180.152.35 netmask 0xffffffff broadcast 198.180.152.35 inet 198.180.152.36 netmask 0xffffffff broadcast 198.180.152.36 inet 198.180.152.37 netmask 0xffffffff broadcast 198.180.152.37 inet 198.180.152.38 netmask 0xffffffff broadcast 198.180.152.38 inet 198.180.152.39 netmask 0xffffffff broadcast 198.180.152.39 media: Ethernet autoselect (1000baseT ) status: active igb1: flags=8843 metric 0 mtu 1500 options=13b ether 00:30:48:d6:6c:23 inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseT ) status: active 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=8843 metric 0 mtu 1500 ether 00:bd:b8:25:00:00 inet 147.28.224.41 netmask 0xfffffffc broadcast 147.28.224.43 tap1: flags=8843 metric 0 mtu 1500 ether 00:bd:bc:25:00:01 inet 147.28.224.45 netmask 0xfffffffc broadcast 147.28.224.47 tap2: flags=8843 metric 0 mtu 1500 ether 00:bd:c1:25:00:02 inet 147.28.224.49 netmask 0xfffffffc broadcast 147.28.224.51 tap3: flags=8843 metric 0 mtu 1500 ether 00:bd:c5:25:00:03 inet 147.28.224.53 netmask 0xfffffffc broadcast 147.28.224.55 tap4: flags=8843 metric 0 mtu 1500 ether 00:bd:c9:25:00:04 inet 147.28.224.57 netmask 0xfffffffc broadcast 147.28.224.59 tap5: flags=8843 metric 0 mtu 1500 ether 00:bd:cd:25:00:05 inet 147.28.224.61 netmask 0xfffffffc broadcast 147.28.224.63 tap6: flags=8843 metric 0 mtu 1500 ether 00:bd:d1:25:00:06 inet 147.28.224.65 netmask 0xfffffffc broadcast 147.28.224.67 tap7: flags=8843 metric 0 mtu 1500 ether 00:bd:d5:25:00:07 inet 147.28.224.69 netmask 0xfffffffc broadcast 147.28.224.71 tap8: flags=8843 metric 0 mtu 1500 ether 00:bd:d9:25:00:08 inet 147.28.224.73 netmask 0xfffffffc broadcast 147.28.224.75 tap9: flags=8843 metric 0 mtu 1500 ether 00:bd:dd:25:00:09 inet 147.28.224.77 netmask 0xfffffffc broadcast 147.28.224.79 From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 08:20:01 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5C2B10656A3 for ; Tue, 1 Feb 2011 08:20:01 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 741ED8FC12 for ; Tue, 1 Feb 2011 08:20:01 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p118JvnL046496 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 00:19:59 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D47C232.2090903@freebsd.org> Date: Tue, 01 Feb 2011 00:20:02 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <4D47B924.5070403@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: taps in rc.config 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, 01 Feb 2011 08:20:01 -0000 On 1/31/11 11:43 PM, Randy Bush wrote: >> 1/ wow does that (dynamips ciscos) actually run on BSD? > yep > >> 2/ "why?" > so we can have a routing research topology testbed of real cisco and > real juniper code. > >> first you need to create them right? >> ifconfig tap0 create 192.168.3.1/28 up >> >> I think you do: >> in rc.conf: >> cloned_interfaces="tap0 tap1 tap2 tap3" >> ifconfig_tap0=192.168.3.1/28 >> ifconfig_tap1=192.168.4.1/28 >> ifconfig_tap2=192.168.5.1/28 >> ifconfig_tap3=192.168.6.1/28 >> >> but I may not be remembering right. > thanks. and what binds them to a particular ether so they respond to > arp? does the dynamips thingy know how to read the /dev side of a tap device? if so then I think you can use the bridging facilities, you should be able to use teh autobridge config settings.. look in /etc/defaults/rc.conf for an example.. it shows tap/if examples.. man rc.conf for more details.. remember don't change that file... put your changes in /etc/rc.conf > randy > From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 08:27:55 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D5601065679; Tue, 1 Feb 2011 08:27:55 +0000 (UTC) (envelope-from batcilla@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id E6BAB8FC14; Tue, 1 Feb 2011 08:27:54 +0000 (UTC) Received: by qwj9 with SMTP id 9so6276733qwj.13 for ; Tue, 01 Feb 2011 00:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=S4jcSsJCxtleiMPl0LIDpva4x9adsg4LbyxVr8u5LfM=; b=DImYbsff4sB1diwQp6Ws9MP1AG7YK4It3cab5F75c5gU8OXiA/cclCQJeYmWN84OPW vVV8LUxuj8QieJiPaSTK8KXncMdjZ4BnBm4/ZwZg/FTy1w6G+dxH53QgHb6QHIyru1Nf N7TlaepS0ASW30R2n6A2eWc2z24n2959fUoFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KcoDky3KM7XJyWyeoRXGmyOqkRP2HcmfCH4QtFTCo2zL0pwvq3XdalksbKPm4o8tYz lNqKt5q/+kP3ECmMJgmy/BKlXiKMVz99v4ThQGjzMzEyqX48uDxlbWVZ1L37fM3k7YJA 7vfvdipkW9/ya5tUHN5JYShEsbvkdSg8SnU9s= MIME-Version: 1.0 Received: by 10.229.193.204 with SMTP id dv12mr4984136qcb.274.1296548874207; Tue, 01 Feb 2011 00:27:54 -0800 (PST) Received: by 10.229.228.145 with HTTP; Tue, 1 Feb 2011 00:27:54 -0800 (PST) In-Reply-To: References: <4D47B924.5070403@freebsd.org> Date: Tue, 1 Feb 2011 10:27:54 +0200 Message-ID: From: batcilla itself To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: taps in rc.config 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, 01 Feb 2011 08:27:55 -0000 2011/2/1 Randy Bush > cloned_interfaces="*bridge0* tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 > tap9" > ifconfig_tap0=147.28.224.41/30 > ifconfig_tap1=147.28.224.45/30 > ifconfig_tap2=147.28.224.49/30 > ifconfig_tap3=147.28.224.53/30 > ifconfig_tap4=147.28.224.57/30 > ifconfig_tap5=147.28.224.61/30 > ifconfig_tap6=147.28.224.65/30 > ifconfig_tap7=147.28.224.69/30 > ifconfig_tap8=147.28.224.73/30 > ifconfig_tap9=147.28.224.77/30 > autobridge_interfaces=bridge0 > autobridge_bridge0="tap* igb0" > > gets me no bridge. do i need a cloned interface for it? > Yes, it should be in cloned_interfaces list. > > igb0: flags=8843 metric 0 mtu 1500 > options=13b > ether 00:30:48:d6:6c:22 > inet 198.180.152.11 netmask 0xffffffc0 broadcast 198.180.152.63 > inet 198.180.152.30 netmask 0xffffffff broadcast 198.180.152.30 > inet 198.180.152.31 netmask 0xffffffff broadcast 198.180.152.31 > inet 198.180.152.32 netmask 0xffffffff broadcast 198.180.152.32 > inet 198.180.152.33 netmask 0xffffffff broadcast 198.180.152.33 > inet 198.180.152.34 netmask 0xffffffff broadcast 198.180.152.34 > inet 198.180.152.35 netmask 0xffffffff broadcast 198.180.152.35 > inet 198.180.152.36 netmask 0xffffffff broadcast 198.180.152.36 > inet 198.180.152.37 netmask 0xffffffff broadcast 198.180.152.37 > inet 198.180.152.38 netmask 0xffffffff broadcast 198.180.152.38 > inet 198.180.152.39 netmask 0xffffffff broadcast 198.180.152.39 > media: Ethernet autoselect (1000baseT ) > status: active > igb1: flags=8843 metric 0 mtu 1500 > options=13b > ether 00:30:48:d6:6c:23 > inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 > media: Ethernet autoselect (1000baseT ) > status: active > 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=8843 metric 0 mtu 1500 > ether 00:bd:b8:25:00:00 > inet 147.28.224.41 netmask 0xfffffffc broadcast 147.28.224.43 > tap1: flags=8843 metric 0 mtu 1500 > ether 00:bd:bc:25:00:01 > inet 147.28.224.45 netmask 0xfffffffc broadcast 147.28.224.47 > tap2: flags=8843 metric 0 mtu 1500 > ether 00:bd:c1:25:00:02 > inet 147.28.224.49 netmask 0xfffffffc broadcast 147.28.224.51 > tap3: flags=8843 metric 0 mtu 1500 > ether 00:bd:c5:25:00:03 > inet 147.28.224.53 netmask 0xfffffffc broadcast 147.28.224.55 > tap4: flags=8843 metric 0 mtu 1500 > ether 00:bd:c9:25:00:04 > inet 147.28.224.57 netmask 0xfffffffc broadcast 147.28.224.59 > tap5: flags=8843 metric 0 mtu 1500 > ether 00:bd:cd:25:00:05 > inet 147.28.224.61 netmask 0xfffffffc broadcast 147.28.224.63 > tap6: flags=8843 metric 0 mtu 1500 > ether 00:bd:d1:25:00:06 > inet 147.28.224.65 netmask 0xfffffffc broadcast 147.28.224.67 > tap7: flags=8843 metric 0 mtu 1500 > ether 00:bd:d5:25:00:07 > inet 147.28.224.69 netmask 0xfffffffc broadcast 147.28.224.71 > tap8: flags=8843 metric 0 mtu 1500 > ether 00:bd:d9:25:00:08 > inet 147.28.224.73 netmask 0xfffffffc broadcast 147.28.224.75 > tap9: flags=8843 metric 0 mtu 1500 > ether 00:bd:dd:25:00:09 > inet 147.28.224.77 netmask 0xfffffffc broadcast 147.28.224.79 > From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 08:29:24 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89EA4106567A; Tue, 1 Feb 2011 08:29:24 +0000 (UTC) (envelope-from batcilla@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 30D2B8FC14; Tue, 1 Feb 2011 08:29:23 +0000 (UTC) Received: by qyk8 with SMTP id 8so3769410qyk.13 for ; Tue, 01 Feb 2011 00:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MEfeQ0GqZqEakUL8CWiLvUHD5QwQWzpH2gDKinzcAB8=; b=P7WKIQOZSBORMXEFdC1BjB+2VRHvIzjYpz0/4jv7XGyYR/gQ/0N57O9XmfcmRgMQFT BVJ71Mm3eJubd/WZRX8AsTDEA0OWE4vJW17TiG2kWnWSwTxC55VLZvNAFExCAJvANRfq ZsqoaUdmQSDMv4dwElY+BYAKngjcP6WLc1FaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AcjLgVbzONwCptEzhNmGf14DxO8aZOG8Ekx9VeNgs0nVaEylCbzIIn33+8oM63hKL1 yXgaPtISA/AeooLPirpMApiU02oA8Nilq6SKnROYA212/FoqoxFwquBuMgLe+c4PLquN rQBQKsF28teHHwUYE5xRPgO/Wb2kfBnaX1upg= MIME-Version: 1.0 Received: by 10.229.91.3 with SMTP id k3mr6764574qcm.84.1296547281157; Tue, 01 Feb 2011 00:01:21 -0800 (PST) Received: by 10.229.228.145 with HTTP; Tue, 1 Feb 2011 00:01:21 -0800 (PST) In-Reply-To: References: <4D47B924.5070403@freebsd.org> Date: Tue, 1 Feb 2011 10:01:21 +0200 Message-ID: From: batcilla itself To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: taps in rc.config 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, 01 Feb 2011 08:29:24 -0000 Hi Randy, I believe this may help(found in /etc/defaults/rc.conf): #autobridge_interfaces="bridge0" # List of bridges to check #autobridge_bridge0="tap* em0" # Interface glob to automatically add to the bridge if used in addition to example below. //batcilla 2011/2/1 Randy Bush > > 1/ wow does that (dynamips ciscos) actually run on BSD? > > yep > > > 2/ "why?" > > so we can have a routing research topology testbed of real cisco and > real juniper code. > > > first you need to create them right? > > ifconfig tap0 create 192.168.3.1/28 up > > > > I think you do: > > in rc.conf: > > cloned_interfaces="tap0 tap1 tap2 tap3" > > ifconfig_tap0=192.168.3.1/28 > > ifconfig_tap1=192.168.4.1/28 > > ifconfig_tap2=192.168.5.1/28 > > ifconfig_tap3=192.168.6.1/28 > > > > but I may not be remembering right. > > thanks. and what binds them to a particular ether so they respond to > arp? > > randy > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 08:35:02 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31A84106566B; Tue, 1 Feb 2011 08:35:02 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 12FC58FC16; Tue, 1 Feb 2011 08:35:02 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PkBhV-000JM3-Fi; Tue, 01 Feb 2011 08:35:01 +0000 Date: Tue, 01 Feb 2011 17:35:00 +0900 Message-ID: From: Randy Bush To: batcilla itself In-Reply-To: References: <4D47B924.5070403@freebsd.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Net Subject: Re: taps in rc.config 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, 01 Feb 2011 08:35:02 -0000 >> gets me no bridge. do i need a cloned interface for it? > Yes, it should be in cloned_interfaces list. works perfectly. thank you!! randy From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 14:38:18 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 3D7B5106566C for ; Tue, 1 Feb 2011 14:38:18 +0000 (UTC) (envelope-from monthadar@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 CA1CE8FC08 for ; Tue, 1 Feb 2011 14:38:17 +0000 (UTC) Received: by wyf19 with SMTP id 19so7001877wyf.13 for ; Tue, 01 Feb 2011 06:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=RAy0hewFDV7QqpslmB+8JV4mcsRbShdEKkgVUP6j9bA=; b=W/RQHakzUuZtACwObggK/Oc62t+PiPA+VNwtexsDXFQPIsV/hy6EqjwEDLfqnFere7 YW7nyRddmjRRWNIrmpCPS1tkoMy7qKKY7FMCISKCUssHPMtsJYCXeC+2nRk/9YmfrkeB FKexKqAAFteFLRPvH2ca3LxJUfqi+0oEDEoI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZrvzbFOMije+32BykbEyra5ckc459N0zSIgKXdjs5AaWAh4ozNM/TknK2AhAwMo6wJ Nu1BSHwLIsl17tIWcSUOCmSFSgz+DzLKr3q7QipL/T32kAk4o6Q6Hnlvwj9L/3SIl2as iYFNWJZN8AY2lMW3Flr6MpJ8tY85G9Rmt3S68= MIME-Version: 1.0 Received: by 10.227.156.10 with SMTP id u10mr7760913wbw.224.1296571096645; Tue, 01 Feb 2011 06:38:16 -0800 (PST) Received: by 10.227.134.137 with HTTP; Tue, 1 Feb 2011 06:38:16 -0800 (PST) Date: Tue, 1 Feb 2011 15:38:16 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: if_alloc() page fault, VirtualBox + VIMAGE 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, 01 Feb 2011 14:38:18 -0000 Hi, I am running FreeBSD Current (201010) as guest in VirtualBox on an Ubuntu 10.04. FreeBSD is compiled with VIMAGE option. I loaded a module (my own) that calls if_alloc(IFT_IEEE80211), but I get a panic: Kernel page fault with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0fc8284) locked @ /usr/src/sys/net/if.c:414 KDB: stack backtrace: db_trace_self_wrapper(c0cf3cdb,1,0,0,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(19e,1,ffffffff,c0f9b194,c2fc9a1c,...) at kdb_backtrace+0x2a _witness_debugger(c0cf6408,c2fc9a30,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0d2c479,3,c4070d48,...) at witness_warn+0x1fe trap(c2fc9abc) at trap+0x195 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0970999, esp = 0xc2fc9afc, ebp = 0xc2fc9b1c --- ifindex_alloc_locked(c0d003cf,c2fc9b36,19e,19e,c15ab714,...) at ifindex_alloc_locked+0x19 if_alloc(47,c4085a16,3,c0de9614,c32aa780,...) at if_alloc+0x85 wtap_attach(c31a7800,c40857c0,0,4,0,...) at wtap_attach+0x29 new_wtap(c32aa780,0,c2fc9bf0,c083ac9b,c3cbb200,...) at new_wtap+0x9b wtap_ioctl(c3cbb200,80045701,c31edaa0,1,c3f90b40,...) at wtap_ioctl+0x36 devfs_ioctl_f(c3cfe3b8,80045701,c31edaa0,c3185d00,c3f90b40,...) at devfs_ioctl_f+0x10b kern_ioctl(c3f90b40,3,80045701,c31edaa0,fc9cec,...) at kern_ioctl+0x20d ioctl(c3f90b40,c2fc9cec,c2fc9d28,c0cf5783,0,...) at ioctl+0x134 syscallenter(c3f90b40,c2fc9ce4,c2fc9ce4,0,0,...) at syscallenter+0x263 syscall(c2fc9d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28181203, esp = 0xbfbfec3c, ebp = 0xbfbfec58 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0970999 stack pointer = 0x28:0xc2fc9afc frame pointer = 0x28:0xc2fc9b1c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1203 (ioctl) panic: from debugger cpuid = 0 Uptime: 21s Physical memory: 495 MB Dumping 55 MB: 40 24 8 Without VIMAGE option if_alloc returns fine, I thought if I dont create any VNETs the system should behave like normal... what is the problem? Best regards, -- //Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 14:53: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 E83E1106566B for ; Tue, 1 Feb 2011 14:53:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BA7198FC13 for ; Tue, 1 Feb 2011 14:53:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5D3A546B0D; Tue, 1 Feb 2011 09:53:10 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 59FE08A01D; Tue, 1 Feb 2011 09:53:09 -0500 (EST) From: John Baldwin To: Eugene Grosbein Date: Tue, 1 Feb 2011 08:17:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D3011DB.9050900@frasunek.com> <201101311146.43119.jhb@freebsd.org> <4D479FE0.70809@rdtc.ru> In-Reply-To: <4D479FE0.70809@rdtc.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102010817.04927.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Feb 2011 09:53:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-net@freebsd.org Subject: Re: panic: bufwrite: buffer is not busy??? 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, 01 Feb 2011 14:53:11 -0000 On Tuesday, February 01, 2011 12:53:36 am Eugene Grosbein wrote: > On 31.01.2011 22:46, John Baldwin wrote: > > >># gdb kernel > >> GNU gdb 6.1.1 [FreeBSD] > >> Copyright 2004 Free Software Foundation, Inc. > >> GDB is free software, covered by the GNU General Public License, and you are > >> welcome to change it and/or distribute copies of it under certain > > conditions. > >> Type "show copying" to see the conditions. > >> There is absolutely no warranty for GDB. Type "show warranty" for details. > >> This GDB was configured as "amd64-marcel-freebsd"... > >> (gdb) l *0xffffffff803c1315 > >> 0xffffffff803c1315 is in ng_address_hook > > (/home/src/sys/netgraph/ng_base.c:3504). > >> 3499 * Quick sanity check.. > >> 3500 * Since a hook holds a reference on it's node, once we know > >> 3501 * that the peer is still connected (even if invalid,) we > > know > >> 3502 * that the peer node is present, though maybe invalid. > >> 3503 */ > >> 3504 if ((hook == NULL) || > >> 3505 NG_HOOK_NOT_VALID(hook) || > >> 3506 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || > >> 3507 NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { > >> 3508 NG_FREE_ITEM(item); > > > > Hmmm. I think you might have a hardware problem. Notice the fault address, > > it is 0x200000030. Can you do 'x/i '? > > (gdb) x/i 0xffffffff803c1315 > 0xffffffff803c1315 : testb $0x1,0x28(%rdx) Hmm, offset is 0x28, so the original pointer would have been 0x200000008, which has two bits set. That is a bit more of a stretch. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 14:53:11 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2867106564A; Tue, 1 Feb 2011 14:53:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 92DDE8FC14; Tue, 1 Feb 2011 14:53:11 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 45FDF46B17; Tue, 1 Feb 2011 09:53:11 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 89E608A027; Tue, 1 Feb 2011 09:53:10 -0500 (EST) From: John Baldwin To: Lawrence Stewart Date: Tue, 1 Feb 2011 08:29:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101311217.07073.jhb@freebsd.org> <4D477289.8040901@freebsd.org> In-Reply-To: <4D477289.8040901@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102010829.24043.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Feb 2011 09:53:10 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Bjoern A. Zeeb" , Andre Oppermann , net@freebsd.org Subject: Re: Bogus KASSERT() in tcp_output()? 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, 01 Feb 2011 14:53:11 -0000 On Monday, January 31, 2011 9:40:09 pm Lawrence Stewart wrote: > On 02/01/11 04:17, John Baldwin wrote: > > Somewhat related fallout to the bug reported on security@ recently, I think > > this KASSERT() in tcp_output() is bogus: > > > > > > KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL), > > ("%s: mbuf chain shorter than expected", __func__)); > > > > Specifically, just a few lines earlier in tcp_output() we set the packet > > header length to just 'len + hdrlen': > > > > /* > > * Put TCP length in extended header, and then > > * checksum extended header and data. > > */ > > m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */ > > > > Also, the ipoptions are stored in a separate mbuf chain in the in pcb > > (inp_options) that is passed as a separate argument to ip_output(). Given > > that, I would think that m_length() should not reflect ipoptlen since it > > should not include IP options in that chain? > > > > There is some relevant prior discussion on src-committers@ for r212803 > between Andre and Bjoern. I still don't see where ipoptlen bytes are reserved in the mbuf chain. After this block where 'm' is allocated and initialized: /* * Grab a header mbuf, attaching a copy of data to * be transmitted, and initialize the header from * the template for sends on this connection. */ if (len) { ... m->m_len = hdrlen; ... if (len <= MHLEN - hdrlen - max_linkhdr) { ... m->m_len += len; } else { m->m_next = m_copy(mb, moff, (int)len); ... } ... } else { ... m->m_len = hdrlen; } The length of the mbuf chain headed by 'm' is clearly hdrlen + len. At no point anywhere do we do any sort of m_prepend() or other operation to allocate space in the mbuf chain for the IP options. They are merged in in ip_output(). I think the only reason this KASSERT() isn't firing in HEAD is that IP options are rarely used? Is there an easy way to test a connection with IP options enabled with this KASSERT() enabled? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 14:53: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 A90371065796 for ; Tue, 1 Feb 2011 14:53:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7D40B8FC08 for ; Tue, 1 Feb 2011 14:53:16 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3DCFD46B0D; Tue, 1 Feb 2011 09:53:16 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 75FA68A02A; Tue, 1 Feb 2011 09:53:15 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Tue, 1 Feb 2011 09:49:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102010949.07643.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Feb 2011 09:53:15 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Monthadar Al Jaberi Subject: Re: if_alloc() page fault, VirtualBox + VIMAGE 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, 01 Feb 2011 14:53:16 -0000 On Tuesday, February 01, 2011 9:38:16 am Monthadar Al Jaberi wrote: > Hi, > > I am running FreeBSD Current (201010) as guest in VirtualBox on an > Ubuntu 10.04. FreeBSD is compiled with VIMAGE option. > > I loaded a module (my own) that calls if_alloc(IFT_IEEE80211), but I > get a panic: Did you compile your module with VIMAGE enabled? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 14:55:08 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 501AF10656B4 for ; Tue, 1 Feb 2011 14:55:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id CB8A08FC12 for ; Tue, 1 Feb 2011 14:55:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8292441C798; Tue, 1 Feb 2011 15:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id GgE+NhaSG3Mc; Tue, 1 Feb 2011 15:55:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 878D541C7A8; Tue, 1 Feb 2011 15:55:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id AA8E04448F3; Tue, 1 Feb 2011 14:53:41 +0000 (UTC) Date: Tue, 1 Feb 2011 14:53:41 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Monthadar Al Jaberi In-Reply-To: Message-ID: <20110201145319.W43179@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: if_alloc() page fault, VirtualBox + VIMAGE 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, 01 Feb 2011 14:55:08 -0000 On Tue, 1 Feb 2011, Monthadar Al Jaberi wrote: > Hi, > > I am running FreeBSD Current (201010) as guest in VirtualBox on an > Ubuntu 10.04. FreeBSD is compiled with VIMAGE option. > > I loaded a module (my own) that calls if_alloc(IFT_IEEE80211), but I > get a panic: see discussions and patch on freebsd-virtualization@ > Kernel page fault with the following non-sleepable locks held: > exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0fc8284) locked @ > /usr/src/sys/net/if.c:414 > KDB: stack backtrace: > db_trace_self_wrapper(c0cf3cdb,1,0,0,0,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(19e,1,ffffffff,c0f9b194,c2fc9a1c,...) at kdb_backtrace+0x2a > _witness_debugger(c0cf6408,c2fc9a30,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0d2c479,3,c4070d48,...) at witness_warn+0x1fe > trap(c2fc9abc) at trap+0x195 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc0970999, esp = 0xc2fc9afc, ebp = 0xc2fc9b1c --- > ifindex_alloc_locked(c0d003cf,c2fc9b36,19e,19e,c15ab714,...) at > ifindex_alloc_locked+0x19 > if_alloc(47,c4085a16,3,c0de9614,c32aa780,...) at if_alloc+0x85 > wtap_attach(c31a7800,c40857c0,0,4,0,...) at wtap_attach+0x29 > new_wtap(c32aa780,0,c2fc9bf0,c083ac9b,c3cbb200,...) at new_wtap+0x9b > wtap_ioctl(c3cbb200,80045701,c31edaa0,1,c3f90b40,...) at wtap_ioctl+0x36 > devfs_ioctl_f(c3cfe3b8,80045701,c31edaa0,c3185d00,c3f90b40,...) at > devfs_ioctl_f+0x10b > kern_ioctl(c3f90b40,3,80045701,c31edaa0,fc9cec,...) at kern_ioctl+0x20d > ioctl(c3f90b40,c2fc9cec,c2fc9d28,c0cf5783,0,...) at ioctl+0x134 > syscallenter(c3f90b40,c2fc9ce4,c2fc9ce4,0,0,...) at syscallenter+0x263 > syscall(c2fc9d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28181203, esp = > 0xbfbfec3c, ebp = 0xbfbfec58 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0970999 > stack pointer = 0x28:0xc2fc9afc > frame pointer = 0x28:0xc2fc9b1c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1203 (ioctl) > panic: from debugger > cpuid = 0 > Uptime: 21s > Physical memory: 495 MB > Dumping 55 MB: 40 24 8 > > > Without VIMAGE option if_alloc returns fine, I thought if I dont > create any VNETs the system should behave like normal... what is the > problem? > > Best regards, > > -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 14:59: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 567B91065697 for ; Tue, 1 Feb 2011 14:59:25 +0000 (UTC) (envelope-from monthadar@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 E1C328FC1D for ; Tue, 1 Feb 2011 14:59:24 +0000 (UTC) Received: by wwi17 with SMTP id 17so4857730wwi.1 for ; Tue, 01 Feb 2011 06:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sOMEq09MyXNQetVLysRkfaGU3AvOKOipNWDagAdoLO8=; b=R7CXF976WoRydsNkenPeVXd1tn9Yx8cYfZfFv8S+hxELgmTpv8W73XLl2HvkrC+GAD 2OFcWvdYyEpfpqd2EmouZVk1CmSOQOwgNF62a1jBDkvOZJ4KV8zHvoTDyLsw9edczcnV aiXFiXqFKVLJKiecoPGn5/glldnv+vmB5S6EA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jbxeeR1dmxT6CUD68bPHtAnK9V9nShqtEZdoGoA2/BuDRcrJjCCwVnaavv2INFhvIg nnqPMGJoDZvF0qNH4pCBBtKBmw+IYoR7jEOfXDcIwAqdH3rJcbwy0hY/aPQCqtiB4jlf qlec1jGHaJdaolDlKPIN0E+GQvXQHMqKKVc38= MIME-Version: 1.0 Received: by 10.227.129.17 with SMTP id m17mr7740180wbs.79.1296572363465; Tue, 01 Feb 2011 06:59:23 -0800 (PST) Received: by 10.227.134.137 with HTTP; Tue, 1 Feb 2011 06:59:20 -0800 (PST) In-Reply-To: <201102010949.07643.jhb@freebsd.org> References: <201102010949.07643.jhb@freebsd.org> Date: Tue, 1 Feb 2011 15:59:20 +0100 Message-ID: From: Monthadar Al Jaberi To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: if_alloc() page fault, VirtualBox + VIMAGE 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, 01 Feb 2011 14:59:25 -0000 On Tue, Feb 1, 2011 at 3:49 PM, John Baldwin wrote: > On Tuesday, February 01, 2011 9:38:16 am Monthadar Al Jaberi wrote: >> Hi, >> >> I am running FreeBSD Current (201010) as guest in VirtualBox on an >> Ubuntu 10.04. FreeBSD is compiled with VIMAGE option. >> >> I loaded a module (my own) that calls if_alloc(IFT_IEEE80211), but I >> get a panic: > > Did you compile your module with VIMAGE enabled? How do I check that? My makefile is: # Note: It is important to make sure you include the makefile after declaring the KMOD and SRCS variables. .PATH: ${.CURDIR}/wtap_hal # Declare Name of kernel module KMOD = wtap # Enumerate Source files for kernel module SRCS = if_wtap_module.c if_wtap.c if_medium.c hal.c # Include kernel module makefile .include > > -- > John Baldwin > Thnx Bjoern, I will check the mailing list br -- //Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 17:40:08 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B3CD106566B; Tue, 1 Feb 2011 17:40:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 619978FC0A; Tue, 1 Feb 2011 17:40:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6171641C7A5; Tue, 1 Feb 2011 18:40:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id rjt5CfTDUgin; Tue, 1 Feb 2011 18:40:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id EA9B841C7A4; Tue, 1 Feb 2011 18:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id ADF244448F3; Tue, 1 Feb 2011 17:37:58 +0000 (UTC) Date: Tue, 1 Feb 2011 17:37:58 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: John Baldwin In-Reply-To: <201102010829.24043.jhb@freebsd.org> Message-ID: <20110201171959.W43179@maildrop.int.zabbadoz.net> References: <201101311217.07073.jhb@freebsd.org> <4D477289.8040901@freebsd.org> <201102010829.24043.jhb@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Lawrence Stewart , Andre Oppermann , net@freebsd.org Subject: Re: Bogus KASSERT() in tcp_output()? 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, 01 Feb 2011 17:40:08 -0000 On Tue, 1 Feb 2011, John Baldwin wrote: > On Monday, January 31, 2011 9:40:09 pm Lawrence Stewart wrote: >> On 02/01/11 04:17, John Baldwin wrote: >>> Somewhat related fallout to the bug reported on security@ recently, I think >>> this KASSERT() in tcp_output() is bogus: >>> >>> >>> KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL), >>> ("%s: mbuf chain shorter than expected", __func__)); >>> >>> Specifically, just a few lines earlier in tcp_output() we set the packet >>> header length to just 'len + hdrlen': >>> >>> /* >>> * Put TCP length in extended header, and then >>> * checksum extended header and data. >>> */ >>> m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */ >>> >>> Also, the ipoptions are stored in a separate mbuf chain in the in pcb >>> (inp_options) that is passed as a separate argument to ip_output(). Given >>> that, I would think that m_length() should not reflect ipoptlen since it >>> should not include IP options in that chain? >>> >> >> There is some relevant prior discussion on src-committers@ for r212803 >> between Andre and Bjoern. > > I still don't see where ipoptlen bytes are reserved in the mbuf chain. After > this block where 'm' is allocated and initialized: > > /* > * Grab a header mbuf, attaching a copy of data to > * be transmitted, and initialize the header from > * the template for sends on this connection. > */ > if (len) { > ... > m->m_len = hdrlen; > ... > if (len <= MHLEN - hdrlen - max_linkhdr) { > ... > m->m_len += len; > } else { > m->m_next = m_copy(mb, moff, (int)len); > ... > } > ... > } else { > ... > m->m_len = hdrlen; > } > > The length of the mbuf chain headed by 'm' is clearly hdrlen + len. It is. > At no point anywhere do we do any sort of m_prepend() or other operation to > allocate space in the mbuf chain for the IP options. They are merged in in > ip_output(). I think the only reason this KASSERT() isn't firing in HEAD is > that IP options are rarely used? Right and probably reason why I also hit it with IPSec as result of 718 #ifdef IPSEC 719 ipoptlen += ipsec_optlen; 720 #endif which wasn't because of ipsec_optlen really, I had just stopping looking too soon back last year. > Is there an easy way to test a connection with IP options enabled with this > KASSERT() enabled? Yes, see patch at [1], and using my modified KASSERT still I get... which btw sounds wrong to me as well btw as I wouldn't expect ipoptlen to be 4 here given the test case. # ./tcpconnect client 127.0.0.1 12345 1 ipopt panic: tcp_output: mbuf chain shorter than expected: 0 + 60 + 4 - 0 != 60 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 tcp_output() at tcp_output+0x1d01 tcp_usr_connect() at tcp_usr_connect+0x15f soconnect() at soconnect+0x14f kern_connect() at kern_connect+0x12e connect() at connect+0x41 syscallenter() at syscallenter+0x1cb syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (98, FreeBSD ELF64, connect), rip = 0x80072934c, rsp = 0x7fffffffe9d8, rbp = 0x3 --- /bz References: [1] http://people.freebsd.org/~bz/20110201-01-tcpconnect-ipopt.diff -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 17:50:06 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 C7E961065674; Tue, 1 Feb 2011 17:50:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1638FC1A; Tue, 1 Feb 2011 17:50:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D569541C735; Tue, 1 Feb 2011 18:50:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 6IxdfJLSg2z4; Tue, 1 Feb 2011 18:50:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 6505F41C733; Tue, 1 Feb 2011 18:50:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id C25F64448F3; Tue, 1 Feb 2011 17:48:09 +0000 (UTC) Date: Tue, 1 Feb 2011 17:48:09 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Monthadar Al Jaberi In-Reply-To: Message-ID: <20110201174653.Y43179@maildrop.int.zabbadoz.net> References: <201102010949.07643.jhb@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: if_alloc() page fault, VirtualBox + VIMAGE 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, 01 Feb 2011 17:50:06 -0000 On Tue, 1 Feb 2011, Monthadar Al Jaberi wrote: > On Tue, Feb 1, 2011 at 3:49 PM, John Baldwin wrote: >> On Tuesday, February 01, 2011 9:38:16 am Monthadar Al Jaberi wrote: >>> Hi, >>> >>> I am running FreeBSD Current (201010) as guest in VirtualBox on an >>> Ubuntu 10.04. FreeBSD is compiled with VIMAGE option. >>> >>> I loaded a module (my own) that calls if_alloc(IFT_IEEE80211), but I >>> get a panic: >> >> Did you compile your module with VIMAGE enabled? > > How do I check that? My makefile is: > > # Note: It is important to make sure you include the > makefile after declaring the KMOD and SRCS variables. > .PATH: ${.CURDIR}/wtap_hal > > # Declare Name of kernel module > KMOD = wtap > > # Enumerate Source files for kernel module > SRCS = if_wtap_module.c if_wtap.c if_medium.c hal.c > > # Include kernel module makefile > .include > >> >> -- >> John Baldwin >> > > Thnx Bjoern, I will check the mailing list Never mind; I was clearly not awake enough. The patch etc. is for virtualbox on a FreeBSD with VIMAGE. But people will be able to help you with your module there as well if it's related to a VIMAGE kernel. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 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 0CF4D106566C; Tue, 1 Feb 2011 18:30:29 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 3886B8FC0C; Tue, 1 Feb 2011 18:30:27 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p11IUP9t063264; Wed, 2 Feb 2011 00:30:25 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D48513C.40503@rdtc.ru> Date: Wed, 02 Feb 2011 00:30:20 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Julian Elischer References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> In-Reply-To: <4D4670C2.4050500@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: panic: bufwrite: buffer is not busy??? 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, 01 Feb 2011 18:30:29 -0000 On 31.01.2011 14:20, Julian Elischer wrote: > replace with: > > 3504 if ((hook == NULL) || > 3505 NG_HOOK_NOT_VALID(hook) || > ((peer = NG_HOOK_PEER(hook)) == NULL) || > 3506 NG_HOOK_NOT_VALID(peer) || > ((peernode = NG_PEER_NODE(hook)) == NULL) || > 3507 NG_NODE_NOT_VALID(peernode)) { > if (peer) > kassert((peernode != NULL), ("peer node NULL wile peer hook exists")); > 3508 NG_FREE_ITEM(item); This day I have updated panicing router to RELENG_8 and combined changes supposed by Julian and Gleb. After 8 hours it has just paniced again and could not finish to write crashdump again: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0x63 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803d4ccd stack pointer = 0x28:0xffffff80ebffc600 frame pointer = 0x28:0xffffff80ebffc680 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2390 (mpd5) trap number = 12 panic: page fault cpuid = 3 Uptime: 8h3m51s Dumping 4087 MB (3 chunks) chunk 0: 1MB (150 pages) ... ok chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? cpuid = 3 Uptime: 8h3m52s Automatic reboot in 15 seconds - press a key on the console to abort # gdb kernel GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... (gdb) l *0xffffffff803d4ccd 0xffffffff803d4ccd is in ng_pppoe_disconnect (netgraph.h:191). 186 int line); 187 188 static __inline void 189 _chkhook(hook_p hook, char *file, int line) 190 { 191 if (hook->hk_magic != HK_MAGIC) { 192 printf("Accessing freed hook "); 193 dumphook(hook, file, line); 194 } 195 hook->lastline = line; (gdb) x/i 0xffffffff803d4ccd 0xffffffff803d4ccd : cmpl $0x78573011,0x64(%rbx) Here is a patch I've applied to the tree: --- sys/netgraph/ng_base.c.orig 2011-02-01 12:34:09.000000000 +0600 +++ sys/netgraph/ng_base.c 2011-02-01 12:00:17.000000000 +0600 @@ -1643,10 +1643,8 @@ node_p *destp, hook_p *lasthook) { char fullpath[NG_PATHSIZ]; - char *nodename, *path, pbuf[2]; + char *nodename, *path; node_p node, oldnode; - char *cp; - hook_p hook = NULL; /* Initialize */ if (destp == NULL) { @@ -1664,11 +1662,6 @@ TRAP_ERROR(); return EINVAL; } - if (path == NULL) { - pbuf[0] = '.'; /* Needs to be writable */ - pbuf[1] = '\0'; - path = pbuf; - } /* * For an absolute address, jump to the starting node. @@ -1690,41 +1683,41 @@ NG_NODE_REF(node); } + if (path == NULL) { + if (lasthook != NULL) + *lasthook = NULL; + *destp = node; + return (0); + } + /* * Now follow the sequence of hooks - * XXX - * We actually cannot guarantee that the sequence - * is not being demolished as we crawl along it - * without extra-ordinary locking etc. - * So this is a bit dodgy to say the least. - * We can probably hold up some things by holding - * the nodelist mutex for the time of this - * crawl if we wanted.. At least that way we wouldn't have to - * worry about the nodes disappearing, but the hooks would still - * be a problem. + * + * XXXGL: The path may demolish as we go the sequence, but if + * we hold the topology mutex at critical places, then, I hope, + * we would always have valid pointers in hand, although the + * path behind us may no longer exist. */ - for (cp = path; node != NULL && *cp != '\0'; ) { + for (;;) { + hook_p hook; char *segment; /* * Break out the next path segment. Replace the dot we just - * found with a NUL; "cp" points to the next segment (or the + * found with a NUL; "path" points to the next segment (or the * NUL at the end). */ - for (segment = cp; *cp != '\0'; cp++) { - if (*cp == '.') { - *cp++ = '\0'; + for (segment = path; *path != '\0'; path++) { + if (*path == '.') { + *path++ = '\0'; break; } } - /* Empty segment */ - if (*segment == '\0') - continue; - /* We have a segment, so look for a hook by that name */ hook = ng_findhook(node, segment); + mtx_lock(&ng_topo_mtx); /* Can't get there from here... */ if (hook == NULL || NG_HOOK_PEER(hook) == NULL @@ -1732,15 +1725,7 @@ || NG_HOOK_NOT_VALID(NG_HOOK_PEER(hook))) { TRAP_ERROR(); NG_NODE_UNREF(node); -#if 0 - printf("hooknotvalid %s %s %d %d %d %d ", - path, - segment, - hook == NULL, - NG_HOOK_PEER(hook) == NULL, - NG_HOOK_NOT_VALID(hook), - NG_HOOK_NOT_VALID(NG_HOOK_PEER(hook))); -#endif + mtx_unlock(&ng_topo_mtx); return (ENOENT); } @@ -1757,21 +1742,25 @@ NG_NODE_UNREF(oldnode); /* XXX another race */ if (NG_NODE_NOT_VALID(node)) { NG_NODE_UNREF(node); /* XXX more races */ - node = NULL; + mtx_unlock(&ng_topo_mtx); + TRAP_ERROR(); + return (ENXIO); } - } - /* If node somehow missing, fail here (probably this is not needed) */ - if (node == NULL) { - TRAP_ERROR(); - return (ENXIO); + if (*path == '\0') { + if (lasthook != NULL) { + if (hook != NULL) { + *lasthook = NG_HOOK_PEER(hook); + NG_HOOK_REF(*lasthook); + } else + *lasthook = NULL; + } + mtx_unlock(&ng_topo_mtx); + *destp = node; + return (0); + } + mtx_unlock(&ng_topo_mtx); } - - /* Done */ - *destp = node; - if (lasthook != NULL) - *lasthook = (hook ? NG_HOOK_PEER(hook) : NULL); - return (0); } /***************************************************************\ @@ -3501,12 +3490,18 @@ * that the peer is still connected (even if invalid,) we know * that the peer node is present, though maybe invalid. */ + mtx_lock(&ng_topo_mtx); if ((hook == NULL) || NG_HOOK_NOT_VALID(hook) || - NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || - NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { + ((peer = NG_HOOK_PEER(hook)) == NULL) || + NG_HOOK_NOT_VALID(peer) || + ((peernode = NG_PEER_NODE(hook)) == NULL) || + NG_NODE_NOT_VALID(peernode)) { + if (peer) + KASSERT((peernode != NULL), ("peer node NULL while peer hook exists")); NG_FREE_ITEM(item); TRAP_ERROR(); + mtx_unlock(&ng_topo_mtx); return (ENETDOWN); } @@ -3518,6 +3513,9 @@ NGI_SET_HOOK(item, peer); NGI_SET_NODE(item, peernode); SET_RETADDR(item, here, retaddr); + + mtx_unlock(&ng_topo_mtx); + return (0); } @@ -3539,10 +3537,9 @@ return (error); } NGI_SET_NODE(item, dest); - if ( hook) { - NG_HOOK_REF(hook); /* don't let it go while on the queue */ + if (hook) NGI_SET_HOOK(item, hook); - } + SET_RETADDR(item, here, retaddr); return (0); } From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 18:36: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 D9BE01065673; Tue, 1 Feb 2011 18:36:59 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 2858A8FC13; Tue, 1 Feb 2011 18:36:58 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p11IavVS063298; Wed, 2 Feb 2011 00:36:57 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D4852C4.8040109@rdtc.ru> Date: Wed, 02 Feb 2011 00:36:52 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Julian Elischer References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> In-Reply-To: <4D48513C.40503@rdtc.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: panic: bufwrite: buffer is not busy??? 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, 01 Feb 2011 18:36:59 -0000 On 02.02.2011 00:30, Eugene Grosbein wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 06 > fault virtual address = 0x63 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff803d4ccd > stack pointer = 0x28:0xffffff80ebffc600 > frame pointer = 0x28:0xffffff80ebffc680 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2390 (mpd5) > trap number = 12 > panic: page fault > cpuid = 3 > Uptime: 8h3m51s > Dumping 4087 MB (3 chunks) > chunk 0: 1MB (150 pages) ... ok > chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? > cpuid = 3 > Uptime: 8h3m52s > Automatic reboot in 15 seconds - press a key on the console to abort > > # gdb kernel > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > (gdb) l *0xffffffff803d4ccd > 0xffffffff803d4ccd is in ng_pppoe_disconnect (netgraph.h:191). > 186 int line); > 187 > 188 static __inline void > 189 _chkhook(hook_p hook, char *file, int line) > 190 { > 191 if (hook->hk_magic != HK_MAGIC) { > 192 printf("Accessing freed hook "); > 193 dumphook(hook, file, line); > 194 } > 195 hook->lastline = line; > (gdb) x/i 0xffffffff803d4ccd > 0xffffffff803d4ccd : cmpl $0x78573011,0x64(%rbx) Forgot to mention, this time kernel has options NETGRAPH_DEBUG. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 18:50: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 CCAB8106564A; Tue, 1 Feb 2011 18:50:28 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB2B8FC1A; Tue, 1 Feb 2011 18:50:27 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p11IoQh0030398; Tue, 1 Feb 2011 21:50:26 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p11IoQbj030397; Tue, 1 Feb 2011 21:50:26 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 1 Feb 2011 21:50:26 +0300 From: Gleb Smirnoff To: Eugene Grosbein Message-ID: <20110201185026.GB62007@glebius.int.ru> References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4D48513C.40503@rdtc.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Julian Elischer , John Baldwin Subject: Re: panic: bufwrite: buffer is not busy??? 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, 01 Feb 2011 18:50:29 -0000 On Wed, Feb 02, 2011 at 12:30:20AM +0600, Eugene Grosbein wrote: E> On 31.01.2011 14:20, Julian Elischer wrote: E> E> > replace with: E> > E> > 3504 if ((hook == NULL) || E> > 3505 NG_HOOK_NOT_VALID(hook) || E> > ((peer = NG_HOOK_PEER(hook)) == NULL) || E> > 3506 NG_HOOK_NOT_VALID(peer) || E> > ((peernode = NG_PEER_NODE(hook)) == NULL) || E> > 3507 NG_NODE_NOT_VALID(peernode)) { E> > if (peer) E> > kassert((peernode != NULL), ("peer node NULL wile peer hook exists")); E> > 3508 NG_FREE_ITEM(item); E> E> This day I have updated panicing router to RELENG_8 and combined changes supposed E> by Julian and Gleb. After 8 hours it has just paniced again and could not finish E> to write crashdump again: E> E> Fatal trap 12: page fault while in kernel mode E> cpuid = 3; apic id = 06 E> fault virtual address = 0x63 E> fault code = supervisor read data, page not present E> instruction pointer = 0x20:0xffffffff803d4ccd E> stack pointer = 0x28:0xffffff80ebffc600 E> frame pointer = 0x28:0xffffff80ebffc680 E> code segment = base 0x0, limit 0xfffff, type 0x1b E> = DPL 0, pres 1, long 1, def32 0, gran 1 E> processor eflags = interrupt enabled, resume, IOPL = 0 E> current process = 2390 (mpd5) E> trap number = 12 E> panic: page fault E> cpuid = 3 E> Uptime: 8h3m51s E> Dumping 4087 MB (3 chunks) E> chunk 0: 1MB (150 pages) ... ok E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? E> cpuid = 3 E> Uptime: 8h3m52s E> Automatic reboot in 15 seconds - press a key on the console to abort E> E> # gdb kernel E> GNU gdb 6.1.1 [FreeBSD] E> Copyright 2004 Free Software Foundation, Inc. E> GDB is free software, covered by the GNU General Public License, and you are E> welcome to change it and/or distribute copies of it under certain conditions. E> Type "show copying" to see the conditions. E> There is absolutely no warranty for GDB. Type "show warranty" for details. E> This GDB was configured as "amd64-marcel-freebsd"... E> (gdb) l *0xffffffff803d4ccd E> 0xffffffff803d4ccd is in ng_pppoe_disconnect (netgraph.h:191). E> 186 int line); E> 187 E> 188 static __inline void E> 189 _chkhook(hook_p hook, char *file, int line) E> 190 { E> 191 if (hook->hk_magic != HK_MAGIC) { E> 192 printf("Accessing freed hook "); E> 193 dumphook(hook, file, line); E> 194 } E> 195 hook->lastline = line; E> (gdb) x/i 0xffffffff803d4ccd E> 0xffffffff803d4ccd : cmpl $0x78573011,0x64(%rbx) This looks like ng_pppoe_disconnect() was called with NULL argument. Can you add KDB_TRACE option to kernel? Your boxes for some reason can't dump core, but with this option we will have at least trace. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 18:53:00 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 42B9C1065670; Tue, 1 Feb 2011 18:53:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 031648FC17; Tue, 1 Feb 2011 18:53:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A25BE46B32; Tue, 1 Feb 2011 13:52:59 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 788238A01D; Tue, 1 Feb 2011 13:52:58 -0500 (EST) From: John Baldwin To: Eugene Grosbein Date: Tue, 1 Feb 2011 13:51:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D3011DB.9050900@frasunek.com> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> In-Reply-To: <4D48513C.40503@rdtc.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102011351.40544.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Feb 2011 13:52:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-net@freebsd.org Subject: Re: panic: bufwrite: buffer is not busy??? 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, 01 Feb 2011 18:53:00 -0000 On Tuesday, February 01, 2011 1:30:20 pm Eugene Grosbein wrote: > On 31.01.2011 14:20, Julian Elischer wrote: > > > replace with: > > > > 3504 if ((hook == NULL) || > > 3505 NG_HOOK_NOT_VALID(hook) || > > ((peer = NG_HOOK_PEER(hook)) == NULL) || > > 3506 NG_HOOK_NOT_VALID(peer) || > > ((peernode = NG_PEER_NODE(hook)) == NULL) || > > 3507 NG_NODE_NOT_VALID(peernode)) { > > if (peer) > > kassert((peernode != NULL), ("peer node NULL wile peer hook exists")); > > 3508 NG_FREE_ITEM(item); > > This day I have updated panicing router to RELENG_8 and combined changes supposed > by Julian and Gleb. After 8 hours it has just paniced again and could not finish > to write crashdump again: > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 06 > fault virtual address = 0x63 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff803d4ccd > stack pointer = 0x28:0xffffff80ebffc600 > frame pointer = 0x28:0xffffff80ebffc680 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2390 (mpd5) > trap number = 12 > panic: page fault > cpuid = 3 > Uptime: 8h3m51s > Dumping 4087 MB (3 chunks) > chunk 0: 1MB (150 pages) ... ok > chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? > cpuid = 3 > Uptime: 8h3m52s > Automatic reboot in 15 seconds - press a key on the console to abort > > # gdb kernel > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > (gdb) l *0xffffffff803d4ccd > 0xffffffff803d4ccd is in ng_pppoe_disconnect (netgraph.h:191). > 186 int line); > 187 > 188 static __inline void > 189 _chkhook(hook_p hook, char *file, int line) > 190 { > 191 if (hook->hk_magic != HK_MAGIC) { > 192 printf("Accessing freed hook "); > 193 dumphook(hook, file, line); > 194 } > 195 hook->lastline = line; > (gdb) x/i 0xffffffff803d4ccd > 0xffffffff803d4ccd : cmpl $0x78573011,0x64(%rbx) So %rbx (hook) was -1 here. Perhaps the locking is insufficient for whatever structure contains the hook pointer? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 18: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 0D36E106567A; Tue, 1 Feb 2011 18:57:13 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1558FC18; Tue, 1 Feb 2011 18:57:11 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p11IvAWp063382; Wed, 2 Feb 2011 00:57:10 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D485781.40905@rdtc.ru> Date: Wed, 02 Feb 2011 00:57:05 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gleb Smirnoff References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> <20110201185026.GB62007@glebius.int.ru> In-Reply-To: <20110201185026.GB62007@glebius.int.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: panic: bufwrite: buffer is not busy??? 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, 01 Feb 2011 18:57:13 -0000 On 02.02.2011 00:50, Gleb Smirnoff wrote: > This looks like ng_pppoe_disconnect() was called with NULL argument. > > Can you add KDB_TRACE option to kernel? Your boxes for some reason can't > dump core, but with this option we will have at least trace. Of course. I was pretty sure I have this option but it's commented out :-( Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 19:56: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 66E231065679; Tue, 1 Feb 2011 19:56:49 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9D68FC25; Tue, 1 Feb 2011 19:56:48 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p11JuU9U033130; Tue, 1 Feb 2011 11:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1296590191; bh=WHTIhaRlpqT+nb1zqSWBS5Ncmjpc1u9WWJt7kbZTzPI=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version; b=Pv+2IW3l353HQgSgworStVGfSSe3jo/PzzmLvlbVBVRTwujGVkYbw+1H0bGbAWq/H JaXXR7JfsEWOlBBjNN4zKsUoUNSFkE8IuH7ZQ1/e44SiqZkKiz8WOHHYOjm3Ti/jdt dJiXhmpkDJOhGSZfSBk9nAWd0K2CFbtezFLkln1g= From: Sean Bruno To: Mike Tancsa In-Reply-To: <4D42EA74.4090807@sentex.net> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> Content-Type: multipart/mixed; boundary="=-jFCXdpagJIiUUJVyJJjK" Date: Tue, 01 Feb 2011 11:56:30 -0800 Message-ID: <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Cc: "freebsd-net@freebsd.org" , Ivan Voras , Jack Vogel , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 19:56:49 -0000 --=-jFCXdpagJIiUUJVyJJjK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: > On 1/23/2011 10:21 AM, Mike Tancsa wrote: > > On 1/21/2011 4:21 AM, Jan Koum wrote: > > One other thing I noticed is that when the nic is in its hung state, the > > WOL option is gone ? > > > > e.g > > > > em1: flags=8843 metric 0 mtu 1500 > > options=19b > > ether 00:15:17:ed:68:a4 > > > > vs > > > > > > em1: flags=8843 metric 0 mtu 1500 > > > > options=219b > > ether 00:15:17:ed:68:a4 > > > Another hang last night :( > > Whats really strange is that the WOL_MAGIC and TSO4 got turned back on > somehow ? I had explicitly turned it off, but when the NIC was in its > bad state > > em1: flags=8843 metric 0 mtu 1500 > options=2198 > > ... its back on along with TSO? Not sure if its coincidence or a side > effect or what. For now, I have had to re-purpose this nic to something > else. > > debug info shows > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625 > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903 > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024 > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0 > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0 > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904 > Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN > Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP > > > ---Mike I'm trying to get some more testing done regarding my suggestions around the OACTIVE assertions in the driver. More or less, it looks like intense periods of activity can push the driver into the OACTIVE hold off state and the logic isn't quite right in igb(4) or em(4) to handle it. I suspect that something like this modification to igb(4) may be required for em(4). Comments? Sean --=-jFCXdpagJIiUUJVyJJjK Content-Disposition: attachment; filename="if_igb.diff_oactive" Content-Type: text/x-patch; name="if_igb.diff_oactive"; charset="UTF-8" Content-Transfer-Encoding: 7bit --- p4/freebsd_7/src/sys/dev/e1000/if_igb.c 2010-12-23 11:06:17.127417000 -0800 +++ p4/ybsd_7/src/sys/dev/e1000/if_igb.c 2010-12-23 11:28:50.476993000 -0800 @@ -784,10 +784,14 @@ return; /* Call cleanup if number of TX descriptors low */ +#if 0 if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD) igb_txeof(txr); +#endif while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { + if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD) + igb_txeof(txr); if (txr->tx_avail <= IGB_TX_OP_THRESHOLD) { ifp->if_drv_flags |= IFF_DRV_OACTIVE; break; @@ -1162,10 +1166,10 @@ IGB_TX_LOCK(txr); if (igb_txeof(txr)) more = TRUE; - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - igb_start_locked(txr, ifp); + /*if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) Pointless as igb_start_locked() checks this right off the bat*/ + igb_start_locked(txr, ifp); IGB_TX_UNLOCK(txr); - if (more) { + if (more || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { taskqueue_enqueue(que->tq, &que->que_task); return; } @@ -1361,7 +1370,7 @@ no_calc: /* Schedule a clean task if needed*/ - if (more_tx || more_rx) + if (more_tx || more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) taskqueue_enqueue(que->tq, &que->que_task); else /* Reenable this interrupt */ @@ -1535,6 +1545,14 @@ if (m_head->m_flags & M_VLANTAG) cmd_type_len |= E1000_ADVTXD_DCMD_VLE; +/* + * We just did this in before invocation, seems completely + * redundant, igb_handle_queue -> igb_txeof + * Pretty sure this is impossible as we check for the + * IGB_TX_CLEANUP_THRESHOLD in igb_start_locked() which happens + * before this func in invoked + */ +#if 0 /* * Force a cleanup if number of TX descriptors * available hits the threshold @@ -1547,6 +1565,7 @@ return (ENOBUFS); } } +#endif /* * Map the packet for DMA. --=-jFCXdpagJIiUUJVyJJjK-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 20:05: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 BD4FF106564A for ; Tue, 1 Feb 2011 20:05:40 +0000 (UTC) (envelope-from jfvogel@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 6F6B08FC22 for ; Tue, 1 Feb 2011 20:05:40 +0000 (UTC) Received: by gxk8 with SMTP id 8so2836045gxk.13 for ; Tue, 01 Feb 2011 12:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4HFspTDwSJ3xMCFYSOujGvVxy9RrJ7hCM1PkEgP0WJc=; b=FFAg+hBfJXcC8Fm+SsTdpQ7GapZCoFotOtakoGI6ozEMh3AMVpQGUH1LF3RdJ3uPa+ myY1qRDxTtNL5KsETO7IS2yrFDVZRA5JfZPDEnDFk613lvcZU+DrwI9vcxVPTyJc5wy3 S9dBQ07CEnqiNo3QCgXkKKYYMGVjxILnw18FU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NGGx1LtJHmZvU4nDL7nwu96sw8x+kzDJCmSVjGJbpXHUtUR2Xh087VOVPXoA+0wo2v 3AmV2m2ax8XW7hN33XS/QWtESlJdyrAIoMYty6n2VIUa9R8EnYXPsxaNHZbUmk7Wi4HH vW5PQbVcowdvGgM/vnTc7cz4ntjOBHDEEaPzQ= MIME-Version: 1.0 Received: by 10.100.48.14 with SMTP id v14mr2973436anv.4.1296590739248; Tue, 01 Feb 2011 12:05:39 -0800 (PST) Received: by 10.147.171.17 with HTTP; Tue, 1 Feb 2011 12:05:39 -0800 (PST) In-Reply-To: <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> Date: Tue, 1 Feb 2011 12:05:39 -0800 Message-ID: From: Jack Vogel To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Ivan Voras , Jan Koum , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 20:05:40 -0000 At this point I'm open to any ideas, this sounds like a good one Sean, thanks. Mike, you want to test this ? Jack On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno wrote: > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: > > > On 1/21/2011 4:21 AM, Jan Koum wrote: > > > One other thing I noticed is that when the nic is in its hung state, > the > > > WOL option is gone ? > > > > > > e.g > > > > > > em1: flags=8843 metric 0 mtu > 1500 > > > > options=19b > > > ether 00:15:17:ed:68:a4 > > > > > > vs > > > > > > > > > em1: flags=8843 metric 0 mtu > 1500 > > > > > > > options=219b > > > ether 00:15:17:ed:68:a4 > > > > > > Another hang last night :( > > > > Whats really strange is that the WOL_MAGIC and TSO4 got turned back on > > somehow ? I had explicitly turned it off, but when the NIC was in its > > bad state > > > > em1: flags=8843 metric 0 mtu 1500 > > options=2198 > > > > ... its back on along with TSO? Not sure if its coincidence or a side > > effect or what. For now, I have had to re-purpose this nic to something > > else. > > > > debug info shows > > > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625 > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904 > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP > > > > > > ---Mike > > > I'm trying to get some more testing done regarding my suggestions around > the OACTIVE assertions in the driver. More or less, it looks like > intense periods of activity can push the driver into the OACTIVE hold > off state and the logic isn't quite right in igb(4) or em(4) to handle > it. > > I suspect that something like this modification to igb(4) may be > required for em(4). > > Comments? > > Sean > From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 20:15:22 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 30F4B106566B; Tue, 1 Feb 2011 20:15:22 +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 D4FB48FC12; Tue, 1 Feb 2011 20:15:21 +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.4/8.14.4) with ESMTP id p11KFIY8078660 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 15:15:19 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D4869D1.1010709@sentex.net> Date: Tue, 01 Feb 2011 15:15:13 -0500 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: Jack Vogel References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> 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.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 20:15:22 -0000 On 2/1/2011 3:05 PM, Jack Vogel wrote: > At this point I'm open to any ideas, this sounds like a good one Sean, > thanks. > Mike, you want to test this ? Sure, I am feeling lucky ;-) If someone generates the appropriate em diffs for me, I will apply on the box that sees this issue the most. ---Mike > > Jack > > > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno wrote: > >> On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: >>> On 1/23/2011 10:21 AM, Mike Tancsa wrote: >>>> On 1/21/2011 4:21 AM, Jan Koum wrote: >>>> One other thing I noticed is that when the nic is in its hung state, >> the >>>> WOL option is gone ? >>>> >>>> e.g >>>> >>>> em1: flags=8843 metric 0 mtu >> 1500 >>>> >> options=19b >>>> ether 00:15:17:ed:68:a4 >>>> >>>> vs >>>> >>>> >>>> em1: flags=8843 metric 0 mtu >> 1500 >>>> >>>> >> options=219b >>>> ether 00:15:17:ed:68:a4 >>> >>> >>> Another hang last night :( >>> >>> Whats really strange is that the WOL_MAGIC and TSO4 got turned back on >>> somehow ? I had explicitly turned it off, but when the NIC was in its >>> bad state >>> >>> em1: flags=8843 metric 0 mtu 1500 >>> options=2198 >>> >>> ... its back on along with TSO? Not sure if its coincidence or a side >>> effect or what. For now, I have had to re-purpose this nic to something >>> else. >>> >>> debug info shows >>> >>> Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE >>> Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625 >>> Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903 >>> Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 >>> Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024 >>> Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0 >>> Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0 >>> Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 >>> Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904 >>> Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN >>> Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP >>> >>> >>> ---Mike >> >> >> I'm trying to get some more testing done regarding my suggestions around >> the OACTIVE assertions in the driver. More or less, it looks like >> intense periods of activity can push the driver into the OACTIVE hold >> off state and the logic isn't quite right in igb(4) or em(4) to handle >> it. >> >> I suspect that something like this modification to igb(4) may be >> required for em(4). >> >> Comments? >> >> Sean >> > -- ------------------- 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 Tue Feb 1 20:20: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 822ED106564A; Tue, 1 Feb 2011 20:20:52 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 459588FC12; Tue, 1 Feb 2011 20:20:51 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p11KJPa8040694; Tue, 1 Feb 2011 12:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1296591566; bh=gz56gpIBkyRvWf/OxNDQ2mfB91/S+vlsI4QkXNZ8ikY=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=isQUmCffUaIfh6l9jpa5mAW+zoyAyAUitxI66MQ8eKk37ldbi+m4TAOwhTO/DQfSL 9b0Ef/+CLfgp7e6++oUPvJQw8zk8B01bR5YBxkiKhnaqzaZFKTDlXv/h74bdXtlo16 f8oEo5juK93NzVxVAR5zREMZVKcCWCmy2/QaX+NI= From: Sean Bruno To: Jack Vogel In-Reply-To: References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Feb 2011 12:19:25 -0800 Message-ID: <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Ivan Voras , Jan Koum , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 20:20:52 -0000 On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: > At this point I'm open to any ideas, this sounds like a good one Sean, > thanks. > Mike, you want to test this ? > > Jack > > > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno > wrote: > > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: > > > On 1/21/2011 4:21 AM, Jan Koum wrote: > > > One other thing I noticed is that when the nic is in its > hung state, the > > > WOL option is gone ? > > > > > > e.g > > > > > > em1: flags=8843 > metric 0 mtu 1500 > > > > options=19b > > > ether 00:15:17:ed:68:a4 > > > > > > vs > > > > > > > > > em1: flags=8843 > metric 0 mtu 1500 > > > > > > > options=219b > > > ether 00:15:17:ed:68:a4 > > > > > > Another hang last night :( > > > > Whats really strange is that the WOL_MAGIC and TSO4 got > turned back on > > somehow ? I had explicitly turned it off, but when the NIC > was in its > > bad state > > > > em1: flags=8843 > metric 0 mtu 1500 > > > options=2198 > > > > ... its back on along with TSO? Not sure if its coincidence > or a side > > effect or what. For now, I have had to re-purpose this nic > to something > > else. > > > > debug info shows > > > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and > INACTIVE > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = > 625 > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = > 903 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = > 1024 > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail > failure = 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = > 0 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = > 904 > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to > DOWN > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to > UP > > > > > > ---Mike > > > > I'm trying to get some more testing done regarding my > suggestions around > the OACTIVE assertions in the driver. More or less, it looks > like > intense periods of activity can push the driver into the > OACTIVE hold > off state and the logic isn't quite right in igb(4) or em(4) > to handle > it. > > I suspect that something like this modification to igb(4) may > be > required for em(4). > > Comments? > > Sean > Does the logic I've implemented look sane? Sean From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 20:37: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 367FF106564A; Tue, 1 Feb 2011 20:37:38 +0000 (UTC) (envelope-from jfvogel@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 B0FB38FC27; Tue, 1 Feb 2011 20:37:37 +0000 (UTC) Received: by gxk8 with SMTP id 8so2850127gxk.13 for ; Tue, 01 Feb 2011 12:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4tKv703wl7PQ0Zvg9ztljEJxNM/1/LCB04sy3mOrGlM=; b=ArQOsEVF2ZrvEeKF2SUfqqMm5oJIRDfDVsyau87AaLtyBoIgYjp+J7s6g255eSCTX8 ZV9u8iAHl1eHcJTr0NvWsz0U6mfxoAdiugk24Z00nkPz6+lXa5vl3zDVuKLgTfPQs+o9 vcQ/2waHxRXlTFmBLttEKVMaC4BsigpnTBNv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SUcGibnLdaY9a/xW2yMCdEqlAVT+LCTyc1ygusYHJNAal8OHtWrpMdBUNsBQglhm1U RGUoUrE2pr9wiOV+MprWy2ZeIcnyuc+r+2TlV/ltGaiadkIAf2Jf0Dl8nLfyquGwsOxM jtRE6RJA4IPCedNIihD5aSwztmo0qKCZbsZ6M= MIME-Version: 1.0 Received: by 10.91.54.29 with SMTP id g29mr9004138agk.46.1296592656885; Tue, 01 Feb 2011 12:37:36 -0800 (PST) Received: by 10.147.171.17 with HTTP; Tue, 1 Feb 2011 12:37:36 -0800 (PST) In-Reply-To: <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> Date: Tue, 1 Feb 2011 12:37:36 -0800 Message-ID: From: Jack Vogel To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Ivan Voras , Jan Koum , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 20:37:38 -0000 Looks good, except I don't like code #if 0'd out, I'll make an if_em.c to try and send it shortly. Jack On Tue, Feb 1, 2011 at 12:19 PM, Sean Bruno wrote: > On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: > > At this point I'm open to any ideas, this sounds like a good one Sean, > > thanks. > > Mike, you want to test this ? > > > > Jack > > > > > > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno > > wrote: > > > > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: > > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: > > > > On 1/21/2011 4:21 AM, Jan Koum wrote: > > > > One other thing I noticed is that when the nic is in its > > hung state, the > > > > WOL option is gone ? > > > > > > > > e.g > > > > > > > > em1: flags=8843 > > metric 0 mtu 1500 > > > > > > > options=19b > > > > ether 00:15:17:ed:68:a4 > > > > > > > > vs > > > > > > > > > > > > em1: flags=8843 > > metric 0 mtu 1500 > > > > > > > > > > > options=219b > > > > ether 00:15:17:ed:68:a4 > > > > > > > > > Another hang last night :( > > > > > > Whats really strange is that the WOL_MAGIC and TSO4 got > > turned back on > > > somehow ? I had explicitly turned it off, but when the NIC > > was in its > > > bad state > > > > > > em1: flags=8843 > > metric 0 mtu 1500 > > > > > options=2198 > > > > > > ... its back on along with TSO? Not sure if its coincidence > > or a side > > > effect or what. For now, I have had to re-purpose this nic > > to something > > > else. > > > > > > debug info shows > > > > > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and > > INACTIVE > > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = > > 625 > > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = > > 903 > > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 > > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = > > 1024 > > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail > > failure = 0 > > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = > > 0 > > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 > > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = > > 904 > > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to > > DOWN > > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to > > UP > > > > > > > > > ---Mike > > > > > > > > I'm trying to get some more testing done regarding my > > suggestions around > > the OACTIVE assertions in the driver. More or less, it looks > > like > > intense periods of activity can push the driver into the > > OACTIVE hold > > off state and the logic isn't quite right in igb(4) or em(4) > > to handle > > it. > > > > I suspect that something like this modification to igb(4) may > > be > > required for em(4). > > > > Comments? > > > > Sean > > > > > Does the logic I've implemented look sane? > > Sean > > From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 20:55: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 3556510656A5; Tue, 1 Feb 2011 20:55:16 +0000 (UTC) (envelope-from jfvogel@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 B03178FC17; Tue, 1 Feb 2011 20:55:15 +0000 (UTC) Received: by yxh35 with SMTP id 35so2830985yxh.13 for ; Tue, 01 Feb 2011 12:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oAGops7MoDv5bID3Yrt+NJoIzOya8mkoRBsMwPRph48=; b=YDvI+peJTwSu73wClxmjuUNalas2e4QAbFI96i7Pu7xuyVhl7fnif6nkfOC3upgGsi YJJ64VYAYy7HI211lVl37p6mAL/ZmO8dWDpAPWLFvH5r267GwVsM0YXNUiKNp/EoZ54A qFWfEFfnDnT4maAQh83+KRX9f5fMxd37KaCfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Dl8ODc21LjLSHp++3TyQE3wyTR7IKMAJq0LyBXMnRg0b+QG+vt6yudZ6hb819d8uX2 g0d9hJIQkMP3qapcnDhL9wjvL4AFRAETnZzCrX8yooFsevnBBE872gj6/w8dCUjLhYEF 5GWUQAH4Gz8fD67Fg2IYZ94cWYOoujQx9fkfk= MIME-Version: 1.0 Received: by 10.150.228.20 with SMTP id a20mr6519178ybh.22.1296593705719; Tue, 01 Feb 2011 12:55:05 -0800 (PST) Received: by 10.147.171.17 with HTTP; Tue, 1 Feb 2011 12:55:05 -0800 (PST) In-Reply-To: References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> Date: Tue, 1 Feb 2011 12:55:05 -0800 Message-ID: From: Jack Vogel To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Ivan Voras , Jan Koum , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 20:55:16 -0000 Mike, just to remind me, are you running these 82574 adapters with MSIX ? Jack On Tue, Feb 1, 2011 at 12:37 PM, Jack Vogel wrote: > Looks good, except I don't like code #if 0'd out, I'll make an if_em.c to > try and > send it shortly. > > Jack > > > > On Tue, Feb 1, 2011 at 12:19 PM, Sean Bruno wrote: > >> On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: >> > At this point I'm open to any ideas, this sounds like a good one Sean, >> > thanks. >> > Mike, you want to test this ? >> > >> > Jack >> > >> > >> > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno >> > wrote: >> > >> > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: >> > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: >> > > > On 1/21/2011 4:21 AM, Jan Koum wrote: >> > > > One other thing I noticed is that when the nic is in its >> > hung state, the >> > > > WOL option is gone ? >> > > > >> > > > e.g >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > >> options=19b >> > > > ether 00:15:17:ed:68:a4 >> > > > >> > > > vs >> > > > >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > > > >> > >> options=219b >> > > > ether 00:15:17:ed:68:a4 >> > > >> > > >> > > Another hang last night :( >> > > >> > > Whats really strange is that the WOL_MAGIC and TSO4 got >> > turned back on >> > > somehow ? I had explicitly turned it off, but when the NIC >> > was in its >> > > bad state >> > > >> > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > >> > options=2198 >> > > >> > > ... its back on along with TSO? Not sure if its coincidence >> > or a side >> > > effect or what. For now, I have had to re-purpose this nic >> > to something >> > > else. >> > > >> > > debug info shows >> > > >> > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and >> > INACTIVE >> > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = >> > 625 >> > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = >> > 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = >> > 1024 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail >> > failure = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = >> > 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = >> > 904 >> > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to >> > DOWN >> > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to >> > UP >> > > >> > > >> > > ---Mike >> > >> > >> > >> > I'm trying to get some more testing done regarding my >> > suggestions around >> > the OACTIVE assertions in the driver. More or less, it looks >> > like >> > intense periods of activity can push the driver into the >> > OACTIVE hold >> > off state and the logic isn't quite right in igb(4) or em(4) >> > to handle >> > it. >> > >> > I suspect that something like this modification to igb(4) may >> > be >> > required for em(4). >> > >> > Comments? >> > >> > Sean >> > >> >> >> Does the logic I've implemented look sane? >> >> Sean >> >> > From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 21:05: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 ADE3B106566C; Tue, 1 Feb 2011 21:05:38 +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 422E08FC14; Tue, 1 Feb 2011 21:05:38 +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.4/8.14.4) with ESMTP id p11L5aW3091854 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 16:05:36 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D48759A.1030704@sentex.net> Date: Tue, 01 Feb 2011 16:05:30 -0500 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: Jack Vogel References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> 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.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 21:05:38 -0000 On 2/1/2011 3:55 PM, Jack Vogel wrote: > Mike, just to remind me, are you running these 82574 adapters with MSIX ? Yes. Board is an Intel MB (S3420GPX). 8G RAM, AMD64. Kernel from a few days ago 0(backup3)# vmstat -i | grep em1 irq257: em1:rx 0 113712958 159 irq258: em1:tx 0 96623551 135 irq259: em1:link 488 0 0(backup3)# grep ^em1 /var/run/dmesg.boot em1: port 0x2000-0x201f mem 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci10 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:ed:68:a4 em1: link state changed to UP 0(backup3)# em1@pci0:10:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet 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 From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 21:17: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 F317210656A6; Tue, 1 Feb 2011 21:17:39 +0000 (UTC) (envelope-from jfvogel@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 792518FC23; Tue, 1 Feb 2011 21:17:39 +0000 (UTC) Received: by yxh35 with SMTP id 35so2840396yxh.13 for ; Tue, 01 Feb 2011 13:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kWVIaaS7Q4k0pys8ozovTVnC2K/xFc/vnEGe8D0FT64=; b=NAa3MuBDHsQN1asn6C7IgT7rsDAMDtXMWikyI9g8vWKVgJpzsdXnmRm1m85VEThRnG GSHgo9MeTCDnEjgCgNhSqK+bh07EjwcIzWRCQoJmx4U/T5FUo+ppwu5iSn3PhBpyPJDj 4Efz9clWokimb8hGqMHx8zCnaABHGgBl4yJaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gGBDcMNnsM92Ejci5ZSc7FuWpd6sijNQulzYYPQf57pDMy8GqvP1UIJG8AmPgp15YU kz7LbiANVy8N2sC4LTk0ZQrYnTo56PnJAH+cBEH8HGtL+kyGxyanfvaAjfx0Gwi9eYhf NgJi3n5sQUrgyhPZ8sTBeYJ1+jdl/WaOMeSAA= MIME-Version: 1.0 Received: by 10.236.95.140 with SMTP id p12mr16881104yhf.24.1296595058610; Tue, 01 Feb 2011 13:17:38 -0800 (PST) Received: by 10.147.171.17 with HTTP; Tue, 1 Feb 2011 13:17:38 -0800 (PST) In-Reply-To: <4D48759A.1030704@sentex.net> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <4D48759A.1030704@sentex.net> Date: Tue, 1 Feb 2011 13:17:38 -0800 Message-ID: From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 21:17:40 -0000 But you aren't defining EM_MULTIQUEUE are you? (its not on by default) Jack On Tue, Feb 1, 2011 at 1:05 PM, Mike Tancsa wrote: > On 2/1/2011 3:55 PM, Jack Vogel wrote: > > Mike, just to remind me, are you running these 82574 adapters with MSIX ? > > Yes. Board is an Intel MB (S3420GPX). 8G RAM, AMD64. Kernel from a few > days ago > > > 0(backup3)# vmstat -i | grep em1 > irq257: em1:rx 0 113712958 159 > irq258: em1:tx 0 96623551 135 > irq259: em1:link 488 0 > 0(backup3)# grep ^em1 /var/run/dmesg.boot > em1: port 0x2000-0x201f mem > 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci10 > em1: Using MSIX interrupts with 3 vectors > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: Ethernet address: 00:15:17:ed:68:a4 > em1: link state changed to UP > 0(backup3)# > em1@pci0:10:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > 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 > From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 21:19: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 A299E106566B for ; Tue, 1 Feb 2011 21:19:10 +0000 (UTC) (envelope-from carlson39@llnl.gov) Received: from smtp.llnl.gov (nspiron-3.llnl.gov [128.115.41.83]) by mx1.freebsd.org (Postfix) with ESMTP id 912D48FC18 for ; Tue, 1 Feb 2011 21:19:10 +0000 (UTC) X-Attachments: None Received: from bagua.llnl.gov (HELO [134.9.197.135]) ([134.9.197.135]) by smtp.llnl.gov with ESMTP; 01 Feb 2011 12:50:36 -0800 Message-ID: <4D48721A.5040906@llnl.gov> Date: Tue, 01 Feb 2011 12:50:34 -0800 From: Mike Carlson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: A flood of bacula traffic causes igb interface to go offline. 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, 01 Feb 2011 21:19:10 -0000 Hey net@, I have a FreeBSD 8.2-RC2 system running on a HP DL180 G6, using the onboard Intel controller, and it is our primary Bacula storage node and director node. We have 96 clients that are scheduled to run at 8:30pm. After about 9 - 10 minutes of activity (mrtg graphs show about 50-60MB/sec incoming traffic), the igb1 interface is no longer able to communicate with the Cisco switch. The interesting part is, the interface is still "up", there is nothing in the kernel message buffer, and nothing relevant in the log file (just syslogd and ldap errors because they cannot reach their respective network servers). The system only responds to the network until I either reboot, or run 'ifconfig igb1 down ; ifconfig igb1 up'. There is no firewall loaded/configured. Thankfully, I have a KVM over IP, so when this happens I can at least run script(1) and capture some useful information. ifconfig igb1 igb1: flags=8843 metric 0 mtu 1500 options=1bb ether 1c:c1:de:e9:fb:af inet 128.15.136.105 netmask 0xffffff00 broadcast 128.15.136.255 inet 128.15.136.108 netmask 0xffffff00 broadcast 128.15.136.255 inet 128.15.136.102 netmask 0xffffff00 broadcast 128.15.136.255 media: Ethernet autoselect (1000baseT ) status: active I can ping the internal IP (but I realize that is probably a useless test...) root@write /etc]> ping 128.15.136.105 PING 128.15.136.105 (128.15.136.105): 56 data bytes 64 bytes from 128.15.136.105: icmp_seq=0 ttl=64 time=0.024 ms 64 bytes from 128.15.136.105: icmp_seq=1 ttl=64 time=0.015 ms ^C --- 128.15.136.105 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.015/0.019/0.024/0.005 ms Attempting to ping the router: root@write /etc]> ping 128.15.136.254 PING 128.15.136.254 (128.15.136.254): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ^C --- 128.15.136.254 ping statistics --- 9 packets transmitted, 0 packets received, 100.0% packet loss The only thing that seems to solve this problem is to either reboot, or do an "ifconfig down/up": root@write /etc]> ifconfig igb1 down root@write /etc]> ifconfig igb1 root@write /etc]> ping 128.15.136.254 PING 128.15.136.254 (128.15.136.254): 56 data bytes 64 bytes from 128.15.136.254: icmp_seq=1 ttl=255 time=1.015 ms 64 bytes from 128.15.136.254: icmp_seq=2 ttl=255 time=0.217 ms 64 bytes from 128.15.136.254: icmp_seq=3 ttl=255 time=0.278 ms 64 bytes from 128.15.136.254: icmp_seq=4 ttl=255 time=0.238 ms ^C --- 128.15.136.254 ping statistics --- 5 packets transmitted, 4 packets received, 20.0% packet loss round-trip min/avg/max/stddev = 0.217/0.437/1.015/0.334 ms I was able to run tcpdump during all of this, and it *nothing* between the system and the switch until I run ifconfig igb1 down/up, and then you see the CDP and Tree Spanning traffic. The networking team here has told me there are no errors on the switch, or the port I am on, and they even moved me from one port to another, but this is still happening on a fairly regular basis now that I've added more backup clients. Is this a possible bug with my hardware and the intel driver? I have a pcap file and more system information that might provide a lot more information, but I don't want to send that out to a mailing list. From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 21:36: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 A99AC10656B4; Tue, 1 Feb 2011 21:36:35 +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 3B8608FC1B; Tue, 1 Feb 2011 21:36:35 +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.4/8.14.4) with ESMTP id p11LaWpK098399 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 16:36:33 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D487CDB.5080603@sentex.net> Date: Tue, 01 Feb 2011 16:36:27 -0500 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: Jack Vogel References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <4D48759A.1030704@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.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 21:36:35 -0000 On 2/1/2011 4:17 PM, Jack Vogel wrote: > But you aren't defining EM_MULTIQUEUE are you? (its not on by default) Nope. Everything is the default wrt to the em driver. Nothing odd in loader.conf 0(backup3)% grep -v ^# /boot/loader.conf ahci_load="YES" siis_load="YES" if_em_load="YES" coretemp_load="YES" comconsole_speed="115200" # Set the current serial console speed console="comconsole,vidconsole" # A comma separated list of console(s) aesni_load="YES" cryptodev_load="YES" ---Mike From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 21:51: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 BEFB21065695; Tue, 1 Feb 2011 21:51:44 +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 6CDF68FC22; Tue, 1 Feb 2011 21:51:44 +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.4/8.14.4) with ESMTP id p11LpgoD002574 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 16:51:42 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D488069.7050301@sentex.net> Date: Tue, 01 Feb 2011 16:51:37 -0500 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: Jack Vogel References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> 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.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 21:51:44 -0000 On 2/1/2011 4:43 PM, Jack Vogel wrote: > To those who are going to test, here is the if_em.c, based on head, with my > changes, I have to leave for the afternoon, and have not had a chance to > build > this, but it should work. I will check back in the later evening. > > Any blatant problems Sean, feel free to fix them :) My boxes are RELENG_7 and RELENG_8. Apart from manually hand editing those pesky sysctl changes out, is there a better way to generate RELENG_8 and 7 diffs ? ---Mike From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 22:04: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 8602E106566B; Tue, 1 Feb 2011 22:04:26 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 32CEF8FC0A; Tue, 1 Feb 2011 22:04:25 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p11M3lCl058130; Tue, 1 Feb 2011 14:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1296597828; bh=HVxtNRXvELUI7evCZkOlsk8CQ0yuVmL8huppodBysyg=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=rnViGl4M+4u35KP+ze0jSxjlCcgQI58VrkyPpMTIVc+BeSQUCDeh5CcZBFMSOEflJ 61JQDS0+MJnhLux3IHLfE5XrLJtYl4Lrw7LvI+ElyRuRm5kiGGYe1D3MoFSchqXGfn yAMa287rjySK5Q1LSnkhyJVQ02k1Tnr30yMXVkdg= From: Sean Bruno To: Jack Vogel In-Reply-To: References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Feb 2011 14:03:47 -0800 Message-ID: <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Ivan Voras , Jan Koum , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 22:04:26 -0000 On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote: > To those who are going to test, here is the if_em.c, based on head, > with my > changes, I have to leave for the afternoon, and have not had a chance > to build > this, but it should work. I will check back in the later evening. > > Any blatant problems Sean, feel free to fix them :) > > Jack > I suspect that line 1490 should be: if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { Sean From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 22:05: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 EA3581065672; Tue, 1 Feb 2011 22:05:29 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 9ACAB8FC14; Tue, 1 Feb 2011 22:05:29 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p11M4JN1058307; Tue, 1 Feb 2011 14:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1296597859; bh=UdVkIxLEp/gkE6I9jRmEju6KppgC4e4E7ac7KhzI1hI=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=J3ooGKGjpIZU4aQZBWyQVZHOXccJtAQ+JCF4Xb0FwZk27Rky12Icw1MldGUY6t6Oc zgrEtOWN0rmWz3d2ti+JHMKTGlnc1xuDq2QOVWf+53ivLw+nXqZicY3OvW2I9ESJDZ rFkXp8XyvBRsqbm3OZfk2YyCXmM1cBDVHS7AC4Xg= From: Sean Bruno To: Mike Tancsa In-Reply-To: <4D488069.7050301@sentex.net> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <4D488069.7050301@sentex.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Feb 2011 14:04:18 -0800 Message-ID: <1296597858.2326.13.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Ivan Voras , Jack Vogel , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 22:05:30 -0000 On Tue, 2011-02-01 at 13:51 -0800, Mike Tancsa wrote: > On 2/1/2011 4:43 PM, Jack Vogel wrote: > > To those who are going to test, here is the if_em.c, based on head, with my > > changes, I have to leave for the afternoon, and have not had a chance to > > build > > this, but it should work. I will check back in the later evening. > > > > Any blatant problems Sean, feel free to fix them :) > > My boxes are RELENG_7 and RELENG_8. Apart from manually hand editing > those pesky sysctl changes out, is there a better way to generate > RELENG_8 and 7 diffs ? > > ---Mike Not at the moment. sean From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 23: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 21E601065679 for ; Tue, 1 Feb 2011 23:29:45 +0000 (UTC) (envelope-from m.oe@x-trader.de) Received: from qhexrelay2.hosting.inetserver.de (fw1.hostedoffice.ag [81.20.90.82]) by mx1.freebsd.org (Postfix) with ESMTP id C14458FC08 for ; Tue, 1 Feb 2011 23:29:44 +0000 (UTC) Received: from qhexhub2.hosting.inetserver.de (unknown [10.20.10.21]) by qhexrelay2.hosting.inetserver.de (Postfix) with ESMTP id 790EC187131 for ; Wed, 2 Feb 2011 00:11:55 +0100 (CET) Received: from QHEXMBOX2.hosting.inetserver.de ([fe80:0000:0000:0000:d926:a88f:242.116.230.85]) by qhexhub2.hosting.inetserver.de ([10.20.10.225]) with mapi; Wed, 2 Feb 2011 00:11:55 +0100 From: Markus Oestreicher To: "freebsd-net@freebsd.org" Content-Class: urn:content-classes:message Date: Wed, 2 Feb 2011 00:11:54 +0100 Thread-Topic: Current state of FreeBSD routing Thread-Index: AcvCZWrHgdkn/dHOTpKLN29v55ELaQ== Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V8.2.176.0 acceptlanguage: de-DE, en-US MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Current state of FreeBSD routing 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, 01 Feb 2011 23:29:45 -0000 Hi there! After a few hours of reading list archives and source code I need some clarification on the current state of FreeBSD forwarding capabilities. Given the following setup: - Quad Core CPU - Intel 82576 NIC (igb) - 8.2-RELEASE - Router with BGP full table 1) Queues: Card and driver seem to have support for multiple TX/RX queues. How many cores will it use for RX / TX per NIC? 2) Fastforwarding vs multiple netisr: In the past (6.x) using fastforwarding=3D1 was the best option for dedicate= d routers. I found "multiple netisr" added to 8.0. Can that help with routing on multi= ple cores? Any experience from using it in production? 3) lagg: I found lagg(4) mostly mentioned on home user setups. Any experience with using lagg in high-pps environments? (>100k pps) Will lagg play nicely together with multiple netisr routing or fastforwardi= ng? How much overhead will it add versus a single connection? Thanks a lot Markus From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 01:13:18 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DAAF1065675 for ; Wed, 2 Feb 2011 01:13:18 +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 0B4278FC15 for ; Wed, 2 Feb 2011 01:13:17 +0000 (UTC) Received: (qmail 12837 invoked from network); 2 Feb 2011 00:41:56 -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 ; 2 Feb 2011 00:41:56 -0000 Message-ID: <4D48AFAC.6090309@freebsd.org> Date: Wed, 02 Feb 2011 02:13:16 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <201101311217.07073.jhb@freebsd.org> <4D477289.8040901@freebsd.org> <201102010829.24043.jhb@freebsd.org> <20110201171959.W43179@maildrop.int.zabbadoz.net> In-Reply-To: <20110201171959.W43179@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , John Baldwin , net@freebsd.org Subject: Re: Bogus KASSERT() in tcp_output()? 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, 02 Feb 2011 01:13:18 -0000 On 01.02.2011 18:37, Bjoern A. Zeeb wrote: > On Tue, 1 Feb 2011, John Baldwin wrote: > >> On Monday, January 31, 2011 9:40:09 pm Lawrence Stewart wrote: >>> On 02/01/11 04:17, John Baldwin wrote: >>>> Somewhat related fallout to the bug reported on security@ recently, I think >>>> this KASSERT() in tcp_output() is bogus: >>>> >>>> >>>> KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL), >>>> ("%s: mbuf chain shorter than expected", __func__)); >>>> >>>> Specifically, just a few lines earlier in tcp_output() we set the packet >>>> header length to just 'len + hdrlen': >>>> >>>> /* >>>> * Put TCP length in extended header, and then >>>> * checksum extended header and data. >>>> */ >>>> m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */ >>>> >>>> Also, the ipoptions are stored in a separate mbuf chain in the in pcb >>>> (inp_options) that is passed as a separate argument to ip_output(). Given >>>> that, I would think that m_length() should not reflect ipoptlen since it >>>> should not include IP options in that chain? >>>> >>> >>> There is some relevant prior discussion on src-committers@ for r212803 >>> between Andre and Bjoern. >> >> I still don't see where ipoptlen bytes are reserved in the mbuf chain. After >> this block where 'm' is allocated and initialized: >> >> /* >> * Grab a header mbuf, attaching a copy of data to >> * be transmitted, and initialize the header from >> * the template for sends on this connection. >> */ >> if (len) { >> ... >> m->m_len = hdrlen; >> ... >> if (len <= MHLEN - hdrlen - max_linkhdr) { >> ... >> m->m_len += len; >> } else { >> m->m_next = m_copy(mb, moff, (int)len); >> ... >> } >> ... >> } else { >> ... >> m->m_len = hdrlen; >> } >> >> The length of the mbuf chain headed by 'm' is clearly hdrlen + len. > > It is. > > >> At no point anywhere do we do any sort of m_prepend() or other operation to >> allocate space in the mbuf chain for the IP options. They are merged in in >> ip_output(). I think the only reason this KASSERT() isn't firing in HEAD is >> that IP options are rarely used? > > Right and probably reason why I also hit it with IPSec as result of > > 718 #ifdef IPSEC > 719 ipoptlen += ipsec_optlen; > 720 #endif > > which wasn't because of ipsec_optlen really, I had just stopping > looking too soon back last year. IPSEC and TCP is very sub-optimal at the moment. The size of the IPSEC header/ overhead is calculated per packet including a full lookup into the SADB. After the discussions at EuroBSDCon I attempted to solve that in a better way but didn't finish. Have to dig it up again. >> Is there an easy way to test a connection with IP options enabled with this >> KASSERT() enabled? > > Yes, see patch at [1], and using my modified KASSERT still I get... > which btw sounds wrong to me as well btw as I wouldn't expect ipoptlen > to be 4 here given the test case. Byte swap issue? > # ./tcpconnect client 127.0.0.1 12345 1 ipopt > > panic: tcp_output: mbuf chain shorter than expected: 0 + 60 + 4 - 0 != 60 > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x187 > tcp_output() at tcp_output+0x1d01 > tcp_usr_connect() at tcp_usr_connect+0x15f > soconnect() at soconnect+0x14f > kern_connect() at kern_connect+0x12e > connect() at connect+0x41 > syscallenter() at syscallenter+0x1cb > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xe2 > --- syscall (98, FreeBSD ELF64, connect), rip = 0x80072934c, rsp = 0x7fffffffe9d8, rbp = 0x3 --- > > /bz > > References: > > [1] http://people.freebsd.org/~bz/20110201-01-tcpconnect-ipopt.diff > From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 01:28: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 5B44D106566C; Wed, 2 Feb 2011 01:28:44 +0000 (UTC) (envelope-from chris@vorota.cabstand.com) Received: from vorota.cabstand.com (vorota.cabstand.com [174.36.194.55]) by mx1.freebsd.org (Postfix) with ESMTP id DE5648FC08; Wed, 2 Feb 2011 01:28:43 +0000 (UTC) Received: from vorota.cabstand.com (localhost [127.0.0.1]) by vorota.cabstand.com (8.14.4/8.14.4) with ESMTP id p120v1PL078127 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 16:57:01 -0800 (PST) (envelope-from chris@vorota.cabstand.com) Received: (from chris@localhost) by vorota.cabstand.com (8.14.4/8.14.4/Submit) id p120uuAe078126; Tue, 1 Feb 2011 16:56:56 -0800 (PST) (envelope-from chris) Date: Tue, 1 Feb 2011 16:56:56 -0800 From: Chris Peiffer To: Mike Tancsa Message-ID: <20110202005656.GB76219@cabstand.com> Mail-Followup-To: Mike Tancsa , Jack Vogel , "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" References: <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <4D488069.7050301@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D488069.7050301@sentex.net> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , Jan Koum , Jack Vogel , "freebsd-hardware@freebsd.org" , Sean Bruno , Ivan Voras Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 02 Feb 2011 01:28:44 -0000 On Tue, Feb 01, 2011 at 04:51:37PM -0500, Mike Tancsa wrote: > On 2/1/2011 4:43 PM, Jack Vogel wrote: > > To those who are going to test, here is the if_em.c, based on head, with my > > changes, I have to leave for the afternoon, and have not had a chance to > > build > > this, but it should work. I will check back in the later evening. > > Did this get sent to the list? I didn't get this quoted message and I can't find it in the archives. If someone could post the current revision of if_em.c that would be great; we are also very eager to test. Thanks. From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 01:28:49 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 386E5106573C for ; Wed, 2 Feb 2011 01:28:49 +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 3C4A38FC1A for ; Wed, 2 Feb 2011 01:28:47 +0000 (UTC) Received: (qmail 12802 invoked from network); 2 Feb 2011 00:30: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 ; 2 Feb 2011 00:30:45 -0000 Message-ID: <4D48AD0C.1020703@freebsd.org> Date: Wed, 02 Feb 2011 02:02:04 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <201101311217.07073.jhb@freebsd.org> <4D477289.8040901@freebsd.org> <201102010829.24043.jhb@freebsd.org> In-Reply-To: <201102010829.24043.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Lawrence Stewart , "Bjoern A. Zeeb" , net@freebsd.org Subject: Re: Bogus KASSERT() in tcp_output()? 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, 02 Feb 2011 01:28:49 -0000 On 01.02.2011 14:29, John Baldwin wrote: > On Monday, January 31, 2011 9:40:09 pm Lawrence Stewart wrote: >> On 02/01/11 04:17, John Baldwin wrote: >>> Somewhat related fallout to the bug reported on security@ recently, I think What was the bug reported to security@? >>> this KASSERT() in tcp_output() is bogus: >>> >>> KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL), >>> ("%s: mbuf chain shorter than expected", __func__)); >>> >>> Specifically, just a few lines earlier in tcp_output() we set the packet >>> header length to just 'len + hdrlen': Yes. ipoptlen should not be added in this comparison as the space for the ipoptions is not reserved in the header mbuf. The value of ipoptlen is used for earlier checks to make sure the overall packet length does not exceed 64K. >>> /* >>> * Put TCP length in extended header, and then >>> * checksum extended header and data. >>> */ >>> m->m_pkthdr.len = hdrlen + len; /* in6_cksum() need this */ >>> >>> Also, the ipoptions are stored in a separate mbuf chain in the in pcb >>> (inp_options) that is passed as a separate argument to ip_output(). Given >>> that, I would think that m_length() should not reflect ipoptlen since it >>> should not include IP options in that chain? Correct. >> There is some relevant prior discussion on src-committers@ for r212803 >> between Andre and Bjoern. I have a pile of other patches to TCP and other parts laying around. Many of them fixes for long standing PR's. After EuroBSDCon I got stalled and lost bit of interest because of a severe reviewer shortage (neither Lawrence, Qing or Björn responded with reviews to my requests due to severe time shortage on their part). I then got sidetracked with other work. > I still don't see where ipoptlen bytes are reserved in the mbuf chain. After > this block where 'm' is allocated and initialized: > > /* > * Grab a header mbuf, attaching a copy of data to > * be transmitted, and initialize the header from > * the template for sends on this connection. > */ > if (len) { > ... > m->m_len = hdrlen; > ... > if (len<= MHLEN - hdrlen - max_linkhdr) { > ... > m->m_len += len; > } else { > m->m_next = m_copy(mb, moff, (int)len); > ... > } > ... > } else { > ... > m->m_len = hdrlen; > } > > The length of the mbuf chain headed by 'm' is clearly hdrlen + len. > > At no point anywhere do we do any sort of m_prepend() or other operation to > allocate space in the mbuf chain for the IP options. They are merged in in > ip_output(). I think the only reason this KASSERT() isn't firing in HEAD is > that IP options are rarely used? Essentially non-existent on protocols other than ICMP (for ping). In most parts of the Internet IP options are filtered. They haven't been very useful except for record route perhaps. That's of very limited use though to being able to record only the eight most recent hops. > Is there an easy way to test a connection with IP options enabled with this > KASSERT() enabled? -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 01:44: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 0A5AD1065694; Wed, 2 Feb 2011 01:44:49 +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 B00678FC19; Wed, 2 Feb 2011 01:44:48 +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.4/8.14.4) with ESMTP id p121iiXn033159 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 20:44:44 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D48B706.2090305@sentex.net> Date: Tue, 01 Feb 2011 20:44:38 -0500 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: Jack Vogel , "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" References: <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <4D488069.7050301@sentex.net> <20110202005656.GB76219@cabstand.com> In-Reply-To: <20110202005656.GB76219@cabstand.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 02 Feb 2011 01:44:49 -0000 On 2/1/2011 7:56 PM, Chris Peiffer wrote: > > Did this get sent to the list? I didn't get this quoted message and I > can't find it in the archives. > > If someone could post the current revision of if_em.c that would be > great; we are also very eager to test. > Strange, it seems to be eaten/held by mailman ? I posted the file to http://www.tancsa.com/if_em.c % md5 if_em.c MD5 (if_em.c) = 0f2d48c7734496c2262f468cd1ab9117 % ident if_em.c if_em.c: $FreeBSD: src/sys/dev/e1000/if_em.c,v 1.68 2011/01/19 18:20:11 jfv Exp $ ---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 Wed Feb 2 02:14: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 DCBEB1065675; Wed, 2 Feb 2011 02:14:19 +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 8E0258FC12; Wed, 2 Feb 2011 02:14:19 +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.4/8.14.4) with ESMTP id p122EHt2036801 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 21:14:17 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D48BDF3.4000102@sentex.net> Date: Tue, 01 Feb 2011 21:14:11 -0500 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: Jack Vogel , "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" References: <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <4D488069.7050301@sentex.net> <20110202005656.GB76219@cabstand.com> <4D48B706.2090305@sentex.net> In-Reply-To: <4D48B706.2090305@sentex.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 02 Feb 2011 02:14:20 -0000 On 2/1/2011 8:44 PM, Mike Tancsa wrote: > > % md5 if_em.c > MD5 (if_em.c) = 0f2d48c7734496c2262f468cd1ab9117 Sorry, thats MD5 (if_em.c) = 9cede4ab0d833e0f97172ed715e2b4e3 ---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 Wed Feb 2 03:03: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 C728B106566B; Wed, 2 Feb 2011 03:03:24 +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 62BEE8FC15; Wed, 2 Feb 2011 03:03:24 +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.4/8.14.4) with ESMTP id p1233LO9042205 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 22:03:21 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D48C973.7080503@sentex.net> Date: Tue, 01 Feb 2011 22:03:15 -0500 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: Sean Bruno References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Ivan Voras , Jack Vogel , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 02 Feb 2011 03:03:24 -0000 On 2/1/2011 5:03 PM, Sean Bruno wrote: > On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote: >> To those who are going to test, here is the if_em.c, based on head, >> with my >> changes, I have to leave for the afternoon, and have not had a chance >> to build >> this, but it should work. I will check back in the later evening. >> >> Any blatant problems Sean, feel free to fix them :) >> >> Jack >> > > > I suspect that line 1490 should be: > if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { > I have hacked up a RELENG_8 version which I think is correct including the above change http://www.tancsa.com/if_em-8.c --- if_em.c.orig 2011-02-01 21:47:14.000000000 -0500 +++ if_em.c 2011-02-01 21:47:19.000000000 -0500 @@ -30,7 +30,7 @@ POSSIBILITY OF SUCH DAMAGE. ******************************************************************************/ -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53 jfv Exp $*/ +/*$FreeBSD$*/ #ifdef HAVE_KERNEL_OPTION_HEADERS #include "opt_device_polling.h" @@ -93,7 +93,7 @@ /********************************************************************* * Driver version: *********************************************************************/ -char em_driver_version[] = "7.1.9"; +char em_driver_version[] = "7.1.9-test"; /********************************************************************* * PCI Device ID Table @@ -927,11 +927,10 @@ if (!adapter->link_active) return; - /* Call cleanup if number of TX descriptors low */ - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) - em_txeof(txr); - while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { + /* First cleanup if TX descriptors low */ + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) + em_txeof(txr); if (txr->tx_avail < EM_MAX_SCATTER) { ifp->if_drv_flags |= IFF_DRV_OACTIVE; break; @@ -1411,8 +1410,7 @@ if (!drbr_empty(ifp, txr->br)) em_mq_start_locked(ifp, txr, NULL); #else - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - em_start_locked(ifp, txr); + em_start_locked(ifp, txr); #endif EM_TX_UNLOCK(txr); @@ -1475,11 +1473,10 @@ struct ifnet *ifp = adapter->ifp; struct tx_ring *txr = adapter->tx_rings; struct rx_ring *rxr = adapter->rx_rings; - bool more; - if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - more = em_rxeof(rxr, adapter->rx_process_limit, NULL); + bool more_rx; + more_rx = em_rxeof(rxr, adapter->rx_process_limit, NULL); EM_TX_LOCK(txr); em_txeof(txr); @@ -1487,12 +1484,10 @@ if (!drbr_empty(ifp, txr->br)) em_mq_start_locked(ifp, txr, NULL); #else - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - em_start_locked(ifp, txr); + em_start_locked(ifp, txr); #endif - em_txeof(txr); EM_TX_UNLOCK(txr); - if (more) { + if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { taskqueue_enqueue(adapter->tq, &adapter->que_task); return; } @@ -1604,7 +1599,6 @@ if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) em_start_locked(ifp, txr); #endif - em_txeof(txr); E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims); EM_TX_UNLOCK(txr); } @@ -3730,17 +3724,17 @@ txr->queue_status = EM_QUEUE_HUNG; /* - * If we have enough room, clear IFF_DRV_OACTIVE + * If we have a minimum free, clear IFF_DRV_OACTIVE * to tell the stack that it is OK to send packets. */ - if (txr->tx_avail > EM_TX_CLEANUP_THRESHOLD) { + if (txr->tx_avail > EM_MAX_SCATTER) ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; - /* Disable watchdog if all clean */ - if (txr->tx_avail == adapter->num_tx_desc) { - txr->queue_status = EM_QUEUE_IDLE; - return (FALSE); - } - } + + /* Disable watchdog if all clean */ + if (txr->tx_avail == adapter->num_tx_desc) { + txr->queue_status = EM_QUEUE_IDLE; + return (FALSE); + } return (TRUE); } @@ -5064,8 +5058,8 @@ char namebuf[QUEUE_NAME_LEN]; /* Driver Statistics */ - SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", - CTLFLAG_RD, &adapter->link_irq, 0, + SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", + CTLFLAG_RD, &adapter->link_irq,0, "Link MSIX IRQ Handled"); SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "mbuf_alloc_fail", CTLFLAG_RD, &adapter->mbuf_alloc_failed, @@ -5108,11 +5102,13 @@ queue_list = SYSCTL_CHILDREN(queue_node); SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_head", - CTLFLAG_RD, adapter, E1000_TDH(txr->me), + CTLFLAG_RD, adapter, + E1000_TDH(txr->me), em_sysctl_reg_handler, "IU", "Transmit Descriptor Head"); SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_tail", - CTLFLAG_RD, adapter, E1000_TDT(txr->me), + CTLFLAG_RD, adapter, + E1000_TDT(txr->me), em_sysctl_reg_handler, "IU", "Transmit Descriptor Tail"); SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "tx_irq", @@ -5123,11 +5119,13 @@ "Queue No Descriptor Available"); SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_head", - CTLFLAG_RD, adapter, E1000_RDH(rxr->me), + CTLFLAG_RD, adapter, + E1000_RDH(rxr->me), em_sysctl_reg_handler, "IU", "Receive Descriptor Head"); SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_tail", - CTLFLAG_RD, adapter, E1000_RDT(rxr->me), + CTLFLAG_RD, adapter, + E1000_RDT(rxr->me), em_sysctl_reg_handler, "IU", "Receive Descriptor Tail"); SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "rx_irq", @@ -5141,19 +5139,19 @@ CTLFLAG_RD, NULL, "Statistics"); stat_list = SYSCTL_CHILDREN(stat_node); - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", CTLFLAG_RD, &stats->ecol, "Excessive collisions"); - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", CTLFLAG_RD, &stats->scc, "Single collisions"); - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", CTLFLAG_RD, &stats->mcc, "Multiple collisions"); - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", CTLFLAG_RD, &stats->latecol, "Late collisions"); - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", CTLFLAG_RD, &stats->colc, "Collision Count"); SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "symbol_errors", @@ -5240,12 +5238,12 @@ SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "rx_frames_1024_1522", CTLFLAG_RD, &adapter->stats.prc1522, "1023-1522 byte frames received"); - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", CTLFLAG_RD, &adapter->stats.gorc, "Good Octets Received"); /* Packet Transmission Stats */ - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", CTLFLAG_RD, &adapter->stats.gotc, "Good Octets Transmitted"); SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "total_pkts_txd", -- ------------------- 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 Wed Feb 2 04:21:44 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 5CC4B1065670; Wed, 2 Feb 2011 04:21:44 +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 322428FC08; Wed, 2 Feb 2011 04:21:44 +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 p124LilU082641; Wed, 2 Feb 2011 04:21:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p124LifD082637; Wed, 2 Feb 2011 04:21:44 GMT (envelope-from linimon) Date: Wed, 2 Feb 2011 04:21:44 GMT Message-Id: <201102020421.p124LifD082637@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154443: [bridge] Kernel module bridgestp.ko missing after upgrade (if_bridge.ko depend on it) 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, 02 Feb 2011 04:21:44 -0000 Old Synopsis: Kernel module bridgestp.ko missing after upgrade (if_bridge.ko depend on it) New Synopsis: [bridge] Kernel module bridgestp.ko missing after upgrade (if_bridge.ko depend on it) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Feb 2 04:20:20 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154443 From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 21:43: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 0AD421065696; Tue, 1 Feb 2011 21:43:59 +0000 (UTC) (envelope-from jfvogel@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 2CFAB8FC17; Tue, 1 Feb 2011 21:43:58 +0000 (UTC) Received: by ywp6 with SMTP id 6so2857205ywp.13 for ; Tue, 01 Feb 2011 13:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0+Hq/tHMUWsidQ5/7U7H66rJj6c/S8697deFwQxCdUI=; b=TKfrQr3lptDQV8SAvqaOKn2Z4NPvvYjQAczIDB81V200ItKwksdbik7oK7TEN3DczY aLDIhpxQdlYLFoikDwQW+zw8DtYvjb7eFjJCIbBFkPiLIuRjgFbfYpldqaABXuxRt6kr xFqnyI9rGIDVVZcYl6mGAjSm8CdHFZdUoUpv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=k+Xp4qZI+MeSbUKZVh2o9TYhXhV0AJhhnVSEcxHScYUmVzrimf9yQRFGwn6c22TlGG a4DPumwrBIwx/qP9SXh3NvYkxpnAIjIbp/1/u96flnwub734FyPwAL9aamockwLU0BMa soKsZdh3dkNuKAr7+nQmMUoDGlvqi+t2LqpcQ= MIME-Version: 1.0 Received: by 10.151.8.9 with SMTP id l9mr10326940ybi.79.1296596637310; Tue, 01 Feb 2011 13:43:57 -0800 (PST) Received: by 10.147.171.17 with HTTP; Tue, 1 Feb 2011 13:43:57 -0800 (PST) In-Reply-To: References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> Date: Tue, 1 Feb 2011 13:43:57 -0800 Message-ID: From: Jack Vogel To: Sean Bruno Content-Type: multipart/mixed; boundary=000e0cd4038cfbdee9049b3f6d45 X-Mailman-Approved-At: Wed, 02 Feb 2011 04:36:07 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Ivan Voras , Jan Koum , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 01 Feb 2011 21:43:59 -0000 --000e0cd4038cfbdee9049b3f6d45 Content-Type: text/plain; charset=ISO-8859-1 To those who are going to test, here is the if_em.c, based on head, with my changes, I have to leave for the afternoon, and have not had a chance to build this, but it should work. I will check back in the later evening. Any blatant problems Sean, feel free to fix them :) Jack On Tue, Feb 1, 2011 at 12:37 PM, Jack Vogel wrote: > Looks good, except I don't like code #if 0'd out, I'll make an if_em.c to > try and > send it shortly. > > Jack > > > > On Tue, Feb 1, 2011 at 12:19 PM, Sean Bruno wrote: > >> On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: >> > At this point I'm open to any ideas, this sounds like a good one Sean, >> > thanks. >> > Mike, you want to test this ? >> > >> > Jack >> > >> > >> > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno >> > wrote: >> > >> > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: >> > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: >> > > > On 1/21/2011 4:21 AM, Jan Koum wrote: >> > > > One other thing I noticed is that when the nic is in its >> > hung state, the >> > > > WOL option is gone ? >> > > > >> > > > e.g >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > >> options=19b >> > > > ether 00:15:17:ed:68:a4 >> > > > >> > > > vs >> > > > >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > > > >> > >> options=219b >> > > > ether 00:15:17:ed:68:a4 >> > > >> > > >> > > Another hang last night :( >> > > >> > > Whats really strange is that the WOL_MAGIC and TSO4 got >> > turned back on >> > > somehow ? I had explicitly turned it off, but when the NIC >> > was in its >> > > bad state >> > > >> > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > >> > options=2198 >> > > >> > > ... its back on along with TSO? Not sure if its coincidence >> > or a side >> > > effect or what. For now, I have had to re-purpose this nic >> > to something >> > > else. >> > > >> > > debug info shows >> > > >> > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and >> > INACTIVE >> > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = >> > 625 >> > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = >> > 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = >> > 1024 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail >> > failure = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = >> > 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = >> > 904 >> > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to >> > DOWN >> > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to >> > UP >> > > >> > > >> > > ---Mike >> > >> > >> > >> > I'm trying to get some more testing done regarding my >> > suggestions around >> > the OACTIVE assertions in the driver. More or less, it looks >> > like >> > intense periods of activity can push the driver into the >> > OACTIVE hold >> > off state and the logic isn't quite right in igb(4) or em(4) >> > to handle >> > it. >> > >> > I suspect that something like this modification to igb(4) may >> > be >> > required for em(4). >> > >> > Comments? >> > >> > Sean >> > >> >> >> Does the logic I've implemented look sane? >> >> Sean >> >> > --000e0cd4038cfbdee9049b3f6d45-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 05: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 B5DBA1065672 for ; Wed, 2 Feb 2011 05:49:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6C64D8FC0C for ; Wed, 2 Feb 2011 05:49:29 +0000 (UTC) Received: by qyk36 with SMTP id 36so7344675qyk.13 for ; Tue, 01 Feb 2011 21:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3p8/eekBdiSUJkMeDZxD7pdoQ9pbjbG3hdmtWposglM=; b=nUNDT1rY3ZDyJSlzLAsjJiL3+lLf34oJ4d0HvfohRa4gpcuPRN7ToR3D2jSipSxwl6 6PKQ/5G5iC0jCYbt/SzZJXEaIUn0NTytHXEYHfn/1/xrfq3G+MOEg1y1c5qpbW7UVYQH xQDdBJmVRp8pcXFJeU2DJ+uTJkcSoHCuxdmzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cAMubKoze3b8oKqvsLwZTtGCAgxl15EZUnXta/rMVjhvDEWQPzdrS+Ix8wzanYKCq6 +Vu4jh76yfkUl2JjTgg2hlCeam5O/+SeGFIDnKVGt0jC7zzzKN91HjlgEYrfG5qkunEc VfImTLPJirtFFr3D0YG/gmZgpVBvKShaYKx/o= MIME-Version: 1.0 Received: by 10.229.89.208 with SMTP id f16mr6092155qcm.43.1296625769237; Tue, 01 Feb 2011 21:49:29 -0800 (PST) Received: by 10.229.102.87 with HTTP; Tue, 1 Feb 2011 21:49:29 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Feb 2011 08:49:29 +0300 Message-ID: From: Sergey Kandaurov To: Markus Oestreicher Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" Subject: Re: Current state of FreeBSD routing 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, 02 Feb 2011 05:49:30 -0000 On 2 February 2011 02:11, Markus Oestreicher wrote: > Hi there! > > After a few hours of reading list archives and source code I need some > clarification on the current state of FreeBSD forwarding capabilities. > > Given the following setup: > - Quad Core CPU > - Intel 82576 NIC (igb) > - 8.2-RELEASE > - Router with BGP full table > > 1) Queues: > Card and driver seem to have support for multiple TX/RX queues. > How many cores will it use for RX / TX per NIC? That depends on how many cpu cores you have. e.g. with several 82576 NICs installed I have 8 queues per each port. So it looks like # vmstat -ia | grep igb7 irq320: igb7:que 0 0 0 irq321: igb7:que 1 0 0 irq322: igb7:que 2 0 0 irq323: igb7:que 3 0 0 irq324: igb7:que 4 0 0 irq325: igb7:que 5 0 0 irq326: igb7:que 6 0 0 irq327: igb7:que 7 0 0 irq328: igb7:link 0 0 With Quad Core CPU you will have 4 queues. > > 2) Fastforwarding vs multiple netisr: > In the past (6.x) using fastforwarding=1 was the best option for dedicated routers. > I found "multiple netisr" added to 8.0. Can that help with routing on multiple cores? > Any experience from using it in production? > > 3) lagg: > I found lagg(4) mostly mentioned on home user setups. > Any experience with using lagg in high-pps environments? (>100k pps) > Will lagg play nicely together with multiple netisr routing or fastforwarding? > How much overhead will it add versus a single connection? > > Thanks a lot > > Markus -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 06:10: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 2CA7E1065670 for ; Wed, 2 Feb 2011 06:10:57 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 8BDD28FC14 for ; Wed, 2 Feb 2011 06:10:56 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p126ArqO067328; Wed, 2 Feb 2011 12:10:53 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D48F568.6020502@rdtc.ru> Date: Wed, 02 Feb 2011 12:10:48 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Markus Oestreicher References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: Current state of FreeBSD routing 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, 02 Feb 2011 06:10:57 -0000 On 02.02.2011 05:11, Markus Oestreicher wrote: > 2) Fastforwarding vs multiple netisr: > In the past (6.x) using fastforwarding=1 was the best option for dedicated routers. > I found "multiple netisr" added to 8.0. Can that help with routing on multiple cores? Yes, it allows more even distribution of input traffic processing over cores. > Any experience from using it in production? It helps greatly but I was forced to disable it for mpd-based router where there are many dynamically born/destroyed network interfaces. I suspect it increases possibility of kernel panic in such configuration due to famous 'dangling pointer' problem: an interface ngXXX got destroyed while packets received from it reside in netisr queues. Then kernel might panic while processing these packets if needs to check incoming interface, f.e. due to ipfw antispoofing rules. > 3) lagg: > I found lagg(4) mostly mentioned on home user setups. > Any experience with using lagg in high-pps environments? (>100k pps) Works fine for me. > Will lagg play nicely together with multiple netisr routing or fastforwarding? > How much overhead will it add versus a single connection? Unnoticed. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 07:11: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 CF12110656A4 for ; Wed, 2 Feb 2011 07:11:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9F6E48FC0C for ; Wed, 2 Feb 2011 07:11:30 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p127BOV0053263 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 23:11:29 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D49039F.8080804@freebsd.org> Date: Tue, 01 Feb 2011 23:11:27 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eugene Grosbein References: <4D48F568.6020502@rdtc.ru> In-Reply-To: <4D48F568.6020502@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: Current state of FreeBSD routing 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, 02 Feb 2011 07:11:30 -0000 On 2/1/11 10:10 PM, Eugene Grosbein wrote: > On 02.02.2011 05:11, Markus Oestreicher wrote: > >> 2) Fastforwarding vs multiple netisr: >> In the past (6.x) using fastforwarding=1 was the best option for dedicated routers. >> I found "multiple netisr" added to 8.0. Can that help with routing on multiple cores? > Yes, it allows more even distribution of input traffic processing over cores. > >> Any experience from using it in production? > It helps greatly but I was forced to disable it for mpd-based router > where there are many dynamically born/destroyed network interfaces. > > I suspect it increases possibility of kernel panic in such configuration > due to famous 'dangling pointer' problem: an interface ngXXX got destroyed > while packets received from it reside in netisr queues. Then kernel might > panic while processing these packets if needs to check incoming interface, > f.e. due to ipfw antispoofing rules. workaround for that may be to delay ng interface destruction by 2 seconds or something. I'll think about it.. >> 3) lagg: >> I found lagg(4) mostly mentioned on home user setups. >> Any experience with using lagg in high-pps environments? (>100k pps) > Works fine for me. > >> Will lagg play nicely together with multiple netisr routing or fastforwarding? >> How much overhead will it add versus a single connection? > Unnoticed. > > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 08:50: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 5A736106566C for ; Wed, 2 Feb 2011 08:50:16 +0000 (UTC) (envelope-from mike.barnardq@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 155BB8FC0A for ; Wed, 2 Feb 2011 08:50:15 +0000 (UTC) Received: by ywp6 with SMTP id 6so3043397ywp.13 for ; Wed, 02 Feb 2011 00:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3l8ukaLKg9djexEjBpDD2WviLP1hUrRjynzCt1iE+a0=; b=hJWNZ8fKkRU26OOcOuiLBwaGTOYvFVlUZ5L3kENsqpX3EDQ/AANL0gn8CuXY3BkIor yPJRHsMCxaxMWunQNvAtzACcswpQJhUy5xE/SwYDXyV6w4305MEOic7qiTXAjWzW9X4Y kVfq2jEy6I28Nsy2/QwP6EbVUadwPdpDXxGFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wo6YeghsjPpHMys0GaLSpZnWiwvVYMPpG6fLchXNH0DMUl7ZWDPmCtdkcVHUoz4Xzj ZBLPPX//gHIb245A/qbp7SpUTpXjVV8/YVtvDiSnvGjbMc+XDyCFYBKJpcW5KAlX8ZxV REOyyA2owLvhOiGkxtKL4bykuRitO2pu8ZKTo= MIME-Version: 1.0 Received: by 10.100.215.12 with SMTP id n12mr5601935ang.191.1296636615103; Wed, 02 Feb 2011 00:50:15 -0800 (PST) Received: by 10.100.116.7 with HTTP; Wed, 2 Feb 2011 00:50:15 -0800 (PST) In-Reply-To: <20110128173921.GY316@verio.net> References: <20110128173921.GY316@verio.net> Date: Wed, 2 Feb 2011 11:50:15 +0300 Message-ID: From: Mike Barnard To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: CARP Failover 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, 02 Feb 2011 08:50:16 -0000 sorry for the delay in responding. The two firewalls cannot hear each other's CARP announcements. Test > with tcpdump; do you see the CARP packets coming from the other > firewall? If not, you have a switching problem, like the two firewalls > are not in the same VLAN together. > > that there was the problem. The interfaces on the different nodes were not in the same vlan. -- Mike Of course, you might discount this possibility, but remember that one in a million chances happen 99% of the time. ------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 17:37: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 9DDD0106566C; Wed, 2 Feb 2011 17:37:32 +0000 (UTC) (envelope-from jfvogel@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 1F70E8FC19; Wed, 2 Feb 2011 17:37:31 +0000 (UTC) Received: by gxk8 with SMTP id 8so103994gxk.13 for ; Wed, 02 Feb 2011 09:37:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9uweL4xAiLTcxFrOXJoRZizf9PLx28n9lreb8OgzKNs=; b=yHtmzHfsLno+HL82TE8i5MA2eGN5L6wttkPg8eHIaRSOR+srx2Sc54vaRo3XYEbvhe DgfUFWW6OKcvBdea6JScqFSr7lawI0/pm8nfCiNMLMBpzL5rP4YrZMytjq9VDNv/NpDE Ds5M4C5M5SxqFoYU+6/+8zr+99J1L+5ihlqp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pm0njKnMABsp93DZHE8TP0Pr3MHFnwEuv6dNL79pi7bYzbOa+GiQVBqYzDqG756jIG zo3cq4RTALp5tgh5fD00FbUoWpHbx6mAMsNTzkrBhMT0TBVZOBaJFaECdFUtRHpuRa+n tPjkfjQw6a6Mu/oVcDv4BBadB8fcvLbsTwtfo= MIME-Version: 1.0 Received: by 10.90.80.15 with SMTP id d15mr807163agb.19.1296668250810; Wed, 02 Feb 2011 09:37:30 -0800 (PST) Received: by 10.147.171.17 with HTTP; Wed, 2 Feb 2011 09:37:30 -0800 (PST) In-Reply-To: <4D48C973.7080503@sentex.net> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> Date: Wed, 2 Feb 2011 09:37:30 -0800 Message-ID: From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 02 Feb 2011 17:37:32 -0000 So has everyone that wanted to get something testing been able to do so? Jack On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote: > On 2/1/2011 5:03 PM, Sean Bruno wrote: > > On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote: > >> To those who are going to test, here is the if_em.c, based on head, > >> with my > >> changes, I have to leave for the afternoon, and have not had a chance > >> to build > >> this, but it should work. I will check back in the later evening. > >> > >> Any blatant problems Sean, feel free to fix them :) > >> > >> Jack > >> > > > > > > I suspect that line 1490 should be: > > if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { > > > > > I have hacked up a RELENG_8 version which I think is correct including > the above change > > http://www.tancsa.com/if_em-8.c > > > > --- if_em.c.orig 2011-02-01 21:47:14.000000000 -0500 > +++ if_em.c 2011-02-01 21:47:19.000000000 -0500 > @@ -30,7 +30,7 @@ > POSSIBILITY OF SUCH DAMAGE. > > > ******************************************************************************/ > -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53 > jfv Exp $*/ > +/*$FreeBSD$*/ > > #ifdef HAVE_KERNEL_OPTION_HEADERS > #include "opt_device_polling.h" > @@ -93,7 +93,7 @@ > /********************************************************************* > * Driver version: > *********************************************************************/ > -char em_driver_version[] = "7.1.9"; > +char em_driver_version[] = "7.1.9-test"; > > /********************************************************************* > * PCI Device ID Table > @@ -927,11 +927,10 @@ > if (!adapter->link_active) > return; > > - /* Call cleanup if number of TX descriptors low */ > - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > - em_txeof(txr); > - > while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { > + /* First cleanup if TX descriptors low */ > + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > + em_txeof(txr); > if (txr->tx_avail < EM_MAX_SCATTER) { > ifp->if_drv_flags |= IFF_DRV_OACTIVE; > break; > @@ -1411,8 +1410,7 @@ > if (!drbr_empty(ifp, txr->br)) > em_mq_start_locked(ifp, txr, NULL); > #else > - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > - em_start_locked(ifp, txr); > + em_start_locked(ifp, txr); > #endif > EM_TX_UNLOCK(txr); > > @@ -1475,11 +1473,10 @@ > struct ifnet *ifp = adapter->ifp; > struct tx_ring *txr = adapter->tx_rings; > struct rx_ring *rxr = adapter->rx_rings; > - bool more; > - > > if (ifp->if_drv_flags & IFF_DRV_RUNNING) { > - more = em_rxeof(rxr, adapter->rx_process_limit, NULL); > + bool more_rx; > + more_rx = em_rxeof(rxr, adapter->rx_process_limit, NULL); > > EM_TX_LOCK(txr); > em_txeof(txr); > @@ -1487,12 +1484,10 @@ > if (!drbr_empty(ifp, txr->br)) > em_mq_start_locked(ifp, txr, NULL); > #else > - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > - em_start_locked(ifp, txr); > + em_start_locked(ifp, txr); > #endif > - em_txeof(txr); > EM_TX_UNLOCK(txr); > - if (more) { > + if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { > taskqueue_enqueue(adapter->tq, &adapter->que_task); > return; > } > @@ -1604,7 +1599,6 @@ > if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > em_start_locked(ifp, txr); > #endif > - em_txeof(txr); > E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims); > EM_TX_UNLOCK(txr); > } > @@ -3730,17 +3724,17 @@ > txr->queue_status = EM_QUEUE_HUNG; > > /* > - * If we have enough room, clear IFF_DRV_OACTIVE > + * If we have a minimum free, clear IFF_DRV_OACTIVE > * to tell the stack that it is OK to send packets. > */ > - if (txr->tx_avail > EM_TX_CLEANUP_THRESHOLD) { > + if (txr->tx_avail > EM_MAX_SCATTER) > ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; > - /* Disable watchdog if all clean */ > - if (txr->tx_avail == adapter->num_tx_desc) { > - txr->queue_status = EM_QUEUE_IDLE; > - return (FALSE); > - } > - } > + > + /* Disable watchdog if all clean */ > + if (txr->tx_avail == adapter->num_tx_desc) { > + txr->queue_status = EM_QUEUE_IDLE; > + return (FALSE); > + } > > return (TRUE); > } > @@ -5064,8 +5058,8 @@ > char namebuf[QUEUE_NAME_LEN]; > > /* Driver Statistics */ > - SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", > - CTLFLAG_RD, &adapter->link_irq, 0, > + SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", > + CTLFLAG_RD, &adapter->link_irq,0, > "Link MSIX IRQ Handled"); > SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "mbuf_alloc_fail", > CTLFLAG_RD, &adapter->mbuf_alloc_failed, > @@ -5108,11 +5102,13 @@ > queue_list = SYSCTL_CHILDREN(queue_node); > > SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_head", > - CTLFLAG_RD, adapter, E1000_TDH(txr->me), > + CTLFLAG_RD, adapter, > + E1000_TDH(txr->me), > em_sysctl_reg_handler, "IU", > "Transmit Descriptor Head"); > SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_tail", > - CTLFLAG_RD, adapter, E1000_TDT(txr->me), > + CTLFLAG_RD, adapter, > + E1000_TDT(txr->me), > em_sysctl_reg_handler, "IU", > "Transmit Descriptor Tail"); > SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "tx_irq", > @@ -5123,11 +5119,13 @@ > "Queue No Descriptor Available"); > > SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_head", > - CTLFLAG_RD, adapter, E1000_RDH(rxr->me), > + CTLFLAG_RD, adapter, > + E1000_RDH(rxr->me), > em_sysctl_reg_handler, "IU", > "Receive Descriptor Head"); > SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_tail", > - CTLFLAG_RD, adapter, E1000_RDT(rxr->me), > + CTLFLAG_RD, adapter, > + E1000_RDT(rxr->me), > em_sysctl_reg_handler, "IU", > "Receive Descriptor Tail"); > SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "rx_irq", > @@ -5141,19 +5139,19 @@ > CTLFLAG_RD, NULL, "Statistics"); > stat_list = SYSCTL_CHILDREN(stat_node); > > - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", > + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", > CTLFLAG_RD, &stats->ecol, > "Excessive collisions"); > - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", > + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", > CTLFLAG_RD, &stats->scc, > "Single collisions"); > - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", > + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", > CTLFLAG_RD, &stats->mcc, > "Multiple collisions"); > - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", > + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", > CTLFLAG_RD, &stats->latecol, > "Late collisions"); > - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", > + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", > CTLFLAG_RD, &stats->colc, > "Collision Count"); > SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "symbol_errors", > @@ -5240,12 +5238,12 @@ > SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "rx_frames_1024_1522", > CTLFLAG_RD, &adapter->stats.prc1522, > "1023-1522 byte frames received"); > - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", > + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", > CTLFLAG_RD, &adapter->stats.gorc, > "Good Octets Received"); > > /* Packet Transmission Stats */ > - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", > + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", > CTLFLAG_RD, &adapter->stats.gotc, > "Good Octets Transmitted"); > SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "total_pkts_txd", > > -- > ------------------- > 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 Wed Feb 2 18:07: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 1C872106564A for ; Wed, 2 Feb 2011 18:07:38 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id E40868FC08 for ; Wed, 2 Feb 2011 18:07:37 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p12I7EYa011192; Wed, 2 Feb 2011 10:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1296670034; bh=YXPFPkjW4DN7z1MsRc7EIdrVRUYIO4zBhOHr7HRSHjQ=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=vSJhyBjm8bDfA9tMU4lLIn76jm0LrCDXPcq5g7er9nR+AfdTf7EqWVxP1TNwSeVzz ixP4gX1MgJINIBS+qQrZW2eaux2aX386ALcPmiRwektDxPkNVE4dmnz1H7VZjXep8V Q6gBlA3wXHed3goIyA0p5LZmuMmu/Ij5Ggcne0no= From: Sean Bruno To: Mike Carlson In-Reply-To: <4D48721A.5040906@llnl.gov> References: <4D48721A.5040906@llnl.gov> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Feb 2011 10:07:13 -0800 Message-ID: <1296670033.2286.0.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: A flood of bacula traffic causes igb interface to go offline. 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, 02 Feb 2011 18:07:38 -0000 On Tue, 2011-02-01 at 12:50 -0800, Mike Carlson wrote: > Hey net@, > > I have a FreeBSD 8.2-RC2 system running on a HP DL180 G6, using the > onboard Intel controller, and it is our primary Bacula storage node and > director node. > > We have 96 clients that are scheduled to run at 8:30pm. After about 9 - > 10 minutes of activity (mrtg graphs show about 50-60MB/sec incoming > traffic), the igb1 interface is no longer able to communicate with the > Cisco switch. > > The interesting part is, the interface is still "up", there is nothing > in the kernel message buffer, and nothing relevant in the log file (just > syslogd and ldap errors because they cannot reach their respective > network servers). The system only responds to the network until I either > reboot, or run 'ifconfig igb1 down ; ifconfig igb1 up'. There is no > firewall loaded/configured. > > Thankfully, I have a KVM over IP, so when this happens I can at least > run script(1) and capture some useful information. > ifconfig igb1 > igb1: flags=8843 metric 0 mtu 1500 > > options=1bb > ether 1c:c1:de:e9:fb:af > inet 128.15.136.105 netmask 0xffffff00 broadcast 128.15.136.255 > inet 128.15.136.108 netmask 0xffffff00 broadcast 128.15.136.255 > inet 128.15.136.102 netmask 0xffffff00 broadcast 128.15.136.255 > media: Ethernet autoselect (1000baseT ) > status: active > > I can ping the internal IP (but I realize that is probably a useless > test...) > root@write /etc]> ping 128.15.136.105 > PING 128.15.136.105 (128.15.136.105): 56 data bytes > 64 bytes from 128.15.136.105: icmp_seq=0 ttl=64 time=0.024 ms > 64 bytes from 128.15.136.105: icmp_seq=1 ttl=64 time=0.015 ms > ^C > --- 128.15.136.105 ping statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.015/0.019/0.024/0.005 ms > > Attempting to ping the router: > root@write /etc]> ping 128.15.136.254 > PING 128.15.136.254 (128.15.136.254): 56 data bytes > ping: sendto: Host is down > ping: sendto: Host is down > ping: sendto: Host is down > ping: sendto: Host is down > ^C > --- 128.15.136.254 ping statistics --- > 9 packets transmitted, 0 packets received, 100.0% packet loss > > > The only thing that seems to solve this problem is to either reboot, or > do an "ifconfig down/up": > > root@write /etc]> ifconfig igb1 down > root@write /etc]> ifconfig igb1 > root@write /etc]> ping 128.15.136.254 > PING 128.15.136.254 (128.15.136.254): 56 data bytes > 64 bytes from 128.15.136.254: icmp_seq=1 ttl=255 time=1.015 ms > 64 bytes from 128.15.136.254: icmp_seq=2 ttl=255 time=0.217 ms > 64 bytes from 128.15.136.254: icmp_seq=3 ttl=255 time=0.278 ms > 64 bytes from 128.15.136.254: icmp_seq=4 ttl=255 time=0.238 ms > ^C > --- 128.15.136.254 ping statistics --- > 5 packets transmitted, 4 packets received, 20.0% packet loss > round-trip min/avg/max/stddev = 0.217/0.437/1.015/0.334 ms > > I was able to run tcpdump during all of this, and it *nothing* between > the system and the switch until I run ifconfig igb1 down/up, and then > you see the CDP and Tree Spanning traffic. > > The networking team here has told me there are no errors on the switch, > or the port I am on, and they even moved me from one port to another, > but this is still happening on a fairly regular basis now that I've > added more backup clients. > > Is this a possible bug with my hardware and the intel driver? I have a > pcap file and more system information that might provide a lot more > information, but I don't want to send that out to a mailing list. > _______________________________________________ You may want to pay attention to the current discussions regarding the intel driver (em and igb). Can you post the output of lspci -vvv ? Sean From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 18:17: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 9C13D1065670 for ; Wed, 2 Feb 2011 18:17:13 +0000 (UTC) (envelope-from carlson39@llnl.gov) Received: from smtp.llnl.gov (nspiron-3.llnl.gov [128.115.41.83]) by mx1.freebsd.org (Postfix) with ESMTP id 857868FC19 for ; Wed, 2 Feb 2011 18:17:13 +0000 (UTC) X-Attachments: None Received: from bagua.llnl.gov (HELO [134.9.197.135]) ([134.9.197.135]) by smtp.llnl.gov with ESMTP; 02 Feb 2011 10:17:12 -0800 Message-ID: <4D499FA8.7020101@llnl.gov> Date: Wed, 02 Feb 2011 10:17:12 -0800 From: Mike Carlson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sean Bruno References: <4D48721A.5040906@llnl.gov> <1296670033.2286.0.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1296670033.2286.0.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: A flood of bacula traffic causes igb interface to go offline. 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, 02 Feb 2011 18:17:13 -0000 On 02/02/2011 10:07 AM, Sean Bruno wrote: > On Tue, 2011-02-01 at 12:50 -0800, Mike Carlson wrote: >> Hey net@, >> >> I have a FreeBSD 8.2-RC2 system running on a HP DL180 G6, using the >> onboard Intel controller, and it is our primary Bacula storage node and >> director node. >> >> We have 96 clients that are scheduled to run at 8:30pm. After about 9 - >> 10 minutes of activity (mrtg graphs show about 50-60MB/sec incoming >> traffic), the igb1 interface is no longer able to communicate with the >> Cisco switch. >> >> The interesting part is, the interface is still "up", there is nothing >> in the kernel message buffer, and nothing relevant in the log file (just >> syslogd and ldap errors because they cannot reach their respective >> network servers). The system only responds to the network until I either >> reboot, or run 'ifconfig igb1 down ; ifconfig igb1 up'. There is no >> firewall loaded/configured. >> >> Thankfully, I have a KVM over IP, so when this happens I can at least >> run script(1) and capture some useful information. >> ifconfig igb1 >> igb1: flags=8843 metric 0 mtu 1500 >> >> options=1bb >> ether 1c:c1:de:e9:fb:af >> inet 128.15.136.105 netmask 0xffffff00 broadcast 128.15.136.255 >> inet 128.15.136.108 netmask 0xffffff00 broadcast 128.15.136.255 >> inet 128.15.136.102 netmask 0xffffff00 broadcast 128.15.136.255 >> media: Ethernet autoselect (1000baseT) >> status: active >> >> I can ping the internal IP (but I realize that is probably a useless >> test...) >> root@write /etc]> ping 128.15.136.105 >> PING 128.15.136.105 (128.15.136.105): 56 data bytes >> 64 bytes from 128.15.136.105: icmp_seq=0 ttl=64 time=0.024 ms >> 64 bytes from 128.15.136.105: icmp_seq=1 ttl=64 time=0.015 ms >> ^C >> --- 128.15.136.105 ping statistics --- >> 2 packets transmitted, 2 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.015/0.019/0.024/0.005 ms >> >> Attempting to ping the router: >> root@write /etc]> ping 128.15.136.254 >> PING 128.15.136.254 (128.15.136.254): 56 data bytes >> ping: sendto: Host is down >> ping: sendto: Host is down >> ping: sendto: Host is down >> ping: sendto: Host is down >> ^C >> --- 128.15.136.254 ping statistics --- >> 9 packets transmitted, 0 packets received, 100.0% packet loss >> >> >> The only thing that seems to solve this problem is to either reboot, or >> do an "ifconfig down/up": >> >> root@write /etc]> ifconfig igb1 down >> root@write /etc]> ifconfig igb1 >> root@write /etc]> ping 128.15.136.254 >> PING 128.15.136.254 (128.15.136.254): 56 data bytes >> 64 bytes from 128.15.136.254: icmp_seq=1 ttl=255 time=1.015 ms >> 64 bytes from 128.15.136.254: icmp_seq=2 ttl=255 time=0.217 ms >> 64 bytes from 128.15.136.254: icmp_seq=3 ttl=255 time=0.278 ms >> 64 bytes from 128.15.136.254: icmp_seq=4 ttl=255 time=0.238 ms >> ^C >> --- 128.15.136.254 ping statistics --- >> 5 packets transmitted, 4 packets received, 20.0% packet loss >> round-trip min/avg/max/stddev = 0.217/0.437/1.015/0.334 ms >> >> I was able to run tcpdump during all of this, and it *nothing* between >> the system and the switch until I run ifconfig igb1 down/up, and then >> you see the CDP and Tree Spanning traffic. >> >> The networking team here has told me there are no errors on the switch, >> or the port I am on, and they even moved me from one port to another, >> but this is still happening on a fairly regular basis now that I've >> added more backup clients. >> >> Is this a possible bug with my hardware and the intel driver? I have a >> pcap file and more system information that might provide a lot more >> information, but I don't want to send that out to a mailing list. >> _______________________________________________ > You may want to pay attention to the current discussions regarding the > intel driver (em and igb). > > Can you post the output of lspci -vvv ? > > Sean > Hey Sean, thanks for the reply! Yeah, I've noticed a lot of the em/igb emails going around, and I'm curious if it is related or something different all together. Here is the output from pciconf -lvbc: hostb0@pci0:0:0:0: class=0x060000 card=0x330b103c chip=0x34068086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub to ESI Port' class = bridge subclass = HOST-PCI cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 128(128) link x4(x4) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib1@pci0:0:1:0: class=0x060400 card=0x330b103c chip=0x34088086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 1' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x330b103c cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x4(x4) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib2@pci0:0:3:0: class=0x060400 card=0x330b103c chip=0x340a8086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 3' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x330b103c cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x8(x16) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib3@pci0:0:7:0: class=0x060400 card=0x330b103c chip=0x340e8086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 7' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x330b103c cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x4(x16) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib4@pci0:0:9:0: class=0x060400 card=0x330b103c chip=0x34108086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 9' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x330b103c cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x4(x4) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 none0@pci0:0:20:0: class=0x080000 card=0x000b003c chip=0x342e8086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub System Management Registers' class = base peripheral subclass = interrupt controller cap 10[40] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) none1@pci0:0:20:1: class=0x080000 card=0x000b003c chip=0x34228086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub GPIO and Scratch Pad Registers' class = base peripheral subclass = interrupt controller cap 10[40] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) none2@pci0:0:20:2: class=0x080000 card=0x000b003c chip=0x34238086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub Control Status and RAS Registers' class = base peripheral subclass = interrupt controller cap 10[40] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) uhci0@pci0:0:26:0: class=0x0c0300 card=0x330b103c chip=0x3a378086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *4' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x9800, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:7: class=0x0c0320 card=0x330b103c chip=0x3a3c8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB EHCI Controller *2' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfa7f8000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP pcib5@pci0:0:28:0: class=0x060400 card=0x330b103c chip=0x3a408086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express Port 1' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(128) link x0(x4) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x330b103c cap 01[a0] = powerspec 2 supports D0 D3 current D0 ecap 0002[100] = VC 1 max VC0 ecap 0005[180] = unknown 1 pcib6@pci0:0:28:4: class=0x060400 card=0x330b103c chip=0x3a488086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express Port 5' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x2) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x330b103c cap 01[a0] = powerspec 2 supports D0 D3 current D0 ecap 0002[100] = VC 1 max VC0 ecap 0005[180] = unknown 1 uhci1@pci0:0:29:0: class=0x0c0300 card=0x330b103c chip=0x3a348086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *1' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x9880, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP uhci2@pci0:0:29:1: class=0x0c0300 card=0x330b103c chip=0x3a358086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *2' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x9c00, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP uhci3@pci0:0:29:2: class=0x0c0300 card=0x330b103c chip=0x3a368086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *3' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xa000, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP ehci1@pci0:0:29:7: class=0x0c0320 card=0x330b103c chip=0x3a3a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB EHCI Controller *1' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfa7fa000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP pcib7@pci0:0:30:0: class=0x060401 card=0x330b103c 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 cap 0d[50] = PCI Bridge card=0x330b103c isab0@pci0:0:31:0: class=0x060100 card=0x330b103c chip=0x3a168086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'LPC Interface Controller' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: SATA RAID-5, 4 PCI-e x1 slots atapci0@pci0:0:31:2: class=0x010601 card=0x330b103c chip=0x3a228086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '6 port SATA AHCI Controller' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0xa880, size 8, enabled bar [14] = type I/O Port, range 32, base 0xa800, size 4, enabled bar [18] = type I/O Port, range 32, base 0xa480, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xa400, size 4, enabled bar [20] = type I/O Port, range 32, base 0xa080, size 32, enabled bar [24] = type Memory, range 32, base 0xfa7fc000, size 2048, enabled cap 05[80] = MSI supports 16 messages cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 13[b0] = PCI Advanced Features: FLR TP igb0@pci0:7:0:0: class=0x020000 card=0x323f103c chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfbe60000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfbe40000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xe880, size 32, enabled bar [1c] = type Memory, range 32, base 0xfbeb8000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 1cc1deffffe9fbae ecap 000e[150] = unknown 1 ecap 0010[160] = unknown 1 igb1@pci0:7:0:1: class=0x020000 card=0x323f103c chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfbee0000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfbec0000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xec00, size 32, enabled bar [1c] = type Memory, range 32, base 0xfbebc000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 1cc1deffffe9fbae ecap 000e[150] = unknown 1 ecap 0010[160] = unknown 1 ciss0@pci0:6:0:0: class=0x010400 card=0x3243103c chip=0x323a103c rev=0x01 hdr=0x00 vendor = 'Hewlett-Packard Company' device = 'Smart Array P410i Controller (Smart Array P410i Controller)' class = mass storage subclass = RAID bar [10] = type Memory, range 64, base 0xfb800000, size 4194304, enabled bar [18] = type Memory, range 64, base 0xfbdff000, size 4096, enabled bar [20] = type I/O Port, range 32, base 0xd800, size 256, enabled cap 01[40] = powerspec 3 supports D0 D1 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint max data 256(256) link x8(x8) cap 11[ac] = MSI-X supports 16 messages in map 0x10 enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected isp0@pci0:5:0:0: class=0x0c0400 card=0x015d1077 chip=0x25321077 rev=0x02 hdr=0x00 vendor = 'QLogic Corporation' device = '8Gb PCIe x8 Single/Dual Fibre Channel HBA (ISP2532)' class = serial bus subclass = Fibre Channel bar [10] = type I/O Port, range 32, base 0xc400, size 256, enabled bar [14] = type Memory, range 64, base 0xfb7f8000, size 16384, enabled bar [1c] = type Memory, range 64, base 0xfb500000, size 1048576, enabled cap 01[44] = powerspec 3 supports D0 D3 current D0 cap 10[4c] = PCI-Express 2 endpoint max data 256(1024) link x4(x8) cap 05[88] = MSI supports 32 messages, 64 bit enabled with 1 message cap 03[98] = VPD cap 11[a0] = MSI-X supports 32 messages in map 0x14 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[138] = unknown 1 isp1@pci0:5:0:1: class=0x0c0400 card=0x015d1077 chip=0x25321077 rev=0x02 hdr=0x00 vendor = 'QLogic Corporation' device = '8Gb PCIe x8 Single/Dual Fibre Channel HBA (ISP2532)' class = serial bus subclass = Fibre Channel bar [10] = type I/O Port, range 32, base 0xc800, size 256, enabled bar [14] = type Memory, range 64, base 0xfb7fc000, size 16384, enabled bar [1c] = type Memory, range 64, base 0xfb600000, size 1048576, enabled cap 01[44] = powerspec 3 supports D0 D3 current D0 cap 10[4c] = PCI-Express 2 endpoint max data 256(1024) link x4(x8) cap 05[88] = MSI supports 32 messages, 64 bit enabled with 1 message cap 03[98] = VPD cap 11[a0] = MSI-X supports 32 messages in map 0x14 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[138] = unknown 1 isp2@pci0:4:0:0: class=0x0c0400 card=0x015d1077 chip=0x25321077 rev=0x02 hdr=0x00 vendor = 'QLogic Corporation' device = '8Gb PCIe x8 Single/Dual Fibre Channel HBA (ISP2532)' class = serial bus subclass = Fibre Channel bar [10] = type I/O Port, range 32, base 0xb400, size 256, enabled bar [14] = type Memory, range 64, base 0xfb4f8000, size 16384, enabled bar [1c] = type Memory, range 64, base 0xfb200000, size 1048576, enabled cap 01[44] = powerspec 3 supports D0 D3 current D0 cap 10[4c] = PCI-Express 2 endpoint max data 256(1024) link x4(x8) cap 05[88] = MSI supports 32 messages, 64 bit enabled with 1 message cap 03[98] = VPD cap 11[a0] = MSI-X supports 32 messages in map 0x14 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[138] = unknown 1 isp3@pci0:4:0:1: class=0x0c0400 card=0x015d1077 chip=0x25321077 rev=0x02 hdr=0x00 vendor = 'QLogic Corporation' device = '8Gb PCIe x8 Single/Dual Fibre Channel HBA (ISP2532)' class = serial bus subclass = Fibre Channel bar [10] = type I/O Port, range 32, base 0xb800, size 256, enabled bar [14] = type Memory, range 64, base 0xfb4fc000, size 16384, enabled bar [1c] = type Memory, range 64, base 0xfb300000, size 1048576, enabled cap 01[44] = powerspec 3 supports D0 D3 current D0 cap 10[4c] = PCI-Express 2 endpoint max data 256(1024) link x4(x8) cap 05[88] = MSI supports 32 messages, 64 bit enabled with 1 message cap 03[98] = VPD cap 11[a0] = MSI-X supports 32 messages in map 0x14 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[138] = unknown 1 vgapci0@pci0:2:0:0: class=0x030000 card=0x010019a2 chip=0x0522102b rev=0x02 hdr=0x00 vendor = 'Matrox Electronic Systems Ltd.' device = 'Matrox G200e (ServerEngines) - English (G200e)' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 32, base 0xf8000000, size 16777216, enabled bar [14] = type Memory, range 32, base 0xfb1fc000, size 16384, enabled bar [18] = type Memory, range 32, base 0xfa800000, size 8388608, enabled cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 10[e4] = PCI-Express 1 legacy endpoint max data 128(128) link x1(x1) cap 05[54] = MSI supports 1 message And just for good measure, the output of sysctl -a|grep igb.1: dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.7 dev.igb.1.%driver: igb dev.igb.1.%location: slot=0 function=1 dev.igb.1.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x103c subdevice=0x323f class=0x020000 dev.igb.1.%parent: pci7 dev.igb.1.nvm: -1 dev.igb.1.flow_control: 3 dev.igb.1.enable_aim: 1 dev.igb.1.rx_processing_limit: 100 dev.igb.1.link_irq: 2 dev.igb.1.dropped: 0 dev.igb.1.tx_dma_fail: 0 dev.igb.1.rx_overruns: 0 dev.igb.1.watchdog_timeouts: 0 dev.igb.1.device_control: 1221591617 dev.igb.1.rx_control: 67141634 dev.igb.1.interrupt_mask: 4 dev.igb.1.extended_int_mask: 2147484159 dev.igb.1.tx_buf_alloc: 0 dev.igb.1.rx_buf_alloc: 0 dev.igb.1.fc_high_water: 58976 dev.igb.1.fc_low_water: 58960 dev.igb.1.queue0.interrupt_rate: 90909 dev.igb.1.queue0.txd_head: 123 dev.igb.1.queue0.txd_tail: 123 dev.igb.1.queue0.no_desc_avail: 0 dev.igb.1.queue0.tx_packets: 9087511 dev.igb.1.queue0.rxd_head: 561 dev.igb.1.queue0.rxd_tail: 560 dev.igb.1.queue0.rx_packets: 17568305 dev.igb.1.queue0.rx_bytes: 10622483930 dev.igb.1.queue0.lro_queued: 0 dev.igb.1.queue0.lro_flushed: 0 dev.igb.1.queue1.interrupt_rate: 71428 dev.igb.1.queue1.txd_head: 750 dev.igb.1.queue1.txd_tail: 750 dev.igb.1.queue1.no_desc_avail: 0 dev.igb.1.queue1.tx_packets: 5785476 dev.igb.1.queue1.rxd_head: 1012 dev.igb.1.queue1.rxd_tail: 1011 dev.igb.1.queue1.rx_packets: 9985012 dev.igb.1.queue1.rx_bytes: 8632281270 dev.igb.1.queue1.lro_queued: 0 dev.igb.1.queue1.lro_flushed: 0 dev.igb.1.queue2.interrupt_rate: 71428 dev.igb.1.queue2.txd_head: 510 dev.igb.1.queue2.txd_tail: 510 dev.igb.1.queue2.no_desc_avail: 0 dev.igb.1.queue2.tx_packets: 8436814 dev.igb.1.queue2.rxd_head: 312 dev.igb.1.queue2.rxd_tail: 311 dev.igb.1.queue2.rx_packets: 14930232 dev.igb.1.queue2.rx_bytes: 10272636551 dev.igb.1.queue2.lro_queued: 0 dev.igb.1.queue2.lro_flushed: 0 dev.igb.1.queue3.interrupt_rate: 47619 dev.igb.1.queue3.txd_head: 921 dev.igb.1.queue3.txd_tail: 923 dev.igb.1.queue3.no_desc_avail: 0 dev.igb.1.queue3.tx_packets: 22152920 dev.igb.1.queue3.rxd_head: 642 dev.igb.1.queue3.rxd_tail: 641 dev.igb.1.queue3.rx_packets: 41651842 dev.igb.1.queue3.rx_bytes: 24505237708 dev.igb.1.queue3.lro_queued: 0 dev.igb.1.queue3.lro_flushed: 0 dev.igb.1.queue4.interrupt_rate: 5747 dev.igb.1.queue4.txd_head: 265 dev.igb.1.queue4.txd_tail: 265 dev.igb.1.queue4.no_desc_avail: 0 dev.igb.1.queue4.tx_packets: 23137021 dev.igb.1.queue4.rxd_head: 45 dev.igb.1.queue4.rxd_tail: 43 dev.igb.1.queue4.rx_packets: 33201196 dev.igb.1.queue4.rx_bytes: 43730274433 dev.igb.1.queue4.lro_queued: 0 dev.igb.1.queue4.lro_flushed: 0 dev.igb.1.queue5.interrupt_rate: 71428 dev.igb.1.queue5.txd_head: 252 dev.igb.1.queue5.txd_tail: 252 dev.igb.1.queue5.no_desc_avail: 0 dev.igb.1.queue5.tx_packets: 71891198 dev.igb.1.queue5.rxd_head: 337 dev.igb.1.queue5.rxd_tail: 336 dev.igb.1.queue5.rx_packets: 129434961 dev.igb.1.queue5.rx_bytes: 103517960728 dev.igb.1.queue5.lro_queued: 0 dev.igb.1.queue5.lro_flushed: 0 dev.igb.1.queue6.interrupt_rate: 5494 dev.igb.1.queue6.txd_head: 597 dev.igb.1.queue6.txd_tail: 597 dev.igb.1.queue6.no_desc_avail: 0 dev.igb.1.queue6.tx_packets: 26263632 dev.igb.1.queue6.rxd_head: 943 dev.igb.1.queue6.rxd_tail: 942 dev.igb.1.queue6.rx_packets: 38106031 dev.igb.1.queue6.rx_bytes: 53989177532 dev.igb.1.queue6.lro_queued: 0 dev.igb.1.queue6.lro_flushed: 0 dev.igb.1.queue7.interrupt_rate: 71428 dev.igb.1.queue7.txd_head: 1016 dev.igb.1.queue7.txd_tail: 1016 dev.igb.1.queue7.no_desc_avail: 0 dev.igb.1.queue7.tx_packets: 15092803 dev.igb.1.queue7.rxd_head: 798 dev.igb.1.queue7.rxd_tail: 797 dev.igb.1.queue7.rx_packets: 22656798 dev.igb.1.queue7.rx_bytes: 26720782500 dev.igb.1.queue7.lro_queued: 0 dev.igb.1.queue7.lro_flushed: 0 dev.igb.1.mac_stats.excess_coll: 0 dev.igb.1.mac_stats.single_coll: 0 dev.igb.1.mac_stats.multiple_coll: 0 dev.igb.1.mac_stats.late_coll: 0 dev.igb.1.mac_stats.collision_count: 0 dev.igb.1.mac_stats.symbol_errors: 0 dev.igb.1.mac_stats.sequence_errors: 0 dev.igb.1.mac_stats.defer_count: 0 dev.igb.1.mac_stats.missed_packets: 0 dev.igb.1.mac_stats.recv_no_buff: 0 dev.igb.1.mac_stats.recv_undersize: 0 dev.igb.1.mac_stats.recv_fragmented: 0 dev.igb.1.mac_stats.recv_oversize: 0 dev.igb.1.mac_stats.recv_jabber: 0 dev.igb.1.mac_stats.recv_errs: 0 dev.igb.1.mac_stats.crc_errs: 0 dev.igb.1.mac_stats.alignment_errs: 0 dev.igb.1.mac_stats.coll_ext_errs: 0 dev.igb.1.mac_stats.xon_recvd: 0 dev.igb.1.mac_stats.xon_txd: 0 dev.igb.1.mac_stats.xoff_recvd: 0 dev.igb.1.mac_stats.xoff_txd: 0 dev.igb.1.mac_stats.total_pkts_recvd: 307576071 dev.igb.1.mac_stats.good_pkts_recvd: 307531561 dev.igb.1.mac_stats.bcast_pkts_recvd: 198160 dev.igb.1.mac_stats.mcast_pkts_recvd: 14761 dev.igb.1.mac_stats.rx_frames_64: 77487 dev.igb.1.mac_stats.rx_frames_65_127: 1023263 dev.igb.1.mac_stats.rx_frames_128_255: 1189767 dev.igb.1.mac_stats.rx_frames_256_511: 2057322 dev.igb.1.mac_stats.rx_frames_512_1023: 182252548 dev.igb.1.mac_stats.rx_frames_1024_1522: 120931174 dev.igb.1.mac_stats.good_octets_recvd: 283217010128 dev.igb.1.mac_stats.good_octets_txd: 12132098897 dev.igb.1.mac_stats.total_pkts_txd: 181849061 dev.igb.1.mac_stats.good_pkts_txd: 181849061 dev.igb.1.mac_stats.bcast_pkts_txd: 58 dev.igb.1.mac_stats.mcast_pkts_txd: 0 dev.igb.1.mac_stats.tx_frames_64: 120262472 dev.igb.1.mac_stats.tx_frames_65_127: 61075351 dev.igb.1.mac_stats.tx_frames_128_255: 15636 dev.igb.1.mac_stats.tx_frames_256_511: 488238 dev.igb.1.mac_stats.tx_frames_512_1023: 2904 dev.igb.1.mac_stats.tx_frames_1024_1522: 4460 dev.igb.1.mac_stats.tso_txd: 3047 dev.igb.1.mac_stats.tso_ctx_fail: 0 dev.igb.1.interrupts.asserts: 285657274 dev.igb.1.interrupts.rx_pkt_timer: 307528026 dev.igb.1.interrupts.rx_abs_timer: 0 dev.igb.1.interrupts.tx_pkt_timer: 0 dev.igb.1.interrupts.tx_abs_timer: 307531561 dev.igb.1.interrupts.tx_queue_empty: 181847483 dev.igb.1.interrupts.tx_queue_min_thresh: 0 dev.igb.1.interrupts.rx_desc_min_thresh: 0 dev.igb.1.interrupts.rx_overrun: 0 dev.igb.1.host.breaker_tx_pkt: 0 dev.igb.1.host.host_tx_pkt_discard: 0 dev.igb.1.host.rx_pkt: 3536 dev.igb.1.host.breaker_rx_pkts: 0 dev.igb.1.host.breaker_rx_pkt_drop: 0 dev.igb.1.host.tx_good_pkt: 1578 dev.igb.1.host.breaker_tx_pkt_drop: 0 dev.igb.1.host.rx_good_bytes: 283217016487 dev.igb.1.host.tx_good_bytes: 12132098897 dev.igb.1.host.length_errors: 0 dev.igb.1.host.serdes_violation_pkt: 0 dev.igb.1.host.header_redir_missed: 0 From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 18:29: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 DDF03106564A; Wed, 2 Feb 2011 18:29:09 +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 7A7C78FC17; Wed, 2 Feb 2011 18:29:09 +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.4/8.14.4) with ESMTP id p12IT70o065398 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Feb 2011 13:29:07 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D49A26B.5050803@sentex.net> Date: Wed, 02 Feb 2011 13:28:59 -0500 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: Jack Vogel References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@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.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Ivan Voras , Sean Bruno , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 02 Feb 2011 18:29:10 -0000 On 2/2/2011 12:37 PM, Jack Vogel wrote: > So has everyone that wanted to get something testing been able to do so? I have been testing in the back and will deploy to my production box this afternoon. As I am not able to reproduce it easily, it will be a bit before I can say the issue is gone. Jan however, was able to trigger it with greater ease ? ---Mike > > Jack > > > On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote: > >> On 2/1/2011 5:03 PM, Sean Bruno wrote: >>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote: >>>> To those who are going to test, here is the if_em.c, based on head, >>>> with my >>>> changes, I have to leave for the afternoon, and have not had a chance >>>> to build >>>> this, but it should work. I will check back in the later evening. >>>> >>>> Any blatant problems Sean, feel free to fix them :) >>>> >>>> Jack >>>> >>> >>> >>> I suspect that line 1490 should be: >>> if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { >>> >> >> >> I have hacked up a RELENG_8 version which I think is correct including >> the above change >> >> http://www.tancsa.com/if_em-8.c >> >> >> >> --- if_em.c.orig 2011-02-01 21:47:14.000000000 -0500 >> +++ if_em.c 2011-02-01 21:47:19.000000000 -0500 >> @@ -30,7 +30,7 @@ >> POSSIBILITY OF SUCH DAMAGE. >> >> >> ******************************************************************************/ >> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53 >> jfv Exp $*/ >> +/*$FreeBSD$*/ >> >> #ifdef HAVE_KERNEL_OPTION_HEADERS >> #include "opt_device_polling.h" >> @@ -93,7 +93,7 @@ >> /********************************************************************* >> * Driver version: >> *********************************************************************/ >> -char em_driver_version[] = "7.1.9"; >> +char em_driver_version[] = "7.1.9-test"; >> >> /********************************************************************* >> * PCI Device ID Table >> @@ -927,11 +927,10 @@ >> if (!adapter->link_active) >> return; >> >> - /* Call cleanup if number of TX descriptors low */ >> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) >> - em_txeof(txr); >> - >> while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { >> + /* First cleanup if TX descriptors low */ >> + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) >> + em_txeof(txr); >> if (txr->tx_avail < EM_MAX_SCATTER) { >> ifp->if_drv_flags |= IFF_DRV_OACTIVE; >> break; >> @@ -1411,8 +1410,7 @@ >> if (!drbr_empty(ifp, txr->br)) >> em_mq_start_locked(ifp, txr, NULL); >> #else >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >> - em_start_locked(ifp, txr); >> + em_start_locked(ifp, txr); >> #endif >> EM_TX_UNLOCK(txr); >> >> @@ -1475,11 +1473,10 @@ >> struct ifnet *ifp = adapter->ifp; >> struct tx_ring *txr = adapter->tx_rings; >> struct rx_ring *rxr = adapter->rx_rings; >> - bool more; >> - >> >> if (ifp->if_drv_flags & IFF_DRV_RUNNING) { >> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL); >> + bool more_rx; >> + more_rx = em_rxeof(rxr, adapter->rx_process_limit, NULL); >> >> EM_TX_LOCK(txr); >> em_txeof(txr); >> @@ -1487,12 +1484,10 @@ >> if (!drbr_empty(ifp, txr->br)) >> em_mq_start_locked(ifp, txr, NULL); >> #else >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >> - em_start_locked(ifp, txr); >> + em_start_locked(ifp, txr); >> #endif >> - em_txeof(txr); >> EM_TX_UNLOCK(txr); >> - if (more) { >> + if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { >> taskqueue_enqueue(adapter->tq, &adapter->que_task); >> return; >> } >> @@ -1604,7 +1599,6 @@ >> if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >> em_start_locked(ifp, txr); >> #endif >> - em_txeof(txr); >> E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims); >> EM_TX_UNLOCK(txr); >> } >> @@ -3730,17 +3724,17 @@ >> txr->queue_status = EM_QUEUE_HUNG; >> >> /* >> - * If we have enough room, clear IFF_DRV_OACTIVE >> + * If we have a minimum free, clear IFF_DRV_OACTIVE >> * to tell the stack that it is OK to send packets. >> */ >> - if (txr->tx_avail > EM_TX_CLEANUP_THRESHOLD) { >> + if (txr->tx_avail > EM_MAX_SCATTER) >> ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; >> - /* Disable watchdog if all clean */ >> - if (txr->tx_avail == adapter->num_tx_desc) { >> - txr->queue_status = EM_QUEUE_IDLE; >> - return (FALSE); >> - } >> - } >> + >> + /* Disable watchdog if all clean */ >> + if (txr->tx_avail == adapter->num_tx_desc) { >> + txr->queue_status = EM_QUEUE_IDLE; >> + return (FALSE); >> + } >> >> return (TRUE); >> } >> @@ -5064,8 +5058,8 @@ >> char namebuf[QUEUE_NAME_LEN]; >> >> /* Driver Statistics */ >> - SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", >> - CTLFLAG_RD, &adapter->link_irq, 0, >> + SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", >> + CTLFLAG_RD, &adapter->link_irq,0, >> "Link MSIX IRQ Handled"); >> SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "mbuf_alloc_fail", >> CTLFLAG_RD, &adapter->mbuf_alloc_failed, >> @@ -5108,11 +5102,13 @@ >> queue_list = SYSCTL_CHILDREN(queue_node); >> >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_head", >> - CTLFLAG_RD, adapter, E1000_TDH(txr->me), >> + CTLFLAG_RD, adapter, >> + E1000_TDH(txr->me), >> em_sysctl_reg_handler, "IU", >> "Transmit Descriptor Head"); >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_tail", >> - CTLFLAG_RD, adapter, E1000_TDT(txr->me), >> + CTLFLAG_RD, adapter, >> + E1000_TDT(txr->me), >> em_sysctl_reg_handler, "IU", >> "Transmit Descriptor Tail"); >> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "tx_irq", >> @@ -5123,11 +5119,13 @@ >> "Queue No Descriptor Available"); >> >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_head", >> - CTLFLAG_RD, adapter, E1000_RDH(rxr->me), >> + CTLFLAG_RD, adapter, >> + E1000_RDH(rxr->me), >> em_sysctl_reg_handler, "IU", >> "Receive Descriptor Head"); >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_tail", >> - CTLFLAG_RD, adapter, E1000_RDT(rxr->me), >> + CTLFLAG_RD, adapter, >> + E1000_RDT(rxr->me), >> em_sysctl_reg_handler, "IU", >> "Receive Descriptor Tail"); >> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "rx_irq", >> @@ -5141,19 +5139,19 @@ >> CTLFLAG_RD, NULL, "Statistics"); >> stat_list = SYSCTL_CHILDREN(stat_node); >> >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", >> CTLFLAG_RD, &stats->ecol, >> "Excessive collisions"); >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", >> CTLFLAG_RD, &stats->scc, >> "Single collisions"); >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", >> CTLFLAG_RD, &stats->mcc, >> "Multiple collisions"); >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", >> CTLFLAG_RD, &stats->latecol, >> "Late collisions"); >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", >> CTLFLAG_RD, &stats->colc, >> "Collision Count"); >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "symbol_errors", >> @@ -5240,12 +5238,12 @@ >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "rx_frames_1024_1522", >> CTLFLAG_RD, &adapter->stats.prc1522, >> "1023-1522 byte frames received"); >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", >> CTLFLAG_RD, &adapter->stats.gorc, >> "Good Octets Received"); >> >> /* Packet Transmission Stats */ >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", >> CTLFLAG_RD, &adapter->stats.gotc, >> "Good Octets Transmitted"); >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "total_pkts_txd", >> >> -- >> ------------------- >> 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/ >> > -- ------------------- 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 Wed Feb 2 20:10:13 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 4FAC5106566B for ; Wed, 2 Feb 2011 20:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2220E8FC12 for ; Wed, 2 Feb 2011 20:10:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p12KACAk039593 for ; Wed, 2 Feb 2011 20:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p12KACV5039592; Wed, 2 Feb 2011 20:10:12 GMT (envelope-from gnats) Date: Wed, 2 Feb 2011 20:10:12 GMT Message-Id: <201102022010.p12KACV5039592@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mark Boolootian Cc: Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Boolootian List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 20:10:13 -0000 The following reply was made to PR kern/146792; it has been noted by GNATS. From: Mark Boolootian To: bug-followup@FreeBSD.org, niko@gtelecom.ru Cc: Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load Date: Wed, 2 Feb 2011 11:37:16 -0800 --00163630f77dc34e0d049b51c661 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I hit this problem on a pair of anycast name servers. What I'm running: FreeBSD ns1.example.com 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Here's a peak at ps: ns1b# ps auxwww | head USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 11 100.0 0.0 0 32 ?? RL 11Jan11 59960:15.43 [idle] root 21 100.0 0.0 0 16 ?? RL 11Jan11 1112:01.24 [flowcleaner] root 0 0.0 0.0 0 96 ?? DLs 11Jan11 0:02.94 [kernel] root 1 0.0 0.0 3204 556 ?? ILs 11Jan11 0:00.01 /sbin/init -- root 2 0.0 0.0 0 16 ?? DL 11Jan11 0:52.87 [g_event] root 3 0.0 0.0 0 16 ?? DL 11Jan11 0:10.10 [g_up] root 4 0.0 0.0 0 16 ?? DL 11Jan11 0:15.18 [g_down] root 5 0.0 0.0 0 16 ?? DL 11Jan11 0:00.00 [mpt_recovery0] The box is running Quagga with a single OSPF adjacency. It has about 500 routes. Both anycast instances of ns1 hit this problem, but neither instance of ns2, which are configured identically, saw the trouble. The ns1 name servers are much busier than ns2. It appears that one instance of ns1 died almost a week ago, which went unnoticed :-( This morning, the second instance died. At that point, it was hard not to notice :-) Traffic on the mailing list suggests that 'sysctl net.inet.flowtable.enable=0' is a work-around. We'll pursue that path and hope for a bug fix in the not-too-distant future. thanks, mark --00163630f77dc34e0d049b51c661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi folks,
=A0
I hit this problem on a pair of anyc= ast name servers. =A0What
I'm running:
=A0
FreeBSD ns1.example.com 8.1-RELEAS= E FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49
UTC 2010 =A0 =A0 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENER= IC =A0amd64

Here's a peak at ps:
ns1b# ps auxwww | head
USER =A0 =A0 PID %CPU %MEM =A0 VSZ =A0 RSS =A0TT =A0STAT STARTED =A0 = =A0 =A0TIME COMMAND
root =A0 =A0 =A011 100.0 =A00.0 =A0 = =A0 0 =A0 =A032 =A0?? =A0RL =A0 11Jan11 59960:15.43 [idle]
root =A0 =A0 =A021 100.0 =A00.0 =A0 =A0 0 =A0 =A016 =A0?? =A0RL =A0 11= Jan11 1112:01.24 [flowcleaner]
root =A0 =A0 =A0 0 =A00.0 = =A00.0 =A0 =A0 0 =A0 =A096 =A0?? =A0DLs =A011Jan11 =A0 0:02.94 [kernel]
root =A0 =A0 =A0 1 =A00.0 =A00.0 =A03204 =A0 556 =A0?? =A0ILs =A011Jan= 11 =A0 0:00.01 /sbin/init --
root =A0 =A0 =A0 2 =A00.0 =A0= 0.0 =A0 =A0 0 =A0 =A016 =A0?? =A0DL =A0 11Jan11 =A0 0:52.87 [g_event]
root =A0 =A0 =A0 3 =A00.0 =A00.0 =A0 =A0 0 =A0 =A016 =A0?? =A0DL =A0 1= 1Jan11 =A0 0:10.10 [g_up]
root =A0 =A0 =A0 4 =A00.0 =A00.0= =A0 =A0 0 =A0 =A016 =A0?? =A0DL =A0 11Jan11 =A0 0:15.18 [g_down]
root =A0 =A0 =A0 5 =A00.0 =A00.0 =A0 =A0 0 =A0 =A016 =A0?? =A0DL =A0 1= 1Jan11 =A0 0:00.00 [mpt_recovery0]

The box is running Quagga with a single OSPF adjacency. =A0It= has about 500 routes.
Both anycast instances of ns1 hit this = problem, but neither instance of ns2, which are=A0
configured identically, saw the trouble. =A0The ns1 name servers are much = busier than ns2.

It appears that one instance of ns1 died almost a week ago, w= hich went unnoticed :-( =A0This
morning, the second instance d= ied. =A0At that point, it was hard not to notice :-)

Traffic on the mailing list suggests that 'sysctl ne= t.inet.flowtable.enable=3D0' is a work-around.
We'll pursue that path and hope for a bug fix in the not-too-distant f= uture.

thanks,
mark
--00163630f77dc34e0d049b51c661-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 2 20:50:11 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 C7DD0106566B for ; Wed, 2 Feb 2011 20:50:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF9E8FC14 for ; Wed, 2 Feb 2011 20:50:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p12KoBc4081512 for ; Wed, 2 Feb 2011 20:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p12KoBEI081511; Wed, 2 Feb 2011 20:50:11 GMT (envelope-from gnats) Date: Wed, 2 Feb 2011 20:50:11 GMT Message-Id: <201102022050.p12KoBEI081511@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Bjoern A. Zeeb" Cc: Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bjoern A. Zeeb" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 20:50:11 -0000 The following reply was made to PR kern/146792; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, niko@gtelecom.ru Cc: Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load Date: Wed, 2 Feb 2011 20:36:04 +0000 (UTC) Hi, things could be improved in HEAD and stable/8 (as of r217168 [1]). Please test and report back. /bz [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=217168 -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 03:16: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 F3F61106564A for ; Thu, 3 Feb 2011 03:16:44 +0000 (UTC) (envelope-from szander@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mx1.freebsd.org (Postfix) with ESMTP id 87C3C8FC08 for ; Thu, 3 Feb 2011 03:16:44 +0000 (UTC) Received: from [136.186.229.101] (szander-laptop.caia.swin.edu.au [136.186.229.101]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p132jiH8028887 for ; Thu, 3 Feb 2011 13:45:44 +1100 Message-ID: <4D4A16DA.8060705@swin.edu.au> Date: Thu, 03 Feb 2011 13:45:46 +1100 From: Sebastian Zander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IPFW extension for traffic classification based on statistical properties 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, 03 Feb 2011 03:16:45 -0000 Hi all, We believe this may be of some interest to list members, and apologise in advance for any duplicates you may receive. We are pleased to announce DIFFUSE v0.2, our second release of a system enabling FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties and separate flow classification and treatment. This release contains a number of bug fixes as well as a number of new features. Most notably version 0.2 contains tools to build classifier models, and a feature module and classifier model to classify Skype traffic. Furthermore, there is a Linux version of DIFFUSE now. The project site is http://caia.swin.edu.au/urp/diffuse and the source code can be downloaded directly from http://caia.swin.edu.au/urp/diffuse/downloads.html. The software was developed as part of the DIFFUSE research project at Swinburne University's Centre for Advanced Internet Architectures. The project has been made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. We welcome your feedback and hope you enjoy playing with the code and tools. Cheers, Sebastian Zander and Grenville Armitage http://caia.swin.edu.au From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 05:11: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 B0D95106566B; Thu, 3 Feb 2011 05:11:34 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 188DE8FC14; Thu, 3 Feb 2011 05:11:33 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p135BUZd077272; Thu, 3 Feb 2011 11:11:30 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D4A38FD.7000607@rdtc.ru> Date: Thu, 03 Feb 2011 11:11:25 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gleb Smirnoff References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> <20110201185026.GB62007@glebius.int.ru> In-Reply-To: <20110201185026.GB62007@glebius.int.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John Baldwin Subject: About "panic: bufwrite: buffer is not busy???" 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, 03 Feb 2011 05:11:34 -0000 On 02.02.2011 00:50, Gleb Smirnoff wrote: > E> Uptime: 8h3m51s > E> Dumping 4087 MB (3 chunks) > E> chunk 0: 1MB (150 pages) ... ok > E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? > E> cpuid = 3 > E> Uptime: 8h3m52s > E> Automatic reboot in 15 seconds - press a key on the console to abort > Can you add KDB_TRACE option to kernel? Your boxes for some reason can't > dump core, but with this option we will have at least trace. I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. Has anyone a thought how to fix generation of crashdumps? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 11:16: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 426E21065675 for ; Thu, 3 Feb 2011 11:16:11 +0000 (UTC) (envelope-from plaine@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 0C9C18FC0A for ; Thu, 3 Feb 2011 11:16:10 +0000 (UTC) Received: by iyb26 with SMTP id 26so948339iyb.13 for ; Thu, 03 Feb 2011 03:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=KDGuQwx4sVSLAOZf+NedPcBPLoQwGCpHpQE50EclUIo=; b=unJLVqm0Q7x9pB76Xt6FINCOqa3IZfNH2xqxDvi1zWhdLk8u2HttfCDaswxKNgXJ1r AX+kP/OuBBkYrBBKms4M/DiBq58mFUMhj7yR1R60f/mgwWuSdlp+ZwO049vDAxXUUc6A 1bt6Rox+PBpeXzq4SG/v7XbVXwHF2yKheNsD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Nj4fH/sVLhyL07Q4Rbr9j8fOp0iscMtzAvQ27sF+jsMLQfKQYDe09NXVtj6QZgYRwl x+HkTBi0k2eQi1OAG+4cGBwe3bFw5NWE6o8Fbb0aWpSogQwlQACLuPSvQuipO5vWn5MT PUhU3PcWcXcO4n2oF8+JvlqjoEr31msnGGL10= MIME-Version: 1.0 Received: by 10.42.178.135 with SMTP id bm7mr12616097icb.101.1296730370304; Thu, 03 Feb 2011 02:52:50 -0800 (PST) Received: by 10.42.241.9 with HTTP; Thu, 3 Feb 2011 02:52:50 -0800 (PST) Date: Thu, 3 Feb 2011 12:52:50 +0200 Message-ID: From: pepe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipv6 problem 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, 03 Feb 2011 11:16:11 -0000 I have 2001:14b8:10:402::/64 ipv6 from my isp and I cant get it working. Ifconfig should be ok: backup# ifconfig rl0 inet6 rl0: flags=8843 metric 0 mtu 1500 options=8 inet6 2001:14b8:10:402:2::1 prefixlen 64 default gateway is set to 2001:14b8:10:402::1. When I try to traceroute irc server for example I get this: traceroute6: Warning: irc.cc.tut.fi has multiple addresses; using 2001:708:310:4952:4320:5365:7276:6572 traceroute6 to irc.cc.tut.fi (2001:708:310:4952:4320:5365:7276:6572) from 2001:14b8:10:402:2::1, 64 hops max, 12 byte packets 1 2001:14b8:10:402:2::1 2026.908 ms !A 2999.587 ms !A 3000.423 ms !A So. Could this be problem in my configs or is this because of something wrong at the isp side? -- pepe From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 11:22: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 E0AB1106566B; Thu, 3 Feb 2011 11:22:42 +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 979708FC14; Thu, 3 Feb 2011 11:22:42 +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.4/8.14.4) with ESMTP id p13BMdV4007972 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 06:22:40 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D4A8FF6.2090602@sentex.net> Date: Thu, 03 Feb 2011 06:22:30 -0500 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: Eugene Grosbein References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> <20110201185026.GB62007@glebius.int.ru> <4D4A38FD.7000607@rdtc.ru> In-Reply-To: <4D4A38FD.7000607@rdtc.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: About "panic: bufwrite: buffer is not busy???" 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, 03 Feb 2011 11:22:43 -0000 On 2/3/2011 12:11 AM, Eugene Grosbein wrote: > On 02.02.2011 00:50, Gleb Smirnoff wrote: > >> E> Uptime: 8h3m51s >> E> Dumping 4087 MB (3 chunks) >> E> chunk 0: 1MB (150 pages) ... ok >> E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? >> E> cpuid = 3 >> E> Uptime: 8h3m52s >> E> Automatic reboot in 15 seconds - press a key on the console to abort >> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't >> dump core, but with this option we will have at least trace. > > I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. > Has anyone a thought how to fix generation of crashdumps? But it generates the dump despite the error message Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0x33b9fc fault code = supervisor read, page not present instruction pointer = 0x20:0xc072df2f stack pointer = 0x28:0xe94c2a44 frame pointer = 0x28:0xe94c2a64 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1089 (mpd5) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0xc0681b07 at kdb_backtrace+0x47 #1 0xc0652d27 at panic+0x117 #2 0xc08cd873 at trap_fatal+0x323 #3 0xc08cdaf0 at trap_pfault+0x270 #4 0xc08ce035 at trap+0x465 #5 0xc08b4e6c at calltrap+0x6 #6 0xc07358df at in_leavegroup_locked+0x4f #7 0xc07320d1 at in_control+0x13d1 #8 0xc06fb04a at ifioctl+0x1b4a #9 0xc0698422 at soo_ioctl+0x612 #10 0xc0690c90 at kern_ioctl+0x250 #11 0xc0690e04 at ioctl+0x134 #12 0xc068d82f at syscallenter+0x30f #13 0xc08cdb44 at syscall+0x34 #14 0xc08b4ed1 at Xint0x80_syscall+0x21 Uptime: 1d4h20m49s Physical memory: 3574 MB Dumping 289 MB:panic: bufwrite: buffer is not busy??? cpuid = 1 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Dump complete > > Eugene Grosbein > > > _______________________________________________ > 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" > > -- ------------------- 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 Thu Feb 3 11:25: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 6F1BA1065672 for ; Thu, 3 Feb 2011 11:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 2BC648FC1B for ; Thu, 3 Feb 2011 11:25:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8A36A41C6B4; Thu, 3 Feb 2011 12:25:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id RbZTk8wRJY6Q; Thu, 3 Feb 2011 12:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id AAD6E41C6A7; Thu, 3 Feb 2011 12:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 4AEB94448F3; Thu, 3 Feb 2011 11:23:31 +0000 (UTC) Date: Thu, 3 Feb 2011 11:23:31 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: pepe In-Reply-To: Message-ID: <20110203112145.W80258@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: ipv6 problem 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, 03 Feb 2011 11:25:07 -0000 On Thu, 3 Feb 2011, pepe wrote: > I have 2001:14b8:10:402::/64 ipv6 from my isp and I cant get it working. > Ifconfig should be ok: > backup# ifconfig rl0 inet6 > > rl0: flags=8843 metric 0 mtu 1500 > options=8 > inet6 2001:14b8:10:402:2::1 prefixlen 64 > > default gateway is set to 2001:14b8:10:402::1. When I try to traceroute irc > server for example > I get this: > > traceroute6: Warning: irc.cc.tut.fi has multiple addresses; using > 2001:708:310:4952:4320:5365:7276:6572 > traceroute6 to irc.cc.tut.fi (2001:708:310:4952:4320:5365:7276:6572) from > 2001:14b8:10:402:2::1, 64 hops max, 12 byte packets > 1 2001:14b8:10:402:2::1 2026.908 ms !A 2999.587 ms !A 3000.423 ms !A > > So. Could this be problem in my configs or is this because of something > wrong at the isp side? Not sure as you didn't show us your rc.conf configs and didn't give a release. Try what happens if you do .. manually (rc.conf would do it for you normally) -- if you are on FreeBSD 8.x: ifconfig rl0 -ifdisabled -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 11:52: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 E2A35106566B for ; Thu, 3 Feb 2011 11:52:49 +0000 (UTC) (envelope-from plaine@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 785378FC21 for ; Thu, 3 Feb 2011 11:52:49 +0000 (UTC) Received: by wwf26 with SMTP id 26so1027148wwf.31 for ; Thu, 03 Feb 2011 03:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ojCpeOmS5yWZxt+06JIgbSbe1JXoYBi3vi5GWur+FYI=; b=OBMf75rdPEkyodq4RHFwvdZf/GA76mncIGTZ5QOSNsrlNQuwH4MGMeXdZkDUy0pSS0 p/i/8bKqZ6zABLJ38VBhFZBHKKuiSFsidNIgCxgUVS0Fy5/GAOcyggMmEFhibIVX8pkf V2lDBucgQl3KNJ7GRTfb8DXFxyXTgXNN/N0V0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=xwd7+t5uy6GadJHlwywzctvp7vyyD4v4eyBiM3tPP6WRODToU2CbT2nqeDD+cNmbYZ 27CILuiQYrFVdf3oZPd/eb+neZ19XWLLiJt7qLuebrO+l1z9CE1HSYaNqUaD6aOkxba+ RiGFafWpscrWcNSfxO/ibuNhWRIlzP0chwvp0= Received: by 10.227.179.141 with SMTP id bq13mr6499204wbb.149.1296733968425; Thu, 03 Feb 2011 03:52:48 -0800 (PST) Received: from [192.168.0.30] (78-27-68-136.bb.dnainternet.fi [78.27.68.136]) by mx.google.com with ESMTPS id y29sm526768wbd.22.2011.02.03.03.52.46 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 03:52:47 -0800 (PST) Message-ID: <4D4A970F.30206@gmail.com> Date: Thu, 03 Feb 2011 13:52:47 +0200 From: pepe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipv6 problem 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, 03 Feb 2011 11:52:50 -0000 On 3.2.2011 13:23, Bjoern A. Zeeb wrote: > On Thu, 3 Feb 2011, pepe wrote: > >> I have 2001:14b8:10:402::/64 ipv6 from my isp and I cant get it working. >> Ifconfig should be ok: >> backup# ifconfig rl0 inet6 >> >> rl0: flags=8843 metric 0 mtu 1500 >> options=8 >> inet6 2001:14b8:10:402:2::1 prefixlen 64 >> >> default gateway is set to 2001:14b8:10:402::1. When I try to >> traceroute irc >> server for example >> I get this: >> >> traceroute6: Warning: irc.cc.tut.fi has multiple addresses; using >> 2001:708:310:4952:4320:5365:7276:6572 >> traceroute6 to irc.cc.tut.fi (2001:708:310:4952:4320:5365:7276:6572) from >> 2001:14b8:10:402:2::1, 64 hops max, 12 byte packets >> 1 2001:14b8:10:402:2::1 2026.908 ms !A 2999.587 ms !A 3000.423 ms !A >> >> So. Could this be problem in my configs or is this because of something >> wrong at the isp side? > > Not sure as you didn't show us your rc.conf configs and didn't give a > release. > > Try what happens if you do .. manually (rc.conf would do it for you > normally) -- if you are on FreeBSD 8.x: > > ifconfig rl0 -ifdisabled > IPv6 configs in rc.conf: ipv6_enable="YES" ipv6_defaultrouter="2001:14b8:0010:0402::1" ipv6_network_interfaces="rl0" ifconfig_rl0_alias52="inet6 2001:14b8:0010:0402:2::1 prefixlen 64" Same system is running ipv4 that works fine... And it's 7.2-RELEASE-p6 i386 From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 11:53: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 D787F106566B for ; Thu, 3 Feb 2011 11:53:15 +0000 (UTC) (envelope-from plaine@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 68EB08FC29 for ; Thu, 3 Feb 2011 11:53:15 +0000 (UTC) Received: by wyf19 with SMTP id 19so1049406wyf.13 for ; Thu, 03 Feb 2011 03:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SOp555JhxrDLl+kAcMvvRxIM8KqQ6YTFsWnliXpRYmc=; b=CA0/jVvGwixnRgKOe3J6wcOU4O3wsnJ5o0+17Dmb9dZ0JuEwR4xAFGjWpDIAlh8b7u 4SGwqgkqTQ4on7v0GJQKpiYQq1+OoDdNh1ldG/xJf+m9rhX8XCgNs1BXgpVHVTUTod/o MfhKDPFFoT5CU+YY+82UW6p0mkhmNXuAoZY+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=qGyp8x+e8UdqbBJ6b2thg3V68sNPEQPsI+gEOHg/1NrH4eOWHers3cMWBlAS9D6Xi/ hLVXxmSAXpkjbY9zS3QLWQjgvd2h7K0eq2FEtClhpRc1ZFDhJcDB7xrV6VAL3/MsaM6I qltdOkLCgs35xTOM9LDGaqI4HVawlQTIGL1Jc= Received: by 10.227.142.68 with SMTP id p4mr10622425wbu.140.1296733992908; Thu, 03 Feb 2011 03:53:12 -0800 (PST) Received: from [192.168.0.30] (78-27-68-136.bb.dnainternet.fi [78.27.68.136]) by mx.google.com with ESMTPS id x1sm57147wbh.14.2011.02.03.03.53.11 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 03:53:12 -0800 (PST) Message-ID: <4D4A9728.20103@gmail.com> Date: Thu, 03 Feb 2011 13:53:12 +0200 From: pepe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20110203112145.W80258@maildrop.int.zabbadoz.net> In-Reply-To: <20110203112145.W80258@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipv6 problem 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, 03 Feb 2011 11:53:15 -0000 On 3.2.2011 13:23, Bjoern A. Zeeb wrote: > On Thu, 3 Feb 2011, pepe wrote: > >> I have 2001:14b8:10:402::/64 ipv6 from my isp and I cant get it working. >> Ifconfig should be ok: >> backup# ifconfig rl0 inet6 >> >> rl0: flags=8843 metric 0 mtu 1500 >> options=8 >> inet6 2001:14b8:10:402:2::1 prefixlen 64 >> >> default gateway is set to 2001:14b8:10:402::1. When I try to >> traceroute irc >> server for example >> I get this: >> >> traceroute6: Warning: irc.cc.tut.fi has multiple addresses; using >> 2001:708:310:4952:4320:5365:7276:6572 >> traceroute6 to irc.cc.tut.fi (2001:708:310:4952:4320:5365:7276:6572) from >> 2001:14b8:10:402:2::1, 64 hops max, 12 byte packets >> 1 2001:14b8:10:402:2::1 2026.908 ms !A 2999.587 ms !A 3000.423 ms !A >> >> So. Could this be problem in my configs or is this because of something >> wrong at the isp side? > > Not sure as you didn't show us your rc.conf configs and didn't give a > release. > > Try what happens if you do .. manually (rc.conf would do it for you > normally) -- if you are on FreeBSD 8.x: > > ifconfig rl0 -ifdisabled > Now I added ipv6 config to another server on same network. It's 8.1-RELEASE amd64. Exactly same problem, but ping6 between these server works fine: backup% ping6 2001:14b8:10:402:1::1 PING6(56=40+8+8 bytes) 2001:14b8:10:402:2::1 --> 2001:14b8:10:402:1::1 16 bytes from 2001:14b8:10:402:1::1, icmp_seq=0 hlim=64 time=0.356 ms 16 bytes from 2001:14b8:10:402:1::1, icmp_seq=1 hlim=64 time=0.163 ms traceroute6 doesn't: backup% traceroute6 2001:14b8:10:402:1::1 traceroute6 to 2001:14b8:10:402:1::1 (2001:14b8:10:402:1::1) from 2001:14b8:10:402:2::1, 64 hops max, 12 byte packets 1 * * * From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 11:56: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 A69CC1065670; Thu, 3 Feb 2011 11:56:01 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id E4E4B8FC15; Thu, 3 Feb 2011 11:56:00 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p13Btwir080588; Thu, 3 Feb 2011 17:55:58 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D4A97C9.9020007@rdtc.ru> Date: Thu, 03 Feb 2011 17:55:53 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mike Tancsa References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> <20110201185026.GB62007@glebius.int.ru> <4D4A38FD.7000607@rdtc.ru> <4D4A8FF6.2090602@sentex.net> In-Reply-To: <4D4A8FF6.2090602@sentex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: About "panic: bufwrite: buffer is not busy???" 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, 03 Feb 2011 11:56:01 -0000 On 03.02.2011 17:22, Mike Tancsa wrote: >>> E> Uptime: 8h3m51s >>> E> Dumping 4087 MB (3 chunks) >>> E> chunk 0: 1MB (150 pages) ... ok >>> E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? >>> E> cpuid = 3 >>> E> Uptime: 8h3m52s >>> E> Automatic reboot in 15 seconds - press a key on the console to abort >>> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't >>> dump core, but with this option we will have at least trace. >> >> I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. >> Has anyone a thought how to fix generation of crashdumps? > > But it generates the dump despite the error message > > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 00 > fault virtual address = 0x33b9fc > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc072df2f > stack pointer = 0x28:0xe94c2a44 > frame pointer = 0x28:0xe94c2a64 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1089 (mpd5) > trap number = 12 > panic: page fault > cpuid = 1 > KDB: stack backtrace: > #0 0xc0681b07 at kdb_backtrace+0x47 > #1 0xc0652d27 at panic+0x117 > #2 0xc08cd873 at trap_fatal+0x323 > #3 0xc08cdaf0 at trap_pfault+0x270 > #4 0xc08ce035 at trap+0x465 > #5 0xc08b4e6c at calltrap+0x6 > #6 0xc07358df at in_leavegroup_locked+0x4f > #7 0xc07320d1 at in_control+0x13d1 > #8 0xc06fb04a at ifioctl+0x1b4a > #9 0xc0698422 at soo_ioctl+0x612 > #10 0xc0690c90 at kern_ioctl+0x250 > #11 0xc0690e04 at ioctl+0x134 > #12 0xc068d82f at syscallenter+0x30f > #13 0xc08cdb44 at syscall+0x34 > #14 0xc08b4ed1 at Xint0x80_syscall+0x21 > Uptime: 1d4h20m49s > Physical memory: 3574 MB > Dumping 289 MB:panic: bufwrite: buffer is not busy??? > cpuid = 1 > 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 > Dump complete It does not generate dump for me. Perhaps, due to greater amount of RAM and/or amd64 differences. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 12:34: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 E0EC2106566B for ; Thu, 3 Feb 2011 12:34:28 +0000 (UTC) (envelope-from plaine@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 713428FC12 for ; Thu, 3 Feb 2011 12:34:28 +0000 (UTC) Received: by wwf26 with SMTP id 26so1064227wwf.31 for ; Thu, 03 Feb 2011 04:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YinSCil0FVFnVspfmg+Sn9sMBNYoN6rZHG7tE4xwrlM=; b=Q/hXFYdaTRKkusHPlIGOyFR/DN9j6eMAtxpHP/bWQJkZl8SoD+IUKtdSMorPLFfq9b 71sWhBr6P8iA8IVpltAfAUrvRhFNQDsrTt0rDm09qRrUMbyGGEf0qh8Zgo3Or13A6iIu z8LHqyQede+5EvJtDyAmAviQLXoBumLqbiGT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=e43tei9M1jE9ZyqfZr3MzbCt1qPm44m1hbXZ+yj1DwWg9jS/IhjOf0G8hdzEuecOTY bu/kEmzx2omtrTqhHo97NfpGXBmgK5D3K8bPFMZauydtTgqQg6jRnqp/m0miS18Agv9m Ji0bK4n6HjY/qDbiZ3bln9y9FFNmZv2AO14g0= Received: by 10.227.136.81 with SMTP id q17mr10695956wbt.129.1296736467327; Thu, 03 Feb 2011 04:34:27 -0800 (PST) Received: from [192.168.0.30] (78-27-68-136.bb.dnainternet.fi [78.27.68.136]) by mx.google.com with ESMTPS id x1sm83551wbh.20.2011.02.03.04.34.24 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 04:34:25 -0800 (PST) Message-ID: <4D4AA0D0.8020703@gmail.com> Date: Thu, 03 Feb 2011 14:34:24 +0200 From: pepe User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20110203112145.W80258@maildrop.int.zabbadoz.net> <4D4A945D.8@gmail.com> <20110203121008.D80258@maildrop.int.zabbadoz.net> In-Reply-To: <20110203121008.D80258@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipv6 problem 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, 03 Feb 2011 12:34:29 -0000 On 3.2.2011 14:13, Bjoern A. Zeeb wrote: > On Thu, 3 Feb 2011, pepe wrote: > >> On 3.2.2011 13:23, Bjoern A. Zeeb wrote: >>> On Thu, 3 Feb 2011, pepe wrote: >>> >>>> I have 2001:14b8:10:402::/64 ipv6 from my isp and I cant get it >>>> working. >>>> Ifconfig should be ok: >>>> backup# ifconfig rl0 inet6 >>>> >>>> rl0: flags=8843 metric 0 mtu >>>> 1500 >>>> options=8 >>>> inet6 2001:14b8:10:402:2::1 prefixlen 64 >>>> >>>> default gateway is set to 2001:14b8:10:402::1. When I try to >>>> traceroute irc >>>> server for example >>>> I get this: >>>> >>>> traceroute6: Warning: irc.cc.tut.fi has multiple addresses; using >>>> 2001:708:310:4952:4320:5365:7276:6572 >>>> traceroute6 to irc.cc.tut.fi (2001:708:310:4952:4320:5365:7276:6572) >>>> from >>>> 2001:14b8:10:402:2::1, 64 hops max, 12 byte packets >>>> 1 2001:14b8:10:402:2::1 2026.908 ms !A 2999.587 ms !A 3000.423 ms !A >>>> >>>> So. Could this be problem in my configs or is this because of something >>>> wrong at the isp side? >>> >>> Not sure as you didn't show us your rc.conf configs and didn't give a >>> release. >>> >>> Try what happens if you do .. manually (rc.conf would do it for you >>> normally) -- if you are on FreeBSD 8.x: >>> >>> ifconfig rl0 -ifdisabled >>> >> >> IPv6 configs in rc.conf: >> >> ipv6_enable="YES" >> ipv6_defaultrouter="2001:14b8:0010:0402::1" >> ipv6_network_interfaces="rl0" >> ifconfig_rl0_alias52="inet6 2001:14b8:0010:0402:2::1 prefixlen 64" > > That might work; try > > ipv6_ifconfig_rl0="2001:14b8:0010:0402:2::1 prefixlen 64" > > instead. > > Another thing you can do is: > > ping6 ff02::1%rl0 > > All hosts on the segment should reply with their link local address. > > /bz > I changed rc.conf to what you suggest, but it didn't help. I seems to be same with either one of those lines. output of that ping: backup% ping6 ff02::1%rl0 PING6(56=40+8+8 bytes) fe80::208:54ff:fe36:f25b%rl0 --> ff02::1%rl0 16 bytes from fe80::208:54ff:fe36:f25b%rl0, icmp_seq=0 hlim=64 time=0.141 ms 16 bytes from fe80::240:f4ff:fe76:d441%rl0, icmp_seq=0 hlim=64 time=0.294 ms(DUP!) 16 bytes from fe80::208:54ff:fe36:f25b%rl0, icmp_seq=1 hlim=64 time=0.054 ms 16 bytes from fe80::240:f4ff:fe76:d441%rl0, icmp_seq=1 hlim=64 time=0.179 ms(DUP!) 16 bytes from fe80::208:54ff:fe36:f25b%rl0, icmp_seq=2 hlim=64 time=0.053 ms 16 bytes from fe80::240:f4ff:fe76:d441%rl0, icmp_seq=2 hlim=64 time=0.169 ms(DUP!) 16 bytes from fe80::208:54ff:fe36:f25b%rl0, icmp_seq=3 hlim=64 time=0.041 ms 16 bytes from fe80::240:f4ff:fe76:d441%rl0, icmp_seq=3 hlim=64 time=0.158 ms(DUP!) ^C --- ff02::1%rl0 ping6 statistics --- 4 packets transmitted, 4 packets received, +4 duplicates, 0.0% packet loss round-trip min/avg/max/std-dev = 0.041/0.136/0.294/0.080 ms From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 13:25: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 49E001065674 for ; Thu, 3 Feb 2011 13:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id CF2118FC18 for ; Thu, 3 Feb 2011 13:25:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D554C41C6A7; Thu, 3 Feb 2011 14:25:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id HkJ7z1gDGsTy; Thu, 3 Feb 2011 14:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 567E441C679; Thu, 3 Feb 2011 14:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D07F94448F3; Thu, 3 Feb 2011 13:22:24 +0000 (UTC) Date: Thu, 3 Feb 2011 13:22:24 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: pepe In-Reply-To: <4D4AA0D0.8020703@gmail.com> Message-ID: <20110203131535.I80258@maildrop.int.zabbadoz.net> References: <20110203112145.W80258@maildrop.int.zabbadoz.net> <4D4A945D.8@gmail.com> <20110203121008.D80258@maildrop.int.zabbadoz.net> <4D4AA0D0.8020703@gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: ipv6 problem 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, 03 Feb 2011 13:25:07 -0000 On Thu, 3 Feb 2011, pepe wrote: >>> IPv6 configs in rc.conf: >>> >>> ipv6_enable="YES" >>> ipv6_defaultrouter="2001:14b8:0010:0402::1" >>> ipv6_network_interfaces="rl0" >>> ifconfig_rl0_alias52="inet6 2001:14b8:0010:0402:2::1 prefixlen 64" >> >> That might work; try >> >> ipv6_ifconfig_rl0="2001:14b8:0010:0402:2::1 prefixlen 64" >> >> instead. >> >> Another thing you can do is: >> >> ping6 ff02::1%rl0 >> >> All hosts on the segment should reply with their link local address. >> >> /bz >> > > I changed rc.conf to what you suggest, but it didn't help. I seems to be same > with either one of those lines. It's a freebsd 7 and you didn't have ipv6_enable=YES on your last boot, right? I am asking because I didn't see a link-local address on your ifconfig output. Do you have one there? I guess you do as otherwise the following might not have worked: > output of that ping: > backup% ping6 ff02::1%rl0 > PING6(56=40+8+8 bytes) fe80::208:54ff:fe36:f25b%rl0 --> ff02::1%rl0 > 16 bytes from fe80::208:54ff:fe36:f25b%rl0, icmp_seq=0 hlim=64 time=0.141 ms > 16 bytes from fe80::240:f4ff:fe76:d441%rl0, icmp_seq=0 hlim=64 time=0.294 .. Let's assume that's your box and your other box? You should be able to check that, btw. So can you try ping6 ff02::2%rl0 which should make all routers reply and see? /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 13:32: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 41E161065673 for ; Thu, 3 Feb 2011 13:32:26 +0000 (UTC) (envelope-from plaine@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 C50128FC15 for ; Thu, 3 Feb 2011 13:32:25 +0000 (UTC) Received: by wwi17 with SMTP id 17so7241171wwi.1 for ; Thu, 03 Feb 2011 05:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z2WeOw2p56HAOFyLtV5mSs17mt58ROOInAqPRiIBLqQ=; b=RpvL6p2c68emiWYr6AaiHKZYX0yETnDjzz4/nlf+JckzGCDn1JkjW1R3TBiv64cSW0 FoUcoaI6p47gg6QNhWvFe/3QJRZZ0UWPbRdeWf6XC1utQT3U9xxcHG/YPcqWyeXIxtN4 KouIWMEGqirmYX8TloGDwF6P0nJnjgv+HG2Rs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=HqmISzlhlQEBBmJxciTFSPxS1J0elt+tnqgtv7s94IYj+Eq0KHxJUn2mXEKm3zzzrb E+TWOUxANq9A+EbIK2WRSphiEo8Fw9/DGC1xh9VPaSJk5fcUZXKFo1AJkcol3s2DINw5 6CxToWhCO1V5WOpATOsjDKSraIQ/IbktaXh30= Received: by 10.227.146.85 with SMTP id g21mr10110447wbv.113.1296739944594; Thu, 03 Feb 2011 05:32:24 -0800 (PST) Received: from [213.141.125.204] (judaspriest.silakka.biz [213.141.125.204]) by mx.google.com with ESMTPS id y29sm596918wbd.10.2011.02.03.05.32.22 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Feb 2011 05:32:23 -0800 (PST) Message-ID: <4D4AAE7E.7010300@gmail.com> Date: Thu, 03 Feb 2011 15:32:46 +0200 From: pepe 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: freebsd-net@freebsd.org References: <20110203112145.W80258@maildrop.int.zabbadoz.net> <4D4A945D.8@gmail.com> <20110203121008.D80258@maildrop.int.zabbadoz.net> <4D4AA0D0.8020703@gmail.com> <20110203131535.I80258@maildrop.int.zabbadoz.net> In-Reply-To: <20110203131535.I80258@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipv6 problem 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, 03 Feb 2011 13:32:26 -0000 On 3.2.2011 15:22, Bjoern A. Zeeb wrote: > On Thu, 3 Feb 2011, pepe wrote: > >>>> IPv6 configs in rc.conf: >>>> >>>> ipv6_enable="YES" >>>> ipv6_defaultrouter="2001:14b8:0010:0402::1" >>>> ipv6_network_interfaces="rl0" >>>> ifconfig_rl0_alias52="inet6 2001:14b8:0010:0402:2::1 prefixlen 64" >>> >>> That might work; try >>> >>> ipv6_ifconfig_rl0="2001:14b8:0010:0402:2::1 prefixlen 64" >>> >>> instead. >>> >>> Another thing you can do is: >>> >>> ping6 ff02::1%rl0 >>> >>> All hosts on the segment should reply with their link local address. >>> >>> /bz >>> >> >> I changed rc.conf to what you suggest, but it didn't help. I seems to >> be same with either one of those lines. > > It's a freebsd 7 and you didn't have ipv6_enable=YES on your last boot, > right? I am asking because I didn't see a link-local address on your > ifconfig > output. Do you have one there? Yes ipv6_enable was there... > I guess you do as otherwise the following might not have worked: > >> output of that ping: >> backup% ping6 ff02::1%rl0 >> PING6(56=40+8+8 bytes) fe80::208:54ff:fe36:f25b%rl0 --> ff02::1%rl0 >> 16 bytes from fe80::208:54ff:fe36:f25b%rl0, icmp_seq=0 hlim=64 >> time=0.141 ms >> 16 bytes from fe80::240:f4ff:fe76:d441%rl0, icmp_seq=0 hlim=64 >> time=0.294 .. > > Let's assume that's your box and your other box? You should be able > to check that, btw. > > So can you try ping6 ff02::2%rl0 which should make all routers reply > and see? That doesn't work. 100% packet loss. From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 13:40: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 14EB9106564A for ; Thu, 3 Feb 2011 13:40:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 263BD8FC08 for ; Thu, 3 Feb 2011 13:40:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7D3A741C7A6; Thu, 3 Feb 2011 14:40:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id fzgumi5M8-bg; Thu, 3 Feb 2011 14:40:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E3BAA41C7A5; Thu, 3 Feb 2011 14:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id C1F504448F3; Thu, 3 Feb 2011 13:38:31 +0000 (UTC) Date: Thu, 3 Feb 2011 13:38:31 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: pepe In-Reply-To: <4D4AAE7E.7010300@gmail.com> Message-ID: <20110203133729.T80258@maildrop.int.zabbadoz.net> References: <20110203112145.W80258@maildrop.int.zabbadoz.net> <4D4A945D.8@gmail.com> <20110203121008.D80258@maildrop.int.zabbadoz.net> <4D4AA0D0.8020703@gmail.com> <20110203131535.I80258@maildrop.int.zabbadoz.net> <4D4AAE7E.7010300@gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: ipv6 problem 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, 03 Feb 2011 13:40:09 -0000 On Thu, 3 Feb 2011, pepe wrote: > On 3.2.2011 15:22, Bjoern A. Zeeb wrote: >> On Thu, 3 Feb 2011, pepe wrote: >> >>>>> IPv6 configs in rc.conf: >>>>> >>>>> ipv6_enable="YES" >>>>> ipv6_defaultrouter="2001:14b8:0010:0402::1" >>>>> ipv6_network_interfaces="rl0" >>>>> ifconfig_rl0_alias52="inet6 2001:14b8:0010:0402:2::1 prefixlen 64" >>>> >>>> That might work; try >>>> >>>> ipv6_ifconfig_rl0="2001:14b8:0010:0402:2::1 prefixlen 64" >>>> >>>> instead. >>>> >>>> Another thing you can do is: >>>> >>>> ping6 ff02::1%rl0 >>>> >>>> All hosts on the segment should reply with their link local address. >>>> >>>> /bz >>>> >>> >>> I changed rc.conf to what you suggest, but it didn't help. I seems to >>> be same with either one of those lines. >> >> It's a freebsd 7 and you didn't have ipv6_enable=YES on your last boot, >> right? I am asking because I didn't see a link-local address on your >> ifconfig >> output. Do you have one there? > > Yes ipv6_enable was there... > >> I guess you do as otherwise the following might not have worked: >> >>> output of that ping: >>> backup% ping6 ff02::1%rl0 >>> PING6(56=40+8+8 bytes) fe80::208:54ff:fe36:f25b%rl0 --> ff02::1%rl0 >>> 16 bytes from fe80::208:54ff:fe36:f25b%rl0, icmp_seq=0 hlim=64 >>> time=0.141 ms >>> 16 bytes from fe80::240:f4ff:fe76:d441%rl0, icmp_seq=0 hlim=64 >>> time=0.294 .. >> >> Let's assume that's your box and your other box? You should be able >> to check that, btw. >> >> So can you try ping6 ff02::2%rl0 which should make all routers reply >> and see? > > That doesn't work. 100% packet loss. Sounds like no routers on the segement. Talk to DNA to confirm they configuted it properly. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 13:59: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 A76D8106566B for ; Thu, 3 Feb 2011 13:59:01 +0000 (UTC) (envelope-from jmgm@iki.fi) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by mx1.freebsd.org (Postfix) with ESMTP id 25CA98FC1B for ; Thu, 3 Feb 2011 13:59:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 4CB854E6D7; Thu, 3 Feb 2011 15:58:59 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9156hR0tcnBz; Thu, 3 Feb 2011 15:58:58 +0200 (EET) Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id B03C64E6BC; Thu, 3 Feb 2011 15:58:58 +0200 (EET) Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id 7A02E1AE1C5; Thu, 3 Feb 2011 15:58:58 +0200 (EET) Received: from esealmw967.eemea.ericsson.se (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id 463F91ADE63; Thu, 3 Feb 2011 15:58:58 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jan Melen In-Reply-To: <4D4AAE7E.7010300@gmail.com> Date: Thu, 3 Feb 2011 15:58:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4637C230-03CF-4C70-A033-22C58F57A610@iki.fi> References: <20110203112145.W80258@maildrop.int.zabbadoz.net> <4D4A945D.8@gmail.com> <20110203121008.D80258@maildrop.int.zabbadoz.net> <4D4AA0D0.8020703@gmail.com> <20110203131535.I80258@maildrop.int.zabbadoz.net> <4D4AAE7E.7010300@gmail.com> To: pepe X-Mailer: Apple Mail (2.1082) X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org Subject: Re: ipv6 problem 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, 03 Feb 2011 13:59:01 -0000 Hi, On Feb 3, 2011, at 3:32 PM, pepe wrote: > On 3.2.2011 15:22, Bjoern A. Zeeb wrote: >> On Thu, 3 Feb 2011, pepe wrote: >>=20 >>>>> IPv6 configs in rc.conf: >>>>>=20 >>>>> ipv6_enable=3D"YES" >>>>> ipv6_defaultrouter=3D"2001:14b8:0010:0402::1" >>>>> ipv6_network_interfaces=3D"rl0" >>>>> ifconfig_rl0_alias52=3D"inet6 2001:14b8:0010:0402:2::1 prefixlen = 64" >>>>=20 >>>> That might work; try >>>>=20 >>>> ipv6_ifconfig_rl0=3D"2001:14b8:0010:0402:2::1 prefixlen 64" >>>>=20 >>>> instead. >>>>=20 >>>> Another thing you can do is: >>>>=20 >>>> ping6 ff02::1%rl0 >>>>=20 >>>> All hosts on the segment should reply with their link local = address. >>>>=20 >>>> /bz >>>>=20 >>>=20 >>> I changed rc.conf to what you suggest, but it didn't help. I seems = to >>> be same with either one of those lines. >>=20 >> It's a freebsd 7 and you didn't have ipv6_enable=3DYES on your last = boot, >> right? I am asking because I didn't see a link-local address on your >> ifconfig >> output. Do you have one there? >=20 > Yes ipv6_enable was there... >=20 >> I guess you do as otherwise the following might not have worked: >>=20 >>> output of that ping: >>> backup% ping6 ff02::1%rl0 >>> PING6(56=3D40+8+8 bytes) fe80::208:54ff:fe36:f25b%rl0 --> = ff02::1%rl0 >>> 16 bytes from fe80::208:54ff:fe36:f25b%rl0, icmp_seq=3D0 hlim=3D64 >>> time=3D0.141 ms >>> 16 bytes from fe80::240:f4ff:fe76:d441%rl0, icmp_seq=3D0 hlim=3D64 >>> time=3D0.294 .. >>=20 >> Let's assume that's your box and your other box? You should be able >> to check that, btw. >>=20 >> So can you try ping6 ff02::2%rl0 which should make all routers reply >> and see? >=20 > That doesn't work. 100% packet loss. If you haven't figured out already that means that your ISP router is = not answering to all routers multicast address which could mean that the = other end has not been configured as a router or that there is no IPv6 = on the other side (I would guess that it is the latter)? Ask your ISP to = check their configs and run e.g. tcpdump? If you ping the default = gateway with tcpdump you should at least see neighbour solicitation = going out and neighbour advertisement coming in with the default gateway = address to your machine if the ISP:s interface has the address. Regards, Jan From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 18:30: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 304E310656D0 for ; Thu, 3 Feb 2011 18:30:16 +0000 (UTC) (envelope-from david.somayajulu@qlogic.com) Received: from VA3EHSOBE008.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by mx1.freebsd.org (Postfix) with ESMTP id C75808FC14 for ; Thu, 3 Feb 2011 18:30:15 +0000 (UTC) Received: from mail154-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.8; Thu, 3 Feb 2011 18:15:12 +0000 Received: from mail154-va3 (localhost.localdomain [127.0.0.1]) by mail154-va3-R.bigfish.com (Postfix) with ESMTP id 3B45BCF06EB for ; Thu, 3 Feb 2011 18:15:12 +0000 (UTC) X-SpamScore: -12 X-BigFish: VPS-12(zz14ffOzz1202hzz8275bh8275dh186Mz2fh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:avexcashub1.qlogic.com; RD:avexcashub1.qlogic.com; EFVD:NLI Received: from mail154-va3 (localhost.localdomain [127.0.0.1]) by mail154-va3 (MessageSwitch) id 1296756911605813_31416; Thu, 3 Feb 2011 18:15:11 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.241]) by mail154-va3.bigfish.com (Postfix) with ESMTP id 91821F9004E for ; Thu, 3 Feb 2011 18:15:11 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.61) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 3 Feb 2011 18:15:10 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub1.qlogic.org ([::1]) with mapi; Thu, 3 Feb 2011 10:15:09 -0800 From: David Somayajulu To: "freebsd-net@freebsd.org" Date: Thu, 3 Feb 2011 10:15:08 -0800 Thread-Topic: Ethernet Drivers: Question on Sending Received Packets to the FreeBSD Network Stack Thread-Index: AcvDzVfmWheTpRb6QzKV2V2AFNGtawAAOCdg Message-ID: <75E1A2A7D185F841A975979B0906BBA6774DD4D905@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Ethernet Drivers: Question on Sending Received Packets to the FreeBSD Network Stack 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, 03 Feb 2011 18:30:16 -0000 Hi All, While sending the Received Ethernet Frames (non - LRO case) to the FreeBSD = Network Stack via (struct ifnet *)->if_input((struct ifnet *), (struct *mbuf)); Is it possible to send multiple Ethernet Frames in a single invocation of t= he above callback function? In other words should (struct *mbuf) above always correspond to a single Et= hernet Frame? I am not sure if I missed something, but I gathered from a qu= ick perusal of ether_input() in net/if_ethersubr.c, that only ONE Ethernet = Frame may be sent per callback. Thanks David S. ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 20:38: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 8D8F61065694; Thu, 3 Feb 2011 20:38:30 +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 2C7B78FC0C; Thu, 3 Feb 2011 20:38:30 +0000 (UTC) Received: by vws9 with SMTP id 9so958598vws.13 for ; Thu, 03 Feb 2011 12:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LpaXWXQXK8xXNTdYqsmqpa/3WSNQuOnivW37d8W4XrY=; b=MOdmPdSK2QG1LNqUn0EOMq9GRf+aqDzx9lFAK+EyqktOXXW/qGF+eqtitcYhsv+2Sh Vpx2WDKFabzNLAkbAMz5jRk8mi0+ymhBGMNG8a0KMk3DtzBrmel/v6qedANRQrr8qQoT 7o/r8FDBzJDd8DPs+eY2epPIjwPkOVluSFArw= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=kLIFr2xn2sYYkZTWeo4jTyXOH06kZW1JbmYOvPGUxFguxRxZHO1QuNP0bReCpqi7Jk /9kJE5fhdKaGsA6Ev5vaXrLw4hndeRt2cMju9FW/49gdPpipjHXBXDYVvySsQEJ2E3wq PGqV/dgwKKQwv7X/Oaj/FLGJA8WfkzoCyywS4= MIME-Version: 1.0 Received: by 10.220.96.202 with SMTP id i10mr2804966vcn.191.1296765509439; Thu, 03 Feb 2011 12:38:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.220.198.203 with HTTP; Thu, 3 Feb 2011 12:38:29 -0800 (PST) In-Reply-To: <201102032030.p13KUH9B057585@svn.freebsd.org> References: <201102032030.p13KUH9B057585@svn.freebsd.org> Date: Fri, 4 Feb 2011 04:38:29 +0800 X-Google-Sender-Auth: nYmd4QXZUADAyxF6GzgB3GfyXNI Message-ID: From: Adrian Chadd To: freebsd-mobile@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net Subject: Re: svn commit: r218240 - head/sys/dev/ath 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, 03 Feb 2011 20:38:30 -0000 Hi all, This commit may have broken TX on if_ath. I'd appreciate it if people tested things out and got back to me. In particular, I'd like to make sure that the legacy rates TX with the short and long preamble correctly. Thanks, Adrian On 4 February 2011 04:30, Adrian Chadd wrote: > Author: adrian > Date: Thu Feb =A03 20:30:17 2011 > New Revision: 218240 > URL: http://svn.freebsd.org/changeset/base/218240 > > Log: > =A0Modify the TX path to set and use the 11n rate scenario bits. > > =A0This isn't strictly required to TX (at least non-agg and non-HT40, > =A0non-short-GI) frames; but as it needs to be done anyway, just get > =A0it done. > > =A0Linux ath9k uses the rate scenario style path for -all- packets, > =A0legacy or otherwise. This code does much the same. > > =A0Beacon TX still uses the legacy, non-rate-scenario TX descriptor > =A0setup. Ath9k also does this. > > =A0This 11n rate scenario path is only called for chips in the AR5416 > =A0HAL; legacy chips use the previous interface for TX'ing. > > Modified: > =A0head/sys/dev/ath/if_ath_tx.c > > Modified: head/sys/dev/ath/if_ath_tx.c > =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 > --- head/sys/dev/ath/if_ath_tx.c =A0 =A0 =A0 =A0Thu Feb =A03 20:27:20 201= 1 =A0 =A0 =A0 =A0(r218239) > +++ head/sys/dev/ath/if_ath_tx.c =A0 =A0 =A0 =A0Thu Feb =A03 20:30:17 201= 1 =A0 =A0 =A0 =A0(r218240) > @@ -97,6 +97,7 @@ __FBSDID("$FreeBSD$"); > > =A0#include > =A0#include > +#include > > =A0/* > =A0* Whether to use the 11n rate scenario functions or not > @@ -482,6 +483,10 @@ ath_tx_start(struct ath_softc *sc, struc > =A0 =A0 =A0 =A0HAL_BOOL shortPreamble; > =A0 =A0 =A0 =A0struct ath_node *an; > =A0 =A0 =A0 =A0u_int pri; > + =A0 =A0 =A0 uint8_t try[4], rate[4]; > + > + =A0 =A0 =A0 bzero(try, sizeof(try)); > + =A0 =A0 =A0 bzero(rate, sizeof(rate)); > > =A0 =A0 =A0 =A0wh =3D mtod(m0, struct ieee80211_frame *); > =A0 =A0 =A0 =A0iswep =3D wh->i_fc[1] & IEEE80211_FC1_WEP; > @@ -768,10 +773,17 @@ ath_tx_start(struct ath_softc *sc, struc > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0txq->axq_intrcnt =3D 0; > =A0 =A0 =A0 =A0} > > + =A0 =A0 =A0 if (ath_tx_is_11n(sc)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate[0] =3D rix; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 try[0] =3D try0; > + =A0 =A0 =A0 } > + > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Formulate first tx descriptor with tx controls. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0/* XXX check return value? */ > + =A0 =A0 =A0 /* XXX is this ok to call for 11n descriptors? */ > + =A0 =A0 =A0 /* XXX or should it go through the first, next, last 11n ca= lls? */ > =A0 =A0 =A0 =A0ath_hal_setuptxdesc(ah, ds > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0, pktlen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*= packet length */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0, hdrlen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/*= header length */ > @@ -792,8 +804,16 @@ ath_tx_start(struct ath_softc *sc, struc > =A0 =A0 =A0 =A0 * when the hardware supports multi-rate retry and > =A0 =A0 =A0 =A0 * we don't use it. > =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 if (ismrr) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ath_rate_setupxtxdesc(sc, an, ds, shortPrea= mble, rix); > + =A0 =A0 =A0 =A0if (ismrr) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (ath_tx_is_11n(sc)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ath_rate_getxtxrates(sc,= an, rix, rate, try); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ath_rate_setupxtxdesc(sc= , an, ds, shortPreamble, rix); > + =A0 =A0 =A0 =A0} > + > + =A0 =A0 =A0 =A0if (ath_tx_is_11n(sc)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ath_buf_set_rate(sc, ni, bf, pktlen, fla= gs, ctsrate, rate, try); > + =A0 =A0 =A0 =A0} > > =A0 =A0 =A0 =A0ath_tx_handoff(sc, txq, bf); > =A0 =A0 =A0 =A0return 0; > @@ -817,6 +837,10 @@ ath_tx_raw_start(struct ath_softc *sc, s > =A0 =A0 =A0 =A0const HAL_RATE_TABLE *rt; > =A0 =A0 =A0 =A0struct ath_desc *ds; > =A0 =A0 =A0 =A0u_int pri; > + =A0 =A0 =A0 uint8_t try[4], rate[4]; > + > + =A0 =A0 =A0 bzero(try, sizeof(try)); > + =A0 =A0 =A0 bzero(rate, sizeof(rate)); > > =A0 =A0 =A0 =A0wh =3D mtod(m0, struct ieee80211_frame *); > =A0 =A0 =A0 =A0ismcast =3D IEEE80211_IS_MULTICAST(wh->i_addr1); > @@ -925,30 +949,56 @@ ath_tx_raw_start(struct ath_softc *sc, s > =A0 =A0 =A0 =A0); > =A0 =A0 =A0 =A0bf->bf_txflags =3D flags; > > - =A0 =A0 =A0 if (ismrr) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 rix =3D ath_tx_findrix(sc, params->ibp_rate= 1); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate1 =3D rt->info[rix].rateCode; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (params->ibp_flags & IEEE80211_BPF_SHORT= PRE) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate1 |=3D rt->info[rix].sh= ortPreamble; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (params->ibp_try2) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rix =3D ath_tx_findrix(sc, = params->ibp_rate2); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate2 =3D rt->info[rix].rat= eCode; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (params->ibp_flags & IEE= E80211_BPF_SHORTPRE) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate2 |=3D = rt->info[rix].shortPreamble; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate2 =3D 0; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (params->ibp_try3) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rix =3D ath_tx_findrix(sc, = params->ibp_rate3); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate3 =3D rt->info[rix].rat= eCode; > + =A0 =A0 =A0 if (ath_tx_is_11n(sc)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate[0] =3D ath_tx_findrix(sc, params->ibp_= rate0); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 try[0] =3D params->ibp_try0; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ismrr) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Remember, rate[] is actu= ally an array of rix's -adrian */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate[0] =3D ath_tx_findrix(= sc, params->ibp_rate0); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate[1] =3D ath_tx_findrix(= sc, params->ibp_rate1); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate[2] =3D ath_tx_findrix(= sc, params->ibp_rate2); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate[3] =3D ath_tx_findrix(= sc, params->ibp_rate3); > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 try[0] =3D params->ibp_try0= ; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 try[1] =3D params->ibp_try1= ; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 try[2] =3D params->ibp_try2= ; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 try[3] =3D params->ibp_try3= ; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 } else { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ismrr) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rix =3D ath_tx_findrix(sc, = params->ibp_rate1); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate1 =3D rt->info[rix].rat= eCode; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (params->ibp_flags & IE= EE80211_BPF_SHORTPRE) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate3 |=3D = rt->info[rix].shortPreamble; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate3 =3D 0; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ath_hal_setupxtxdesc(ah, ds > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 , rate1, params->ibp_try1 = =A0 =A0 =A0 /* series 1 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 , rate2, params->ibp_try2 = =A0 =A0 =A0 /* series 2 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 , rate3, params->ibp_try3 = =A0 =A0 =A0 /* series 3 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate1 |=3D = rt->info[rix].shortPreamble; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (params->ibp_try2) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rix =3D ath= _tx_findrix(sc, params->ibp_rate2); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate2 =3D r= t->info[rix].rateCode; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (params-= >ibp_flags & IEEE80211_BPF_SHORTPRE) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 rate2 |=3D rt->info[rix].shortPreamble; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate2 =3D 0= ; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (params->ibp_try3) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rix =3D ath= _tx_findrix(sc, params->ibp_rate3); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate3 =3D r= t->info[rix].rateCode; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (params-= >ibp_flags & IEEE80211_BPF_SHORTPRE) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 rate3 |=3D rt->info[rix].shortPreamble; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rate3 =3D 0= ; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ath_hal_setupxtxdesc(ah, ds > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 , rate1, pa= rams->ibp_try1 =A0 =A0 =A0 /* series 1 */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 , rate2, pa= rams->ibp_try2 =A0 =A0 =A0 /* series 2 */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 , rate3, pa= rams->ibp_try3 =A0 =A0 =A0 /* series 3 */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 } > + > + =A0 =A0 =A0 if (ath_tx_is_11n(sc)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* notice that rix doesn't include any of= the "magic" flags txrate > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* does for communicating "other stuff" t= o the HAL. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ath_buf_set_rate(sc, ni, bf, pktlen, flags,= ctsrate, rate, try); > =A0 =A0 =A0 =A0} > > =A0 =A0 =A0 =A0/* NB: no buffered multicast in power save support */ > From owner-freebsd-net@FreeBSD.ORG Thu Feb 3 22:04: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 C9ADB1065672; Thu, 3 Feb 2011 22:04:16 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1E08FC1C; Thu, 3 Feb 2011 22:04:16 +0000 (UTC) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id p13Lre2A000511; Thu, 3 Feb 2011 16:53:40 -0500 Received: from dieterbsd@engineer.com by imo-ma03.mx.aol.com (mail_out_v42.9.) id n.eb6.64b9962 (44667); Thu, 3 Feb 2011 16:53:37 -0500 (EST) Received: from smtprly-me01.mx.aol.com (smtprly-me01.mx.aol.com [64.12.95.102]) by cia-mc01.mx.aol.com (v129.8) with ESMTP id MAILCIAMC016-b2944d4b23dd35d; Thu, 03 Feb 2011 16:53:36 -0500 Received: from web-mmc-d01 (web-mmc-d01.sim.aol.com [205.188.103.67]) by smtprly-me01.mx.aol.com (v129.8) with ESMTP id MAILSMTPRLYME014-b2944d4b23dd35d; Thu, 03 Feb 2011 16:53:33 -0500 To: bug-followup@FreeBSD.org Content-Transfer-Encoding: quoted-printable Date: Thu, 03 Feb 2011 16:53:32 -0500 X-AOL-IP: 67.206.163.54 X-MB-Message-Source: WebUI Received: from 67.206.163.54 by web-mmc-d01.sysops.aol.com (205.188.103.67) with HTTP (WebMailUI); Thu, 03 Feb 2011 16:53:32 -0500 MIME-Version: 1.0 From: dieterbsd@engineer.com X-MB-Message-Type: User Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailer: Mail.com Webmail 33189-STANDARD Message-Id: <8CD9203EF6F6EE0-1760-B81@web-mmc-d01.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: dieterbsd@engineer.com Cc: freebsd-net@freebsd.org, freebsd@sopwith.solgatos.com, freebsd-firewire@freebsd.org, freebsd-drivers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be lost 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, 03 Feb 2011 22:04:16 -0000 New data: USB causes the same problem that firewire does. FreeBSD 8.0 amd64 nfe0: port 0xb400-0xb407=20 mem 0xfebf9000-0xfebf9fff irq 23 at device 10.0 on pci0 bge0: mem 0xfe4f0000-0xfe4fffff irq 19 at device 0.0 on pci5 fwohci1: mem 0xfdeff000-0xfdefffff irq 19 at device=20 8.0 on pci2 ehci0: mem 0xfebfe000-0xfebfe0ff=20 irq 22 at device 2.1 on pci0 Plugging in a USB_to_RS-232 bridge generates: ugen0.2: at usbus0 uplcom0: on usbus0 And networking is locked out for too long, and data is lost. (The node=20 sending data via Ethernet has too small a transmit buffer, but is a closed source=20 closed hardware black box and cannot be fixed. Once data is lost it is lost forever,=20 it cannot be recreated, so this is very bad.) The FreeBSD box receiving data has a=20 very large receive buffer, but if another device driver locks out networking it=20 doesn't help. Changing the printf(9)s to log(9)s fixes the problem, but this is not a=20 good workaround, there are LOTS of printfs in the kernel, I keep hitting new ones. =20 Printf(9) alone isn't the problem, adding printfs to chown(2) does not cause the problem, but=20 printfs from device drivers do. (usb, firewire, ...) My theory is there is a locking conflict. Here is lock profiling data for USB_RS-232 bridge being plugged in=20 printfs locking out networking: debug.lock.prof.enable: 0 debug.lock.prof.reset: 0 debug.lock.prof.stats: max wait_max total wait_total count avg wait_avg=20 cnt_hold cnt_lock name 251240 0 499982 0 303 1650 0 0= =20 0 /usr/src/sys/dev/usb/usb_request.c:322 (sx:0123456789ABCDEF -=20 USB device SX lock) 104255 0 110429 0 2 55214 0 0= =20 0 /usr/src/sys/dev/usb/usb_device.c:2459 (sx:123456789ABCDEF - USB= =20 config SX lock) 104217 0 29670949 0 47087 630 0 0= =20 0 /usr/src/sys/kern/uipc_sockbuf.c:148 (sx:so_rcv_sx) =20 <---------<<<< 101962 0 103089 0 27 3818 0 0= =20 0 /usr/src/sys/kern/kern_condvar.c:145 (sleep mutex:Giant) 51071 0 81088 0 3 27029 0 0= =20 0 /usr/src/sys/kern/kern_cons.c:422 (spin mutex:cnputs_mtx) 23049 0 31351 0 2 15675 0 0= =20 0 /usr/src/sys/kern/vfs_syscalls.c:3508 (lockmgr:ufs) 12408 0 978544 0 971 1007 0 0= =20 0 /usr/src/sys/kern/vfs_vnops.c:604 (lockmgr:ufs) 11466 0 744372 0 11567 64 0 0= =20 0 /usr/src/sys/kern/vfs_bio.c:2559 (lockmgr:bufwait) 11141 0 501155 0 3850 130 0 0= =20 0 /usr/src/sys/kern/vfs_bio.c:1835 (lockmgr:bufwait) 6115 0 61720 0 26 2373 0 0= =20 0 /usr/src/sys/dev/usb/usb_request.c:322 (sx:123456789ABCDEF - USB= =20 device SX lock) 5551 0 16749 0 19 881 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:1693 (lockmgr:syncer) 3043 0 3749 0 6 624 0 0= =20 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1321 (sleep mutex:struct mount= =20 mtx) 2333 0 9901 0 36 275 0 0= =20 0 /usr/src/sys/kern/vfs_mount.c:2231 (sleep mutex:struct mount mtx) 2055 0 9462 0 100 94 0 0= =20 0 /usr/src/sys/kern/subr_hints.c:117 (sleep mutex:kernel=20 environment) 1649 0 79272 0 3846 20 0 0= =20 0 /usr/src/sys/kern/vfs_bio.c:2963 (sleep mutex:vm object) 1636 0 36196 0 15515 2 0 0= =20 0 /usr/src/sys/vm/vm_page.c:1052 (sleep mutex:vm page queue free=20 mutex) 1205 0 55601 0 15411 3 0 0= =20 0 /usr/src/sys/kern/vfs_bio.c:2545 (sleep mutex:bufobj interlock) 1076 0 1076 0 1 1076 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:1693 (lockmgr:ufs) 1069 0 31117 0 30 1037 0 0= =20 0 /usr/src/sys/kern/kern_mutex.c:147 (sleep mutex:nfe0) 848 0 3752 0 1359 2 0 0= =20 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1297 (sleep mutex:vnode=20 interlock) 754 0 10016 0 3846 2 0 0= =20 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:4274 (sleep mutex:Softdep=20 Lock) 739 0 2463 0 4 615 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:1693 (lockmgr:devfs) 540 0 3370 0 1365 2 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:3179 (sleep mutex:vnode interlock) 525 0 80852 0 160 505 0 0= =20 0 /usr/src/sys/dev/uart/uart_cpu.h:92 (spin mutex:uart_hwmtx) 512 0 2065 0 23 89 0 0= =20 0 /usr/src/sys/kern/vfs_default.c:599 (lockmgr:bufwait) 487 0 97058 0 481 201 0 0= =20 0 /usr/src/sys/vm/vm_pager.c:311 (lockmgr:bufwait) 467 0 2069 0 12 172 0 0= =20 0 /usr/src/sys/dev/usb/usb_busdma.c:547 (sleep mutex:uplcom) 455 0 2978 0 18 165 0 0= =20 0 /usr/src/sys/dev/usb/usb_transfer.c:286 (sleep mutex:uplcom) 423 0 727 0 2 363 0 0= =20 0 /usr/src/sys/vm/uma_core.c:1565 (sleep mutex:UMA lock) 367 0 230166 0 47087 4 0 0= =20 0 /usr/src/sys/netinet/tcp_usrreq.c:708 (rw:tcpinp) 358 0 1387 0 11 126 0 0= =20 0 /usr/src/sys/kern/kern_synch.c:241 (sleep mutex:Giant) 339 0 72085 0 46119 1 0 0= =20 0 /usr/src/sys/kern/kern_mutex.c:147 (sleep mutex:so_rcv) 332 0 225434 0 93206 2 0 0= =20 0 /usr/src/sys/kern/uipc_socket.c:1441 (sleep mutex:so_rcv) 332 0 19529 0 11551 1 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:1927 (sleep mutex:bufobj interlock) 331 0 162523 0 94887 1 0 0= =20 0 /usr/src/sys/netinet/tcp_output.c:280 (sleep mutex:so_snd) 330 0 73512 0 47087 1 0 0= =20 0 /usr/src/sys/kern/uipc_socket.c:1843 (sleep mutex:so_rcv) 329 0 88069 0 47771 1 0 0= =20 0 /usr/src/sys/kern/uipc_socket.c:1687 (sleep mutex:so_rcv) 329 0 348 0 12 29 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:1955 (sleep mutex:Syncer mtx) 320 0 66185 0 3353 19 0 0= =20 0 /usr/src/sys/kern/vfs_cluster.c:868 (lockmgr:bufwait) 303 0 7410 0 4360 1 0 0= =20 0 /usr/src/sys/kern/vfs_bio.c:3944 (sleep mutex:bufobj interlock) debug.lock.prof.rejected: 0 debug.lock.prof.skipcount: 0 debug.lock.prof.skipspin: 0 Here is lock profiling data for firewire bus reset printfs locking out=20 Ethernet: max wait_max total wait_total count avg wait_avg=20 cnt_hold cnt_lock name 373345 0 397495 0 643 618 0 0= =20 0 /usr/src/sys/kern/vfs_lookup.c:497 (lockmgr:ufs) 373325 0 390815 0 3140 124 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:2218 (sleep mutex:vnode interlock) 359514 0 32199808 0 45582 706 0 0= =20 0 /usr/src/sys/kern/uipc_sockbuf.c:148 (sx:so_rcv_sx) =20 <---------<<<< 63827 320 746196 740 70067 10 0 0= =20 4 /usr/src/sys/dev/firewire/fwohci.c:2107 (sleep mutex:firewire) 49927 0 165929 0 8 20741 0 0= =20 0 /usr/src/sys/kern/vfs_syscalls.c:3508 (lockmgr:ufs) 33358 0 1707461 0 1106 1543 0 0= =20 0 /usr/src/sys/kern/vfs_vnops.c:604 (lockmgr:ufs) 30294 0 401224 0 2641 151 0 0= =20 0 /usr/src/sys/vm/vm_map.c:3526 (sx:user map) 28432 0 934681 0 74 12630 0 0= =20 0 /usr/src/sys/kern/kern_cons.c:422 (spin mutex:cnputs_mtx) 28296 0 66892 0 2641 25 0 0= =20 0 /usr/src/sys/vm/vm_fault.c:297 (sleep mutex:vm object) 25020 0 26667 0 45 592 0 0= =20 0 /usr/src/sys/kern/kern_exit.c:825 (sx:proctree) 19027 0 1225496 0 11937 102 0 0= =20 0 /usr/src/sys/kern/vfs_bio.c:2559 (lockmgr:bufwait) 18887 0 906297 0 4140 218 0 0= =20 0 /usr/src/sys/kern/vfs_bio.c:1835 (lockmgr:bufwait) 12101 0 23459 0 1675 14 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:2342 (sleep mutex:vnode interlock) 7448 0 170841 0 2229 76 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:2083 (lockmgr:ufs) 7342 0 21792 0 2169 10 0 0= =20 0 /usr/src/sys/kern/vfs_cache.c:390 (rw:Name Cache) 4648 0 10831 0 11 984 0 0= =20 0 /usr/src/sys/kern/vfs_subr.c:1693 (lockmgr:syncer) 3536 0 35352 0 9218 3 0 0= =20 0 /usr/src/sys/amd64/amd64/pmap.c:3989 (sleep mutex:pmap) 3039 0 34283 0 2641 12 0 0= =20 0 /usr/src/sys/vm/vm_fault.c:937 (sleep mutex:vm object) 2825 0 53949 0 3495 15 0 0= =20 0 /usr/src/sys/vm/vm_fault.c:1010 (sleep mutex:vm object) 2286 0 7169 0 547 13 0 0= =20 0 /usr/src/sys/kern/kern_sig.c:983 (sleep mutex:process lock) 2083 4010 9037 5380 2143 4 2 0= =20 2 /usr/src/sys/kern/vfs_subr.c:2118 (sleep mutex:vnode interlock) 2083 57 2089 57 4 522 14 0= =20 1 /usr/src/sys/kern/kern_mutex.c:147 (sleep mutex:pipe mutex) 2022 0 181449 0 515 352 0 0= =20 0 /usr/src/sys/vm/vm_pager.c:311 (lockmgr:bufwait) 1997 0 3397 0 2 1698 0 0= =20 0 /usr/src/sys/kern/kern_sysctl.c:1513 (sx:sysctl mem) 1994 0 4890 0 117 41 0 0= =20 0 /usr/src/sys/kern/kern_sysctl.c:1521 (sx:sysctl lock) 1971 0 4156 0 13 319 0 0= =20 0 /usr/src/sys/kern/kern_sysctl.c:1417 (sleep mutex:Giant) 1965 0 31838 0 3471 9 0 0= =20 0 /usr/src/sys/vm/vm_object.c:482 (sleep mutex:vm object) 1926 0 17695 0 83 213 0 0= =20 0 /usr/src/sys/vm/vm_object.c:541 (sleep mutex:vm object) There is at least one line in common that looks networking related,=20 /usr/src/sys/kern/uipc_sockbuf.c:148 (sx:so_rcv_sx) int sblock(struct sockbuf *sb, int flags) { KASSERT((flags & SBL_VALID) =3D=3D flags, ("sblock: flags invalid (0x%x)", flags)); if (flags & SBL_WAIT) { if ((sb->sb_flags & SB_NOINTR) || (flags & SBL_NOINTR)) { sx_xlock(&sb->sb_sx); return (0); } return (sx_xlock_sig(&sb->sb_sx)); } else { if (sx_try_xlock(&sb->sb_sx) =3D=3D 0) return (EWOULDBLOCK); return (0); } } It is not clear to me what this code is doing. (comments might help) It is not clear to me why networking and a USB_to_RS-232 bridge would have a lock conflict. It is not clear to me why networking and firewire would have a lock conflict. How do we fix this? From owner-freebsd-net@FreeBSD.ORG Fri Feb 4 06: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 70C371065670 for ; Fri, 4 Feb 2011 06:08:12 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id 171198FC13 for ; Fri, 4 Feb 2011 06:08:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=bkysoeGCfcLnGrCULB66IKRlWVij2dTv3UJohu4ndtE=; b=xLdfH86RLFrWWjwfu1UkPsG5rjVTIcQ3fgmS2/6BCStDd2lidz3DCmLBMi5yp75ycQc7wJMz6nWZ5DnH9PI9dMPl+iWhhLBpt+UaIeMSzsX3jeaZh3uhhwevI/0lC2BlxANhXsGTbIn6kb3zsp+Ec/rCAF0yWeToyqsVl78YTVQ=; Received: from alex by mail.zagrebin.ru with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PlEq1-000PXM-4e for freebsd-net@freebsd.org; Fri, 04 Feb 2011 09:08:09 +0300 Date: Fri, 4 Feb 2011 09:08:08 +0300 From: Alexander Zagrebin To: freebsd-net@freebsd.org Message-ID: <20110204060808.GA97298@gw.zagrebin.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: if_run in hostap mode: issue with stations in the power save mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 06:08:12 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm using an Ralink RT2870 based adapter (run(4) driver) in the hostap mode. and I've noticed that if_run doesn't support stations working in the power save mode (PSM). The reason is in lack of the TIM in beacons. The attached patch adds this functionality and completely fixes this issue. Despite the fact that patch is working, it seems that it needs an additional work. For example, now the result of ieee80211_beacon_update is ignored with a corresponding message, but may be necessary to process it... Can somebody review it? -- Alexander Zagrebin --ew6BAiZeqk4r7MaW Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch-if_run.c" --- sys/dev/usb/wlan/if_run.c.orig 2011-01-21 08:28:14.000000000 +0300 +++ sys/dev/usb/wlan/if_run.c 2011-02-03 20:46:16.809999991 +0300 @@ -3903,6 +3903,7 @@ struct run_softc *sc = ic->ic_ifp->if_softc; uint32_t i; + setbit(RUN_VAP(vap)->bo.bo_flags, item); i = RUN_CMDQ_GET(&sc->cmdq_store); DPRINTF("cmdq_store=%d\n", i); sc->cmdq[i].func = run_update_beacon_cb; @@ -3921,13 +3922,25 @@ struct rt2860_txwi txwi; struct mbuf *m; uint8_t ridx; + uint8_t flags[4]; if (vap->iv_bss->ni_chan == IEEE80211_CHAN_ANYC) return; + /* + * ieee80211_beacon_construct called from ieee80211_beacon_alloc + * will clear bo_flags, so we need store it for later use + */ + memcpy(&flags, &RUN_VAP(vap)->bo.bo_flags, sizeof(flags)); + if ((m = ieee80211_beacon_alloc(vap->iv_bss, &RUN_VAP(vap)->bo)) == NULL) return; + /* Now we may restore bo_flags and update the dynamic beacon contents */ + memcpy(&RUN_VAP(vap)->bo.bo_flags, &flags, sizeof(flags)); + if (ieee80211_beacon_update(vap->iv_bss, &RUN_VAP(vap)->bo, m, 1)) + device_printf(sc->sc_dev, "ieee80211_beacon_update failed\n"); + memset(&txwi, 0, sizeof txwi); txwi.wcid = 0xff; txwi.len = htole16(m->m_pkthdr.len); --ew6BAiZeqk4r7MaW-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 4 08:54: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 D92F4106566B for ; Fri, 4 Feb 2011 08:54:45 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 733B88FC15 for ; Fri, 4 Feb 2011 08:54:45 +0000 (UTC) Received: by fxm16 with SMTP id 16so2149231fxm.13 for ; Fri, 04 Feb 2011 00:54:44 -0800 (PST) Received: by 10.223.79.6 with SMTP id n6mr2187912fak.122.1296809684259; Fri, 04 Feb 2011 00:54:44 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-067-208-143.pools.arcor-ip.net [88.67.208.143]) by mx.google.com with ESMTPS id o17sm113569fal.25.2011.02.04.00.54.40 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 00:54:42 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Alexander Zagrebin Date: Fri, 4 Feb 2011 09:51:34 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.5; amd64; ; ) References: <20110204060808.GA97298@gw.zagrebin.ru> In-Reply-To: <20110204060808.GA97298@gw.zagrebin.ru> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_W47SNdY1J+fqshI" Message-Id: <201102040951.34201.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: if_run in hostap mode: issue with stations in the power save mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 08:54:45 -0000 --Boundary-00=_W47SNdY1J+fqshI Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote: > I'm using an Ralink RT2870 based adapter (run(4) driver) in the > hostap mode. and I've noticed that if_run doesn't support stations > working in the power save mode (PSM). The reason is in lack of the > TIM in beacons. The attached patch adds this functionality and > completely fixes this issue. Despite the fact that patch is working, > it seems that it needs an additional work. For example, now the > result of ieee80211_beacon_update is ignored with a corresponding > message, but may be necessary to process it... > > Can somebody review it? That looks about right, good catch! Handling ieee80211_beacon_update()'s return value doesn't seem to be necessary, the mbuf's length is handled in the next few lines of code anyways, doesn't matter if it changed or not. Though, I have a some doubts about just restoring bo_flags is enough (Can't prove that with some obvious code, still..). It feels saner to me if we just reuse the whole mbuf, similar to what ath(4) does. Can you look at attached patch? Completely untested, so I'm not sure what does happen on e.g. changing the SSID. -- Bernhard --Boundary-00=_W47SNdY1J+fqshI Content-Type: text/x-patch; charset="ISO-8859-1"; name="run-beacon.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="run-beacon.diff" Index: sys/dev/usb/wlan/if_runvar.h =================================================================== --- sys/dev/usb/wlan/if_runvar.h (revision 218083) +++ sys/dev/usb/wlan/if_runvar.h (working copy) @@ -121,6 +121,7 @@ struct run_cmdq { struct run_vap { struct ieee80211vap vap; struct ieee80211_beacon_offsets bo; + struct mbuf *beacon_mbuf; int (*newstate)(struct ieee80211vap *, enum ieee80211_state, int); Index: sys/dev/usb/wlan/if_run.c =================================================================== --- sys/dev/usb/wlan/if_run.c (revision 218083) +++ sys/dev/usb/wlan/if_run.c (working copy) @@ -856,6 +856,8 @@ run_vap_delete(struct ieee80211vap *vap) RUN_LOCK(sc); + m_freem(rvp->beacon_mbuf); + rvp_id = rvp->rvp_id; sc->ratectl_run &= ~(1 << rvp_id); sc->rvp_bmap &= ~(1 << rvp_id); @@ -3903,6 +3905,7 @@ run_update_beacon(struct ieee80211vap *vap, int it struct run_softc *sc = ic->ic_ifp->if_softc; uint32_t i; + setbit(RUN_VAP(vap)->bo.bo_flags, item); i = RUN_CMDQ_GET(&sc->cmdq_store); DPRINTF("cmdq_store=%d\n", i); sc->cmdq[i].func = run_update_beacon_cb; @@ -3916,6 +3919,7 @@ static void run_update_beacon_cb(void *arg) { struct ieee80211vap *vap = arg; + struct run_vap *rvp = RUN_VAP(vap); struct ieee80211com *ic = vap->iv_ic; struct run_softc *sc = ic->ic_ifp->if_softc; struct rt2860_txwi txwi; @@ -3925,8 +3929,15 @@ run_update_beacon_cb(void *arg) if (vap->iv_bss->ni_chan == IEEE80211_CHAN_ANYC) return; - if ((m = ieee80211_beacon_alloc(vap->iv_bss, &RUN_VAP(vap)->bo)) == NULL) - return; + if (&RUN_VAP(vap)->beacon_mbuf == NULL) { + m = ieee80211_beacon_alloc(vap->iv_bss, &RUN_VAP(vap)->bo); + if (m == NULL) + return; + rvp->beacon_mbuf = m; + } else { + m = rvp->beacon_mbuf; + ieee80211_beacon_update(vap->iv_bss, &rvp->bo, m, 1); + } memset(&txwi, 0, sizeof txwi); txwi.wcid = 0xff; @@ -3941,13 +3952,11 @@ run_update_beacon_cb(void *arg) txwi.flags = RT2860_TX_TS; txwi.xflags = RT2860_TX_NSEQ; - run_write_region_1(sc, RT2860_BCN_BASE(RUN_VAP(vap)->rvp_id), - (uint8_t *)&txwi, sizeof txwi); - run_write_region_1(sc, RT2860_BCN_BASE(RUN_VAP(vap)->rvp_id) + sizeof txwi, + run_write_region_1(sc, RT2860_BCN_BASE(rvp->rvp_id), (uint8_t *)&txwi, + sizeof txwi); + run_write_region_1(sc, RT2860_BCN_BASE(rvp->rvp_id) + sizeof txwi, mtod(m, uint8_t *), (m->m_pkthdr.len + 1) & ~1); /* roundup len */ - m_freem(m); - return; } --Boundary-00=_W47SNdY1J+fqshI-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 4 11:40: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 908521065674; Fri, 4 Feb 2011 11:40:25 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id 3452E8FC12; Fri, 4 Feb 2011 11:40:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=XBfKrxT8oDazwxH2snajU5Zg4BExf2soMmTsmhH1WFs=; b=2wwyxb6HAflusBalc2237xWEnRmLVBfACDbFOBGWlvURQ+fVK/p6QmDhHk3ipP/qG54zijVfY7q0jyH5DEwSc4/KM+kfWsf5CapGGwyP6BUK8RagXutn0WCt84LS6Mhsp/QvJo3KFJIkTECwUll6WzYJmUt5ULLU4NH8dOsJXpM=; Received: from alex by mail.zagrebin.ru with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PlK1W-0000tj-DG; Fri, 04 Feb 2011 14:40:22 +0300 Date: Fri, 4 Feb 2011 14:40:21 +0300 From: Alexander Zagrebin To: Bernhard Schmidt Message-ID: <20110204114021.GA237@gw.zagrebin.ru> References: <20110204060808.GA97298@gw.zagrebin.ru> <201102040951.34201.bschmidt@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102040951.34201.bschmidt@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: if_run in hostap mode: issue with stations in the power save mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 11:40:25 -0000 Hi! On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote: > On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote: > > I'm using an Ralink RT2870 based adapter (run(4) driver) in the > > hostap mode. and I've noticed that if_run doesn't support stations > > working in the power save mode (PSM). The reason is in lack of the > > TIM in beacons. The attached patch adds this functionality and > > completely fixes this issue. Despite the fact that patch is working, > > it seems that it needs an additional work. For example, now the > > result of ieee80211_beacon_update is ignored with a corresponding > > message, but may be necessary to process it... > > > > Can somebody review it? > > That looks about right, good catch! > > Handling ieee80211_beacon_update()'s return value doesn't seem to be > necessary, the mbuf's length is handled in the next few lines of code > anyways, doesn't matter if it changed or not. > > Though, I have a some doubts about just restoring bo_flags is enough > (Can't prove that with some obvious code, still..). It feels saner to me > if we just reuse the whole mbuf, similar to what ath(4) does. Can you > look at attached patch? Completely untested, so I'm not sure what does > happen on e.g. changing the SSID. I've thought about such solution, and it looks more right, but I've decided just to add ieee80211_beacon_update() to make the patch clear. I'll try your patch a bit later, but I already have a question: on the first invocation of the run_update_beacon_cb() only ieee80211_beacon_alloc() will be called. So dynamic beacon contents will not updated. Is it a problem? Also I have to note, that it seems that other wlan drivers can has this problem too: only ral's and ath's code uses ieee80211_beacon_update(). Also, I've found a kern/124753. One of replies contains a log's fragment with many records, like following: kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now queued kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 now queued kernel: ath0: [00:18:41:c0:06:54] power save mode off, 0 sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] flush ps queue, 2 packets queue But there are no records, which have to be for a PSM enabled stations: When a beacon is properly updated, then we have to see records about 1. TIM updating, like ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1 2. poll messages from a stations, like wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue empty Thanks for your cooperation! -- Alexander Zagrebin From owner-freebsd-net@FreeBSD.ORG Fri Feb 4 12:17: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 65EEA106566C for ; Fri, 4 Feb 2011 12:17:32 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 00C648FC15 for ; Fri, 4 Feb 2011 12:17:31 +0000 (UTC) Received: by fxm16 with SMTP id 16so2335493fxm.13 for ; Fri, 04 Feb 2011 04:17:31 -0800 (PST) Received: by 10.223.95.203 with SMTP id e11mr11325192fan.60.1296821850701; Fri, 04 Feb 2011 04:17:30 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-067-208-143.pools.arcor-ip.net [88.67.208.143]) by mx.google.com with ESMTPS id k6sm200596faa.6.2011.02.04.04.17.27 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 04:17:29 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Alexander Zagrebin Date: Fri, 4 Feb 2011 13:14:17 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.5; amd64; ; ) References: <20110204060808.GA97298@gw.zagrebin.ru> <201102040951.34201.bschmidt@freebsd.org> <20110204114021.GA237@gw.zagrebin.ru> In-Reply-To: <20110204114021.GA237@gw.zagrebin.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201102041314.17939.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org, PseudoCylon Subject: Re: if_run in hostap mode: issue with stations in the power save mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 12:17:32 -0000 On Friday 04 February 2011 12:40:21 Alexander Zagrebin wrote: > Hi! > > On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote: > > On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote: > > > I'm using an Ralink RT2870 based adapter (run(4) driver) in the > > > hostap mode. and I've noticed that if_run doesn't support > > > stations working in the power save mode (PSM). The reason is in > > > lack of the TIM in beacons. The attached patch adds this > > > functionality and completely fixes this issue. Despite the fact > > > that patch is working, it seems that it needs an additional > > > work. For example, now the result of ieee80211_beacon_update is > > > ignored with a corresponding message, but may be necessary to > > > process it... > > > > > > Can somebody review it? > > > > That looks about right, good catch! > > > > Handling ieee80211_beacon_update()'s return value doesn't seem to > > be necessary, the mbuf's length is handled in the next few lines > > of code anyways, doesn't matter if it changed or not. > > > > Though, I have a some doubts about just restoring bo_flags is > > enough (Can't prove that with some obvious code, still..). It > > feels saner to me if we just reuse the whole mbuf, similar to what > > ath(4) does. Can you look at attached patch? Completely untested, > > so I'm not sure what does happen on e.g. changing the SSID. > > I've thought about such solution, and it looks more right, but I've > decided just to add ieee80211_beacon_update() to make the patch > clear. I'll try your patch a bit later, but I already have a > question: on the first invocation of the run_update_beacon_cb() only > ieee80211_beacon_alloc() will be called. So dynamic beacon contents > will not updated. Is it a problem? I don't think it is. The work beacon_update does is handling changes to bo_flags, which are only changed through calls to iv_update_beacon(), so this is safe, because the driver itself does change bo_flags which is immediately followed by the beacon update process. There is one expection I'm not sure about how to handle though, slottime. This value might change based on nodes associating and leaving, resulting in a call to ic_updateslot() which is currently commentted out. Basically there needs to be another call to run_update_beacon_cb() in that function, of course based on the current opmode. > Also I have to note, that it seems that other wlan drivers can has > this problem too: only ral's and ath's code uses > ieee80211_beacon_update(). Yeah, true. > Also, I've found a kern/124753. One of > replies contains a log's fragment with many records, like following: > kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's in ps > mode kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now > queued kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 > now queued kernel: ath0: [00:18:41:c0:06:54] power save mode off, 0 > sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] flush ps queue, 2 > packets queue But there are no records, which have to be for a PSM > enabled stations: When a beacon is properly updated, then we have to > see records about 1. TIM updating, like > ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1 > 2. poll messages from a stations, like > wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue > empty > > Thanks for your cooperation! You mean there are missing debug messages in net80211/run? -- Bernhard From owner-freebsd-net@FreeBSD.ORG Fri Feb 4 14:30:15 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 850531065672 for ; Fri, 4 Feb 2011 14:30:15 +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 588B08FC16 for ; Fri, 4 Feb 2011 14:30:15 +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 p14EUFIt003052 for ; Fri, 4 Feb 2011 14:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p14EUFDU003047; Fri, 4 Feb 2011 14:30:15 GMT (envelope-from gnats) Date: Fri, 4 Feb 2011 14:30:15 GMT Message-Id: <201102041430.p14EUFDU003047@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: elof2@sentor.se Cc: Subject: Re: kern/154443: [bridge] Kernel module bridgestp.ko missing after upgrade (if_bridge.ko depend on it) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: elof2@sentor.se List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 14:30:15 -0000 The following reply was made to PR kern/154443; it has been noted by GNATS. From: elof2@sentor.se To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154443: [bridge] Kernel module bridgestp.ko missing after upgrade (if_bridge.ko depend on it) Date: Fri, 4 Feb 2011 15:03:00 +0100 (CET) Update to the bug report: It is not only the bridgestp.ko file that is missing. I've looked at /boot/kernel/*.ko on a system that was binary upgraded from 6.4-RELEASE to 7.3-RELEASE (i386) and compared it with a 7.3-RELEASE (i386) system installed from CD. The upgraded system has a total of 470 kernel modules. ls /boot/kernel/*.ko | wc -l 470 The CD-installed box has 572 kernel modules. ls /boot/kernel/*.ko | wc -l 572 Apart from bridgestp.ko, there are 101 other missing modules after the upgrade. :-/ The command 'freebsd-update IDS' does not complain about any of these missing files! When diffing the 470 vs 572 files, no modules on the upgraded system are missing on the CD-installed system. All differences (102 in total) are files that exist on the CD-installed system but not on the upgraded one. Here's a list of all missing kernel modules after upgrade: /boot/kernel/acpi_aiboost.ko /boot/kernel/alias_cuseeme.ko /boot/kernel/alias_dummy.ko /boot/kernel/alias_ftp.ko /boot/kernel/alias_irc.ko /boot/kernel/alias_nbt.ko /boot/kernel/alias_pptp.ko /boot/kernel/alias_skinny.ko /boot/kernel/alias_smedia.ko /boot/kernel/amdsbwd.ko /boot/kernel/amdtemp.ko /boot/kernel/bridgestp.ko /boot/kernel/cmx.ko /boot/kernel/cpuctl.ko /boot/kernel/cxgb_t3fw.ko /boot/kernel/cyclic.ko /boot/kernel/dpms.ko /boot/kernel/dtmalloc.ko /boot/kernel/dtrace.ko /boot/kernel/dtrace_test.ko /boot/kernel/dtraceall.ko /boot/kernel/fbt.ko /boot/kernel/geom_cache.ko /boot/kernel/geom_journal.ko /boot/kernel/geom_linux_lvm.ko /boot/kernel/geom_multipath.ko /boot/kernel/geom_part_apm.ko /boot/kernel/geom_part_bsd.ko /boot/kernel/geom_part_ebr.ko /boot/kernel/geom_part_gpt.ko /boot/kernel/geom_part_mbr.ko /boot/kernel/geom_part_pc98.ko /boot/kernel/geom_part_vtoc8.ko /boot/kernel/geom_virstor.ko /boot/kernel/glxsb.ko /boot/kernel/hptiop.ko /boot/kernel/if_ae.ko /boot/kernel/if_age.ko /boot/kernel/if_alc.ko /boot/kernel/if_ale.ko /boot/kernel/if_cas.ko /boot/kernel/if_et.ko /boot/kernel/if_igb.ko /boot/kernel/if_lmc.ko /boot/kernel/if_malo.ko /boot/kernel/if_nfe.ko /boot/kernel/if_nxge.ko /boot/kernel/if_rum.ko /boot/kernel/if_wpi.ko /boot/kernel/if_zyd.ko /boot/kernel/ipfw_nat.ko /boot/kernel/ipw_bss.ko /boot/kernel/ipw_ibss.ko /boot/kernel/ipw_monitor.ko /boot/kernel/iscsi_initiator.ko /boot/kernel/isp_1040.ko /boot/kernel/isp_1040_it.ko /boot/kernel/isp_1080.ko /boot/kernel/isp_1080_it.ko /boot/kernel/isp_12160.ko /boot/kernel/isp_12160_it.ko /boot/kernel/isp_2100.ko /boot/kernel/isp_2200.ko /boot/kernel/isp_2300.ko /boot/kernel/isp_2322.ko /boot/kernel/isp_2400.ko /boot/kernel/iw_cxgb.ko /boot/kernel/iwi_bss.ko /boot/kernel/iwi_ibss.ko /boot/kernel/ipw_monitor.ko /boot/kernel/iscsi_initiator.ko /boot/kernel/isp_1040.ko /boot/kernel/isp_1040_it.ko /boot/kernel/isp_1080.ko /boot/kernel/isp_1080_it.ko /boot/kernel/isp_12160.ko /boot/kernel/isp_12160_it.ko /boot/kernel/isp_2100.ko /boot/kernel/isp_2200.ko /boot/kernel/isp_2300.ko /boot/kernel/isp_2322.ko /boot/kernel/isp_2400.ko /boot/kernel/iw_cxgb.ko /boot/kernel/iwi_bss.ko /boot/kernel/iwi_ibss.ko /boot/kernel/iwi_monitor.ko /boot/kernel/krping.ko /boot/kernel/lindev.ko /boot/kernel/mmc.ko /boot/kernel/mmcsd.ko /boot/kernel/mqueuefs.ko /boot/kernel/ng_car.ko /boot/kernel/ohci.ko /boot/kernel/opensolaris.ko /boot/kernel/profile.ko /boot/kernel/prototype.ko /boot/kernel/rdma_addr.ko /boot/kernel/rdma_cma.ko /boot/kernel/rdma_core.ko /boot/kernel/rdma_iwcm.ko /boot/kernel/scc.ko /boot/kernel/sdhci.ko /boot/kernel/sdt.ko /boot/kernel/sem.ko /boot/kernel/snd_emu10kx.ko /boot/kernel/systrace.ko /boot/kernel/tmpfs.ko /boot/kernel/toecore.ko /boot/kernel/tom.ko /boot/kernel/u3g.ko /boot/kernel/ufoma.ko /boot/kernel/uhci.ko /boot/kernel/uslcom.ko /boot/kernel/wlan_scan_ap.ko /boot/kernel/wlan_scan_sta.ko /boot/kernel/wpifw.ko /boot/kernel/xfs.ko /boot/kernel/zfs.ko /Elof From owner-freebsd-net@FreeBSD.ORG Fri Feb 4 18:10: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 DA6B0106566B; Fri, 4 Feb 2011 18:10:30 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7A2908FC19; Fri, 4 Feb 2011 18:10:30 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p14I9uc4062603; Fri, 4 Feb 2011 10:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1296842997; bh=ZSVZVd05IHh6EQiRRKtTZ8q51ey9s2jjxsOIxbWxMBs=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=oAU7zzt1g6KykhOvWG45kKGSMlnDp2t4/+bZ/sYnytObfYZiq2tBczzka8w24MQdc G1QxeP4CnMFC9AHaMUkVvuIWjII3KWp7abyoj88PDSh00VElEMeKTcg6htjIpzKmfl +9NcxHfLmLSRo4JoTjtYv5tEAPZ/WfmcwpiKhliU= From: Sean Bruno To: Mike Tancsa In-Reply-To: <4D49A26B.5050803@sentex.net> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Feb 2011 10:09:56 -0800 Message-ID: <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Jack Vogel , Jan Koum , Ivan Voras Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 04 Feb 2011 18:10:31 -0000 Any more data on this problem or do we have to wait a while? Sean On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote: > On 2/2/2011 12:37 PM, Jack Vogel wrote: > > So has everyone that wanted to get something testing been able to do so? > > I have been testing in the back and will deploy to my production box > this afternoon. As I am not able to reproduce it easily, it will be a > bit before I can say the issue is gone. Jan however, was able to > trigger it with greater ease ? > > ---Mike > > > > > Jack > > > > > > On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote: > > > >> On 2/1/2011 5:03 PM, Sean Bruno wrote: > >>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote: > >>>> To those who are going to test, here is the if_em.c, based on head, > >>>> with my > >>>> changes, I have to leave for the afternoon, and have not had a chance > >>>> to build > >>>> this, but it should work. I will check back in the later evening. > >>>> > >>>> Any blatant problems Sean, feel free to fix them :) > >>>> > >>>> Jack > >>>> > >>> > >>> > >>> I suspect that line 1490 should be: > >>> if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { > >>> > >> > >> > >> I have hacked up a RELENG_8 version which I think is correct including > >> the above change > >> > >> http://www.tancsa.com/if_em-8.c > >> > >> > >> > >> --- if_em.c.orig 2011-02-01 21:47:14.000000000 -0500 > >> +++ if_em.c 2011-02-01 21:47:19.000000000 -0500 > >> @@ -30,7 +30,7 @@ > >> POSSIBILITY OF SUCH DAMAGE. > >> > >> > >> ******************************************************************************/ > >> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53 > >> jfv Exp $*/ > >> +/*$FreeBSD$*/ > >> > >> #ifdef HAVE_KERNEL_OPTION_HEADERS > >> #include "opt_device_polling.h" > >> @@ -93,7 +93,7 @@ > >> /********************************************************************* > >> * Driver version: > >> *********************************************************************/ > >> -char em_driver_version[] = "7.1.9"; > >> +char em_driver_version[] = "7.1.9-test"; > >> > >> /********************************************************************* > >> * PCI Device ID Table > >> @@ -927,11 +927,10 @@ > >> if (!adapter->link_active) > >> return; > >> > >> - /* Call cleanup if number of TX descriptors low */ > >> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > >> - em_txeof(txr); > >> - > >> while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { > >> + /* First cleanup if TX descriptors low */ > >> + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > >> + em_txeof(txr); > >> if (txr->tx_avail < EM_MAX_SCATTER) { > >> ifp->if_drv_flags |= IFF_DRV_OACTIVE; > >> break; > >> @@ -1411,8 +1410,7 @@ > >> if (!drbr_empty(ifp, txr->br)) > >> em_mq_start_locked(ifp, txr, NULL); > >> #else > >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > >> - em_start_locked(ifp, txr); > >> + em_start_locked(ifp, txr); > >> #endif > >> EM_TX_UNLOCK(txr); > >> > >> @@ -1475,11 +1473,10 @@ > >> struct ifnet *ifp = adapter->ifp; > >> struct tx_ring *txr = adapter->tx_rings; > >> struct rx_ring *rxr = adapter->rx_rings; > >> - bool more; > >> - > >> > >> if (ifp->if_drv_flags & IFF_DRV_RUNNING) { > >> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL); > >> + bool more_rx; > >> + more_rx = em_rxeof(rxr, adapter->rx_process_limit, NULL); > >> > >> EM_TX_LOCK(txr); > >> em_txeof(txr); > >> @@ -1487,12 +1484,10 @@ > >> if (!drbr_empty(ifp, txr->br)) > >> em_mq_start_locked(ifp, txr, NULL); > >> #else > >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > >> - em_start_locked(ifp, txr); > >> + em_start_locked(ifp, txr); > >> #endif > >> - em_txeof(txr); > >> EM_TX_UNLOCK(txr); > >> - if (more) { > >> + if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { > >> taskqueue_enqueue(adapter->tq, &adapter->que_task); > >> return; > >> } > >> @@ -1604,7 +1599,6 @@ > >> if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > >> em_start_locked(ifp, txr); > >> #endif > >> - em_txeof(txr); > >> E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims); > >> EM_TX_UNLOCK(txr); > >> } > >> @@ -3730,17 +3724,17 @@ > >> txr->queue_status = EM_QUEUE_HUNG; > >> > >> /* > >> - * If we have enough room, clear IFF_DRV_OACTIVE > >> + * If we have a minimum free, clear IFF_DRV_OACTIVE > >> * to tell the stack that it is OK to send packets. > >> */ > >> - if (txr->tx_avail > EM_TX_CLEANUP_THRESHOLD) { > >> + if (txr->tx_avail > EM_MAX_SCATTER) > >> ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; > >> - /* Disable watchdog if all clean */ > >> - if (txr->tx_avail == adapter->num_tx_desc) { > >> - txr->queue_status = EM_QUEUE_IDLE; > >> - return (FALSE); > >> - } > >> - } > >> + > >> + /* Disable watchdog if all clean */ > >> + if (txr->tx_avail == adapter->num_tx_desc) { > >> + txr->queue_status = EM_QUEUE_IDLE; > >> + return (FALSE); > >> + } > >> > >> return (TRUE); > >> } > >> @@ -5064,8 +5058,8 @@ > >> char namebuf[QUEUE_NAME_LEN]; > >> > >> /* Driver Statistics */ > >> - SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", > >> - CTLFLAG_RD, &adapter->link_irq, 0, > >> + SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", > >> + CTLFLAG_RD, &adapter->link_irq,0, > >> "Link MSIX IRQ Handled"); > >> SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "mbuf_alloc_fail", > >> CTLFLAG_RD, &adapter->mbuf_alloc_failed, > >> @@ -5108,11 +5102,13 @@ > >> queue_list = SYSCTL_CHILDREN(queue_node); > >> > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_head", > >> - CTLFLAG_RD, adapter, E1000_TDH(txr->me), > >> + CTLFLAG_RD, adapter, > >> + E1000_TDH(txr->me), > >> em_sysctl_reg_handler, "IU", > >> "Transmit Descriptor Head"); > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_tail", > >> - CTLFLAG_RD, adapter, E1000_TDT(txr->me), > >> + CTLFLAG_RD, adapter, > >> + E1000_TDT(txr->me), > >> em_sysctl_reg_handler, "IU", > >> "Transmit Descriptor Tail"); > >> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "tx_irq", > >> @@ -5123,11 +5119,13 @@ > >> "Queue No Descriptor Available"); > >> > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_head", > >> - CTLFLAG_RD, adapter, E1000_RDH(rxr->me), > >> + CTLFLAG_RD, adapter, > >> + E1000_RDH(rxr->me), > >> em_sysctl_reg_handler, "IU", > >> "Receive Descriptor Head"); > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_tail", > >> - CTLFLAG_RD, adapter, E1000_RDT(rxr->me), > >> + CTLFLAG_RD, adapter, > >> + E1000_RDT(rxr->me), > >> em_sysctl_reg_handler, "IU", > >> "Receive Descriptor Tail"); > >> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "rx_irq", > >> @@ -5141,19 +5139,19 @@ > >> CTLFLAG_RD, NULL, "Statistics"); > >> stat_list = SYSCTL_CHILDREN(stat_node); > >> > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", > >> CTLFLAG_RD, &stats->ecol, > >> "Excessive collisions"); > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", > >> CTLFLAG_RD, &stats->scc, > >> "Single collisions"); > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", > >> CTLFLAG_RD, &stats->mcc, > >> "Multiple collisions"); > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", > >> CTLFLAG_RD, &stats->latecol, > >> "Late collisions"); > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", > >> CTLFLAG_RD, &stats->colc, > >> "Collision Count"); > >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "symbol_errors", > >> @@ -5240,12 +5238,12 @@ > >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "rx_frames_1024_1522", > >> CTLFLAG_RD, &adapter->stats.prc1522, > >> "1023-1522 byte frames received"); > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", > >> CTLFLAG_RD, &adapter->stats.gorc, > >> "Good Octets Received"); > >> > >> /* Packet Transmission Stats */ > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", > >> CTLFLAG_RD, &adapter->stats.gotc, > >> "Good Octets Transmitted"); > >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "total_pkts_txd", > >> > >> -- > >> ------------------- > >> 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/ > >> > > > > > -- > ------------------- > 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/ > _______________________________________________ > 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 Feb 4 18:12: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 0883F106566B; Fri, 4 Feb 2011 18:12:19 +0000 (UTC) (envelope-from jfvogel@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 781D88FC08; Fri, 4 Feb 2011 18:12:18 +0000 (UTC) Received: by ywp6 with SMTP id 6so1082259ywp.13 for ; Fri, 04 Feb 2011 10:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u9dJSGpWTOziYYo1MG59YTEGWt6KsFoLDn8FxxeQQUk=; b=v0o0Sk6njf6WuwGHNCc6xTf11r09chCncPdwLz449EyD2iV0yOCIWdkT+rKRKEDRIs xxfxqOVeb+hCLaxEVpigtBznKQPCgW9aAMnT3Ms32q7raZvq0aHxOk3a74KwgBHZe/Kz xXyk554dROGwooqAnUDYD/iH2l1IT9j6l5/lQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N4uwf4er7ACCSVmfT3VTxf27faV9v815y9S/GzU/HQ1vtG+IyGgWoGpxpgOSiFy0vZ Ito/aHpSZrHVoWRfsCJjwpL2pdA3yVE8qxpNarcBjqmRcSs0QwzyD8/xb9PJ3RCSb6bJ rKJsnX3QrqyseCebZ5gIwbiikFD4RYCOfGFkM= MIME-Version: 1.0 Received: by 10.151.106.7 with SMTP id i7mr376067ybm.193.1296843137478; Fri, 04 Feb 2011 10:12:17 -0800 (PST) Received: by 10.147.171.17 with HTTP; Fri, 4 Feb 2011 10:12:17 -0800 (PST) In-Reply-To: <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> Date: Fri, 4 Feb 2011 10:12:17 -0800 Message-ID: From: Jack Vogel To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Ivan Voras , Jan Koum , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 04 Feb 2011 18:12:19 -0000 Was curious too, but being more patient than you :) Jack On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno wrote: > Any more data on this problem or do we have to wait a while? > > Sean > > > On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote: > > On 2/2/2011 12:37 PM, Jack Vogel wrote: > > > So has everyone that wanted to get something testing been able to do > so? > > > > I have been testing in the back and will deploy to my production box > > this afternoon. As I am not able to reproduce it easily, it will be a > > bit before I can say the issue is gone. Jan however, was able to > > trigger it with greater ease ? > > > > ---Mike > > > > > > > > Jack > > > > > > > > > On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote: > > > > > >> On 2/1/2011 5:03 PM, Sean Bruno wrote: > > >>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote: > > >>>> To those who are going to test, here is the if_em.c, based on head, > > >>>> with my > > >>>> changes, I have to leave for the afternoon, and have not had a > chance > > >>>> to build > > >>>> this, but it should work. I will check back in the later evening. > > >>>> > > >>>> Any blatant problems Sean, feel free to fix them :) > > >>>> > > >>>> Jack > > >>>> > > >>> > > >>> > > >>> I suspect that line 1490 should be: > > >>> if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { > > >>> > > >> > > >> > > >> I have hacked up a RELENG_8 version which I think is correct including > > >> the above change > > >> > > >> http://www.tancsa.com/if_em-8.c > > >> > > >> > > >> > > >> --- if_em.c.orig 2011-02-01 21:47:14.000000000 -0500 > > >> +++ if_em.c 2011-02-01 21:47:19.000000000 -0500 > > >> @@ -30,7 +30,7 @@ > > >> POSSIBILITY OF SUCH DAMAGE. > > >> > > >> > > >> > ******************************************************************************/ > > >> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53 > > >> jfv Exp $*/ > > >> +/*$FreeBSD$*/ > > >> > > >> #ifdef HAVE_KERNEL_OPTION_HEADERS > > >> #include "opt_device_polling.h" > > >> @@ -93,7 +93,7 @@ > > >> > /********************************************************************* > > >> * Driver version: > > >> > *********************************************************************/ > > >> -char em_driver_version[] = "7.1.9"; > > >> +char em_driver_version[] = "7.1.9-test"; > > >> > > >> > /********************************************************************* > > >> * PCI Device ID Table > > >> @@ -927,11 +927,10 @@ > > >> if (!adapter->link_active) > > >> return; > > >> > > >> - /* Call cleanup if number of TX descriptors low */ > > >> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > > >> - em_txeof(txr); > > >> - > > >> while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { > > >> + /* First cleanup if TX descriptors low */ > > >> + if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > > >> + em_txeof(txr); > > >> if (txr->tx_avail < EM_MAX_SCATTER) { > > >> ifp->if_drv_flags |= IFF_DRV_OACTIVE; > > >> break; > > >> @@ -1411,8 +1410,7 @@ > > >> if (!drbr_empty(ifp, txr->br)) > > >> em_mq_start_locked(ifp, txr, NULL); > > >> #else > > >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > > >> - em_start_locked(ifp, txr); > > >> + em_start_locked(ifp, txr); > > >> #endif > > >> EM_TX_UNLOCK(txr); > > >> > > >> @@ -1475,11 +1473,10 @@ > > >> struct ifnet *ifp = adapter->ifp; > > >> struct tx_ring *txr = adapter->tx_rings; > > >> struct rx_ring *rxr = adapter->rx_rings; > > >> - bool more; > > >> - > > >> > > >> if (ifp->if_drv_flags & IFF_DRV_RUNNING) { > > >> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL); > > >> + bool more_rx; > > >> + more_rx = em_rxeof(rxr, adapter->rx_process_limit, > NULL); > > >> > > >> EM_TX_LOCK(txr); > > >> em_txeof(txr); > > >> @@ -1487,12 +1484,10 @@ > > >> if (!drbr_empty(ifp, txr->br)) > > >> em_mq_start_locked(ifp, txr, NULL); > > >> #else > > >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > > >> - em_start_locked(ifp, txr); > > >> + em_start_locked(ifp, txr); > > >> #endif > > >> - em_txeof(txr); > > >> EM_TX_UNLOCK(txr); > > >> - if (more) { > > >> + if (more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) > { > > >> taskqueue_enqueue(adapter->tq, > &adapter->que_task); > > >> return; > > >> } > > >> @@ -1604,7 +1599,6 @@ > > >> if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > > >> em_start_locked(ifp, txr); > > >> #endif > > >> - em_txeof(txr); > > >> E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims); > > >> EM_TX_UNLOCK(txr); > > >> } > > >> @@ -3730,17 +3724,17 @@ > > >> txr->queue_status = EM_QUEUE_HUNG; > > >> > > >> /* > > >> - * If we have enough room, clear IFF_DRV_OACTIVE > > >> + * If we have a minimum free, clear IFF_DRV_OACTIVE > > >> * to tell the stack that it is OK to send packets. > > >> */ > > >> - if (txr->tx_avail > EM_TX_CLEANUP_THRESHOLD) { > > >> + if (txr->tx_avail > EM_MAX_SCATTER) > > >> ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; > > >> - /* Disable watchdog if all clean */ > > >> - if (txr->tx_avail == adapter->num_tx_desc) { > > >> - txr->queue_status = EM_QUEUE_IDLE; > > >> - return (FALSE); > > >> - } > > >> - } > > >> + > > >> + /* Disable watchdog if all clean */ > > >> + if (txr->tx_avail == adapter->num_tx_desc) { > > >> + txr->queue_status = EM_QUEUE_IDLE; > > >> + return (FALSE); > > >> + } > > >> > > >> return (TRUE); > > >> } > > >> @@ -5064,8 +5058,8 @@ > > >> char namebuf[QUEUE_NAME_LEN]; > > >> > > >> /* Driver Statistics */ > > >> - SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", > > >> - CTLFLAG_RD, &adapter->link_irq, 0, > > >> + SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", > > >> + CTLFLAG_RD, &adapter->link_irq,0, > > >> "Link MSIX IRQ Handled"); > > >> SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "mbuf_alloc_fail", > > >> CTLFLAG_RD, &adapter->mbuf_alloc_failed, > > >> @@ -5108,11 +5102,13 @@ > > >> queue_list = SYSCTL_CHILDREN(queue_node); > > >> > > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_head", > > >> - CTLFLAG_RD, adapter, > E1000_TDH(txr->me), > > >> + CTLFLAG_RD, adapter, > > >> + E1000_TDH(txr->me), > > >> em_sysctl_reg_handler, "IU", > > >> "Transmit Descriptor Head"); > > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_tail", > > >> - CTLFLAG_RD, adapter, > E1000_TDT(txr->me), > > >> + CTLFLAG_RD, adapter, > > >> + E1000_TDT(txr->me), > > >> em_sysctl_reg_handler, "IU", > > >> "Transmit Descriptor Tail"); > > >> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "tx_irq", > > >> @@ -5123,11 +5119,13 @@ > > >> "Queue No Descriptor Available"); > > >> > > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_head", > > >> - CTLFLAG_RD, adapter, > E1000_RDH(rxr->me), > > >> + CTLFLAG_RD, adapter, > > >> + E1000_RDH(rxr->me), > > >> em_sysctl_reg_handler, "IU", > > >> "Receive Descriptor Head"); > > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_tail", > > >> - CTLFLAG_RD, adapter, > E1000_RDT(rxr->me), > > >> + CTLFLAG_RD, adapter, > > >> + E1000_RDT(rxr->me), > > >> em_sysctl_reg_handler, "IU", > > >> "Receive Descriptor Tail"); > > >> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "rx_irq", > > >> @@ -5141,19 +5139,19 @@ > > >> CTLFLAG_RD, NULL, "Statistics"); > > >> stat_list = SYSCTL_CHILDREN(stat_node); > > >> > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", > > >> CTLFLAG_RD, &stats->ecol, > > >> "Excessive collisions"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", > > >> CTLFLAG_RD, &stats->scc, > > >> "Single collisions"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", > > >> CTLFLAG_RD, &stats->mcc, > > >> "Multiple collisions"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", > > >> CTLFLAG_RD, &stats->latecol, > > >> "Late collisions"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", > > >> CTLFLAG_RD, &stats->colc, > > >> "Collision Count"); > > >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "symbol_errors", > > >> @@ -5240,12 +5238,12 @@ > > >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "rx_frames_1024_1522", > > >> CTLFLAG_RD, &adapter->stats.prc1522, > > >> "1023-1522 byte frames received"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", > > >> CTLFLAG_RD, &adapter->stats.gorc, > > >> "Good Octets Received"); > > >> > > >> /* Packet Transmission Stats */ > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", > > >> CTLFLAG_RD, &adapter->stats.gotc, > > >> "Good Octets Transmitted"); > > >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "total_pkts_txd", > > >> > > >> -- > > >> ------------------- > > >> 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/ > > >> > > > > > > > > > -- > > ------------------- > > 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/ > > _______________________________________________ > > 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 Feb 4 19:22: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 B0AFD1065672; Fri, 4 Feb 2011 19:22:09 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 61CF98FC16; Fri, 4 Feb 2011 19:22:09 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p14JLfeI076851; Fri, 4 Feb 2011 11:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1296847302; bh=LnUiV52+/Ki6nwyPPPY3NxOKuMICyCwMiOChbOkrA/o=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=fsQo73O8U8lEVR2uv3FO3YPEW0CUi9a0XtQx8TeOGmh6a91SN26K3zK6f1gG1oD2x XM7ri/qnApyl6fbyTRwY9YUNiiW5JIP8APml1cYdobe6wrXpP2p84YOZjNzKGXn9W/ 7N67irWL//XA6C9duZ3EobuOBC5waq3KONY1x34Y= From: Sean Bruno To: Jack Vogel In-Reply-To: References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Feb 2011 11:21:40 -0800 Message-ID: <1296847300.2509.0.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Ivan Voras , Jan Koum , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 04 Feb 2011 19:22:09 -0000 meh, patience is not one of my character traits. :-) Sean On Fri, 2011-02-04 at 10:12 -0800, Jack Vogel wrote: > Was curious too, but being more patient than you :) > > Jack > > > On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno > wrote: > Any more data on this problem or do we have to wait a while? > > Sean > > > > On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote: > > On 2/2/2011 12:37 PM, Jack Vogel wrote: > > > So has everyone that wanted to get something testing been > able to do so? > > > > I have been testing in the back and will deploy to my > production box > > this afternoon. As I am not able to reproduce it easily, it > will be a > > bit before I can say the issue is gone. Jan however, was > able to > > trigger it with greater ease ? > > > > ---Mike > > > > > > > > Jack > > > > > > > > > On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa > wrote: > > > > > >> On 2/1/2011 5:03 PM, Sean Bruno wrote: > > >>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote: > > >>>> To those who are going to test, here is the if_em.c, > based on head, > > >>>> with my > > >>>> changes, I have to leave for the afternoon, and have > not had a chance > > >>>> to build > > >>>> this, but it should work. I will check back in the > later evening. > > >>>> > > >>>> Any blatant problems Sean, feel free to fix them :) > > >>>> > > >>>> Jack > > >>>> > > >>> > > >>> > > >>> I suspect that line 1490 should be: > > >>> if (more_rx || (ifp->if_drv_flags & > IFF_DRV_OACTIVE)) { > > >>> > > >> > > >> > > >> I have hacked up a RELENG_8 version which I think is > correct including > > >> the above change > > >> > > >> http://www.tancsa.com/if_em-8.c > > >> > > >> > > >> > > >> --- if_em.c.orig 2011-02-01 21:47:14.000000000 > -0500 > > >> +++ if_em.c 2011-02-01 21:47:19.000000000 -0500 > > >> @@ -30,7 +30,7 @@ > > >> POSSIBILITY OF SUCH DAMAGE. > > >> > > >> > > >> > ******************************************************************************/ > > >> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 > 2011/01/22 01:37:53 > > >> jfv Exp $*/ > > >> +/*$FreeBSD$*/ > > >> > > >> #ifdef HAVE_KERNEL_OPTION_HEADERS > > >> #include "opt_device_polling.h" > > >> @@ -93,7 +93,7 @@ > > >> > /********************************************************************* > > >> * Driver version: > > >> > *********************************************************************/ > > >> -char em_driver_version[] = "7.1.9"; > > >> +char em_driver_version[] = "7.1.9-test"; > > >> > > >> > /********************************************************************* > > >> * PCI Device ID Table > > >> @@ -927,11 +927,10 @@ > > >> if (!adapter->link_active) > > >> return; > > >> > > >> - /* Call cleanup if number of TX descriptors low > */ > > >> - if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > > >> - em_txeof(txr); > > >> - > > >> while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { > > >> + /* First cleanup if TX descriptors low */ > > >> + if (txr->tx_avail <= > EM_TX_CLEANUP_THRESHOLD) > > >> + em_txeof(txr); > > >> if (txr->tx_avail < EM_MAX_SCATTER) { > > >> ifp->if_drv_flags |= > IFF_DRV_OACTIVE; > > >> break; > > >> @@ -1411,8 +1410,7 @@ > > >> if (!drbr_empty(ifp, txr->br)) > > >> em_mq_start_locked(ifp, txr, NULL); > > >> #else > > >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > > >> - em_start_locked(ifp, txr); > > >> + em_start_locked(ifp, txr); > > >> #endif > > >> EM_TX_UNLOCK(txr); > > >> > > >> @@ -1475,11 +1473,10 @@ > > >> struct ifnet *ifp = adapter->ifp; > > >> struct tx_ring *txr = adapter->tx_rings; > > >> struct rx_ring *rxr = adapter->rx_rings; > > >> - bool more; > > >> - > > >> > > >> if (ifp->if_drv_flags & IFF_DRV_RUNNING) { > > >> - more = em_rxeof(rxr, > adapter->rx_process_limit, NULL); > > >> + bool more_rx; > > >> + more_rx = em_rxeof(rxr, > adapter->rx_process_limit, NULL); > > >> > > >> EM_TX_LOCK(txr); > > >> em_txeof(txr); > > >> @@ -1487,12 +1484,10 @@ > > >> if (!drbr_empty(ifp, txr->br)) > > >> em_mq_start_locked(ifp, txr, > NULL); > > >> #else > > >> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > > >> - em_start_locked(ifp, txr); > > >> + em_start_locked(ifp, txr); > > >> #endif > > >> - em_txeof(txr); > > >> EM_TX_UNLOCK(txr); > > >> - if (more) { > > >> + if (more_rx || (ifp->if_drv_flags & > IFF_DRV_OACTIVE)) { > > >> taskqueue_enqueue(adapter->tq, > &adapter->que_task); > > >> return; > > >> } > > >> @@ -1604,7 +1599,6 @@ > > >> if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > > >> em_start_locked(ifp, txr); > > >> #endif > > >> - em_txeof(txr); > > >> E1000_WRITE_REG(&adapter->hw, E1000_IMS, > txr->ims); > > >> EM_TX_UNLOCK(txr); > > >> } > > >> @@ -3730,17 +3724,17 @@ > > >> txr->queue_status = EM_QUEUE_HUNG; > > >> > > >> /* > > >> - * If we have enough room, clear IFF_DRV_OACTIVE > > >> + * If we have a minimum free, clear > IFF_DRV_OACTIVE > > >> * to tell the stack that it is OK to send > packets. > > >> */ > > >> - if (txr->tx_avail > EM_TX_CLEANUP_THRESHOLD) { > > >> + if (txr->tx_avail > EM_MAX_SCATTER) > > >> ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; > > >> - /* Disable watchdog if all clean */ > > >> - if (txr->tx_avail == > adapter->num_tx_desc) { > > >> - txr->queue_status = > EM_QUEUE_IDLE; > > >> - return (FALSE); > > >> - } > > >> - } > > >> + > > >> + /* Disable watchdog if all clean */ > > >> + if (txr->tx_avail == adapter->num_tx_desc) { > > >> + txr->queue_status = EM_QUEUE_IDLE; > > >> + return (FALSE); > > >> + } > > >> > > >> return (TRUE); > > >> } > > >> @@ -5064,8 +5058,8 @@ > > >> char namebuf[QUEUE_NAME_LEN]; > > >> > > >> /* Driver Statistics */ > > >> - SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", > > >> - CTLFLAG_RD, &adapter->link_irq, > 0, > > >> + SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", > > >> + CTLFLAG_RD, &adapter->link_irq,0, > > >> "Link MSIX IRQ Handled"); > > >> SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, > "mbuf_alloc_fail", > > >> CTLFLAG_RD, > &adapter->mbuf_alloc_failed, > > >> @@ -5108,11 +5102,13 @@ > > >> queue_list = SYSCTL_CHILDREN(queue_node); > > >> > > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, > "txd_head", > > >> - CTLFLAG_RD, adapter, > E1000_TDH(txr->me), > > >> + CTLFLAG_RD, adapter, > > >> + E1000_TDH(txr->me), > > >> em_sysctl_reg_handler, > "IU", > > >> "Transmit Descriptor > Head"); > > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, > "txd_tail", > > >> - CTLFLAG_RD, adapter, > E1000_TDT(txr->me), > > >> + CTLFLAG_RD, adapter, > > >> + E1000_TDT(txr->me), > > >> em_sysctl_reg_handler, > "IU", > > >> "Transmit Descriptor > Tail"); > > >> SYSCTL_ADD_ULONG(ctx, queue_list, > OID_AUTO, "tx_irq", > > >> @@ -5123,11 +5119,13 @@ > > >> "Queue No Descriptor > Available"); > > >> > > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, > "rxd_head", > > >> - CTLFLAG_RD, adapter, > E1000_RDH(rxr->me), > > >> + CTLFLAG_RD, adapter, > > >> + E1000_RDH(rxr->me), > > >> em_sysctl_reg_handler, > "IU", > > >> "Receive Descriptor > Head"); > > >> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, > "rxd_tail", > > >> - CTLFLAG_RD, adapter, > E1000_RDT(rxr->me), > > >> + CTLFLAG_RD, adapter, > > >> + E1000_RDT(rxr->me), > > >> em_sysctl_reg_handler, > "IU", > > >> "Receive Descriptor > Tail"); > > >> SYSCTL_ADD_ULONG(ctx, queue_list, > OID_AUTO, "rx_irq", > > >> @@ -5141,19 +5139,19 @@ > > >> CTLFLAG_RD, NULL, > "Statistics"); > > >> stat_list = SYSCTL_CHILDREN(stat_node); > > >> > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "excess_coll", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "excess_coll", > > >> CTLFLAG_RD, &stats->ecol, > > >> "Excessive collisions"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "single_coll", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "single_coll", > > >> CTLFLAG_RD, &stats->scc, > > >> "Single collisions"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "multiple_coll", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "multiple_coll", > > >> CTLFLAG_RD, &stats->mcc, > > >> "Multiple collisions"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "late_coll", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "late_coll", > > >> CTLFLAG_RD, &stats->latecol, > > >> "Late collisions"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "collision_count", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "collision_count", > > >> CTLFLAG_RD, &stats->colc, > > >> "Collision Count"); > > >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "symbol_errors", > > >> @@ -5240,12 +5238,12 @@ > > >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "rx_frames_1024_1522", > > >> CTLFLAG_RD, > &adapter->stats.prc1522, > > >> "1023-1522 byte frames received"); > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "good_octets_recvd", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "good_octets_recvd", > > >> CTLFLAG_RD, &adapter->stats.gorc, > > >> "Good Octets Received"); > > >> > > >> /* Packet Transmission Stats */ > > >> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "good_octets_txd", > > >> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "good_octets_txd", > > >> CTLFLAG_RD, &adapter->stats.gotc, > > >> "Good Octets Transmitted"); > > >> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, > "total_pkts_txd", > > >> > > >> -- > > >> ------------------- > > >> 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/ > > >> > > > > > > > > > -- > > ------------------- > > 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/ > > > > _______________________________________________ > > 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 Feb 4 22:33:43 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 9D12F1065673; Fri, 4 Feb 2011 22:33:43 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id 2048B8FC0C; Fri, 4 Feb 2011 22:33:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=urdHBbmWTSm/RMH/pLGg6FykhOTNB+/T2xZWfjQJ9/E=; b=tGX+XkveJ8PXpR0lrbNkaLWI3cdgKarBSBebKdeBcZoJf3zSjnn9Dhi+sXI7qzbibJvCpCuM/jTh9KOCcv0EBleRDg3FQ+ZPBvnztuTRC5f4DZjCzB7wH7wRak/KW4N0pSCGRjTeWKwHMX/r0Anw3aD/8L6zS1m69RAB36jgCG8=; Received: from alex by mail.zagrebin.ru with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PlUDk-0003d7-IA; Sat, 05 Feb 2011 01:33:40 +0300 Date: Sat, 5 Feb 2011 01:33:40 +0300 From: Alexander Zagrebin To: Bernhard Schmidt Message-ID: <20110204223339.GA12555@gw.zagrebin.ru> References: <20110204060808.GA97298@gw.zagrebin.ru> <201102040951.34201.bschmidt@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline In-Reply-To: <201102040951.34201.bschmidt@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: if_run in hostap mode: issue with stations in the power save mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 22:33:43 -0000 --s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote: > On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote: > > I'm using an Ralink RT2870 based adapter (run(4) driver) in the > > hostap mode. and I've noticed that if_run doesn't support stations > > working in the power save mode (PSM). The reason is in lack of the > > TIM in beacons. The attached patch adds this functionality and > > completely fixes this issue. Despite the fact that patch is working, > > it seems that it needs an additional work. For example, now the > > result of ieee80211_beacon_update is ignored with a corresponding > > message, but may be necessary to process it... > > > > Can somebody review it? > > That looks about right, good catch! > > Handling ieee80211_beacon_update()'s return value doesn't seem to be > necessary, the mbuf's length is handled in the next few lines of code > anyways, doesn't matter if it changed or not. > > Though, I have a some doubts about just restoring bo_flags is enough > (Can't prove that with some obvious code, still..). It feels saner to me > if we just reuse the whole mbuf, similar to what ath(4) does. Can you > look at attached patch? Completely untested, so I'm not sure what does > happen on e.g. changing the SSID. I've tried the slightly modified version of your patch (see attached files), and found that it is working too. Moreover, it looks more safe. For example, suppose we need update the beacon due to a new TIM. Immediately after updating, but before the beacon with a TIM will be transmitted, we need update the beacon again for any other reason. With the first version of the patch the beacon will completely recreated, so a TIM will be lost. But if we are using the second version of the patch, then TIM will be preserved. I had the doubts about ability to change or hide/unhide the SSID, but it works too. It seems that after `ifconfig wlan0 ssid ...` or `ifconfig wlan0 (hidessid|-hidessid)` the following occurs: 1. run_newstate() is called 2. run_newstate() invokes run_update_beacon_cb() 3. run_update_beacon_cb() invokes ieee80211_beacon_update() But I couldn't understand where ieee80211_beacon_update() can change a SSID... -- Alexander Zagrebin --s2ZSL+KKDSLx8OML Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="patch-if_run.c" --- sys/dev/usb/wlan/if_run.c.orig 2011-01-21 08:28:14.000000000 +0300 +++ sys/dev/usb/wlan/if_run.c 2011-02-04 21:01:38.659409262 +0300 @@ -856,6 +856,8 @@ RUN_LOCK(sc); + m_freem(rvp->beacon_mbuf); + rvp_id = rvp->rvp_id; sc->ratectl_run &= ~(1 << rvp_id); sc->rvp_bmap &= ~(1 << rvp_id); @@ -3903,6 +3905,7 @@ struct run_softc *sc = ic->ic_ifp->if_softc; uint32_t i; + setbit(RUN_VAP(vap)->bo.bo_flags, item); i = RUN_CMDQ_GET(&sc->cmdq_store); DPRINTF("cmdq_store=%d\n", i); sc->cmdq[i].func = run_update_beacon_cb; @@ -3916,6 +3919,7 @@ run_update_beacon_cb(void *arg) { struct ieee80211vap *vap = arg; + struct run_vap *rvp = RUN_VAP(vap); struct ieee80211com *ic = vap->iv_ic; struct run_softc *sc = ic->ic_ifp->if_softc; struct rt2860_txwi txwi; @@ -3925,8 +3929,14 @@ if (vap->iv_bss->ni_chan == IEEE80211_CHAN_ANYC) return; - if ((m = ieee80211_beacon_alloc(vap->iv_bss, &RUN_VAP(vap)->bo)) == NULL) - return; + if (rvp->beacon_mbuf == NULL) { + m = ieee80211_beacon_alloc(vap->iv_bss, &rvp->bo); + if (m == NULL) return; + rvp->beacon_mbuf = m; + } else { + m = rvp->beacon_mbuf; + ieee80211_beacon_update(vap->iv_bss, &rvp->bo, m, 1); + } memset(&txwi, 0, sizeof txwi); txwi.wcid = 0xff; @@ -3941,13 +3951,11 @@ txwi.flags = RT2860_TX_TS; txwi.xflags = RT2860_TX_NSEQ; - run_write_region_1(sc, RT2860_BCN_BASE(RUN_VAP(vap)->rvp_id), + run_write_region_1(sc, RT2860_BCN_BASE(rvp->rvp_id), (uint8_t *)&txwi, sizeof txwi); - run_write_region_1(sc, RT2860_BCN_BASE(RUN_VAP(vap)->rvp_id) + sizeof txwi, + run_write_region_1(sc, RT2860_BCN_BASE(rvp->rvp_id) + sizeof txwi, mtod(m, uint8_t *), (m->m_pkthdr.len + 1) & ~1); /* roundup len */ - m_freem(m); - return; } --s2ZSL+KKDSLx8OML Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="patch-if_runvar.h" --- sys/dev/usb/wlan/if_runvar.h.orig 2010-11-20 10:22:53.446928634 +0300 +++ sys/dev/usb/wlan/if_runvar.h 2011-02-04 20:03:08.090731320 +0300 @@ -121,6 +121,7 @@ struct run_vap { struct ieee80211vap vap; struct ieee80211_beacon_offsets bo; + struct mbuf *beacon_mbuf; int (*newstate)(struct ieee80211vap *, enum ieee80211_state, int); --s2ZSL+KKDSLx8OML-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 4 23:06:17 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 6904E106566B; Fri, 4 Feb 2011 23:06:17 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id 134918FC18; Fri, 4 Feb 2011 23:06:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=vZRtbUH4V9O+kiusX6gxIEcKf06lurdWzXLMyvKmWjw=; b=tIfqVqJF7xs/KE15CQgVyoo6VmWo25jKz57gi/oTrZlo9zLUfxWbwDyoT7S999VXUz1PaeBRAMYc0Q5Amh6D28gLBRyKcOsRgC10FO0/DwYJv5665bJxMv/uEiLKUHUPq4td1LWEzolXAN8duVKM69Rh1bW0flosPOztQrC7YN8=; Received: from alex by mail.zagrebin.ru with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PlUjH-0003kS-S8; Sat, 05 Feb 2011 02:06:15 +0300 Date: Sat, 5 Feb 2011 02:06:15 +0300 From: Alexander Zagrebin To: Bernhard Schmidt Message-ID: <20110204230615.GB12555@gw.zagrebin.ru> References: <20110204060808.GA97298@gw.zagrebin.ru> <201102040951.34201.bschmidt@freebsd.org> <20110204114021.GA237@gw.zagrebin.ru> <201102041314.17939.bschmidt@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102041314.17939.bschmidt@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: if_run in hostap mode: issue with stations in the power save mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 23:06:17 -0000 Hi! On 04.02.2011 13:14:17 +0100, Bernhard Schmidt wrote: > > Also I have to note, that it seems that other wlan drivers can has > > this problem too: only ral's and ath's code uses > > ieee80211_beacon_update(). > > Yeah, true. > > > Also, I've found a kern/124753. One of > > replies contains a log's fragment with many records, like following: > > kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's in ps > > mode kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now > > queued kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 > > now queued kernel: ath0: [00:18:41:c0:06:54] power save mode off, 0 > > sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] flush ps queue, 2 > > packets queue But there are no records, which have to be for a PSM > > enabled stations: When a beacon is properly updated, then we have to > > see records about 1. TIM updating, like > > ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1 > > 2. poll messages from a stations, like > > wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue > > empty > > > > Thanks for your cooperation! > > You mean there are missing debug messages in net80211/run? I meant, that when stations in the PSM are handled correctly, then the log contains a records like this: kernel: wlan0: [18:86:ac:10:4b:88] power save mode on, 1 sta's in ps mode kernel: wlan0: [18:86:ac:10:4b:88] save frame with age 8, 1 now queued kernel: wlan0: ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1 kernel: wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue empty kernel: wlan0: ieee80211_beacon_update: TIM updated, pending 0, off 0, len 1 But the log's fragment from the kern/124753 doesn't contain records with the text "...TIM updated..." and "...recv ps-poll...". I had the very similar records in the log with the unpatched if_run.c. -- Alexander Zagrebin From owner-freebsd-net@FreeBSD.ORG Sat Feb 5 00:34: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 22B881065675 for ; Sat, 5 Feb 2011 00:34:28 +0000 (UTC) (envelope-from prabhuh@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 D51518FC0C for ; Sat, 5 Feb 2011 00:34:27 +0000 (UTC) Received: by yxh35 with SMTP id 35so1194596yxh.13 for ; Fri, 04 Feb 2011 16:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=5nGdHwcnUUHKAlbFKpTmhpsNmx6R4xck+LIh7NWuOCw=; b=bbjEDStuC2nnLiF7cdJ6JHD0NoPVBcT3uEyxfs7jmnBfapanR2v/19KuzdHYthoJJq vYF4SjGPM+co4Coz8ZcwKz3tJ5WGl93iueko1lLj+HMNHYjeMVNTdMTiyTKxdCseTyli aNIBPMGl0sCR61xfQprQW38TrIvUN02rVMWqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AGrHjB7u9ny6Sb6Vip4IrnOnM+sA5ZdUMYFLv61By8DZO1+mv1bRZ82r6pYph6DrYK FtIq62VWKYo2PIHg4evTPBawPZt5BBr870BpOdYuPGf8wxjkIo0OSMgxfcyksKLQTwAb X/sdrkLUtHZpbslVgGJSC4tmMaMP1HByMr2io= MIME-Version: 1.0 Received: by 10.100.131.4 with SMTP id e4mr1666457and.59.1296864184709; Fri, 04 Feb 2011 16:03:04 -0800 (PST) Received: by 10.100.38.14 with HTTP; Fri, 4 Feb 2011 16:03:04 -0800 (PST) Date: Fri, 4 Feb 2011 16:03:04 -0800 Message-ID: From: Prabhu Hariharan To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Connections not purged on address deletion 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, 05 Feb 2011 00:34:28 -0000 Hi, When I delete an IP-address from an interface, the TCP (and other) connections using that local IP-address are not getting purged. The telnet or ssh sessions on the other end just get hung, as FreeBSD address-deletion doesn't handle this situation and fails to call pfctlinput() to notify protocols on this event. The TCP connections simply linger in the system and takes it due course on TCP timers to free those inpcbs. tcp4 0 0 30.30.30.31.22 30.30.30.30.58796 ESTABLISHED Is this by design? Or any significance on relying on applications intelligently to do timeouts, without a notification from network layer? Thanks, Prabhu H From owner-freebsd-net@FreeBSD.ORG Sat Feb 5 00:42: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 C5282106566C for ; Sat, 5 Feb 2011 00:42:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 995268FC16 for ; Sat, 5 Feb 2011 00:42:59 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p150gr49026770 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 16:42:58 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D4C9D10.4040308@freebsd.org> Date: Fri, 04 Feb 2011 16:42:56 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Prabhu Hariharan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Connections not purged on address deletion 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, 05 Feb 2011 00:42:59 -0000 On 2/4/11 4:03 PM, Prabhu Hariharan wrote: > Hi, > > When I delete an IP-address from an interface, the TCP (and other) > connections using that local IP-address are not getting purged. The telnet > or ssh sessions on the other end just get hung, as FreeBSD address-deletion > doesn't handle this situation and fails to call pfctlinput() to notify > protocols on this event. The TCP connections simply linger in the system > and takes it due course on TCP timers to free those inpcbs. > > tcp4 0 0 30.30.30.31.22 30.30.30.30.58796 > ESTABLISHED > > Is this by design? Or any significance on relying on applications > intelligently to do timeouts, without a notification from network layer? theoretically if you move the address to another interface it should start working again assuming the routing is correct. It's mostly by design. If you want to get rid of them you might try to add a firewall rule to send them resets. I don't know what other systems do. > Thanks, > Prabhu H > _______________________________________________ > 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 Sat Feb 5 00:56: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 50527106564A for ; Sat, 5 Feb 2011 00:56:23 +0000 (UTC) (envelope-from prabhuh@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 0BFEB8FC08 for ; Sat, 5 Feb 2011 00:56:22 +0000 (UTC) Received: by ywp6 with SMTP id 6so1202723ywp.13 for ; Fri, 04 Feb 2011 16:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oXQsmVMgqOM7TiEljYhKGU7BdCCEz7HmE+xjlX1fTSM=; b=div6RAYNOupHOw1pj7dLTb/c4ZWqRQQ/yk2Y6KiMViXVIhOhvnbwCxu2O2qT9eRpEX /+Lc/1Z7v/c7Qxa/CPpQDv6aSkmO6GehKDsHrnwhXpNJHMWYxHsJmea0Hw3qTLtY7mjF O9WQYiQox2JAQ4RJuzvUWESFF8GBnxrl83BL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SUmLIm2W9WuZ/ZA89GIZemNZR1z8Q67v957vjblhb/8O1+aTEJysXZJJFT1b4cPi+O QP2NRuxLdaGtypHHdi99Dhs22Pd+GXzqrT5m5L94X9mBGFvyspY28MlTuYwEbQKf7/7w axKPuDrCi2Zl5+3FroWpvupt61ao3kQd7Lk40= MIME-Version: 1.0 Received: by 10.100.167.2 with SMTP id p2mr425441ane.195.1296867380950; Fri, 04 Feb 2011 16:56:20 -0800 (PST) Received: by 10.100.38.14 with HTTP; Fri, 4 Feb 2011 16:56:20 -0800 (PST) In-Reply-To: <4D4C9D10.4040308@freebsd.org> References: <4D4C9D10.4040308@freebsd.org> Date: Fri, 4 Feb 2011 16:56:20 -0800 Message-ID: From: Prabhu Hariharan To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Connections not purged on address deletion 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, 05 Feb 2011 00:56:23 -0000 Thanks for the reply. I think, atleast system should have some option/sysctl (without individual firewall rules) to enable the purging of connections which are simply dormant when address get removed (not intended to move address to other interface). On Fri, Feb 4, 2011 at 4:42 PM, Julian Elischer wrote: > On 2/4/11 4:03 PM, Prabhu Hariharan wrote: > >> Hi, >> >> When I delete an IP-address from an interface, the TCP (and other) >> connections using that local IP-address are not getting purged. The >> telnet >> or ssh sessions on the other end just get hung, as FreeBSD >> address-deletion >> doesn't handle this situation and fails to call pfctlinput() to notify >> protocols on this event. The TCP connections simply linger in the system >> and takes it due course on TCP timers to free those inpcbs. >> >> tcp4 0 0 30.30.30.31.22 30.30.30.30.58796 >> ESTABLISHED >> >> Is this by design? Or any significance on relying on applications >> intelligently to do timeouts, without a notification from network layer? >> > > theoretically if you move the address to another interface it should start > working again assuming the routing is correct. > It's mostly by design. If you want to get rid of them you might try to > add a firewall rule to send them resets. > I don't know what other systems do. > > Thanks, >> Prabhu H >> _______________________________________________ >> 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 Sat Feb 5 01:51: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 2391C106566B; Sat, 5 Feb 2011 01:51:33 +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 C2A7E8FC14; Sat, 5 Feb 2011 01:51:32 +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.4/8.14.4) with ESMTP id p151pUgr033611 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 20:51:30 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D4CAD16.2030502@sentex.net> Date: Fri, 04 Feb 2011 20:51:18 -0500 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: Sean Bruno References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Jack Vogel , Jan Koum , Ivan Voras Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 05 Feb 2011 01:51:33 -0000 On 2/4/2011 1:09 PM, Sean Bruno wrote: > Any more data on this problem or do we have to wait a while? On my RELENG_8 production box, so far so good. It usually would hang on weekend runs, so tomorrow would be a good sign, but not a proof that its fixed as it has on occasion survived a few weeks in a row. I am running the version Jack posted with the one change Sean suggested and is at http://www.tancsa.com/if_em-8.c I am also using all default options for the two onboard nics em0: flags=8843 metric 0 mtu 1500 options=219b em1: flags=8843 metric 0 mtu 1500 options=219b 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 pci10 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:ed:68:a4 em0: link state changed to UP em1: link state changed to UP ---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 Sat Feb 5 04:46: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 39ECD1065673 for ; Sat, 5 Feb 2011 04:46:02 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web39304.mail.mud.yahoo.com (web39304.mail.mud.yahoo.com [66.94.238.171]) by mx1.freebsd.org (Postfix) with SMTP id AE87D8FC15 for ; Sat, 5 Feb 2011 04:46:01 +0000 (UTC) Received: (qmail 93959 invoked by uid 60001); 5 Feb 2011 04:46:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1296881160; bh=huFq3B+d8Eld5CCrgFdpYSodmsTr97yM/LFES3p+RY0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wESb59pHQVQp+T2uvNBeMBnyB/jIIilVBh7GQrsIRH3igGzLjR0/Ro+UvQ/8C+1RJDVlRaXUXoYXXrEhcVv0uNONmREzlBlNGM1eowiFi5RQ3bAUFak39yviHVqfOJGeiX4IT6o0Ks5chL/ekXx+nwC0ot9ThmQYMyuIjfluRlQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LxU1pv6AOEdRPpW949z1XCEeK6q9xsfWuuQxyr3IqRby/NSYDqFO80+9ASbFEHzfNJDeyxGqDYQPTFmhq1CnW2B5W0Lrrx+Kx5hbYAE6tf37F0z/OHYhM9jsQgkXhTe87+imPx8VVkefSolUOUfViN42vIcQKNtEYYwkAL2X7TI=; Message-ID: <147585.89029.qm@web39304.mail.mud.yahoo.com> X-YMail-OSG: PfvUXvwVM1m_bQE7lOxJtqz3_deMaiyX6h1PG6X_rLnxR_F sEQzbZVV2zpFwaIANachdYFdO8o_.OF6C2maWE7EoFnCmc9ikPVUYRlT1Ftx z.mcnMQqwFB7gtT50fgfX_yPurAUs1kxTAsje4wxorZOpuTqqacY28NMKkRM lCxotUkHRW4.sfSb.jqmr6QlnQ9v11E0pUdveKvYQVK8yU7lZ6dVIWAKSoXq i1FI41TSeb69Ll9y0WBbcfq3Rrp5sblf0x7Vt5ox7LQB_r8E0ouzXY8dYdU5 pCgH77w4NvLXqnFXXUiJgK23eqHa8SIre2HD8OAIykMtSX9d5h_WS Received: from [206.75.146.55] by web39304.mail.mud.yahoo.com via HTTP; Fri, 04 Feb 2011 20:45:59 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.108.291010 References: <20110204060808.GA97298@gw.zagrebin.ru> <201102040951.34201.bschmidt@freebsd.org> <20110204114021.GA237@gw.zagrebin.ru> <201102041314.17939.bschmidt@freebsd.org> Date: Fri, 4 Feb 2011 20:45:59 -0800 (PST) From: PseudoCylon To: Bernhard Schmidt , Alexander Zagrebin In-Reply-To: <201102041314.17939.bschmidt@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org Subject: Re: if_run in hostap mode: issue with stations in the power save mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 04:46:02 -0000 ----- Original Message ---- > From: Bernhard Schmidt > To: Alexander Zagrebin > Cc: freebsd-net@freebsd.org; PseudoCylon > Sent: Fri, February 4, 2011 5:14:17 AM > Subject: Re: if_run in hostap mode: issue with stations in the power save mode > > On Friday 04 February 2011 12:40:21 Alexander Zagrebin wrote: > > Hi! > > > > On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote: > > > On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote: > > > > I'm using an Ralink RT2870 based adapter (run(4) driver) in the > > > > hostap mode. and I've noticed that if_run doesn't support > > > > stations working in the power save mode (PSM). The reason is in > > > > lack of the TIM in beacons. The attached patch adds this > > > > functionality and completely fixes this issue. Despite the fact > > > > that patch is working, it seems that it needs an additional > > > > work. For example, now the result of ieee80211_beacon_update is > > > > ignored with a corresponding message, but may be necessary to > > > > process it... > > > > > > > > Can somebody review it? > > > > > > That looks about right, good catch! > > > > > > Handling ieee80211_beacon_update()'s return value doesn't seem to > > > be necessary, the mbuf's length is handled in the next few lines > > > of code anyways, doesn't matter if it changed or not. > > > > > > Though, I have a some doubts about just restoring bo_flags is > > > enough (Can't prove that with some obvious code, still..). It > > > feels saner to me if we just reuse the whole mbuf, similar to what > > > ath(4) does. Can you look at attached patch? Completely untested, > > > so I'm not sure what does happen on e.g. changing the SSID. > > > > I've thought about such solution, and it looks more right, but I've > > decided just to add ieee80211_beacon_update() to make the patch > > clear. I'll try your patch a bit later, but I already have a > > question: on the first invocation of the run_update_beacon_cb() only > > ieee80211_beacon_alloc() will be called. So dynamic beacon contents > > will not updated. Is it a problem? > > I don't think it is. The work beacon_update does is handling changes to > bo_flags, which are only changed through calls to iv_update_beacon(), so > this is safe, because the driver itself does change bo_flags which is > immediately followed by the beacon update process. > I like the way mwl(4) handles it. http://fxr.watson.org/fxr/source/dev/mwl/if_mwl.c#L1927 though I don't know why it uses ieee80211_beacon_alloc() instead of _update() @@run_update_beacon(struct ieee80211vap *vap, int item) struct run_vap *rvp = RUN_VAP(vap); +int mcast = 0; uint32_t i; +KASSERT(vap != NULL, ("no beacon")); + +switch (item) { +case IEEE80211_BEACON_ERP: +run_updateslot(ic->ic_ifp); +break; +case IEEE80211_BEACON_HTINFO: +run_updateprot(ic); +break; +case IEEE80211_BEACON_TIM: +mcast = 1;/*TODO*/ +break; +default: + break; } +setbit(rvp->bo.bo_flags, item); +ieee80211_beacon_update(vap->iv_bss, &rvp->bo, rvp->bm, mcast); + i = RUN_CMDQ_GET(&sc->cmdq_store); DPRINTF("cmdq_store=%d\n", i); sc->cmdq[i].func = run_update_beacon_cb; It's been working fine updating protection mode in HT mode past a few days. (Some how, iwn(4) works fine with run(4), I cannot tell it works fin with power saving mode.) I'd like to move ieee80211_beacon_alloc() into iv_vap_alloc(). Then we don't need to test beacon_mbuf == NULL in run_update_beacon_cb(), and there is already switch we can use for conditionally alloc mem. > There is one expection I'm not sure about how to handle though, > slottime. This value might change based on nodes associating and > leaving, resulting in a call to ic_updateslot() which is currently > commentted out. > That's only because of LOR. I'm adding another call back function since run_updateprot() need to be deferred when it is called from run_update_beacon(). AK From owner-freebsd-net@FreeBSD.ORG Sat Feb 5 08:57:18 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 BFDB91065674; Sat, 5 Feb 2011 08:57:18 +0000 (UTC) (envelope-from weongyo.jeong@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 5E93D8FC0C; Sat, 5 Feb 2011 08:57:18 +0000 (UTC) Received: by gyf3 with SMTP id 3so1266768gyf.13 for ; Sat, 05 Feb 2011 00:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :mail-followup-to:mime-version:content-type:content-disposition :user-agent:organization:x-operation-sytem; bh=67d7FL37dm0SjfqUMQ51GBPcz3qznDCPKL7VcfJlqwU=; b=llG86fLmC5wYX6uov08g7GrYSgns7xWOCL9z31ae+1KBPMnM0jZUAgMQjkfe562rP+ iQ+tn2hcSOIUkQ1kchBGp+KzOZJqYi1XBLwsIC8L60bAX/DZFdhxiBHkWoWmVwPEr8Q4 Zg0Vsn3gn17QS9nq0ZtG3mwgFzURLuT8JEvrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :mime-version:content-type:content-disposition:user-agent :organization:x-operation-sytem; b=qwbTOhtnd+6tYWy8UR9Hx941zyfhfBs4ZovrcenyQsx4yPYopZ9/KVJERr99KZl21z y8HCdFSZvXCXML/MFHMGoTsTCMK3ozwzgsqcTFskqZN8MXs3Yc18laTFgdnYzBHCIF0S D7Sgcas9dY9SNf1q9hR/FDPvJfWYcIl3Y46D8= Received: by 10.90.51.9 with SMTP id y9mr16570851agy.124.1296894892077; Sat, 05 Feb 2011 00:34:52 -0800 (PST) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id x31sm2075890ana.29.2011.02.05.00.34.48 (version=SSLv3 cipher=RC4-MD5); Sat, 05 Feb 2011 00:34:50 -0800 (PST) Received: by weongyo (sSMTP sendmail emulation); Sat, 05 Feb 2011 00:36:21 -0800 From: Weongyo Jeong Date: Sat, 5 Feb 2011 00:36:21 -0800 To: freebsd-current@freebsd.org Message-ID: <20110205083620.GA60200@weongyo> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-net@freebsd.org Subject: [CFR] Forward RTO recovery algorithm (rfc5682) patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 08:57:18 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This patch is *VERY* experimental patch to implement rfc5862 which is on the IETF standard tracks so it could be completely wrong or has a lot of bugs on it or wrong approaches because I'm a really newbie on TCP stack. This patch includes two features to support `Basic FRTO algorithm' and `SACK-Enhanced FRTO algorithm' but not including a feature to support things mentioned at `Appendix A'. I'm looking for reviewers teaching me where it's wrong or what the approach was bad on line by line. However any comments are welcome. The patch is available at: http://people.freebsd.org/~weongyo/patch_tcpfrto_20110205.diff regards, Weongyo Jeong --XsQoSWH+UP9D9v3l Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch_tcpfrto_20110205.diff" Index: netinet/tcp_input.c =================================================================== --- netinet/tcp_input.c (revision 218148) +++ netinet/tcp_input.c (working copy) @@ -161,6 +161,11 @@ &VNET_NAME(tcp_abc_l_var), 2, "Cap the max cwnd increment during slow-start to this number of segments"); +VNET_DEFINE(int, tcp_do_rfc5682) = 1; +SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, rfc5682, CTLFLAG_RW, + &VNET_NAME(tcp_do_rfc5682), 0, + "Enable RFC 5682 (Forward RTO-Recovery: F-RTO)"); + SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, "TCP ECN"); VNET_DEFINE(int, tcp_do_ecn) = 0; @@ -254,6 +259,212 @@ } } +/* revert to the conventional RTO recovery. */ +#define TCP_FRTO_REVERT(tp) do { \ + (tp)->frto_flags = 0; \ +} while (0) + +static int +tcp_frto_send2mss(struct tcpcb *tp, struct tcphdr *th, uint16_t type) +{ + struct inpcb *inp = tp->t_inpcb; + struct socket *so = inp->inp_socket; + u_long oldcwnd; + tcp_seq onxt; + + /* + * XXXWG If the TCP sender does not have any new data to send, OR the + * advertised window prohibits new transmissions, the recommended + * action is to skip step 3 of this algorithm and continue with + * slow-start retransmissions, following the conventional RTO recovery + * algorithm. However, alternative ways of handling the window-limited + * cases that could result in better performance are discussed in + * Appendix A. + */ + if (so->so_snd.sb_cc == 0 || tp->snd_wnd == 0) + /* XXXWG skip step 3 OR do alternative ways. */ + return (1); + oldcwnd = tp->snd_cwnd; + onxt = tp->snd_nxt; + /* + * XXXWG transmit up to two new (previously unsent) segments and enter + * step 3 of this algorithm. If the TCP sender does not have enough + * unsent data, it can send only one segment. + */ + tp->snd_cwnd = 2 * tp->t_maxseg; + tp->snd_nxt = tp->snd_max; + /* + * XXXWG in addition, the TCP sender MAY override the Nagle algorithm. + */ + tp->t_flags |= TF_ACKNOW; + (void) tcp_output(tp); + tp->snd_nxt = onxt; + tp->snd_cwnd = oldcwnd; + return (0); +} + +static void inline +tcp_frto_ack_received(struct tcpcb *tp, struct tcphdr *th, uint16_t type) +{ + + /* SACK-Enhanced F-RTO */ + + if (tp->t_flags & TF_SACK_PERMIT) { + if ((tp->frto_flags & FRTO_INSTEP1) != 0 && + (tp->frto_flags & FRTO_CANGOSTEP2) != 0) { + /* SACK-Enhanced F-RTO - step 2 */ + if (type == CC_DUPACK) + /* + * 2) If duplicate ACKs arrive before the + * cumulative acknowledgment for retransmitted + * data, adjust the scoreboard according to + * the incoming SACK information. Stay in + * step 2 and wait for the next new + * acknowledgment. + */ + return; + KASSERT(type == CC_ACK, + ("%s: expected ACK (but %d)", __func__, type)); + + /* + * 2) When a new acknowledgment arrives, set variable + * "RecoveryPoint" to indicate the highest sequence + * number transmitted so far. + */ + tp->frto_flags |= FRTO_INSTEP2; + tp->snd_recover = tp->snd_max; + + /* + * 2a) If the Cumulative Acknowledgement field covers + * "RecoveryPoint" but not more than + * "RecoveryPoint", revert to the conventional RTO + * recovery and set the congestion window to no + * more than 2 * MSS, like a regular TCP would do. + * Do not enter step 3 of this algorithm. + */ + if (th->th_ack == tp->snd_recover) { + tp->snd_cwnd = 2 * tp->t_maxseg; + TCP_FRTO_REVERT(tp); + return; + /* + * 2b) If the Cumulative Acknowledgment field does not + * cover "RecoveryPoint" but is larger than + * SND.UNA. + */ + } else if (SEQ_LT(th->th_ack, tp->snd_recover) && + SEQ_GT(th->th_ack, tp->snd_una) && + !tcp_frto_send2mss(tp, th, type)) { + tp->frto_flags |= FRTO_CANGOSTEP3; + tp->frto_fack = tp->snd_fack; + } + } + if ((tp->frto_flags & FRTO_INSTEP2) != 0 && + (tp->frto_flags & FRTO_CANGOSTEP3) != 0) { + struct sackhole *q = TAILQ_FIRST(&tp->snd_holes); + /* the Cumulative Acknowledgment */ + tcp_seq cack = SEQ_MAX(th->th_ack, tp->snd_una); + + /* + * XXXWG 3a) If the Cumulative Acknowledgment field or + * the SACK information covers more than + * "RecoveryPoint". + */ + if (SEQ_GEQ(cack, tp->snd_recover) || + (q != NULL && SEQ_GT(q->start, tp->snd_recover))) + goto frto_revert; + /* + * XXXWG 3a) take this branch also when the + * acknowledgment is a duplicate ACK and it does not + * acknowledge any new, previously unacknowledged + * data below "RecoveryPoint" in the SACK information. + * + * FIXME At this implementation there is a limitation + * that it doesn't traverse all SACK information below + * "RecoveryPoint". So needs to implement a simple way + * to check whether SACK information is updated or not + * after receiving this ACK. + */ + if (type == CC_DUPACK && + SEQ_LEQ(tp->snd_fack, tp->snd_recover) && + SEQ_LEQ(tp->snd_fack, tp->frto_fack)) { +frto_revert: + tp->snd_cwnd = 3 * tp->t_maxseg; + TCP_FRTO_REVERT(tp); + return; + } + /* + * XXXWG 3b) If the Cumulative Acknowledgment field or a + * SACK information in the ACK does not cover more than + * "RecoveryPoint" AND it acknowledges data that was + * not acknowledged earlier, declare the timeout + * spurious. + */ + if (type == CC_ACK && + (SEQ_LEQ(cack, tp->snd_recover) || + (q != NULL && + SEQ_LT(q->start, tp->snd_recover)))) + /* SPUR_TO: the timeout is spurious */ + tp->snd_recover = tp->snd_una; + } + return; + } + + /* + * Basic F-RTO algorithm + */ + + if ((tp->frto_flags & FRTO_INSTEP1) != 0 && + (tp->frto_flags & FRTO_CANGOSTEP2) != 0) { + /* Basic F-RTO - step 2 */ + tp->frto_flags |= FRTO_INSTEP2; + tp->snd_recover = tp->snd_max; + + if (type == CC_DUPACK || + /* + * XXXWG The acknowledgment field covers "recover" but not + * more than "recover" + */ + th->th_ack == tp->snd_recover || + /* + * XXXWG acknowledgement does not acknowledge all of + * the data that was retransmitted in step 1. + */ + SEQ_LEQ(th->th_ack, tp->snd_una)) + TCP_FRTO_REVERT(tp); + else if (type == CC_ACK && + /* + * XXXWG Acknowledgement field does not cover + * "recover" + */ + SEQ_LT(th->th_ack, tp->snd_recover) && + !tcp_frto_send2mss(tp, th, type)) + tp->frto_flags |= FRTO_CANGOSTEP3; + else + TCP_FRTO_REVERT(tp); + } + if ((tp->frto_flags & FRTO_INSTEP2) != 0 && + (tp->frto_flags & FRTO_CANGOSTEP3) != 0) { + /* Basic F-RTO - step 3 */ + if (type == CC_DUPACK) { + /* + * XXXWG set the congestion window to no more + * than 3 * MSS (where MSS indicates Maximum + * Segment Size), and continue with the + * slow-start algorithm retransmitting + * unacknowledged segments. The congestion + * window can be set to 3 * MSS, because two + * round-trip times have elapsed since the TRO, + * and a conventional TCP sender would have + * increased cwnd to 3 during the same time. + */ + tp->snd_cwnd = 3 * tp->t_maxseg; + TCP_FRTO_REVERT(tp); + } else if (type == CC_ACK) + /* SPUR_TO: the timeout is spurious */ + tp->snd_recover = tp->snd_una; + } +} + /* * CC wrapper hook functions */ @@ -262,6 +473,9 @@ { INP_WLOCK_ASSERT(tp->t_inpcb); + if (V_tcp_do_rfc5682) + tcp_frto_ack_received(tp, th, type); + tp->ccv->bytes_this_ack = BYTES_THIS_ACK(tp, th); if (tp->snd_cwnd == min(tp->snd_cwnd, tp->snd_wnd)) tp->ccv->flags |= CCF_CWND_LIMITED; Index: netinet/tcp_timer.c =================================================================== --- netinet/tcp_timer.c (revision 218148) +++ netinet/tcp_timer.c (working copy) @@ -60,6 +60,7 @@ #endif #include #include +#include #include #include #include @@ -556,8 +557,64 @@ tp->t_rttvar += (tp->t_srtt >> TCP_RTT_SHIFT); tp->t_srtt = 0; } + if (V_tcp_do_rfc5682) { + /* + * If the retrasmission timer expires again during + * the execution of the F-RTO algorithm, the TCP sender MUST + * re-start the algorithm processing from step 1. + */ + tp->frto_flags = FRTO_INSTEP1; + + /* + * If the sender implements some loss recovery algorithm + * other than Reno or NewReno [FHH04], the F-RTO algorithm + * SHOULD NOT be entered when earlier fast recovery is underway. + */ + if (CC_ALGO(tp) != &newreno_cc_algo && + IN_RECOVERY(tp->t_flags)) + goto no_rfc5682; + /* + * SACK-Enhanced F-RTO + * This algorithm SHOULD NOT be applied if the TCP sender is + * already in loss recovery when a retransmission timeout + * occurs. + */ + if ((tp->t_flags & TF_SACK_PERMIT) != 0 && + IN_RECOVERY(tp->t_flags)) + goto no_rfc5682; + + /* + * Basic F-RTO algorithm - step 1: if the TCP sender is already + * in RTO recovery AND "recover" is larger than or equal to + * SND.UNA (the oldest unacknowledged sequence number [Pos81]), + * do not enter step 2 of this algorithm. Instead, store the + * highest sequence number transmitted so far in variable + * "recover". + */ + if ((tp->t_flags & TF_SACK_PERMIT) == 0 && + tp->t_rxtshift > 0 && + SEQ_GEQ(tp->snd_recover, tp->snd_una)) + /* + * continue with slow-start retransmissions following + * the conventional RTO recovery algorithm. + */ + goto no_rfc5682; + /* + * SACK-Enhanced F-RTO - step 1: If "RecoveryPoint" is larger + * than or equal to SND.UNA, do not enter step 2 of this + * algorithm. + */ + else if ((tp->t_flags & TF_SACK_PERMIT) != 0 && + SEQ_GEQ(tp->snd_recover, tp->snd_una)) + goto no_rfc5682; + else + tp->frto_flags |= FRTO_CANGOSTEP2; + } else { +no_rfc5682: + tp->snd_recover = tp->snd_max; + } tp->snd_nxt = tp->snd_una; - tp->snd_recover = tp->snd_max; + /* * Force a segment to be sent. */ Index: netinet/tcp_var.h =================================================================== --- netinet/tcp_var.h (revision 218148) +++ netinet/tcp_var.h (working copy) @@ -202,6 +202,12 @@ struct cc_algo *cc_algo; /* congestion control algorithm */ struct cc_var *ccv; /* congestion control specific vars */ struct osd *osd; /* storage for Khelp module data */ + u_int frto_flags; /* step flags for RFC5682 where it's */ +#define FRTO_INSTEP1 (1 << 0) +#define FRTO_CANGOSTEP2 (1 << 1) +#define FRTO_INSTEP2 (1 << 2) +#define FRTO_CANGOSTEP3 (1 << 3) + tcp_seq frto_fack; /* previous snd_fack at step 1 */ int t_ispare; /* explicit pad for 64bit alignment */ void *t_pspare2[4]; /* 4 TBD */ @@ -602,6 +608,7 @@ VNET_DECLARE(int, ss_fltsz_local); VNET_DECLARE(int, tcp_do_rfc3465); VNET_DECLARE(int, tcp_abc_l_var); +VNET_DECLARE(int, tcp_do_rfc5682); #define V_tcb VNET(tcb) #define V_tcbinfo VNET(tcbinfo) #define V_tcpstat VNET(tcpstat) @@ -614,6 +621,7 @@ #define V_ss_fltsz_local VNET(ss_fltsz_local) #define V_tcp_do_rfc3465 VNET(tcp_do_rfc3465) #define V_tcp_abc_l_var VNET(tcp_abc_l_var) +#define V_tcp_do_rfc5682 VNET(tcp_do_rfc5682) VNET_DECLARE(int, tcp_do_sack); /* SACK enabled/disabled */ VNET_DECLARE(int, tcp_sc_rst_sock_fail); /* RST on sock alloc failure */ --XsQoSWH+UP9D9v3l-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 5 12:23: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 4525C1065670 for ; Sat, 5 Feb 2011 12:23:49 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id B7C628FC12 for ; Sat, 5 Feb 2011 12:23:48 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id p15CNkjj077781 for ; Sat, 5 Feb 2011 14:23:46 +0200 (EET) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id p15CNksU077780 for freebsd-net@freebsd.org; Sat, 5 Feb 2011 14:23:46 +0200 (EET) Date: Sat, 5 Feb 2011 14:23:46 +0200 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20110205122346.GE91679@relay.ibs.dn.ua> Mail-Followup-To: freebsd-net@freebsd.org References: <20101112070759.GA36248@relay.ibs.dn.ua> <20101112230000.GD22460@michelle.cdnetworks.com> <20110121125917.GA48950@relay.ibs.dn.ua> <20110130064048.GA14888@relay.ibs.dn.ua> <20110131012032.GD1323@michelle.cdnetworks.com> <20110131020720.GB1229@michelle.cdnetworks.com> <20110131121509.GE14888@relay.ibs.dn.ua> <20110131211346.GD1275@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110131211346.GD1275@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus@ibs.dn.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 12:23:49 -0000 Pyun YongHyeon (pyunyh@gmail.com) [11.01.31 23:14] wrote: > > Then I have no idea. Does other OS work with your hardware without > issues? As last resort, could you try vendor's FreeBSD driver? The > vendor's driver applies a bunch of magic DSP fixups which re(4) > does not have. I don't know whether it makes difference or not but > it would be worth a try. Note, vendor's driver treat your > controller as old 8139 such that it disables all offload features > and does not work on non-x86 architectures. > i386 exposes the same problem :( as for vendor's drivers, i didn't try them yet ... -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Sat Feb 5 13:49: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 F35EF1065670; Sat, 5 Feb 2011 13:49:09 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id A6B6F8FC13; Sat, 5 Feb 2011 13:49:08 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p15Dn4xM092068; Sat, 5 Feb 2011 19:49:05 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D4D554B.4050407@rdtc.ru> Date: Sat, 05 Feb 2011 19:48:59 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gleb Smirnoff References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> <20110201185026.GB62007@glebius.int.ru> In-Reply-To: <20110201185026.GB62007@glebius.int.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Alexander Motin , John Baldwin Subject: Re: panic: bufwrite: buffer is not busy??? 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, 05 Feb 2011 13:49:10 -0000 On 02.02.2011 00:50, Gleb Smirnoff wrote: > On Wed, Feb 02, 2011 at 12:30:20AM +0600, Eugene Grosbein wrote: > E> On 31.01.2011 14:20, Julian Elischer wrote: > E> > E> > replace with: > E> > > E> > 3504 if ((hook == NULL) || > E> > 3505 NG_HOOK_NOT_VALID(hook) || > E> > ((peer = NG_HOOK_PEER(hook)) == NULL) || > E> > 3506 NG_HOOK_NOT_VALID(peer) || > E> > ((peernode = NG_PEER_NODE(hook)) == NULL) || > E> > 3507 NG_NODE_NOT_VALID(peernode)) { > E> > if (peer) > E> > kassert((peernode != NULL), ("peer node NULL wile peer hook exists")); > E> > 3508 NG_FREE_ITEM(item); > E> > E> This day I have updated panicing router to RELENG_8 and combined changes supposed > E> by Julian and Gleb. After 8 hours it has just paniced again and could not finish > E> to write crashdump again: > E> > E> Fatal trap 12: page fault while in kernel mode > E> cpuid = 3; apic id = 06 > E> fault virtual address = 0x63 > E> fault code = supervisor read data, page not present > E> instruction pointer = 0x20:0xffffffff803d4ccd > E> stack pointer = 0x28:0xffffff80ebffc600 > E> frame pointer = 0x28:0xffffff80ebffc680 > E> code segment = base 0x0, limit 0xfffff, type 0x1b > E> = DPL 0, pres 1, long 1, def32 0, gran 1 > E> processor eflags = interrupt enabled, resume, IOPL = 0 > E> current process = 2390 (mpd5) > E> trap number = 12 > E> panic: page fault > E> cpuid = 3 > E> Uptime: 8h3m51s > E> Dumping 4087 MB (3 chunks) > E> chunk 0: 1MB (150 pages) ... ok > E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? > E> cpuid = 3 > E> Uptime: 8h3m52s > E> Automatic reboot in 15 seconds - press a key on the console to abort > E> > E> # gdb kernel > E> GNU gdb 6.1.1 [FreeBSD] > E> Copyright 2004 Free Software Foundation, Inc. > E> GDB is free software, covered by the GNU General Public License, and you are > E> welcome to change it and/or distribute copies of it under certain conditions. > E> Type "show copying" to see the conditions. > E> There is absolutely no warranty for GDB. Type "show warranty" for details. > E> This GDB was configured as "amd64-marcel-freebsd"... > E> (gdb) l *0xffffffff803d4ccd > E> 0xffffffff803d4ccd is in ng_pppoe_disconnect (netgraph.h:191). > E> 186 int line); > E> 187 > E> 188 static __inline void > E> 189 _chkhook(hook_p hook, char *file, int line) > E> 190 { > E> 191 if (hook->hk_magic != HK_MAGIC) { > E> 192 printf("Accessing freed hook "); > E> 193 dumphook(hook, file, line); > E> 194 } > E> 195 hook->lastline = line; > E> (gdb) x/i 0xffffffff803d4ccd > E> 0xffffffff803d4ccd : cmpl $0x78573011,0x64(%rbx) > > This looks like ng_pppoe_disconnect() was called with NULL argument. > > Can you add KDB_TRACE option to kernel? Your boxes for some reason can't > dump core, but with this option we will have at least trace. Same box, more panics with KDB_TRACE, NETGRAPGH_DEBUG and your patch and Julian's. First: again, no dump (not even started to dump, and no "Uptime:" written to console): Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0x20000006c fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803e5a6d stack pointer = 0x28:0xffffff80ec03d600 frame pointer = 0x28:0xffffff80ec03d680 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2390 (mpd5) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: X_db_sym_numargs() at 0xffffffff801a227a = X_db_sym_numargs+0x15a kdb_backtrace() at 0xffffffff8033d547 = kdb_backtrace+0x37 panic() at 0xffffffff8030b567 = panic+0x187 dblfault_handler() at 0xffffffff804c0ca0 = dblfault_handler+0x330 dblfault_handler() at 0xffffffff804c107f = dblfault_handler+0x70f trap() at 0xffffffff804c155f = trap+0x3df calltrap() at 0xffffffff804a8de4 = calltrap+0x8 --- trap 0xc, rip = 0xffffffff803e5a6d, rsp = 0xffffff80ec03d600, rbp = 0xffffff80ec03d680 --- ng_parse_get_token() at 0xffffffff803e5a6d = ng_parse_get_token+0x70cd ng_destroy_hook() at 0xffffffff803d53b2 = ng_destroy_hook+0x222 ng_rmnode() at 0xffffffff803d69bb = ng_rmnode+0x12ab ng_snd_item() at 0xffffffff803d8520 = ng_snd_item+0x3f0 ng_parse_get_token() at 0xffffffff803e97fa = ng_parse_get_token+0xae5a sosend_generic() at 0xffffffff80373df6 = sosend_generic+0x436 kern_sendit() at 0xffffffff803776d5 = kern_sendit+0x1a5 kern_sendit() at 0xffffffff8037790c = kern_sendit+0x3dc sendto() at 0xffffffff803779fd = sendto+0x4d syscallenter() at 0xffffffff8034a015 = syscallenter+0x1e5 syscall() at 0xffffffff804c10fb = syscall+0x4b Xfast_syscall() at 0xffffffff804a90c2 = Xfast_syscall+0xe2 --- syscall (133, FreeBSD ELF64, sendto), rip = 0x8018c971c, rsp = 0x7fffffbfe838, rbp = 0x8020f3d00 --- Then IPMI watchdog rebooted this box, after 5 minutes. (gdb) l *0xffffffff803e5a6d 0xffffffff803e5a6d is in ng_pppoe_disconnect (netgraph.h:191). 186 int line); 187 188 static __inline void 189 _chkhook(hook_p hook, char *file, int line) 190 { 191 if (hook->hk_magic != HK_MAGIC) { 192 printf("Accessing freed hook "); 193 dumphook(hook, file, line); 194 } 195 hook->lastline = line; (gdb) x/i 0xffffffff803e5a6d 0xffffffff803e5a6d : cmpl $0x78573011,0x64(%rbx) Second: after 3 hours and half, another panic (started to dump, not finished). Note: instruction pointer is the same, fault address differs. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0x63 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803e5a6d stack pointer = 0x28:0xffffff80ec06f600 frame pointer = 0x28:0xffffff80ec06f680 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2390 (mpd5) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: X_db_sym_numargs() at 0xffffffff801a227a = X_db_sym_numargs+0x15a kdb_backtrace() at 0xffffffff8033d547 = kdb_backtrace+0x37 panic() at 0xffffffff8030b567 = panic+0x187 dblfault_handler() at 0xffffffff804c0ca0 = dblfault_handler+0x330 dblfault_handler() at 0xffffffff804c107f = dblfault_handler+0x70f trap() at 0xffffffff804c155f = trap+0x3df calltrap() at 0xffffffff804a8de4 = calltrap+0x8 --- trap 0xc, rip = 0xffffffff803e5a6d, rsp = 0xffffff80ec06f600, rbp = 0xffffff80ec06f680 --- ng_parse_get_token() at 0xffffffff803e5a6d = ng_parse_get_token+0x70cd ng_destroy_hook() at 0xffffffff803d53b2 = ng_destroy_hook+0x222 ng_rmnode() at 0xffffffff803d69bb = ng_rmnode+0x12ab ng_snd_item() at 0xffffffff803d8520 = ng_snd_item+0x3f0 ng_parse_get_token() at 0xffffffff803e97fa = ng_parse_get_token+0xae5a sosend_generic() at 0xffffffff80373df6 = sosend_generic+0x436 kern_sendit() at 0xffffffff803776d5 = kern_sendit+0x1a5 kern_sendit() at 0xffffffff8037790c = kern_sendit+0x3dc sendto() at 0xffffffff803779fd = sendto+0x4d syscallenter() at 0xffffffff8034a015 = syscallenter+0x1e5 syscall() at 0xffffffff804c10fb = syscall+0x4b Xfast_syscall() at 0xffffffff804a90c2 = Xfast_syscall+0xe2 --- syscall (133, FreeBSD ELF64, sendto), rip = 0x8018c971c, rsp = 0x7fffffbfe838, rbp = 0x802a867c0 --- Uptime: 3h32m11s Dumping 4087 MB (3 chunks) chunk 0: 1MB (150 pages) ... ok chunk 1: 3575MB (915088 pages)panic: bufwrite: buffer is not busy??? cpuid = 1 Uptime: 3h32m11s Automatic reboot in 15 seconds - press a key on the console to abort From owner-freebsd-net@FreeBSD.ORG Sat Feb 5 13:55: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 A482C1065670; Sat, 5 Feb 2011 13:55:57 +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 58B2A8FC13; Sat, 5 Feb 2011 13:55:57 +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.4/8.14.4) with ESMTP id p15DtsIW002071 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 5 Feb 2011 08:55:55 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D4D56DD.30902@sentex.net> Date: Sat, 05 Feb 2011 08:55:41 -0500 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: Eugene Grosbein References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> <20110201185026.GB62007@glebius.int.ru> <4D4D554B.4050407@rdtc.ru> In-Reply-To: <4D4D554B.4050407@rdtc.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Alexander Motin , John Baldwin Subject: Re: panic: bufwrite: buffer is not busy??? 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, 05 Feb 2011 13:55:57 -0000 On 2/5/2011 8:48 AM, Eugene Grosbein wrote: > > First: again, no dump (not even started to dump, and no "Uptime:" written to console): if you try and enable dumps manually from the shell, dumpon -v /dev/ad0s1b (or whatever your swap partition is), what does dumpon return with ? ---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 Sat Feb 5 14:00: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 E3DA4106566C; Sat, 5 Feb 2011 14:00:59 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 479198FC18; Sat, 5 Feb 2011 14:00:58 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p15E0val092133; Sat, 5 Feb 2011 20:00:57 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D4D5814.80600@rdtc.ru> Date: Sat, 05 Feb 2011 20:00:52 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mike Tancsa References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> <20110201185026.GB62007@glebius.int.ru> <4D4D554B.4050407@rdtc.ru> <4D4D56DD.30902@sentex.net> In-Reply-To: <4D4D56DD.30902@sentex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Alexander Motin , John Baldwin Subject: Re: panic: bufwrite: buffer is not busy??? 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, 05 Feb 2011 14:01:00 -0000 On 05.02.2011 19:55, Mike Tancsa wrote: > On 2/5/2011 8:48 AM, Eugene Grosbein wrote: >> >> First: again, no dump (not even started to dump, and no "Uptime:" written to console): > > if you try and enable dumps manually from the shell, > > dumpon -v /dev/ad0s1b > (or whatever your swap partition is), what does dumpon return with ? # . /etc/rc.conf # set -x # dumpon -v $dumpdev + dumpon -v /dev/ad0s4b kernel dumps on /dev/ad0s4b From owner-freebsd-net@FreeBSD.ORG Sat Feb 5 19:55: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 D28601065670; Sat, 5 Feb 2011 19:55:59 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 029F18FC17; Sat, 5 Feb 2011 19:55:58 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p15JttLl093258; Sun, 6 Feb 2011 01:55:56 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D4DAB46.8080509@rdtc.ru> Date: Sun, 06 Feb 2011 01:55:50 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mike Tancsa References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <4D4670C2.4050500@freebsd.org> <4D48513C.40503@rdtc.ru> <20110201185026.GB62007@glebius.int.ru> <4D4D554B.4050407@rdtc.ru> <4D4D56DD.30902@sentex.net> <4D4D5814.80600@rdtc.ru> In-Reply-To: <4D4D5814.80600@rdtc.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Alexander Motin , John Baldwin Subject: Re: panic: bufwrite: buffer is not busy??? 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, 05 Feb 2011 19:55:59 -0000 On 05.02.2011 20:00, Eugene Grosbein wrote: >>> First: again, no dump (not even started to dump, and no "Uptime:" written to console): >> >> if you try and enable dumps manually from the shell, >> >> dumpon -v /dev/ad0s1b >> (or whatever your swap partition is), what does dumpon return with ? > > # . /etc/rc.conf > # set -x > # dumpon -v $dumpdev > + dumpon -v /dev/ad0s4b > kernel dumps on /dev/ad0s4b Note: this is NanoBSD running from SSD. It uses ad0s1 and ad0s2 for code and ad0s3 for /cfg, as usual, 1GB total. Other space of SSD is dedicated to ad0s4 where I have ad0s4b (8GB) for crashdump and the rest as ad0s4a for /var/crash. And ad0s4b is NOT configured as swap. There are 4GB of RAM and no swap here. More than 3GB of RAM are generally free. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Feb 5 22:20:15 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 318B01065674 for ; Sat, 5 Feb 2011 22:20:15 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id E01058FC0A for ; Sat, 5 Feb 2011 22:20:14 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p15MKCRP037999 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 5 Feb 2011 14:20:13 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D4DCD1E.1050906@freebsd.org> Date: Sat, 05 Feb 2011 14:20:14 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: divert rewrite 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, 05 Feb 2011 22:20:15 -0000 for some time now it has been apparent that the divert socket protocol was a little too heavily tied to IPv4. With IPv6 coming along now, it seems that we should look at how to extend it. I see a couple of possible ways to do this: --- the first way: ---- One would be to add an IPV6 version of divert sockets, possibly from the same base code. The ipfw code to call it would pass on whether it was an ipv4 or ipv6 packet that is passed out (or it can just look) and the divert packet would pass it to the correct socket if it was openned. From an application point of view, this means you would have to open an ipv4 divert socket and an ipv6 divert socket. if you didn't have the right one open.. you would just never see the packet. Since applications that use divert would probably have to be rewritten to cope with ipv6 anyhwo this seems to be an ok solution/cost. Any app that was not updated would continue to run with ipv4 but would never see IPV6 packets even if diverted. ------ another way ---- Another way to do this would be to recode divert to be its own protocol family with its own sockaddr type. that socket addr would include the family as now, but would have enough room to support ipv4 and ipv6 addresses, as well as special fields that are curently not available in divert or are just 'hacked' (such as the fact that the name of the interface is hidden in the 'sa_zero' bytes of the ipv4 socket address, and if you keep it and pass it back you are effectively passing that information back too). In this scheme we would allow the socket address structure to have enough fields to be able to encode some of the more intersting packet layer information that is in the mbuf. For example, the FIB, or somefo the other packet flags or maybe even one or two of the common tags. I could see that some of these flags might be useful to a divert agent that understood the protocol stack it was working with: #define M_PROTO1 0x00000010 /* protocol-specific */ #define M_PROTO2 0x00000020 /* protocol-specific */ #define M_PROTO3 0x00000040 /* protocol-specific */ #define M_PROTO4 0x00000080 /* protocol-specific */ #define M_PROTO5 0x00000100 /* protocol-specific */ #define M_BCAST 0x00000200 /* send/received as link-level broadcast */ #define M_MCAST 0x00000400 /* send/received as link-level multicast */ #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ #define M_VLANTAG 0x00010000 /* ether_vtag is valid */ #define M_PROMISC 0x00020000 /* packet was not for us */ #define M_PROTO6 0x00080000 /* protocol-specific */ #define M_PROTO7 0x00100000 /* protocol-specific */ #define M_PROTO8 0x00200000 /* protocol-specific */ #define M_FLOWID 0x00400000 /* flowid is valid */ If we really wanted to do more, we could also define an OOB format that could be used with recvmsg() and sendmsg() that would be extensible enough to really give a lot of information. This would be the least compatible, and to tell the truth, I'd be tempted to leave the old ipv4 interface in place as an upgrade aid. it could however handle all sorts of protocols, not just ipv4 and ipv6 but possibly L2 packets etc. as well. It may also be more work than I hope to do :-) ------ If anyone else has suggetions or man-power or would like to help.. pipe up! Julian