Nar,
Thank you very much for the reply.
My bus driver enumerates a bus for our fibre channel adapter. This then is
used by our current functional layers, peer to peer, file systems driver and
any future FDO, to do large block IO as well as RDMA, on a fibre channel
adapter. The bus driver owns all aspects of the hardware. Any attaching FDO
queries the enumerated PDO of the bus for a proprietary interface and then
manages it’s own queues, using the proprietary interface to transfer data
and pass control commands to the bus driver. The mechanism we use to notify
a function driver of IO activity within the bus driver ISR is through a
callback function that is passed down to the bus driver in the control
packet. Each FDO passes its own notification function callback in that
control packet.
Getting a virtual SCSI miniport to load and initialize properly in this
scenario is problematic, in the extreme, requiring one to break the standard
model. First … what bus interface do I use to keep the PnP Manager and
SCSIPORT happy? Internal? See the preceding posts in this thread. PCI? Oh
no. Use that and FindAdpater never gets called. ISA? It isn’t ISA and that
really cobbles the INF file up with unneeded LogConfig crap. See a post by
Mark Roddy dated 24 Sep 2001, “SCSI miniport handle”. Internal makes the
most sense, all though defining my own would be better. Granted much of this
might be resolved if there was some SCSI specific documentation that
explained what the bus driver must do to keep SCSIPORT happy as it passes
down IRP_MN_XXXX requests. Also granted, much of this may be exacerbated
because I am breaking the standard model.
Second … SCSIPORT does not own the ISR. It does not own any of the
hardware. The bus driver owns the hardware including the ISR. I initially
tried the route your developers suggested — symbolically linking with the
bus driver. This allowed all the niceties of getting access to that
proprietary interface. But … the fact that SCSIPORT did not have the ISR
screwed data rates. I went from data rates of 60 to 70 MBps in the peer to
peer FDO to 10 to 12 MBps in the SCSI miniport using a 64k block size with
multiple IO command queuing. Why? Because there was NO WAY to trigger the
SCSIPORT DPC routine other than by requesting a timer, or setting
PHW_INTERRUPT.
Here’s the basic logic of a transfer — The miniport StartIo function uses
the SRB to build a fibre channel request block (FCRB) which includes setting
an IO notification callback into the miniport, and calls the fibre channel
data transfer function. At some point the adapter generates an interrupt and
calls the bus driver ISR. The ISR fetches the relevant FCRB, sets status and
volatile information within the FCRB, and calls the callback function in the
FCRB passing it a pointer to the FCRB. The callback and FCRB is now back
in miniport context. It resolves the FCRB back to an SRB, and hangs it on an
internal queue managed by the CallEnableInterrupts function. The callback
returns to the bus driver ISR which either loops if another FCRB is ready or
executes an exit from the ISR.
The SCSI miniport notification callback cannot use
ScsiPortNotification(RequestComplete,…) to complete the SRB that was
contained in the FCRB. Well it can, but it will do no good since it has no
way of triggering the DPC that is required to complete the SRB. Why?
ScsiPortNotification(CallEnableInterrupts,…) does not trigger the DPC.
That is only done in ScsiPortInterrupt and
ScsiPortNotification(RequestTimerCall…). I have no interrupt, remember,
and the timer injects a quantum delay every time it is called. Since I had
already “screwed the pooch” as far as the rules went, I went a little
farther and resolved the problem by calling
ScsiPortNotification(CallEnableInterrupts,…) on my SCSI extension to do a
proper setup for the SRB. Before returning from my ISR call back, I finish
by calling an NTDDK function that calls IoRequestDpc on the SCSIPORT FDO
that I looked for and squirrel away during initialization. Doing this is not
my first choice, but it does show what can happen if I can get the SCSIPORT
DPC to run. In comparison to the QLA2200 driver at 85 MBps, my driver now
does about 83 MBps.
If any of this is “remotely interesting” enough to drop a dime, my number is
(949) 7372731. I would love a solution that keeps me coloring within the
lines and could permit a logo, but so far I have found none.
–
Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net
“Nar Ganapathy [MS]” wrote in message
news:xxxxx@ntdev…
>
> What does your bus interface do ?
>
> Here’s an answer from our scsiport team.
>
> “Since he’s already breaking the miniport model and therefore is not
> interested in getting a logo, he could create a symbolic link in his bus
> driver that the miniport can get to. The two drivers then could pass
> whatever information they wanted. So I guess you could ask him why he
thinks
> he needs the busdriver hooks. (so the busdriver can tell him that the
> interrupt is just received is for the miniport??). There might be a more
> palatable method available. And if it’s remotely interesting, it might be
> something for further consideration in the new model.”
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties, and confers no
rights.
> “Jay Talbott” wrote in message
> news:xxxxx@ntdev…
> >
> > Gary,
> >
> > I agree with you wholeheartedly regarding the limitations of the
> > miniport model. As long as you are developing for a physical SCSI
> > adapter that falls within the design constraints of the miniport model,
> > all is fine. But if dealing with anything that doesn’t perfectly fit
> > the model (virtual adapters being a prime example), the miniport model
> > ties your hands in ways that are very frustrating.
> >
> > Again, if you have any luck modifying your .inf file so that only ONE
> > instance gets created in the ENUM tree, please share your findings.
> >
> > - Jay
> >
> > Jay Talbott
> > Principal Consulting Engineer
> > SysPro Consulting, LLC
> > 3519 E. South Fork Drive
> > Suite 201
> > Phoenix, AZ 85044
> > (480) 704-8045
> > xxxxx@sysproconsulting.com
> > http://www.sysproconsulting.com
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> > > Sent: Tuesday, July 02, 2002 10:06 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: SCSI miniport AddDevice …
> > >
> > >
> > > Jay,
> > >
> > > Yup … same problem with the banged out (!) SCSI/RAID
> > > controller in the
> > > Device manager. My first attack was the install app as well.
> > > I went back to
> > > WDM/INF to get that PDO and thus the current problems. It
> > > would certainly be
> > > nice if SCSI/STORPORT had extensions that made writing
> > > VIRTUAL miniports
> > > easier and reduced the need for thinking outside box.
> > >
> > > –
> > > Gary G. Little
> > > xxxxx@broadstor.com
> > > xxxxx@inland.net
> > >
> > > “Jay Talbott” wrote in message
> > > news:xxxxx@ntdev…
> > > >
> > > > Hi Gary,
> > > >
> > > > This all sounds familiar to a problem I was having 6 months
> > > ago or so
> > > > when working on a SCSI project for a client. The SCSI adapter was a
> > > > “virtual” SCSI adapter (no real hardware) which then
> > > communicated with a
> > > > flash card drive that connected to a serial port. I too had to step
> > > > outside the bounds of the SCSI miniport model in order to
> > > make things
> > > > work, since I needed to communicate to the drive through
> > > the serial port
> > > > driver (thus needing IoCallDriver(), amoungst other things).
> > > >
> > > > Check Device Manager. Are there two SCSI adapter entries,
> > > one with a
> > > > ‘!’?
> > > >
> > > > I found that upon installation of the driver using an .inf
> > > file, I would
> > > > always get two entries in the ENUM tree in the registry, one under
> > > > \ENUM\Root, and one under \ENUM\Root\SCSIADAPTER. This was
> > > causing the
> > > > FindAdapter routine to get called twice, once for each instance.
> > > > Obviously, only one instance should succeed, and the other
> > > should fail.
> > > >
> > > > Check the registry and see if you also have two entries in the ENUM
> > > > tree.
> > > >
> > > > After much effort trying to find an incantation of the .inf
> > > file that
> > > > resolved the problem without success, I wrote an install app instead
> > > > that doesn’t use an .inf file to do the installation of the
> > > driver (like
> > > > I used to do for NT 4.0 drivers), and that resolved the
> > > problem. Not
> > > > exactly the solution I had in mind, but I had to deliver
> > > something to my
> > > > client, and that did it.
> > > >
> > > > I also was specifying an “Internal” bus, but the problem
> > > remained even
> > > > if I specified an “ISA” bus (on the loose association that
> > > the serial
> > > > port exists on the ISA bus).
> > > >
> > > > If you are facing the same issue, and you figure out the
> > > right .inf file
> > > > incantation to resolve the problem, please let me know for future
> > > > reference.
> > > >
> > > > - Jay
> > > >
> > > > Jay Talbott
> > > > Principal Consulting Engineer
> > > > SysPro Consulting, LLC
> > > > 3519 E. South Fork Drive
> > > > Suite 201
> > > > Phoenix, AZ 85044
> > > > (480) 704-8045
> > > > xxxxx@sysproconsulting.com
> > > > http://www.sysproconsulting.com
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: xxxxx@lists.osr.com
> > > > > [mailto:xxxxx@lists.osr.com] On Behalf Of
> > > Gary G. Little
> > > > > Sent: Tuesday, July 02, 2002 8:34 AM
> > > > > To: NT Developers Interest List
> > > > > Subject: [ntdev] SCSI miniport AddDevice …
> > > > >
> > > > >
> > > > > My current project is a SCSI miniport that requires an
> > > interface to a
> > > > > proprietary bus driver. If you have noticed, ScsiPort provides no
> > > > > methodology, that I could discover, whereby a miniport can
> > > > > acquire such an
> > > > > interface. In that light, I do an awful lot of stuff in an
> > > > > NTDDK starboard
> > > > > edge of the miniport. The only way I could think of to
> > > acquire the bus
> > > > > interface I needed was to somehow acquire the PDO that is
> > > > > generated by the
> > > > > bus driver when it enumerates it’s bus. The simplest method
> > > > > would be to use
> > > > > an AddDevice … but AddDevice is owned by ScsiPort, as are
> > > > > all the other
> > > > > Dispatch entry points in the DriverObject, and I really
> > > > > really need access
> > > > > to that bus driver PDO that ScsiPort is going to get when the
> > > > > PnP manager
> > > > > calls ScsiPort->AddDevice.
> > > > >
> > > > > Since I was already compiling for a NTDDK edge I simply said
> > > > > “Aww screw-it”
> > > > > and hooked the AddDevice routine in DriverEntry when
> > > > > ScsiPortInitialize
> > > > > returns. My AddDevice then squirrels away the PDO that is
> > > > > passed to it by
> > > > > the PnP manager and makes the PnP calls needed to properly
> > > > > acquire the bus
> > > > > interface that was needed. My AddDevice then calls
> > > > > ScsiPort->AddDevice,
> > > > > passing it the pointer to the DriverObject and the PDO.
> > > > >
> > > > > Since this is not a PCI or EISA or even ISA bus, I define
> > > things as an
> > > > > Internal bus in both the registry PnPInterface and the
> > > > > AdapterInterfaceType,
> > > > > and there lies the problem — I think. I get two calls to
> > > > > the AddDevice
> > > > > function. The first call to AddDevice is with a PDO that is
> > > > > pointing to
> > > > > \Driver\PnPManager, which generally fails everything I
> > > want to do. The
> > > > > second call is with a PDO pointing to \Driver\FibreGear. That
> > > > > one is good
> > > > > since it is the PDO enumerated by my bus driver. I am
> > > > > currently failing the
> > > > > first call, but the real question is why the bloody hell do I
> > > > > get it? Is
> > > > > this normal? What should I do with it? Pass it to ScsiPort
> > > > > who would have
> > > > > gotten it in the first place? Or should I fail it, and if so
> > > > > fail it with
> > > > > what status?
> > > > >
> > > > > Yeah I know … I’m tramping in areas where I shouldn’t …
> > > > > but we got’s
> > > > > customers who want to pay us tons of money to do it this way.
> > > > > And no … I
> > > > > can’t layer things on top of a standard SCSIMINIPORT, circa
> > > > > class/filter,
> > > > > since the bus driver provides an ISR and interface to a peer
> > > > > to peer layer
> > > > > that may transfer 4 MByte buffers and 4K-1 sized scatter
> > > > > gather lists. That
> > > > > side does 100+ megabytes per second … the best SCSI
> > > > > performance we have
> > > > > seen is 80+MBps to a 4 disk JBOD. With 2 Gigabit boards we
> > > > > expect to double
> > > > > our peer to peer rates.
> > > > >
> > > > > –
> > > > > Gary G. Little
> > > > > xxxxx@broadstor.com
> > > > > xxxxx@inland.net
> > > > >
> > > > >
> > > > >
> > > > > —
> > > > > You are currently subscribed to ntdev as:
> > > > > xxxxx@sysproconsulting.com
> > > > > To unsubscribe send a blank email to %%email.unsub%%
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> > > xxxxx@sysproconsulting.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> > >
> >
> >
> >
>
>
>
>
