From owner-freebsd-current@FreeBSD.ORG Wed Jun 17 00:15:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D183106566B for ; Wed, 17 Jun 2009 00:15:33 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id E14138FC19 for ; Wed, 17 Jun 2009 00:15:32 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5856DA0790; Wed, 17 Jun 2009 02:15:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 4C3A5A078E; Wed, 17 Jun 2009 02:15:28 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 28D52A078B; Wed, 17 Jun 2009 02:15:28 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009061702152747-10102 ; Wed, 17 Jun 2009 02:15:27 +0200 Received: by wep4035 (sSMTP sendmail emulation); Wed, 17 Jun 2009 02:15:27 +0200 Date: Wed, 17 Jun 2009 02:15:27 +0200 From: Alexey Shuvaev To: Pyun YongHyeon Message-ID: <20090617001527.GB4146@wep4035.physik.uni-wuerzburg.de> References: <20090615044106.GC78415@michelle.cdnetworks.co.kr> <4A36018E.2050301@incunabulum.net> <20090615084850.GD78415@michelle.cdnetworks.co.kr> MIME-Version: 1.0 In-Reply-To: <20090615084850.GD78415@michelle.cdnetworks.co.kr> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.19 (2009-01-05) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 06/17/2009 02:15:27 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 06/17/2009 02:15:27 AM, Serialize complete at 06/17/2009 02:15:27 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: Bruce Simpson , freebsd-current@freebsd.org Subject: Re: CFT: fxp(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 00:15:33 -0000 On Mon, Jun 15, 2009 at 05:48:50PM +0900, Pyun YongHyeon wrote: > On Mon, Jun 15, 2009 at 09:08:46AM +0100, Bruce Simpson wrote: > > Pyun YongHyeon wrote: > > >Please test the patch in the following URL if you have fxp(4) > > >hardwares. The patch contains various accumulated fixes for > > >multicast handling, bus_dma fixes, more sane initialization > > >and enhanced lockup detection for buggy controllers. > > > > This is just a note to say that I *have* observed problems with > > multicast setup in fxp(4) -- it seems to need setting up of the > > link-layer hash filter for a group to transmit as well as receive. > > > > I couldn't see this limitation in datasheet. So it could be a > bug in stock fxp(4). > > > This isn't OK, NICs should be able to transmit w/o receive setup, and > > may break normal use-cases (esp. IPv6), I posted to freebsd-net@ about > > this over the past 12 months, but did not have time to reproduce or > > isolate the issue. So a fix is very, very welcome. Thanks for working on > > this. > > So does that patch fixed the issue? I'm not familiar with > multicasting but I did my best to make fxp(4) work on multicasting > environments. fxp(4) hardwares do not allow multicast hash filter > programming when device is not in idle state. So stock fxp(4) > used to rely on Tx completion interrupt to program multicast > filters. I think that is error-prone/complex and fxp(4) can drop > multicat frames until its filter is fully reprogrammed. > My setup on one side: mskc0@pci0:1:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' class = network subclass = ethernet msk0: flags=8843 metric 0 mtu 1500 options=11a ... media: Ethernet autoselect (100baseTX ) status: active The other side is: fxp0@pci0:2:8:0: class=0x020000 card=0x00011179 chip=0x10318086 rev=0x42 hdr=0x00 vendor = 'Intel Corporation' device = '82801CAM (ICH3) PRO/100 VE (LOM) Network Connection' class = network subclass = ethernet fxp0: flags=8843 metric 0 mtu 1500 options=2009 ... media: Ethernet autoselect (100baseTX ) status: active Both sides: ~> uname -a FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r194030M: Thu Jun 11 21:12:19 CEST 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 The command used to receive packets (thanks to gnn): ./mctest -i msk0/fxp0 -m 0 -s 1024 -n 10000 -r to transmit: ./mctest -i fxp0/msk0 -M 1 -s 1024 -n 10000 -t 1 The switch is CentreCOM FS709FC which was disconnected from the uplink during the tests. That means that the network was still idle other than test packets. Looks like everything is working both with and without the patch. However it seems I understand too little about multicasting to perform sensible tests. Do I need any route add 224.0.0.0/4 -interface fxp0/msk0 commands? How long should I wait before exchanging multicast transmitter with receiver? ... ftp upload/download are working also good with/without the patch. Alexey.