Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jul 2013 16:43:41 +0900
From:      Yonghyeon PYUN <pyunyh@gmail.com>
To:        Hiroki Sato <hrs@FreeBSD.org>
Cc:        sean_bruno@yahoo.com, freebsd-net@FreeBSD.org, davidch@FreeBSD.org, yongari@FreeBSD.org
Subject:   Re: bce(4) panics, 9.2rc1 [redux]
Message-ID:  <20130731074341.GC1105@michelle.cdnetworks.com>
In-Reply-To: <20130731.155406.1300421756782257141.hrs@allbsd.org>
References:  <1374700042.1493.14.camel@localhost> <1375145809.1488.3.camel@localhost> <1375208841.1496.3.camel@localhost> <20130731.155406.1300421756782257141.hrs@allbsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <sean_bruno@yahoo.com> 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.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130731074341.GC1105>