From owner-freebsd-current@FreeBSD.ORG Tue Jul 25 23:06:54 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 A068C16A4E5 for ; Tue, 25 Jul 2006 23:06:54 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15C9943D58 for ; Tue, 25 Jul 2006 23:06:53 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id 1C4999A9AC; Wed, 26 Jul 2006 01:06:53 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 909A99C9CA; Tue, 25 Jul 2006 23:07:21 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 70093405F; Wed, 26 Jul 2006 01:07:21 +0200 (CEST) Date: Wed, 26 Jul 2006 01:07:21 +0200 From: Jeremie Le Hen To: Jack Vogel Message-ID: <20060725230721.GL6253@obiwan.tataz.chchile.org> References: <20060721123448.GV6253@obiwan.tataz.chchile.org> <44C1CE73.7030200@FreeBSD.org> <20060725124328.GI6253@obiwan.tataz.chchile.org> <2a41acea0607251119i33176020pfc4183ecd2251dd2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0607251119i33176020pfc4183ecd2251dd2@mail.gmail.com> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: em(4) watchdog timeout 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, 25 Jul 2006 23:06:54 -0000 Jack, others, On Tue, Jul 25, 2006 at 11:19:22AM -0700, Jack Vogel wrote: > On 7/25/06, Jeremie Le Hen wrote: > >I am rebuilding a fresher one right now. According to Ian's post, > >the problem is likely to remain. What do you advice me to do to > >track this down ? > > > >FYI, my -CURRENT kernel (as well userland) is patched with ProPolice. > >I don't think this can lead to this kind of problem, the overhead is > >really small, in an order of 3 percent. Do you think such an > >overhead in a time-critial path could trigger a watchdog timeout ? > > Well, watchdogs ARE about timeouts :) > > I know nothing about ProPolice but would suggest removing for a test > and see if the problem goes away. As a matter of fact ProPolice protects stack-based buffer overflows by pushing an additional value in the stack during vulnerable functions' prologue and checking it within the epilogue. This is really a matter of a few CPU cycles. Nevertheless, I will try to reproduce the problem as-is and will also recompile my kernel without ProPolice ASAP. > As for the debug_info and stats data you sent, there was nothing that > looked bad in it, but those are more of a dynamic tool, its when the > problem occurs that this will possibly show why.... I know, it doesnt > make it easy :( It would be a pain to do it manually, I will try to write a small script thates watch over dmesg and issues a few sysctl on debug_info whenever it detects a watch dog timeout. Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >