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

["Nick Couchman" <Nick.Couchman@xxxxxxxxx>]

Thanks, James - looking good so far!  I'm curious as to why Symantec Ghost 
would be the thing to set it off.  I also use the iSCSI initiator on this VM 
(and several others running the pre18 version of the drivers) and that's never 
caused a crash, but Ghost was almost guaranteed to crash it.  Very strange.  I 
wonder what Pekka has running that was forcing it to crash.

Anyway, thanks, again, for the fix and for all the hard work put into these 
drivers!

-Nick

>>> "James Harper" <james.harper@xxxxxxxxxxxxxxxx> 10/31/08 2:02 AM >>>
-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.




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