Hey All
Several Issuses I am NOT clear about GPL Windows Driver
1. In xennet, GPL Win Driver set the rx(XenNet_RxInit())/tx(XenNet_TxInit()) DPC
to vCPU0 using KeSetTargetProcessorDpc().
My quetions why we should do in this way, Any problem if I unset the rx/tx DPC
to vCPU0, just let OS to assign DPC to which vCPUs?
2. In xenpci, XenPci_DOP_BuildScatterGatherListButDontExecute() line 756,
line 756 gref = (grant_ref_t)GntTbl_GrantAccess(xpdd, 0, (ULONG)pfn, FALSE,
INVALID_GRANT_REF);
line 757 ASSERT(gref != INVALID_GRANT_REF);
if there''s NOT eough gref, there should be a crash, why NOT deal with
it like the way XenScsi_PutSrbOnRing() in xenscsi.c?
line 614 if (shadow->req.seg[shadow->req.nr_segments].gref ==
0x0FFFFFFF)
line 615 {
line 616 return; /* better than crashing... */
line 617 }
At least, this will NOT crash the OS.
Because when I use iperf do a test between two DomU (WINDOWS XP SP2) on some
Dom0.
A:One DomU as iperf client
iperf -c $(IP_SERVER) -i 1 -w 64k -l 1 -t 300
another one as iperf server:
B:iperf -s -P 1 -i 1 -w 64k -l 1
In this way, I set iperf buffer length is 1 bytes.
The Client crashes everytime!!!!
The callstack of Client Windows is as following.
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: 80000003, The exception code that was not handled
Arg2: 80531e95, The address that the exception occurred at
Arg3: f8ab95b4, Trap Frame
Arg4: 00000000
Debugging Details:
------------------
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - <Unable to get error code
text>
FAULTING_IP:
nt!IopVerifyDiskSignature+52
80531e95 cc int 3
TRAP_FRAME: f8ab95b4 -- (.trap 0xfffffffff8ab95b4)
ErrCode = 00000000
eax=00000002 ebx=f8ab96a4 ecx=8052cc7a edx=00000056 esi=8052cc7b edi=00000002
eip=80531e96 esp=f8ab9628 ebp=f8ab963c iopl=3 nv up ei pl nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00003216
nt!IopVerifyDiskSignature+0x53:
80531e96 5b pop ebx
Resetting default scope
CUSTOMER_CRASH_COUNT: 2
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: csrss.exe
IRP_ADDRESS: f8ab962c
LAST_CONTROL_TRANSFER: from 80531f0a to 80531e96
STACK_TEXT:
f8ab963c 80531f0a 00000002 8052cc7a 00000056 nt!IopVerifyDiskSignature+0x53
f8ab9658 8052b7c6 f8ab966c f8ab9674 8052cc1d nt!IopCompleteRequest+0x333
f8ab967c 8052cd92 8052cc7a f8ab96a4 00000002 nt!`string''+0x1a
f8ab9978 8052ce40 f8521e90 f8521bb0 000002f6 nt!FsRtlAddLargeMcbEntry+0x49c
f8ab9994 f8515802 f8521e90 f8521bb0 000002f6 nt!FsRtlSplitLargeMcb+0x9d
f8ab99ac f8516b7c f8521e90 f8521bb0 000002f6 xenpci!XenRtlAssert+0x32
[e:\driverstudio_prj\win-pvdrivers.hg\common\include\xen_windows.h @ 255]
f8ab9a78 f851661e 81eaa000 820779d0 814e1104
xenpci!XenPci_DOP_BuildScatterGatherListButDontExecute+0x52c
[e:\driverstudio_prj\win-pvdrivers.hg\xenpci\xenpci_dma.c @ 758]
f8ab9aa8 f835a56e 81eaa000 820779d0 814e1104
xenpci!XenPci_DOP_BuildScatterGatherList+0x2e
[e:\driverstudio_prj\win-pvdrivers.hg\xenpci\xenpci_dma.c @ 865]
f8ab9b00 f8341a08 00000000 00000001 81ff8688 NDIS!ndisMAllocSGList+0xd9
f8ab9b1c f822c528 81ff8688 814e2c20 814e2be8 NDIS!ndisMSendX+0x1a0
f8ab9b58 f8341985 81fb24e8 814e2c20 00000002 psched!MpSend+0x706
f8ab9b80 f80ead40 82006ac8 814e2c20 82095008 NDIS!ndisMSendX+0x1d6
f8ab9ba8 f80ea916 82095008 814e2c20 81f05788 tcpip!GetTCPHeaderAtDpcLevel+0x1f
f8ab9bd4 f80ea65a 82095008 f8ab9c02 00000001 tcpip!MdpAllocateAtDpcLevel+0xe7
f8ab9c04 f80ea79f 81eee500 09050980 814e2c20 tcpip!IPSendComplete+0x58
f8ab9d50 f80efdeb f8128898 814df1e8 814df180 tcpip!GetIPHdrBuffer+0x13
f8ab9dbc f80ef3a5 18b078c7 00000002 00000000 tcpip!GetConnID+0x1cb
f8ab9de0 f80e7a08 00000002 00000002 f8ab9e0c tcpip!TCPRcv+0x140e
f8ab9e14 f80e794f 00000002 f80e7901 f80e73d6 tcpip!ProcessTCBDelayQ+0xc4
f8ab9e20 f80e73d6 00000000 81ec52d8 f80e77f2 tcpip!TCPRcvComplete+0x20
f8ab9e2c f80e77f2 f8363d40 82095008 f8230b40 tcpip!IPRcvComplete+0x21
f8ab9e30 f8363d40 82095008 f8230b40 81fb24e8 tcpip!ARPRcvComplete+0x5
f8ab9e80 f822b01d 00ed5730 81fee178 00000003
NDIS!ethFilterDprIndicateReceivePacket+0x5a4
f8ab9e94 f822b1b4 81ec52d8 81fee178 00000003 psched!PsFlushReceiveQueue+0x15
f8ab9eb8 f822b5f9 81fb24f0 00000000 81ec52d8 psched!PsEnqueueReceivePacket+0xda
f8ab9ed0 f8363d40 81fb24e8 806e5422 ffdff9c0 psched!ClReceiveComplete+0x13
f8ab9f20 f87708b4 00ed5730 f8ab9f74 00000003
NDIS!ethFilterDprIndicateReceivePacket+0x5a4
f8ab9fcc 80545e6f 81e75b34 81e72000 00000000 xennet!XenNet_RxBufferCheck+0x604
[e:\driverstudio_prj\win-pvdrivers.hg\xennet\xennet_rx.c @ 811]
ffdff980 8055c4a4 f8aba000 0000391a 00000002 nt!WmiTraceEvent+0x3f8
ffdff984 f8aba000 0000391a 00000002 f8ab9fe4 nt!MiPageFileTraces+0x8c4
WARNING: Frame IP not in any known module. Following frames may be wrong.
ffdff988 00000000 00000002 f8ab9fe4 00000001 0xf8aba000
STACK_COMMAND: kb
FOLLOWUP_IP:
xenpci!XenRtlAssert+32
[e:\driverstudio_prj\win-pvdrivers.hg\common\include\xen_windows.h @ 255]
f8515802 5d pop ebp
FAULTING_SOURCE_CODE:
251: XenRtlAssert(PCHAR expr, PCHAR filename, ULONG line_number)
252: {
253: XenDbgPrint("Failed ASSERTion ''%s'' at
%s:%d\n", expr, filename, line_number);
254: RtlAssert(expr, filename, line_number, NULL);> 255: }
256:
257:
258: #if 1
259: #ifdef KdPrint
260: #undef KdPrint
SYMBOL_STACK_INDEX: 5
SYMBOL_NAME: xenpci!XenRtlAssert+32
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: xenpci
IMAGE_NAME: xenpci.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4af3a64f
FAILURE_BUCKET_ID: 0x8E_xenpci!XenRtlAssert+32
BUCKET_ID: 0x8E_xenpci!XenRtlAssert+32
Followup: MachineOwner
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
And then I unset the rx(XenNet_RxInit())/tx(XenNet_TxInit()) DPC to vCPU0, just
let OS to assign the DPC, this problem vanishes.
Any ideas about the two problem ?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
James Harper
2009-Nov-13 09:52 UTC
RE: [Xen-devel] Several Issues about GPL Windows Driver
> Hey All > > Several Issuses I am NOT clear about GPL Windows Driver > > 1. In xennet, GPL Win Driver set therx(XenNet_RxInit())/tx(XenNet_TxInit())> DPC to vCPU0 using KeSetTargetProcessorDpc(). > My quetions why we should do in this way, Any problem if I unset therx/tx DPC> to vCPU0, just let OS to assign DPC to which vCPUs?NDIS Dpc''s only run on CPU 0. I think you''ll find a lot of lock contention if you make the DPC''s run on all CPU''s.> > 2. In xenpci, XenPci_DOP_BuildScatterGatherListButDontExecute() line756,> line 756 gref = (grant_ref_t)GntTbl_GrantAccess(xpdd, 0, (ULONG)pfn,FALSE,> INVALID_GRANT_REF); > line 757 ASSERT(gref != INVALID_GRANT_REF); > if there''s NOT eough gref, there should be a crash, why NOT deal withit like> the way XenScsi_PutSrbOnRing() in xenscsi.c? > line 614 if (shadow->req.seg[shadow->req.nr_segments].gref =0x0FFFFFFF) > line 615 { > line 616 return; /* better than crashing... */ > line 617 } > At least, this will NOT crash the OS. > Because when I use iperf do a test between two DomU (WINDOWS XP SP2)on some> Dom0. > A:One DomU as iperf client > iperf -c $(IP_SERVER) -i 1 -w 64k -l 1 -t 300 > another one as iperf server: > B:iperf -s -P 1 -i 1 -w 64k -l 1 > > In this way, I set iperf buffer length is 1 bytes. > > The Client crashes everytime!!!! > The callstack of Client Windows is as following. >You posted that previously. Do you have a Windows 2003 setup you can test with too? That way I could reproduce it and know if it will be fixed. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel