Date: Sun, 7 May 2000 18:15:22 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Steve Passe <smp@csn.net> Cc: djb@ifa.au.dk, smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <Pine.BSF.4.21.0005071755480.9614-100000@besplex.bde.org> In-Reply-To: <200005070131.TAA79722@Ilsa.StevesCafe.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 6 May 2000, Steve Passe wrote: > I need to clarify, I can't think of any way the hlt could cause a stray irq7, > but in this business you can never say never... A "stray irq7" is what occurs Perhaps it does so by changing the timing. > when some piece of hardware causes an INT cycle on the PIC (in our case APIC) > to begin, but when the PIC gets to the INTACK cycle the hardware is no longer > asserting the INT. Thus the PIC has no way to build a vector to return on the > bus, so it arbitrarily uses the irq7 vector (intel design decision). Usually > the offending INT wasn't even asserted on the INT7 pin, but the hardware has > no > way of telling this... I believe its perfectly feasable that the stray irq7s > are causing printer related hangs, as a stray irq7 happening in a race with > real irq7s from the printer port could well cause problems. 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 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?Pine.BSF.4.21.0005071755480.9614-100000>