From owner-freebsd-current@FreeBSD.ORG Tue Mar 28 06:39:36 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D5C516A420; Tue, 28 Mar 2006 06:39:36 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (dsl-230-156.ipns.com [209.210.230.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1069343D48; Tue, 28 Mar 2006 06:39:32 +0000 (GMT) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.13.4/8.13.3) with ESMTP id k2S6dWmI046920; Mon, 27 Mar 2006 22:39:32 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.13.4/8.13.3/Submit) id k2S6dVJZ046919; Mon, 27 Mar 2006 22:39:31 -0800 (PST) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Mon, 27 Mar 2006 22:39:31 -0800 From: David Greenman-Lawrence To: Sergey Matveychuk Message-ID: <20060328063930.GC12815@tnn.dglawrence.com> References: <20060328044432.152CD45047@ptavv.es.net> <4428CA90.7090501@FreeBSD.org> <200603281247.49142.root@solink.ru> <4428D0EE.6080603@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4428D0EE.6080603@FreeBSD.org> Cc: Bachilo Dmitry , freebsd-current@FreeBSD.org Subject: Re: nve0: device timeout (1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 06:39:36 -0000 > Bachilo Dmitry wrote: > > Patch, by the way, was rejected. I have edited if_nve.c by hands, just changed > > Yep. It looks as a workaround, not a fix. Right. It's a reasonable work-around, however, so people shouldn't be afraid of using it. Here is my original message on this subject: In reply to... > It doesn't only run into timeouts, during some of these timeout the > machine or at least the keyboard hangs for about a minute. > > Is there anything I can do to help debug this? I ran into this problem recently as well and spent some time diagnosing it. It's not that the cable isn't plugged in - rather it happens whenever the traffic levels are low. The problem is that the nvidia-supplied portion of the driver is defering the releasing of the completed transmit buffers and this occasionally results in if_timer expiring, causing the driver watchdog routine to be called ("device timeout"). The watchdog routine resets the card and the nvidia-supplied code sits in a high-priority loop waiting for the card to reset. This can take many seconds and your system will be hung until it completes. I have a work-around patch for the problem that I've attached to this email. It simply disables the watchdog. A real fix would involve accounting for the outstanding transmit buffers differently (or perhaps not at all - e.g. always attempt to call the nvidia-supplied code and if a queue-full error occurs, then wait for an interrupt before trying to queue more transmit packets). Index: if_nve.c =================================================================== RCS file: /home/ncvs/src/sys/dev/nve/if_nve.c,v retrieving revision 1.7.2.8 diff -c -r1.7.2.8 if_nve.c *** if_nve.c 25 Dec 2005 21:57:03 -0000 1.7.2.8 --- if_nve.c 5 Jan 2006 00:12:45 -0000 *************** *** 943,949 **** return; } /* Set watchdog timer. */ ! ifp->if_timer = 8; /* Copy packet to BPF tap */ BPF_MTAP(ifp, m0); --- 943,949 ---- return; } /* Set watchdog timer. */ ! ifp->if_timer = 0; /* Copy packet to BPF tap */ BPF_MTAP(ifp, m0); -DG David Greenman-Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities.