Date: Thu, 11 Nov 2010 13:18:08 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: Rob Farmer <rfarmer@predatorlabs.net> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pyun YongHyeon <yongari@freebsd.org>, Joel Dahl <joel@freebsd.org> Subject: Re: svn commit: r215132 - head/sys/dev/nfe Message-ID: <20101111211808.GE17566@michelle.cdnetworks.com> In-Reply-To: <AANLkTimjUgNLsvqzGNn7SEHZ_=7oF-BJyG2jS7bezy55@mail.gmail.com> References: <201011111808.oABI8olX079570@svn.freebsd.org> <20101111183409.GA1011@pluto.vnode.local> <20101111191900.GC17566@michelle.cdnetworks.com> <AANLkTimjUgNLsvqzGNn7SEHZ_=7oF-BJyG2jS7bezy55@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 11, 2010 at 11:56:43AM -0800, Rob Farmer wrote: > On Thu, Nov 11, 2010 at 11:19, Pyun YongHyeon <pyunyh@gmail.com> 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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101111211808.GE17566>