From owner-svn-src-all@FreeBSD.ORG Thu Nov 11 21:19:05 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 726CB106566B; Thu, 11 Nov 2010 21:19:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 22DA08FC0C; Thu, 11 Nov 2010 21:19:04 +0000 (UTC) Received: by pwi10 with SMTP id 10so539852pwi.13 for ; Thu, 11 Nov 2010 13:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=4h0nHWajC6ZAPk83cLk+lLBy5JifCG6voFrc/glUAmE=; b=Sd7kKP0iMAZB7QJtcseScoNBWJHUoNXOA7m7hFjSqwoGggcqzKwnkr+ef2ZAExaxaV hywrUo1RcLT7Mrl55L6q43x3b21sNeuKPXULocuDjyLzpZmhuKFUPVNJ6Vw0eglhTQzM LEFHszf6dPNpMQov0g3I7RJxllDBuQo5a7s94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Z4YtnZ5IcX6jw+TQgIrBa9Q6dXD0daMpvldAkoGJcGGoWy7C+QeyY/iPPFw26s3aTV egcnX22QhMuVNpwJ3MkvPZJyx5Eae5QgcjMVsaSitg4O9ZuzORVYbYrwbesy1+cmPpwN JFIv7M7GSa4RrjFcbSkw5uh/wS8Or9UIj4ye0= Received: by 10.142.43.5 with SMTP id q5mr851461wfq.401.1289510344583; Thu, 11 Nov 2010 13:19:04 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id x18sm2855673wfa.11.2010.11.11.13.19.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 13:19:03 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Nov 2010 13:18:08 -0800 From: Pyun YongHyeon Date: Thu, 11 Nov 2010 13:18:08 -0800 To: Rob Farmer Message-ID: <20101111211808.GE17566@michelle.cdnetworks.com> References: <201011111808.oABI8olX079570@svn.freebsd.org> <20101111183409.GA1011@pluto.vnode.local> <20101111191900.GC17566@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pyun YongHyeon , Joel Dahl Subject: Re: svn commit: r215132 - head/sys/dev/nfe X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:19:05 -0000 On Thu, Nov 11, 2010 at 11:56:43AM -0800, Rob Farmer wrote: > On Thu, Nov 11, 2010 at 11:19, Pyun YongHyeon wrote: > > On Thu, Nov 11, 2010 at 07:34:09PM +0100, Joel Dahl wrote: > >> On 11-11-2010 18:08, Pyun YongHyeon wrote: > >> > Author: yongari > >> > Date: Thu Nov 11 18:08:50 2010 > >> > New Revision: 215132 > >> > URL: http://svn.freebsd.org/changeset/base/215132 > >> > > >> > Log: > >> > ? Add basic WOL support for MCP ethernet controllers. It seems the > >> > ? controller does not perform automatic switching from 1000Mbps link > >> > ? to 10/100Mbps link when WOL is activated. Implement establishing > >> > ? 10/100Mps link with auto-negotiation in driver. Link status change > >> > ? handler was modified to remove taskqueue based approach since driver > >> > ? now needs synchronous handling for link establishment. > >> > >> Somewhat unrelated but this commit reminds me of something: why do we still > >> keep the nve driver? ?I thought nfe was written as a replacement years ago? > >> > > > > Perhaps to address edge cases not covered by nfe(4)? > > Personally I don't know any of them. > > amd64/115126 ? > > Its even assigned to you. > Yes, but I think this has nothing to do with the subject. I think MCP controllers have a silicon bug that does not generate TX completion interrupts under certain conditions/controller models. The PR indicates what was really happened which also indicates possible silicon bug. nve(4) also seems to have some workaround for that but I wanted to verify it since we don't know what binary blob did during controller initialization. The message just shows informational message and does not reset controller so I think that edge case is already handled by nfe(4).