Date: Mon, 3 Sep 2012 14:43:33 -0700 From: YongHyeon PYUN <pyunyh@gmail.com> To: Eugene Grosbein <egrosbein@rdtc.ru> Cc: freebsd-net@freebsd.org, Lev Serebryakov <lev@freebsd.org>, Ian Smith <smithi@nimnet.asn.au> Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset Message-ID: <20120903214333.GC3730@michelle.cdnetworks.com> In-Reply-To: <50443888.9080400@rdtc.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <CAHu1Y70MynCMQTrJUMwTZ0%2BLrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 03, 2012 at 11:56:40AM +0700, Eugene Grosbein wrote: > 04.09.2012 01:40, YongHyeon PYUN пишет: > > >> Presently, every day my WAN vr interface stops running correctly: > >> sometimes it stops receiving all packets - tcpdump shows none of them. > >> Sometimes, it receives some but with great delay - up to 10 seconds (not miliseconds) > >> and even more. tcpdump shows that delay occurs on receive path. > >> Sometimes, it even rearranges packets - tcpdump shows that some incoming ICMP echo requests > >> with lower sequence numbers come in later that already answered higher-numbered requests. > > > > Hmm, it seems driver's consumer/producer index of RX path were > > corrupted. > > Have you any idea how to find that out for sure? Sorry, no clue yet. The only wild guess I have at this moment is handling for VR_ISR_RX_NOBUF/VR_ISR_RX_OFLOW interrupt. It forces to restart RX MAC by reprogramming VR_RXADDR register. If driver is out of sync with hardware this may produce unexpected results. The VIA data sheet I have has no special comments on this as other VIA data sheets. > Add some debug printfs or KASSERT, may be? > I'm ready to test. > > > By chance, did vr(4) spew some kind of diagnostics messages to > > console? If I remember correctly, vr(4) automatically restarts > > controller and show these errors when it detects abnormal > > condition. Abnormal conditions for vr(4) would be: > > - TX/RX MAC stuck > > - RX MAC stop due to FIFO overflow or no RX buffers > > - PCI bus errors > > - TX abort > > - TX underrun > > > > None. I've read its source and learned it prints its debug > to the kernel dmesg buffer with sysctl dev.vr.1.stats=1 > and done that before, during and after noted failure - > all counters are zero except of good frames conters (in/out). Ok, it seems you didn't encounter TX/RX MAC shutdown/restart related issues. To get more verbose debugging messages, you have to define VR_SHOW_ERRORS in if_vr.c. BTW, I see really poor bulk TCP performance on vr(4) with CURRENT (< 12 Mbps). :-( This is a quad-port VT6105 with Core2 Duo E6550. Pre-r235334 restores the old good performance for me(> 86Mbps). However I can't explain how taskq change shows this huge difference. > > Eugene Grosbein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120903214333.GC3730>