Date: Wed, 27 Oct 2004 15:31:57 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Bruce M Simpson <bms@FreeBSD.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/pci if_vr.c Message-ID: <F984F473F79BBB9BF467E2C4@caspian.scsiguy.com> In-Reply-To: <200410271902.i9RJ2Nui009028@repoman.freebsd.org> References: <200410271902.i9RJ2Nui009028@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F984F473F79BBB9BF467E2C4>