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

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


  • To: "Fischer, Anna" <anna.fischer@xxxxxx>
  • From: "Robert Dunkley" <Robert@xxxxxxxxx>
  • Date: Wed, 6 May 2009 08:03:32 +0100
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 06 May 2009 00:04:19 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcnN7JJ9eaAgL9CoR+e1ofdxmch/kQAG//hwAAO0RCA=
  • Thread-topic: [Xen-users] Attempt to allocate order 5 skbuff. IncreaseMAX_SKBUFF_ORDER

I get this same error on bootup only, I'm using a Centos 5.2 Dom0 and
the Xen 3.31 Centos RPMs. I suspect it is related to Infiniband/IPOIB
(OFED 1.3.1) and the 32Kb MTU I use but I never found a solution. Please
let me know if you find any kind of solution.

Thanks,

Rob
-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Fischer,
Anna
Sent: 06 May 2009 06:47
To: Steven Timm
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-users] Attempt to allocate order 5 skbuff.
IncreaseMAX_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

The SAQ Group

Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
Company Number: 06481952

http://www.saqnet.co.uk AS29219

SAQ Group Delivers high quality, honestly priced communication and I.T. 
services to UK Business.

Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : 
Backups : Managed Networks : Remote Support.

ISPA Member

Find us in http://www.thebestof.co.uk/petersfield


_______________________________________________
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®.