From owner-freebsd-hackers Wed Aug 12 16:25:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03429 for freebsd-hackers-outgoing; Wed, 12 Aug 1998 16:25:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA03381 for ; Wed, 12 Aug 1998 16:25:31 -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 TAA26825 for hackers@freebsd.org; Wed, 12 Aug 1998 19:28:14 -0400 From: Bill Paul Message-Id: <199808122328.TAA26825@skynet.ctr.columbia.edu> Subject: More XL driver fixes To: hackers@FreeBSD.ORG Date: Wed, 12 Aug 1998 19:28:13 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You know the drill. I uploaded yet another version of the Etherlink XL driver to www.freebsd.org/~wpaul/3Com. This update fixes the following multicast bugs: - The second for(;;) statement in xl_calchash() was wrong. I'm so damn accustomed to typing "for(i = 0; i < foo; i++)" that my brain failed so switch gears when I moved from i to j. - The patch I applied to xl_setmulti() to turn off multicast reception if acpcom.ac_multicnt was 0 worked okay for 2.2.x but not for 3.0. The multicast code in 3.0 is different and ac_multicnt is never updated. - The 3Com manual states that 3c905B adapters have a 64-bit multicast hash filter, and that future ASIC revisions will have a 256-bit filter instead. As it happens, there are already ASICs with 256-bit filters out there; I know because I've got one. Previously I was masking the upper 2 bits of the hash value thinking that only 6 bits were needed. Now I supply all 8 bits to the NIC; it will ignore bits that it doesn't need. Today I found out that there are some Dell Latitude laptop machines with embedded 3c905B-TX adapters. If anybody has one of these, I'd like to know if the driver works properly. The one person who's talked to me about these things so far says that on his laptop, the driver blows up because it gets a value from the media options register that it wasn't expecting. Supposedly, when he does a "boot: -v" on his machine, he gets a message that says: xl0: media options word: e100 On the 3c905B, the media options register is loaded from the EEPROM (with earlier 3c90x NICs the value is hard-wired). According to the manual, there are 4 possible values that may be encoded in the EEPROM depending on the adapter (TP, TX, T4 and FX) none of which are anywhere close to e100. (You can see the media options bit definitions in if_xlreg.h. Look for XL_MEDIAOPT_*.) I am not sure why this person's system comes up with this value. My suspicion is that either the EEPROM contents are corrupted somehow, or Dell has reprogrammed the EEPROM with their own custom values. It's also possible that this is just a bit combination that isn't documented in the 3Com manual. If you have such a laptop machine and the driver panics in ifmedia_set() for you, please try the following patch: *** if_xl.c 1998/08/11 15:26:56 1.27 --- if_xl.c 1998/08/12 15:21:26 *************** *** 1291,1296 **** --- 1291,1317 ---- printf("xl%d: media options word: %x\n", sc->xl_unit, sc->xl_media); + /* XXXXXX WARNING! THIS IS A HACK! WARNING! XXXXXX */ + /* + * Read the media options word directly from the EEPROM. The + * value printed here and the value shown above should match, + * otherwise something is seriously wrong. Note: only the 3c905B + * has the media options data loaded from the EEPROM. Earlier + * cards have the media options register set by physically + * latching pins on the controller chip when the adapter is + * manufactured. + */ + #define XL_EE_MEDIAOPT 0x19 + xl_read_eeprom(sc, (char *)&sc->xl_media, XL_EE_MEDIAOPT, 1, 0); + printf("xl%d: media options word from EEPROM: %x\n", + sc->xl_unit, sc->xl_media); + /* + * The media options word for a 3c905B-TX adapter is + * supposed to be 0x000A. Force it here for a test. + */ + sc->xl_media = 0x000a; + /* XXXXXX WARNING! THIS IS A HACK! WARNING! XXXXXX */ + xl_read_eeprom(sc, (char *)&sc->xl_xcvr, XL_EE_ICFG_0, 2, 0); sc->xl_xcvr &= XL_ICFG_CONNECTOR_MASK; sc->xl_xcvr >>= XL_ICFG_CONNECTOR_BITS; This patch changes the attach routine so that it checks the value of the EEPROM location from which the media options register is loaded so that it can be compared with the value in read from the register itself. It also forces the media type to XL_MEDIAOPT_BT|XL_MEDIAOPT_BTX, which is supposed to be the correct default for a 3c905B-TX. YOU SHOULD ONLY USE THIS PATCH IF YOU HAVE A 3c905B! Don't use it with a 3c905 or 3c900 because it will muck up the media detection routine! -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-hackers" in the body of the message