Messages in this thread | | | Date | Mon, 14 Feb 2000 16:40:32 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: Port of 3c575_cb to 2.3.43pre8 |
| |
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/
| |