[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Steven Timm <timm@xxxxxxxx>
  • 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
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • 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
> MAX_SKBUFF_ORDER
> 
> >> 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:131.225.107.144  Bcast:131.225.107.255
> >> Mask:255.255.255.0
> >>            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 
recompile with CONFIG_XEN_SKBUFF, CONFIG_HAVE_ARCH_ALLOC_SKB and 
CONFIG_HAVE_ARCH_DEV_ALLOC_SKB disabled, and see if it makes any difference.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.