From owner-freebsd-net@FreeBSD.ORG Sun Jul 14 19:52:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2C763BDB for ; Sun, 14 Jul 2013 19:52:42 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id CBD2111E for ; Sun, 14 Jul 2013 19:52:41 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 608145CE7B; Sun, 14 Jul 2013 21:52:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id bKJyTQPZGOTW; Sun, 14 Jul 2013 21:52:39 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 7B76C5CE76; Sun, 14 Jul 2013 21:52:39 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 1B68C50861; Sun, 14 Jul 2013 21:52:39 +0200 (CEST) Message-ID: <51E30186.9050707@incore.de> Date: Sun, 14 Jul 2013 21:52:38 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: sis(4) flow control References: <51DC1599.8040805@incore.de> <20130710023512.GB2753@michelle.cdnetworks.com> <51DDDDAB.6070100@incore.de> <20130711002557.GA6697@michelle.cdnetworks.com> <51E1B8F0.5030100@incore.de> <20130714100347.GA1105@michelle.cdnetworks.com> In-Reply-To: <20130714100347.GA1105@michelle.cdnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 19:52:42 -0000 Yonghyeon PYUN wrote: >> Maybe there is a bug in vr(4) that generates the hang, but why is > > Probably yes and I shall have to narrow down the issue. One more hint: No hang - but of course no TX support - anymore, when I use --- if_vr.c.orig 2013-06-25 09:58:29.000000000 +0200 +++ if_vr.c 2013-07-14 18:09:12.000000000 +0200 @@ -351,7 +351,6 @@ fc |= VR_FLOWCR1_RXPAUSE; if ((IFM_OPTIONS(mii->mii_media_active) & IFM_ETH_TXPAUSE) != 0) { - fc |= VR_FLOWCR1_TXPAUSE; sc->vr_flags |= VR_F_TXPAUSE; } CSR_WRITE_1(sc, VR_FLOWCR1, fc); Probably the RX pause frames will work with this patch. >> negotiation of flowcontrol on vr(4) not done at boot time as shown for >> msk(4) ? >> > > msk(4) supported flow-control from day 1 with a hack and it was > re-implemented later with proper way such that it always announces > flow-control. However for other drivers(i.e vr(4)) that didn't > support the feature in the beginning, you have to explicitly enable > the feature. The decision was made to provide compatibility and to > not introduce POLA. Thanks for clarification, I see the flag MIIF_FORCEPAUSE does the job. >> If you need more information about the hang let me know. > > I guess it would be good idea to use a link partner that shows > hardware MAC statistics. If your switch provides such information > that's fine. If you use direct connection between two hosts without > switch, use other network drivers(most gigabit controllers support > hardware MAC counters). I can easy realize to use my laptop with msk(4) as a link partner for my soekris box with vr(4). -- Dr. Andreas Longwitz