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