>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
> 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
> 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”
To: “NT Developers Interest List”
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”
To: “NT Developers Interest List”
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%%
>
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.
“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 ----
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%%
>
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%%
>
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%%
>"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.
Max
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”
To: “NT Developers Interest List”
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”
> > 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%%
>
>
>
> —
> 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”
To: “NT Developers Interest List”
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%%
>
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”
> 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
> > 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”
To: “NT Developers Interest List”
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%%
>
> 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”
To: “NT Developers Interest List”
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%%
>