file operation across USB mass storage -- USB (Msc) experts and MS

hi,

W.r.t USB stack, let's say some IO operation is in one of the
following layers (USBDisk6, USB mass storage client driver, USBD) when
the system is suspended. Note that this means the IO call has
crossed the Storage Manager level where PNPUnloadDelay plays a role.

When my system resumes, it is natural that HCD intimates USBD that
the device has been removed and then added (to avoid the cases where
USB devices are changed physically before resume). As far as I could
see,

a> this implies that USBD unloads the client drivers and
reloads them again as required.
b> there 's also no power cycle related blocking for IO calls
in either USBDISK6, USBMSC and USBD. They directly return
ERROR_ACCESS_DENIED if they find that the device is removed.

I feel this is very much correct as in case of removable cases
(USB), none of these layers have the intelligence to know whether the
device is still present or has been replaced with something other USB
device during the suspend cycle.

Does this mean that it's natural and OK to expect IO calls to fail
when the system is suspended after they pass through the storage
manager level? Or is there something that can be done to still make
them work?

Any input with be highly appreciable. Any parallel's to other
storage related stacks?

regards,
joseph.

Bruce
Wed Feb 06 09:30:17 PST 2008

Not just USB mass storage, but CF cards, SD cards, any removable storage. I
would expect that I/O calls can and will fail, not just on suspend\resume,
but on device removal.

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

<joseph.garibaldi1@gmail.com> wrote in message
news:bc25ae47-842e-430d-916d-15e3a87df92c@k39g2000hsf.googlegroups.com...
> hi,
>
> W.r.t USB stack, let's say some IO operation is in one of the
> following layers (USBDisk6, USB mass storage client driver, USBD) when
> the system is suspended. Note that this means the IO call has
> crossed the Storage Manager level where PNPUnloadDelay plays a role.
>
> When my system resumes, it is natural that HCD intimates USBD that
> the device has been removed and then added (to avoid the cases where
> USB devices are changed physically before resume). As far as I could
> see,
>
> a> this implies that USBD unloads the client drivers and
> reloads them again as required.
> b> there 's also no power cycle related blocking for IO calls
> in either USBDISK6, USBMSC and USBD. They directly return
> ERROR_ACCESS_DENIED if they find that the device is removed.
>
> I feel this is very much correct as in case of removable cases
> (USB), none of these layers have the intelligence to know whether the
> device is still present or has been replaced with something other USB
> device during the suspend cycle.
>
> Does this mean that it's natural and OK to expect IO calls to fail
> when the system is suspended after they pass through the storage
> manager level? Or is there something that can be done to still make
> them work?
>
> Any input with be highly appreciable. Any parallel's to other
> storage related stacks?
>
> regards,
> joseph.

joseph
Thu Feb 07 03:22:01 PST 2008

hi bruce,

thanks for responding.

ERROR_ACCESS_DENIED is what i see the USB stack code returning in
case the IO call happens to be in the USB stack after RESUME. From our
discussion, I would be ok to get this error. But I get
ERROR_DEVICE_REMOVED as well sometimes. Can this error code also be
expected in general for removable storages for operations across
SUSPEND/RESUME?

Earlier we used to get ERROR_DEVICE_REMOVED very frequently. We
figured out that this happens because of USBDISK6.dll calling
CeResyncFilesys() in case where ScsiTestUnitReady() is tried before
the unmounting of USBDISK6.dll (simulation of removal/insertion after
system RESUME). We avoided the call to ScsiTestUnitReady() after
DSK_PowerDown() and ERROR_DEVICE_REMOVED became very infrequent. But
again, it still happens.

Should we just go by this assuming these two errors and many more
such errors can happen for operation on removable storage media across
suspend/resume in WinCE? Or can we isolate the errors into cases which
can be debugged and avoided (as in ERROR_DEVICE_REMOVED) and errors
which are perfectly normal with operations (as in ERROR_ACCESS_DENIED)
across suspend/resume?

Thanks again,

regards,
joseph garibaldi.