This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Several Issues about GPL Windows Driver

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Several Issues about GPL Windows Driver
From: Huibin QIAN <qianhb@xxxxxxxxxx>
Date: Fri, 13 Nov 2009 14:40:25 +0800
Cc: james.harper@xxxxxxxxxxxxxxxx, q00147403@xxxxxxxxxxxxxxxxxxxx, c47994@xxxxxxxxxxxxx
Delivery-date: Thu, 12 Nov 2009 22:42:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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                                    *
*                                                                             *
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
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>
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
80531e96 5b              pop     ebx
Resetting default scope
PROCESS_NAME:  csrss.exe
IRP_ADDRESS:  f8ab962c
LAST_CONTROL_TRANSFER:  from 80531f0a to 80531e96
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

xenpci!XenRtlAssert+32 [e:\driverstudio_prj\win-pvdrivers.hg\common\include\xen_windows.h @ 255]
f8515802 5d              pop     ebp
   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: }
   258: #if 1
   259: #ifdef KdPrint
   260:   #undef KdPrint

SYMBOL_NAME:  xenpci!XenRtlAssert+32
FOLLOWUP_NAME:  MachineOwner
IMAGE_NAME:  xenpci.sys
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
<Prev in Thread] Current Thread [Next in Thread>