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


RE: [Xen-devel] Xen 3.0 RHEL4.1 networking problem

To: "Michael Best" <mbest@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Xen 3.0 RHEL4.1 networking problem
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 6 Dec 2005 16:51:44 -0000
Delivery-date: Tue, 06 Dec 2005 16:52:08 +0000
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcX6ZNmuqH7gDH1ORHqENgJeF5SrLAAFtFoQ
Thread-topic: [Xen-devel] Xen 3.0 RHEL4.1 networking problem
> I'm copying the installer from my dom0 to my domU (48M file) 
> the file transfer stalls out and on the domU I get this 
> kernel message:
> i.e. dom0:
> # scp xen-3.0-x86_32-rhel4.1.bin.tar domU:/mnt/sources 
> root@domU's password:
> xen-3.0-x86_32-rhel4.1.bin.tar       0%  196KB   0.0KB/s - stalled -K
> domU:
> dmesg | tail -n 1
> Received packet needs 8 bytes more headroom.
> tail /var/log/message:
> Dec  5 16:28:06 domU kernel: Received packet needs 8 bytes 
> more headroom.
> Dec  5 16:28:59 domU last message repeated 10 times

This bug is understood and a fix has been applied to the testing tree.

It only effects dom0 kernels built with the -xen config rather than

[Basically, the -xen kernel config turns on so much stuff that the area
reserved for the max posible header length is too big. This causes a
netfront slow-path to be exercised that copys the skb. Unfortunately,
this path hadn't been exercised before, and guess what, it was subteley
broken for checksum offloaded packets.]

You can work around the bug by reducing the MTU of eth0 in the dom0 e.g.
"ifconfig eth0 mtu 1400"


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>