From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 04:53:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9038B16A4CE for ; Tue, 22 Feb 2005 04:53:56 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B97A43D48 for ; Tue, 22 Feb 2005 04:53:54 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j1M4rmWi006063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2005 20:53:49 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <421ABB04.3030301@errno.com> Date: Mon, 21 Feb 2005 20:54:28 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: frank@exit.com References: <200502220402.j1M42pt9060271@realtime.exit.com> In-Reply-To: <200502220402.j1M42pt9060271@realtime.exit.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Hard hangs running 6-current. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 04:53:56 -0000 Frank Mayhar wrote: > Doug White wrote: > >>Try one of these loader tunables: >>1. Disabling SMP (kern.smp.disabled=1) >>2. Disabling mpsafenet (debug.mpsafenet=0) > > > I run with debug.mpsafenet=0 (due to a bug I ran into some time ago which I > haven't looked at recently). > > The current kernel is running with HTT turned off and no SMP builtin. So > kern.smp.disabled=1 is kind of redundant. > > So no dice on either one of these. > > >>This may be a symptom of a deadlock we're observing on >>sparc64 in the network stack. Either one of these should stop the >>problem, if its the issue we were seeing earlier today. > > > Doesn't look like it, I'm afraid. > > >>If you especially adventurous, try setting net.inet.tcp.do_tcpdrain=0 >>instead of the options above. This might cause mbuf exhaustion but is >>implicated in the deadlock. >> >>This is a total hunch and I may be influenced by the time put in on this >>issue today :) > > > If you're interested, you might take a look at > http://www.freebsd.org/cgi/query-pr.cgi?pr=77751 > It has my results for the day. Warning: Lots of ath debug output. I'm > pretty sure it's the ath driver that's the problem, particularly in light > of my most recent results. > > Thanks for the ideas, though. Other than a busted card the only thing I can think of is you're getting an interrupt storm from the MIB counters. If so try disabling HAL_INT_MIB in the driver. The easiest way to do that is probably to force sc_needmib to 0 in ath_attach by disabling the following code: /* * Check if the device has hardware counters for PHY * errors. If so we need to enable the MIB interrupt * so we can act on stat triggers. */ if (ath_hal_hwphycounters(ah)) sc->sc_needmib = 1; If your problem does not go away then I can only suggest trying another card. FWIW I haven't seen this. Sam