From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 05:43:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 171B3106564A; Mon, 3 Sep 2012 05:43:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CDC238FC19; Mon, 3 Sep 2012 05:43:41 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so7454542pbb.13 for ; Sun, 02 Sep 2012 22:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=RgMob0m3zZWLjIMWlI7lygFAicBJTNDadx1oMhWml3M=; b=G2lfFoIyfFqoh3sVSsIs6LS1zmm9Jkd3A6jWQr4JnoxN6pExSAbmyJKus8vueW6Zgp /XGeWKlnuMy72oamJXX2vpwaAVABU4/qANtFYZUXG8c9ZoUO2JDJcsv/Z/XMIpHOPg7H LljRhnzsd5TpzpvUyOPivswN3S1TEG3wlSY5vZOd18ruUHSL5Lti9UV9iTuwQKOd+D12 RtwkE8UnfOJSbeP0vz5pSEHGcTZye3GJbpEqbZm9Aa4mwA0p5j90k16SoUB+RHFXn06p 6zBZeQyWTva16wRFHawiL/f36UdPL8c2cRJXv6gdf+qjG9J2XK6+2lHZuXahf4C3oWhf CThA== Received: by 10.66.84.130 with SMTP id z2mr31532321pay.77.1346651021429; Sun, 02 Sep 2012 22:43:41 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id oc2sm9154599pbb.69.2012.09.02.22.43.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Sep 2012 22:43:40 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 03 Sep 2012 14:43:33 -0700 From: YongHyeon PYUN Date: Mon, 3 Sep 2012 14:43:33 -0700 To: Eugene Grosbein Message-ID: <20120903214333.GC3730@michelle.cdnetworks.com> References: <1865271844.20120829131610@serebryakov.spb.ru> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <50443888.9080400@rdtc.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:43:42 -0000 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