Date: Tue, 12 Dec 2006 21:31:07 -0700 From: Scott Long <scottl@samsco.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-src@freebsd.org, "Bjoern A. Zeeb" <bz@freebsd.org>, Scott Long <scottl@freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/bge if_bge.c if_bgereg.h Message-ID: <457F820B.6040104@samsco.org> In-Reply-To: <20061213113025.O833@delplex.bde.org> References: <200612120511.kBC5BCvi018697@repoman.freebsd.org> <20061212231257.M91892@maildrop.int.zabbadoz.net> <20061213113025.O833@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > On Tue, 12 Dec 2006, Bjoern A. Zeeb wrote: > >> On Tue, 12 Dec 2006, Scott Long wrote: >> >>> scottl 2006-12-12 05:11:12 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/dev/bge if_bge.c if_bgereg.h >>> Log: >>> Fix support for certain 575x/578x chips. This consists of the >>> following: >> ... >> this change makes my machine hang completely (even not able to break >> into kernel debugger) by the time the interfaces are setup (upon >> boot after hostnames gets set from rc scripts). >> >> it's a dual cpu amd64 with a tyan K8SE which has 2 bges onboard: >> Broadcom BCM5704 A3, ASIC rev. 0x2003 >> >> backing out this one makes it boot again without any problems. > > I use the following quick fix for a <Broadcom BCM5701 B5, ASIC rev. 0x105>. > > %%% > Index: if_bge.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v > retrieving revision 1.159 > diff -u -2 -r1.159 if_bge.c > --- if_bge.c 12 Dec 2006 05:11:12 -0000 1.159 > +++ if_bge.c 12 Dec 2006 17:17:21 -0000 > @@ -2542,5 +2631,4 @@ > __FUNCTION__); > CSR_WRITE_4(sc, BGE_FASTBOOT_PC, 0x0); > - } > > /* > @@ -2550,4 +2638,5 @@ > */ > bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); > + } > > reset = BGE_MISCCFG_RESET_CORE_CLOCKS|(65<<1); > %%% > > This moves the bge_writemem() into a new new block of code that is > only executed for certain bge_asicrevs. (BTW, it is confusing that > bge_asicrev != ASIC rev. printed by dmesg.) The bge_writemem() is new > too and without the above it seems to be associated with nothing. The > above is in bge_reset(). The hang always occurred for initialization > from /etc/rc.d. bge_reset() somehow succeeded when called twice before > getting that far. > > The patch also some other details that I'm interested in and some style > bugs. I will report these in private mail. > > Bruce The write to BGE_SOFTWARE_GENCOMM that you are effectively disabling was added by my patch, and it originated from a suggestion from David C. The write is effectively done twice in a row, as well as being done by bge_sig_pre_reset() right before bge_reset() is called. In other words, it's written 3 times, 2 of them back-to-back if you don't have a PCIe controller. I can imagine that this might make the chip upset for one reason or another. Looking at the linux driver, the write is only done once, in their equivalent of bge_sig_pre_reset(). It's not clear why the first or second extra writes were added to FreeBSD, and without docs or detailed knowledge, my only option is to use the Linux driver as canon. It's also not clear to me why my tests on various chips didn't fail, but I'll chalk that up to quantum physics, sunspots, and tea leaves. I'll try to run some tests with the third write disabled, but I don't have much time left to devote to this particular project. If others would be willing to test with the third write removed, I'd appreciate it. It might be interesting to test with the second write removed as well (i.e. both writes in bge_reset). I'll post patches if anyone wants to test but can't grok what I'm saying here. Thanks again for looking at this. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?457F820B.6040104>