Date: Thu, 27 May 2004 13:32:29 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Thomas Moestl <tmm@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/uart uart_dev_ns8250.c Message-ID: <20040527123826.R8527@gamplex.bde.org> In-Reply-To: <200405262159.i4QLx1cQ072334@repoman.freebsd.org> References: <200405262159.i4QLx1cQ072334@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 May 2004, Thomas Moestl wrote: > tmm 2004/05/26 14:59:01 PDT > > FreeBSD src repository > > Modified files: > sys/dev/uart uart_dev_ns8250.c > Log: > It seems that clearing the MCR_IE bit in the modem control register > does not reliably prevent the triggering of interrupts for all supported > configurations. Thus, the FIFO size probe could cause an interrupt, > which could lead to an interrupt storm in the shared interrupt case. s/It seems that clearing/Clearing/. Clearing MCR_IE disables the device's line driver for the irq. At least on old i386 isa systems, the line driver is normally connected to a tri-state latch which floats high due to a weak pullup when all its inputs are disabled. So "disabling" interrupts by clearing MCR_IE normally _causes_ exactly one interrupt on old i386 isa systems with edge-sensitive interrupts. If the interrupt is level-senstive and floats high, then it should be active-low so that there is not an interrupt storm from the spurious interrupt (and not even a single spurious interrupt) for the level-sensitive case. However, the buggy uart probe probably caused interrupt storms determistically for non-spurious interrupts as follows: - have a shared irq with one device already using it attached - cause an interrupt in the probe - the interrupt is enabled for the other device(s) attached to it, so it gets sent to the interrupt handler, but the interrupt handler can't handle it because the device that generated it isn't attached yet. The sio driver needs to generate interrupts in the probe for other reasons. It tries to avoid the problem by disabling CPU interrupts. This works right in the !SMP case, and I think it works well enough in the SMP case too. In the SMP case, other CPUs may see the interrupt, but if it is shared with an sio device then they will block and not see a storm; if it is shared with a non-sio device, then they may see a storm. In both cases, the CPU running the probe is unaffected and eventually handles the interrupt, so the interrupt or storm seen by the other CPUs goes away. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040527123826.R8527>