Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jan 2006 16:21:03 -0800
From:      "David G. Lawrence" <dg@dglawrence.com>
To:        Martin Cracauer <cracauer@cons.org>
Cc:        "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, FreeBSD current mailing list <current@freebsd.org>
Subject:   Re: nve(4) patch - please test!
Message-ID:  <20060105002103.GB98594@tnn.dglawrence.com>
In-Reply-To: <20060104183612.A88093@cons.org>
References:  <20051209175607.C23668@maildrop.int.zabbadoz.net> <20051210125221.M23668@maildrop.int.zabbadoz.net> <20051216173106.B31803@cons.org> <20060104183612.A88093@cons.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> Since I sent the mail below I had to discover that the new driver
> has a problem when no cable is plugged in, at least on my Asus board.
> 
> 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).

-DG

David G. 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.

--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="nve.diff"

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);

--YiEDa0DAkWCtVeE4--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060105002103.GB98594>