From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 17:56:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6AA51065679 for ; Tue, 11 Oct 2011 17:56:59 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 839298FC12 for ; Tue, 11 Oct 2011 17:56:59 +0000 (UTC) Received: by iaby12 with SMTP id y12so5295785iab.13 for ; Tue, 11 Oct 2011 10:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Rw34+XnUM3FbjkDaXv5wE2LI/+lhlmfu0tsCGVpB9cI=; b=plvq/sNBooOOstd2c+a1teYrGsqgreIdXg50TMKLlCiCsc6Jw1G/i6VetmZyl78m2G EMzx3Gt5ZxMy/qrc8HW4oMlwIycsCThirkc2pIU8Vlym0XduX68cyJ6LAtzT9Gc7gC8L LCSPM7d/I0OAD9xYQVeQLoiQ1pD3bYqyJ+csg= MIME-Version: 1.0 Received: by 10.231.67.80 with SMTP id q16mr10579656ibi.86.1318354287507; Tue, 11 Oct 2011 10:31:27 -0700 (PDT) Received: by 10.231.36.69 with HTTP; Tue, 11 Oct 2011 10:31:27 -0700 (PDT) In-Reply-To: <20111011171029.GA5661@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> Date: Tue, 11 Oct 2011 10:31:27 -0700 Message-ID: From: Kevin Oberman To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Karim , freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:56:59 -0000 On Tue, Oct 11, 2011 at 10:10 AM, YongHyeon PYUN wrote: > On Tue, Oct 11, 2011 at 11:40:42AM -0400, Karim wrote: >> Hi List, >> >> Using a Marvell NIC plugged into a CISCO switch I see the >> auto-negotiation failing and even when forcing the device to full-duplex >> we sometimes see packet drops. >> >> Here is the device description from dmesg: >> >> mskc0: port 0xbe00-0xbeff mem >> 0xfdefc000-0xfdefffff irq 16 at device 0.0 on pci1 >> msk0: on mskc0 >> msk0: Ethernet address: 00:03:2d:09:94:52 >> miibus0: on msk0 >> e1000phy0: PHY 0 on miibus0 >> e1000phy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> mskc0: [ITHREAD] >> >> The switch its plugged in (Cisco) is configured for 100baseTX full-duple= x. >> >> ifconfig reports: >> >> msk0: >> flags=3D608843 >> metric 0 mtu 1500 >> =A0 =A0 =A0 =A0 options=3D40018 > > The flags and options show that you're using very customized > driver, right? > >> =A0 =A0 =A0 =A0 ether 00:03:2d:09:94:52 >> =A0 =A0 =A0 =A0 inet 192.168.122.7 netmask 0xffffff00 broadcast 192.168.= 122.255 >> =A0 =A0 =A0 =A0 media: Ethernet autoselect (100baseTX ) > =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Resolved duplex is half so I guess it would be normal to see > dropped frames which may be triggered by collision. You have a duplex mis-match. If you are hard setting the remote end to full, the local end must also be configured o full. Auto-configuration of duplex requires that both ends run auto-config. When one end is set to not do auto-config, the other end SHOULD always set to half-duplex. This is part of 802.3 that is a carry-over from the days when hubs and coax dominated, so the default was declared to be half. Since so much hardware now exists with that default, changing it ill never happen. Either set your computer to full duplex or turn on auto-configuration on the Cisco. Very little hardware now in service fails to auto-config correctly, but the practice of lacking down the duplex setting became common in the early days of full-duplex when it was not yet a standard and many Ethernet chip-sets didn't play nice with others. Things would be much better if people would just stop hard-setting the duplex, but old, old habits and memes die hard. Also, contrary to common belief, collisions are NOT errors. They are a normal part of half-dulpex Ethernet operation and do NOT result in packets being dropped. Only "excessive collisions do and they ARE a real error and a clear indication that something is wrong. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com