From owner-freebsd-current Tue Aug 31 20:37: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 2739715256 for ; Tue, 31 Aug 1999 20:36:53 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id XAA23014; Tue, 31 Aug 1999 23:37:55 -0400 From: Bill Paul Message-Id: <199909010337.XAA23014@skynet.ctr.columbia.edu> Subject: Re: Problems with the latest changes to ifconfig (I guess) -> Bad To: jeremyp@gsmx07.alcatel.com.au (Peter Jeremy) Date: Tue, 31 Aug 1999 23:37:54 -0400 (EDT) Cc: current@freebsd.org, ian@whalley.org, ncbp@bank-pedersen.dk In-Reply-To: <99Sep1.130654est.40337@border.alcanet.com.au> from "Peter Jeremy" at Sep 1, 99 01:08:24 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2715 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Peter Jeremy had to walk into mine and say: > Ian Whalley 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