Strange SCSI miniport problem

In my SCSI miniport driver I have MapBuffers=TRUE
and MaximumTransferLength=64*1024.

In a call made by the SCSI port to HwScsiStartIo
I’m receiving (example):

Srb 81473CA8
Srb->DataBuffer 81472000
Srb->TransferLength 10000

So if I fill the buffer passed I destroy the Srb and probably something else.
This miniport works ok when MaximumTransferLength=512
but any bigger MaximumTransferLength causes above.

Any ideas what can it mean?

thanks,

Gera.


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

>In a call made by the SCSI port to HwScsiStartIo

I’m receiving (example):

Srb 81473CA8
Srb->DataBuffer 81472000
Srb->TransferLength 10000

So if I fill the buffer passed I destroy the Srb and probably something else.
This miniport works ok when MaximumTransferLength=512
but any bigger MaximumTransferLength causes above.

Any ideas what can it mean?

Perhaps your just seeing some stupid application. If the transfer size in
the CDB is small, this will not really overwrite the SRB. What do the
transfer direction flags say? What does the SCSI command say about the
transfer length?

  • Jan

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

> In my SCSI miniport driver I have MapBuffers=TRUE

and MaximumTransferLength=64*1024.

In a call made by the SCSI port to HwScsiStartIo
I’m receiving (example):

Srb 81473CA8
Srb->DataBuffer 81472000
Srb->TransferLength 10000

I found that Srb->DataBuffer points to first 512 block
of some hidden list of blocks, not to whole 8192 buffer.

Anyone knows how to get info about this list?

Anyone has experience with program (not DMA)
access to SRB data buffers on W2K?
It seems it is different from NT4…

thanks,

Gera.


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

Gera,

I think I had a similar problem with a miniport that used busmaster
non-scattergather dma, but also had to sometimes access the DataBuffer using
a virtual address and do PIO. I think I came to the conclusion that this
particular combination is not actually supported, which is to say you have
hit a bug. It looked to me like it was associated with the nonsense that
scsiport was doing to implement scattergather list support and IoMapTransfer
behind the scenes. I have no idea if it is documented or not. The
work-around I came up with was to (!horrors!) lie about my scatter-gather
capabilities and implement my own ‘bounce-buffer’ (using a non-cached
extension) to get the data in and out of the system. Once I did that my
DataBuffer appeared to be a valid systemVA with the appropriate contents. On
reflection, this is a better approach from my driver’s performance
perspective anyhow, as I don’t have to queue up with anyone else waiting for
‘map registers’, and those map registers were going to incur the same data
copy cost as my bounce buffer anyhow.

-----Original Message-----
From: Gera Kazakov [mailto:xxxxx@setengineering.com]
Sent: Wednesday, November 14, 2001 10:04 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Strange SCSI miniport problem

In my SCSI miniport driver I have MapBuffers=TRUE
and MaximumTransferLength=64*1024.

In a call made by the SCSI port to HwScsiStartIo
I’m receiving (example):

Srb 81473CA8
Srb->DataBuffer 81472000
Srb->TransferLength 10000

I found that Srb->DataBuffer points to first 512 block
of some hidden list of blocks, not to whole 8192 buffer.

Anyone knows how to get info about this list?

Anyone has experience with program (not DMA)
access to SRB data buffers on W2K?
It seems it is different from NT4…

thanks,

Gera.


You are currently subscribed to ntdev as: xxxxx@stratus.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

Mark,

Thank you for the info. I’ll try to trick the SCSI port your way.
But I afraid this will force the SCSI port to perform extra
copy to assemble/disassemble scatter/gather list it naturally has.

For now I’ve outsmarted it by reporting in the READ CAPACITY
that my block size is 4K (i’m emulating a disk drive, btw) and
setting same 4K as a MaxTransferLength.
After that i’m getting DataBuffer pointing to 4K block,
i’m checking it in the associated Mdl. I believe that it is still
a scatttergather list fortunately containing just one element.

Of course this solution is bad. I cannot increase the block length
infinitely. Even with this 4K size I cannot format disk
to FAT or FAT32. NTFS, however, works fine.
A good solution for this can be accessing that internal
scatter/gather list directly. Well, it will probably not be portable
but any other solution I know for now is even worse.

Reading this list I learned that many people have
written SCSI miniports, or writing it now or… It would be
interesting to know it someone else already faced to
this problem and has some solution for it.

----- Original Message -----
From: “Roddy, Mark”
To: “NT Developers Interest List”
Sent: Wednesday, November 14, 2001 11:30 AM
Subject: [ntdev] Re: Strange SCSI miniport problem

> Gera,
>
> I think I had a similar problem with a miniport that used busmaster
> non-scattergather dma, but also had to sometimes access the DataBuffer using
> a virtual address and do PIO. I think I came to the conclusion that this
> particular combination is not actually supported, which is to say you have
> hit a bug. It looked to me like it was associated with the nonsense that
> scsiport was doing to implement scattergather list support and IoMapTransfer
> behind the scenes. I have no idea if it is documented or not. The
> work-around I came up with was to (!horrors!) lie about my scatter-gather
> capabilities and implement my own ‘bounce-buffer’ (using a non-cached
> extension) to get the data in and out of the system. Once I did that my
> DataBuffer appeared to be a valid systemVA with the appropriate contents. On
> reflection, this is a better approach from my driver’s performance
> perspective anyhow, as I don’t have to queue up with anyone else waiting for
> ‘map registers’, and those map registers were going to incur the same data
> copy cost as my bounce buffer anyhow.
>
>
> -----Original Message-----
> From: Gera Kazakov [mailto:xxxxx@setengineering.com]
> Sent: Wednesday, November 14, 2001 10:04 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Strange SCSI miniport problem
>
>
> > In my SCSI miniport driver I have MapBuffers=TRUE
> > and MaximumTransferLength=64*1024.
> >
> > In a call made by the SCSI port to HwScsiStartIo
> > I’m receiving (example):
> >
> > Srb 81473CA8
> > Srb->DataBuffer 81472000
> > Srb->TransferLength 10000
>
> I found that Srb->DataBuffer points to first 512 block
> of some hidden list of blocks, not to whole 8192 buffer.
>
> Anyone knows how to get info about this list?
>
> Anyone has experience with program (not DMA)
> access to SRB data buffers on W2K?
> It seems it is different from NT4…
>
> thanks,
>
> Gera.
>
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@setengineering.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

It will only be an extra copy if you support more than one scatter/gather
element, otherwise scsiport will use ‘map registers’ and copy the data
anyhow. My miniport did not do scatter/gather (i.e. one element only,) so I
could afford the copy. Besides 4K at a time like sucks, dude. What the heck
does a 2G cpu have to do anyhow besides wait for PCI bus transactions and
move data from one location to another :slight_smile:

-----Original Message-----
From: Gera Kazakov [mailto:xxxxx@setengineering.com]
Sent: Thursday, November 15, 2001 10:02 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Strange SCSI miniport problem

Mark,

Thank you for the info. I’ll try to trick the SCSI port your way. But I
afraid this will force the SCSI port to perform extra copy to
assemble/disassemble scatter/gather list it naturally has.

For now I’ve outsmarted it by reporting in the READ CAPACITY that my block
size is 4K (i’m emulating a disk drive, btw) and setting same 4K as a
MaxTransferLength. After that i’m getting DataBuffer pointing to 4K block,
i’m checking it in the associated Mdl. I believe that it is still a
scatttergather list fortunately containing just one element.

Of course this solution is bad. I cannot increase the block length
infinitely. Even with this 4K size I cannot format disk to FAT or FAT32.
NTFS, however, works fine. A good solution for this can be accessing that
internal scatter/gather list directly. Well, it will probably not be
portable but any other solution I know for now is even worse.

Reading this list I learned that many people have
written SCSI miniports, or writing it now or… It would be interesting to
know it someone else already faced to this problem and has some solution for
it.

----- Original Message -----
From: “Roddy, Mark”
To: “NT Developers Interest List”
Sent: Wednesday, November 14, 2001 11:30 AM
Subject: [ntdev] Re: Strange SCSI miniport problem

> Gera,
>
> I think I had a similar problem with a miniport that used busmaster
> non-scattergather dma, but also had to sometimes access the DataBuffer
> using a virtual address and do PIO. I think I came to the conclusion
> that this particular combination is not actually supported, which is
> to say you have hit a bug. It looked to me like it was associated with
> the nonsense that scsiport was doing to implement scattergather list
> support and IoMapTransfer behind the scenes. I have no idea if it is
> documented or not. The work-around I came up with was to (!horrors!)
> lie about my scatter-gather capabilities and implement my own
> ‘bounce-buffer’ (using a non-cached
> extension) to get the data in and out of the system. Once I did that my
> DataBuffer appeared to be a valid systemVA with the appropriate contents.
On
> reflection, this is a better approach from my driver’s performance
> perspective anyhow, as I don’t have to queue up with anyone else waiting
for
> ‘map registers’, and those map registers were going to incur the same data
> copy cost as my bounce buffer anyhow.
>
>
> -----Original Message-----
> From: Gera Kazakov [mailto:xxxxx@setengineering.com]
> Sent: Wednesday, November 14, 2001 10:04 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Strange SCSI miniport problem
>
>
> > In my SCSI miniport driver I have MapBuffers=TRUE
> > and MaximumTransferLength=64*1024.
> >
> > In a call made by the SCSI port to HwScsiStartIo
> > I’m receiving (example):
> >
> > Srb 81473CA8
> > Srb->DataBuffer 81472000
> > Srb->TransferLength 10000
>
> I found that Srb->DataBuffer points to first 512 block
> of some hidden list of blocks, not to whole 8192 buffer.
>
> Anyone knows how to get info about this list?
>
> Anyone has experience with program (not DMA)
> access to SRB data buffers on W2K?
> It seems it is different from NT4…
>
> thanks,
>
> Gera.
>
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@setengineering.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@stratus.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