This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-users] Attempt to allocate order 5 skbuff. Increase MAX_SKBUFF_

To: Steven Timm <timm@xxxxxxxx>
Subject: RE: [Xen-users] Attempt to allocate order 5 skbuff. Increase MAX_SKBUFF_ORDER
From: "Fischer, Anna" <anna.fischer@xxxxxx>
Date: Wed, 6 May 2009 05:46:42 +0000
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 05 May 2009 22:48:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.64.0905052024570.27970@xxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <Pine.LNX.4.64.0905011400380.12390@xxxxxxxxxxxxxxx> <0199E0D51A61344794750DC57738F58E66BB5FAC6D@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0905031824430.300@xxxxxxxxxxxxxxx> <0199E0D51A61344794750DC57738F58E66BB5FAD07@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0905040859520.13912@xxxxxxxxxxxxxxx> <0199E0D51A61344794750DC57738F58E66BB6AF6EC@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0905052024570.27970@xxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcnN7JJ9eaAgL9CoR+e1ofdxmch/kQAG//hw
Thread-topic: [Xen-users] Attempt to allocate order 5 skbuff. Increase MAX_SKBUFF_ORDER
> Subject: RE: [Xen-users] Attempt to allocate order 5 skbuff. Increase
> >> very few ports from accessing our site.
> >>
> >> I am not sure why the iptables_nat module would be loaded
> >> because we are not using NAT in our network configuration, at least
> we
> >> are
> >> not intending to do so.
> >
> > Well if you don't need it then just try and remove the NAT module
> using "modprobe -r iptable_nat". And see if that makes any difference.
> >
> Can't remove it, get the message
> "module is in use".. not sure by what.

Do you have any rules in the NAT table? E.g. check "iptables -t nat -L". Then 
remove those rules and try removing the module again. I doubt that the NAT 
module is the core of your problem though.

> >>> Now the issue about MAX_SKBUFF_ORDER should only show up when you
> are
> >> trying to send large packets. Do you use jumbo frames or something
> like
> >> that? What MTU sizes are set for the interfaces? As far as I know
> the
> >> message you get means that Xen is trying to allocate a buffer for
> the
> >> packet to send, but the packet size is too big for the buffer
> >> allocator.
> >>>
> >> [root@fg3x3 ~]# ifconfig
> >> eth0      Link encap:Ethernet  HWaddr 00:16:3E:05:03:03
> >>            inet addr:  Bcast:
> >> Mask:
> >>            inet6 addr: fe80::216:3eff:fe05:303/64 Scope:Link
> >>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>            RX packets:2971214615 errors:0 dropped:0 overruns:0
> frame:0
> >>            TX packets:1576876803 errors:0 dropped:0 overruns:0
> >> carrier:0
> >>            collisions:0 txqueuelen:1000
> >>            RX bytes:2428856680 (2.2 GiB)  TX bytes:4068069258 (3.7
> GiB)
> >>
> >> No--no jumbo frames anywhere. MTU size is the standard 1500.
> >
> > This is on all Dom0/DomU frontend and backend interfaces?
> That's right.
> >
> >
> >
> >
> >>> In general, you can configure the Xen kernel to use a Xen-specific
> >> buffer allocator, or the kernel's default buffer allocator. There is
> a
> >> kernel configuration option for that and it is called
> >> CONFIG_XEN_SKBUFF. You could try and switch that off, and recompile
> the
> >> kernel.
> >>>
> >> So CONFIG_XEN_SKBUFF is by default on?
> >
> CONFIG_XEN_SKBUFF is on in my config.
> There is no MAX_SKBUFF_ORDER parameter anywhere in my source tree,
> much less the config file.

MAX_SKUFF_ORDER is not a configuration option. It is part of the Dom0/DomU 
kernel code.

Your posted kernel config is from your Dom0? You said before that you are 
running a 64-bit Dom0. You need to check the CONFIG_XEN_SKBUFF option in the 
Dom0 config. I am in general wondering if you might have issues with your 
DomU/Dom0 configuration. How did you install those kernels? Did you install 
them using the distro? Did you compile them yourself? I assume you also run a 
64-bit hypervisor?

If it is easy for you to recompile DomU/Dom0 kernels then you could try and 
CONFIG_HAVE_ARCH_DEV_ALLOC_SKB disabled, and see if it makes any difference.

Xen-users mailing list