Hang with Intel storage Driver IaStor

All,

we have a volume lower filter, which does read write processing, and
sometimes also generates its own IO writes on a volume.The driver
works fine, but we have observed that with Intel’s desktop RAID
controller driver isStor we hang and the IO we send down ourselves by
rolling our own IRP_MJ_WRITE hangs, and is never completed by the
storage driver below. This happens only with this raid driver.

So is there anything special needed to be done to handle RAID kind of
environments? Perhaps a flag in the IRP?

thanks

ami

Fill Irp->Tail.Overlay.Thread with some sane ETHREAD pointer.


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

“Ami Awbadhho” wrote in message news:xxxxx@ntdev…
> All,
>
> we have a volume lower filter, which does read write processing, and
> sometimes also generates its own IO writes on a volume.The driver
> works fine, but we have observed that with Intel’s desktop RAID
> controller driver isStor we hang and the IO we send down ourselves by
> rolling our own IRP_MJ_WRITE hangs, and is never completed by the
> storage driver below. This happens only with this raid driver.
>
> So is there anything special needed to be done to handle RAID kind of
> environments? Perhaps a flag in the IRP?
>
> thanks
>
> ami
>

max,

thanks for trying to help. we already do that, but stil lthings wont work.

here is the code:

NTSTATUS
MakeSynchronousIoRequest(
IN PDEVICE_OBJECT DeviceObject, // ptr to our filtering device
object for a given volume
IN PVOID WriteBuffer, // ptr to Write buffer for data
to be written to disk
IN ULONG NumBytes, // size of Write buffer
IN PLARGE_INTEGER StartingOffset, // ptr to starting offset
value on raw disk volume to be written
IN ULONG MajorFunction) // IRP major function code
(always IRP_MJ_WRITE at present)
{
NTSTATUS status;
PIRP irp;
KEVENT event;
PMDL mdl, nextMdl;
PIO_STACK_LOCATION nextStack;
PDEVICE_OBJECT TopOfDeviceStack=NULL;

if(!DeviceObject)
{

return STATUS_INVALID_PARAMETER;
}

// get a typed ptr to our device extension data for the filtering device
P_FLT_DEV_EXT DevExt = (P_FLT_DEV_EXT) DeviceObject->DeviceExtension;

TopOfDeviceStack = DevExt->StackInfo.TargetDevice;
// init an event for a “synchronous” i/o request
KeInitializeEvent(&event, NotificationEvent, FALSE);

//
// Start by allocating the IRP for this request. Do not charge quota
// to the current process for this IRP. We can also reuse this IRP
every time we need to Write the map file to disk.
//

irp = IoAllocateIrp( TopOfDeviceStack->StackSize, FALSE );
if (NULL == irp)
{

return STATUS_INSUFFICIENT_RESOURCES;
}

//
// Obtain a pointer to the stack location of the first driver that will be
// invoked. This is where the function codes and the parameters are set.
//

nextStack = IoGetNextIrpStackLocation( irp );
nextStack->MajorFunction = (UCHAR)MajorFunction;
nextStack->Parameters.Write.Length = NumBytes;
nextStack->Parameters.Write.ByteOffset = *StartingOffset;
nextStack->DeviceObject = VtDevExt->StackInfo.TargetDevice;
nextStack->Flags = SL_OVERRIDE_VERIFY_VOLUME;

irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Cancel = FALSE;
irp->Flags |=(IRP_SYNCHRONOUS_API | IRP_WRITE_OPERATION) ;

if(TopOfDeviceStack->Flags & DO_BUFFERED_IO)
{

irp->AssociatedIrp.SystemBuffer = WriteBuffer;
irp->MdlAddress = NULL;
irp->Flags |= IRP_BUFFERED_IO ;

} else if (TopOfDeviceStack->Flags & DO_DIRECT_IO)
{
//
// The target device supports direct I/O operations. Allocate
// an MDL large enough to map the buffer and lock the pages into
// memory.
//
irp->MdlAddress = IoAllocateMdl( WriteBuffer,
NumBytes,
FALSE,
FALSE,
(PIRP) NULL );
if (irp->MdlAddress == NULL)
{
IoFreeIrp( irp );
return STATUS_INSUFFICIENT_RESOURCES;
}

MmBuildMdlForNonPagedPool(irp->MdlAddress);
}

IoSetCompletionRoutine( irp,
MakeSynchronousRequestCompletion,
(PVOID ) &event,
TRUE,
TRUE,
TRUE);

status =IoCallDriver(TopOfDeviceStack, irp);

if (status == STATUS_PENDING)
{

KIRQL cIRQL = KeGetCurrentIrql();

if(cIRQL >= DISPATCH_LEVEL){
DbgPrint((“High irql\n”));
}
// wait for the result
(void) KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);
// set the final result of this Write IRP
status = irp->IoStatus.Status;
}

if (irp->MdlAddress != NULL)
{
for (mdl = irp->MdlAddress; mdl != NULL; mdl = nextMdl)
{
nextMdl = mdl->Next;
IoFreeMdl( mdl ); // This function will also unmap pages.
}
irp->MdlAddress = NULL;
}

IoFreeIrp(irp);
return status;
}

the completion routine is:

NTSTATUS
MakeSynchronousRequestCompletion(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PVOID Context
)
{

PKEVENT pEvent= (PKEVENT)Context;
PDEVICE_OBJECT Dev= DeviceObject;

if(Dev==NULL || Irp ==NULL)
{

// some code

}
if(NULL == Context)
{
//Something looks to be gone bad ,lets hang the system to findout what.
// dng prints
}else
{

KIRQL cIRQL = KeGetCurrentIrql();

if(cIRQL >= DISPATCH_LEVEL){
// dbg prints
}

KeSetEvent(pEvent, (KPRIORITY) 0, FALSE);
}
return STATUS_MORE_PROCESSING_REQUIRED;
}

On Fri, Aug 3, 2012 at 9:05 AM, Maxim S. Shatskih
wrote:
> Fill Irp->Tail.Overlay.Thread with some sane ETHREAD pointer.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “Ami Awbadhho” wrote in message news:xxxxx@ntdev…
>> All,
>>
>> we have a volume lower filter, which does read write processing, and
>> sometimes also generates its own IO writes on a volume.The driver
>> works fine, but we have observed that with Intel’s desktop RAID
>> controller driver isStor we hang and the IO we send down ourselves by
>> rolling our own IRP_MJ_WRITE hangs, and is never completed by the
>> storage driver below. This happens only with this raid driver.
>>
>> So is there anything special needed to be done to handle RAID kind of
>> environments? Perhaps a flag in the IRP?
>>
>> thanks
>>
>> ami
>>
>
> —
> 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

Try to make that KeWaitForSingleObject alertable wait.

hi grigora,

thjis driver is a volume lower filter. also i have read that alertable
is only useful for user mode waits, in kernel mode it wont have any
effect at all, perhaps you can tell me something more, which is not in
the docs?

we use this routine for writing to disks from both user mode threads
(we open the volume object directly through createfile, so the context
is the user mode thread) and kernel mode threads.

the bservation is the hang only occurs when the volsnap does come
operations where the storage driver is involved. we never receive any
completion from the iastor driver below, and hang forever…

On Fri, Aug 3, 2012 at 8:38 PM, wrote:
> Try to make that KeWaitForSingleObject alertable wait.
>
> —
> 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

So where is the IRP when it is stuck? You should be able to find this
particular IRP and at least determine where it is, what state it is
in, etc. Presumably you have a thread stuck in KeWaitForSingleObject
and you have the local variables for that stack frame, including the
Irp.

Mark Roddy

On Sat, Aug 4, 2012 at 3:13 AM, Ami Awbadhho wrote:
> hi grigora,
>
>
> thjis driver is a volume lower filter. also i have read that alertable
> is only useful for user mode waits, in kernel mode it wont have any
> effect at all, perhaps you can tell me something more, which is not in
> the docs?
>
> we use this routine for writing to disks from both user mode threads
> (we open the volume object directly through createfile, so the context
> is the user mode thread) and kernel mode threads.
>
> the bservation is the hang only occurs when the volsnap does come
> operations where the storage driver is involved. we never receive any
> completion from the iastor driver below, and hang forever…
>
>
>
>
> On Fri, Aug 3, 2012 at 8:38 PM, wrote:
>> Try to make that KeWaitForSingleObject alertable wait.
>>
>> —
>> 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
>
> —
> 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

it gets stuck in partition manager…

On Sun, Aug 5, 2012 at 7:23 PM, Mark Roddy wrote:
> So where is the IRP when it is stuck? You should be able to find this
> particular IRP and at least determine where it is, what state it is
> in, etc. Presumably you have a thread stuck in KeWaitForSingleObject
> and you have the local variables for that stack frame, including the
> Irp.
>
>
> Mark Roddy
>
>
> On Sat, Aug 4, 2012 at 3:13 AM, Ami Awbadhho wrote:
>> hi grigora,
>>
>>
>> thjis driver is a volume lower filter. also i have read that alertable
>> is only useful for user mode waits, in kernel mode it wont have any
>> effect at all, perhaps you can tell me something more, which is not in
>> the docs?
>>
>> we use this routine for writing to disks from both user mode threads
>> (we open the volume object directly through createfile, so the context
>> is the user mode thread) and kernel mode threads.
>>
>> the bservation is the hang only occurs when the volsnap does come
>> operations where the storage driver is involved. we never receive any
>> completion from the iastor driver below, and hang forever…
>>
>>
>>
>>
>> On Fri, Aug 3, 2012 at 8:38 PM, wrote:
>>> Try to make that KeWaitForSingleObject alertable wait.
>>>
>>> —
>>> 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
>>
>> —
>> 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
>
> —
> 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