[lkml]   [2000]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    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
    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

    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

    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.

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.023 / U:10.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site