NumberOfPhysicalBreaks of Scsi Miniport Driver

NTDEV
1

Hi,

My driver is a virtual scsi miniport driver. In the FindAdapter routine, I set:

ConfigInfo->MaximumTransferLength = 0x20000;
ConfigInfo->NumberOfPhysicalBreaks = 0x11; // 0x30;
ConfigInfo->MaximumNumberOfLogicalUnits = 1;
ConfigInfo->ScatterGather = TRUE; // FALSE; // fuck off scatter/gather
ConfigInfo->Master = TRUE; // FALSE; // NOT bus master
ConfigInfo->NeedPhysicalAddresses = FALSE;
ConfigInfo->CachesData = TRUE;
ConfigInfo->TaggedQueuing = FALSE;
ConfigInfo->AlignmentMask = 0x0;

However, on XP 32 with running spti.exe in DDK it always shows:

MaximumPhysicalPages: 00000008
TrueMaximumTransfer: 00007000 (bytes)

I event try to set ConfigInfo->NumberOfPhysicalBreaks to other bigger value but it’s always 8

On XP 64, spti.exe shows the correct value of:
MaximumPhysicalPages: 00000011

So, what’s wrong with my code? Thanks for any idea.

Regards
R. Y.

2

So you actually want 18 physical breaks? The docs state number minus 1, so 0x11 being one short, your actual number is 18 (0x11=17). That means 8 gives you 9.

That aside, have you scanned the list for virtual SCSIPORT miniports? Virtual SCSI miniports have been discussed many times here and in the Microsoft forums. I’m assuming you have a nifty little widget and a nifty little driver to control it, and now you want to write a nifty virtual SCSIPORT to provide a nifty interface for your nifty driver and nifty widget to interact with the storage stack. In actuality it’s a nifty way to burn up about 18 months, and ask a splendiferous amount of questions here, which will always be answered with “you can’t do that”.

The personal opinion of
Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@ybwork.com
Sent: Monday, July 17, 2006 8:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NumberOfPhysicalBreaks of Scsi Miniport Driver

Hi,

My driver is a virtual scsi miniport driver. In the FindAdapter routine, I set:

ConfigInfo->MaximumTransferLength = 0x20000;
ConfigInfo->NumberOfPhysicalBreaks = 0x11; // 0x30;
ConfigInfo->MaximumNumberOfLogicalUnits = 1;
ConfigInfo->ScatterGather = TRUE; // FALSE; // fuck off scatter/gather
ConfigInfo->Master = TRUE; // FALSE; // NOT bus master
ConfigInfo->NeedPhysicalAddresses = FALSE;
ConfigInfo->CachesData = TRUE;
ConfigInfo->TaggedQueuing = FALSE;
ConfigInfo->AlignmentMask = 0x0;

However, on XP 32 with running spti.exe in DDK it always shows:

MaximumPhysicalPages: 00000008
TrueMaximumTransfer: 00007000 (bytes)

I event try to set ConfigInfo->NumberOfPhysicalBreaks to other bigger value but it’s always 8

On XP 64, spti.exe shows the correct value of:
MaximumPhysicalPages: 00000011

So, what’s wrong with my code? Thanks for any idea.

Regards
R. Y.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

__________ NOD32 1.1663 (20060716) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

3

> So you actually want 18 physical breaks? The docs state number minus 1, so 0x11

being one short, your actual number is 18 (0x11=17). That means 8 gives you 9.

Then, how does Windows get 8 from 18? Is this defined by DMA spec or something else? It’s also so weird that I can not change this value in my driver.

In fact, my problem is caused by the value of TrueMaximumTransfer. 0x7000 is too small for some applications which send large buffers. In this case, scsiport.sys just denies SPTI commands with 0xc000000d. So, my purpose is enlarging TrueMaximumTransfer to 0x10000. Any idea about this?

BTW: About virtual scsi miniport topics, I knew those posts, articles and arguments 4+ years ago when I started this product. Especially ppl who argue about DO & DO NOT. :slight_smile:

4

Writing a driver is a lot like cooking. Microsoft offers recipes through examples of how to write particular drivers. When you need to make your own driver, stick to the Microsoft recipe and you’ll get a good result. Sometimes Microsoft has no practical recipe, like a virtual storage device. People then create their own recipes from scratch, but the problem is to do a good job you need to be a master chef who can blend all the right ingredients just right. A lot of people don’t understand this and they just end up making bad recipes that continually fail in the field, one revision after another. This makes the driver writer look bad, the company whose flag they are under look bad, and ultimately makes Microsoft look bad when Windows doesn’t work right. And surely none of us want one of those drivers on our machine.

There traditionally have been two reasons why people wanted to go the virtual scsi miniport route. First, for Win9x binary compatibility. Needless to say, no one really cares about this anymore; advantage gone. Second, because writing a full bus driver is many, many thousands of lines of complicated spaghetti code dealing with all sorts of things you really don’t care about. This has been simplified with the introduction of KMDF, but you’re still looking at about 2000 lines of code to pull off a virtual scsi device.

You can also make a rock solid, concise virtual scsi miniport by starting with a proven recipe; that is if you can find one. You’ll get solid results, improved time to market, and everyone will look good and be happy. Here’s one:

http://www.perisoft.net/miniram/index.htm

In regards to your specific problem, you will note the following (correct) output from spti when loading this miniport:

***** STORAGE ADAPTER DESCRIPTOR DATA *****
Version: 00000020
TotalSize: 00000020
MaximumTransferLength: ffffffff (bytes)
MaximumPhysicalPages: 00100000
TrueMaximumTransfer: fffff000 (bytes)
AlignmentMask: 00000000
AdapterUsesPio: True
AdapterScansDown: False
CommandQueueing: False
AcceleratedTransfer: True
Bus Type: Scsi
Bus Major Version: 0002
Bus Minor Version: 0000

eof

5

A long long long long…reply :slight_smile:

Anyway, I got what I need after lots of tests.

On XP 32, ConfigInfo->Master *must* be FALSE to enable NumberOfPhysicalBreaks > 8

On XP 64, ConfigInfo->Master *must* be TRUE. Otherwise the adapter can not be started.

I didn’t check if these are the default settings on XP 32 & 64. Any reason for such values?