Well that sounds very much like you are not looking at the correct location
for this status register, or you are looking at the correct location and
have not interpreted the interrupt reason correctly and not done the proper
handshaking with your device to convince it to stop generating an interrupt.
The fact that when you return FALSE the system works correctly argues for
the case that you are looking at the wrong locations on the PCI bus for your
status register. You are of course talking about some register located off
of BAR0 or BAR1, right? Not some value in the config space for your device?
And you did do all the right things to obtain the NT safe ‘translated’
resource addresses, rather than using raw values, right? And finally you are
of course using the HAL API to access your device rather than using raw
pointers, right?
It is also possible that your device has malfunctioned, but as I said the
fact that when you do not process the interrupt (you return FALSE) the
system behaves normally, strongly suggests that your ISR is defective.
-----Original Message-----
From: xxxxx@yahoo.com [mailto:xxxxx@yahoo.com]
Sent: Wednesday, June 06, 2001 9:19 AM
To: NT Developers Interest List
Subject: [ntdev] RE: ISR gets called although device does not interrupt
Thanks for the quick reply. Actually initially I was reading the status
register of my device and verifying whether it is my interrupt or not. But
even then, it would always tell me that I have an interrupt although I am
sure that my device is not interrupting. ( My device is a FIFO card. It
needs to be connected to a testor which sends data to it. Only after the
FIFO is half full, it sends an interrupt. As of now, I have not connected
the testor at all).
Madhu
On 06/06/01, ““Roddy, Mark” ” wrote:
> You need to very carefully re-read the DDK manual regarding how to
> process interrupts. You only return TRUE if the interrupt is for you.
> You have to use a hardware specific mechanism to determine if the
> interrupt is for you. Testing your device extension does not help -
> that simply validates that the device object is your device object. If
> it wasn’t your device object you should bugcheck as the operating
> system is seriously compromised. As you are sharing interrupts (and
> that is very normal for PCI devices,) it is very likely that your ISR
> will be invoked a lot when the interrupt is NOT from your device. The
> OS has no idea who requested the interrupt, it just calls in turn each
> ISR linked to the same interrupt vector.
>
> Generally your hardware will have some status register that will have
> a bit that is asserted when the device has requested an interrupt.
> Like I said, this is hardware specific, I can’t tell you which
> register it is, but unless your PCI device is seriously brain-dead, it
> has such a register. Your ISR should look at this register in order to
> decide if the interrupt is for your device. If it is then you will be
> returning TRUE from your ISR, otherwise you will be returning FALSE.
>
> But wait! There’s more! If it is your interrupt, you absolutely have
> to tell your device to shut up (stop asserting an interrupt,) or you
> will just be back in your ISR again as soon as you return from it.
> That will be very bad, perhaps even evil. Once again, how you tell
> your PCI device to stop interrupting is hardware specific. Generally
> you clear one or more bits in some register or registers indicating
> that you have seen and/or processed whatever it was that caused your
> device to assert an interrupt to begin with.
>
>
> -----Original Message-----
> From: xxxxx@yahoo.com [mailto:xxxxx@yahoo.com]
> Sent: Tuesday, June 05, 2001 9:01 PM
> To: NT Developers Interest List
> Subject: [ntdev] ISR gets called although device does not interrupt
>
>
> Hi All,
>
> In my WDM for a PCI memory mapped device, I call IoConnectInterrupt as
> follows:
>
> Status = IoConnectInterrupt(&(pDevExt->pIntObj),
> (PKSERVICE_ROUTINE)FifoIsr,
> (PVOID)pDevExt,NULL,pDevExt->ulVector,
> pDevExt->IRQL,pDevExt->IRQL,
> pDevExt -> InterruptMode,
> pDevExt->bShareVector,
> pDevExt->Affinity,FALSE );
>
> Evrything goes fine, and my device is assigned interrupt 9. (In my
> machine interrupt 9 seems to be shared by all PCI devices.) Now, my
> ISR seems to get called during system boot. I do the following check
> in the ISR to check that the interrupt is indeed from my device
>
> if ( pDevExt->ulMyDriverId == MY_DRIVER_ID )
> {
> DbgPrint (“FIFO5W: pDevExt -> pMemRegs\n”);
> return TRUE ;
> }
> return FALSE;
> }
>
> The problem is that the system hangs while boot up if I am returning a
> TRUE anywhere in the ISR although my device does not issue any
> interrupt. Does anybody have an idea why this is happening ??
>
> I also tried this
>
> if ( pDevExt->ulMyDriverId == MY_DRIVER_ID )
> {
> DbgPrint (“FIFO5W: pDevExt -> pMemRegs\n”);
> return FALSE ;//unlike earler case
> }
> return FALSE;
> }
>
> Again, although my device does not issue interrupts, the ISR is called
> and enters into the if loop and prints the message. But now, the
> machine does not hang and boots properly. What mistake am I making
> ??Please guide me.
>
> Also, I seem to be getting a CmResourceTypeDevicePrivate parameter in
> IRP_MN_START_DEVICE along with CmResourceTypeMemory and
> CmResourceTypeInterrupt. How am I supposed to process it ??
>
> Thanks a lot for all help.
> Madhu
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com