archive mirror
 help / color / mirror / Atom feed
From: "Kathy Frazier" <>
To: <>, <>
Subject: RE: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo
Date: Tue, 15 Jul 2003 11:52:54 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <Pine.LNX.4.53.0307141833190.4354@chaos>

>There is a possibility that you are trying to use a shared interrupt,
>but the IRQ is set up for edge. You can only share level interrupts.

I checked it out.  The Edge/Level Triggered Register (ELCR) of Intel's 82801
ICH4 PIC register shows that our IRQ is setup for edge.

>Also, in the keyboard ISR, there is code that will spin <forever>
>if the bit that was supposed to be true when the interrupt occurred,
>remains false. This means that, if the timing was screwed up on some
>feature-board bus interface state-machine, it could corrupt what
>other devices see on the bus. The result could be a "hang forever"

Hmmm, this is good information.  Exactly what bit are you referring too?  Is
this in /drivers/char/keyboard.c?  I took a quick look through, but didn't
see anything.  With the symptoms I am experiencing, I thought it might be
due to a piece of software spinning in a loop after it issued a cli.
However, I should at least see any pending interrupts in the IRR of the
8259!  The cli would just prevent the CPU from being notified of the pending

>The 8259 is such an old device that all its bugs are known and
>work-arounds have been in-place for ages. It is unlikely that your
>problem has anything to do with either in 8259 or existing kernel
>code. My bet's on with a level/edge problem or bus corruption due
>to bus-contention (timing issues).

I tend to agree with you - the 8259 has been around forever.  The snooping
I've done with my debug indicates that that the IRQ never gets through from
the hardware.  The CPU is still running software and apparantly other things
are getting scheduled.  But no other IRQs are getting through!  Something is
corrupted on the bus.  This posting was a final sanity check to insure I
wasn't totally out in left field with respect to the driver software.  I
know there are issues of race conditions when using the sleep_on/wake_up
mechanisms.  However, from what I've read, wait_event_interruptible() method
will avoid this . . .  Any thoughts on that?

Thanks for your input!


       reply	other threads:[~2003-07-15 15:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.53.0307141833190.4354@chaos>
2003-07-15 16:52 ` Kathy Frazier [this message]
     [not found] <>
2003-07-15 16:14 ` Kathy Frazier
2003-07-15 15:31   ` Richard B. Johnson
2003-07-15 17:06   ` Brian Gerst
2003-07-15 17:43     ` Jamie Lokier
2003-07-15 17:59     ` Luciano Miguel Ferreira Rocha
2003-07-15 18:24       ` Brian Gerst
2003-07-15 18:44         ` Alan Cox
2003-07-15 19:44           ` Jamie Lokier
2003-07-20 21:04           ` Riley Williams
2003-07-20 22:25             ` Jeremy Fitzhardinge
2003-07-14 21:35 Kathy Frazier

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='RE: Interrupt doesn'\''t make it to the 8259 on a ASUS P4PE mobo' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).