From owner-cvs-all@FreeBSD.ORG Sat Oct 30 23:23:15 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D30216A4CE; Sat, 30 Oct 2004 23:23:15 +0000 (GMT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8933B43D31; Sat, 30 Oct 2004 23:23:14 +0000 (GMT) (envelope-from gibbs@scsiguy.com) Received: from caspian.scsiguy.com (caspian.scsiguy.com [63.229.232.105]) by aslan.scsiguy.com (8.12.11/8.12.11) with ESMTP id i9UNMilH043126; Sat, 30 Oct 2004 17:22:44 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Wed, 27 Oct 2004 15:31:57 -0600 From: "Justin T. Gibbs" To: Bruce M Simpson , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Message-ID: In-Reply-To: <200410271902.i9RJ2Nui009028@repoman.freebsd.org> References: <200410271902.i9RJ2Nui009028@repoman.freebsd.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: cvs commit: src/sys/pci if_vr.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 23:23:15 -0000 > bms 2004-10-27 19:02:23 UTC > > FreeBSD src repository > > Modified files: > sys/pci if_vr.c > Log: > Forcibly disable interrupts, if we find ourselves servicing one when > the device is suspended or shutting down. This will need to be rethought > slightly if we implement suspend/resume support within vr(4). > This appears to fix the vr_shutdown() panic on SMP machines. > > My theory here is there's a race somewhere during vr_detach() with > vr_intr() in the SMP case which was sometimes being triggered, > although quite why this was happening is unclear (vr_stop() also > explicitly disables interrupts by writing to the IMR register). Don't you have to detach the isr and wait for any pending interrupts to "drain" before being assured that no future entry into your ISR is possible? Just disabling interrupts in the hardware doesn't prevent entry into your ISR if the system has just seen an interrupt for your vector, and it certainly does not thing to prevent another device sharing your interrupt from triggering your handler. -- Justin