-pre19 should fix this problem.
I have just run Microsoft's NDIS tester and it has found 8 errors and 1
warning. Nothing too major but worth fixing.
James
> -----Original Message-----
> From: Nick Couchman [mailto:Nick.Couchman@xxxxxxxxx]
> Sent: Friday, 31 October 2008 14:14
> To: James Harper
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx; Pekka.Panula@xxxxxxxx
> Subject: 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
|
Home