vr(4) troubles for AMD Geode CS5536 chipset

[YongHyeon PYUN]

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