From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: Chris Wedgwood <cw@f00f.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
swsnyder@home.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
macro@ds2.pg.gda.pl
Subject: Re: "APIC error on CPUx" - what does this mean?
Date: Tue, 8 Jan 2002 18:35:35 +0100 [thread overview]
Message-ID: <E542D8F46A1@vcnet.vc.cvut.cz> (raw)
On 9 Jan 02 at 1:30, Chris Wedgwood wrote:
> On Tue, Jan 08, 2002 at 01:12:04PM +0100, Maciej W. Rozycki wrote:
>
> A possible reason is the 8259A in the chipset deasserts its INT
> output late enough for the Athlon CPU's local APIC to register
> another ExtINTA interrupt sometimes, possibly under specific
> circumstances.
>
> Actully... we could potentially measure this... after an interrupt it
> serviced (or before, or both) we could store the interrupt source
> globally and the cycle counter... when a suprrious interrupt is
> received check the last interrupt and how long ago it was and then
> start looking for a pattern...
I instrumented kernel at home, and when spurious interrupt happens,
stack trace almost always says that spurious interrupt happened
during HLT in default_idle (if I disable ACPI...), ISR is always zero,
and IRR contains 0x00 (before parport driver is loaded) or 0x80
(after parport driver is loaded (without IRQ support)). Few times
stack trace was different, and pointed to ide__sti() in ide_do_request,
but it was < 5% of occurences.
As spurious IRQ happens during HLT, and IRR is clear at the time
we are going to ack IRQ, it looks like real spurious IRQ (caused by
noise?). Or delay between spurious one and real IRQ is really long.
I'll try some of your suggestions today night.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
next reply other threads:[~2002-01-08 17:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-08 17:35 Petr Vandrovec [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-01-09 12:41 "APIC error on CPUx" - what does this mean? Petr Vandrovec
2002-01-09 14:34 ` Maciej W. Rozycki
2002-01-07 16:58 Petr Vandrovec
2002-01-08 12:12 ` Maciej W. Rozycki
2002-01-08 12:30 ` Chris Wedgwood
2002-01-07 13:16 Petr Vandrovec
2002-01-07 13:33 ` Alan Cox
2002-01-07 13:42 ` Chris Wedgwood
2002-01-07 14:40 ` Martin Eriksson
2002-01-07 17:32 ` Steven Walter
2002-01-07 18:20 ` Rene Rebe
2002-01-07 12:29 Petr Vandrovec
2002-01-07 13:08 ` Chris Wedgwood
2002-01-03 19:55 Steve Snyder
2002-01-03 20:10 ` listmail
2002-01-03 21:47 ` Ryan Cumming
2002-01-03 22:38 ` Alan Cox
2002-01-03 23:21 ` Pozsar Balazs
2002-01-07 10:17 ` Chris Wedgwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E542D8F46A1@vcnet.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@ds2.pg.gda.pl \
--cc=swsnyder@home.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox