From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 23:55:33 2004 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 913FB16A4CE for ; Thu, 18 Nov 2004 23:55:33 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E07543D46 for ; Thu, 18 Nov 2004 23:55:33 +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 id IBA74465; Thu, 18 Nov 2004 15:55:32 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4BA8E5D04; Thu, 18 Nov 2004 15:55:32 -0800 (PST) To: "Wilkinson, Alex" In-reply-to: Your message of "Fri, 19 Nov 2004 09:06:43 +1030." <20041118223639.GA71388@squash.dsto.defence.gov.au> Date: Thu, 18 Nov 2004 15:55:32 -0800 From: "Kevin Oberman" Message-Id: <20041118235532.4BA8E5D04@ptavv.es.net> cc: freebsd-current@freebsd.org Subject: Re: stray IRQ .... 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, 18 Nov 2004 23:55:33 -0000 > Date: Fri, 19 Nov 2004 09:06:43 +1030 > From: "Wilkinson, Alex" > Sender: owner-freebsd-current@freebsd.org > > Hi all, > > Whenever I do a shutdown I notice the following warning/error: > > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...4 4 3 3 3 0 0 0 0 done > No buffers busy after final sync > Uptime: 16h6m31s > Shutting down ACPI > stray irq9 <------- This is what I am concerned about. > Rebooting... > > Is this anything to be concerned about ? > > What does this actually mean ? IRQ 9 is commonly used by ACPI and there seems to be a race where it generates an interrupt after the ACPI handler has gone away. It is common to many platforms and is not of great concern, although I think Nate is hoping to get rid of it some day. -- 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