cristalink
Tue Jan 11 20:11:54 CST 2005
>>But, as the IoCreateDevice call initialized the device extension to zero,
>>a NULL is effectively passed to IoConnectInterrupt
>> &pExt->rupt
If the pExt pointer is non-NULL (which is the case, I assume), then
(&pExt->rupt) won't be ((PKSPIN_LOCK) NULL), but rather a pointer to an
uninitialized spinlock. Why don't you try passing a real NULL( ..., NULL,
...), to eliminate the spinlock from search?
--
http://www.firestreamer.com - NTBackup to DVD and DV
"JimE" <JimE@NOSPAMmacrolink.com> wrote in message
news:BE5644AE-7FC9-47A6-9DBB-F3B06457E46A@microsoft.com...
> Actually, I just was looking at that myself. Originally, I thought I
> needed
> it for KeSynchronizeExecution, but I ended up being able to do all of the
> required work in various DPC routines, so it was left uninitialized. But,
> as
> the IoCreateDevice call initialized the device extension to zero, a NULL
> is
> effectively passed to IoConnectInterrupt. I just changed the code to
> initialize the spinlock, but I still get the same results.
>
> The OS does spit out a message, but it tells me little:
>
> HalEnableSystemInterrupt failed
>
> Since it's a "HAL" (presumably from a HalXxx routine) instead of a "IO"
> (from a IoXxx routine) message, maybe the invalid parameter status is
> misleading? I wish it was a little more specific about what offends it.
>
> "Ray Trent" wrote:
>
>> The only potentially suspicious thing I see is the &iExt->rupt passed in
>> as the spinlock.
>>
>> A) Is it actually a KSPIN_LOCK and have you initialized it? (you might
>> not notice on an uniprocessor).
>> B) Are you sure you need it? Normally this is NULL unless you're
>> handling more than 1 interrupt, and in that case often your Irql and
>> SynchronizeIrql are at least potentially different.
>>
>> JimE wrote:
>> > Sure, here it is:
>> >
>> > PIO_STACK_LOCATION pIrpSp = IoGetCurrentIrpStackLocation(pIrp);
>> > PCM_PARTIAL_RESOURCE_LIST pList =
>> > &pIrpSp->Parameters.StartDevice.AllocatedResourcesTranslated->List[0].PartialResourceList;
>> > PCM_PARTIAL_RESOURCE_DESCRIPTOR pDesc = pList->PartialDescriptors;
>> > ULONG count;
>> > ULONG vector;
>> > KINTERRUPT_MODE mode;
>> > KAFFINITY affinity;
>> > KIRQL irql;
>> > BOOLEAN shared;
>> > NTSTATUS status;
>> >
>> > for (count = 0; count < pList->Count; count++, pDesc++)
>> > {
>> > switch (pDesc->Type)
>> > {
>> > ...
>> > case CmResourceTypeInterrupt:
>> > vector = (KIRQL)pDesc->u.Interrupt.Vector;
>> > irql = (KIRQL)pDesc->u.Interrupt.Level;
>> > affinity = pDesc->u.Interrupt.Affinity;
>> > mode = (pDesc->Flags == CM_RESOURCE_INTERRUPT_LATCHED) ?
>> > Latched :
>> > LevelSensitive;
>> > shared = (pDesc->ShareDisposition == CmResourceShareShared);
>> > break;
>> > }
>> > }
>> > ...
>> > /* hardware initialization */
>> > ...
>> > status = IoConnectInterrupt(&pExt->pInterrupt,
>> > (PKSERVICE_ROUTINE)mccsIsr,
>> > (PVOID)pExt, &pExt->rupt, vector, irql, irql, mode, TRUE, affinity,
>> > FALSE);
>> >
>> > I would not be so confused by this if I was just starting the project
>> > and
>> > the code was otherwise untested, but this has worked flawlessly on
>> > Win2K,
>> > Win2003, and Xp on a couple of single processor machines.
>> >
>> > -JimE
>> >
>> > "Ray Trent" wrote:
>> >
>> >
>> >>Hmmm... Nothing obviously wrong there that I can see. I was only
>> >>suggesting -1 because the affinity I thought you were being passed
>> >>looked broken. There's a hint the docs for
>> >>CM_PARTIAL_RESOURCE_DESCRIPTOR that this might be ok. But if you're
>> >>getting a good value (and 3 looks like a perfectly reasonable value,
>> >>assuming you have 2 processors :-), that's definitely better.
>> >>
>> >>I'd suggest posting the code that leads up to this call to
>> >>IoConnectInterrupt so we can see the parameters and how they were
>> >>allocated/initialized.
>> >>
>> >>JimE wrote:
>> >>
>> >>>Ray,
>> >>>
>> >>>Thanks for the speedy reply. I looked at my code again and the info
>> >>>above
>> >>>was incorrect. It was a DbgPrint error (is there a compiler option I
>> >>>can set
>> >>>to warn about mismatched number of parameters?). The actual parameters
>> >>>are:
>> >>>
>> >>>vector: 0xb4 (changed for unknown reasons)
>> >>>irql: 0xa
>> >>>affinity: 3
>> >>>mode: 0
>> >>>shared: TRUE
>> >>>
>> >>>This makes more sense to me, assuming that "affinity" is a bit
>> >>>weighted
>> >>>processor enable, and "mode" must be one of the enumerated values in
>> >>>wdm.h (0
>> >>>or 1). I also double checked that I was using the translated
>> >>>resources, and
>> >>>not raw.
>> >>>
>> >>>What part of the DDK documentation states that "affinity" can be 0xff?
>> >>>
>> >>>None of the above parameters seem unreasonable to me. Does anyone have
>> >>>any
>> >>>ideas?
>> >>>
>> >>>-JimE
>> >>>
>> >>>"Ray Trent" wrote:
>> >>>
>> >>>
>> >>>
>> >>>>0xa4 strikes me as a pretty weird processor affinity mask. Are you
>> >>>>using
>> >>>>the translated resources (normally what you want rather than the raw
>> >>>>resources)? I would tend to think (and the documentation says) that
>> >>>>passing -1 as the affinity should work, but perhaps that's naughty
>> >>>>for
>> >>>>some reason.
>> >>>>
>> >>>>JimE wrote:
>> >>>>
>> >>>>
>> >>>>>Hello All,
>> >>>>>
>> >>>>>My driver testing has progressed to a multi-processor system, and
>> >>>>>now
>> >>>>>IoConnectInterrupt fails with status 0xc000000d (invalid parameter).
>> >>>>>I am
>> >>>>>using XP w/SP2. This all worked on a single processor system.
>> >>>>>
>> >>>>>The parameters I get in the start device IRP are:
>> >>>>>vector: 0xa4
>> >>>>>irql: 9
>> >>>>>affinity: 0xa4
>> >>>>>mode: 3
>> >>>>>shared: FALSE
>> >>>>>
>> >>>>>I think the bad parameter is the affinity. I double checked that I
>> >>>>>was
>> >>>>>getting vector from u.Interrupt.Vector, and affinity from
>> >>>>>u.Interrupt.Affinity.
>> >>>>>
>> >>>>>Is there some magic I need to do to connect an interrupt on a
>> >>>>>multi-processor machine?
>> >>>>>
>> >>>>>Thanks!
>> >>>>
>> >>>>--
>> >>>>.../ray\..
>> >>>>
>> >>
>> >>--
>> >>.../ray\..
>> >>
>>
>> --
>> .../ray\..
>>