Date: Tue, 31 Aug 1999 23:37:54 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: jeremyp@gsmx07.alcatel.com.au (Peter Jeremy) Cc: current@freebsd.org, ian@whalley.org, ncbp@bank-pedersen.dk Subject: Re: Problems with the latest changes to ifconfig (I guess) -> Bad Message-ID: <199909010337.XAA23014@skynet.ctr.columbia.edu> In-Reply-To: <99Sep1.130654est.40337@border.alcanet.com.au> from "Peter Jeremy" at Sep 1, 99 01:08:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Peter Jeremy had to walk into mine and say: > Ian Whalley <ian@whalley.org> wrote: > >My card is identified as <3Com 3c905B-TX Fast Etherlink XL>. > > FWIW, I'm running a kernel about 30 hours old with a <3Com 3c905-TX > Fast Etherlink XL> and I'm not seeing this problem. > > At a quick quess, something in the miibus support broke the 3C905B > support. Not quite. The original 3c905-TX NIC used an external NatSemi PHY chip which was mapped to MII address 24. The 3c905B uses an internal transceiver, which is also mapped to MII address 24 for compatibility purposes. However, there are several different 3c905B ASIC revisions and at least one of them, for some peculiar reason, maps the transceiver to *all* MII addresses (0 through 31). Technically this isn't a big problem since if you always assume that the PHY is at address 24 (which I sure is what 3Com's drivers do) you'll never notice the difference. But you have to watch out for it. The old code in if_xl.c would probe for PHYs and stop the moment it encountered the first one, which would work fine: it would stop at address 0 for the broken ASIC and 24 for the working ones. But the miibus code probes at all addresses because there are some NICs that actually have more than one transceiver. But with the buggy 3Com ASIC, we end up incorrectly trying to map the same PHY several times over, which the xlphy driver doesn't like, so the probe fails, the miibus attach fails, and bad things happen later. I just committed a patch to -current to deal with this: the xl_miibus_readreg() and xl_miibus_writereg() routines will not only return values at MII address 24. This will make the buggy ASIC appear to work correctly so that only one PHY instance will be detected. Why didn't I catch this earlier? Well, the 3c905B NIC that I tested happens to work correctly. So did the 3c905C that I tried after it. In fact, I think the only place I encountered the buggy ASIC locally is with the embedded 3c905B NIC in some of the Dell machines in the lab, which aren't currently running FreeBSD. Don't you just love hardware programming? -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909010337.XAA23014>