Why so many SCSIOP_TEST_UNIT_READY

NTDEV
1

Hi folks,

I am designing a virtual SCSI miniport driver. When this driver services
a block device. START_IO routine will receive a lot of
SCSIOP_TEST_UNIT_READY and SCSI_READ command. I know that file system
will read some data block to get some info. But why my miniport driver
receive so many SCSIOP_TEST_UNIT_READY command. When such driver
services a boot disk, it receives about more than 130
SCSIOP_TEST_UNIT_READY commands, even after can read and write data
from/to disk which miniport driver serviced. In my driver, for
SCSIOP_TEST_UNIT_READY command , I just return success with
Srb->SrbStatus = SRB_STATUS_SUCCESS and Srb->ScsiStatus = 0. Is that
correct?

Another issue is about disk capacity. In ‘My computer’, I cannot see
disk capacity and disk usage which my miniport driver serviced. But I
can get them from ‘disk property’. Disk capacity is OK but usage is not
correctly. Why?

Here is the code of READ_CAPACITY

PVOID buffer = Srb->DataBuffer;
ULONG BytePerBlock = disk->sectorSize;// disk sector size
ULONG LogicalBlockAddress = disk->sectors -1; // disk capacity

REVERSE_BYTES(&(((PREAD_CAPACITY_DATA)buffer)->BytesPerBlock),
&BytePerBlock);
REVERSE_BYTES(&(((PREAD_CAPACITY_DATA)buffer)->LogicalBlockAddress),
&LogicalBlockAddress);

Best regards – Wayne

2

I Dont know the reason why TEST_UNIT_READY is getting called so many times.

About disk capacity:
The code looks just fine.

You dont see disk capacity in my computer is because maybe you have set your
device as Removable Media in SCSIOP_INQUIRY (InquiryData.RemovableMedia =
1). Set it to 0.
(Just a trivial thing - You might have overlooked explorer view which
doesn't show disk usages. Set it to Details)

In property page you can see the disk capacity correct but not the disk
usage. Because Disk capacity is reported correctly by your driver, hence you
can see correct disk capacity. And disk usage has nothing to do with disk
capacity. This is file systems job to report disk usage. May be the format
is going wrong somewhere, of course because of some corner case in
SCSIOP_READ or SCSIOP_WRITE.

Check that first.

--
Thanks and Regards,

Charansing D Deore
Sr. Software Developer,
CalSoft Pvt Ltd.
Baner Road, Pune-411045
Office: +91 20 39853000 Ext: 3055
Cell: +91 9850960550

On Wed, Sep 17, 2008 at 8:21 AM, Wayne Gong wrote:

> Hi folks,
>
> I am designing a virtual SCSI miniport driver. When this driver services a
> block device. START_IO routine will receive a lot of SCSIOP_TEST_UNIT_READY
> and SCSI_READ command. I know that file system will read some data block to
> get some info. But why my miniport driver receive so many
> SCSIOP_TEST_UNIT_READY command. When such driver services a boot disk, it
> receives about more than 130 SCSIOP_TEST_UNIT_READY commands, even after can
> read and write data from/to disk which miniport driver serviced. In my
> driver, for SCSIOP_TEST_UNIT_READY command , I just return success with
> Srb->SrbStatus = SRB_STATUS_SUCCESS and Srb->ScsiStatus = 0. Is that
> correct?
>
> Another issue is about disk capacity. In 'My computer', I cannot see disk
> capacity and disk usage which my miniport driver serviced. But I can get
> them from 'disk property'. Disk capacity is OK but usage is not correctly.
> Why?
>
> Here is the code of READ_CAPACITY
>
> PVOID buffer = Srb->DataBuffer;
> ULONG BytePerBlock = disk->sectorSize;// disk sector size
> ULONG LogicalBlockAddress = disk->sectors -1; // disk capacity
>
> REVERSE_BYTES(&(((PREAD_CAPACITY_DATA)buffer)->BytesPerBlock),
> &BytePerBlock);
> REVERSE_BYTES(&(((PREAD_CAPACITY_DATA)buffer)->LogicalBlockAddress),
> &LogicalBlockAddress);
>
> Best regards -- Wayne
>
> ---
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> OSR Seminars – OSR
>
> To unsubscribe, visit the List Server section of OSR Online at
> ListServer/Forum
>

3

Dump the callstack when you are presented the TUR. It might give you a clue as to which component (user or kernel) is sending it

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Charansing Rajput
Sent: Tuesday, September 16, 2008 11:15 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Why so many SCSIOP_TEST_UNIT_READY

I Dont know the reason why TEST_UNIT_READY is getting called so many times.

About disk capacity:
The code looks just fine.

You dont see disk capacity in my computer is because maybe you have set your device as Removable Media in SCSIOP_INQUIRY (InquiryData.RemovableMedia = 1). Set it to 0.
(Just a trivial thing - You might have overlooked explorer view which doesn't show disk usages. Set it to Details)

In property page you can see the disk capacity correct but not the disk usage. Because Disk capacity is reported correctly by your driver, hence you can see correct disk capacity. And disk usage has nothing to do with disk capacity. This is file systems job to report disk usage. May be the format is going wrong somewhere, of course because of some corner case in SCSIOP_READ or SCSIOP_WRITE.

Check that first.

--
Thanks and Regards,

Charansing D Deore
Sr. Software Developer,
CalSoft Pvt Ltd.
Baner Road, Pune-411045
Office: +91 20 39853000 Ext: 3055
Cell: +91 9850960550

On Wed, Sep 17, 2008 at 8:21 AM, Wayne Gong > wrote:
Hi folks,

I am designing a virtual SCSI miniport driver. When this driver services a block device. START_IO routine will receive a lot of SCSIOP_TEST_UNIT_READY and SCSI_READ command. I know that file system will read some data block to get some info. But why my miniport driver receive so many SCSIOP_TEST_UNIT_READY command. When such driver services a boot disk, it receives about more than 130 SCSIOP_TEST_UNIT_READY commands, even after can read and write data from/to disk which miniport driver serviced. In my driver, for SCSIOP_TEST_UNIT_READY command , I just return success with Srb->SrbStatus = SRB_STATUS_SUCCESS and Srb->ScsiStatus = 0. Is that correct?

Another issue is about disk capacity. In 'My computer', I cannot see disk capacity and disk usage which my miniport driver serviced. But I can get them from 'disk property'. Disk capacity is OK but usage is not correctly. Why?

Here is the code of READ_CAPACITY

PVOID buffer = Srb->DataBuffer;
ULONG BytePerBlock = disk->sectorSize;// disk sector size
ULONG LogicalBlockAddress = disk->sectors -1; // disk capacity

REVERSE_BYTES(&(((PREAD_CAPACITY_DATA)buffer)->BytesPerBlock), &BytePerBlock);
REVERSE_BYTES(&(((PREAD_CAPACITY_DATA)buffer)->LogicalBlockAddress), &LogicalBlockAddress);

Best regards -- Wayne

---
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit: OSR Seminars – OSR

To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum

--- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: OSR Seminars – OSR To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum

4

Charansing Rajput wrote:

I Dont know the reason why TEST_UNIT_READY is getting called so many
times.

About disk capacity:
The code looks just fine.

You dont see disk capacity in my computer is because maybe you have
set your device as Removable Media in SCSIOP_INQUIRY
(InquiryData.RemovableMedia = 1). Set it to 0.
(Just a trivial thing - You might have overlooked explorer view which
doesn’t show disk usages. Set it to Details)

In property page you can see the disk capacity correct but not the
disk usage. Because Disk capacity is reported correctly by your
driver, hence you can see correct disk capacity. And disk usage has
nothing to do with disk capacity. This is file systems job to report
disk usage. May be the format is going wrong somewhere, of course
because of some corner case in SCSIOP_READ or SCSIOP_WRITE.

As your advice, after I set InquiryData.RemovableMedia = 0.
TEST_UNIT_READY is ok now. For the disk usage issue, I figure out that
maybe the problem is coursed by the architecture of my design.

I am developing a Xen VM windows paravirtual driver. For a virtual disk
from xen, there are working model in a windows VM. One is Qemu and the
other is paravirtual front end. So, for a block device, there is an Qemu
block device represents in windows. Now, I am developing a virtual scsi
miniport driver which represents the paravirtual front end device. For
only one block device, there are two different drivers services for it.
So, I think the key point is that I need to hide the Qemu block device
driver and use only my scsi miniport driver to service the block device.

So the current question is: How can I hide the Qemu device. In my
opinion, one approach is to write a system bus filter driver to hide the
device.(Also, I need to hide the Qemu network device since I will design
a network paravirtual front driver after I finish the miniport driver.).
So is there any alternative?

Best regards-- Wayne

5

How about disabling or uinstalling the device in device manager?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Wayne Gong
Sent: Tuesday, September 16, 2008 11:37 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Why so many SCSIOP_TEST_UNIT_READY

Charansing Rajput wrote:

I Dont know the reason why TEST_UNIT_READY is getting called so many
times.

About disk capacity:
The code looks just fine.

You dont see disk capacity in my computer is because maybe you have
set your device as Removable Media in SCSIOP_INQUIRY
(InquiryData.RemovableMedia = 1). Set it to 0.
(Just a trivial thing - You might have overlooked explorer view which
doesn’t show disk usages. Set it to Details)

In property page you can see the disk capacity correct but not the
disk usage. Because Disk capacity is reported correctly by your
driver, hence you can see correct disk capacity. And disk usage has
nothing to do with disk capacity. This is file systems job to report
disk usage. May be the format is going wrong somewhere, of course
because of some corner case in SCSIOP_READ or SCSIOP_WRITE.

As your advice, after I set InquiryData.RemovableMedia = 0.
TEST_UNIT_READY is ok now. For the disk usage issue, I figure out that
maybe the problem is coursed by the architecture of my design.

I am developing a Xen VM windows paravirtual driver. For a virtual disk
from xen, there are working model in a windows VM. One is Qemu and the
other is paravirtual front end. So, for a block device, there is an Qemu
block device represents in windows. Now, I am developing a virtual scsi
miniport driver which represents the paravirtual front end device. For
only one block device, there are two different drivers services for it.
So, I think the key point is that I need to hide the Qemu block device
driver and use only my scsi miniport driver to service the block device.

So the current question is: How can I hide the Qemu device. In my
opinion, one approach is to write a system bus filter driver to hide the
device.(Also, I need to hide the Qemu network device since I will design
a network paravirtual front driver after I finish the miniport driver.).
So is there any alternative?

Best regards-- Wayne

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

6

Doron Holan wrote:

How about disabling or uinstalling the device in device manager?

It 's the boot device, so I cannot disable or uninstall that device in
device manager.

7

I am pretty sure you can do both, you just need to reboot to have it take effect.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Wayne Gong
Sent: Tuesday, September 16, 2008 11:51 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Why so many SCSIOP_TEST_UNIT_READY

Doron Holan wrote:

How about disabling or uinstalling the device in device manager?

It 's the boot device, so I cannot disable or uninstall that device in
device manager.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

8

Find out the driver name which is by default servicing this block device. In
registry, under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services you
will find this service, in its start type set 1 or 3. and for your driver
set it to 0.

This should load your driver as a boot scsi driver and the default as a non
boot driver. your driver will automatically start servicing the qemu disk.

Thanks and Regards,

Charansing D Deore
Sr. Software Developer,
CalSoft Pvt Ltd.
Baner Road, Pune-411045
Office: +91 20 39853000 Ext: 3055
Cell: +91 9850960550

On Wed, Sep 17, 2008 at 12:07 PM, Wayne Gong wrote:

> Charansing Rajput wrote:
>
>> I Dont know the reason why TEST_UNIT_READY is getting called so many
>> times.
>>
>> About disk capacity:
>> The code looks just fine.
>>
>> You dont see disk capacity in my computer is because maybe you have set
>> your device as Removable Media in SCSIOP_INQUIRY (InquiryData.RemovableMedia
>> = 1). Set it to 0.
>> (Just a trivial thing - You might have overlooked explorer view which
>> doesn't show disk usages. Set it to Details)
>>
>> In property page you can see the disk capacity correct but not the disk
>> usage. Because Disk capacity is reported correctly by your driver, hence you
>> can see correct disk capacity. And disk usage has nothing to do with disk
>> capacity. This is file systems job to report disk usage. May be the format
>> is going wrong somewhere, of course because of some corner case in
>> SCSIOP_READ or SCSIOP_WRITE.
>>
>> As your advice, after I set InquiryData.RemovableMedia = 0.
> TEST_UNIT_READY is ok now. For the disk usage issue, I figure out that maybe
> the problem is coursed by the architecture of my design.
>
> I am developing a Xen VM windows paravirtual driver. For a virtual disk
> from xen, there are working model in a windows VM. One is Qemu and the other
> is paravirtual front end. So, for a block device, there is an Qemu block
> device represents in windows. Now, I am developing a virtual scsi miniport
> driver which represents the paravirtual front end device. For only one block
> device, there are two different drivers services for it. So, I think the key
> point is that I need to hide the Qemu block device driver and use only my
> scsi miniport driver to service the block device.
>
> So the current question is: How can I hide the Qemu device. In my opinion,
> one approach is to write a system bus filter driver to hide the
> device.(Also, I need to hide the Qemu network device since I will design a
> network paravirtual front driver after I finish the miniport driver.). So is
> there any alternative?
>
>
> Best regards-- Wayne
>
> ---
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> OSR Seminars – OSR
>
> To unsubscribe, visit the List Server section of OSR Online at
> ListServer/Forum
>

--

9

Hi folks,

I have write a filter driver to hide devices which I don’t need. In this
filter driver, I will read a System Start Options register key to
determine whether we need to hide devices. So I can edit boot.ini to
tell the filter driver to hide devices which I don’t need. So thank you all.

Best regards – Wayne

10

I just have to ask: How many Windows PV Storage Drivers for Xen does the world really need? There are already several companies who have PV Windows drivers for (some flavor of Xen), including some that perform exceptionally well. There are also open-source PV drivers.

And here I thought the whole “open source” thing was about not re-inventing the world,

Peter
OSR

11

More is always better. Quantity vs Quality…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, September 19, 2008 12:42 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Why so many SCSIOP_TEST_UNIT_READY

I just have to ask: How many Windows PV Storage Drivers for Xen does the
world really need? There are already several companies who have PV
Windows drivers for (some flavor of Xen), including some that perform
exceptionally well. There are also open-source PV drivers.

And here I thought the whole “open source” thing was about not
re-inventing the world,

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

12

Mark Cariddi wrote:

More is always better. Quantity vs Quality…

More importantly, perhaps, is that programmers never trust code they
didn’t write. That seems to be especially true in India, where the big
shops much prefer to do it themselves rather than reuse known good code.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

Tim Roberts wrote:

Mark Cariddi wrote:
> More is always better. Quantity vs Quality…
>

More importantly, perhaps, is that programmers never trust code they
didn’t write. That seems to be especially true in India, where the big
shops much prefer to do it themselves rather than reuse known good code.

By the same token, why shops in India would trust Not Made Here code.

–pa

14

In fact there are two conflicting choices: (1) Trust code written by
others ( in source or binary form) and reuse; (2) Don’t trust code
written by others (source or binary form).

From a pure programmers point of view, no one should trust others code.
From the productivity point of view trust as much code as possible from
others … And it really boils down to the culture of the shop along
with the current designer(programmer). On the top of it, how much effort
could be devoted to do the work …

I try to take a middle ground: Trust but be watchful. Leave the rest on
probability of shits to happen :). Since taking everything on my own
hand does not necessarily decreases the probability of shit to happen…

-pro

Pavel A. wrote:

Tim Roberts wrote:
> Mark Cariddi wrote:
>> More is always better. Quantity vs Quality…
>>
>
> More importantly, perhaps, is that programmers never trust code they
> didn’t write. That seems to be especially true in India, where the big
> shops much prefer to do it themselves rather than reuse known good code.
>

By the same token, why shops in India would trust Not Made Here code.

–pa

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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