Hello All,
I am looking at the MiniportISR and MiniportHandleInterrupt routines in
the e100 Ethernet NDIS sample driver. It seems like the generic flow of
the HandleInterrupt routine is as follow
MiniportHandleInterrupt
{
// 1. read and acknowledge interrupts - by writing back what was
read and clearing out the bits
// 2. process various interrupts depending on which bits are set.
// 3. finally re-enable interrupt mask
return;
}
Based on the above routine, isn’t there a case of missed a interrupt
here? For instance, if a frame is received in step 1 between when the
status is read and the status is written back to ack the interrupts. The
receive handler looks at a status field in each descriptor to see if the
descriptor is complete. The missed interrupt happens if we read the
descriptor before it is completely flushed to host memory (DMA). In this
case we’ll stop processing the frame but will not see another interrupt
because we just cleared our interrupt status earlier. I realize that it
is a really small window and I am assuming too many things, but can this
happen? How are missed interrupts handled? Or do we simply rely on the
fact that additional receives will keep things moving and missed
interrupts like this are okay?
Thanks
Ravi
Murty, Ravi wrote:
Hello All,
I am looking at the MiniportISR and MiniportHandleInterrupt routines
in the e100 Ethernet NDIS sample driver. It seems like the generic
flow of the HandleInterrupt routine is as follow
MiniportHandleInterrupt
{
// 1. read and acknowledge interrupts – by writing back what was read
and clearing out the bits
// 2. process various interrupts depending on which bits are set.
// 3. finally re-enable interrupt mask
return;
}
Based on the above routine, isn’t there a case of missed a interrupt
here? For instance, if a frame is received in step 1 between when the
status is read and the status is written back to ack the interrupts.
The receive handler looks at a status field in each descriptor to see
if the descriptor is complete. The missed interrupt happens if we read
the descriptor before it is completely flushed to host memory (DMA).
In this case we’ll stop processing the frame but will not see another
interrupt because we just cleared our interrupt status earlier. I
realize that it is a really small window and I am assuming too many
things, but can this happen? How are missed interrupts handled? Or do
we simply rely on the fact that additional receives will keep things
moving and missed interrupts like this are okay?
For this to happen, the interrupt would have to fire before the packet
were completely written to memory. I don’t know the E100 hardware, but I
would consider that a serious design flaw. As long as the interrupt only
occurs when the DMA transfer is complete, there is no way to lose an
interrupt. Even if we do handle an interrupt in mid-transfer, another
interrupt will occur when the transfer completes. It will fire as soon
as we re-enable the interrupts.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
i’m sure someone will answer about how the e100 part works.
my experience with other controllers is that you usually acknowlege the
interrupt by setting the bit for that interrupt. If you were to read
out 0x6 you would write back 0x6. If the interrupt for flag 0x1 becomes
active in the interval you’d still only be clearing condition flags 2 &
4. The controller would keep the interrupt line active and you’d get
another interrupt when the first ISR returns.
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Murty, Ravi
Sent: Wednesday, May 18, 2005 11:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Missing Interrupts
Hello All,
I am looking at the MiniportISR and MiniportHandleInterrupt
routines in the e100 Ethernet NDIS sample driver. It seems like the
generic flow of the HandleInterrupt routine is as follow
MiniportHandleInterrupt
{
// 1. read and acknowledge interrupts - by writing back what
was read and clearing out the bits
// 2. process various interrupts depending on which bits
are set.
// 3. finally re-enable interrupt mask
return;
}
Based on the above routine, isn’t there a case of missed a
interrupt here? For instance, if a frame is received in step 1 between
when the status is read and the status is written back to ack the
interrupts. The receive handler looks at a status field in each
descriptor to see if the descriptor is complete. The missed interrupt
happens if we read the descriptor before it is completely flushed to
host memory (DMA). In this case we’ll stop processing the frame but will
not see another interrupt because we just cleared our interrupt status
earlier. I realize that it is a really small window and I am assuming
too many things, but can this happen? How are missed interrupts handled?
Or do we simply rely on the fact that additional receives will keep
things moving and missed interrupts like this are okay?
Thanks
Ravi
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
Tim,
Here’s something I found in the PCI specification and this is what I was
thinking of earlier. Now, reading the intr_status register should flush
the data written to host memory, but in the case I mentioned - recv
happening after the read but before the write is bad.
Some systems may not guarantee that data is delivered to main memory
before interrupts are
delivered to the CPU. If not handled properly, this can lead to data
consistency problems
(loss of data). This situation is most often associated with the
implementation of posting
buffers in bridges between the PCI bus and other buses.
There are three ways that data and interrupt consistency can be
guaranteed:
1. The system hardware can guarantee that posting buffers are flushed
before interrupts are
delivered to the processor.
2. The device signaling the interrupt can perform a read of the
just-written data before
signaling the interrupt. This causes posting buffers to be flushed.
3. The device driver can perform a read to any register in the device
before accessing the
data written by the device. This read causes posting buffers to be
flushed.
Device drivers are ultimately responsible for guaranteeing consistency
of interrupts and data
by assuring that at least one of the three methods described above is
performed in the
system. This means a device driver must do Method 3 unless it implicitly
knows Method 2 is
done by its device, or it is informed (by some means outside the scope
of this specification)
that Method 1 is done by the system hardware.
Thanks
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, May 18, 2005 11:57 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Missing Interrupts
Murty, Ravi wrote:
> Hello All,
>
> I am looking at the MiniportISR and MiniportHandleInterrupt routines
> in the e100 Ethernet NDIS sample driver. It seems like the generic
> flow of the HandleInterrupt routine is as follow
>
> MiniportHandleInterrupt
> {
>
> // 1. read and acknowledge interrupts - by writing back what was read
> and clearing out the bits
>
> // 2. process various interrupts depending on which bits are set.
>
> // 3. finally re-enable interrupt mask
>
> return;
> }
>
> Based on the above routine, isn’t there a case of missed a interrupt
> here? For instance, if a frame is received in step 1 between when the
> status is read and the status is written back to ack the interrupts.
> The receive handler looks at a status field in each descriptor to see
> if the descriptor is complete. The missed interrupt happens if we read
> the descriptor before it is completely flushed to host memory (DMA).
> In this case we’ll stop processing the frame but will not see another
> interrupt because we just cleared our interrupt status earlier. I
> realize that it is a really small window and I am assuming too many
> things, but can this happen? How are missed interrupts handled? Or do
> we simply rely on the fact that additional receives will keep things
> moving and missed interrupts like this are okay?
>
For this to happen, the interrupt would have to fire before the packet
were completely written to memory. I don’t know the E100 hardware, but I
would consider that a serious design flaw. As long as the interrupt only
occurs when the DMA transfer is complete, there is no way to lose an
interrupt. Even if we do handle an interrupt in mid-transfer, another
interrupt will occur when the transfer completes. It will fire as soon
as we re-enable the interrupts.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
No it isn’t bad. The interrupt status bit is set if and only if the data is
available. If the bit is set after your driver reads the status register,
the bit will not be reset by the write (unless you screw up) and a new
interrupt will be generated when your isr exits. Your excerpt from the pci
spec is talking about a different issue: flushing the bridge post buffers so
that host memory actually contains the data that the interrupt signaled was
available, and that is guaranteed by the register read for the interrupt
status bits.
=====================
Mark Roddy
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Murty, Ravi
Sent: Wednesday, May 18, 2005 4:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Missing Interrupts
Tim,
Here’s something I found in the PCI specification and this is what I was
thinking of earlier. Now, reading the intr_status register should flush the
data written to host memory, but in the case I mentioned - recv happening
after the read but before the write is bad.
Some systems may not guarantee that data is delivered to main memory before
interrupts are delivered to the CPU. If not handled properly, this can lead
to data consistency problems (loss of data). This situation is most often
associated with the implementation of posting buffers in bridges between the
PCI bus and other buses.
There are three ways that data and interrupt consistency can be
guaranteed:
1. The system hardware can guarantee that posting buffers are flushed before
interrupts are delivered to the processor.
2. The device signaling the interrupt can perform a read of the just-written
data before signaling the interrupt. This causes posting buffers to be
flushed.
3. The device driver can perform a read to any register in the device before
accessing the data written by the device. This read causes posting buffers
to be flushed.
Device drivers are ultimately responsible for guaranteeing consistency of
interrupts and data by assuring that at least one of the three methods
described above is performed in the system. This means a device driver must
do Method 3 unless it implicitly knows Method 2 is done by its device, or it
is informed (by some means outside the scope of this specification) that
Method 1 is done by the system hardware.
Thanks
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, May 18, 2005 11:57 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Missing Interrupts
Murty, Ravi wrote:
> Hello All,
>
> I am looking at the MiniportISR and MiniportHandleInterrupt routines
> in the e100 Ethernet NDIS sample driver. It seems like the generic
> flow of the HandleInterrupt routine is as follow
>
> MiniportHandleInterrupt
> {
>
> // 1. read and acknowledge interrupts - by writing back what was read
> and clearing out the bits
>
> // 2. process various interrupts depending on which bits are set.
>
> // 3. finally re-enable interrupt mask
>
> return;
> }
>
> Based on the above routine, isn’t there a case of missed a interrupt
> here? For instance, if a frame is received in step 1 between when the
> status is read and the status is written back to ack the interrupts.
> The receive handler looks at a status field in each descriptor to see
> if the descriptor is complete. The missed interrupt happens if we read
> the descriptor before it is completely flushed to host memory (DMA).
> In this case we’ll stop processing the frame but will not see another
> interrupt because we just cleared our interrupt status earlier. I
> realize that it is a really small window and I am assuming too many
> things, but can this happen? How are missed interrupts handled? Or do
> we simply rely on the fact that additional receives will keep things
> moving and missed interrupts like this are okay?
>
For this to happen, the interrupt would have to fire before the packet were
completely written to memory. I don’t know the E100 hardware, but I
would consider that a serious design flaw. As long as the interrupt only
occurs when the DMA transfer is complete, there is no way to lose an
interrupt. Even if we do handle an interrupt in mid-transfer, another
interrupt will occur when the transfer completes. It will fire as soon as we
re-enable the interrupts.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Murty, Ravi wrote:
Tim,
Here’s something I found in the PCI specification and this is what I was
thinking of earlier. Now, reading the intr_status register should flush
the data written to host memory, but in the case I mentioned - recv
happening after the read but before the write is bad.
I think you’re worrying over nothing. Look at NIC_ACK_INTERRUPT, which
is used to clear the pending interrupts. It is a read/modify/write
operation. Thus, you are looking at a window of perhaps 3 CPU cycles.
Considering that one single PCI clock period takes approximately 100
cycles on a 3GHz CPU, it is impossible that a data write AND another
interrupt could slip in between there.
Further, the code in the e100bex sample disables interrupts in the
hardware (NICDisableInterrupt) before clearing the interrupt status. As
I said, I don’t know the E100 hardware, but one would hope that
disabling interrupts would actually result in interrupts being deferred
until they are re-enabled.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hmm… I thought these read and writes were actually going down to the
device? Reads and Writes to Adapter->CSRAddress
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, May 18, 2005 2:00 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Missing Interrupts
Murty, Ravi wrote:
Tim,
Here’s something I found in the PCI specification and this is what I
was
thinking of earlier. Now, reading the intr_status register should flush
the data written to host memory, but in the case I mentioned - recv
happening after the read but before the write is bad.
I think you’re worrying over nothing. Look at NIC_ACK_INTERRUPT, which
is used to clear the pending interrupts. It is a read/modify/write
operation. Thus, you are looking at a window of perhaps 3 CPU cycles.
Considering that one single PCI clock period takes approximately 100
cycles on a 3GHz CPU, it is impossible that a data write AND another
interrupt could slip in between there.
Further, the code in the e100bex sample disables interrupts in the
hardware (NICDisableInterrupt) before clearing the interrupt status. As
I said, I don’t know the E100 hardware, but one would hope that
disabling interrupts would actually result in interrupts being deferred
until they are re-enabled.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Murty, Ravi wrote:
Hmm… I thought these read and writes were actually going down to the
device? Reads and Writes to Adapter->CSRAddress
OK, so I tried to slip in a fast one here. It won’t take 3 cycles,
because it has to talk to the bus.
Yes, the read/modify/write will involve a register on the device. As
far as the device can tell, the write will happen IMMEDIATELY after the
read. I still think there is no problem here.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
There is no window. If the data available bit is not set when he reads it,
the device will generate another interrupt (actually it will keep interrupt
asserted) and when he exits his isr it will get re-invoked.
=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, May 18, 2005 7:46 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Missing Interrupts
Murty, Ravi wrote:
>Hmm… I thought these read and writes were actually going
down to the
>device? Reads and Writes to Adapter->CSRAddress
>
>
OK, so I tried to slip in a fast one here. It won’t take 3
cycles, because it has to talk to the bus.
Yes, the read/modify/write will involve a register on the
device. As far as the device can tell, the write will happen
IMMEDIATELY after the read. I still think there is no problem here.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@hollistech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com