domU network data payload corruption

[Saku Ytti <saku+xen-devel@ytti.fi>]

 neutral observing machine running 'ping 10.10.10.101 -p aa', where
10.10.10.101 is latest xen/unstable domU (dom0 also xen/unstable, kernel,
hypervisor, tools)

 tethereal ran in domU for packet leaving:
 0000  6d 6d eb 43 88 0c 0f 00 aa aa aa aa aa aa aa aa   mm.C............
 0010  aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa   ................
 0020  aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa   ................
 0030  aa aa aa aa aa aa aa aa                           ........

 tethereal ran in neutral observing machine for packet arriving:
 0000  6d 6d eb 43 88 0c 0f 00 aa aa aa aa aa aa aa aa   mm.C............
 0010  aa aa aa aa aa aa ff ff ff ff ff ff ff ff ff ff   ................
 0020  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff   ................
 0030  ff ff ff ff ff ff ff ff                           ........


Also 'ping' command reporting:
64 bytes from 10.10.10.101: icmp_seq=13 ttl=64 time=0.268 ms
wrong data byte #22 should be 0xaa but was 0xff
#8      aa aa aa aa aa aa aa aa aa aa aa aa aa aa ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff 
#40     ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 


now if I run 'ping 10.10.10.101 -p ff', there is no problem, packets
are received without errors. To further prove it 'ping 10.10.10.101 -s 22
-p aa' is also ok, but 'ping 10.10.10.101 -s 23 -p aa' not anymore, as 
all bits after that are set '1'.

Any clue what might be causing this? Reloading domU doesn't help, but
if I reload dom0 domU can be ok for long time (upgraded debian/unstable
etc) but after some time and especially after adding more domU it
seems always trigger at least after adding 3rd domU and then hits
also to the earlier domU's.

I'm happy to provide any information required, I'm using forcedeth
NIC driver in dom0.

Thanks,
-- 
  ++ytti