Date: Sat, 24 Sep 2005 10:01:12 +0200 From: Christian Brueffer <chris@unixpages.org> To: Pyun YongHyeon <pyunyh@gmail.com> Cc: Miles Nordin <carton@Ivy.NET>, freebsd-sparc64@freebsd.org Subject: Re: bge(4) Message-ID: <20050924080112.GD1302@unixpages.org> In-Reply-To: <20050924072413.GA19116@rndsoft.co.kr> References: <oqr7bijrw7.fsf@castrovalva.Ivy.NET> <20050924061342.GA1302@unixpages.org> <20050924072413.GA19116@rndsoft.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
--VdOwlNaOFKGAtAAV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 24, 2005 at 04:24:13PM +0900, Pyun YongHyeon wrote: > On Sat, Sep 24, 2005 at 08:13:42AM +0200, Christian Brueffer wrote: > > On Wed, Sep 21, 2005 at 12:40:40PM -0400, Miles Nordin wrote: > > > When I do 'kldload if_bge' i get: > > >=20 > > > -----8<----- > > > bge0: <Altima AC9100 Gigabit Ethernet, ASIC rev. 0x105> mem 0x10000-= 0x1ffff at device 3.0 on pci2 > > > bge0: firmware handshake timed out > > > bge0 PHY read timed out > > > bge0: MII without any PHY! > > > device_attach: bge0 attach returned 6 > > > -----8<----- > > >=20 > > > Is this expected? > > >=20 > > > I'm looking for a good card to do forwarding of high pps on a Netra = T1 > > > 200, because AFAICT gem and hme aren't documented to support interru= pt > > > mitigation nor polling(9). Will em(4) work on sparc64? Do people > > > have other suggestions? > > >=20 > >=20 > > You can find a prototype polling(4) patch for bge(4) here: > >=20 > > http://people.freebsd.org/~brueffer/polling/bge_polling.diff > >=20 > > It lacks error recovery though. I haven't worked on this for some tim= e, > > but I'll look into polishing it this weekend. > >=20 >=20 > Do you have a documentation for Tigon3? Unfortunately not. > Due to lack of data sheet for Tigon3 I can't sure supporting polling > for bge(4) is feasible. Comments in bge_intr says bge(4) needs an > interrupt to check link state changes as some revisions of BCM5700 > have bugs in the chip. In addition, unlike most other drivers, bge(4) > calls bus_dmamap_sync(9) to update statistics for its status block > in bge_intr.=20 >=20 Ah, yes. I haven't looked at the code for almost a year, so apparently I forgot quite a few things. For the BCM5700 case, we can simply make polling conditional. For the bus_dmamap_sync issue, I'll take a look at how other drivers handle this. Thanks for the update on this! BTW, Bill Paul and Paul Saab probably have documentation for these chips (judging on some of their commits). > > If I get my Ultra 10 to play nice with CURRENT and Pyun doesn't beat me > > to it, I'll also take a look at hme(4). > >=20 >=20 > I'm happy to review your changes. >=20 Thanks, I'll keep that in mind. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --VdOwlNaOFKGAtAAV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFDNQfIbHYXjKDtmC0RAj+zAJ4o3Y9QsC3CTxecMbcDq1hXyKl3SgCgvMaO ZIgpnd73KMgwh6FF+HzJh4U= =dVNv -----END PGP SIGNATURE----- --VdOwlNaOFKGAtAAV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050924080112.GD1302>