Xen 3.0 RHEL4.1 networking problem

Xen 3.0 RHEL4.1 networking problem

[Michael Best]

I'm running the Xen 3.0 RHEL4.1 kernel, and I'm having a 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

To the best of my knowledge this only happens on network traffic between 
the dom0 and the domU.

It appears to be similar to this message:
http://lists.xensource.com/archives/html/xen-devel/2004-09/msg00354.html

I built and installed my own kernel from the xen-unstable-src.tar.gz
previously and ran without problems on this same hardware.

-Mike

RE: Xen 3.0 RHEL4.1 networking problem

[Ian Pratt]

> 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
-xen0.

[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"


Ian