SCSI miniport over other software

Hi all,

I have the task to write the SCSI miniport driver for NT4 which will talk to
some other drivers on the bottom side, not to the hardware. This will be the
driver for some special kind of disk.
The problems is - how to handle request completions in the miniport?
SRBs are completed using ScsiPortNotification, and it must be called from
the miniport context (with some SCSIPORT’s locks held).
Is it impossible to call ScsiPortNotification from some other code - namely
from the completion routine called by the lower driver?

If yes - what are the ways of doing this? NDIS had the similar problem with
inidications - and IIRC it was bypassed by setting an NDIS timer and
indicating the packets from within the timer’s callback which is in the
miniport context.
But I have a strong suspect that ScsiPortNotification(RequestTimerCall…)
must also be called from the miniport context, not from the other DPC.

Is there any ways to bypass this? I can write a full SCSI port driver on
NT4 - but this is very, very complex on w2k, because on w2k it must also be
the PnP bus enumerator. Any other ways?

regards,
Max

Max,

Everything in scsiport has to be called from within the ‘miniport context’.
So you are either going to have to byte the bullet and do a full scsiport
(which I don’t think is as big a deal as you fear,) or adopt a polling model
in you miniport. You can initiate polling via a call to ScsiPortNotification
either in your startIO routine or when you initialize your adapter.Your
timer routine will have to check with your other driver regarding what has
or has not been completed.

Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Monday, September 25, 2000 4:33 AM
To: NT Developers Interest List
Subject: [ntdev] SCSI miniport over other software

Hi all,

I have the task to write the SCSI miniport driver for NT4 which
will talk to
some other drivers on the bottom side, not to the hardware. This
will be the
driver for some special kind of disk.
The problems is - how to handle request completions in the miniport?
SRBs are completed using ScsiPortNotification, and it must be called from
the miniport context (with some SCSIPORT’s locks held).
Is it impossible to call ScsiPortNotification from some other
code - namely
from the completion routine called by the lower driver?

If yes - what are the ways of doing this? NDIS had the similar
problem with
inidications - and IIRC it was bypassed by setting an NDIS timer and
indicating the packets from within the timer’s callback which is in the
miniport context.
But I have a strong suspect that ScsiPortNotification(RequestTimerCall…)
must also be called from the miniport context, not from the other DPC.

Is there any ways to bypass this? I can write a full SCSI port driver on
NT4 - but this is very, very complex on w2k, because on w2k it
must also be
the PnP bus enumerator. Any other ways?

regards,
Max


You are currently subscribed to ntdev as: xxxxx@wattanuck.mv.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

Miniport context means SCSIPORT has acquired a spinlock and synchronized
with an interrupt, both associated with the adapter’s device object. It
is possible (but not portable) for you to find and acquire/sync with
these objects too. But I’m not sure how you would ensure there is a
valid KINTERRUPT if you’re driver doesn’t correspond to actual hardware
with interrupt capability.

We hacked target reset and other special functionality into an NT4 hardware
miniport this way:

//“Device Extension” given to miniports is offset 0x180 bytes
//into the actual device extension for the ScsiPortX device.

LPBYTE pMiniDevExt = pExtBase + 0x180;

//I observed SCSIPORT to acquire this spin-lock before calling
//KeSynchronizeExecution to invoke QLStartIo.

PKSPIN_LOCK pSpinLock = (PKSPIN_LOCK)(pExtBase + 0x34);

KIRQL oldIRQL;
KeAcquireSpinLock(pSpinLock, &oldIRQL);

//This is the location in SCSIPORT’s portion of the device
//extension where it keeps the KINTERRUPT pointer for the HBA’s
//interrupt.

PKINTERRUPT pInterrupt = (PKINTERRUPT)*(DWORD*)(pExtBase + 0x24);

//Invoke TargetReset routine at same DIRQL as the ISR
//with KeSynchronizeExecution

TargetResetParams params;

//setup params

BOOLEAN bSyncExRes = KeSynchronizeExecution(
pInterrupt,
SynchronizedTargetReset,
&params
);

KeReleaseSpinLock(pSpinLock, oldIRQL);


Dave Cox
Hewlett-Packard Co.
HPSO/SMSO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Monday, September 25, 2000 1:33 AM
To: NT Developers Interest List
Subject: [ntdev] SCSI miniport over other software

Hi all,

I have the task to write the SCSI miniport driver for NT4 which will talk to
some other drivers on the bottom side, not to the hardware. This will be the
driver for some special kind of disk.
The problems is - how to handle request completions in the miniport?
SRBs are completed using ScsiPortNotification, and it must be called from
the miniport context (with some SCSIPORT’s locks held).
Is it impossible to call ScsiPortNotification from some other code - namely
from the completion routine called by the lower driver?

If yes - what are the ways of doing this? NDIS had the similar problem with
inidications - and IIRC it was bypassed by setting an NDIS timer and
indicating the packets from within the timer’s callback which is in the
miniport context.
But I have a strong suspect that ScsiPortNotification(RequestTimerCall…)
must also be called from the miniport context, not from the other DPC.

Is there any ways to bypass this? I can write a full SCSI port driver on
NT4 - but this is very, very complex on w2k, because on w2k it must also be
the PnP bus enumerator. Any other ways?

regards,
Max


You are currently subscribed to ntdev as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

Max,

I have the task to write the SCSI miniport driver for NT4 which will talk
to
some other drivers on the bottom side, not to the hardware. This will be
the
driver for some special kind of disk.
The problems is - how to handle request completions in the miniport?
SRBs are completed using ScsiPortNotification, and it must be called from
the miniport context (with some SCSIPORT’s locks held).
Is it impossible to call ScsiPortNotification from some other code -
namely
from the completion routine called by the lower driver?
Yes. You cannot complete the miniport SRB request from some other device. It
has
to be done strictly in miniport context.

If yes - what are the ways of doing this? NDIS had the similar problem
with
inidications - and IIRC it was bypassed by setting an NDIS timer and
indicating the packets from within the timer’s callback which is in the
miniport context.
But I have a strong suspect that ScsiPortNotification(RequestTimerCall…)
must also be called from the miniport context, not from the other DPC.

Is there any ways to bypass this? I can write a full SCSI port driver on
NT4 - but this is very, very complex on w2k, because on w2k it must also
be
the PnP bus enumerator. Any other ways?

Yes. What I have done is to have a free wheeling timer (RequestTimercall)
and have the miniport
request completed within this. However, the latency will be atmost 10
millisec.

regards

Deva

regards,
Max


You are currently subscribed to ntdev as: devanpdy@md4.vsnl.net.in
To unsubscribe send a blank email to $subst(‘Email.Unsub’)