From owner-freebsd-current@FreeBSD.ORG Thu Apr 17 09:25:53 2003 Return-Path: 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 A4BA737B405 for ; Thu, 17 Apr 2003 09:25:53 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B2BF43FBD for ; Thu, 17 Apr 2003 09:25:52 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 17482 invoked from network); 17 Apr 2003 16:25:56 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 17 Apr 2003 16:25:56 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3HGPnOv075711; Thu, 17 Apr 2003 12:25:50 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200304171722.aa13792@salmon.maths.tcd.ie> Date: Thu, 17 Apr 2003 12:25:51 -0400 (EDT) From: John Baldwin To: Ian Dowse cc: current@freebsd.org cc: Andrew Gallatin cc: Nate Lawson Subject: Re: Your locking and rman changes to pci/if_* X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Thu, 17 Apr 2003 16:25:53 -0000 On 17-Apr-2003 Ian Dowse wrote: > In message <20030417113218.GA96808@sunbay.com>, Ruslan Ermilov writes: >> >>Yes, Ian's patch did the trick. Let me know if you still want a backtrace, >>and should it be against the kernel with debug information or not. > > FYI, below is the backtrace that I got. The fact that the trap was > in softclock() was a good indication of a missing callout_stop(). > It looks BTW, as if we convert some kernel page faults into witness > panics, which is not so good... I think it is limited to cases where > we page fault without Giant, but with a spin lock held (in this > case callout_lock). Yes, the trap_pfault() should basically just instantly do a trap_fatal() if td_critnest != 0. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/