WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

RE: [Xen-users] Stop 8E with GPL PV Drivers

James,
Here's the output with update5:
 
XenNet     Something went wrong... analyzing
XenNet     total_length = 42
XenNet     in_mdl = 86232020
XenNet     MmGetSystemAddressForMdlSafe(in_mdl) = 86232040
XenNet     MmGetMdlByteCount(in_mdl) = 14
XenNet     in_mdl = 860FC020
XenNet     MmGetSystemAddressForMdlSafe(in_mdl) = 860FC040
XenNet     MmGetMdlByteCount(in_mdl) = 20
XenNet     in_mdl = 86233020
XenNet     MmGetSystemAddressForMdlSafe(in_mdl) = 86233060
XenNet     MmGetMdlByteCount(in_mdl) = 8
XenNet     in_mdl = 863DDD40
XenNet     MmGetSystemAddressForMdlSafe(in_mdl) = 863DDCC0
XenNet     MmGetMdlByteCount(in_mdl) = 0
 
*** Assertion failed: FALSE
***   Source File: c:\projects\win-pvdrivers.hg\xennet\xennet_tx.c, line 200
If you need the full output, I'll be happy to send that along, too.
 
-Nick

>>> "James Harper" <james.harper@xxxxxxxxxxxxxxxx> 2008/10/30 20:35 >>>
>
> Okay, attached is the output from the debug session - looks like
there's
> some more info there.  Also, FYI, the file you uploaded isn't a zip
file,
> it's the actual .sys file.  I kept getting a message about a corrupt
> archive file and finally used the "file" command on Linux and
determined
> that the zip file wasn't actually a zip file.  I was still able to use
it,
> but just thought I'd let you know.
>

D'oh. Yes I must have goofed somewhere. Pity, the version you used
didn't have one extra debug statement in it. I have just uploaded update
5, but maybe wait a bit and I'll have a proper fix for you.

The data that did come out tells me that there were 4 buffers supplied:
14 bytes (Ethernet header)
20 bytes (IP header)
8 bytes (? - normally this would be the ICMP/TCP/UDP header, but I guess
you are using another protocol)
0 bytes (???)

I'm pretty sure I can see the problem - the original failing ASSERT was
to make sure that there was no data left over after we processed the
expected data in the buffers. I did that by checking for another buffer
on the end. In your case though, even though there is another buffer on
the end, it has no data in it, so my check was making an invalid
assumption.

James


This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
<Prev in Thread] Current Thread [Next in Thread>