Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

RE: Device Interrupt priority - Reviewing Jose Flores

Jake_OshinsJake_Oshins Member Posts: 1,058
You asked for an evaluation....

I wish that Jose had talked to me, or somebody who actually works on the
code, before he wrote that. He missed some pretty fundamental points.

First let me say, as I have said in the past in this forum, calling
IoConnectInterrupt with an IRQL other than that which you were handed by
the PnP manager will only result in a machine that either fails to
connect your interrupt or a machine that will eventually deadlock
itself.

Second, let me say that you can only run HALMPS.dll on machines with an
MPS BIOS. And, if your machine has one of those, HALMPS.dll will be
installed by default. So replacing your HAL will probably result in a
machine that doesn't boot. (Furthermore, in Windows 2000, Windows XP
and Windows .Net Server, we'll probably install halmacpi.dll, which is
similar to halmps.dll, except that it works with an ACPI BIOS.)

As for the article, Jose's most egregious misunderstanding is that he
thinks that IRQL is meaningless on uniprocessor systems. It's not.
It's exactly the same thing that it is on multi-processor systems, a way
to assign a priority level to a processor.

What Jose got tripped up on is something that we call "Lazy IRQL." This
is a way to avoid writing to the control registers on the 8259 PIC
Interrupt Controller, which is usually in a part of the machine that
takes a long time to send I/O cycles to.

In a "Strict IRQL" system, when we take an interrupt, we raise IRQL to
the appropriate level (which involves writing to the interrupt
controller) before we issue a "sti" instruction, which re-enables
interrupts at the processor. Thus we are guaranteed that we will never
execute any code that is of a lower priority until we finish running the
appropriate ISR and lower IRQL.

In a Lazy IRQL HAL, we take advantage of the fact that most interrupts
don't overlap with other interrupts. Instead of writing to the
interrupt controller, we merely note that a change of IRQL should have
occurred. Then we call the ISR for the device, even though
lower-priority interrupts aren't masked. If one of those interrupts
happens before we finish the first device's ISR, then the interrupt
pre-amble code will note that we have just taken an interrupt that
should have been masked, actually mask the interrupt controller and
dismiss the errant interrupt without ever calling that second device's
ISR. Then, when the first device's ISR completes, we go back and run
the second device's ISR at the correct lower IRQL.

This system maintains all the semantics of the Strict IRQL system, but
does many fewer writes to the interrupt controller. At present, we only
do Lazy IRQL in hal.dll, which is the default single-processor non-ACPI
HAL. All the other HALs use Strict IRQL.

Please ignore most of Jose's conclusions, as they are based on these
misunderstandings.

Jake Oshins
NT Kernel Team
Microsoft


This posting is provided "AS IS" with no warranties, and confers no
rights.


-----Original Message-----
Subject: Device Interrupt priority & Extreme ISR Priority : new thread
From: "Christiaan Ghijselinck" <xxxxx@Compaqnet.be>
Date: Sun, 8 Dec 2002 09:33:59 -0500
X-Message-Number: 2



Could someone please evaluate the article of Jose Flores at

http://www.joseflores.com/docs/ExploringIrql.html

Assuming that the information is correct, may I then conclude that on a
multiprocessor system, an ISR connected through IoConnectInterrupt ( ...
,
POWER_LEVEL , ...) ; will :

- never be suspended by another IRQ
- always suspend ( preempt ) running lower priority ISR's

If I install the MPS version on a monoprocessor system, does the
installation revert to the mono processor HAL.ddl or may I profit from
the
multiprocessor version ( halmps.dll ).
«1

Comments

  • Thanks for the reply Jake,

    You wrote :

    > In a "Strict IRQL" system, when we take an interrupt, we raise IRQL to
    > the appropriate level (which involves writing to the interrupt
    > controller) before we issue a "sti" instruction, which re-enables
    > interrupts at the processor. Thus we are guaranteed that we will never
    > execute any code that is of a lower priority until we finish running the
    > appropriate ISR and lower IRQL.

    As for my understanding, may I conclude that higher level IRQ's DO
    interrupt the running ISR and will run to the end, after which the current
    interrupted ISR will continue ? Does this mean that the 8259 PIC's IRQ
    priority handling is programmed/reprogrammed on the fly by the OS to match
    the IRQL of the ISR's in the system ?
  • JoseJose Member Posts: 5
    Couple of things:

    [1] Nowhere in that article does it recommend calling IoConnectInterrupt()
    w/ a made up IRQL. Nor does it advocate yanking & replacing hals out from
    underneath the installation.

    The point of the article was (1) to give a peek at what goes on under the
    hood of IRQL manipulation and (2) to illustrate that raising IRQL does not
    always deny interrupts associated with lower priority IRQLs to fire. I
    don't think it’s a stretch do assume that most people take for granted
    that if they raise to SYNCH that practically no interrupts will fire.
    This is clearly not the case on UP systems. On such a hal, ALL interrupts
    will fire (initially), but the subsequent execution of NT's interrupt stub
    will prevent the clients ISR from running until IRQL is lowered to an
    acceptable level.

    No doubt that this subtly hardly matters to anyone, except maybe a handful
    of people who are either doing seriously funky (most likely non-production
    quality) work, or are just morbidly curious.

    [2] Nowhere in the article does it state that IRQL is meaningless on
    uniprocessor systems. In fact it does describe what you call "Lazy IRQL".
    From the article (edited for brevity):

    "why do we use it (IRQL) at all on uniprocessor systems?...the NT kernel
    performs explicit checks of the IRQL value at key points in it's
    execution..."

    "...If the vector's IRQL is less than or equal to the currently executing
    code's IRQL, then everything is undone, the processor's context is
    restored, and control is returned to the interrupted code. … In cases
    where the interrupt is dismissed, variables inside the PCR are used to
    mark the particular interrupt vectors as having had an interrupt fire that
    was not completely serviced. …. dismissing the interrupt is usually
    followed with actually masking the particular interrupt in hardware to
    prevent further execution of the ISR until the pending interrupt can be
    serviced completely."

    "Each time IRQL is dropped, a check is performed to see if there are any
    'pending' interrupts. If so, then a software interrupt is issued (after
    the IRQL is dropped) corresponding to the vector to which the hardware
    interrupt is mapped. For example, if the clock interrupt is mapped to
    vector 0x30 with an IRQL of 0x1C, then if the current IRQL is dropping
    from 0x1F to 0x2, then … The ISR executes as normal, and the interrupt is
    now completely serviced. The pending bit is cleared, and the interrupt is
    unmasked."

    Granted the article wasn't privy to more colorful insider descriptions
    such as Lazy and Strict IRQL, but the end description is essentially the
    same. Likewise, what the article calls an interrupt stub, you call a
    preamble. Tomato, tomato.

    Maybe the unfinished article was poorly written to have anyone to conclude
    that the article suggests the above. Or maybe it just wasn't read in the
    right frame of mind. Either way, I'd be interested in hearing criticisms
    privately from someone with your inside knowledge.



    "Jake Oshins" wrote in message news:xxxxx@ntdev...

    You asked for an evaluation....

    I wish that Jose had talked to me, or somebody who actually works on the
    code, before he wrote that. He missed some pretty fundamental points.

    First let me say, as I have said in the past in this forum, calling
    IoConnectInterrupt with an IRQL other than that which you were handed by
    the PnP manager will only result in a machine that either fails to
    connect your interrupt or a machine that will eventually deadlock
    itself.

    Second, let me say that you can only run HALMPS.dll on machines with an
    MPS BIOS. And, if your machine has one of those, HALMPS.dll will be
    installed by default. So replacing your HAL will probably result in a
    machine that doesn't boot. (Furthermore, in Windows 2000, Windows XP
    and Windows .Net Server, we'll probably install halmacpi.dll, which is
    similar to halmps.dll, except that it works with an ACPI BIOS.)

    As for the article, Jose's most egregious misunderstanding is that he
    thinks that IRQL is meaningless on uniprocessor systems. It's not.
    It's exactly the same thing that it is on multi-processor systems, a way
    to assign a priority level to a processor.

    What Jose got tripped up on is something that we call "Lazy IRQL." This
    is a way to avoid writing to the control registers on the 8259 PIC
    Interrupt Controller, which is usually in a part of the machine that
    takes a long time to send I/O cycles to.

    In a "Strict IRQL" system, when we take an interrupt, we raise IRQL to
    the appropriate level (which involves writing to the interrupt
    controller) before we issue a "sti" instruction, which re-enables
    interrupts at the processor. Thus we are guaranteed that we will never
    execute any code that is of a lower priority until we finish running the
    appropriate ISR and lower IRQL.

    In a Lazy IRQL HAL, we take advantage of the fact that most interrupts
    don't overlap with other interrupts. Instead of writing to the
    interrupt controller, we merely note that a change of IRQL should have
    occurred. Then we call the ISR for the device, even though
    lower-priority interrupts aren't masked. If one of those interrupts
    happens before we finish the first device's ISR, then the interrupt
    pre-amble code will note that we have just taken an interrupt that
    should have been masked, actually mask the interrupt controller and
    dismiss the errant interrupt without ever calling that second device's
    ISR. Then, when the first device's ISR completes, we go back and run
    the second device's ISR at the correct lower IRQL.

    This system maintains all the semantics of the Strict IRQL system, but
    does many fewer writes to the interrupt controller. At present, we only
    do Lazy IRQL in hal.dll, which is the default single-processor non-ACPI
    HAL. All the other HALs use Strict IRQL.

    Please ignore most of Jose's conclusions, as they are based on these
    misunderstandings.

    Jake Oshins
    NT Kernel Team
    Microsoft


    This posting is provided "AS IS" with no warranties, and confers no
    rights.


    -----Original Message-----
    Subject: Device Interrupt priority & Extreme ISR Priority : new thread
    From: "Christiaan Ghijselinck"
    Date: Sun, 8 Dec 2002 09:33:59 -0500
    X-Message-Number: 2



    Could someone please evaluate the article of Jose Flores at

    http://www.joseflores.com/docs/ExploringIrql.html

    Assuming that the information is correct, may I then conclude that on a
    multiprocessor system, an ISR connected through IoConnectInterrupt ( ...
    ,
    POWER_LEVEL , ...) ; will :

    - never be suspended by another IRQ
    - always suspend ( preempt ) running lower priority ISR's

    If I install the MPS version on a monoprocessor system, does the
    installation revert to the mono processor HAL.ddl or may I profit from
    the
    multiprocessor version ( halmps.dll ).
  • JoseJose Member Posts: 5
    Yes interrupts associated with a higher IRQL than the current IRQL will
    run end to end. At completion of the high IRQL isr, control is resumed by
    the lower IRQL. On all hals, everywhere.

    However, on at least 1 common hal, an interrupt associated with an IRQL
    *lower* than the current IRQL will (1) preempt and run for a little bit
    (long enough for the OS stub to gain control), (2) be masked on the
    controller (to prevent unwarrented preemption from happening again), (3)
    be marked "pending" in memory, and (4) return control to the higher IRQL
    (current) code block. Following the completion of the higher IRQL ISR,
    control is resumed by the lower IRQL ISR, the interrupt "unpended", and be
    unmasked in hardware & life goes on as normal.

    In all hals, in all cases, the meat of a lower IRQL ISR is never run
    before a higher IRQL ISR. Where meat is defined as the device driver's
    ISR passed to IoconnectInterrupt.

    "Christiaan Ghijselinck" wrote in message news:xxxxx@ntdev...
    >
    >
    > Thanks for the reply Jake,
    >
    > You wrote :
    >
    > As for my understanding, may I conclude that higher level IRQ's DO
    > interrupt the running ISR and will run to the end, after which the current
    > interrupted ISR will continue ? Does this mean that the 8259 PIC's IRQ
    > priority handling is programmed/reprogrammed on the fly by the OS to match
    > the IRQL of the ISR's in the system ?
    >
    >
    >
    >
    >
  • Thanks Jose for this clear and brief exposure.

    Could someone please also describe how the ISR's are managed from devices
    that share the same IRQ? Does the PNP manager ( or the obsolete
    "HalGetInterruptVector" )
    provide identical IRQL for ISR's that share the same IRQ? If not, I assume
    that while
    dispatching the queued ISR's that share the same interrupt, another ISR
    coming
    from a different IRQ can slip in between the shared one's and will become
    running. Is this correct ?

    Somewhere I have read that all DPC's for a particular processor within the
    system are FIFO queued
    to run at the same IRQL. This would mean that when a high priority ISR
    queues a DPC, this DPC will
    only come to run when all other DPC's, even those queued by less priority
    ISR's, have finished.
    Is this correct ?


    Jose also wrote :

    >> No doubt that this subtly hardly matters to anyone, except maybe a
    handful
    >> of people who are either doing seriously funky (most likely
    non-production
    >> quality) work, or are just morbidly curious


    Many people experience the MS OS's as a beautiful battleships, full loaded
    with
    sophisticated technology. But just one piece of hardware that spins up to
    fire interrupts every 5 us ( which is a tremendous timeperiod for a
    gigahertz processor ) paralyses these ships.

    It's commonly stated that Windows OS's should not be used for real time
    processing, but which popular operating system can deliver the functionality
    today
    of MS-Windows AND being a real time OS ? Replacing the Windows OS kernel
    with
    third party real time extensions seems to be to risky and even to expensive.

    This all results in implementing tricks to squeeze the last drop out of it,
    to let it work with conceptionally cripple ( cheap ) embedded hardware.
    Assume that you use a PC whose primary goal is to serve as a platform
    for a PCI card that fires an IRQ every 30 us, and that MUST be treated under
    all
    circumstances AND whose data becomes available 20 us after it has fired its
    IRQ ?
    MS has still a lot of work to do, even because multiprocessor technology IS
    available and even running since the end of the 80's on particular systems
    with a MTBF of ONE per YEAR !!!!
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I'm not that familiar with the ins and outs of Windows, but the 386
    architecture says that a Trap Gate will allow interrupts to come into the
    processor, whatever the IRQL - of course as long as it's not masked away at
    the 8259 or the APIC. However, a quick look at the IDT with SoftICE shows me
    that except for ints 8 and 12h, all others have Interrupt Gates in their IDT
    entries, meaning that NO interrupt will interlope into the interrupted
    processor, higher or lower IRQL, until, as Jake pointed out, the software
    issues an STI. This leaves a small window within which an interrupt could
    theoretically be missed, but I imagine that it's such a small bracket that
    it seldom if ever happens.


    Alberto.


    -----Original Message-----
    From: Christiaan Ghijselinck [mailto:xxxxx@CompaqNet.be]
    Sent: Tuesday, December 10, 2002 11:17 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores




    Thanks Jose for this clear and brief exposure.

    Could someone please also describe how the ISR's are managed from devices
    that share the same IRQ? Does the PNP manager ( or the obsolete
    "HalGetInterruptVector" )
    provide identical IRQL for ISR's that share the same IRQ? If not, I assume
    that while
    dispatching the queued ISR's that share the same interrupt, another ISR
    coming
    from a different IRQ can slip in between the shared one's and will become
    running. Is this correct ?

    Somewhere I have read that all DPC's for a particular processor within the
    system are FIFO queued
    to run at the same IRQL. This would mean that when a high priority ISR
    queues a DPC, this DPC will
    only come to run when all other DPC's, even those queued by less priority
    ISR's, have finished.
    Is this correct ?


    Jose also wrote :

    >> No doubt that this subtly hardly matters to anyone, except maybe a
    handful
    >> of people who are either doing seriously funky (most likely
    non-production
    >> quality) work, or are just morbidly curious


    Many people experience the MS OS's as a beautiful battleships, full loaded
    with
    sophisticated technology. But just one piece of hardware that spins up to
    fire interrupts every 5 us ( which is a tremendous timeperiod for a
    gigahertz processor ) paralyses these ships.

    It's commonly stated that Windows OS's should not be used for real time
    processing, but which popular operating system can deliver the functionality
    today
    of MS-Windows AND being a real time OS ? Replacing the Windows OS kernel
    with
    third party real time extensions seems to be to risky and even to expensive.

    This all results in implementing tricks to squeeze the last drop out of it,
    to let it work with conceptionally cripple ( cheap ) embedded hardware.
    Assume that you use a PC whose primary goal is to serve as a platform
    for a PCI card that fires an IRQ every 30 us, and that MUST be treated under
    all
    circumstances AND whose data becomes available 20 us after it has fired its
    IRQ ?
    MS has still a lot of work to do, even because multiprocessor technology IS
    available and even running since the end of the 80's on particular systems
    with a MTBF of ONE per YEAR !!!!





    ---
    You are currently subscribed to ntdev as: xxxxx@compuware.com
    To unsubscribe send a blank email to %%email.unsub%%



    The contents of this e-mail are intended for the named addressee only. It
    contains information that may be confidential. Unless you are the named
    addressee or an authorized designee, you may not copy or use it, or disclose
    it to anyone else. If you received it in error please notify us immediately
    and then destroy it.
  • Hi Alberto,


    ----- Original Message -----
    From: "Moreira, Alberto" <xxxxx@compuware.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Tuesday, December 10, 2002 5:31 PM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > I'm not that familiar with the ins and outs of Windows, but the 386
    > architecture says that a Trap Gate will allow interrupts to come into the
    > processor, whatever the IRQL - of course as long as it's not masked away
    at
    > the 8259 or the APIC. However, a quick look at the IDT with SoftICE shows
    me
    > that except for ints 8 and 12h, all others have Interrupt Gates in their
    IDT
    > entries, meaning that NO interrupt will interlope into the interrupted
    > processor, higher or lower IRQL, until, as Jake pointed out, the software
    > issues an STI. This leaves a small window within which an interrupt could
    > theoretically be missed, but I imagine that it's such a small bracket that
    > it seldom if ever happens.
    >
    >
    > Alberto.
    >
    >

    It should be garantueed that the processor gets interrupted for every IRQ
    that
    occurs. What else should we do with a PC ? Just use it as word processor or
    to play games?
    As soon as the PIC/APIC is serviced, it allows other ( even the same )
    interrupts to occur. Now, the CPU holds its "int" call because of the
    interrupt flag
    cleared. Another ( third ) IRQ that arrives before the STI instruction is
    executed,
    may potentionlly get lost I think, although Intel-Processor + PIC/APIC
    architecture
    is not conceived to manage these situations ..... Nevertheless, be sure this
    situation happens !!!! I have also the "feeling" that the "Lazy method" is
    more
    robust.


    Christiaan
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    Yes, both are true. But, for charts, let me point out that the built in
    priority scheme on the 8259 PIC doesn't have anything to do with IRQL.

    This posting is provided "AS IS" with no warranties, and confers no
    rights.

    -----Original Message-----
    Subject: RE: Device Interrupt priority - Reviewing Jose Flores
    From: "Christiaan Ghijselinck" <xxxxx@Compaqnet.be>
    Date: Mon, 9 Dec 2002 18:27:00 -0500
    X-Message-Number: 35


    Thanks for the reply Jake,

    You wrote :

    > In a "Strict IRQL" system, when we take an interrupt, we raise IRQL to
    > the appropriate level (which involves writing to the interrupt
    > controller) before we issue a "sti" instruction, which re-enables
    > interrupts at the processor. Thus we are guaranteed that we will
    never
    > execute any code that is of a lower priority until we finish running
    the
    > appropriate ISR and lower IRQL.

    As for my understanding, may I conclude that higher level IRQ's DO
    interrupt the running ISR and will run to the end, after which the
    current
    interrupted ISR will continue ? Does this mean that the 8259 PIC's IRQ
    priority handling is programmed/reprogrammed on the fly by the OS to
    match
    the IRQL of the ISR's in the system ?
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    You're right. I owe you an apology. A careful re-reading of your
    article shows that you did understand the code.

    I still think that the first half of your article makes little
    distinction between taking an interrupt and calling a device driver's
    ISR. I believe that the difference between the two is meaningless to
    most of the readers of this list. And it should be made very clear that
    NT will never pre-empt a high-IRQL ISR with a low-IRQL ISR. It will
    also never violate the locking semantics that are supported through the
    concept of IRQL.

    I don't think that the fact that an interrupt is actually enabled or
    disabled at the interrupt controller has much relevence in this context.
    I don't mean to say that you shouldn't be interested in how things are
    implemented. I just mean that you should be careful how you present
    this, since I believe it clouded at least one reader's overall
    understanding.

    - Jake

    -----Original Message-----
    Subject: RE: Device Interrupt priority - Reviewing Jose Flores
    From: "Jose Flores" <xxxxx@joseflores.com>
    Date: Mon, 9 Dec 2002 19:05:47 -0500
    X-Message-Number: 36

    Couple of things:

    [1] Nowhere in that article does it recommend calling
    IoConnectInterrupt()
    w/ a made up IRQL. Nor does it advocate yanking & replacing hals out
    from
    underneath the installation.

    The point of the article was (1) to give a peek at what goes on under
    the
    hood of IRQL manipulation and (2) to illustrate that raising IRQL does
    not
    always deny interrupts associated with lower priority IRQLs to fire. I
    don't think it's a stretch do assume that most people take for granted
    that if they raise to SYNCH that practically no interrupts will fire.
    This is clearly not the case on UP systems. On such a hal, ALL
    interrupts
    will fire (initially), but the subsequent execution of NT's interrupt
    stub
    will prevent the clients ISR from running until IRQL is lowered to an
    acceptable level.

    No doubt that this subtly hardly matters to anyone, except maybe a
    handful
    of people who are either doing seriously funky (most likely
    non-production
    quality) work, or are just morbidly curious.

    [2] Nowhere in the article does it state that IRQL is meaningless on
    uniprocessor systems. In fact it does describe what you call "Lazy
    IRQL".
    From the article (edited for brevity):

    "why do we use it (IRQL) at all on uniprocessor systems?...the NT kernel
    performs explicit checks of the IRQL value at key points in it's
    execution..."

    "...If the vector's IRQL is less than or equal to the currently
    executing
    code's IRQL, then everything is undone, the processor's context is
    restored, and control is returned to the interrupted code. ... In cases
    where the interrupt is dismissed, variables inside the PCR are used to
    mark the particular interrupt vectors as having had an interrupt fire
    that
    was not completely serviced. .... dismissing the interrupt is usually
    followed with actually masking the particular interrupt in hardware to
    prevent further execution of the ISR until the pending interrupt can be
    serviced completely."

    "Each time IRQL is dropped, a check is performed to see if there are any
    'pending' interrupts. If so, then a software interrupt is issued (after
    the IRQL is dropped) corresponding to the vector to which the hardware
    interrupt is mapped. For example, if the clock interrupt is mapped to
    vector 0x30 with an IRQL of 0x1C, then if the current IRQL is dropping
    from 0x1F to 0x2, then ... The ISR executes as normal, and the
    interrupt is
    now completely serviced. The pending bit is cleared, and the interrupt
    is
    unmasked."

    Granted the article wasn't privy to more colorful insider descriptions
    such as Lazy and Strict IRQL, but the end description is essentially the
    same. Likewise, what the article calls an interrupt stub, you call a
    preamble. Tomato, tomato.

    Maybe the unfinished article was poorly written to have anyone to
    conclude
    that the article suggests the above. Or maybe it just wasn't read in
    the
    right frame of mind. Either way, I'd be interested in hearing
    criticisms
    privately from someone with your inside knowledge.



    "Jake Oshins" <xxxxx@windows.microsoft.com> wrote in message
    news:xxxxx@ntdev...

    You asked for an evaluation....

    I wish that Jose had talked to me, or somebody who actually works on the
    code, before he wrote that. He missed some pretty fundamental points.

    First let me say, as I have said in the past in this forum, calling
    IoConnectInterrupt with an IRQL other than that which you were handed by
    the PnP manager will only result in a machine that either fails to
    connect your interrupt or a machine that will eventually deadlock
    itself.

    Second, let me say that you can only run HALMPS.dll on machines with an
    MPS BIOS. And, if your machine has one of those, HALMPS.dll will be
    installed by default. So replacing your HAL will probably result in a
    machine that doesn't boot. (Furthermore, in Windows 2000, Windows XP
    and Windows .Net Server, we'll probably install halmacpi.dll, which is
    similar to halmps.dll, except that it works with an ACPI BIOS.)

    As for the article, Jose's most egregious misunderstanding is that he
    thinks that IRQL is meaningless on uniprocessor systems. It's not.
    It's exactly the same thing that it is on multi-processor systems, a way
    to assign a priority level to a processor.

    What Jose got tripped up on is something that we call "Lazy IRQL." This
    is a way to avoid writing to the control registers on the 8259 PIC
    Interrupt Controller, which is usually in a part of the machine that
    takes a long time to send I/O cycles to.

    In a "Strict IRQL" system, when we take an interrupt, we raise IRQL to
    the appropriate level (which involves writing to the interrupt
    controller) before we issue a "sti" instruction, which re-enables
    interrupts at the processor. Thus we are guaranteed that we will never
    execute any code that is of a lower priority until we finish running the
    appropriate ISR and lower IRQL.

    In a Lazy IRQL HAL, we take advantage of the fact that most interrupts
    don't overlap with other interrupts. Instead of writing to the
    interrupt controller, we merely note that a change of IRQL should have
    occurred. Then we call the ISR for the device, even though
    lower-priority interrupts aren't masked. If one of those interrupts
    happens before we finish the first device's ISR, then the interrupt
    pre-amble code will note that we have just taken an interrupt that
    should have been masked, actually mask the interrupt controller and
    dismiss the errant interrupt without ever calling that second device's
    ISR. Then, when the first device's ISR completes, we go back and run
    the second device's ISR at the correct lower IRQL.

    This system maintains all the semantics of the Strict IRQL system, but
    does many fewer writes to the interrupt controller. At present, we only
    do Lazy IRQL in hal.dll, which is the default single-processor non-ACPI
    HAL. All the other HALs use Strict IRQL.

    Please ignore most of Jose's conclusions, as they are based on these
    misunderstandings.

    Jake Oshins
    NT Kernel Team
    Microsoft


    This posting is provided "AS IS" with no warranties, and confers no
    rights.


    -----Original Message-----
    Subject: Device Interrupt priority & Extreme ISR Priority : new thread
    From: "Christiaan Ghijselinck" <xxxxx@Compaqnet.be>
    Date: Sun, 8 Dec 2002 09:33:59 -0500
    X-Message-Number: 2



    Could someone please evaluate the article of Jose Flores at

    http://www.joseflores.com/docs/ExploringIrql.html

    Assuming that the information is correct, may I then conclude that on a
    multiprocessor system, an ISR connected through IoConnectInterrupt ( ...
    ,
    POWER_LEVEL , ...) ; will :

    - never be suspended by another IRQ
    - always suspend ( preempt ) running lower priority ISR's

    If I install the MPS version on a monoprocessor system, does the
    installation revert to the mono processor HAL.ddl or may I profit from
    the
    multiprocessor version ( halmps.dll ).




    ----------------------------------------------------------------------

    Subject: Re: Writng and Debuging Drivers in C++
    From: "David J. Craig" <xxxxx@yoshimuni.com>
    Date: Mon, 9 Dec 2002 19:02:25 -0500
    X-Message-Number: 37

    I think MSDN is required for someone in the development group to have
    available. You can get the DDKs for "free" if you have one. I have
    also
    found that keeping the old DDKs, SDKs, and operating systems to be
    necess=
    ary
    because most of the world isn't switching as quickly as Microsoft would
    like. There is the archive pack with some of the old stuff too. I have
    found that some documentation disappears if you don't have access to the
    older versions. Also there is one hardware "requirement" that OSR
    advise=
    s
    and that is a 8x SMP system. Some deadlocks and other SMP issues may
    not
    show up quickly on a single CPU or a dual processor. I remember
    releasin=
    g
    one driver that had the no-SMP flag set. We didn't have a SMP system to
    test and the risk to our partners was deemed too high. I have been at a
    company where only one or two of the systems had DVDs. Every other
    syste=
    m
    had CD-ROMs only. I prefer the paychecks get paid instead of having all
    =
    the
    toys I want, but I still want the toys.

    I think that using the checked builds of the HAL and Kernel is required
    t=
    o
    drivers stable. I don't think that you need the entire checked OS for
    drivers, but you may want it for some applications.

    ----- Original Message -----
    From: "Chris Dor=E9" <xxxxx@connecttech.com>
    Newsgroups: ntdev
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Monday, December 09, 2002 5:34 PM
    Subject: [ntdev] Re: Writng and Debuging Drivers in C++


    > >
    > > It is expensive and Microsoft has not done much itself to reduce
    cost=
    s.
    > > Windbg is "free", but you still have to download it. Just printing
    t=
    he
    > user
    > > guide will chew up most of a ream of paper. MSDN is absurdly
    expensi=
    ve
    > and
    > > appears designed to limit the ability to develop to those who have
    de=
    ep
    > > pockets. MSDN Universal costs more than the two computers you need
    t=
    o
    > write
    > > drivers. Add in the IFS Kits and you need $10,000 just to start in
    t=
    he
    > > first year. Remember when many shareware developers could write
    usef=
    ul
    > > utilities, TSRs, and drivers for MS-DOS with little or no expense
    exc=
    ept
    > the
    > > hardware. The costs seem to have shifted from hardware to software.
    =
    I
    > just
    > > read that Microsoft has said that its costs for their operating
    syste=
    ms
    is
    > > only $0.15 or $0.16 per dollar charged. Nice margins!
    > >
    >
    > You do not, by any means, need an MSDN subscription to develop device
    > drivers. If you have access to the internet then you're completely
    set.
    The
    > DDK is practically free (just pay for the shipping), and the entire
    MSD=
    N
    > library is available for free on Microsoft's website. The DDK comes
    wit=
    h a
    > compiler and everything you need to build a driver...in fact you don't
    > _really_ even need access to the internet (of course access to the
    extr=
    a
    > information is quite a help).
    >
    > Now there are some useful things lacking from not having a MSDN
    > subscription, like checked OS builds, but I have actually never used
    th=
    em
    > despite having access to them (I've only used a couple checked system
    > drivers. ie. USB).
    >
    > You are correct on the IFS kit, it does cost a fair amount. I wish I
    co=
    uld
    > get my hands on it for free...oh well.
    >
    > In summary, if you're just starting out, don't feel as though you need
    large
    > capital in order to start developing for windows.
    >
    > Chris
    >
    > P.S. This doesn't just apply to device drivers. You can develop
    applications
    > for free using MS tools as well (you don't need Visual
    Studio...althoug=
    h
    IMO
    > it is a great product and I use it).
    >
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
    > To unsubscribe send a blank email to %%email.unsub%%
    >




    ----------------------------------------------------------------------

    Subject: Registry for device driver? And Walter Oney?
    From: Michael Wade <xxxxx@pacbell.net>
    Date: Mon, 09 Dec 2002 17:17:40 -0800
    X-Message-Number: 38

    I apologize for asking such a basic question, but I really want to make
    sure before I play around with the registry.

    I thought that once upon a time the path to the registry key for the
    driver
    was passed into the driver. However, from reading around the net and
    the
    WDM DDK, I am confused. Where should I look to unconfuse myself? Is it

    true that I should not use that path? I am resurrecting an NT 4 driver
    and
    hoping that getting it to work under Win2K won't be impossible. We have

    several parameters that need to be accessed by the driver and I would
    think
    that the registry would be the place for them. My device driver coding
    is
    really from NT4, but I know that we are going to go to WinXP so I would
    like to do this "right" if possible. I was going to put the parameters
    in
    HKLM\System\CurrentControlSet\Services\MyDriver\Parameters\(keys/values
    here). Is that not correct anymore (if it ever was)? If not, where is
    the
    normal place to put device driver parameters?

    Also, where is the normal/standard/whatever place to put device driver
    data
    that is too large to fit in the registry? We load hex files into our
    card
    and I don't know if \Winnt\System32\drivers is the correct place or
    not. If not, then where?

    If anyone has any advice or knowledge I sure would appreciate you
    passing
    it on.

    Also, I have Walter Oney's book "Programming the Microsoft Windows
    Driver
    Model" from 1999. Is there a later release or another book that I
    should
    read? This one is fine, but I know that I am going to have to move this

    driver to XP eventually and I don't know what has changed. And I think
    that Walter Oney's book was published in 1999, before XP. Or are the
    changes for XP so small that there really is no need?

    Thanks very much,
    Michael




    ----------------------------------------------------------------------

    Subject: Property Page DLL in registry won't change. When does one
    change the
    .inf class GUID?
    From: Michael Wade <xxxxx@pacbell.net>
    Date: Mon, 09 Dec 2002 17:21:04 -0800
    X-Message-Number: 39

    I see these heavy duty threads going on about interrupt priority and
    filters and I feel like a little kid crying "Let me play! Let me
    play! You never let me play!"

    Be that as it may. I am trying to get a property page up and going and
    I
    thought that I did. But I can't seem to get rid of my test dll for the
    property page provider. I have a line in my .inf file that reads:
    HKR,,EnumPropPages32,,"DevPropSheet.dll,DevicePropPageProvider"
    It used to read:
    HKR,,EnumPropPages32,,"TestDevPropSheet.dll,DevicePropPageProvider"

    However, when I install it, my old "TestDevPropSheet.dll" seems to
    always
    get loaded. I have uninstalled the driver, deleted the corresponding
    oem*.inf files and everything else I could think of. But it still wants
    to
    grab that test dll. I then looked in the registry for it, and it's in
    there under HKLM/SYSTEM/CurrentControlSet/(CLASSGUID). But I don't know

    why it's not getting overwritten when I load the device driver again
    using
    the .inf file with the DevPropSheet.dll (without the Test). The GUID
    corresponds to that in the [Version] section key = ClassGUID. Which
    brings
    up another question that is probably at the root. When should one
    change
    the Class GUID? And where does one find information about that GUID? I

    tried the Win2k DDK, but if it's there then I'm not finding it.

    Thanks for any help,
    Michael




    ----------------------------------------------------------------------

    Subject: RE: Property Page DLL in registry won't change. When does one
    change the .inf class GUID?
    From: "Doron Holan" <xxxxx@windows.microsoft.com>
    Date: Mon, 9 Dec 2002 17:29:38 -0800
    X-Message-Number: 40

    What is happening is that the class registry info is written only the
    first time a device of that class is installed (ie the first time the OS
    sees that new device class). Are you having these problems on a fresh
    installed system where your test DLL has never been installed before?

    Also, are you sure you want to have the property page for the entire
    class? You can also install a property page on each individual device
    (it ends up being in
    HKLM/SYSTEM/CurrentControlSet/(CLASSGUID)/<instance>). The per instance
    value is written everytime a device is installed (no matter the device
    class).

    D

    This posting is provided "AS IS" with no warranties, and confers no
    rights=20

    -----Original Message-----
    From: Michael Wade [mailto:xxxxx@pacbell.net]=20
    Sent: Monday, December 09, 2002 5:21 PM
    To: NT Developers Interest List
    Subject: [ntdev] Property Page DLL in registry won't change. When does
    one change the .inf class GUID?

    I see these heavy duty threads going on about interrupt priority and=20
    filters and I feel like a little kid crying "Let me play! Let me=20
    play! You never let me play!"

    Be that as it may. I am trying to get a property page up and going and
    I=20
    thought that I did. But I can't seem to get rid of my test dll for
    the=20
    property page provider. I have a line in my .inf file that reads:
    HKR,,EnumPropPages32,,"DevPropSheet.dll,DevicePropPageProvider"
    It used to read:
    HKR,,EnumPropPages32,,"TestDevPropSheet.dll,DevicePropPageProvider"

    However, when I install it, my old "TestDevPropSheet.dll" seems to
    always=20
    get loaded. I have uninstalled the driver, deleted the corresponding=20
    oem*.inf files and everything else I could think of. But it still wants
    to=20
    grab that test dll. I then looked in the registry for it, and it's
    in=20
    there under HKLM/SYSTEM/CurrentControlSet/(CLASSGUID). But I don't know

    why it's not getting overwritten when I load the device driver again
    using=20
    the .inf file with the DevPropSheet.dll (without the Test). The GUID=20
    corresponds to that in the [Version] section key =3D ClassGUID. Which
    brings=20
    up another question that is probably at the root. When should one
    change=20
    the Class GUID? And where does one find information about that GUID? I

    tried the Win2k DDK, but if it's there then I'm not finding it.

    Thanks for any help,
    Michael




    ---
    You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
    To unsubscribe send a blank email to %%email.unsub%%


    ----------------------------------------------------------------------

    Subject: RE: Device Interrupt priority - Reviewing Jose Flores
    From: "Jose Flores" <xxxxx@joseflores.com>
    Date: Mon, 9 Dec 2002 20:48:21 -0500
    X-Message-Number: 41

    Yes interrupts associated with a higher IRQL than the current IRQL will
    run end to end. At completion of the high IRQL isr, control is resumed
    by
    the lower IRQL. On all hals, everywhere.

    However, on at least 1 common hal, an interrupt associated with an IRQL
    *lower* than the current IRQL will (1) preempt and run for a little bit
    (long enough for the OS stub to gain control), (2) be masked on the
    controller (to prevent unwarrented preemption from happening again), (3)
    be marked "pending" in memory, and (4) return control to the higher IRQL
    (current) code block. Following the completion of the higher IRQL ISR,
    control is resumed by the lower IRQL ISR, the interrupt "unpended", and
    be
    unmasked in hardware & life goes on as normal.

    In all hals, in all cases, the meat of a lower IRQL ISR is never run
    before a higher IRQL ISR. Where meat is defined as the device driver's
    ISR passed to IoconnectInterrupt.

    "Christiaan Ghijselinck" <xxxxx@Compaqnet.be> wrote in message
    news:xxxxx@ntdev...
    >
    >
    > Thanks for the reply Jake,
    >
    > You wrote :
    >
    > As for my understanding, may I conclude that higher level IRQ's DO
    > interrupt the running ISR and will run to the end, after which the
    current
    > interrupted ISR will continue ? Does this mean that the 8259 PIC's IRQ
    > priority handling is programmed/reprogrammed on the fly by the OS to
    match
    > the IRQL of the ISR's in the system ?
    >
    >
    >
    >
    >

    ----------------------------------------------------------------------

    Subject: Re: Registry for device driver? And Walter Oney?
    From: Phong Ho <xxxxx@yahoo.com>
    Date: Mon, 9 Dec 2002 18:16:04 -0800 (PST)
    X-Message-Number: 42

    The second release of the Oney's should be out on
    December 9, 2002.
    http://www.microsoft.com/mspress/books/6262.asp
    I am wondering if the second release will cover
    NDIS. Could the author let us know?

    Thanks






    --- Michael Wade <xxxxx@pacbell.net> wrote:
    > I apologize for asking such a basic question, but I
    > really want to make
    > sure before I play around with the registry.
    >
    > I thought that once upon a time the path to the
    > registry key for the driver
    > was passed into the driver. However, from reading
    > around the net and the
    > WDM DDK, I am confused. Where should I look to
    > unconfuse myself? Is it
    > true that I should not use that path? I am
    > resurrecting an NT 4 driver and
    > hoping that getting it to work under Win2K won't be
    > impossible. We have
    > several parameters that need to be accessed by the
    > driver and I would think
    > that the registry would be the place for them. My
    > device driver coding is
    > really from NT4, but I know that we are going to go
    > to WinXP so I would
    > like to do this "right" if possible. I was going to
    > put the parameters in
    >
    HKLM\System\CurrentControlSet\Services\MyDriver\Parameters\(keys/values
    >
    > here). Is that not correct anymore (if it ever
    > was)? If not, where is the
    > normal place to put device driver parameters?
    >
    > Also, where is the normal/standard/whatever place to
    > put device driver data
    > that is too large to fit in the registry? We load
    > hex files into our card
    > and I don't know if \Winnt\System32\drivers is the
    > correct place or
    > not. If not, then where?
    >
    > If anyone has any advice or knowledge I sure would
    > appreciate you passing
    > it on.
    >
    > Also, I have Walter Oney's book "Programming the
    > Microsoft Windows Driver
    > Model" from 1999. Is there a later release or
    > another book that I should
    > read? This one is fine, but I know that I am going
    > to have to move this
    > driver to XP eventually and I don't know what has
    > changed. And I think
    > that Walter Oney's book was published in 1999,
    > before XP. Or are the
    > changes for XP so small that there really is no
    > need?
    >
    > Thanks very much,
    > Michael
    >
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as:
    > xxxxx@yahoo.com
    > To unsubscribe send a blank email to
    %%email.unsub%%


    __________________________________________________
    Do you Yahoo!?
    Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
    http://mailplus.yahoo.com




    ---

    END OF DIGEST

    ---
    You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
    To unsubscribe send a blank email to %%email.unsub%%
  • Dan_PartellyDan_Partelly Member Posts: 741
    For me the reading appeared as statuating that high IRQL can be preempted by
    low IRQL ISR.
    Ill re-read it carefully. I might have been trapped into this beleif by the
    writting style.



    ----- Original Message -----
    From: "Jake Oshins" <xxxxx@windows.microsoft.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Tuesday, December 10, 2002 8:13 PM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    You're right. I owe you an apology. A careful re-reading of your
    article shows that you did understand the code.

    I still think that the first half of your article makes little
    distinction between taking an interrupt and calling a device driver's
    ISR. I believe that the difference between the two is meaningless to
    most of the readers of this list. And it should be made very clear that
    NT will never pre-empt a high-IRQL ISR with a low-IRQL ISR. It will
    also never violate the locking semantics that are supported through the
    concept of IRQL.

    I don't think that the fact that an interrupt is actually enabled or
    disabled at the interrupt controller has much relevence in this context.
    I don't mean to say that you shouldn't be interested in how things are
    implemented. I just mean that you should be careful how you present
    this, since I believe it clouded at least one reader's overall
    understanding.

    - Jake

    -----Original Message-----
    Subject: RE: Device Interrupt priority - Reviewing Jose Flores
    From: "Jose Flores" <xxxxx@joseflores.com>
    Date: Mon, 9 Dec 2002 19:05:47 -0500
    X-Message-Number: 36

    Couple of things:

    [1] Nowhere in that article does it recommend calling
    IoConnectInterrupt()
    w/ a made up IRQL. Nor does it advocate yanking & replacing hals out
    from
    underneath the installation.

    The point of the article was (1) to give a peek at what goes on under
    the
    hood of IRQL manipulation and (2) to illustrate that raising IRQL does
    not
    always deny interrupts associated with lower priority IRQLs to fire. I
    don't think it's a stretch do assume that most people take for granted
    that if they raise to SYNCH that practically no interrupts will fire.
    This is clearly not the case on UP systems. On such a hal, ALL
    interrupts
    will fire (initially), but the subsequent execution of NT's interrupt
    stub
    will prevent the clients ISR from running until IRQL is lowered to an
    acceptable level.

    No doubt that this subtly hardly matters to anyone, except maybe a
    handful
    of people who are either doing seriously funky (most likely
    non-production
    quality) work, or are just morbidly curious.

    [2] Nowhere in the article does it state that IRQL is meaningless on
    uniprocessor systems. In fact it does describe what you call "Lazy
    IRQL".
    From the article (edited for brevity):

    "why do we use it (IRQL) at all on uniprocessor systems?...the NT kernel
    performs explicit checks of the IRQL value at key points in it's
    execution..."

    "...If the vector's IRQL is less than or equal to the currently
    executing
    code's IRQL, then everything is undone, the processor's context is
    restored, and control is returned to the interrupted code. ... In cases
    where the interrupt is dismissed, variables inside the PCR are used to
    mark the particular interrupt vectors as having had an interrupt fire
    that
    was not completely serviced. .... dismissing the interrupt is usually
    followed with actually masking the particular interrupt in hardware to
    prevent further execution of the ISR until the pending interrupt can be
    serviced completely."

    "Each time IRQL is dropped, a check is performed to see if there are any
    'pending' interrupts. If so, then a software interrupt is issued (after
    the IRQL is dropped) corresponding to the vector to which the hardware
    interrupt is mapped. For example, if the clock interrupt is mapped to
    vector 0x30 with an IRQL of 0x1C, then if the current IRQL is dropping
    from 0x1F to 0x2, then ... The ISR executes as normal, and the
    interrupt is
    now completely serviced. The pending bit is cleared, and the interrupt
    is
    unmasked."

    Granted the article wasn't privy to more colorful insider descriptions
    such as Lazy and Strict IRQL, but the end description is essentially the
    same. Likewise, what the article calls an interrupt stub, you call a
    preamble. Tomato, tomato.

    Maybe the unfinished article was poorly written to have anyone to
    conclude
    that the article suggests the above. Or maybe it just wasn't read in
    the
    right frame of mind. Either way, I'd be interested in hearing
    criticisms
    privately from someone with your inside knowledge.



    "Jake Oshins" <xxxxx@windows.microsoft.com> wrote in message
    news:xxxxx@ntdev...

    You asked for an evaluation....

    I wish that Jose had talked to me, or somebody who actually works on the
    code, before he wrote that. He missed some pretty fundamental points.

    First let me say, as I have said in the past in this forum, calling
    IoConnectInterrupt with an IRQL other than that which you were handed by
    the PnP manager will only result in a machine that either fails to
    connect your interrupt or a machine that will eventually deadlock
    itself.

    Second, let me say that you can only run HALMPS.dll on machines with an
    MPS BIOS. And, if your machine has one of those, HALMPS.dll will be
    installed by default. So replacing your HAL will probably result in a
    machine that doesn't boot. (Furthermore, in Windows 2000, Windows XP
    and Windows .Net Server, we'll probably install halmacpi.dll, which is
    similar to halmps.dll, except that it works with an ACPI BIOS.)

    As for the article, Jose's most egregious misunderstanding is that he
    thinks that IRQL is meaningless on uniprocessor systems. It's not.
    It's exactly the same thing that it is on multi-processor systems, a way
    to assign a priority level to a processor.

    What Jose got tripped up on is something that we call "Lazy IRQL." This
    is a way to avoid writing to the control registers on the 8259 PIC
    Interrupt Controller, which is usually in a part of the machine that
    takes a long time to send I/O cycles to.

    In a "Strict IRQL" system, when we take an interrupt, we raise IRQL to
    the appropriate level (which involves writing to the interrupt
    controller) before we issue a "sti" instruction, which re-enables
    interrupts at the processor. Thus we are guaranteed that we will never
    execute any code that is of a lower priority until we finish running the
    appropriate ISR and lower IRQL.

    In a Lazy IRQL HAL, we take advantage of the fact that most interrupts
    don't overlap with other interrupts. Instead of writing to the
    interrupt controller, we merely note that a change of IRQL should have
    occurred. Then we call the ISR for the device, even though
    lower-priority interrupts aren't masked. If one of those interrupts
    happens before we finish the first device's ISR, then the interrupt
    pre-amble code will note that we have just taken an interrupt that
    should have been masked, actually mask the interrupt controller and
    dismiss the errant interrupt without ever calling that second device's
    ISR. Then, when the first device's ISR completes, we go back and run
    the second device's ISR at the correct lower IRQL.

    This system maintains all the semantics of the Strict IRQL system, but
    does many fewer writes to the interrupt controller. At present, we only
    do Lazy IRQL in hal.dll, which is the default single-processor non-ACPI
    HAL. All the other HALs use Strict IRQL.

    Please ignore most of Jose's conclusions, as they are based on these
    misunderstandings.

    Jake Oshins
    NT Kernel Team
    Microsoft


    This posting is provided "AS IS" with no warranties, and confers no
    rights.


    -----Original Message-----
    Subject: Device Interrupt priority & Extreme ISR Priority : new thread
    From: "Christiaan Ghijselinck" <xxxxx@Compaqnet.be>
    Date: Sun, 8 Dec 2002 09:33:59 -0500
    X-Message-Number: 2



    Could someone please evaluate the article of Jose Flores at

    http://www.joseflores.com/docs/ExploringIrql.html

    Assuming that the information is correct, may I then conclude that on a
    multiprocessor system, an ISR connected through IoConnectInterrupt ( ...
    ,
    POWER_LEVEL , ...) ; will :

    - never be suspended by another IRQ
    - always suspend ( preempt ) running lower priority ISR's

    If I install the MPS version on a monoprocessor system, does the
    installation revert to the mono processor HAL.ddl or may I profit from
    the
    multiprocessor version ( halmps.dll ).




    ----------------------------------------------------------------------

    Subject: Re: Writng and Debuging Drivers in C++
    From: "David J. Craig" <xxxxx@yoshimuni.com>
    Date: Mon, 9 Dec 2002 19:02:25 -0500
    X-Message-Number: 37

    I think MSDN is required for someone in the development group to have
    available. You can get the DDKs for "free" if you have one. I have
    also
    found that keeping the old DDKs, SDKs, and operating systems to be
    necess=
    ary
    because most of the world isn't switching as quickly as Microsoft would
    like. There is the archive pack with some of the old stuff too. I have
    found that some documentation disappears if you don't have access to the
    older versions. Also there is one hardware "requirement" that OSR
    advise=
    s
    and that is a 8x SMP system. Some deadlocks and other SMP issues may
    not
    show up quickly on a single CPU or a dual processor. I remember
    releasin=
    g
    one driver that had the no-SMP flag set. We didn't have a SMP system to
    test and the risk to our partners was deemed too high. I have been at a
    company where only one or two of the systems had DVDs. Every other
    syste=
    m
    had CD-ROMs only. I prefer the paychecks get paid instead of having all
    =
    the
    toys I want, but I still want the toys.

    I think that using the checked builds of the HAL and Kernel is required
    t=
    o
    drivers stable. I don't think that you need the entire checked OS for
    drivers, but you may want it for some applications.

    ----- Original Message -----
    From: "Chris Dor=E9" <xxxxx@connecttech.com>
    Newsgroups: ntdev
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Monday, December 09, 2002 5:34 PM
    Subject: [ntdev] Re: Writng and Debuging Drivers in C++


    > >
    > > It is expensive and Microsoft has not done much itself to reduce
    cost=
    s.
    > > Windbg is "free", but you still have to download it. Just printing
    t=
    he
    > user
    > > guide will chew up most of a ream of paper. MSDN is absurdly
    expensi=
    ve
    > and
    > > appears designed to limit the ability to develop to those who have
    de=
    ep
    > > pockets. MSDN Universal costs more than the two computers you need
    t=
    o
    > write
    > > drivers. Add in the IFS Kits and you need $10,000 just to start in
    t=
    he
    > > first year. Remember when many shareware developers could write
    usef=
    ul
    > > utilities, TSRs, and drivers for MS-DOS with little or no expense
    exc=
    ept
    > the
    > > hardware. The costs seem to have shifted from hardware to software.
    =
    I
    > just
    > > read that Microsoft has said that its costs for their operating
    syste=
    ms
    is
    > > only $0.15 or $0.16 per dollar charged. Nice margins!
    > >
    >
    > You do not, by any means, need an MSDN subscription to develop device
    > drivers. If you have access to the internet then you're completely
    set.
    The
    > DDK is practically free (just pay for the shipping), and the entire
    MSD=
    N
    > library is available for free on Microsoft's website. The DDK comes
    wit=
    h a
    > compiler and everything you need to build a driver...in fact you don't
    > _really_ even need access to the internet (of course access to the
    extr=
    a
    > information is quite a help).
    >
    > Now there are some useful things lacking from not having a MSDN
    > subscription, like checked OS builds, but I have actually never used
    th=
    em
    > despite having access to them (I've only used a couple checked system
    > drivers. ie. USB).
    >
    > You are correct on the IFS kit, it does cost a fair amount. I wish I
    co=
    uld
    > get my hands on it for free...oh well.
    >
    > In summary, if you're just starting out, don't feel as though you need
    large
    > capital in order to start developing for windows.
    >
    > Chris
    >
    > P.S. This doesn't just apply to device drivers. You can develop
    applications
    > for free using MS tools as well (you don't need Visual
    Studio...althoug=
    h
    IMO
    > it is a great product and I use it).
    >
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
    > To unsubscribe send a blank email to %%email.unsub%%
    >




    ----------------------------------------------------------------------

    Subject: Registry for device driver? And Walter Oney?
    From: Michael Wade <xxxxx@pacbell.net>
    Date: Mon, 09 Dec 2002 17:17:40 -0800
    X-Message-Number: 38

    I apologize for asking such a basic question, but I really want to make
    sure before I play around with the registry.

    I thought that once upon a time the path to the registry key for the
    driver
    was passed into the driver. However, from reading around the net and
    the
    WDM DDK, I am confused. Where should I look to unconfuse myself? Is it

    true that I should not use that path? I am resurrecting an NT 4 driver
    and
    hoping that getting it to work under Win2K won't be impossible. We have

    several parameters that need to be accessed by the driver and I would
    think
    that the registry would be the place for them. My device driver coding
    is
    really from NT4, but I know that we are going to go to WinXP so I would
    like to do this "right" if possible. I was going to put the parameters
    in
    HKLM\System\CurrentControlSet\Services\MyDriver\Parameters\(keys/values
    here). Is that not correct anymore (if it ever was)? If not, where is
    the
    normal place to put device driver parameters?

    Also, where is the normal/standard/whatever place to put device driver
    data
    that is too large to fit in the registry? We load hex files into our
    card
    and I don't know if \Winnt\System32\drivers is the correct place or
    not. If not, then where?

    If anyone has any advice or knowledge I sure would appreciate you
    passing
    it on.

    Also, I have Walter Oney's book "Programming the Microsoft Windows
    Driver
    Model" from 1999. Is there a later release or another book that I
    should
    read? This one is fine, but I know that I am going to have to move this

    driver to XP eventually and I don't know what has changed. And I think
    that Walter Oney's book was published in 1999, before XP. Or are the
    changes for XP so small that there really is no need?

    Thanks very much,
    Michael




    ----------------------------------------------------------------------

    Subject: Property Page DLL in registry won't change. When does one
    change the
    .inf class GUID?
    From: Michael Wade <xxxxx@pacbell.net>
    Date: Mon, 09 Dec 2002 17:21:04 -0800
    X-Message-Number: 39

    I see these heavy duty threads going on about interrupt priority and
    filters and I feel like a little kid crying "Let me play! Let me
    play! You never let me play!"

    Be that as it may. I am trying to get a property page up and going and
    I
    thought that I did. But I can't seem to get rid of my test dll for the
    property page provider. I have a line in my .inf file that reads:
    HKR,,EnumPropPages32,,"DevPropSheet.dll,DevicePropPageProvider"
    It used to read:
    HKR,,EnumPropPages32,,"TestDevPropSheet.dll,DevicePropPageProvider"

    However, when I install it, my old "TestDevPropSheet.dll" seems to
    always
    get loaded. I have uninstalled the driver, deleted the corresponding
    oem*.inf files and everything else I could think of. But it still wants
    to
    grab that test dll. I then looked in the registry for it, and it's in
    there under HKLM/SYSTEM/CurrentControlSet/(CLASSGUID). But I don't know

    why it's not getting overwritten when I load the device driver again
    using
    the .inf file with the DevPropSheet.dll (without the Test). The GUID
    corresponds to that in the [Version] section key = ClassGUID. Which
    brings
    up another question that is probably at the root. When should one
    change
    the Class GUID? And where does one find information about that GUID? I

    tried the Win2k DDK, but if it's there then I'm not finding it.

    Thanks for any help,
    Michael




    ----------------------------------------------------------------------

    Subject: RE: Property Page DLL in registry won't change. When does one
    change the .inf class GUID?
    From: "Doron Holan" <xxxxx@windows.microsoft.com>
    Date: Mon, 9 Dec 2002 17:29:38 -0800
    X-Message-Number: 40

    What is happening is that the class registry info is written only the
    first time a device of that class is installed (ie the first time the OS
    sees that new device class). Are you having these problems on a fresh
    installed system where your test DLL has never been installed before?

    Also, are you sure you want to have the property page for the entire
    class? You can also install a property page on each individual device
    (it ends up being in
    HKLM/SYSTEM/CurrentControlSet/(CLASSGUID)/<instance>). The per instance
    value is written everytime a device is installed (no matter the device
    class).

    D

    This posting is provided "AS IS" with no warranties, and confers no
    rights=20

    -----Original Message-----
    From: Michael Wade [mailto:xxxxx@pacbell.net]=20
    Sent: Monday, December 09, 2002 5:21 PM
    To: NT Developers Interest List
    Subject: [ntdev] Property Page DLL in registry won't change. When does
    one change the .inf class GUID?

    I see these heavy duty threads going on about interrupt priority and=20
    filters and I feel like a little kid crying "Let me play! Let me=20
    play! You never let me play!"

    Be that as it may. I am trying to get a property page up and going and
    I=20
    thought that I did. But I can't seem to get rid of my test dll for
    the=20
    property page provider. I have a line in my .inf file that reads:
    HKR,,EnumPropPages32,,"DevPropSheet.dll,DevicePropPageProvider"
    It used to read:
    HKR,,EnumPropPages32,,"TestDevPropSheet.dll,DevicePropPageProvider"

    However, when I install it, my old "TestDevPropSheet.dll" seems to
    always=20
    get loaded. I have uninstalled the driver, deleted the corresponding=20
    oem*.inf files and everything else I could think of. But it still wants
    to=20
    grab that test dll. I then looked in the registry for it, and it's
    in=20
    there under HKLM/SYSTEM/CurrentControlSet/(CLASSGUID). But I don't know

    why it's not getting overwritten when I load the device driver again
    using=20
    the .inf file with the DevPropSheet.dll (without the Test). The GUID=20
    corresponds to that in the [Version] section key =3D ClassGUID. Which
    brings=20
    up another question that is probably at the root. When should one
    change=20
    the Class GUID? And where does one find information about that GUID? I

    tried the Win2k DDK, but if it's there then I'm not finding it.

    Thanks for any help,
    Michael




    ---
    You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
    To unsubscribe send a blank email to %%email.unsub%%


    ----------------------------------------------------------------------

    Subject: RE: Device Interrupt priority - Reviewing Jose Flores
    From: "Jose Flores" <xxxxx@joseflores.com>
    Date: Mon, 9 Dec 2002 20:48:21 -0500
    X-Message-Number: 41

    Yes interrupts associated with a higher IRQL than the current IRQL will
    run end to end. At completion of the high IRQL isr, control is resumed
    by
    the lower IRQL. On all hals, everywhere.

    However, on at least 1 common hal, an interrupt associated with an IRQL
    *lower* than the current IRQL will (1) preempt and run for a little bit
    (long enough for the OS stub to gain control), (2) be masked on the
    controller (to prevent unwarrented preemption from happening again), (3)
    be marked "pending" in memory, and (4) return control to the higher IRQL
    (current) code block. Following the completion of the higher IRQL ISR,
    control is resumed by the lower IRQL ISR, the interrupt "unpended", and
    be
    unmasked in hardware & life goes on as normal.

    In all hals, in all cases, the meat of a lower IRQL ISR is never run
    before a higher IRQL ISR. Where meat is defined as the device driver's
    ISR passed to IoconnectInterrupt.

    "Christiaan Ghijselinck" <xxxxx@Compaqnet.be> wrote in message
    news:xxxxx@ntdev...
    >
    >
    > Thanks for the reply Jake,
    >
    > You wrote :
    >
    > As for my understanding, may I conclude that higher level IRQ's DO
    > interrupt the running ISR and will run to the end, after which the
    current
    > interrupted ISR will continue ? Does this mean that the 8259 PIC's IRQ
    > priority handling is programmed/reprogrammed on the fly by the OS to
    match
    > the IRQL of the ISR's in the system ?
    >
    >
    >
    >
    >

    ----------------------------------------------------------------------

    Subject: Re: Registry for device driver? And Walter Oney?
    From: Phong Ho <xxxxx@yahoo.com>
    Date: Mon, 9 Dec 2002 18:16:04 -0800 (PST)
    X-Message-Number: 42

    The second release of the Oney's should be out on
    December 9, 2002.
    http://www.microsoft.com/mspress/books/6262.asp
    I am wondering if the second release will cover
    NDIS. Could the author let us know?

    Thanks






    --- Michael Wade <xxxxx@pacbell.net> wrote:
    > I apologize for asking such a basic question, but I
    > really want to make
    > sure before I play around with the registry.
    >
    > I thought that once upon a time the path to the
    > registry key for the driver
    > was passed into the driver. However, from reading
    > around the net and the
    > WDM DDK, I am confused. Where should I look to
    > unconfuse myself? Is it
    > true that I should not use that path? I am
    > resurrecting an NT 4 driver and
    > hoping that getting it to work under Win2K won't be
    > impossible. We have
    > several parameters that need to be accessed by the
    > driver and I would think
    > that the registry would be the place for them. My
    > device driver coding is
    > really from NT4, but I know that we are going to go
    > to WinXP so I would
    > like to do this "right" if possible. I was going to
    > put the parameters in
    >
    HKLM\System\CurrentControlSet\Services\MyDriver\Parameters\(keys/values
    >
    > here). Is that not correct anymore (if it ever
    > was)? If not, where is the
    > normal place to put device driver parameters?
    >
    > Also, where is the normal/standard/whatever place to
    > put device driver data
    > that is too large to fit in the registry? We load
    > hex files into our card
    > and I don't know if \Winnt\System32\drivers is the
    > correct place or
    > not. If not, then where?
    >
    > If anyone has any advice or knowledge I sure would
    > appreciate you passing
    > it on.
    >
    > Also, I have Walter Oney's book "Programming the
    > Microsoft Windows Driver
    > Model" from 1999. Is there a later release or
    > another book that I should
    > read? This one is fine, but I know that I am going
    > to have to move this
    > driver to XP eventually and I don't know what has
    > changed. And I think
    > that Walter Oney's book was published in 1999,
    > before XP. Or are the
    > changes for XP so small that there really is no
    > need?
    >
    > Thanks very much,
    > Michael
    >
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as:
    > xxxxx@yahoo.com
    > To unsubscribe send a blank email to
    %%email.unsub%%


    __________________________________________________
    Do you Yahoo!?
    Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
    http://mailplus.yahoo.com




    ---

    END OF DIGEST

    ---
    You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
    To unsubscribe send a blank email to %%email.unsub%%


    ---
    You are currently subscribed to ntdev as: xxxxx@rdsor.ro
    To unsubscribe send a blank email to %%email.unsub%%
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >does many fewer writes to the interrupt controller. At present, we
    only
    >do Lazy IRQL in hal.dll, which is the default single-processor
    non-ACPI
    >HAL. All the other HALs use Strict IRQL.

    Sorry, but why Lazy IRQL was not used on UP ACPI HAL (HALACPI)?

    Max
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > Somewhere I have read that all DPC's for a particular processor
    within the
    > system are FIFO queued
    > to run at the same IRQL. This would mean that when a high priority
    ISR
    > queues a DPC, this DPC will
    > only come to run when all other DPC's, even those queued by less
    priority
    > ISR's, have finished.
    > Is this correct ?

    Yes.

    Max
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > issues an STI. This leaves a small window within which an interrupt
    could
    > theoretically be missed

    It will not. It will be put on hold on PIC/APIC.

    Max
  • Correct, but it can hold only ONE ! See my previous answer on this theme
    ....


    ----- Original Message -----
    From: "Maxim S. Shatskih" <xxxxx@storagecraft.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Wednesday, December 11, 2002 10:20 AM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > > issues an STI. This leaves a small window within which an interrupt
    > could
    > > theoretically be missed
    >
    > It will not. It will be put on hold on PIC/APIC.
    >
    > Max
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
    > To unsubscribe send a blank email to %%email.unsub%%
    >
  • Well thanks. This is something for the "MS Driver Survey".
    I need a DPC queue per available interrupt IRQL, handled
    accordingly.


    ----- Original Message -----
    From: "Maxim S. Shatskih" <xxxxx@storagecraft.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Wednesday, December 11, 2002 10:17 AM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > > Somewhere I have read that all DPC's for a particular processor
    > within the
    > > system are FIFO queued
    > > to run at the same IRQL. This would mean that when a high priority
    > ISR
    > > queues a DPC, this DPC will
    > > only come to run when all other DPC's, even those queued by less
    > priority
    > > ISR's, have finished.
    > > Is this correct ?
    >
    > Yes.
    >
    > Max
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
    > To unsubscribe send a blank email to %%email.unsub%%
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Unless the APIC has the ability to queue interrupts, that will be of limited
    usefulness. The last machine I worked with that could queue interrupts by
    hardware was the Sperry Univac 418III, way back in the seventies and
    eighties. Anybody know any other systems that do it ?

    Alberto.


    -----Original Message-----
    From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
    Sent: Wednesday, December 11, 2002 4:20 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > issues an STI. This leaves a small window within which an interrupt
    could
    > theoretically be missed

    It will not. It will be put on hold on PIC/APIC.

    Max



    ---
    You are currently subscribed to ntdev as: xxxxx@compuware.com
    To unsubscribe send a blank email to %%email.unsub%%



    The contents of this e-mail are intended for the named addressee only. It
    contains information that may be confidential. Unless you are the named
    addressee or an authorized designee, you may not copy or use it, or disclose
    it to anyone else. If you received it in error please notify us immediately
    and then destroy it.
  • Norbert_KawulskiNorbert_Kawulski Member Posts: 174
    Hmm, aren't PCI IRQs level triggered ?
    With level triggered IRQ you never loose one.
    But the term 'loose' depends on how you define it. Your hardware may
    have some max. latency requirements that make you loose an event.
    Norbert.
    --------
    "If you have tried something and failed, you are vastly better off
    than if you had tried nothing and succeeded."
    ---- snip ----
    > Unless the APIC has the ability to queue interrupts, that will be of limited
    > usefulness. The last machine I worked with that could queue interrupts by
    > hardware was the Sperry Univac 418III, way back in the seventies and
    > eighties. Anybody know any other systems that do it ?

    ---- snip ----
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    The PCI bus will hold the IRQ signal till the driver's ISR will reset
    it. With any PIC, be it 8259 or APIC.

    Max

    ----- Original Message -----
    From: "Moreira, Alberto" <xxxxx@compuware.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Wednesday, December 11, 2002 6:13 PM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > Unless the APIC has the ability to queue interrupts, that will be of
    limited
    > usefulness. The last machine I worked with that could queue
    interrupts by
    > hardware was the Sperry Univac 418III, way back in the seventies and
    > eighties. Anybody know any other systems that do it ?
    >
    > Alberto.
    >
    >
    > -----Original Message-----
    > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
    > Sent: Wednesday, December 11, 2002 4:20 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
    Flores
    >
    >
    > > issues an STI. This leaves a small window within which an
    interrupt
    > could
    > > theoretically be missed
    >
    > It will not. It will be put on hold on PIC/APIC.
    >
    > Max
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as:
    xxxxx@compuware.com
    > To unsubscribe send a blank email to %%email.unsub%%
    >
    >
    >
    > The contents of this e-mail are intended for the named addressee
    only. It
    > contains information that may be confidential. Unless you are the
    named
    > addressee or an authorized designee, you may not copy or use it, or
    disclose
    > it to anyone else. If you received it in error please notify us
    immediately
    > and then destroy it.
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
    > To unsubscribe send a blank email to %%email.unsub%%
    >
  • Who will rise to the next challenge :


    "Four PCI cards fire quasi at the same moment ( assume 100 ns time
    difference ) an interrupt. Card1 , card2 and card3 have different IRQ's ,
    card4 shares the same IRQ with card3.

    I would like to see a detailled flow of all handschaking actions between the
    Cards <--> [ PCI bus <-- > ] PIC/APIC <--> CPU with bus <--> OS/ISR's in
    both the "Lazy" and the "Strict Model". The flow ends when the last ( fourth )
    IRQ has been completely serviced.

    Such a description would have an incredible value .


    ----- Original Message -----
    From: "Maxim S. Shatskih"
    To: "NT Developers Interest List"
    Sent: Wednesday, December 11, 2002 7:20 PM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > The PCI bus will hold the IRQ signal till the driver's ISR will reset
    > it. With any PIC, be it 8259 or APIC.
    >
    > Max
    >
    > ----- Original Message -----
    > From: "Moreira, Alberto"
    > To: "NT Developers Interest List"
    > Sent: Wednesday, December 11, 2002 6:13 PM
    > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores
    >
    >
    > > Unless the APIC has the ability to queue interrupts, that will be of
    > limited
    > > usefulness. The last machine I worked with that could queue
    > interrupts by
    > > hardware was the Sperry Univac 418III, way back in the seventies and
    > > eighties. Anybody know any other systems that do it ?
    > >
    > > Alberto.
    > >
    > >
    > > -----Original Message-----
    > > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
    > > Sent: Wednesday, December 11, 2002 4:20 AM
    > > To: NT Developers Interest List
    > > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
    > Flores
    > >
    > >
    > > > issues an STI. This leaves a small window within which an
    > interrupt
    > > could
    > > > theoretically be missed
    > >
    > > It will not. It will be put on hold on PIC/APIC.
    > >
    > > Max
    > >
    > >
    > >
    > > ---
    > > You are currently subscribed to ntdev as:
    > xxxxx@compuware.com
    > > To unsubscribe send a blank email to %%email.unsub%%
    > >
    > >
    > >
    > > The contents of this e-mail are intended for the named addressee
    > only. It
    > > contains information that may be confidential. Unless you are the
    > named
    > > addressee or an authorized designee, you may not copy or use it, or
    > disclose
    > > it to anyone else. If you received it in error please notify us
    > immediately
    > > and then destroy it.
    > >
    > >
    > >
    > > ---
    > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
    > > To unsubscribe send a blank email to %%email.unsub%%
    > >
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
    > To unsubscribe send a blank email to %%email.unsub%%
    >
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,305
    I thought the APIC in fact had the ability to queue one or perhaps two interrupts per source
    if no target were ready to service the interrupt.

    ===========================
    Mark Roddy
    Consultant, Microsoft DDK MVP
    Hollis Technology Solutions
    xxxxx@hollistech.com
    www.hollistech.com
    603-321-1032


    > The PCI bus will hold the IRQ signal till the driver's ISR will reset
    > it. With any PIC, be it 8259 or APIC.
    >
    > Max
    >
    > ----- Original Message -----
    > From: "Moreira, Alberto"
    > To: "NT Developers Interest List"
    > Sent: Wednesday, December 11, 2002 6:13 PM
    > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores
    >
    >
    > > Unless the APIC has the ability to queue interrupts, that will be of
    > limited
    > > usefulness. The last machine I worked with that could queue
    > interrupts by
    > > hardware was the Sperry Univac 418III, way back in the seventies and
    > > eighties. Anybody know any other systems that do it ?
    > >
    > > Alberto.
    > >
    > >
    > > -----Original Message-----
    > > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
    > > Sent: Wednesday, December 11, 2002 4:20 AM
    > > To: NT Developers Interest List
    > > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
    > Flores
    > >
    > >
    > > > issues an STI. This leaves a small window within which an
    > interrupt
    > > could
    > > > theoretically be missed
    > >
    > > It will not. It will be put on hold on PIC/APIC.
    > >
    > > Max
    > >
    > >
    > >
    > > ---
    > > You are currently subscribed to ntdev as:
    > xxxxx@compuware.com
    > > To unsubscribe send a blank email to %%email.unsub%%
    > >
    > >
    > >
    > > The contents of this e-mail are intended for the named addressee
    > only. It
    > > contains information that may be confidential. Unless you are the
    > named
    > > addressee or an authorized designee, you may not copy or use it, or
    > disclose
    > > it to anyone else. If you received it in error please notify us
    > immediately
    > > and then destroy it.
    > >
    > >
    > >
    > > ---
    > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
    > > To unsubscribe send a blank email to %%email.unsub%%
    > >
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@hollistech.com
    > To unsubscribe send a blank email to %%email.unsub%%
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >"Four PCI cards fire quasi at the same moment ( assume 100 ns time
    >difference ) an interrupt. Card1 , card2 and card3 have different
    IRQ's ,
    >card4 shares the same IRQ with card3.
    >I would like to see a detailled flow of all handschaking actions
    between the

    I will omit cards1, 2, 3 and describe only cards 3 and 4.

    - card 3 starts to pull INTA# down. Note that the line is
    open-collector.
    - card 4 starts to pull INTA# down.
    - this pull-down causes the PIC to interrupt the CPU.
    - the PIC's mask is raised to this IRQ.
    - the CPU, after possibly executing STI, starts to execute a vector
    - the NT kernel enumerates all drivers on these vectors
    - it calls ISR for card 3
    - the ISR writes something to card 3, which stops it from pulling
    INTA# down.
    - nevertheless, INTA# is still pulled down by card 4
    - card 3 ISR done, the NT kernel calls card 4's ISR
    - the ISR writes something to card 4, which stops it from pulling
    INTA# down.
    - nobody more pulls INTA# down. It is pulled up by a resistor.
    - PIC returns to passive (no interrupt pending) mode
    - the NT kernel returns from the last ISR and executes IRET.

    Max
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Sorry, what is queuing an interrupt?
    The PCI card just holds INTA# down till the driver's ISR will reset it
    from this state. So, no more interrupts from the same PCI card can
    occur during this :-)

    Max

    ----- Original Message -----
    From: "Mark Roddy" <xxxxx@hollistech.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Wednesday, December 11, 2002 11:46 PM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > I thought the APIC in fact had the ability to queue one or perhaps
    two interrupts per source
    > if no target were ready to service the interrupt.
    >
    > ===========================
    > Mark Roddy
    > Consultant, Microsoft DDK MVP
    > Hollis Technology Solutions
    > xxxxx@hollistech.com
    > www.hollistech.com
    > 603-321-1032
    >
    >
    > > The PCI bus will hold the IRQ signal till the driver's ISR will
    reset
    > > it. With any PIC, be it 8259 or APIC.
    > >
    > > Max
    > >
    > > ----- Original Message -----
    > > From: "Moreira, Alberto" <xxxxx@compuware.com>
    > > To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    > > Sent: Wednesday, December 11, 2002 6:13 PM
    > > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
    Flores
    > >
    > >
    > > > Unless the APIC has the ability to queue interrupts, that will
    be of
    > > limited
    > > > usefulness. The last machine I worked with that could queue
    > > interrupts by
    > > > hardware was the Sperry Univac 418III, way back in the seventies
    and
    > > > eighties. Anybody know any other systems that do it ?
    > > >
    > > > Alberto.
    > > >
    > > >
    > > > -----Original Message-----
    > > > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
    > > > Sent: Wednesday, December 11, 2002 4:20 AM
    > > > To: NT Developers Interest List
    > > > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
    > > Flores
    > > >
    > > >
    > > > > issues an STI. This leaves a small window within which an
    > > interrupt
    > > > could
    > > > > theoretically be missed
    > > >
    > > > It will not. It will be put on hold on PIC/APIC.
    > > >
    > > > Max
    > > >
    > > >
    > > >
    > > > ---
    > > > You are currently subscribed to ntdev as:
    > > xxxxx@compuware.com
    > > > To unsubscribe send a blank email to %%email.unsub%%
    > > >
    > > >
    > > >
    > > > The contents of this e-mail are intended for the named addressee
    > > only. It
    > > > contains information that may be confidential. Unless you are
    the
    > > named
    > > > addressee or an authorized designee, you may not copy or use it,
    or
    > > disclose
    > > > it to anyone else. If you received it in error please notify us
    > > immediately
    > > > and then destroy it.
    > > >
    > > >
    > > >
    > > > ---
    > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
    > > > To unsubscribe send a blank email to %%email.unsub%%
    > > >
    > >
    > >
    > >
    > > ---
    > > You are currently subscribed to ntdev as: xxxxx@hollistech.com
    > > To unsubscribe send a blank email to %%email.unsub%%
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
    > To unsubscribe send a blank email to %%email.unsub%%
    >
  • > The PCI card just holds INTA# down till the driver's ISR will reset it

    How ? I thought the hardware signal INTA# is reset by the PIC. There
    are no software instructions for that. The OS acknowledges the PIC
    in different ways, see "Lazy" vs. "Strict"
  • Sorry Max, this is too popular. I like to see the cycle loop when the PIC
    puts the "int"
    instruction on the bus, when in the mean time other cards take the INTA#
    down. I also
    like to know the reaction of the PIC when priorities are changed and /or
    interrupts
    are masked off within the "Lazy" and "Strict" model, also when the PIC
    cannot
    push a new "int" and vector because of a cleared interrupt flag, even then
    when it
    has already been ACK'd by the processor, etc...
    Note : everything I state here is more or less an assumption until I get a
    non-popular
    description

    Christiaan


    ----- Original Message -----
    From: "Maxim S. Shatskih" <xxxxx@storagecraft.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Wednesday, December 11, 2002 10:52 PM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > >"Four PCI cards fire quasi at the same moment ( assume 100 ns time
    > >difference ) an interrupt. Card1 , card2 and card3 have different
    > IRQ's ,
    > >card4 shares the same IRQ with card3.
    > >I would like to see a detailled flow of all handschaking actions
    > between the
    >
    > I will omit cards1, 2, 3 and describe only cards 3 and 4.
    >
    > - card 3 starts to pull INTA# down. Note that the line is
    > open-collector.
    > - card 4 starts to pull INTA# down.
    > - this pull-down causes the PIC to interrupt the CPU.
    > - the PIC's mask is raised to this IRQ.
    > - the CPU, after possibly executing STI, starts to execute a vector
    > - the NT kernel enumerates all drivers on these vectors
    > - it calls ISR for card 3
    > - the ISR writes something to card 3, which stops it from pulling
    > INTA# down.
    > - nevertheless, INTA# is still pulled down by card 4
    > - card 3 ISR done, the NT kernel calls card 4's ISR
    > - the ISR writes something to card 4, which stops it from pulling
    > INTA# down.
    > - nobody more pulls INTA# down. It is pulled up by a resistor.
    > - PIC returns to passive (no interrupt pending) mode
    > - the NT kernel returns from the last ISR and executes IRET.
    >
    > Max
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
    > To unsubscribe send a blank email to %%email.unsub%%
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    PCI controllers are generally designed so that their interrupt signal output is "asserted" 'til some systems software (like a device driver, usually code in a first-level or second-level interrupt handler) performs a well-defined operation to clear the condition which caused the controller to "assert" the interrupt to start with.

    So, I think the answer to this question is "by definition of a PCI 2.1 (and lesser version) controller level-sensitive interrupt mechanism".

    When PCI 2.2-2.3 becomes ubiquitous, we'll be discussing "how does Message Signaled Interrupts" work.

    Cheers

    -----Original Message-----
    From: Christiaan Ghijselinck [mailto:xxxxx@CompaqNet.be]
    Sent: Wednesday, December 11, 2002 4:12 PM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores



    > The PCI card just holds INTA# down till the driver's ISR will reset it

    How ? I thought the hardware signal INTA# is reset by the PIC. There
    are no software instructions for that. The OS acknowledges the PIC
    in different ways, see "Lazy" vs. "Strict"


    -
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > Note : everything I state here is more or less an assumption until I
    get a
    > non-popular
    > description

    You can find it on Intel's site - for both 8259 and APIC.

    Max
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > > The PCI card just holds INTA# down till the driver's ISR will
    reset it
    >
    > How ? I thought the hardware signal INTA# is reset by the PIC.

    No.
    The only way of resetting it is the card-dependent one (writing to
    status or "IRQ disable" register), and only the card's driver can (and
    must) do this.

    > are no software instructions for that. The OS acknowledges the PIC

    The only "acknowledgement" for PCI IRQs is the card-dependent one.

    Max
  • Thanks, I know that these fine documents exist. But I would like to see an
    even
    detailled desciption on how the OS works with the CPU and PIC/APIC in a
    timely
    manner. This would allow us to link both desriptions, construct time related
    x/y-axis
    flow diagrams and getting a deep insight of what is possible/not allowed.
    Much of
    that hard problems that occur "one or two times a week/month" could be
    avoided.


    ----- Original Message -----
    From: "Maxim S. Shatskih" <xxxxx@storagecraft.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Thursday, December 12, 2002 2:15 PM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > > Note : everything I state here is more or less an assumption until I
    > get a
    > > non-popular
    > > description
    >
    > You can find it on Intel's site - for both 8259 and APIC.
    >
    > Max
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
    > To unsubscribe send a blank email to %%email.unsub%%
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > Much of
    > that hard problems that occur "one or two times a week/month" could
    be
    > avoided.

    NT _never_ loses an interrupt. It can only deliver it a bit later then
    you want, but not lose.

    Max
  • I have understand that now. This brings me upon the idea how long this
    could take when a driver acknownledges the card within a DPC ( just as
    MS prescribes ) that WILL be queued at the bottom : 10 us, 50 us 100 us ?

    To give you an idea, my NE2000 compatible driver "consumes" about
    15 us on old ISA NIC. By teh way, is it a hard rule that a card should
    hold
    its INTA# as long as it does not receive a response ?


    ----- Original Message -----
    From: "Maxim S. Shatskih" <xxxxx@storagecraft.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Thursday, December 12, 2002 2:13 PM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > > > The PCI card just holds INTA# down till the driver's ISR will
    > reset it
    > >
    > > How ? I thought the hardware signal INTA# is reset by the PIC.
    >
    > No.
    > The only way of resetting it is the card-dependent one (writing to
    > status or "IRQ disable" register), and only the card's driver can (and
    > must) do this.
    >
    > > are no software instructions for that. The OS acknowledges the PIC
    >
    > The only "acknowledgement" for PCI IRQs is the card-dependent one.
    >
    > Max
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
    > To unsubscribe send a blank email to %%email.unsub%%
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    With hardware interrupt handling you traverse into the deepest, darkest secrets of systems programming.

    I've broken down below into the following:

    1) Interrupts exist
    2) IO Bus Side Interrupt signaling
    3) IO Bus Interrupt topology
    4) Host side interrupt signaling
    5) Host side interrupt signaling evolution
    6) Software servicing of interrupts
    7) Common mistakes
    8) Live within the model

    1) Interrupts exist

    The first realization is that interrupts exist at all. Basically their intent is to inform that something that you expect to happen or might have expected to happen may have actually happened.

    2) IO Bus Side Interrupt signaling

    At the IO bus level (ISA, PCI), interrupts are dedicated signal traces from a device to the host bridge that attaches the IO bus to the remainder of the system (memory, CPUs, other IO buses). These signal traces can be thought of as unidirectional, in that the device drives the signal line, whereas the host bridge samples/responds to the signal line.

    Whether or not the signal traces (interrupt lines) can be shared by more than one device is a function of the IO bus design. ISA buses do not provide sharing of these interrupt lines, whereas PCI does. In order to facilitate sharing devices employ level sensitive interrupts. By electrical design, there is a pull up or down in h/w on the signal so that if no device is asserting the signal it appears as deasserted. When a device wishes to signal a level sensitive interrupt, it drives or sinks the signal to the opposite state thus making the interrupt line asserted. Electrically, these shared signals are special because you can have two or more devices driving or sinking the current (WIRE-OR or WIRE-AND) without burning out the h/w circuits in the other devices that are also asserting the signal.

    When a device has asserted a level sensitive interrupt, it keeps the interrupt line asserted until an IO bus transaction clears the interrupt condition. This IO bus transaction is normally initiated by software. Typically, s/w reads a device interrupt status register to determine the actual cause of the interrupt and then writes back the set of bits that the s/w serviced. So from a h/w perspective each device has 3 interrupt related registers. One is the interrupt status bits, indicating which interrupts conditions are occurring. An interrupt status mask which s/w can use to mask off particular interrupt status bits so that they do not cause an interrupt, and finally an interrupt acknowledge register. By design the h/w will assert its interrupt line if the result of anding the interrupt status bits with the interrupt mask register is non-zero. Software normally reads the interrupt status bits (sometimes there is an additional register called interrupt pending which is the anded result of the interrupt status and mask) to determine if its device is interrupting. If so the s/w employs whatever s/w logic is needed to service the condition. When s/w has finished servicing all the unmasked interrupt status conditions it does a write back to the interrupt acknowledge register specifying the bits that it has serviced. Thus causes the h/w to re-evaluate the conditions feeding into the interrupt status register. Note there is no-potential of missing an interrupt here as long as the software only acknowledges the interrupt conditions that it has actually serviced. The h/w will keep the interrupt line asserted while unmasked interrupt status bits are still valid.

    So you may ask, why with level sensitive interrupts isn't the processor being interrupted all the time? This is solved with an mechanism called EOI (End of Interrupt). The host bridge examines the interrupt lines and maintains state about each interrupt line. When it detects that a level triggered interrupt line is asserted it schedules a host bus transaction to inform the system about the interrupt. When this is internally scheduled, it marks the internal state for that interrupt line so that it doesn't schedule a new host bus transaction to report that interrupt again until s/w does a host bus transaction to the host bridge to EOI that particular interrupt source. The EOI causes the host bridge to re-enable its internal logic associated with that interrupt line and re-examine the interrupt signal to determine if its still asserted. If the line is still asserted then the whole process starts over again.

    On ISA buses, devices used Edge Triggered interrupts. The triggering edge could be a rising or falling edge of the signal (i.e. only one side of the signal transition signals the interrupt). PCI devices can also use edge triggered interrupts, but level triggered is preferred mechanism for PCI.

    The drawback with Edge Triggered interrupts is that they cannot be easily shared amongst multiple devices. The ISA or PCI device that uses Edge Triggered interrupts will need different logic to create a signal interrupt line pulse (and not generate another one) until s/w has explicitly told it that it is done servicing interrupts. This is typically the folly of many of the edge triggered designs.

    One of the advantages of the Edge Triggered interrupts is that the host bridge doesn't need an EOI. It can accept another interrupt from an edge triggered device as soon as it has sent the previous host bus transaction to report the previous interrupt. If the edge triggered interrupt occurs again before the previous host bus transaction has completed, the behavior is host bridge dependent. Sometimes the host bridge can latch one additional edge, other host bridges report this as a spurious interrupt.

    3) IO Bus Interrupt topology

    Since ISA devices use edge triggered interrupts and edge triggered interrupts aren't easily shared, each ISA 16 bit bus slot has access to all interrupt signal lines. Thus each device needs to be configured to uniquely use just one of these interrupt lines. In the 1980's this was done with jumpers. ISA plug and play came around and with some additional device logic the interrupt line selection could be done programmatically.

    PCI defines four interrupt lines per device A, B, C and D. By default, if a PCI device only uses one interrupt it should only use interrupt A. The motherboard designer selects how the A, B, C and D interrupt lines from each PCI slot are routed to the host interrupt controller. Normally, the A(s) from each slot are routed to unique interrupt signal pins on the host interrupt controller. This mapping from of the interrupt lines from each slot to the host interrupt controller is known a priori by the system BIOS. This information is reported to the host OS during system boot.

    You may have noticed in this section I started referring to the host interrupt controller instead of the host bridge. This is because in early systems the host interrupt controller was a unique set of devices from the host bridge. Thus interrupts are in essence handled (originally physically) logically on a different bus. However, as time as passed the two functions have merged to interoperate on top of the same infrastructure.

    On original 16 bit ISA PCs, the host interrupt controller was 2 cascaded Intel 8259A Programmer Interrupt Controllers. One device was the master interrupt controller, the second was a slave (a feature of the 8259A). This master/slave design allowed up to 64 interrupts with 9 devices, but the original PC design only used two.

    Each 8259A has 8 interrupt line inputs. Each could be configured as edge or level triggered. On the master device an interrupt line could be configured as cascaded (indicating that a second 8259A was driving that interrupt line input). Thus this cascading caused the loss of one interrupt line in exchange for 8 more, thus we had 15 interrupts in the original PC design.

    Some of these interrupts were dedicated to system resources, timer, clock, math co-processor interrupt. Others ended up being available to be used as IO bus interrupt signal inputs.

    4) Host side interrupt signaling

    Amazingly the 8259A(s) appeared as devices on the ISA bus itself, since they had programmable registers (e.g. interrupt masks, configuration, interrupt status, etc). Thus the ISA bus design included special transaction types that allowed the 8259A to tell the system (i.e. essentially the host bus transaction I mentioned above) about an interrupt that occurred. This was done with a two cycle approach. The master 8259 actually had an interrupt output that was wired directly to the CPU. When the CPU was ready and the interrupt was asserted it would generate an interrupt special cycle indicating that it was ready to receive the interrupt (at this point the 8259A would deassert its interrupt output). The CPU would follow this with an interrupt acknowledge read cycle, which caused either the master or slave 8259A to place the corresponding 8 bit interrupt vector onto the data bus corresponding to the interrupt that was to be serviced). Thus when the CPU had interrupts disabled it would not generate any special interrupt cycles, and interrupts were essentially held in the 8259A(s) until the CPU was ready to accept them.

    5) Host side interrupt signaling evolution

    As time passed the performance of the 8259A, along with the number of supported interrupts became design limitations. This along with the integration of legacy ISA devices into SuperIO style chips allowed Intel to redesign the h/w mechanisms used to deliver host side interrupts while preserving the 8259A programming model. Eventually, the 8259A programming model was itself deemed antiquated, which gave rise to the APIC and SAPIC designs that people are really just starting to understand today.

    So logically, APIC(s) have some additional capabilities that the 8259A(s) lacked. The most important (I think) is the ability to signal an interrupt to a particular processors or a group of processors, along with being able to specify interrupt priority.

    If you research you will discover that Intel has evolved the way that host side interrupts are delivered to the processors. The Pentium III(s) had a special bus called the APIC bus. Each processor, and the host bridge would share this serial bus. Interprocessor interrupts were message types on this bus, along with interrupt messages from the host bridge. One of the neat things is that the APIC in the host bridge could be configured to deliver an interrupt to all processors (actually only one would service it), but the APIC devices in each processor would arbitrate amongst themselves to determine who was best suited to service the interrupt. There are a set of registers in the Pentium III used to control this selection which are under O/S control.

    If you look at a Pentium III systems programmers manual you can see the programming details for the APIC unit in each processor. Each processor has one and it logically appears as device registers.

    Logically the APIC maintains an interrupt bit for each interrupt condition that it has accepted that it has not dispatched internally. When the processor dispatches the interrupt (i.e. it vectors through the IDT), it clears that bit which allows the APIC to accept another interrupt for that vector.

    S/W is responsible for knowing whether the corresponding interrupt was initiated by the an IO device and whether or not an EOI needs to be generated.

    There is a special APIC transaction to generate an EOI.

    I don't believe there is any interrupt priority per se with h/w generated interrupts within the processor. This is managed by s/w using interrupt priority registers defined by the Pentium III.

    Intel has continued to evolve the APIC architecture. The latest is SAPIC which preserves the programming model but gets rid of the separate serial APIC bus.

    6) Software servicing of interrupts

    The nuances of handling priority and servicing interrupts are very OS dependent. I think Jake has done a nice job of explaining some of the performance tweaks in Windows to handle the slow access times to legacy 8259 based designs.

    There are a few more details about Windows that I can add:

    Each interrupt handler at a minimum needs to get its device to stop interrupting. Ideally your device will have a device level interrupt enable/disable (separate from the interrupt mask I mentioned above). Basically the device interrupt enable/disable is a MASK on the interrupt line before it leaves the device.

    Your s/w should interrogate your device normally using a memory mapped or IO bus device access to determine if your device is interrupting (i.e. interrupt pending register is non-zero). If it is interrupting then disable the device interrupt enable for your device, schedule a DPC and return TRUE out of your interrupt handler.

    By returning TRUE when your device is interrupting, Windows will short circuit the rest of the interrupt handler(s) that are sharing the same interrupt with your device (assuming that your device is a level sensitive interrupt).

    Windows is also responsible for sending the EOI to acknowledge the interrupt to the host bridge.

    7) Common mistakes

    If your device doesn't have a device level interrupt enable/disable (separate from the interrupt mask I mentioned above), then make sure you protect changes to the interrupt mask using an interrupt spin-lock since your interrupt handler will need to modify the device interrupt mask directly.

    The much more common mistake is that you designed your interrupt handler differently than I described in the previous paragraph. You are actually trying to service conditions, pass information to your DPC, schedule multiple DPC(s), etc. You are making the game much too complicated and inefficient. If you do your job right you will only have one instance of your DPC queued/running at any time. You want your DPC to be looking at the pending interrupt conditions, writing the interrupt acknowledge register and re-enabling the device level interrupt. If you play the game this way you will avoid many of the programming pitfalls that I've seen in interrupt handling design.

    8) Live within the model

    There is no short answer to your question. It is motherboard, bus, host-bridge, BIOS, HAL, OS Version and Interrupt Handler dependent.

    As you can tell, the underlying mechanisms have evolved significantly overtime. Unfortunately though the OS(s) don't always provide us device driver writers with the additional programming interfaces to control interrupt mechanisms that may be available on the underlying h/w. The OS(s) themselves often live with the interrupt priorities and routing set up by the BIOS/HAL.

    Hopefully, in the future Windows will provide documented access methods to facilitate priority and interrupt routing. Until then live within the model, or we are doomed not to interoperate.


    Duane J. McCrory
    InfiniCon Systems






    -----Original Message-----
    From: Christiaan Ghijselinck [mailto:xxxxx@CompaqNet.be]
    Sent: Wednesday, December 11, 2002 5:30 PM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores




    Sorry Max, this is too popular. I like to see the cycle loop when the PIC
    puts the "int"
    instruction on the bus, when in the mean time other cards take the INTA#
    down. I also
    like to know the reaction of the PIC when priorities are changed and /or
    interrupts
    are masked off within the "Lazy" and "Strict" model, also when the PIC
    cannot
    push a new "int" and vector because of a cleared interrupt flag, even then
    when it
    has already been ACK'd by the processor, etc...
    Note : everything I state here is more or less an assumption until I get a
    non-popular
    description

    Christiaan


    ----- Original Message -----
    From: "Maxim S. Shatskih" <xxxxx@storagecraft.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Wednesday, December 11, 2002 10:52 PM
    Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores


    > >"Four PCI cards fire quasi at the same moment ( assume 100 ns time
    > >difference ) an interrupt. Card1 , card2 and card3 have different
    > IRQ's ,
    > >card4 shares the same IRQ with card3.
    > >I would like to see a detailled flow of all handschaking actions
    > between the
    >
    > I will omit cards1, 2, 3 and describe only cards 3 and 4.
    >
    > - card 3 starts to pull INTA# down. Note that the line is
    > open-collector.
    > - card 4 starts to pull INTA# down.
    > - this pull-down causes the PIC to interrupt the CPU.
    > - the PIC's mask is raised to this IRQ.
    > - the CPU, after possibly executing STI, starts to execute a vector
    > - the NT kernel enumerates all drivers on these vectors
    > - it calls ISR for card 3
    > - the ISR writes something to card 3, which stops it from pulling
    > INTA# down.
    > - nevertheless, INTA# is still pulled down by card 4
    > - card 3 ISR done, the NT kernel calls card 4's ISR
    > - the ISR writes something to card 4, which stops it from pulling
    > INTA# down.
    > - nobody more pulls INTA# down. It is pulled up by a resistor.
    > - PIC returns to passive (no interrupt pending) mode
    > - the NT kernel returns from the last ISR and executes IRET.
    >
    > Max
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
    > To unsubscribe send a blank email to %%email.unsub%%
    >



    ---
    You are currently subscribed to ntdev as: xxxxx@infiniconsys.com
    To unsubscribe send a blank email to %%email.unsub%%
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space