From the DDK documentation, title "Registering an Isr":

To register an ISR, a driver's DispatchPnP routine must call
IoConnectInterrupt when it receives an IRP_MN_START_DEVICE request. In
response, the I/O Manager creates an interrupt object for each processor that
the device can interrupt.

In a previous thread, I had gotten several suggestions about which parameter
to IoConnectInterrupt was causing it to fail with STATUS_INVALID_PARAMETER,
but none of them helped. The code worked OK on single processor systems. If
the affinity argument (extracted from the translated resource list in the
start device IRP) indicates that more than one processor can be interrupted,
how does the I/O manager return a pointer to multiple interrupt objects?

Is there some special coding to connect an interrupt on a multi-processor
machine? The DDK documentation seems to have little to say about this.

Re: IoConnectInterrupt Continued... by Doron

Doron
Wed Jan 12 14:20:10 CST 2005

no magical coding is required. you get back a pointer to an interrupt
object. that interrupt object is just the head of a chain of interrupt
objects (at an abstract level, the impl is free to change). when you pass
in the interrupt object, the OS knows that it is a part of a chain and acts
accordingly. have you tried just hardcoding the affinity to 1? have you
tried this on different MP chipsets? perhaps your device does not behave
well with an IO APIC vs a PIC (found only on uniprocessor machines).

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"JimE" <JimE@NOSPAMmacrolink.com> wrote in message
news:9B6D290D-E4C8-4068-8EF9-D012D67CF1FF@microsoft.com...
> From the DDK documentation, title "Registering an Isr":
>
> To register an ISR, a driver's DispatchPnP routine must call
> IoConnectInterrupt when it receives an IRP_MN_START_DEVICE request. In
> response, the I/O Manager creates an interrupt object for each processor
> that
> the device can interrupt.
>
> In a previous thread, I had gotten several suggestions about which
> parameter
> to IoConnectInterrupt was causing it to fail with
> STATUS_INVALID_PARAMETER,
> but none of them helped. The code worked OK on single processor systems.
> If
> the affinity argument (extracted from the translated resource list in the
> start device IRP) indicates that more than one processor can be
> interrupted,
> how does the I/O manager return a pointer to multiple interrupt objects?
>
> Is there some special coding to connect an interrupt on a multi-processor
> machine? The DDK documentation seems to have little to say about this.



Re: IoConnectInterrupt Continued... by JimE

JimE
Thu Jan 13 11:51:01 CST 2005

I tried using a bit mask and presenting IoConnectInterrupt with each bit that
was set in the affinity mask, which only resulted in two failed calls. The
mask is 3. The device is PCI, using a PLX 9030 PCI to local bus bridge chip.
I don't know what difference PIC vs APIC would make, as a PCI device only
asserts the slot-relative INTA signal when interrupting. Of course, I never
get that far; interrupts are not enabled in the device until after
sucessfully registering the ISR, which is what fails.

Of the 11 parameters to IoConnectInterrupt, 6 are provided by the I/O system
in the list of translated resources in the start device IRP: Vector, Irql,
SynchronizeIrql (same as Irql), InterruptMode, ShareVector, and
ProcessorEnableMask. Why would the I/O system give me bogus resources? The
other 5 parameters are (1) the address of the interrupt object pointer, which
is in the device extension; (2) the address of the ISR; (3) the service
context, which is the address of the device extension; (4) the optional
spinlock; and (5) FloatingSave which must be FALSE for x86-based platforms.

I've tried providing the address of an initialized spinlock, and NULL, both
fail. I've tried hard coding ShareVector to both FALSE and TRUE, both fail.
The address of the interrupt object pointer and the ISR are both valid, and I
don't see how it could know if "ServiceContext" was valid or not, since that
would depend on how the driver is coded, but it is also a valid address.
About the only thing I have'nt tried is hard coding FloatingSave to TRUE.

Is there any way to discover which parameter to IoConnectInterrupt is invalid?

The only message from the operating system is:
HalEnableSystemInterrupt failed


"Doron Holan [MS]" wrote:

> no magical coding is required. you get back a pointer to an interrupt
> object. that interrupt object is just the head of a chain of interrupt
> objects (at an abstract level, the impl is free to change). when you pass
> in the interrupt object, the OS knows that it is a part of a chain and acts
> accordingly. have you tried just hardcoding the affinity to 1? have you
> tried this on different MP chipsets? perhaps your device does not behave
> well with an IO APIC vs a PIC (found only on uniprocessor machines).
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "JimE" <JimE@NOSPAMmacrolink.com> wrote in message
> news:9B6D290D-E4C8-4068-8EF9-D012D67CF1FF@microsoft.com...
> > From the DDK documentation, title "Registering an Isr":
> >
> > To register an ISR, a driver's DispatchPnP routine must call
> > IoConnectInterrupt when it receives an IRP_MN_START_DEVICE request. In
> > response, the I/O Manager creates an interrupt object for each processor
> > that
> > the device can interrupt.
> >
> > In a previous thread, I had gotten several suggestions about which
> > parameter
> > to IoConnectInterrupt was causing it to fail with
> > STATUS_INVALID_PARAMETER,
> > but none of them helped. The code worked OK on single processor systems.
> > If
> > the affinity argument (extracted from the translated resource list in the
> > start device IRP) indicates that more than one processor can be
> > interrupted,
> > how does the I/O manager return a pointer to multiple interrupt objects?
> >
> > Is there some special coding to connect an interrupt on a multi-processor
> > machine? The DDK documentation seems to have little to say about this.
>
>
>

Re: IoConnectInterrupt Continued... by cristalink

cristalink
Thu Jan 13 13:17:00 CST 2005

> Is there any way to discover which parameter to IoConnectInterrupt is
> invalid?

WinDbg?
--
http://www.firestreamer.com - NTBackup to DVD and DV


"JimE" <JimE@NOSPAMmacrolink.com> wrote in message
news:456113C4-E1F0-42BD-9EC4-E4BC301C493D@microsoft.com...
>I tried using a bit mask and presenting IoConnectInterrupt with each bit
>that
> was set in the affinity mask, which only resulted in two failed calls. The
> mask is 3. The device is PCI, using a PLX 9030 PCI to local bus bridge
> chip.
> I don't know what difference PIC vs APIC would make, as a PCI device only
> asserts the slot-relative INTA signal when interrupting. Of course, I
> never
> get that far; interrupts are not enabled in the device until after
> sucessfully registering the ISR, which is what fails.
>
> Of the 11 parameters to IoConnectInterrupt, 6 are provided by the I/O
> system
> in the list of translated resources in the start device IRP: Vector, Irql,
> SynchronizeIrql (same as Irql), InterruptMode, ShareVector, and
> ProcessorEnableMask. Why would the I/O system give me bogus resources? The
> other 5 parameters are (1) the address of the interrupt object pointer,
> which
> is in the device extension; (2) the address of the ISR; (3) the service
> context, which is the address of the device extension; (4) the optional
> spinlock; and (5) FloatingSave which must be FALSE for x86-based
> platforms.
>
> I've tried providing the address of an initialized spinlock, and NULL,
> both
> fail. I've tried hard coding ShareVector to both FALSE and TRUE, both
> fail.
> The address of the interrupt object pointer and the ISR are both valid,
> and I
> don't see how it could know if "ServiceContext" was valid or not, since
> that
> would depend on how the driver is coded, but it is also a valid address.
> About the only thing I have'nt tried is hard coding FloatingSave to TRUE.
>
> Is there any way to discover which parameter to IoConnectInterrupt is
> invalid?
>
> The only message from the operating system is:
> HalEnableSystemInterrupt failed
>
>
> "Doron Holan [MS]" wrote:
>
>> no magical coding is required. you get back a pointer to an interrupt
>> object. that interrupt object is just the head of a chain of interrupt
>> objects (at an abstract level, the impl is free to change). when you
>> pass
>> in the interrupt object, the OS knows that it is a part of a chain and
>> acts
>> accordingly. have you tried just hardcoding the affinity to 1? have you
>> tried this on different MP chipsets? perhaps your device does not behave
>> well with an IO APIC vs a PIC (found only on uniprocessor machines).
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "JimE" <JimE@NOSPAMmacrolink.com> wrote in message
>> news:9B6D290D-E4C8-4068-8EF9-D012D67CF1FF@microsoft.com...
>> > From the DDK documentation, title "Registering an Isr":
>> >
>> > To register an ISR, a driver's DispatchPnP routine must call
>> > IoConnectInterrupt when it receives an IRP_MN_START_DEVICE request. In
>> > response, the I/O Manager creates an interrupt object for each
>> > processor
>> > that
>> > the device can interrupt.
>> >
>> > In a previous thread, I had gotten several suggestions about which
>> > parameter
>> > to IoConnectInterrupt was causing it to fail with
>> > STATUS_INVALID_PARAMETER,
>> > but none of them helped. The code worked OK on single processor
>> > systems.
>> > If
>> > the affinity argument (extracted from the translated resource list in
>> > the
>> > start device IRP) indicates that more than one processor can be
>> > interrupted,
>> > how does the I/O manager return a pointer to multiple interrupt
>> > objects?
>> >
>> > Is there some special coding to connect an interrupt on a
>> > multi-processor
>> > machine? The DDK documentation seems to have little to say about this.
>>
>>
>>



Re: IoConnectInterrupt Continued... by Alexander

Alexander
Thu Jan 13 22:07:07 CST 2005

I suppose you forwarded IRP_MJ_START_DEVICE to the PDO first?

"JimE" <JimE@NOSPAMmacrolink.com> wrote in message
news:456113C4-E1F0-42BD-9EC4-E4BC301C493D@microsoft.com...
>I tried using a bit mask and presenting IoConnectInterrupt with each bit
>that
> was set in the affinity mask, which only resulted in two failed calls. The
> mask is 3. The device is PCI, using a PLX 9030 PCI to local bus bridge
> chip.
> I don't know what difference PIC vs APIC would make, as a PCI device only
> asserts the slot-relative INTA signal when interrupting. Of course, I
> never
> get that far; interrupts are not enabled in the device until after
> sucessfully registering the ISR, which is what fails.
>
> Of the 11 parameters to IoConnectInterrupt, 6 are provided by the I/O
> system
> in the list of translated resources in the start device IRP: Vector, Irql,
> SynchronizeIrql (same as Irql), InterruptMode, ShareVector, and
> ProcessorEnableMask. Why would the I/O system give me bogus resources? The
> other 5 parameters are (1) the address of the interrupt object pointer,
> which
> is in the device extension; (2) the address of the ISR; (3) the service
> context, which is the address of the device extension; (4) the optional
> spinlock; and (5) FloatingSave which must be FALSE for x86-based
> platforms.
>
> I've tried providing the address of an initialized spinlock, and NULL,
> both
> fail. I've tried hard coding ShareVector to both FALSE and TRUE, both
> fail.
> The address of the interrupt object pointer and the ISR are both valid,
> and I
> don't see how it could know if "ServiceContext" was valid or not, since
> that
> would depend on how the driver is coded, but it is also a valid address.
> About the only thing I have'nt tried is hard coding FloatingSave to TRUE.
>
> Is there any way to discover which parameter to IoConnectInterrupt is
> invalid?
>
> The only message from the operating system is:
> HalEnableSystemInterrupt failed
>
>
> "Doron Holan [MS]" wrote:
>
>> no magical coding is required. you get back a pointer to an interrupt
>> object. that interrupt object is just the head of a chain of interrupt
>> objects (at an abstract level, the impl is free to change). when you
>> pass
>> in the interrupt object, the OS knows that it is a part of a chain and
>> acts
>> accordingly. have you tried just hardcoding the affinity to 1? have you
>> tried this on different MP chipsets? perhaps your device does not behave
>> well with an IO APIC vs a PIC (found only on uniprocessor machines).
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "JimE" <JimE@NOSPAMmacrolink.com> wrote in message
>> news:9B6D290D-E4C8-4068-8EF9-D012D67CF1FF@microsoft.com...
>> > From the DDK documentation, title "Registering an Isr":
>> >
>> > To register an ISR, a driver's DispatchPnP routine must call
>> > IoConnectInterrupt when it receives an IRP_MN_START_DEVICE request. In
>> > response, the I/O Manager creates an interrupt object for each
>> > processor
>> > that
>> > the device can interrupt.
>> >
>> > In a previous thread, I had gotten several suggestions about which
>> > parameter
>> > to IoConnectInterrupt was causing it to fail with
>> > STATUS_INVALID_PARAMETER,
>> > but none of them helped. The code worked OK on single processor
>> > systems.
>> > If
>> > the affinity argument (extracted from the translated resource list in
>> > the
>> > start device IRP) indicates that more than one processor can be
>> > interrupted,
>> > how does the I/O manager return a pointer to multiple interrupt
>> > objects?
>> >
>> > Is there some special coding to connect an interrupt on a
>> > multi-processor
>> > machine? The DDK documentation seems to have little to say about this.
>>
>>
>>



Re: IoConnectInterrupt Continued... by JimE

JimE
Mon Jan 17 11:22:57 CST 2005

Yes, I do forward the IRP to the PDO first. It returns a sucessful status.

I have used WinDbg to set breakpoints in the driver, and the system calls
made when trying to connect the interrupt. IoConnectInterrupt calls
KeGetCurrentIrql, and if 1 or less, calls ExAllocatePoolWithTag,
KeInitializeInterrupt, and KeConnectInterrupt. KeConnectInterrupt then calls
KeSetSystemAffinityThread, KeAcquireQueuedSpinLockRaiseToSynch,
KiGetVectorInfo, KiConnectVectorAndInterruptObject, and
HalEnableSystemInterrupt. This last call fails. I am unable to set a
breakpoint at the start of HalEnableSystemInterrupt because this causes the
system to crash.

"Alexander Grigoriev" wrote:

> I suppose you forwarded IRP_MJ_START_DEVICE to the PDO first?
>
> "JimE" <JimE@NOSPAMmacrolink.com> wrote in message
> news:456113C4-E1F0-42BD-9EC4-E4BC301C493D@microsoft.com...
> >I tried using a bit mask and presenting IoConnectInterrupt with each bit
> >that
> > was set in the affinity mask, which only resulted in two failed calls. The
> > mask is 3. The device is PCI, using a PLX 9030 PCI to local bus bridge
> > chip.
> > I don't know what difference PIC vs APIC would make, as a PCI device only
> > asserts the slot-relative INTA signal when interrupting. Of course, I
> > never
> > get that far; interrupts are not enabled in the device until after
> > sucessfully registering the ISR, which is what fails.
> >
> > Of the 11 parameters to IoConnectInterrupt, 6 are provided by the I/O
> > system
> > in the list of translated resources in the start device IRP: Vector, Irql,
> > SynchronizeIrql (same as Irql), InterruptMode, ShareVector, and
> > ProcessorEnableMask. Why would the I/O system give me bogus resources? The
> > other 5 parameters are (1) the address of the interrupt object pointer,
> > which
> > is in the device extension; (2) the address of the ISR; (3) the service
> > context, which is the address of the device extension; (4) the optional
> > spinlock; and (5) FloatingSave which must be FALSE for x86-based
> > platforms.
> >
> > I've tried providing the address of an initialized spinlock, and NULL,
> > both
> > fail. I've tried hard coding ShareVector to both FALSE and TRUE, both
> > fail.
> > The address of the interrupt object pointer and the ISR are both valid,
> > and I
> > don't see how it could know if "ServiceContext" was valid or not, since
> > that
> > would depend on how the driver is coded, but it is also a valid address.
> > About the only thing I have'nt tried is hard coding FloatingSave to TRUE.
> >
> > Is there any way to discover which parameter to IoConnectInterrupt is
> > invalid?
> >
> > The only message from the operating system is:
> > HalEnableSystemInterrupt failed
> >
> >
> > "Doron Holan [MS]" wrote:
> >
> >> no magical coding is required. you get back a pointer to an interrupt
> >> object. that interrupt object is just the head of a chain of interrupt
> >> objects (at an abstract level, the impl is free to change). when you
> >> pass
> >> in the interrupt object, the OS knows that it is a part of a chain and
> >> acts
> >> accordingly. have you tried just hardcoding the affinity to 1? have you
> >> tried this on different MP chipsets? perhaps your device does not behave
> >> well with an IO APIC vs a PIC (found only on uniprocessor machines).
> >>
> >> d
> >>
> >> --
> >> Please do not send e-mail directly to this alias. this alias is for
> >> newsgroup purposes only.
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >> "JimE" <JimE@NOSPAMmacrolink.com> wrote in message
> >> news:9B6D290D-E4C8-4068-8EF9-D012D67CF1FF@microsoft.com...
> >> > From the DDK documentation, title "Registering an Isr":
> >> >
> >> > To register an ISR, a driver's DispatchPnP routine must call
> >> > IoConnectInterrupt when it receives an IRP_MN_START_DEVICE request. In
> >> > response, the I/O Manager creates an interrupt object for each
> >> > processor
> >> > that
> >> > the device can interrupt.
> >> >
> >> > In a previous thread, I had gotten several suggestions about which
> >> > parameter
> >> > to IoConnectInterrupt was causing it to fail with
> >> > STATUS_INVALID_PARAMETER,
> >> > but none of them helped. The code worked OK on single processor
> >> > systems.
> >> > If
> >> > the affinity argument (extracted from the translated resource list in
> >> > the
> >> > start device IRP) indicates that more than one processor can be
> >> > interrupted,
> >> > how does the I/O manager return a pointer to multiple interrupt
> >> > objects?
> >> >
> >> > Is there some special coding to connect an interrupt on a
> >> > multi-processor
> >> > machine? The DDK documentation seems to have little to say about this.
> >>
> >>
> >>
>
>
>

Re: IoConnectInterrupt Continued... by Alexander

Alexander
Mon Jan 17 23:02:40 CST 2005

The only problem I see is that a PCI bridge may need special handling. But
I'm not sure about that. You may need to talk to MS people.

"JimE" <JimE@NOSPAMmacrolink.com> wrote in message
news:C7521B2C-51DC-4FE9-AA40-447F7E9BF0CD@microsoft.com...
> Yes, I do forward the IRP to the PDO first. It returns a sucessful status.
>
> I have used WinDbg to set breakpoints in the driver, and the system calls
> made when trying to connect the interrupt. IoConnectInterrupt calls
> KeGetCurrentIrql, and if 1 or less, calls ExAllocatePoolWithTag,
> KeInitializeInterrupt, and KeConnectInterrupt. KeConnectInterrupt then
> calls
> KeSetSystemAffinityThread, KeAcquireQueuedSpinLockRaiseToSynch,
> KiGetVectorInfo, KiConnectVectorAndInterruptObject, and
> HalEnableSystemInterrupt. This last call fails. I am unable to set a
> breakpoint at the start of HalEnableSystemInterrupt because this causes
> the
> system to crash.
>
> "Alexander Grigoriev" wrote:
>
>> I suppose you forwarded IRP_MJ_START_DEVICE to the PDO first?
>>
>> "JimE" <JimE@NOSPAMmacrolink.com> wrote in message
>> news:456113C4-E1F0-42BD-9EC4-E4BC301C493D@microsoft.com...
>> >I tried using a bit mask and presenting IoConnectInterrupt with each bit
>> >that
>> > was set in the affinity mask, which only resulted in two failed calls.
>> > The
>> > mask is 3. The device is PCI, using a PLX 9030 PCI to local bus bridge
>> > chip.
>> > I don't know what difference PIC vs APIC would make, as a PCI device
>> > only
>> > asserts the slot-relative INTA signal when interrupting. Of course, I
>> > never
>> > get that far; interrupts are not enabled in the device until after
>> > sucessfully registering the ISR, which is what fails.
>> >
>> > Of the 11 parameters to IoConnectInterrupt, 6 are provided by the I/O
>> > system
>> > in the list of translated resources in the start device IRP: Vector,
>> > Irql,
>> > SynchronizeIrql (same as Irql), InterruptMode, ShareVector, and
>> > ProcessorEnableMask. Why would the I/O system give me bogus resources?
>> > The
>> > other 5 parameters are (1) the address of the interrupt object pointer,
>> > which
>> > is in the device extension; (2) the address of the ISR; (3) the service
>> > context, which is the address of the device extension; (4) the optional
>> > spinlock; and (5) FloatingSave which must be FALSE for x86-based
>> > platforms.
>> >
>> > I've tried providing the address of an initialized spinlock, and NULL,
>> > both
>> > fail. I've tried hard coding ShareVector to both FALSE and TRUE, both
>> > fail.
>> > The address of the interrupt object pointer and the ISR are both valid,
>> > and I
>> > don't see how it could know if "ServiceContext" was valid or not, since
>> > that
>> > would depend on how the driver is coded, but it is also a valid
>> > address.
>> > About the only thing I have'nt tried is hard coding FloatingSave to
>> > TRUE.
>> >
>> > Is there any way to discover which parameter to IoConnectInterrupt is
>> > invalid?
>> >
>> > The only message from the operating system is:
>> > HalEnableSystemInterrupt failed
>> >
>> >
>> > "Doron Holan [MS]" wrote:
>> >
>> >> no magical coding is required. you get back a pointer to an interrupt
>> >> object. that interrupt object is just the head of a chain of
>> >> interrupt
>> >> objects (at an abstract level, the impl is free to change). when you
>> >> pass
>> >> in the interrupt object, the OS knows that it is a part of a chain and
>> >> acts
>> >> accordingly. have you tried just hardcoding the affinity to 1? have
>> >> you
>> >> tried this on different MP chipsets? perhaps your device does not
>> >> behave
>> >> well with an IO APIC vs a PIC (found only on uniprocessor machines).
>> >>
>> >> d
>> >>
>> >> --
>> >> Please do not send e-mail directly to this alias. this alias is for
>> >> newsgroup purposes only.
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >>
>> >>
>> >> "JimE" <JimE@NOSPAMmacrolink.com> wrote in message
>> >> news:9B6D290D-E4C8-4068-8EF9-D012D67CF1FF@microsoft.com...
>> >> > From the DDK documentation, title "Registering an Isr":
>> >> >
>> >> > To register an ISR, a driver's DispatchPnP routine must call
>> >> > IoConnectInterrupt when it receives an IRP_MN_START_DEVICE request.
>> >> > In
>> >> > response, the I/O Manager creates an interrupt object for each
>> >> > processor
>> >> > that
>> >> > the device can interrupt.
>> >> >
>> >> > In a previous thread, I had gotten several suggestions about which
>> >> > parameter
>> >> > to IoConnectInterrupt was causing it to fail with
>> >> > STATUS_INVALID_PARAMETER,
>> >> > but none of them helped. The code worked OK on single processor
>> >> > systems.
>> >> > If
>> >> > the affinity argument (extracted from the translated resource list
>> >> > in
>> >> > the
>> >> > start device IRP) indicates that more than one processor can be
>> >> > interrupted,
>> >> > how does the I/O manager return a pointer to multiple interrupt
>> >> > objects?
>> >> >
>> >> > Is there some special coding to connect an interrupt on a
>> >> > multi-processor
>> >> > machine? The DDK documentation seems to have little to say about
>> >> > this.
>> >>
>> >>
>> >>
>>
>>
>>