Skip site navigation (1)Skip section navigation (2)
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>