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-devel

Re: [Xen-devel] network hang trigger

To: "James Harper" <JamesH@xxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] network hang trigger
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 16 Sep 2004 08:24:28 +0100
Cc: "Bin Ren" <br260@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 16 Sep 2004 08:26:19 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 16 Sep 2004 10:48:19 +1000." <AEC6C66638C05B468B556EA548C1A77D3BE080@trantor>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> When I was thinking about this problem, I was imagining a deadlock
> condition where rapid back to back packets (eg a fragmented icmp packet
> from ping or a fragmented udp packet from nfs) was causing a hang until
> part of the deadlock timed itself out and the packets started flowing
> again. I couldn't see 1 packet causing a buffer exhaustion unless it got
> itself into a loop where it kept retrying to send the second fragment
> and didn't free the buffer each time, but even then the buffer bug would
> be a side effect.
> 
> The deadlock would have to be caused in the transmit from xenU to xen0,
> and something about the difference between sending a ping and responding
> to a ping is the difference between always causing a lockup and only
> sometimes causing a lockup.

Try tcpdumping each end of teh connecttion.

I find that for ping 0->U, the 'seizure' is entirely within DOM0 --
ping responses are still received, but for some reason they don't make
it up to the ping application.

For ping U->0, it does look as though the network seizes up -- I see
no packets in either direction.

 -- Keir


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel