Date: Sun, 07 May 2000 10:29:18 -0600 From: Steve Passe <smp@csn.net> To: Bruce Evans <bde@zeta.org.au> Cc: djb@ifa.au.dk, smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <200005071629.KAA83403@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Sun, 07 May 2000 18:15:22 %2B1000." <Pine.BSF.4.21.0005071755480.9614-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> Authors of parallel port drivers and/or spl's should be aware of this :-).
> I think the ICU (and APIC?) mask for irq7 doesn't mask stray irq7's.
> Perhaps this causes more problems with the lazy interrupt masking and/or
> level triggering used in the SMP case (is irq7 ever level triggered?).
> The parallel port driver is sloppy about setting the bits in the ipl masks.
> Perhaps this causes more problems for stray irq7's than for normal ones.
>
> Bruce
---
Quoting from "Intel 82371AB PCI ISA IDE Xcelerator (PIIX4) Datasheet"
In both the edge and level triggered modes, the IRQ inputs must remain
active until after the falling edge of the first INTA#. If the IRQ input
goes inactive before this time, a default IRQ7 occurs when the CPU
acknowledges the interrupt. This can be a useful safeguard for detecting
interrupts caused by spurious noise glitches on the IRQ inputs. To
implement this feature, the IRQ7 routine is used for "clean up" simply
executing a return instruction, thus ignoring the interrupt. If IRQ7 is
needed for other purposes, a default IRQ7 can still be detected by reading
the ISR. A normal IRQ7 interrupt sets the corresponding ISR bit; a default
IRQ7 does not set this bit. However, If a default IRQ7 routine occurs
during a normal IRQ7 routine, the ISR remains set. In this case, it is
necessary to keep track of whether or not the IRQ7 routine was previously
entered. If another IRQ7 occurs, its a default.
---
I need to chew on your comments some more, but the bottom line is that there
should never be any "spurious noise glitches" on the irq lines. At this point,
we are talking about hardware bus cycles, and spl/ipl should have no causal
effect (although they might HIDE and/or ENHANCE the symptoms). I have noticed
stray irq7s on my desktop when removing a compactflash card from the card
reader. This hardware generates an INT when a pair of pins are shorted by
the act of inserting the card. I can imagine this causing glitches as the
(cheap) hardware probably doesn't buffer that pin well. Another reason that
stray irq7s sometimes occur is a misconfigured setup with "dueling INTs".
---
I just ran dmesg on my asus p2b-ds, FreeBSD 4.0-CURRENT #0: Mon Feb 14, 2000
and saw this:
stray irq 7
stray irq 7
stray irq 7
stray irq 7
stray irq 7
too many stray irq 7's; not logging any more
Perhaps we've added a problem that's gone unnoticed? This system does NOT have
the hlt patch.
This code is from i386/isa/intr_machdep.c:
/*
* XXX TODO print a different message for #7 if it is for a
* glitch. Glitches can be distinguished from real #7's by
* testing that the in-service bit is _not_ set. The test
* must be done before sending an EOI so it can't be done if
* we are using AUTO_EOI_1.
*/
if (intrcnt[1 + intr] <= 5)
log(LOG_ERR, "stray irq %d\n", intr);
So evidently we do not yet determine if an INT7 is "stray" or "real".
I don't think irq7 would be level mapped, unless the MPtable was hosed...,
it should say either conforms or edge. But mpapic.c should deal with that:
if ((bustype == ISA) &&
(pin < IOAPIC_ISA_INTS) &&
(irq == pin) &&
(apic_polarity(apic, pin) == 0x1) &&
(apic_trigger(apic, pin) == 0x3)) {
/*
* A broken BIOS might describe some ISA
* interrupts as active-high level-triggered.
* Use default ISA flags for those interrupts.
*/
flags = DEFAULT_ISA_FLAGS;
} else {
/*
* Program polarity and trigger mode according to
* interrupt entry.
*/
--
Steve Passe | powered by
smp@csn.net | Symmetric MultiProcessor FreeBSD
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005071629.KAA83403>