Date: Thu, 11 Nov 2010 13:48:10 -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: <20101111214810.GH17566@michelle.cdnetworks.com> In-Reply-To: <AANLkTikCUBj=j7smC7Jpw_p9g1chPsShEhYEFGws7EHY@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> <20101111211808.GE17566@michelle.cdnetworks.com> <AANLkTikCUBj=j7smC7Jpw_p9g1chPsShEhYEFGws7EHY@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 11, 2010 at 01:34:34PM -0800, Rob Farmer wrote: > On Thu, Nov 11, 2010 at 13:18, Pyun YongHyeon <pyunyh@gmail.com> wrote: > > 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). > > > > I have a system that does this same thing - watchdog timeout (missed > Tx interrupts) over and over. It also generates so much bogus traffic As I said, the message is informational one so you can ignore it. nve(4) just does not show any message for that case. > that all other systems connected to the same switch/hub lose their > network connection while the machine is running. Switching to nve > resolves the problem. > I believe you're the first one that reported real issue. Could you give me more details about bogus traffic? I don't know what PHY was used with the controller but e1000phy(4) may have advertised flow-control so the bogus traffic could be a kind of flow-control storm triggered nfe(4)/e1000phy(4). Maybe opening a PR with dmesg/pciconf output would be better. > If it can't be fixed, that's fine. Just please don't remove nve - > there are systems that need it. > > -- > Rob Farmer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101111214810.GH17566>