From owner-freebsd-net@FreeBSD.ORG Wed Jul 31 07:43:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F3BBD207; Wed, 31 Jul 2013 07:43:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gh0-x22b.google.com (mail-gh0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74F402F12; Wed, 31 Jul 2013 07:43:53 +0000 (UTC) Received: by mail-gh0-f171.google.com with SMTP id f15so167219ghb.30 for ; Wed, 31 Jul 2013 00:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=lotq1q24GcMEkX9/M2l7Xx+ZG1UdJ/Kntp94hQpnGOQ=; b=UpjVDlWeDmjvbObGAHvWTQZYsqGF7jBgQPSnG8HmsUXP0XL4LxmKhIM63JmOL6g1aS qer2IpTYRACcuhc5GEz+oQ0/hsjk4xepfrkisdZRUNM8yeT4ifQhVDRFQ74Pd40k2KAo TDj7wNCrRADMm9TUHbfvqK8DvIIkz0u/RAaLZkn0BDAPcxm9iNKqc6LBtx0KcX4HhR0F QP0zgbQ3p2PAAO5+ZrtlHi6W6dw0OwAVDkZpREKYungwpQZ+O6k3EQpUlgK4EG0urv7e A1U2/60QUv1ReyYSdVvsEMz6FTto0wtzn1HCOab9dw9LknWbloY0CaSI1X3Ne0W8ohps HIqA== X-Received: by 10.236.125.97 with SMTP id y61mr31767233yhh.160.1375256632704; Wed, 31 Jul 2013 00:43:52 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id a62sm509269yhk.4.2013.07.31.00.43.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 31 Jul 2013 00:43:52 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 31 Jul 2013 16:43:41 +0900 From: Yonghyeon PYUN Date: Wed, 31 Jul 2013 16:43:41 +0900 To: Hiroki Sato Subject: Re: bce(4) panics, 9.2rc1 [redux] Message-ID: <20130731074341.GC1105@michelle.cdnetworks.com> References: <1374700042.1493.14.camel@localhost> <1375145809.1488.3.camel@localhost> <1375208841.1496.3.camel@localhost> <20130731.155406.1300421756782257141.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130731.155406.1300421756782257141.hrs@allbsd.org> User-Agent: Mutt/1.4.2.3i Cc: sean_bruno@yahoo.com, freebsd-net@FreeBSD.org, davidch@FreeBSD.org, yongari@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 31 Jul 2013 07:43:54 -0000 On Wed, Jul 31, 2013 at 03:54:06PM +0900, Hiroki Sato wrote: > [Added yougari@ and davidch@ to the To:/Cc: list] > > I confirmed that my issue reported on -current@ is due to the bxe(4) > driver (BCM57711). If it is disabled, shutdown works fine without > NMI. > > Also, I received several reports about the same box that NMI occurred > even on bge(4) (BCM5717) driver when probing during power-cycle test. > The probability was about once per 30 power-cycles. Once it > occurred, an AC on/off cycle was required (resetting a system > reproduced the NMI in the same timing). > Hmm, Hiroki, could you add bge_reset()/bge_chipinit() after bge_stop() in bge_shutdown() and let me know whether that change makes any difference? > Sean Bruno wrote > in <1375208841.1496.3.camel@localhost>: > > se> > se> > se> > http://svnweb.freebsd.org/base?view=revision&revision=236216 > se> > > se> > > se> > se> > se> Ok, confirmed after ~50 reboots. > se> > se> There is a timing problem in this revision that I don't fully > se> understand. Adding printf's inside bce_reset() will cause the existing > se> code to succeed, and sometimes the existing code in this revision will > se> work (about 10% of the time). > se> > se> In the failure mode, the network interface, bce0, will not come up into > se> service *without* and network restart, after which it works fine. > se> > se> I suspect that we are missing a DELAY or UDELAY somewhere in the > se> restoral of the emac_status settings that needs to be implemented. > se> > se> Sean > se> > se> p.s. sorry for the late report as the commit is well over a year old.