Hi all,

I have a PCI device that is displaying some strange behaviour, which I
cannot seem to track down. When I put the machine into standby everything
goes as normal and the machine ends up in its low power state. I then press
the power button to bring it back up and I get the following:

XP:
My ISR gets called almost immediately and any of my calls to
READ_PORT_UCHAR() result in a delayed response of 0xFF. When I say delayed,
I mean it takes 20-25 PCI clock cycles as opposed to the normal 2.
Inspection of the hardware shows that its not generating an interrupt.
Inspection of the PCI bus shows there are no interrupts.

2K:
ISR gets called a bit later than XP, calls to READ_PORT_UCHAR() result in
valid responses, although there is still no real interrupt. Also, the
phantom interrupt will occur randomly thereafter, sometimes in small bursts
of 10-20.

Now to finish everything off, the problem remains when using a different
machine with same hardware, but disappears when moved to a completely
different machine.

For reference; I am experiencing the strange behaviour with a Dell Dimension
L800r (I've used BIOS versions A09 and A14 with the same results).

Has anyone ever run into something like this before?
Thanks, Chris

RE: Phantom Interrupt by pavel_a

pavel_a
Wed Oct 13 14:29:04 CDT 2004

Do you remember that PCI interrupts are shared, so you
can get called on somebody else's interrupt?


"Chris" wrote:
> Hi all,
>
> I have a PCI device that is displaying some strange behaviour, which I
> cannot seem to track down. When I put the machine into standby everything
> goes as normal and the machine ends up in its low power state. I then press
> the power button to bring it back up and I get the following:
>
> XP:
> My ISR gets called almost immediately and any of my calls to
> READ_PORT_UCHAR() result in a delayed response of 0xFF. When I say delayed,
> I mean it takes 20-25 PCI clock cycles as opposed to the normal 2.
> Inspection of the hardware shows that its not generating an interrupt.
> Inspection of the PCI bus shows there are no interrupts.
>
> 2K:
> ISR gets called a bit later than XP, calls to READ_PORT_UCHAR() result in
> valid responses, although there is still no real interrupt. Also, the
> phantom interrupt will occur randomly thereafter, sometimes in small bursts
> of 10-20.
>
> Now to finish everything off, the problem remains when using a different
> machine with same hardware, but disappears when moved to a completely
> different machine.
>
> For reference; I am experiencing the strange behaviour with a Dell Dimension
> L800r (I've used BIOS versions A09 and A14 with the same results).
>
> Has anyone ever run into something like this before?
> Thanks, Chris
>
>
>
>
>

Re: Phantom Interrupt by Chris

Chris
Wed Oct 13 16:35:28 CDT 2004

Yes, but why does it only occur after the machine is put into standby.
Interrupts not beloning to me never show up before a standby cycle.
Could it be that interrupts are being re-shuffled after a standby?

Thanks, Chris

"Pavel A." <pavel_a@geeklife.com> wrote in message
news:873FF431-D108-461A-92B6-3811857B3229@microsoft.com...
> Do you remember that PCI interrupts are shared, so you
> can get called on somebody else's interrupt?
>
>
> "Chris" wrote:
>> Hi all,
>>
>> I have a PCI device that is displaying some strange behaviour, which I
>> cannot seem to track down. When I put the machine into standby
>> everything
>> goes as normal and the machine ends up in its low power state. I then
>> press
>> the power button to bring it back up and I get the following:
>>
>> XP:
>> My ISR gets called almost immediately and any of my calls to
>> READ_PORT_UCHAR() result in a delayed response of 0xFF. When I say
>> delayed,
>> I mean it takes 20-25 PCI clock cycles as opposed to the normal 2.
>> Inspection of the hardware shows that its not generating an interrupt.
>> Inspection of the PCI bus shows there are no interrupts.
>>
>> 2K:
>> ISR gets called a bit later than XP, calls to READ_PORT_UCHAR() result in
>> valid responses, although there is still no real interrupt. Also, the
>> phantom interrupt will occur randomly thereafter, sometimes in small
>> bursts
>> of 10-20.
>>
>> Now to finish everything off, the problem remains when using a different
>> machine with same hardware, but disappears when moved to a completely
>> different machine.
>>
>> For reference; I am experiencing the strange behaviour with a Dell
>> Dimension
>> L800r (I've used BIOS versions A09 and A14 with the same results).
>>
>> Has anyone ever run into something like this before?
>> Thanks, Chris
>>
>>
>>
>>
>>



Re: Phantom Interrupt by Alexander

Alexander
Wed Oct 13 21:15:22 CDT 2004

On low power transition, you're supposed to disconnect your interrupt (make
sure to disable your device interrupts). You can only reconnect the
interrupt on return from D0 power IRP. You cannot touch your device
registers before PCI PDO handled D0 power IRP, because the device may not be
powered yet, or PCI bridge is not reinitialized yet.

"Chris" <cdore.connecttech.com> wrote in message
news:uj2PTyWsEHA.1272@TK2MSFTNGP12.phx.gbl...
> Yes, but why does it only occur after the machine is put into standby.
> Interrupts not beloning to me never show up before a standby cycle.
> Could it be that interrupts are being re-shuffled after a standby?
>
> Thanks, Chris
>
> "Pavel A." <pavel_a@geeklife.com> wrote in message
> news:873FF431-D108-461A-92B6-3811857B3229@microsoft.com...
>> Do you remember that PCI interrupts are shared, so you
>> can get called on somebody else's interrupt?
>>
>>
>> "Chris" wrote:
>>> Hi all,
>>>
>>> I have a PCI device that is displaying some strange behaviour, which I
>>> cannot seem to track down. When I put the machine into standby
>>> everything
>>> goes as normal and the machine ends up in its low power state. I then
>>> press
>>> the power button to bring it back up and I get the following:
>>>
>>> XP:
>>> My ISR gets called almost immediately and any of my calls to
>>> READ_PORT_UCHAR() result in a delayed response of 0xFF. When I say
>>> delayed,
>>> I mean it takes 20-25 PCI clock cycles as opposed to the normal 2.
>>> Inspection of the hardware shows that its not generating an interrupt.
>>> Inspection of the PCI bus shows there are no interrupts.
>>>
>>> 2K:
>>> ISR gets called a bit later than XP, calls to READ_PORT_UCHAR() result
>>> in
>>> valid responses, although there is still no real interrupt. Also, the
>>> phantom interrupt will occur randomly thereafter, sometimes in small
>>> bursts
>>> of 10-20.
>>>
>>> Now to finish everything off, the problem remains when using a different
>>> machine with same hardware, but disappears when moved to a completely
>>> different machine.
>>>
>>> For reference; I am experiencing the strange behaviour with a Dell
>>> Dimension
>>> L800r (I've used BIOS versions A09 and A14 with the same results).
>>>
>>> Has anyone ever run into something like this before?
>>> Thanks, Chris
>>>
>>>
>>>
>>>
>>>
>
>



Re: Phantom Interrupt by Maxim

Maxim
Thu Oct 14 05:27:19 CDT 2004

From what I know, disconnecting the interrupt handler is not necessary, but
disabling the interrupts at hardware level by resetting the "interrupt enable"
bit in the device register is really necessary.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:uz6YpOZsEHA.2128@TK2MSFTNGP11.phx.gbl...
> On low power transition, you're supposed to disconnect your interrupt (make
> sure to disable your device interrupts). You can only reconnect the
> interrupt on return from D0 power IRP. You cannot touch your device
> registers before PCI PDO handled D0 power IRP, because the device may not be
> powered yet, or PCI bridge is not reinitialized yet.
>
> "Chris" <cdore.connecttech.com> wrote in message
> news:uj2PTyWsEHA.1272@TK2MSFTNGP12.phx.gbl...
> > Yes, but why does it only occur after the machine is put into standby.
> > Interrupts not beloning to me never show up before a standby cycle.
> > Could it be that interrupts are being re-shuffled after a standby?
> >
> > Thanks, Chris
> >
> > "Pavel A." <pavel_a@geeklife.com> wrote in message
> > news:873FF431-D108-461A-92B6-3811857B3229@microsoft.com...
> >> Do you remember that PCI interrupts are shared, so you
> >> can get called on somebody else's interrupt?
> >>
> >>
> >> "Chris" wrote:
> >>> Hi all,
> >>>
> >>> I have a PCI device that is displaying some strange behaviour, which I
> >>> cannot seem to track down. When I put the machine into standby
> >>> everything
> >>> goes as normal and the machine ends up in its low power state. I then
> >>> press
> >>> the power button to bring it back up and I get the following:
> >>>
> >>> XP:
> >>> My ISR gets called almost immediately and any of my calls to
> >>> READ_PORT_UCHAR() result in a delayed response of 0xFF. When I say
> >>> delayed,
> >>> I mean it takes 20-25 PCI clock cycles as opposed to the normal 2.
> >>> Inspection of the hardware shows that its not generating an interrupt.
> >>> Inspection of the PCI bus shows there are no interrupts.
> >>>
> >>> 2K:
> >>> ISR gets called a bit later than XP, calls to READ_PORT_UCHAR() result
> >>> in
> >>> valid responses, although there is still no real interrupt. Also, the
> >>> phantom interrupt will occur randomly thereafter, sometimes in small
> >>> bursts
> >>> of 10-20.
> >>>
> >>> Now to finish everything off, the problem remains when using a different
> >>> machine with same hardware, but disappears when moved to a completely
> >>> different machine.
> >>>
> >>> For reference; I am experiencing the strange behaviour with a Dell
> >>> Dimension
> >>> L800r (I've used BIOS versions A09 and A14 with the same results).
> >>>
> >>> Has anyone ever run into something like this before?
> >>> Thanks, Chris
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
>
>



Re: Phantom Interrupt by Peter

Peter
Thu Oct 14 13:45:01 CDT 2004

even if disconnecting your interrupt isn't necessary, reading from your
hardware before it's gotten back into the D0 state is. Since your ISR can't
check the hardware to dismiss the interrupt, you may as well disconnect it.

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:OUiO2fdsEHA.3572@tk2msftngp13.phx.gbl...
> From what I know, disconnecting the interrupt handler is not necessary,
> but
> disabling the interrupts at hardware level by resetting the "interrupt
> enable"
> bit in the device register is really necessary.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:uz6YpOZsEHA.2128@TK2MSFTNGP11.phx.gbl...
>> On low power transition, you're supposed to disconnect your interrupt
>> (make
>> sure to disable your device interrupts). You can only reconnect the
>> interrupt on return from D0 power IRP. You cannot touch your device
>> registers before PCI PDO handled D0 power IRP, because the device may not
>> be
>> powered yet, or PCI bridge is not reinitialized yet.
>>
>> "Chris" <cdore.connecttech.com> wrote in message
>> news:uj2PTyWsEHA.1272@TK2MSFTNGP12.phx.gbl...
>> > Yes, but why does it only occur after the machine is put into standby.
>> > Interrupts not beloning to me never show up before a standby cycle.
>> > Could it be that interrupts are being re-shuffled after a standby?
>> >
>> > Thanks, Chris
>> >
>> > "Pavel A." <pavel_a@geeklife.com> wrote in message
>> > news:873FF431-D108-461A-92B6-3811857B3229@microsoft.com...
>> >> Do you remember that PCI interrupts are shared, so you
>> >> can get called on somebody else's interrupt?
>> >>
>> >>
>> >> "Chris" wrote:
>> >>> Hi all,
>> >>>
>> >>> I have a PCI device that is displaying some strange behaviour, which
>> >>> I
>> >>> cannot seem to track down. When I put the machine into standby
>> >>> everything
>> >>> goes as normal and the machine ends up in its low power state. I
>> >>> then
>> >>> press
>> >>> the power button to bring it back up and I get the following:
>> >>>
>> >>> XP:
>> >>> My ISR gets called almost immediately and any of my calls to
>> >>> READ_PORT_UCHAR() result in a delayed response of 0xFF. When I say
>> >>> delayed,
>> >>> I mean it takes 20-25 PCI clock cycles as opposed to the normal 2.
>> >>> Inspection of the hardware shows that its not generating an
>> >>> interrupt.
>> >>> Inspection of the PCI bus shows there are no interrupts.
>> >>>
>> >>> 2K:
>> >>> ISR gets called a bit later than XP, calls to READ_PORT_UCHAR()
>> >>> result
>> >>> in
>> >>> valid responses, although there is still no real interrupt. Also,
>> >>> the
>> >>> phantom interrupt will occur randomly thereafter, sometimes in small
>> >>> bursts
>> >>> of 10-20.
>> >>>
>> >>> Now to finish everything off, the problem remains when using a
>> >>> different
>> >>> machine with same hardware, but disappears when moved to a completely
>> >>> different machine.
>> >>>
>> >>> For reference; I am experiencing the strange behaviour with a Dell
>> >>> Dimension
>> >>> L800r (I've used BIOS versions A09 and A14 with the same results).
>> >>>
>> >>> Has anyone ever run into something like this before?
>> >>> Thanks, Chris
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >
>> >
>>
>>
>
>



Re: Phantom Interrupt by pavel_a

pavel_a
Thu Oct 14 15:15:45 CDT 2004

Since PCI interrupts are usually shared, and you take care
of disabling IRQ on the device, disconnecting interrupt does not
really make sense.
The OP can set a flag when he disables the device interrupt.
In the ISR, if this flag is set - immediately return false.

--PA

"Peter Wieland [MSFT]" wrote:
> even if disconnecting your interrupt isn't necessary, reading from your
> hardware before it's gotten back into the D0 state is. Since your ISR can't
> check the hardware to dismiss the interrupt, you may as well disconnect it.
>
> -p
>
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:OUiO2fdsEHA.3572@tk2msftngp13.phx.gbl...
> > From what I know, disconnecting the interrupt handler is not necessary,
> > but
> > disabling the interrupts at hardware level by resetting the "interrupt
> > enable"
> > bit in the device register is really necessary.
> >
> > --
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > maxim@storagecraft.com
> > http://www.storagecraft.com
> >
> > "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> > news:uz6YpOZsEHA.2128@TK2MSFTNGP11.phx.gbl...
> >> On low power transition, you're supposed to disconnect your interrupt
> >> (make
> >> sure to disable your device interrupts). You can only reconnect the
> >> interrupt on return from D0 power IRP. You cannot touch your device
> >> registers before PCI PDO handled D0 power IRP, because the device may not
> >> be
> >> powered yet, or PCI bridge is not reinitialized yet.
> >>
> >> "Chris" <cdore.connecttech.com> wrote in message
> >> news:uj2PTyWsEHA.1272@TK2MSFTNGP12.phx.gbl...
> >> > Yes, but why does it only occur after the machine is put into standby.
> >> > Interrupts not beloning to me never show up before a standby cycle.
> >> > Could it be that interrupts are being re-shuffled after a standby?
> >> >
> >> > Thanks, Chris
> >> >
> >> > "Pavel A." <pavel_a@geeklife.com> wrote in message
> >> > news:873FF431-D108-461A-92B6-3811857B3229@microsoft.com...
> >> >> Do you remember that PCI interrupts are shared, so you
> >> >> can get called on somebody else's interrupt?
> >> >>
> >> >>
> >> >> "Chris" wrote:
> >> >>> Hi all,
> >> >>>
> >> >>> I have a PCI device that is displaying some strange behaviour, which
> >> >>> I
> >> >>> cannot seem to track down. When I put the machine into standby
> >> >>> everything
> >> >>> goes as normal and the machine ends up in its low power state. I
> >> >>> then
> >> >>> press
> >> >>> the power button to bring it back up and I get the following:
> >> >>>
> >> >>> XP:
> >> >>> My ISR gets called almost immediately and any of my calls to
> >> >>> READ_PORT_UCHAR() result in a delayed response of 0xFF. When I say
> >> >>> delayed,
> >> >>> I mean it takes 20-25 PCI clock cycles as opposed to the normal 2.
> >> >>> Inspection of the hardware shows that its not generating an
> >> >>> interrupt.
> >> >>> Inspection of the PCI bus shows there are no interrupts.
> >> >>>
> >> >>> 2K:
> >> >>> ISR gets called a bit later than XP, calls to READ_PORT_UCHAR()
> >> >>> result
> >> >>> in
> >> >>> valid responses, although there is still no real interrupt. Also,
> >> >>> the
> >> >>> phantom interrupt will occur randomly thereafter, sometimes in small
> >> >>> bursts
> >> >>> of 10-20.
> >> >>>
> >> >>> Now to finish everything off, the problem remains when using a
> >> >>> different
> >> >>> machine with same hardware, but disappears when moved to a completely
> >> >>> different machine.
> >> >>>
> >> >>> For reference; I am experiencing the strange behaviour with a Dell
> >> >>> Dimension
> >> >>> L800r (I've used BIOS versions A09 and A14 with the same results).
> >> >>>
> >> >>> Has anyone ever run into something like this before?
> >> >>> Thanks, Chris
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >
> >> >
> >>
> >>
> >
> >
>
>
>

Re: Phantom Interrupt by Chris

Chris
Thu Oct 14 16:02:03 CDT 2004

Interrupts are being disabled on the device, but what I had never run into
before (like I originally said, it only happens on one of my machines here)
was having my ISR called before receiving any power IRPs.

For now I've added a check to the ISR that looks for errant cases. I'm
investigating the interrupt disconnect and perhaps will use it instead.

Thanks for your help,
Chris


"Pavel A." <pavel_a@geeklife.com> wrote in message
news:A77A145D-DFA9-4898-ABD0-42127B73FCDB@microsoft.com...
> Since PCI interrupts are usually shared, and you take care
> of disabling IRQ on the device, disconnecting interrupt does not
> really make sense.
> The OP can set a flag when he disables the device interrupt.
> In the ISR, if this flag is set - immediately return false.
>
> --PA
>
> "Peter Wieland [MSFT]" wrote:
>> even if disconnecting your interrupt isn't necessary, reading from your
>> hardware before it's gotten back into the D0 state is. Since your ISR
>> can't
>> check the hardware to dismiss the interrupt, you may as well disconnect
>> it.
>>
>> -p
>>
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
>> news:OUiO2fdsEHA.3572@tk2msftngp13.phx.gbl...
>> > From what I know, disconnecting the interrupt handler is not
>> > necessary,
>> > but
>> > disabling the interrupts at hardware level by resetting the "interrupt
>> > enable"
>> > bit in the device register is really necessary.
>> >
>> > --
>> > Maxim Shatskih, Windows DDK MVP
>> > StorageCraft Corporation
>> > maxim@storagecraft.com
>> > http://www.storagecraft.com
>> >
>> > "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
>> > news:uz6YpOZsEHA.2128@TK2MSFTNGP11.phx.gbl...
>> >> On low power transition, you're supposed to disconnect your interrupt
>> >> (make
>> >> sure to disable your device interrupts). You can only reconnect the
>> >> interrupt on return from D0 power IRP. You cannot touch your device
>> >> registers before PCI PDO handled D0 power IRP, because the device may
>> >> not
>> >> be
>> >> powered yet, or PCI bridge is not reinitialized yet.
>> >>
>> >> "Chris" <cdore.connecttech.com> wrote in message
>> >> news:uj2PTyWsEHA.1272@TK2MSFTNGP12.phx.gbl...
>> >> > Yes, but why does it only occur after the machine is put into
>> >> > standby.
>> >> > Interrupts not beloning to me never show up before a standby cycle.
>> >> > Could it be that interrupts are being re-shuffled after a standby?
>> >> >
>> >> > Thanks, Chris
>> >> >
>> >> > "Pavel A." <pavel_a@geeklife.com> wrote in message
>> >> > news:873FF431-D108-461A-92B6-3811857B3229@microsoft.com...
>> >> >> Do you remember that PCI interrupts are shared, so you
>> >> >> can get called on somebody else's interrupt?
>> >> >>
>> >> >>
>> >> >> "Chris" wrote:
>> >> >>> Hi all,
>> >> >>>
>> >> >>> I have a PCI device that is displaying some strange behaviour,
>> >> >>> which
>> >> >>> I
>> >> >>> cannot seem to track down. When I put the machine into standby
>> >> >>> everything
>> >> >>> goes as normal and the machine ends up in its low power state. I
>> >> >>> then
>> >> >>> press
>> >> >>> the power button to bring it back up and I get the following:
>> >> >>>
>> >> >>> XP:
>> >> >>> My ISR gets called almost immediately and any of my calls to
>> >> >>> READ_PORT_UCHAR() result in a delayed response of 0xFF. When I
>> >> >>> say
>> >> >>> delayed,
>> >> >>> I mean it takes 20-25 PCI clock cycles as opposed to the normal 2.
>> >> >>> Inspection of the hardware shows that its not generating an
>> >> >>> interrupt.
>> >> >>> Inspection of the PCI bus shows there are no interrupts.
>> >> >>>
>> >> >>> 2K:
>> >> >>> ISR gets called a bit later than XP, calls to READ_PORT_UCHAR()
>> >> >>> result
>> >> >>> in
>> >> >>> valid responses, although there is still no real interrupt. Also,
>> >> >>> the
>> >> >>> phantom interrupt will occur randomly thereafter, sometimes in
>> >> >>> small
>> >> >>> bursts
>> >> >>> of 10-20.
>> >> >>>
>> >> >>> Now to finish everything off, the problem remains when using a
>> >> >>> different
>> >> >>> machine with same hardware, but disappears when moved to a
>> >> >>> completely
>> >> >>> different machine.
>> >> >>>
>> >> >>> For reference; I am experiencing the strange behaviour with a Dell
>> >> >>> Dimension
>> >> >>> L800r (I've used BIOS versions A09 and A14 with the same results).
>> >> >>>
>> >> >>> Has anyone ever run into something like this before?
>> >> >>> Thanks, Chris
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>>



Re: Phantom Interrupt by Alexander

Alexander
Thu Oct 14 16:06:59 CDT 2004

It was mentioned on this forum by MS guy, that for APIC to be switched to
low power, all interrupts should be disconnected.

Make sure, though, to avoid KeSynchronizeExecution intil the interrupt is
reconnected. EHCI.SYS driver used to have such a race condition; I was
bitten by it.

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:OUiO2fdsEHA.3572@tk2msftngp13.phx.gbl...
> From what I know, disconnecting the interrupt handler is not necessary,
> but
> disabling the interrupts at hardware level by resetting the "interrupt
> enable"
> bit in the device register is really necessary.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:uz6YpOZsEHA.2128@TK2MSFTNGP11.phx.gbl...
>> On low power transition, you're supposed to disconnect your interrupt
>> (make
>> sure to disable your device interrupts). You can only reconnect the
>> interrupt on return from D0 power IRP. You cannot touch your device
>> registers before PCI PDO handled D0 power IRP, because the device may not
>> be
>> powered yet, or PCI bridge is not reinitialized yet.
>>
>> "Chris" <cdore.connecttech.com> wrote in message
>> news:uj2PTyWsEHA.1272@TK2MSFTNGP12.phx.gbl...
>> > Yes, but why does it only occur after the machine is put into standby.
>> > Interrupts not beloning to me never show up before a standby cycle.
>> > Could it be that interrupts are being re-shuffled after a standby?
>> >
>> > Thanks, Chris
>> >
>> > "Pavel A." <pavel_a@geeklife.com> wrote in message
>> > news:873FF431-D108-461A-92B6-3811857B3229@microsoft.com...
>> >> Do you remember that PCI interrupts are shared, so you
>> >> can get called on somebody else's interrupt?
>> >>
>> >>
>> >> "Chris" wrote:
>> >>> Hi all,
>> >>>
>> >>> I have a PCI device that is displaying some strange behaviour, which
>> >>> I
>> >>> cannot seem to track down. When I put the machine into standby
>> >>> everything
>> >>> goes as normal and the machine ends up in its low power state. I
>> >>> then
>> >>> press
>> >>> the power button to bring it back up and I get the following:
>> >>>
>> >>> XP:
>> >>> My ISR gets called almost immediately and any of my calls to
>> >>> READ_PORT_UCHAR() result in a delayed response of 0xFF. When I say
>> >>> delayed,
>> >>> I mean it takes 20-25 PCI clock cycles as opposed to the normal 2.
>> >>> Inspection of the hardware shows that its not generating an
>> >>> interrupt.
>> >>> Inspection of the PCI bus shows there are no interrupts.
>> >>>
>> >>> 2K:
>> >>> ISR gets called a bit later than XP, calls to READ_PORT_UCHAR()
>> >>> result
>> >>> in
>> >>> valid responses, although there is still no real interrupt. Also,
>> >>> the
>> >>> phantom interrupt will occur randomly thereafter, sometimes in small
>> >>> bursts
>> >>> of 10-20.
>> >>>
>> >>> Now to finish everything off, the problem remains when using a
>> >>> different
>> >>> machine with same hardware, but disappears when moved to a completely
>> >>> different machine.
>> >>>
>> >>> For reference; I am experiencing the strange behaviour with a Dell
>> >>> Dimension
>> >>> L800r (I've used BIOS versions A09 and A14 with the same results).
>> >>>
>> >>> Has anyone ever run into something like this before?
>> >>> Thanks, Chris
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >
>> >
>>
>>
>
>



Re: Phantom Interrupt by Pavel

Pavel
Thu Oct 14 21:15:14 CDT 2004

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message news:uBmx$GjsEHA.3876@TK2MSFTNGP15.phx.gbl...
> It was mentioned on this forum by MS guy, that for APIC to be switched to
> low power, all interrupts should be disconnected.
>
> Make sure, though, to avoid KeSynchronizeExecution intil the interrupt is
> reconnected. EHCI.SYS driver used to have such a race condition; I was
> bitten by it.

So it is just another reason not to disconnect / reconnect interrupt and use a flag instead.
Does APIC use so much power to justify switching it off?
--
PA



Re: Phantom Interrupt by Alexander

Alexander
Fri Oct 15 21:28:49 CDT 2004

Powering down APIC may be a part of bigger scheme, and inability to do that
may disable some other useful PM feature, fir example, suspend to RAM.

"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:OGwaD2lsEHA.2948@TK2MSFTNGP12.phx.gbl...
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:uBmx$GjsEHA.3876@TK2MSFTNGP15.phx.gbl...
>> It was mentioned on this forum by MS guy, that for APIC to be switched to
>> low power, all interrupts should be disconnected.
>>
>> Make sure, though, to avoid KeSynchronizeExecution intil the interrupt is
>> reconnected. EHCI.SYS driver used to have such a race condition; I was
>> bitten by it.
>
> So it is just another reason not to disconnect / reconnect interrupt and
> use a flag instead.
> Does APIC use so much power to justify switching it off?
> --
> PA
>
>