re-enumerating the disks;

NTDEV
1

is there a way to to force the re-enumeration of the disks? I need (ata)port driver to re-issue the identify data command and re-report the attached disks to the system.

To achieve this I did the following:

  1. wait for all the current disks to get started.
  2. call IoInvalidateDeviceRelations (, BusRelations). Probably I should do this with FDO which is also the bus driver for the channels/disk PDOs.
    3. I noticed that port driver did indeed go through the same process of enumeration and issued the identify data command to the miniport.

    Now my questions are:
    1. is it the correct way of doing it? if not kindly suggest an alternative.
    2. Also is there a possibility that miniport may not actually query the device for identify data for the second time and may return the cached data since the disk device was never physically removed from the system.

    Thanks.
2

Reading the archives on NTDEV and msdn indicates probably calling IoInvalidateDeviceRelations is not enough as port driver (the bus driver for disk PDOs) keeps the disk PDO and will report the same everytime.

Is this is the correct flow:

  1. fail the start on the way up in my port filter driver for the desired disk PDO.
  2. pnp will issue REMOVE which will cause port driver to delete the disk PDO.
  3. then in my port filter I call IoInvalidateDeviceRelations.
  4. Pnp will send QDR/BusRelations.
  5. port driver will re-enumerate disks and create new disk PDO.

Am I on the right track? Please advise. Thanks.

3

> is there a way to to force the re-enumeration of the disks? I need (ata)port driver to re-issue the

identify data command and re-report the attached disks to the system.

IOCTL_SCSI_RESCAN_BUS can probably help.

Also you can disable the ATA controller devnode using SetupDiXxx and enable it back. You cannot do this for the boot controller though.

IoInvalidateDeviceRelations is not enough, since ATA port can cache identify responses and respond to MN_QUERY_RELATIONS using cached info.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

4

Thanks Maxim.

as per msdn IOCTL_SCSI_RESCAN_BUS is for legacy drivers only so probably I can’t use it.
disable/enable using setupDi* is not an option for me as my target is boot controller.

My requirement is to force the portdriver to re-obtain identify data from the target disk and re-report it to the system.

5

Try:

a) devmgmt.msc + Scan For Hardware Changes
and
b) run diskmgmt.msc

after adding the disk physically (powering up a eSATA external box or such).

If a) will work - then yes, IoInvalidateDeviceRelations is enough.
If a) will not work - then IoInvalidateDeviceRelations will not work too.

Then, for the b) case, use some IRP tracing tool to trace the IOCTLs sent by diskmgmt.msc at startup. Probably it sends the legacy IOCTL_SCSI_RESCAN_BUS.

Probably this legacy IOCTL is just plain the only way. Probably there are other controller-specific undocumented IOCTLs.

And, if the b) path does not work - then sorry, no ways at all, thanks MS for forgetting to add this functionality to ATAPORT. Probably this is also the case.

In this latter case, just require the AHCI controller for your product, it’s driver (Vista+) surely supports hot disk arrival (though it does not work always due to some strange electrical or software cases).

Pre-AHCI ancient-style PC/AT IDE (even with Intel’s adornments for DMA) just plain does not support hot disk arrival electrically. So, there are chances that the Windows ATA stack just plain does not support bus rescans at all.

More so: parallel ATA and SATA (not eSATA) do not support hot plug.

More so: the users are aware on aforementioned facts, so, I have major doubts you will ever see the disk hot plug to PC/AT controller. There is a case of external eSATA box (wired to PC/AT controller by the SATA-to-eSATA wire from the motherboard to the box’s rear side hole) powering up, but the users are aware that controller restart in Device Manager is a must for this.

And yes, if this is the boot controller - then please reboot.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Thanks Maxim.
>
> as per msdn IOCTL_SCSI_RESCAN_BUS is for legacy drivers only so probably I can’t use it.
> disable/enable using setupDi* is not an option for me as my target is boot controller.
>
> My requirement is to force the portdriver to re-obtain identify data from the target disk and re-report it to the system.
>
>
>
>

6

My case is not of hot plugging ata disk.

I have the boot disk (which is my target disk) already connected. My requirement is to indicate the disk firmware about the presence of my lower disk filter driver. And if it is present then disk should report a different capacity than when my driver is not present.

so my plan was to:

  1. on the way up of START completion, send a private ioctl to the disk to indicate the presence of my driver.
  2. then fail the START.
  3. pnp will issue REMOVE which will cause port driver to delete the disk PDO.
  4. then in my port filter I call IoInvalidateDeviceRelations.
  5. Pnp will send QDR/BusRelations.
  6. port driver will re-enumerate disks and create new disk PDO. And this time disk will report the desired capacity.

I will look into RESCAN thing that you mentioned. Thanks.

7

Oh I think that is probably not going to work well. Your filter driver
that alters the disk capacity should be installed before the capacity
is reported up.

Mark Roddy

On Mon, Dec 13, 2010 at 4:15 PM, wrote:
> My case is not of hot plugging ata disk.
>
> I have the boot disk (which is my target disk) already connected. My requirement is to indicate the disk firmware about the presence of my lower disk filter driver. And if it is present then disk should report a different capacity than when my driver is not present.
>
> so my plan was to:
>
> 1. on the way up of START completion, send a private ioctl to the disk to indicate the presence of my driver.
> 2. then fail the START.
> 3. pnp will issue REMOVE which will cause port driver to delete the disk PDO.
> 4. then in my port filter I call IoInvalidateDeviceRelations.
> 5. Pnp will send QDR/BusRelations.
> 6. port driver will re-enumerate disks and create new disk PDO. And this time disk will report the desired capacity.
>
> I will look into RESCAN thing that you mentioned. Thanks.
>
>
> —
> 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

Hi Mark, loading port filter before the capacity is queried by port driver is not possible that’s why I want to emulate start-remove-start again.

looks like somebody has achieved the similar thing here:
http://www.osronline.com/showThread.cfm?link=33403
but it does not say how :frowning:

9

Gee that thread looks familiar. :slight_smile:

Sort of a different situation though - unless I skipped over it, that
person was not trying to start off with one reported disk capacity and
then substitute another, without removing and re-adding the disk in
question. That person was in for a whole bucket of other trouble.

You can certainly put a filter in place at boot time and have it
intercept disk capacity request completions and substitute your own
(presumable smaller) capacity. What obstacle have you tossed in your
path to prevent you from doing this?

Mark Roddy

On Mon, Dec 13, 2010 at 5:25 PM, wrote:
> Hi Mark, loading port filter before the capacity is queried by port driver is not possible that’s why I want to emulate start-remove-start again.
>
> looks like somebody has achieved the similar thing here:
> http://www.osronline.com/showThread.cfm?link=33403
> but it does not say how :frowning:
>
> —
> 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
>

10

Yes he was not dealing with capacity exactly but the problem was same and (s)he wanted to remove and add the disks back again - force reenumeration.

Reporting a changed capacity is trivial. the problem is I need to indicate the disk that my driver is present so that it reports capacity X and if my driver is not present then it should report capacity Y.

May be there is some other solution that you can suggest. Thank you.

11

So I guess I really do not understand exactly what you are trying to do.

You have a filter driver sitting between scsiport and disk.sys.
Your filter driver is attached to some or all disks.
Your filter driver is able to process disk capacity SRBs and change
the reported capacity, but that is somehow not sufficient - why?

Are you attempting to add - on the fly - your filter to existing disk stacks?

Mark Roddy

On Mon, Dec 13, 2010 at 6:32 PM, wrote:
> Yes he was not dealing with capacity exactly but the problem was same and (s)he wanted to remove and add the disks back again - force reenumeration.
>
> Reporting a changed capacity is trivial. the problem is I need to indicate the disk that my driver is present so that it reports capacity X and if my driver is not present then it should report capacity Y.
>
> May be there is some other solution that you can suggest. Thank you.
>
> —
> 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

sorry for not being clear. let me try again.

I have a port filter. the requirement is that if port filter is present on the system, then a particular proprietary disk (which is a boot disk) must report capacity X but if my port filter is not installed on the system then it must report default capacity Y. And somehow I want to indicate the presence of my port filter to the disk so that it can report the appropriate capacity.

  1. port driver enumerates the disk and disk reports the default capacity Y.
  2. port filter driver loads and sends an IOCTL to the disk to indicate the driver’s presence.
  3. to all future identify requests disk reports capacity X as now it knows that my port filter driver is present.
13

Your ‘port filter’ ought to always be present rather than, it seems,
somehow dynamically loaded and inserted into an existing stack. That
is the part of your description that a) I don’t understand why you
need to do this, and b) is making your task *very* difficult.

Mark Roddy

On Mon, Dec 13, 2010 at 6:59 PM, wrote:
> sorry for not being clear. let me try again.
>
> I have a port filter. the requirement is that if port filter is present on the system, then a particular proprietary disk (which is a boot disk) must report capacity X but if my port filter is not installed on the system then it must report default capacity Y. And somehow I want to indicate the presence of my port filter to the disk so that it can report the appropriate capacity.
>
> 1. port driver enumerates the disk and disk reports the default capacity Y.
> 2. port filter driver loads and sends an IOCTL to the disk to indicate the driver’s presence.
> 3. to all future identify requests disk reports capacity X as now it knows that my port filter driver is present.
>
> —
> 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
>

14

> I have the boot disk (which is my target disk) already connected. My requirement is to indicate the

disk firmware about the presence of my lower disk filter driver. And if it is present then disk should
report a different capacity than when my driver is not present.

Dynamic attach of the filters to the disk stacks is not supported (as for any PnP stacks).

You need to disable/enable the disk stack, and, for boot disk, this requires a reboot.

And, without the dynamic attach, there is no problem at all. Your filter does all work in its START completion, and allows the START to complete up only after the preparation by your filter is done.

READ CAPACITY from the upper drivers will not come till START will complete.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

15

> 1. port driver enumerates the disk and disk reports the default capacity Y.

  1. port filter driver loads and sends an IOCTL to the disk to indicate the driver’s presence.

Just intercept the read capacity request in your filter and patch the reported value.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com