Date: Wed, 10 Jun 2009 12:54:35 +0200 From: Ian FREISLICH <ianf@clue.co.za> To: pyunyh@gmail.com Cc: current@freebsd.org Subject: Re: mixed VLAN problems on msk(4) Message-ID: <E1MELRz-00015A-A5@clue.co.za> In-Reply-To: <20090610082255.GF63941@michelle.cdnetworks.co.kr> References: <20090610082255.GF63941@michelle.cdnetworks.co.kr> <20090609122140.GB59401@michelle.cdnetworks.co.kr> <E1MDz27-00018W-9c@clue.co.za> <E1ME1Ma-0001LQ-6t@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Pyun YongHyeon wrote: > 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 No, it means that untagged frames that arrive around the time that tagged frames arrive are dropped. For instance, ping at 10 packets/s on the untagged address and there's a CARP broadcast recieved from the network on tagged vlan26 every second, then the interface according to ping will get 10% packet loss. > code at this moment. Does hardware MAC statistics report something? > (sysctl dev.msk.0.stats) Or netstat(1) says Ierrs/Drop on vlan/msk0? dev.msk.0.stats.rx.ucast_frames: 44760 dev.msk.0.stats.rx.bcast_frames: 36924 dev.msk.0.stats.rx.pause_frames: 0 dev.msk.0.stats.rx.mcast_frames: 0 dev.msk.0.stats.rx.crc_errs: 0 dev.msk.0.stats.rx.good_octets: 28970771 dev.msk.0.stats.rx.bad_octets: 0 dev.msk.0.stats.rx.frames_64: 27085 dev.msk.0.stats.rx.frames_65_127: 23167 dev.msk.0.stats.rx.frames_128_255: 9571 dev.msk.0.stats.rx.frames_256_511: 6277 dev.msk.0.stats.rx.frames_512_1023: 2782 dev.msk.0.stats.rx.frames_1024_1518: 12802 dev.msk.0.stats.rx.frames_1519_max: 0 dev.msk.0.stats.rx.frames_too_long: 0 dev.msk.0.stats.rx.jabbers: 0 dev.msk.0.stats.rx.overflows: 0 dev.msk.0.stats.tx.ucast_frames: 54795 dev.msk.0.stats.tx.bcast_frames: 25 dev.msk.0.stats.tx.pause_frames: 0 dev.msk.0.stats.tx.mcast_frames: 2 dev.msk.0.stats.tx.octets: 5900142 dev.msk.0.stats.tx.frames_64: 5228 dev.msk.0.stats.tx.frames_65_127: 45780 dev.msk.0.stats.tx.frames_128_255: 843 dev.msk.0.stats.tx.frames_256_511: 875 dev.msk.0.stats.tx.frames_512_1023: 1964 dev.msk.0.stats.tx.frames_1024_1518: 132 dev.msk.0.stats.tx.frames_1519_max: 0 dev.msk.0.stats.tx.colls: 0 dev.msk.0.stats.tx.late_colls: 0 dev.msk.0.stats.tx.excess_colls: 0 dev.msk.0.stats.tx.multi_colls: 0 dev.msk.0.stats.tx.single_colls: 0 dev.msk.0.stats.tx.underflows: 0 [apple] /usr/home/ianf # netstat -ni Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll msk0 1500 <Link#1> 00:16:cb:9f:bc:09 81858 51 54914 0 0 msk0 1500 41.154.1.0/24 41.154.1.178 55676 - 54885 - - Ierrs is climbing. If I stop the switch from forwarding tagged frames, then Ierrs stops increasing. If I move exclusively to tagged vlans, then the errors stop. Turning off vlanhwtag isn't really a solution because shortly after starting a transfer, I get the following: Jun 9 18:01:32 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering Jun 9 18:02:20 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering Jun 9 18:02:45 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering Jun 9 18:02:52 apple kernel: msk0: link state changed to DOWN Jun 9 18:02:54 apple kernel: msk0: link state changed to UP Jun 9 18:03:31 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering Jun 9 18:03:37 apple kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering > I have small patch which corrects bus_dma related bugs but I'm not > sure it can fix the VLAN issue. I'll try this patch later today. Ian -- Ian Freislich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1MELRz-00015A-A5>