Date: Sun, 27 Oct 1996 22:06:23 -0800 From: "Amancio Hasty Jr." <hasty@star-gate.com> To: hackers@freebsd.org Subject: [Fwd: Re: PPro-200 bugged ?] Message-ID: <32744D5F.794BDF32@star-gate.com>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------1CFBAE3959E2B60015FB7483 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Amancio Hasty Hasty Software Consulting Services Tel: 415-495-3046 Fax: 415-495-3046 Cellular: 415-309-8434 e-mail: hasty@star-gate.com Powered by FreeBSD --------------1CFBAE3959E2B60015FB7483 Content-Type: message/news Content-Transfer-Encoding: 7bit Content-Disposition: inline Path: nntp1.best.com!news1.best.com!www.nntp.primenet.com!nntp.primenet.com!arclight.uoregon.edu!feed1.news.erols.com!howland.erols.net!newsfeed.internetmci.com!news1.anet-dfw.com!usenet From: Christian Ludloff <ludloff@anet-dfw.com> Newsgroups: comp.sys.intel Subject: Re: PPro-200 bugged ? Date: Fri, 25 Oct 1996 01:27:09 -0500 Organization: Those who talk, don't know. Those who know, don't talk. Message-ID: <32705DBD.E7@anet-dfw.com> References: <01bbc0eb$309d8de0$03c69ac2@almana.pt.lu> <326fb5cb.6881455@netnews.worldnet.att.net> <54og9n$9re@panix2.panix.com> Reply-To: ludloff@anet-dfw.com NNTP-Posting-Host: ppp54b.anet-dfw.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0Gold (Win95; I) To: Michael Halem <rocket@panix.com> Hello Michael Halem, > Can you send us the text of the Microsoft Email regarding the "Stop F" bug > under NT 4.0 and the name or source of the Microsoft email? The bug is related to the integrated APIC, which under specific circumstances may trigger a spurious interrupt. External interrupts are reported as IRQs. IRQ0..7 come in as INTR8..15, while they could be re-vectored to other INTRs as well (AFAIK WinNT doesn't do it). A spurious IRQ comes in as IRQ7 which is INTR15. INTR15 will invoke a handler 0Fh, which handles exceptions and interrupts (INTR or software INTs). Since a x86 processor exception 0Fh isn't used (because it is this spurious IRQ), the handler can easily differ between a valid IRQ7 (pending PIC bits), a software interrupt (EFLAGS.IF or opcode at origin CS:EIP), and the spurious IRQ (which is anything else then). Thus, a good handler (=good OS) would handle that. It would otherwise not fix the problem that the integrated APIC caused it. (That is why Intel promised to fix it.) The descriptin of this problem can be found in the iPentiumPro's spec update, oder number 242689, under erratum 5AP. For single processor systems there can be workaround in the BIOS code, disabling the local APIC. (It's not needed in a single CPU system.) If you need more information, please contact me. -- Christian Ludloff [Intel's log, stardate 10/30/1994] We are Pentium (TM) ludloff@anet-dfw.com of borg. Division is futile. You will be approximated. Speaking for myself. Any trademark is the property of the respective owner. --------------1CFBAE3959E2B60015FB7483--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32744D5F.794BDF32>