My driver is working fine on a single Athlon 1.2GHz. However, when I tried
it on a dual PII-233 machine, I wasn’t getting my device interrupts (more
specifically, my ISR was not being called) while in my HwScsiInitialize
function. I know that function runs at DIRQL, and if I remember correctly,
it’s because SCSIPORT is holding a spinlock…
Does the SCSIPORT spinlock apparently mask off my interrupt? And if so, is
that only on SMP systems, since it goes just fine on the single CPU?
Basically my initialize code does some things to the hardware that cause it
to generate interrupts (and of course I happen to need them).
To try a quick fix, I moved the interrupting sections into my FindAdapter
function, as they are safe in PASSIVE_LEVEL. That had the effect of
silencing interrupts on both machines, UP and SMP.
I figured PASSIVE_LEVEL would be fine, but then realized SCSIPORT might not
have connected the ISR before entering my FindAdapter. If this is the
case, how can I ensure my ISR gets called back (chuckle) while in my
Initialize function on an SMP system?
Jason
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
> specifically, my ISR was not being called) while in my HwScsiInitialize
function. I know that function runs at DIRQL, and if I remember correctly,
it’s because SCSIPORT is holding a spinlock…
Does the SCSIPORT spinlock apparently mask off my interrupt?
Yes, all miniport functions (except initialization) are called from KeSynchronizeExecution.
Basically my initialize code does some things to the hardware that cause it
to generate interrupts (and of course I happen to need them).
So, you need to process interrupts while initialization. Try to use state machine-like approach - execute first initialization phase
(what must be done before the first interrupt) in HwInitialize, then execute the next phases from the ISR as a state machine.
I figured PASSIVE_LEVEL would be fine, but then realized SCSIPORT might not
have connected the ISR before entering my FindAdapter.
IIRC this is really so.
Max
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
Actually, all miniport functions dont seem to be synchronized on the interrupt object. I was under the same impression, but it turned out to be something other than the interrupt object. They are synchronized, but I think something else is being used. I found this after debugging a problem where a KeSynchronizeExecution with the interrupt object was being entered at the same time as StartIO.
M
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, January 10, 2002 1:19 AM
To: NT Developers Interest List
Subject: [ntdev] Re: SCSI miniport interrupts
specifically, my ISR was not being called) while in my HwScsiInitialize
function. I know that function runs at DIRQL, and if I remember correctly,
it’s because SCSIPORT is holding a spinlock…
Does the SCSIPORT spinlock apparently mask off my interrupt?
Yes, all miniport functions (except initialization) are called from KeSynchronizeExecution.
Basically my initialize code does some things to the hardware that cause it
to generate interrupts (and of course I happen to need them).
So, you need to process interrupts while initialization. Try to use state machine-like approach - execute first initialization phase
(what must be done before the first interrupt) in HwInitialize, then execute the next phases from the ISR as a state machine.
I figured PASSIVE_LEVEL would be fine, but then realized SCSIPORT might not
have connected the ISR before entering my FindAdapter.
IIRC this is really so.
Max
You are currently subscribed to ntdev as: xxxxx@troikanetworks.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