similar to: [PATCH] Fix checksum errors when firewalling in domU

Hello Xen folks, I have independently verified that this patch indeed fixes the issue (I posted a message about the issue over the summer: http://lists.xensource.com/archives/html/xen-devel/2005-08/msg00114.html). I used changeset 8911 of xen-unstable.hg. The patch as written expects kernel linux-2.6.16-rc2, but changeset 8911 uses kernel 2.6.16-rc4. I verified that the patch works with

Looks like the GSO is involved? I got this while running Dom0 only (no guests), with a BOINC/Rosetta@home application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1133! invalid opcode: 0000 [#1] SMP CPU: 0 EIP: 0061:[<c04dceb0>] Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen

Below is a fix for the current problem of checksum offload not working in a NAT''ed network. The cause is the NAT/iptables code incorrectly modifying the TCP/UDP checksum (for the checksum offload case). The original code assumes a valid checksum, which is not the case for checksum offload packets (which has a complimented, partial checksum for the hardware to use). The fix is to

I was cleaning out old sandboxes on my machine and realized that the fix for bug 143 was not in the tree yet. Jon Mason posted a patch, with no negative feedback: http://lists.xensource.com/archives/html/xen-devel/2006-02/msg00162.html The bug originator tested the patch successfully on -rc4: http://lists.xensource.com/archives/html/xen-devel/2006-02/msg00763.html I''ve retested on

The addition of VMDq support to ixgbe completely broke normal RSS receive operation. Since RSS is the default operating mode, the driver would cause a kernel panic as soon as the interface was opened. This patch fixes the problem by correctly checking the VMDQ_ENABLED flag before attempting any VMDQ-specific call. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> diff -r

The 2.6.17 merge inserted the new skb_pull_rcsum() at a place different from the native file, hence causing needless differences to native and complicating applying the Xen changes to newer kernels. This patch moves it to the place where native has it. I don''t think it is appropriate to add a signed-off-by statement to this kind of a patch. Jan Index: head-2007-02-08/net/core/skbuff.c

Not sure if this is a pkg-xen issue or for the debian kernel people, trying here first since the patch I applied is created from the pkg-xen project % apt-get source xen-3.0 % cd xen-3.0-3.0.2+hg9646/ % make mkpatches % cd /usr/src/linux-source-2.6.16 % patch -p1 < ../linux-2.6-xen.patch % cp ../config-2.6.16-1-amd64-k8 .config % make-kpkg --append-to-version -1-xen-3.2.0-d0 binary

The correct kernel configuration for VMDq support is CONFIG_XEN_NETDEV2_VMQ, not CONFIG_XEN_NETDEV2_BACKEND. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> diff -urpN a/drivers/net/ixgbe/ixgbe.h b/drivers/net/ixgbe/ixgbe.h --- a/drivers/net/ixgbe/ixgbe.h 2009-02-06 09:03:44.000000000 -0800 +++ b/drivers/net/ixgbe/ixgbe.h 2009-02-10 14:32:57.000000000 -0800 @@ -35,7 +35,7 @@

I am trying to build a custom kernel for the HIPL code (infrahip.hip.fi), using the patch for the Linux 2.6.18 kernel. I followed all the instructions for getting the kernel source and making a custom kernel provided on the wiki. The rpmbuild fails with the following messages: Get an error on this step (figured out my other problem): Patch #40000

Hi Keir: [LINUX] netfront: Cleanup and fix TSO/GSO/CHECKSUM conditionals This patch tries to minimise the amount of code that is conditionally compiled. This is desirable (and the Linux way) as it helps to prevent people breaking code unwittingly since conditionals may hide compile problems. It also adds a missing conditional around the TSO ethtool operations. This also helps the building of

As I plow through the Kernel source to figure out why the BEET patch is not working, I notice that there are two similar directories under ~/rpmbuild/BUILD/kernel-2.6.18: linux-2.16.18.i386 and linux-2.16.18.i686 So which one am I suppose to be patching? Currently, the patch starts out with: diff -urN a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c I followed the kernel source setup

Hello, I''m trying to setup Xen on a machine with 2 physical network devices using linux bonding without success. I haven''t received any answer on my question on xen-users, the only discussion on this seems to be at http://lists.xensource.com/archives/html/xen-devel/2005-10/msg01174.html Could someone shed some light on state/ plans regarding Xen and bonding? Regards --

This patch adds experimental VMDq support (AKA Netchannel2 vmq) to the ixgbe driver. This applies to the Netchannel2 tree, and should NOT be applied to the "normal" development tree. To enable VMDq functionality, load the driver with the command-line parameter VMDQ=<num queues>, as in: $ modprobe ixgbe VMDQ=8 You can then set up PV domains to use the device by modifying your VM

In netfront, the current driver reserves pools of grant refs for the tx and rx paths, each big enough to satisfy one virtual nic. With more than one nic active you will run out. Both the tx and rx path will BUG() when you do. This patch creates separate tx and rx ref pools for each interface. Signed-off-by: Jim Dykman <dykman@us.ibm.com> Jim

This patch fixes the root cause of bug 183: per-interface transaction ids are being used to index global tables. Signed-off-by: Jim Dykman <dykman@us.ibm.com> Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Single domU, ping loopback and the local eth0. Signed-off-by: Jim Dykman <dykman@us.ibm.com> Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Some network test utilities for the library: Signed-off-by: Jim Dykman <dykman@us.ibm.com> Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths