Date: Wed, 10 Jun 2009 18:22:36 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Ian FREISLICH <ianf@clue.co.za> Cc: current@freebsd.org Subject: Re: mixed VLAN problems on msk(4) Message-ID: <20090610092226.GG63941@michelle.cdnetworks.co.kr> In-Reply-To: <20090610082255.GF63941@michelle.cdnetworks.co.kr> References: <20090609122140.GB59401@michelle.cdnetworks.co.kr> <E1MDz27-00018W-9c@clue.co.za> <E1ME1Ma-0001LQ-6t@clue.co.za> <20090610082255.GF63941@michelle.cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090610092226.GG63941>