From owner-svn-src-head@FreeBSD.ORG Thu Nov 11 21:49:06 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75437106566C; Thu, 11 Nov 2010 21:49:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 252108FC12; Thu, 11 Nov 2010 21:49:05 +0000 (UTC) Received: by pxi1 with SMTP id 1so539410pxi.13 for ; Thu, 11 Nov 2010 13:49:05 -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=p7hVfB9yFAtYSbkB3ApOar4y4L8T4paheND/zD7ZuHY=; b=VOrp0nj+Ry7eRgHsIeDUmxXAgSia+6xkFRbHnQ595cMemYglS7Z7PckMYLZt/eEc0D djyqH+hkY04odvAjd8cR2CrjthNN2KCCU5tY2hf7oIm80TO3UoCXCp2xBJamGzOxqd9T NdwG1IKPC0qoh6C4PRHBwcyGyQJ+Nn8WeVl2A= 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=n9HnXPV0lnNYob9Hlbj6BS4hN9fBSLjrZh4CppGV5d9qvh8NEG3TyM4iw8NBYi0Kxj x3LnQjJetLSaUT64NmkIC4FgGoMz+mM1Uq0naIpfe1aoSm/0fNXNeIT9ERIHH2IlNrR6 b1xy6d4hbedBz3knIuQywW4YbLqtvsNa9iGRE= Received: by 10.143.18.20 with SMTP id v20mr1163449wfi.113.1289512145638; Thu, 11 Nov 2010 13:49:05 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v19sm2891682wfh.0.2010.11.11.13.49.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 13:49:04 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Nov 2010 13:48:10 -0800 From: Pyun YongHyeon Date: Thu, 11 Nov 2010 13:48:10 -0800 To: Rob Farmer Message-ID: <20101111214810.GH17566@michelle.cdnetworks.com> References: <201011111808.oABI8olX079570@svn.freebsd.org> <20101111183409.GA1011@pluto.vnode.local> <20101111191900.GC17566@michelle.cdnetworks.com> <20101111211808.GE17566@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-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:49:06 -0000 On Thu, Nov 11, 2010 at 01:34:34PM -0800, Rob Farmer wrote: > On Thu, Nov 11, 2010 at 13:18, Pyun YongHyeon 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