On Mon, 14 Feb 2000, Alan Cox wrote:
> > If a hardware device asserts its interrupt line long enough for the
> > interrupt controller to see it, it is latched. That is how the interrupt
> > controller 'remembers' that an interrupt occurred. It doesn't care
> > if the interrupt line is deasserted before the CPU is notified. In fact,
> > because of the priority of higher-priority pending interrupts the
> > CPU probably won't know about it right away. That's why any pending
> > hardware interrupts are latched.
> >
> > I do know about this chipset.
>
> Well the man at Intel who documented it, the guys at IBM who designed the PC
> and the folks at Novell whose drivers include hooks for it, and a friend who
> designs boards all disagree with you.
>
> Somehow I trust them. Especially as I've seen it happening.
>
> Alan
I read the Intel rag web-site when it was pointed out to me by
another.
This seems strangely like the response I got from a so-called
application engineer when Intel went to the CMOS process version in
the mid '80s. I remember the typos.
Quote from Web-site:
" In some applications, problem with a spurious IRQ7 might exist.
For example, a spurios IRQ7 will occur under the follwing condition:
While the device is performing extensive I/O operations (IN AL, DX;
OUT DX, AL), an external signal triggers IRQ3. Spurious enabling of
IRQ7 and occassional losing of IRQ3 will be the outcome of this condition.
Design Consideration:
A spurious IRQ7 occurs, in the 8259, if any interrupt request duration is too
short or hasn't met the setup time required by the 8259A.
This is a standard 8259 behavior under specific conditions. IRQ7 is triggered
when IRQ7 is enabled and is requested
OR
when an interrupt request clears (by itself) before the CPU services the request.
A software solution would be to write an IRQ7 handler that checks the various
possible requesters and to handle any "missed" interrupts from any of those
requesters."
Of course this response has no basis in fact. The problem was traced
to the printer-port enable being a tri-state enable. The TTL (actually
PMOS) version of the controller didn't care that its input was left
floating. However, when substituting the CMOS version, we were left
with a floating input because there was no pull-up resistor on this
input. The fix was a resistor.
This was typical "snow them with technical jargon", then claim that
it's normal.
Now, it is commonplace to fix hardware with software. And there may
still be some very early '386 boards out there that we should support.
So I am not claiming that anything should be changed in the existing
software.
What I am claiming is that what you have properly learned and quoted,
is not, in fact, what was happening. Internally, there is nothing
special about interrupt level 7, IRQ7. Externally, it was connected
to a tri-state enable with a missing resistor so electrostatic
fields could move the line around and generate spurious interrupts.
Cheers,
Dick Johnson
Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:28 EST