From owner-freebsd-smp Sat May 6 18:31:19 2000 Delivered-To: freebsd-smp@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id 17CA237B8CB for ; Sat, 6 May 2000 18:31:15 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id TAA79722; Sat, 6 May 2000 19:31:09 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200005070131.TAA79722@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: djb@ifa.au.dk Cc: Steve Passe , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues In-reply-to: Your message of "Sun, 07 May 2000 01:38:50 +0200." <20000507013850.A1023@relativity.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 May 2000 19:31:09 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > On Sat, May 06, 2000 at 04:48:51PM -0600, Steve Passe wrote: > > I think you have something else going on here, the hlt/nohlt issue should > > not cause stray irq7s. And using hlt should not hang your system during > > printing. My 4way has been running with hlt for a week or so now, with > > no hangs (although I admittedly have no printer on the pport). > > I have never had stray irq7's as long as the machine exists (which is > exactly as long as it's running FreeBSD) until I put in the hlt > instruction. They are definitely triggered by turning on the hlt > instruction in the kernel. > > The hang may be a coincidence, however (albeit a damn lucky one if it is). > I still haven't solved the random SMP related hang issue on my Abit BP6 > system and I haven't even found its trigger after all this time (check the > thread called "SMP and vn" for details). > > So the hang may be caused by something else but it's almost too much of a > coincidence that it occurs during printing because I rarely print from that > machine. It is not reproducible, however: I just finished printing some > large documents for testing. > > I'll assume for now that you're right and that the hang isn't hlt-related > (but the stray irq7 is). 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 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. So in summary: I can't see how hlt could cause stray irq7s (but it might...) stray irq7s could well cause a hang if occurring during printing. -- 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