Re: panic in 8-CURRENT / BGE hang

On Wednesday 24 October 2007 12:23 pm, Steve Kargl wrote:
> On Wed, Oct 24, 2007 at 11:42:55AM -0400, Jung-uk Kim wrote:
> > On Wednesday 24 October 2007 02:50 am, JoaoBR wrote:
> > > so that is the reason then that bge hangs with 7 with the same
> > > if_bge.c version as releng_6
> > >
> > > because hw.bge.allow_asf defaults to 0 in releng_6 and to 1 in
> > > 7
> > >
> > > somebody knows why this changed? Would be kind of handy if this
> > > where in the man page since almost all tyans and other server
> > > boards have this bge nics
> >
> > When I MFC'd bge(4) on RELENG_6, I decided to turn it off by
> > default. See the diff between RELENG_6 and MFC point:
> >
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.di
> >ff?r2=1.91.2.21;r1=1.186
> >
> > Since RELENG_7 is branched, I think we should do the same on the
> > branch as well.
>
> So, what exactly does hw.bge.allow_asf do?  I've been running
> -current on several different tyan boards with on-board bge
> devices for the last few years without a hanging problem.
> I just checked and found hw.bge.allow_asf=1.

Basically it makes it work better with some IPMI modules (e.g., server 
management daughter cards).  While it works on some platforms, it 
breaks some, i.e., it is very sensitive to firmware and BIOS.

> I do see the infamous "bge0 watchdog timeout" problem, which can
> be mitigatedi, but not eliminated, byx
>
> Index: bge/if_bge.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
> retrieving revision 1.198
> diff -u -p -r1.198 if_bge.c
> --- bge/if_bge.c        30 Sep 2007 11:05:14 -0000      1.198
> +++ bge/if_bge.c        24 Oct 2007 16:26:41 -0000
> _at__at_ -2454,9 +2454,9 _at__at_ bge_attach(device_t dev)
>         /* Set default tuneable values. */
>         sc->bge_stat_ticks = BGE_TICKS_PER_SEC;
>         sc->bge_rx_coal_ticks = 150;
> -       sc->bge_tx_coal_ticks = 150;
> -       sc->bge_rx_max_coal_bds = 10;
> -       sc->bge_tx_max_coal_bds = 10;
> +       sc->bge_tx_coal_ticks = 1500000;
> +       sc->bge_rx_max_coal_bds = 32;
> +       sc->bge_tx_max_coal_bds = 300;
>
>         /* Set up ifnet structure */
>         ifp = sc->bge_ifp = if_alloc(IFT_ETHER);
> Index: bge/if_bgereg.h
> ===================================================================
> RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v
> retrieving revision 1.73
> diff -u -p -r1.73 if_bgereg.h
> --- bge/if_bgereg.h     22 May 2007 19:22:58 -0000      1.73
> +++ bge/if_bgereg.h     24 Oct 2007 16:26:42 -0000
> _at__at_ -2342,7 +2342,7 _at__at_ struct bge_gib {
>   * allocated for the standard, mini and jumbo receive rings.
>   */
>
> -#define        BGE_SSLOTS      256
> +#define        BGE_SSLOTS      512
>  #define        BGE_MSLOTS      256
>  #define        BGE_JSLOTS      384

That is a separate issue.  scottl changed default 
bge_{r,t}x_max_coal_bds in rev. 1.159 with support for 575x/578x 
chips.  I don't know why it was necessary but I believe he had his 
reasons.  bge_tx_coal_ticks and BGE_SSLOTS never changed from rev. 
1.1.  Unfortunately there are too many BCM57xx variants in the world 
and we don't have any documentation to verify sanity of these 
tunables.  Although I am quite sure the numbers were chosen by wpaul 
from draft specification for BCM570x, I agree that they may not 
applicable to modern BCM57xx chips any more.  Probably we can make 
them real tunables (short-term solution) or auto-tune them (long-term 
solution).

Jung-uk Kim