From owner-freebsd-stable@FreeBSD.ORG Thu Nov 2 18:11:30 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15FFC16A58F for ; Thu, 2 Nov 2006 18:11:30 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8266343D9B for ; Thu, 2 Nov 2006 18:11:08 +0000 (GMT) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-67-174-220-97.hsd1.ca.comcast.net[67.174.220.97]) by comcast.net (rwcrmhc12) with ESMTP id <20061102181100m12000fpfie>; Thu, 2 Nov 2006 18:11:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B125D1FA01A; Thu, 2 Nov 2006 10:10:59 -0800 (PST) Date: Thu, 2 Nov 2006 10:10:59 -0800 From: Jeremy Chadwick To: Jack Vogel Message-ID: <20061102181059.GA23733@icarus.home.lan> Mail-Followup-To: Jack Vogel , "Patrick M. Hausen" , freebsd-stable@freebsd.org, zenker@punkt.de References: <20061102094332.GA15810@hugo10.ka.punkt.de> <2a41acea0611020943p9c91b6fv1e61cd9ea0082b77@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0611020943p9c91b6fv1e61cd9ea0082b77@mail.gmail.com> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org, zenker@punkt.de Subject: Re: New em driver - still watchdog timeouts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 18:11:30 -0000 On Thu, Nov 02, 2006 at 09:43:34AM -0800, Jack Vogel wrote: > Yes, I know this is still happening. I also have pretty good data now > that its a bogus problem, meaning due to scheduling issues the > watchdog does not get reset even though the system is just fine > as far as transmit descriptors is concerned. I have a patch that > detects this and keeps the watchdog from erroneously resetting > you, it has been running on my test system for days now without > problems. I don't understand this explanation of the problem. Here's how I read this paragraph: * It's a "bogus problem" (which means there's not a problem) * ...due to "scheduling issues" (which means there IS a problem) * The watchdog does NOT get reset * ...but there's a patch (to fix the "bogus problem"? or what?) * ...which keeps the watchdog from resetting (but you just said...) Maybe you were in a hurry, I don't know. Either way, the paragraph doesn't make sense. I call for clarification! ;-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |