From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 15:20:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD541065670 for ; Tue, 22 Apr 2008 15:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C65588FC24 for ; Tue, 22 Apr 2008 15:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3MFK4r1046160 for ; Tue, 22 Apr 2008 15:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3MFK4K8046159; Tue, 22 Apr 2008 15:20:04 GMT (envelope-from gnats) Date: Tue, 22 Apr 2008 15:20:04 GMT Message-Id: <200804221520.m3MFK4K8046159@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: petunin1@legis.krsn.ru Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: petunin1@legis.krsn.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2008 15:20:05 -0000 The following reply was made to PR kern/122839; it has been noted by GNATS. From: petunin1@legis.krsn.ru To: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru, bms@FreeBSD.org Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Tue, 22 Apr 2008 22:52:53 +0800 Hi. I cold't find any rtl8139 based adapters at me, so i tryed to play with 3com 3c905-tx (rev. A, as printed on the board, with controller chip "Parallel Tasking 3com 40-0336-004 9750s 04749555 LUCENT 40-03364" ) and OFFICE CONNECT 3csoho100-tx (also rev. a with controller chip "Parallel tasking II perfomance 3com 40-0483-004 0111t 42433437 AGERE 40-04834") The system detected both of them as XL0 and XL1 network devices. And, with first card (3com 3c905-tx) xl0 multicast task routing started working just fine and as expected. But with another card (soho office connect) multicast routnig still do not working, and problem seems to be exact the same as with em and msk drivers. (mrouting working only in promiscious mode). I've downloaded latest intel's driver for FreeBSD7 (6.8.7) and tryed to use it, but with no luck. Problem still exist. So, as it seems to me, it is not a em driver problem. I fink, it is imposiible, what such different drivers, as xl, em and msk were was broken simultaneously and identically. As my colleague says, when we both take a brief look at the source codes of em driver, it seems some card have a hardware filter, and some do not have it. So, if the card's filter programmed correctly (by the driver), multicast working task working just fine, and if not, we have a problems. On latest intel's driver 6.8.7 we have commented a few string on the code, after what, multicast routing started to work correctly. But i fink, it's a wrong way, so i asking for help again, if someone can help me to investigate the source of the problem and fix it by the right way. What we have changed: central-gw# diff if_em.c.orig if_em.c 2337c2337 < if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) { --- > // if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) { 2341,2343c2341,2343 < } else < e1000_update_mc_addr_list(&adapter->hw, mta, < mcnt, 1, adapter->hw.mac.rar_entry_count); --- > // } else > // e1000_update_mc_addr_list(&adapter->hw, mta, > // mcnt, 1, adapter->hw.mac.rar_entry_count); in that part of if_em.c file: /********************************************************************* * Multicast Update * * This routine is called whenever multicast address list is updated. * **********************************************************************/ static void em_set_multi(struct adapter *adapter) { struct ifnet *ifp = adapter->ifp; struct ifmultiaddr *ifma; u32 reg_rctl = 0; u8 mta[512]; /* Largest MTS is 4096 bits */ int mcnt = 0; IOCTL_DEBUGOUT("em_set_multi: begin"); if (adapter->hw.mac.type == e1000_82542 && adapter->hw.revision_id == E1000_REVISION_2) { reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL); if (adapter->hw.bus.pci_cmd_word & CMD_MEM_WRT_INVALIDATE) e1000_pci_clear_mwi(&adapter->hw); reg_rctl |= E1000_RCTL_RST; E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl); msec_delay(5); } IF_ADDR_LOCK(ifp); TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { if (ifma->ifma_addr->sa_family != AF_LINK) continue; if (mcnt == MAX_NUM_MULTICAST_ADDRESSES) break; bcopy(LLADDR((struct sockaddr_dl *)ifma->ifma_addr), &mta[mcnt * ETH_ADDR_LEN], ETH_ADDR_LEN); mcnt++; } IF_ADDR_UNLOCK(ifp); // if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) { reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL); reg_rctl |= E1000_RCTL_MPE; E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl); // } else // e1000_update_mc_addr_list(&adapter->hw, mta, // mcnt, 1, adapter->hw.mac.rar_entry_count); if (adapter->hw.mac.type == e1000_82542 && adapter->hw.revision_id == E1000_REVISION_2) { reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL); reg_rctl &= ~E1000_RCTL_RST; E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl); msec_delay(5); if (adapter->hw.bus.pci_cmd_word & CMD_MEM_WRT_INVALIDATE) e1000_pci_set_mwi(&adapter->hw); } } Thank you