On Fri, Nov 21, 2014 at 04:58:54PM -0800, Eitan Eliahu wrote:
> The driver completes a pending IRP, the IRP is being marked free by the
> I/O manager which causes a system crash when the IRP is completed at
> the second time.
> The driver should not complete a pending IRP in the context of the
> Device I/O control thread.
>
> *** Fatal System Error: 0x00000044
>
> (0xFFFFFA800CF897D0,0x0000000000000F7A,0x0000000000000000,0x0000000000000000)
>
> Break instruction exception - code 80000003 (first chance)
>
> BugCheck 44, {fffffa800cf897d0, f7a, 0, 0}
>
> Probably caused by : OVSExt.sys ( OVSExt!OvsCompleteIrpRequest+3a )
>
> Followup: MachineOwner
> ---------
>
> nt!DbgBreakPointWithStatus:
> fffff800`5a100930 cc int 3
> 11: kd> !analyze -v
> *******************************************************************************
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *******************************************************************************
>
> MULTIPLE_IRP_COMPLETE_REQUESTS (44)
> A driver has requested that an IRP be completed (IoCompleteRequest()), but
> the packet has already been completed. This is a tough bug to find because
> the easiest case, a driver actually attempted to complete its own packet
> twice, is generally not what happened. Rather, two separate drivers each
> believe that they own the packet, and each attempts to complete it. The
> first actually works, and the second fails. Tracking down which drivers
> in the system actually did this is difficult, generally because the trails
> of the first driver have been covered by the second. However, the driver
> stack for the current request can be found by examining the DeviceObject
> fields in each of the stack locations.
> Arguments:
> Arg1: fffffa800cf897d0, Address of the IRP
> Arg2: 0000000000000f7a
> Arg3: 0000000000000000
> Arg4: 0000000000000000
>
> Signed-off-by: Eitan Eliahu <elia...@vmware.com>
Applied, thanks!
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
