| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] Attempt to allocate order 5 skbuff. IncreaseMAX_SKBUFF_O
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
|
|
|
| |
|
Home