Re: Hardware delaying the OS
- From: "heinz" <heinz_baer@xxxxxxxxxxx>
- Date: 9 Nov 2005 21:31:10 -0800
The device being gone that long could have some timeout ramifications.
I can't really comment on max timeouts, but if it is not the boot
drive, you can lock the volume to resolve this and have the drive to
yourself. If it is the boot drive, then you might have to defer the
update to the next system restart where it is initiated from a filter
driver before the filesystem loads.
The other thing is Windows builds unique device ID's used for various
things with the firmware revision. This means changing the firmware
will make Windows see a "new" device. You thus are going to want to
force a device change so Windows can see the firmware changed and
update things appropriately. Letting the drive continue to be present
as if nothing happened after changing inquiry data is not good because
the device will be out of step with what Windows has acquired about it.
Whatever you do, do not use KeStallExecutionProcessor. That is the
wrong approach because it will freeze up the CPU. The user won't like
having their mouse frozen for 30 seconds and it is completely
unnecessary. There are three cases:
1. The drive holds the command and complete it after the firmware
update is finished: have your driver block on the command completing.
In fact, you don't even need a driver for this. Just use scsi pass
through from an app.
2. The drive completes the command immediately and you have to poll for
it to become ready: go into a loop where you block your thread for a
reasonable time (1 sec) with KeWaitForSingleObject, then poll the
drive, then repeat. Don't hammer the drive to death and chew up
resources; the 1 sec delay is important to keep the system running
smoothly.
3. The drive completes the command immediately and cannot be disturbed
for a fixed time frame: block your driver thread for the appropriate
time (30 secs) with KeWaitForSingleObject.
.
- Follow-Ups:
- Re: Hardware delaying the OS
- From: Maxim S. Shatskih
- Re: Hardware delaying the OS
- References:
- Hardware delaying the OS
- From: nws_reader
- Re: Hardware delaying the OS
- From: Maxim S. Shatskih
- Re: Hardware delaying the OS
- From: nws_reader
- Hardware delaying the OS
- Prev by Date: Re: StorPort kernel function restrictions
- Next by Date: Re: GDI does not provide all GLYPH handles for big font size
- Previous by thread: Re: Hardware delaying the OS
- Next by thread: Re: Hardware delaying the OS
- Index(es):
Relevant Pages
|
