similar to: [Patch] vnet-module

Hallo! Has anybody a working version for linux-2.6.16 ARCH=x86_64? As i see it correctly, there is a kernel-call for socketcall, with x86_64 will not have... (and this in kernel-module ?) wbr Robert Valentan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi all, The patch below does four trivial changes and one big change Trivial changes, these are all in br_netfilter.c: - check ar_pln==4 when giving bridged ARP packets to arptables - delete unnecessary if in br_nf_local_in - add more logging for the "Argh" message - add some brag-comments in the file head comment Big change: let {ip,arp}tables see VLAN tagged {I,AR}P packets. This

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

On Mon, Mar 06, 2023 at 07:00:10PM +0300, Arseniy Krasnov wrote: > > >On 06.03.2023 18:51, Stefano Garzarella wrote: >> On Mon, Mar 06, 2023 at 06:31:22PM +0300, Arseniy Krasnov wrote: >>> >>> >>> On 06.03.2023 15:08, Stefano Garzarella wrote: >>>> On Sun, Mar 05, 2023 at 11:07:37PM +0300, Arseniy Krasnov wrote: >>>>> In case of

On Thu, Mar 09, 2023 at 07:20:20PM +0300, Arseniy Krasnov wrote: > > >On 09.03.2023 19:21, Stefano Garzarella wrote: >> On Thu, Mar 09, 2023 at 01:10:36PM +0300, Arseniy Krasnov wrote: >>> Hello, >>> >>> this patchset evolved from previous v2 version (see link below). It does >>> several updates to virtio/vsock: >>> 1) Changes

Hi, This is a second try to fix the long chain call lengths in netfilter. The difference with the previous patch is that I got rid of the extra argument. I somehow didn't see it could be done without using the 'int *ret2' argument. A comment on the number of arguments to nf_hook_slow: I don't think the number of arguments should be decreased. For the bridge-nf code, f.e., the

Hi, I'm having some problems with kernel panic with the bridge. I have the following network setup: | | +----+----+ | (eth0) | +---------+ | Bridge | | | | (eth1)|<-- Mirror of ---+ Switch | +---------+ +- - - - -+ 1000SX link | |<--1000SX-->| Switch | | | |

On Thu, Mar 09, 2023 at 11:27:02PM +0300, Arseniy Krasnov wrote: >Since we now no longer use 'skb->len' to update credit, there is no sense >to update skbuff state, because it is used only once after dequeue to >copy data and then will be released. > >Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") >Signed-off-by: Arseniy Krasnov

On Sun, Mar 05, 2023 at 11:06:26PM +0300, Arseniy Krasnov wrote: >Substraction of 'skb->len' is redundant here: 'skb_headroom()' is delta >between 'data' and 'head' pointers, e.g. it is number of bytes returned >to user (of course accounting size of header). 'skb->len' is number of >bytes rest in buffer. > >Fixes: 71dc9ec9ac7d

> It appears that when alloc''ing a skb, it is bring padded by > an arbitrarily > (and excessive) long value. The value for this padding > really only needs to > be 24. 24 = 14 for the ethernet header + 2 for the cache > alignment + 4 for > the CRC + 4 for the VLAN flags. Given that we''re allocating page sized buffers the current situation

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=339 ------- Additional Comments From scrizt@ludd.ltu.se 2006-06-26 17:57 MET ------- Is this bug forgotten ? Anyhow, I ran into it when setting up this strange network of mine.. I dont think my setup is causing anything strange however.. It appears even if no machine is connected to the "inner" port of the bridge.. I

Hi, One of my servers has had its dom0 "oops" over and over twice in the last week. Unfortunately this is newly deployed so I have no idea if it is down to Xen or not. xen_changeset : Mon Dec 12 18:47:47 2005 +0100 8270:4ad23e798798 dom0 kernel is a vanilla 2.6.12 with Ralph''s .6+xen kernel patch applied. x86_32 sarge packages were used. The .config is

-----Ursprüngliche Nachricht----- Von: Moritz Möller <m.moeller@bigpoint.net> Gesendet: Do 20.03.2008 13:00:21 An: xen-devel@lists.xensource.com; Betreff: [Xen-devel] 3w-9xxx / Out of SW_IOMMU space > Hi, > > .. > Xen 3.2 with 2.8.18.8 kernel from xen (linux-2.6.18-xen.hg) gives lot of > SW IOMMU errors after a 2-3 GB on-disk copy on a 3ware controller. Hallo! I have

On Tue, May 27, 2008 at 12:20:47PM +0100, Mark McLoughlin wrote: > hdr->csum_start is the offset from the start of the ethernet > header to the transport layer checksum field. skb->csum_start > is the offset from skb->head. > > skb_partial_csum_set() assumes that skb->data points to the > ethernet header - i.e. it computes skb->csum_start by adding > the

On Tue, May 27, 2008 at 12:20:47PM +0100, Mark McLoughlin wrote: > hdr->csum_start is the offset from the start of the ethernet > header to the transport layer checksum field. skb->csum_start > is the offset from skb->head. > > skb_partial_csum_set() assumes that skb->data points to the > ethernet header - i.e. it computes skb->csum_start by adding > the

From: Mark McLoughlin <markmc at redhat.com> hdr->csum_start is the offset from the start of the ethernet header to the transport layer checksum field. skb->csum_start is the offset from skb->head. skb_partial_csum_set() assumes that skb->data points to the ethernet header - i.e. it computes skb->csum_start by adding the headroom to hdr->csum_start. Since

From: Mark McLoughlin <markmc at redhat.com> hdr->csum_start is the offset from the start of the ethernet header to the transport layer checksum field. skb->csum_start is the offset from skb->head. skb_partial_csum_set() assumes that skb->data points to the ethernet header - i.e. it computes skb->csum_start by adding the headroom to hdr->csum_start. Since

OS: CentOS 6.5. After I set multicast_router of bridge and it's port to 2, like following: echo 2 > /sys/devices/virtual/net/eth81/bridge/multicast_router echo 2 > /sys/devices/virtual/net/bond2/brport/multicast_router Then soft lockup occured: Message from syslogd at node-0 at Jan 9 15:47:12 ... kernel:BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0] And the call

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

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=478 Summary: Kernel panic - not syncing: Aiee, killing interrupt handler! Product: iptables Version: 1.3.5 Platform: x86_64 OS/Version: Fedora Status: NEW Severity: blocker Priority: P2 Component: iptables AssignedTo: