Skip site navigation (1)Skip section navigation (2)
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>