From owner-freebsd-current@FreeBSD.ORG Tue Mar 28 04:36:11 2006 Return-Path: X-Original-To: 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 1BC8316A401 for ; Tue, 28 Mar 2006 04:36:11 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id D678443D48 for ; Tue, 28 Mar 2006 04:36:10 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 27 Mar 2006 20:36:05 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 64C9F45047; Mon, 27 Mar 2006 20:36:06 -0800 (PST) To: Bachilo Dmitry In-reply-to: Your message of "Tue, 28 Mar 2006 09:56:30 +0700." <200603280956.30659.root@solink.ru> Date: Mon, 27 Mar 2006 20:36:06 -0800 From: "Kevin Oberman" Message-Id: <20060328043606.64C9F45047@ptavv.es.net> Cc: 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 04:36:11 -0000 > From: Bachilo Dmitry > Date: Tue, 28 Mar 2006 09:56:30 +0700 > Sender: owner-freebsd-current@freebsd.org > > I've recently upgraded one of my home PCs from Intel Celeron to AMD Athlon. I > used to have Marvel Gigabit network (sk), and now I have nVidia nForce 3 > network - nve (witch man says: "First appeared in FreeBSD 5.5", so it has > not appeared yet? :-) > > The problem is that if this interface is online and I run something that uses > network (for example XChat, or even Quake 4, witch is always accessing > 127.0.0.1 for ID Server), then like every minute (interval is not always the > same) the computer hangs absolutely (even mouse is not moving) for like two > seconds and then "Jan 2 09:41:12 gamer kernel: nve0: device timeout (1)" > falls on tty0. > > And dmesg says: > Jan 2 09:39:13 gamer kernel: nve0: device timeout (1) > Jan 2 09:39:13 gamer kernel: nve0: link state changed to DOWN > Jan 2 09:39:14 gamer kernel: nve0: link state changed to UP > Jan 2 09:39:44 gamer kernel: nve0: device timeout (1) > Jan 2 09:39:44 gamer kernel: nve0: link state changed to DOWN > Jan 2 09:39:46 gamer kernel: nve0: link state changed to UP > Jan 2 09:40:16 gamer kernel: nve0: device timeout (1) > Jan 2 09:40:16 gamer kernel: nve0: link state changed to DOWN > Jan 2 09:40:17 gamer kernel: nve0: link state changed to UP > Jan 2 09:40:48 gamer kernel: nve0: device timeout (1) > Jan 2 09:40:48 gamer kernel: nve0: link state changed to DOWN > Jan 2 09:40:49 gamer kernel: nve0: link state changed to UP > Jan 2 09:41:12 gamer kernel: nve0: device timeout (1) > Jan 2 09:41:12 gamer kernel: nve0: link state changed to DOWN > Jan 2 09:41:13 gamer kernel: nve0: link state changed to UP > Jan 2 09:41:22 gamer kernel: nve0: device timeout (1) > Jan 2 09:41:22 gamer kernel: nve0: link state changed to DOWN > Jan 2 09:41:23 gamer kernel: nve0: link state changed to UP > > and so on. > > This, you know, spoils all the mood from upgrade. Do I do something wrong or > is that driver or is that the device? > > First I thought that it was overclocking problem, but no, I've set > everything to default and the problem stays. > I use this PC for games, no secure data or anything else is there, so if it > would be necessary, I could provide ssh shell to it. No need. This has been a popular thread for the past few days, but some information might be useful. Is the system an Athlon-64? Is it running amd64 or i386? SMP? Which scheduler are you running? Some systems seem to run fine with the driver in 6.1-Beta. Others show the timeouts. Sometimes they recover. Other times they don't. I have four identical systems. Two never have the problem. One has it a lot and sometimes totally locks up; other times just logs the timeouts. Turning off the watchdog timer in the source may work around the problem. It's probably not a real fix, but, if it works... *** 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); -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634