[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: Robert Dunkley <Robert@xxxxxxxxx>
  • From: "Fischer, Anna" <anna.fischer@xxxxxx>
  • Date: Wed, 6 May 2009 07:28:33 +0000
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 06 May 2009 00:30:38 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcnN7JJ9eaAgL9CoR+e1ofdxmch/kQAG//hwAAO0RCAAARZXUA==
  • Thread-topic: [Xen-users] Attempt to allocate order 5 skbuff. IncreaseMAX_SKBUFF_ORDER

I don't know the detailed implementation but as I said to Steven I believe this 
issue should only show up when you are trying to allocate too large buffers.

I would recommend to post this to xen-devel. 

> -----Original Message-----
> From: Robert Dunkley [mailto:Robert@xxxxxxxxx]
> Sent: 06 May 2009 00:04
> To: Fischer, Anna
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [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®.