From owner-freebsd-current@FreeBSD.ORG Wed Jun 10 09:20:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E393106566B for ; Wed, 10 Jun 2009 09:20:17 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id CA4E28FC13 for ; Wed, 10 Jun 2009 09:20:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so247516rvb.43 for ; Wed, 10 Jun 2009 02:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=A78ioaeqpqrfy153PHtePzTMyEZQgGWB0MxaXFG6m1o=; b=UGyWurQ3ZkD77mdI/6uTMp57nEKVwBu1mBv7dO1bXQnw+P6rOYbJIzKykUFDRHOuJK GyqTcySYcWZknxaj2YvO8AD7u/ajeF1rtBwrvIrFDadsqNoi5878Gjzgg2rmRfpT87SA HCMlXZIc0ddJQSxpP1sFXKH6f9F775utyp2/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=i4v+G4ShrJ6RdElXIRPm6t84E6XeyYGRDAyAloARYsaGAdfjQLgsdQj8hij0SlCnos vsaOWqz+YfmrVNtGiJdTKrwj3uhF54r8izR3ZYT4RO0QTd9QsamvX1Kz15UenqhFjON+ 78f4Wi4re6LYYuOXFU9DJj3cNvODXBOPSeEBc= Received: by 10.141.180.5 with SMTP id h5mr1037439rvp.60.1244625616512; Wed, 10 Jun 2009 02:20:16 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id f21sm1937253rvb.25.2009.06.10.02.20.14 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 02:20:15 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Wed, 10 Jun 2009 18:22:36 +0900 From: Pyun YongHyeon Date: Wed, 10 Jun 2009 18:22:36 +0900 To: Ian FREISLICH Message-ID: <20090610092226.GG63941@michelle.cdnetworks.co.kr> References: <20090609122140.GB59401@michelle.cdnetworks.co.kr> <20090610082255.GF63941@michelle.cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <20090610082255.GF63941@michelle.cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: mixed VLAN problems on msk(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 09:20:17 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 10, 2009 at 05:22:55PM +0900, Pyun YongHyeon wrote: > On Tue, Jun 09, 2009 at 03:27:40PM +0200, Ian FREISLICH wrote: > > Pyun YongHyeon wrote: > > > On Tue, Jun 09, 2009 at 12:58:23PM +0200, Ian Freislich wrote: > > > > Hi > > > > > > > > Debugging some network problems last night, I noticed that I'd get > > > > packet loss on a mixed tagged/untagged network every time a tagged > > > > VLAN packet arrived, so long as hardware VLAN support was enabled > > > > on my NIC. The moment hardware tagging was disabled (manually, or > > > > by tcpdump) the packet loss disappeared. > > > > > > > > My msk(4) hardware: > > > > > > > > mskc0@pci0:2:0:0: class=0x020000 card=0x532111ab chip=0x436211ab rev= > > 0x22 hdr=0x00 > > > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > > > device = 'Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller ( > > 88E8053)' > > > > class = network > > > > subclass = ethernet > > > > cap 01[48] = powerspec 2 supports D0 D1 D2 D3 current D0 > > > > cap 03[50] = VPD > > > > cap 05[5c] = MSI supports 2 messages, 64 bit enabled with 2 messages > > > > cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link x1(x1 > > ) > > > > > > > > The switch was configured as follows: > > > > > > > > Port is member in: > > > > > > > > Vlan Name Egress rule Port Membership Type > > > > ---- -------------------------------- ----------- -------------------- > > > > 14 14 Untagged Static > > > > 26 26 Tagged Static > > > > 1000 1000 Tagged Static > > > > > > > > It appears not to matter whether the vlans are configured with the > > > > msk(4) interface as the parent or not. For example, whenever one > > > > of these broadcasts is recieved: > > > > > > > > 12:49:36.093250 IP 41.154.87.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 19 > > , prio 0, authtype none, intvl 1s, length 36 > > > > 12:49:37.097514 IP 41.154.87.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 19 > > , prio 0, authtype none, intvl 1s, length 36 > > > > 12:49:38.099525 IP 41.154.87.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 19 > > , prio 0, authtype none, intvl 1s, length 36 > > > > > > > > traffic to the untagged address on vlan14 (basically the address > > > > on msk0) is dropped. If I disable vlanhwtag on msk0, the interface > > > > suffers no packet loss on reciept of tagged frames. > > > > > > Does that mean msk(4) cannot see untagged frame if VLAN hardware > tag stripping is enabled on msk(4)? I don't see suspicious part in > code at this moment. Does hardware MAC statistics report something? > (sysctl dev.msk.0.stats) Or netstat(1) says Ierrs/Drop on vlan/msk0? > > I have small patch which corrects bus_dma related bugs but I'm not > sure it can fix the VLAN issue. > Patch attached. --XF85m9dhOBO43t/C Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.busdma.patch" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 193879) +++ sys/dev/msk/if_msk.c (working copy) @@ -673,8 +673,7 @@ } bus_dmamap_sync(sc_if->msk_cdata.msk_rx_ring_tag, - sc_if->msk_cdata.msk_rx_ring_map, - BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + sc_if->msk_cdata.msk_rx_ring_map, BUS_DMASYNC_PREWRITE); /* Update prefetch unit. */ sc_if->msk_cdata.msk_rx_prod = MSK_RX_RING_CNT - 1; @@ -712,8 +711,7 @@ } bus_dmamap_sync(sc_if->msk_cdata.msk_jumbo_rx_ring_tag, - sc_if->msk_cdata.msk_jumbo_rx_ring_map, - BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + sc_if->msk_cdata.msk_jumbo_rx_ring_map, BUS_DMASYNC_PREWRITE); sc_if->msk_cdata.msk_rx_prod = MSK_JUMBO_RX_RING_CNT - 1; CSR_WRITE_2(sc_if->msk_softc, @@ -3365,12 +3363,11 @@ bus_dmamap_sync( sc_if->msk_cdata.msk_jumbo_rx_ring_tag, sc_if->msk_cdata.msk_jumbo_rx_ring_map, - BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + BUS_DMASYNC_PREWRITE); else bus_dmamap_sync( sc_if->msk_cdata.msk_rx_ring_tag, - sc_if->msk_cdata.msk_rx_ring_map, - BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + sc_if->msk_cdata.msk_rx_ring_map, BUS_DMASYNC_PREWRITE); CSR_WRITE_2(sc, Y2_PREF_Q_ADDR(sc_if->msk_rxq, PREF_UNIT_PUT_IDX_REG), sc_if->msk_cdata.msk_rx_prod); } @@ -3391,7 +3388,6 @@ /* Sync status LEs. */ bus_dmamap_sync(sc->msk_stat_tag, sc->msk_stat_map, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); - /* XXX Sync Rx LEs here. */ rxput[MSK_PORT_A] = rxput[MSK_PORT_B] = 0; @@ -3401,16 +3397,9 @@ control = le32toh(sd->msk_control); if ((control & HW_OWNER) == 0) break; - /* - * Marvell's FreeBSD driver updates status LE after clearing - * HW_OWNER. However we don't have a way to sync single LE - * with bus_dma(9) API. bus_dma(9) provides a way to sync - * an entire DMA map. So don't sync LE until we have a better - * way to sync LEs. - */ control &= ~HW_OWNER; - sd->msk_control = htole32(control); status = le32toh(sd->msk_status); + sd->msk_control = 0; len = control & STLE_LEN_MASK; port = (control >> 16) & 0x01; sc_if = sc->msk_if[port]; @@ -3467,8 +3456,9 @@ break; } + bus_dmamap_sync(sc->msk_stat_tag, sc->msk_stat_map, + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); sc->msk_stat_cons = cons; - /* XXX We should sync status LEs here. See above notes. */ if (rxput[MSK_PORT_A] > 0) msk_rxput(sc->msk_if[MSK_PORT_A]); --XF85m9dhOBO43t/C--