[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Checksumming problem in pv_ops dom0 kernel / netback
Hello, I seem to be having some troubles regarding the latest 2.6.31.6 and 2.6.32.9 Xen dom0 pv_ops trees. Our platform: -Xen 3.4.3-rc3 (also tried 3.4.2 on 2.6.31.6 pv_ops dom0) -2.6.32.9 pv_ops dom0 kernel, perhaps a week old checkout from xen/stable git (can provide changeset if requested). -100+ domU's, all PV. Ever since we switched to a pv_ops dom0 kernel (we were using 2.6.26 xenkernel from Debian repo before, with Xen 3.2), we started to have some problems when attempting to route packets on a domU. The following message appears in dmesg on the dom0: "Attempting to checksum a non-TCP/UDP packet, dropping a protocol 1 packet" We can actually sniff both the virtual interface on the dom0 (nothing ever leaves the domU) and we do see the ICMP echo requests inside the domU. The reply, however, never gets to the destination or outside the domU for that matter. It seems that for some reason, as soon as the packet leaves the domU, the dom0 kernel drops the packet, as shown in the dmesg log. Some background info: We're using normal virtual interfaces, on a named bridge, br-internet. This bridge contains the hardware interface 'eth0'. This is a tg3 interface, we already tried turning off both RX and TX checksumming for this interface. Setting Ã'ethtool tx off' in the domU itself, doesn't help, either. The different interfaces are vlan'ed through a Cisco 2927 switch. Since this problem did not occur in xenkernels before, it is most likely related to a netback patch in pv_ops dom0. Perhaps somebody could provide me with some more info, or insights. -- /\/\ Hostingvereniging Soleus | Community-driven < ** > http://soleus.nu | Virtual Private Servers \/\/ Sen (IEF) Verbrugge (CT ProLead) | & more ... _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |